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