In reply to Paul Jakma's flatulent wordings,
> > So I wouldn't use Linux to do those things where it lacks what other
> > Unices can do (such as with packet filter firewalls) and I wouldn't
> > use Linux to those things that it gets stomped for performance (such
> > as user space packet access)
> >
>> of course not. no one would ask you to. if linux doesn't meet your
> requirements for a certain firewalling application, but xyzBSD does, then
> you use xyzBSD. Has anyone here said anything to the contrary?
Yeh, I do recall a Paul Jakma challenging me when i said that Linux wasn't the
best packet filter around, and suggesting a "Linux" alternative that wasn't
really any different from what I could do in xyzBSD in the first place.
> > Alright, tell me how I get stateful firewalling working on Linux 2.2 then,
> > please do, or is this some bullshit API that does nothing?
> >
>> it's how all the ip_masq_ modules are implemented. see
> linux-2.2/Documentation/networking/ip_masq/ for some very very basic info,
> and read the source for the existing ip_masq_ modules for real info.
No, ip_masq modules are not stateful firewalls. These are application
specific transparent proxies. They are application proxies loaded as modules
that don't require any redirecting from the point of view of the application.
It frightens me that you can confuse that with a packet filter. Tell me Paul,
how would I block broadcast pings to my internal network using your stateful
ip_masq firewalls eh? How do I tell my ip_masq modules to drop faked
addresses?
> > I was "lambasting" Linux packet filtering for not being the optimal, and one
> > of the examples I provided was its lack of stateful firewalling (the other
> > being userspace filtering). Have I "lambasted" any part of Linux without
> > justifying myself with facts?
> >
>> linux 2.2+ does have stateful firewalling. (i was wrong).
>> but my preference is still for proxies. (but that's me).
Linux 2.2+ does not have stateful firewalling, you're still wrong (actually
there's a dodgy userland stateful packet filter that would work on 2.2, but it
is heavily stressed by the authors that it is only for use on low bandwidth
machines, and to pursue that approach, the Linux 1.4 series may have had
stateful firewalls when ipfilter worked on them)
> > up, quite unlike you conjecturers, who have absolutely no evidence, no
> > benchmarks, dare I even say no experience with stateful firewalls?),
> > one might claim I'm a bit of a sheep, but one that is much more likely
> > to be correct than you.
> >
>> you're either trolling or you've been out in the sun too long and you need
> to cool down.
do you deny any of this? Have you experience with stateful firewalls? Have
you any benchmarks to justify the performance claims you have made? Have you
any hard evidence that I can look at and say like... yes, Paul is right there.
It's nice to see what I presume to be a grown man resort to calling people
trolls when his credentials are brought into question.
> > and for the 3rd time, that 'state', which the stateful firewall 'maintains'
> > does not require as much memory as buffers already present for data used in a
> > normal tcp/udp connection and the already existing state maintained by your
> > TCP/IP stack, it is akin to the overhead of IP headers of internet data,
> > something which quite small in proportion to the actual data transferred.
> >
>> i sort of agree... however (for the xth time) you're still forgetting
> something ---TIME--- the state has to be remembered! and TCP state is not
> inconsiderable. (_IF irc_ it's about 64k per TCP connection)
64K to keep state per TCP connection? Forgive me for being sceptical, but I
think you just pulled an arbitrary figure out of your hat. Have you any
evidence at all to support that claim?
> > As I've said, this information is present in the kernel anyway, how
> > does the Linux IP stack know when a TCP connection exists and an
> > incoming packet is valid? Or if a UDP session is valid? Good lord it
> > must need infinite memory to do that?
> >
>> ok...
> 2. the static firewall on the other hand must maintain at least some of
> these IP structures for a certain amount of time. In addition it also
> needs to maintain per session data, eg it needs to keep track of the TCP
> state of a connection (static fw doesn't do that), it might even have to
> maintain the data depending on how far it takes the 'keeping' state thing.
No it does not have to maintain the data in a connection, and the IP
structures required are those that you'd expect any IP stack to keep,
fragmentation, SYN/ACK handshake, FIN/RST disconnect and so on, anybody can
tell you that this doesn't take a lot of memory, and most definitely not the
64K that you claim.
> And if it wants to maintain state of UDP app's then it must have an
> understanding of the application data inside the packet (..yuk), and it
> must maintain state from that data for a certain period of time. and it
> still can't stop UDP spoofs completely cause of the very nature of UDP.
You've just demonstrated to me a serious lack of understanding of TCP/IP. To
keep state of a UDP packet it must understand the application data? I know
this to be complete bullshit, not only because I've actually seen stateful
firewalls (you obviously have not) and have a modicum of an idea of what UDP
is (you obviously have not), I've by some coincidence written a UDP
application that ran fine on a stateful firewall, without having to modify any
firewall code to understand the application data. But entertain me please,
explain to me how the stateful firewall would require application data to
maintain state for UDP, I'm well prepared to be completely wrong on this
point.
> > claim that a stateless firewall would run happily on an old 486, and
> > implythat a stateful one would not, have you any benchmarks at all to
> > prove this? Or did you just make that up?
> >
>> no i don't have a benchmark for 'stateful' firewalls - it covers such a
> huge range, how could you? from linux with an ip_masq module to
> large proprietary firewall packages.
Linux with an ip_masq module does not make a stateful firewall, I cannot
stress this enough, it is a transparent proxy module. And if it'll help get
an answer out of you, can you show me a benchmark for "any" stateful
firewall when compared with a stateless equivalent?
> > Especially when you try to use that to argue that Linux packet filters
> > in user space
> >
>> ideally packet filtering, nfs, etc.. should be.
Shame you use kernel modules as examples of user space programs eh?
> > No, same as the way when sendmail goes down people can't access your
> > e-mail (as stated above), but when a packet filter goes down, the
> > effect is that people will have access to all the sevices that the
> > packet filter was there blocking in the first place, you know what I
> > mean, don't give me your bullshit about FUD.
> >
>> eh? no.. cause if it was in userspace, then it would be forwarding in
> userspace and the kernel would be configured not to forward. application
> goes down, forwarding goes down.
I've covered this in another post, but to summarise, you're now doing all
routing using a userland app, even kernel level firewalls undergo a severe
performance penalty when they try this.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
