Re: Best way to block incoming TCP connections?

[Greg Hinton <zenbum () websalad net>]

(This message is a reply to a private message to me.  I am CCing it to the
Netfilter list, in gross violation of email Netiquette.  I hope & trust
the original party doesn't object.  If they do, then I have sullied my
honor and will commit ritual seppaku (sp?) in the alt.firewalls.seppaku
newsgroup.)

(I think this is highly relevant to the recent discussions/food-fights in
the Netfilter list and I'm also very curious to hear if any of you
"experts" have a better way of "skinning the cat" than the kludge I've
implemented.  If you'd please take a moment to look at a small snippet of
my firewall script below and let me (or better yet, all of us) know if
there's a better way, I'd appreciate it.  Maybe somebody smarter than me
can convince me that we really don't need "--reject-with RST"
functionality after all, in which case I promise to shut up (but I refuse
to commit seppaku).  Thanks.)

(I'm also cross-posting this message to the nmap-hackers list.  We haven't
heretofore gotten any input from the nmap experts but I think it's long
overdue that we solicit their advice.  They're intelligent developers and
they generally don't mind helping us "white hats".  Fyodor and his elves
have created the premiere port scanning tool.  It's the tool preferred by
all intelligent crackers to dissect your firewalls and hosts to determine
the best way to invade them.  It's also the tool no serious admin should
be without to test their systems for vulnerabilities.  Some of the nmap
hackers might find it very interesting indeed that most of you apparently
don't take them seriously and make no efforts to evade things like "nmap
-sA" scans.  But of course they already know that; some cracker is
probably doing an nmap -sA scan on you even as we speak.)

The original writer said:
>     I am lost.  Alex wants to iptables -P INPUT DROP
>     and you do what?   Iknow it is equivalent to a RST but how do you 
>     actually do it with iptables?
>
> I'd like to look at it.

Well, letsee, what's the best way to show you the relevant parts of my
firewall script?  Let me give this a try and if it's not clear then let me
know....

In my INPUT chain (in the default "filter" table) all I do is check the
input interface and then branch to a corresponding user-defined chain (I
do this to both better modularize the code and to optimize speed).  The
user-defined chain that gets called when a packet arrives on the Internet
interface is called "in-inet".  Here it is, in its entirety, with the
"critical" line commented:

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

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

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.  So I'd have to kludge some spaghetti code, but it could definitely
be implemented fairly easily.  In principle, the line above is what I
would need to accomplish.

The reason I think this new functionality would be far superior to the
current scheme is because I wouldn't have to hand any bad packets off to
the TCP stack, hoping that that section of code still works the way it did
in the previous version.  My firewall script would have explicit control
over the entire process and thus I could sleep easier at night.

The alternative you mention is "-j DROP" (at least that's what I think you
meant).  However, that method doesn't send anything back to the
originator, doesn't help you evade "nmap -sA" scans, and -- perhaps most
importantly -- it violates the relevant IETF Standards (RFC793, et al). 
Other than that, it's ok.

Hope this helps.

Regards...
Greg

-- 
Greg Hinton (aka ZenBum)
<zenbum () websalad net>      <http://www.websalad.net>
"Search for me in the words I failed to find."  -- Blaga Dimitrova