In reply to Paul Jakma's flatulent wordings,
> On Tue, 27 Jun 2000, Smelly Pooh wrote:
>> > Typical advocate attitude, there is no OS for every occasion,
>> you're agreeing with me??
No, typical advocate attitude is Linux is the OS for every occasion, I'm
saying there isn't such a thing as an OS for every occasion.
> > I like Linux, I recommend it to people who want to try out Unix, I run it
> > at home, I like to read about the new things they're doing with it and the
> > acceptance it's gaining. Hell I'm a minor advocate myself. But when I do
> > see a department in which Linux is obviously lacking,
>> it lacks loads of loads things that other Unices have... so what? And
> there are areas where linux gets stomped for performance. So what?
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)
> > I'm not going to go on about how it's a memory hog, too complex, and
> > doesn't belong in the kernel, especially when the next version of the
> > Linux kernel is going to have that exact feature in the kernel,
>> it already was in the kernel as a programming interface -> ip_masq_...
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?
> > and the man who wrote ipchains and iptables things it's a great thing
>> i'm sure he does. and i never said stateful firewalling wasn't good
> either. i just said that lambasting linux for not having full blown
> stateful firewalling like your $CHOSEN_OS is unjustified.
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?
> > (now who's going to know more about firewalls... Paul and Kevin on the
> > local LUG, or the people who actually write and use these firewalls?)
> >
> rusty russel et al obviously. but if you want to use this point then you
> should shut up about networking/firewalls too.
None of what I say conflict with anything that they say (and if it did, I
would expect to have some pretty decent evidence to back myself 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.
> > > > Stateful information a memory hog? Excuse me, but the kernel
> > > > buffers used to hold the tcp/udp data from connections are only
> > > > orders of magnitude bigger.
> > >
> > > my point exactly, thanks for detailing it for me.
> >
> > You made that point where? I'm referring to kernel buffers which are
> > required for data, not a stateful firewall.
> >
>> think about 'state', now put that together with 'maintain' which a
> stateful firewall does (as you've been so keen to point out).... and which
> a 'static' firewall does not...
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.
> > > stateful firewall must maintain connections. it must maintain socket
> > > state info (considerable in the case of TCP), might even have to
> > > maintain complete TCP fragments depending on how 'stateful' it is.
> >
> > Same information that is kept on an IP stack, I'm no kernel hacker, but I
> > wouldn't be at all surprised if most stateful firewalls use this information
> > that is already present.
> >
>> there is a fundamental difference here that you're not grasping:
>> 1. the static firewall gets packet, processes packet, punts out/discards
> packet, forgets packet ever existed.. (ignoring fragment assembly, which
> stateful would have to do too, but the static one doesn't /have to/ do)
>> 2. the stateful does all the above, but as you have pointed out, it must
> remember them. Eg you gave the example of UDP applications, eg DNS, where
> you say stateful firewalling has the benefit of stronger protection
> against session spoofing. How do you think it does this? It has to
> remember a certain amount of detail of past UDP traffic, and it still
> won't be invulnerable unless it has an infinite memory and a good
> knowledge of the actual application... (in kernel)
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?
> > Benchmarks please
> >
>> can't provide one. however it follows from logical reasoning if you accept
> that stateful requires more memory.
>> - the more state it remembers, the more memory it needs.
> - as memory needs increase, so does load on the cpu<->memory bus.
> - as load on the hot bus increases, so you need a faster bus.
> - faster host buses typically come with come faster CPU's.
The fact that stateful firewalls require more memory is not in dispute here,
much the same way running a graphics card at 800x600 requires more memory than
one at 640x480. I request benchmarks because you 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?
> /anecdotal/ evidence: at compaq they use AS's with Alta Vista firewall
> (stateful) for allowing very limited and controlled access by certain
> customers to certain compaq applications. These machines had at least
> 256MB of RAM.
Oh? And I'm running a stateless firewall on a home machine with 512 MB,
equally valid evidence to the contrary.
> > Those are kernel modules, you know, "kernel" modules that you load
> > into the "kernel", that run in "kernel" space?
>> yep. it's not ideal.
Especially when you try to use that to argue that Linux packet filters in user
space
> > The difference there is that when sendmail goes down, all that happens
> > is mail doesn't get through, when a user space firewall goes down,
> > everything gets through.
> >
>> bollocks...
>> if i'm running squid on a firewall, and squid goes down - does that mean
> everyone can now suddenly access web sites directly? no. stop spreading
> FUD.
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.
> > Um... unless we're talking 16-bit x86 hardware,
>> x86 capable of running DOS/Win3.1 and Linux. (what does 16bit have to do
> with it?)
Well, Win3.1 over DOS being predominantly 16-bit. Granted DOS alone in
protected mode can be faster on the CPU, but not with Win3.1. And DOS
without Win3.1 only runs faster because there's no overhead wrt task switching
and so on, if you consider any other part of the OS, the FS, hardware access
and the like, you're quite likely to see a large performance drop with DOS.
> > I don't think DOS/Win3.1 was ever faster than Linux.
>> DOS is significantly faster than linux. You're a CS grad aren't you,
> figure it out..
We're talking DOS/Win3.1, which I presume to mean DOS with Win3.1, and as
mentioned previously, only on the CPU and nowhere else.
> > Perhaps in the kernel, along with stateful packet filtering, which evidently
> > conflicts with the Linux view
> >
>> if you keep throwing stuff in the kernel you end up with SystemV.. eg why
> is Solaris so pitifully slow on low-end hardware (x86/SPARC compared to
> linux)? Why is IRIX6.5 so much slower than IRIX6.2 which is far far slower
> than the BSD based IRIX5.4 on low-end hardware?
Well genius, stateful firewalling doesn't slow down the kernel, why? Because
it's optional, if you don't use it you don't have to enable it. If you do use
it, it's going to be miles faster than having it as a userspace filter.
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!
