[ale] Another Ipchains question

Joe Steele joe at madewell.com
Thu Jan 24 12:55:25 EST 2002


On Thursday, January 24, 2002 9:43 AM, James P. Kinney III wrote:
> 
> /sbin/ipchains -A input -i eth0 -p tcp -s 0/0 23 -d 0/0 -j DENY
>
> This will deny all telnet from anywhere to your machine.
>

Umm...  I don't think so.  This only denies the input of packets 
whose source TCP port is 23 (telnet).  Most telnet connections 
originate from ports > 1024.  The above rule will not block telnet 
access.  The rule should be something like:

   /sbin/ipchains -A input -i eth0 -p tcp -d 0/0 23 -j DENY

This will deny any incoming packet destined for TCP port 23.

> If you want to allow a single machine telnet access, before the above
> rule add:
>
> /sbin/ipchains -A input -i eth0 -p tcp -s 192.168.0.2/255.255.255.255 23
> -d 192.168.2.231/255.255.255.255 -j ACCEPT
>

The rule above has the same problem as I mentioned earlier.  The 
source port is not likely to be 23.  It's the destination port that 
will be 23.

> IP/NETMASK can also be written IP/24 (IP/255.255.255.0) IP/32
> (IP/255.255.255.255)
>
> On Thu, 2002-01-24 at 09:06, Chris Fowler wrote:
> >
> > I thing I have it.  Here is my command line to disable iincoming telnet requests to the server that this command is ran on
> >
> > /sbin/ipchains -A input -i eth0 -p tcp -s 0.0.0.0/0 23 -d 192.168.2.231/0 23 -j DENY
> >

Again, this rule has the same problem as I mentioned earlier.  It 
will only deny packets whose source port is 23.  Most telnet will get 
through.

> >
> > But here is ipchains -L
> > Chain input (policy ACCEPT):
> > target     prot opt     source                destination           ports
> > DENY       tcp  ------  anywhere             anywhere              telnet ->   telnet
> > Chain forward (policy ACCEPT):
> > Chain output (policy ACCEPT):
> > Chain masq (0 references):
> >
> >
> > the /0 on destination is screwed.  What should /X be?  255?
> >

Using "/0" means a netmask of 0.0.0.0, so any destination address 
will match.  If you want to only match a single address, then you 
want a netmask of 255.255.255.255, which is "/32".  However, unless 
you intend to allow forwarding of telnet packets arriving on eth0 to 
other hosts, you should probably not limit the destination to a 
single address, but instead use "-d 0/0 23".  (Or better yet, start 
with a default policy of DENY, and then figure what you want to 
specifically allow.)

Although it may not be relevant to your specific situation, this 
brings up another issue that people should consider before they try 
to deny access to a single destination IP:  

There are a couple acceptable strategies OSes can implement for 
handling incoming packets on a given interface.  One strategy is to 
consider the packet as local if its destination address matches the 
address of *any* interface on the host, not just the interface on 
which it arrived.  The other strategy is to require local packets to 
have a destination address which matches the specific interface on 
which they arrive.  

My understanding has been that Linux implements the first strategy 
(someone correct me if this has changed).  This can allow a potential 
hole in your firewall if you are only blocking incoming packets whose 
destination is the same as the interface on which they arrive.

For example:  eth0 has the address 192.168.2.231, and you have a rule 
saying:

   /sbin/ipchains -A input -i eth0 -p tcp -d 192.168.2.231/32 23 -j DENY

If someone one the same network (eth0) knows the MAC address of your 
box, they could send it a telnet connection request with a destination 
address of 127.0.0.1.  The packet would be recognized as belonging to 
your box and the above rule would not block the connection (in which 
case, you hope other layers of defense will kick in, such as 
hosts.allow/deny).  Here again, starting with a default policy of 
DENY would help defend against such holes.

--Joe

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.






More information about the Ale mailing list