Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Limit telnet to eth1?

322 views
Skip to first unread message

Andrew Spartz

unread,
Dec 27, 2003, 4:22:45 PM12/27/03
to
I am using a linux box as my router/server/bottle washer...

Unfortunately, occassionaly I have to access it from the INSIDE of my
home LAN (physical security good) using Windows. I cannot get ssh to
work happily on windows, so this leave me with telnet. I would greatly
prefer not to have the WAN side of the box open to telnet (phyical
security NONE).

Can I limit telent to only listen on eth1 and ignore eth0? I asume this
is an iptables issue, but my skills there are still pretty poor.

TIA

ARS

Charles LaCour

unread,
Dec 27, 2003, 8:26:10 PM12/27/03
to
You could have iptables block it for you but it would be better to bind
telnet to the interface you want. If you are using the telnet that is
part of xinetd then you can use the "bind" option in the xinetd file for
telnet to bind telnet to the IP address you want (refer to the man page
for xinetd.conf). If you are using a separate telnet service look at
the documentation for that application.

I would highly suggest that you do not use telnet, use ssh instead.
PuTTY is a decent ssh implementation for the wintel platform. I do not
even have telnet installed on my Linux and Solaris boxes at home. My
home computers are behind a SonicWall firewall appliance but I still
treat them as if they are in an insecure environment. I am a firm
believer that every extra security measure you take makes it that much
harder for some one to hack you.

--
Thanks
Charles LaCour

ch...@nospam.com

unread,
Dec 27, 2003, 11:04:34 PM12/27/03
to

>You could have iptables block it for you but it would be better to bind
>telnet to the interface you want. If you are using the telnet that is
>part of xinetd then you can use the "bind" option in the xinetd file for
>telnet to bind telnet to the IP address you want (refer to the man page
>for xinetd.conf). If you are using a separate telnet service look at
>the documentation for that application.

I would be best to do both. For a 'router/server/bottle washer...'
that has internet exposure, I strongly recommend learning how to setup
iptables Either manually, which really isn't too hard with a good
template or using a utility like Guarddog.


>I would highly suggest that you do not use telnet, use ssh instead.
>PuTTY is a decent ssh implementation for the wintel platform. I do not
>even have telnet installed on my Linux and Solaris boxes at home. My
>home computers are behind a SonicWall firewall appliance but I still
>treat them as if they are in an insecure environment. I am a firm
>believer that every extra security measure you take makes it that much
>harder for some one to hack you.

I highly agree with the SSH recommendation.

-Chris

Armin F. Gnosa

unread,
Dec 28, 2003, 12:24:57 PM12/28/03
to
In article <4elsuvcoctnoa8k5u...@4ax.com>, ch...@nospam.com wrote:
>
>
> I would be best to do both. For a 'router/server/bottle washer...'
> that has internet exposure, I strongly recommend learning how to setup
> iptables Either manually, which really isn't too hard with a good
> template or using a utility like Guarddog.

Although you might not even need iptables provided you 'hardened' the
machine, i.e. there are no services visible to the outside.

OTOH, it might be desirable to have a packet filter for malformed packets
or ICMP flooding attempts, BEFORE the actual TCP/IP stacks has to deal with
them.

>>I would highly suggest that you do not use telnet, use ssh instead.
>>PuTTY is a decent ssh implementation for the wintel platform. I do not
>>even have telnet installed on my Linux and Solaris boxes at home. My
>>home computers are behind a SonicWall firewall appliance but I still
>>treat them as if they are in an insecure environment. I am a firm
>>believer that every extra security measure you take makes it that much
>>harder for some one to hack you.
>
> I highly agree with the SSH recommendation.

Here as well. How often have I seen script kiddies breaking in through
the telnet service only to find that they're too dumb to execute the
install script of their r00tkit...

Regards
Armin
--

ch...@nospam.com

unread,
Dec 28, 2003, 2:40:51 PM12/28/03
to
On Sun, 28 Dec 2003 18:24:57 +0100, "Armin F. Gnosa"
<palm-a...@gnosa.com> wrote:

