(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
Received on May 07 2000
Intro
