gabriel rosenkoetter on Thu, 16 May 2002 11:13:25 -0400


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] IP Tables and SSH X forwarding (fwd)


On Thu, May 16, 2002 at 04:20:11PM +0200, Martin F Krafft wrote:
> it actually *works* in iptables too...

Only if you really force it to.

> there are no hoops to jump through, it's actually *easier* than IPF.

No, it's actually harder. What would take me two rules in IPF takes
me four in IP Tables. See the example in the original email. Those
two lines do everything that it takes me this to do in IP Tables:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -A internal -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT 
iptables -A internal -p udp -m udp --dport 22 -j ACCEPT 

IPF's "keep state" is the same thing as the first two lines, and
it's specific to the port in question. (God forbid I want to treat
services differently, refusing to keep state on some, and actually
had to have all four of those lines for each service I wanted to
keep state on...) All of this disregards the gateway (rather than
local) firewall, where Netfilter's FORWARD chain comes into play
and *really* complicates things.

You're speaking out of your ass, btw, since I know you've never used
IPF.

> i have to give thought to this. i have not worked with any firewall
> before that worked this way. tell me: does IPF automatically allow
> packets through for a connection whose state you explicitly saved?
> iptables certainly doesn't.

Yep. That's the point of state. That's why I say IP Tables doesn't
(really) have it. (Ever configured a Cisco PIX for instance? Guess
which model it more closely resembles...)

> and linux surely does not allow any form of spoofing, provided
> you did not turn off the default.

Uh... point to any code in the TCP/IP stack in Linux that actually
does this, and I'll show you how to get around it. You can't both
trust your network connection and also avoid IP spoofing. If I SNMP
walk on your router and tell it to tell you that a packet's coming
from some IP address, you'll believe it. Nothing you can do about
it on the host side.

> now tell me just why IPF's way is better (after you accept that no,
> iptables' way of doing it does *not* have negative security
> implications)!

See below (all the way down).

> and i'd also be interested in why you argue that iptables facilitates
> OS fingerprinting. again, don't feel obliged to reread the book,
> i won't nitpick, i just want to know why you think so.

Netfilter returns default values where most OSes return different
ones depending on state. This makes it quite easy to detect a host
running Netfilter (and, if memory serves, even which version of
Netfilter) which is a HUGE problem as new vulnerabilities are
discovered. Granted, all software firewalls have had this problem
now and then, but last I heard, Netfilter still did and nobody
seemed to care.

That's based on Bugtraq reading. I'd get the references, but it's
not really my job to do your homework for you.

> usually it's better to give the lines that create your rulebase rather
> than this output (which sucks).

I don't have any rules in a file other than /etc/sysconfig/iptables,
which isn't in a format most people would want to read. (I issued
all the rule creations, then did iptables-save; RedHat's iptables rc
script automatically does an iptables-restore < /etc/sysconfig/iptables.)
I think the list output quite satisfactorily displays the actual
state of the firewall. Had I just posted some script with a list
of commands in it, there's no guarantee that something else isn't
changing the state of my firewall.

> iptables is simply not broken. i'd like to hear some "other ways that
> hamper security" in your eyes!

The one that pisses me off most frequently is that it is literally
impossible to return an RST packet in any way other than letting
the packet fall through to the kernel's TCP/IP stack. If you don't
return an RST, nmap can see the port's firewalled. If you do return
an RST, nmap just thinks the port's closed. But if you return an
RST by letting it through to the OS, you leave yourself open to OS
fingerprinting (due to quirks in the Linux TCP/IP stack) and, even
scarier, vulnerabilities in the Linux TCP/IP stack (say, like this
one:
  https://rhn.redhat.com/network/errata/errata_details.pxt?eid=947
... though I'm not using syncookies, so it's not a perfect example).

There are others, but I didn't take notes. They are invariably
things where I go, "Oh, I must be able to do this; it's really easy
in IPF... uh, oh, but totally difficult/impossible with Netfilter.
Swell."

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpqygzwCXFXo.pgp
Description: PGP signature