| gabriel rosenkoetter on Thu, 16 May 2002 11:13:25 -0400 |
|
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
|
|