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
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
>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
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
--
>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
> 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
--
> 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