| Martin F Krafft on Thu, 16 May 2002 10:23:46 -0400 |
|
also sprach gabriel rosenkoetter <gr@eclipsed.net> [2002.05.16.0513 +0200]: > ... and I'd be done. (See, state actually *works* in IPF.) it actually *works* in iptables too... > Since I'm already jumping through hoops just to tell IP Tables to > maintain state, I'm hoping there's a hoop I haven't figured out yet. there are no hoops to jump through, it's actually *easier* than IPF. > (A rant: I should NOT have to define a separate rule to "accept > connections with a state we know"; in fact, that's a bad idea, > because it leaves one open to spoofing. Rather, it is appropriate > to define with a given rule whether or not state should be maintained. > At the least, it saves a lot of effort. And I'm pretty sure it > protects you marginally from spoofed IP and OS fingerprinting > attacks, though I'd have to go reread my TCP Illustrated to > state that with assurance.) 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. in any case, i have to refute your rant. please explain to me how this would allow you to spoof (no, don't go to the books if you don't have time, just tell me why you wrote this). stateful firewalling lives on the transport layer and above, ip spoofing exists between the data link and network layers, and it's thus *not* at all a responsibiltiy of the a stateful firewall that extensd the TCP/IP stack. were it to employ a stateful inspection kernel (kinda like a separate, specifically designed TCP/IP stack just for filtering), then it would have this job too, but as it is, anti-spoofing is a job to be done by the OS, not the stateful firewall. this applies to IPF as well. and linux surely does not allow any form of spoofing, provided you did not turn off the default. 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)! 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. > Output of iptables -L -v on the host with trouble: usually it's better to give the lines that create your rulebase rather than this output (which sucks). > Is IP Tables simply more broken than I thought (and yes, it's quite > broken in other ways that hamper security already), and it just > can't do this at all? I wouldn't be shocked, though it's one more > reason not to bother with Linux for firewalls. iptables is simply not broken. i'd like to hear some "other ways that hamper security" in your eyes! -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck nobody expects the spanish inquisition. -- monty python Attachment:
pgploGf0DGi5T.pgp
|
|