>In article <4elsuvcoctnoa8k5u...@4ax.com>, ch...@nospam.com wrote:
>>
>>
>> I would be best to do both. For a 'router/server/bottle washer...'
>> that has internet exposure, I strongly recommend learning how to setup
>> iptables Either manually, which really isn't too hard with a good
>> template or using a utility like Guarddog.
>
>Although you might not even need iptables provided you 'hardened' the
>machine, i.e. there are no services visible to the outside.
>
>OTOH, it might be desirable to have a packet filter for malformed packets
>or ICMP flooding attempts, BEFORE the actual TCP/IP stacks has to deal with
>them.

Even without IPTables being setup, turning on some of the kernel
network protections like syn flood detection is a good idea.
echo '1' > /proc/sys/net/ipv4/tcp_syncookies

I prefer having iptables drop spoofed and malicious packets more than
I trust individual services or the tcpip stack. Perhaps its just my
misunderstanding of how services bind to an address. I don't trust
that a service can't be accessed with a spoofed packet sent to an
inside address that arrives on an external interface.

Also, just because a service isn't listening to an outside address,
doesn't mean someone can't connect using the inside address if the
routing policies allow it. This can easily be prevented by using
iptables to control the routing and packet admission.

A safe iptables philosophy is to start by limiting everything on the
outside interface and then punch holes to allow only the incoming
traffic you expect.


>>>I would highly suggest that you do not use telnet, use ssh instead.
>>>PuTTY is a decent ssh implementation for the wintel platform. I do not
>>>even have telnet installed on my Linux and Solaris boxes at home. My
>>>home computers are behind a SonicWall firewall appliance but I still
>>>treat them as if they are in an insecure environment. I am a firm
>>>believer that every extra security measure you take makes it that much
>>>harder for some one to hack you.
>>
>> I highly agree with the SSH recommendation.
>
>Here as well. How often have I seen script kiddies breaking in through
>the telnet service only to find that they're too dumb to execute the
>install script of their r00tkit...

Usually I see more incompetence with the Windows attacks. So yo-yo
found an attack script on the internet, tried it out, then had no clue
what to do when they got a command prompt running under the system
context. They don't even know how to use 'net user...'

-Chris

Armin F. Gnosa

unread,
Dec 28, 2003, 5:01:14 PM12/28/03
to
In article <imbuuvobsq78v3nac...@4ax.com>, ch...@nospam.com wrote:
> On Sun, 28 Dec 2003 18:24:57 +0100, "Armin F. Gnosa"
><palm-a...@gnosa.com> wrote:
>

> Even without IPTables being setup, turning on some of the kernel
> network protections like syn flood detection is a good idea.
> echo '1' > /proc/sys/net/ipv4/tcp_syncookies

Perhaps a bit too big just for the personal routing machine?
A dial-up computer, altough an easy target, wouldn't normally be
a victim of a DoS attack.

> I prefer having iptables drop spoofed and malicious packets more than
> I trust individual services or the tcpip stack. Perhaps its just my
> misunderstanding of how services bind to an address. I don't trust
> that a service can't be accessed with a spoofed packet sent to an
> inside address that arrives on an external interface.

I'm not a kernel developer, but I think the routing code should take
care of that.

> Also, just because a service isn't listening to an outside address,
> doesn't mean someone can't connect using the inside address if the
> routing policies allow it. This can easily be prevented by using
> iptables to control the routing and packet admission.
>
> A safe iptables philosophy is to start by limiting everything on the
> outside interface and then punch holes to allow only the incoming
> traffic you expect.

100% ACK. What I meant was that you COULD have a system that is not
open to the public without using a packet filter. Using it (and
configuring it sensibly) is certainly the way to go.

>>the telnet service only to find that they're too dumb to execute the
>>install script of their r00tkit...
>
> Usually I see more incompetence with the Windows attacks. So yo-yo
> found an attack script on the internet, tried it out, then had no clue
> what to do when they got a command prompt running under the system
> context. They don't even know how to use 'net user...'

That must be their young age. They weren't forced to use the command
line due to the lack of a shiny GUI. Most of them haven't probably
even seen one.

Regards
Armin
--

Andrew Spartz

unread,
Dec 30, 2003, 3:22:01 PM12/30/03
to
Charles LaCour <nos...@lacour.homelinux.com> wrote:

> I would highly suggest that you do not use telnet, use ssh instead.
> PuTTY is a decent ssh implementation for the wintel platform.

Got it -- thanks -- so much for telnet.

ARS

0 new messages