![nmap-announce logo](/images/nmap-announce-logo.png)
Nmap Announce mailing list archives
Re: Best way to block incoming TCP connections?
From: Darren Reed <avalon () coombs anu edu au>
Date: Sun, 7 May 2000 13:28:19 +1000 (Australia/NSW)
In some mail from Greg Hinton, sie said: [...]
# in-inet: returns if and only if packet should be logged and REJECTed iptables -N in-inet # check source address iptables -A in-inet -j chk-inet-src # check protocol iptables -A in-inet -j in-chk-proto # accept anything to established/related ports iptables -A in-inet -m state --state ESTABLISHED,RELATED -j ACCEPT # let stack handle other non-SYN TCP segments iptables -A in-inet -p tcp ! --syn -j ACCEPT ### <--- this is the critical line # reply to pings, drop other ICMP messages iptables -A in-inet -p icmp --icmp-type echo-request -j ACCEPT iptables -A in-inet -p icmp -j in-log-drop # reject everything else iptables -A in-inet -j RETURN
[...]
The critical line is a counter-intuitive kludge and makes me nervous. But it works. It accepts bad packets (which would otherwise be REJECTed or DROPped) so that the firewall's TCP stack will generate a RST reply when it should.
Looks to me like it allows finger printing as well as stealth scans, depending on the current state of affairs of TCP in Linux...
If we had the addition to iptables(1) I've been whining for, then that line would be replaced with the following: iptables -A in-inet -p tcp ! --syn -j REJECT --reject-with RST
Where did state actually get accepted by packets with the SYN flag ? Or does Linux do magic things such that you don't need to worry about that ? Nevertheless, that's a bad rule, IMHO, or maybe my understanding of iptables(1) is being revealed as non-existant :) What does it do with SYN-FIN packets and similar ?
Actually I couldn't code "-j REJECT" in the user-defined chain because, for reasons I don't understand, Rusty limits that target to the INPUT chain.
The limitation should be to INPUT packets, not INPUT chain, so it looks like more information needs to be passed down than is currently being passed down. Generating things like RST packets to already outbound packets is not really a fun thing to do when you consider that you might actually be generating replies to local connections going out. I imagine that "-j REJECT" can also be applied for the "forwarding" chain, if that existed ? Other comments aside, I think this is what you want to do: - generate TCP RST's for any TCP packet this isn't recognised as part of a currently established connection. Now, in IP Filter (can't resist :) you'd do it like this: block return-rst in proto tcp all pass in proto tcp all flags S keep state pass out proto tcp all flags S keep state (or in a similar manner to that, anyway). The *only* rule you must have is to silently handle the receipt of a packet with a TCP RST in it, lest you enter into a "storm", but then that should be in what generates the RST's, not your filter lists. Darren
Current thread:
- Re: Best way to block incoming TCP connections? Greg Hinton (May 06)
- Re: Best way to block incoming TCP connections? Darren Reed (May 06)
- Re: Best way to block incoming TCP connections? Lennert Buytenhek (May 07)
- Re: Best way to block incoming TCP connections? Michael T. Babcock (May 07)
- Re: Best way to block incoming TCP connections? Lennert Buytenhek (May 07)
- <Possible follow-ups>
- Re: Best way to block incoming TCP connections? Greg Hinton (May 06)
- Re: Best way to block incoming TCP connections? Darren Reed (May 06)