Re: Best way to block incoming TCP connections?

[Lennert Buytenhek <buytenh () gnu org>]

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

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

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



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

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. :)


greetings,
Lennert