David Busby wrote:
I have this these rules on a host, to protect only this host.
# Generated by iptables-save v1.2.11 on Tue Jun 7 23:03:58 2005
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.0/255.0.0.0 -i lo -j ACCEPT
-A INPUT -d 192.168.42.2 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -d 192.168.42.2 -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
# Completed on Tue Jun 7 23:03:58 2005
I used loaded these same rules changing only the ip address to match
mine and tested only SSH (didn't have apache running). It worked for
me, however, the DNS reverse lookup for the by SSH daemon had to time
out which took around 10-20 seconds (I'm sure there is a real fixed
number there I'm just to lazy to look it up). Ensure the eth0 really is
192.168.42.2 and be patient. I don't know if there would be issues
with the web server you have with this or not as I didn't test. The
bottom line is that this is an incomplete firewall set as SSH uses DNS
and, even though it may be configured to ignore the result it still does
the query, making it wait for a timeout is a problem.
While not part of your question I'd like to address some comments made
here about connection tracking (all that --state stuff):
For the record, once a connection tracking module is loaded it tracks
connections, it does nothing to them it just tracks the numbers. You
not need to see --state NEW in a rule to actually start tracking. The
--state things are there so you can =query= the state of the packet
relative to the connection tracker, you can see if this is a NEW packet,
an ESTABLISHED connection or a connection/packet RELATED to another (for
example FTP and FTP Data channels). The module tracks the connections
the --state allows us to apply the information to our firewall rules.
This confused me for quite a while too but now that I get it, it is
really quite obvious and simple.
