mailing list archives
Re: Best way to block incoming TCP connections?
From: Lennert Buytenhek <buytenh () gnu org>
Date: Sun, 7 May 2000 12:31:59 +0200 (MEST)
(gee, what a cross-post.. everybody, forgive me please)
On Sun, 7 May 2000, Darren Reed wrote:
# 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
# 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
Looks to me like it allows finger printing as well as stealth scans,
depending on the current state of affairs of TCP in Linux...
I'm sure that the Linux Powers That Be will argue that protecting against
finger printing/stealth scanning is a useless 'feature' that only gets in
the way.. *sigh*
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
The established/related state rule above should do just this.
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 ?
Heh. I'm sure that the Linux Powers That Be will argue that T/TCP does not
exist in nature (sorry, couldn't resist :)
The --syn option will match any packets that have SYN on and RST and ACK
off. It doesn't care about the other flags. So a SYN,FIN packet will match
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
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.
In that case, the local host receives a RST from the local firewall,
right? What kind of bad things might that cause? But yes, I agree this is
not the right place for deciding a RST needs be sent.
I imagine that "-j REJECT" can also be applied for the "forwarding"
chain, if that existed ?
Yup, the FORWARD chain.
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.
Right now, the linux ppl are arguing that the fw generating RSTs is bad,
violates end-to-end, and will cause imminent internet death. Can you see
anything which could remotely support these claims? (you might want to
check a netfilter archive for the full thread, if you're interested)
Now, in IP Filter (can't resist :)
You be forgiven... :)
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.
RFC793, page 64. If I recall correctly. :)