In reply to Paul Jakma's flatulent wordings,
> On Tue, 27 Jun 2000, Smelly Pooh wrote:
>> > Yeh, I do recall a Paul Jakma challenging me when i said that Linux
> > wasn't the best packet filter around,
>> no. i asked you to explain what you said. (cause you had offered none in
> your initial posting).
chal-lenge
n.
1.
a. A call to engage in a contest, fight, or competition: a challenge to a duel.
b. An act or statement of defiance; a call to confrontation: a challenge to
the government's authority.
2. A demand for explanation or justification; a calling into question: a
challenge to a theory.
> > and suggesting a "Linux" alternative that wasn't really any different
> > from what I could do in xyzBSD in the first place.
> >
>> no. i suggested an alternative that would work on any nix.
You tried to flog it off as a Linux solution
"alternatively: run a linux firewall with ipchains + application proxies"
> (the word games are tedious, let's give that a rest)
Once you learn some basic English we can move to discussing firewalls.
> > No, ip_masq modules are not stateful firewalls. These are application
> > specific transparent proxies.
>> that's the problem with 'stateful'. To me that term covers a very broad
> range of firewall types.
No, that's the problem with you, to everybody else stateful firewalls mean the
one thing, feel free to do a google search on the words stateful firewall,
they are quite unanimous in their definition of what a stateful firewall is.
Now try a search on ip_masq stateful firewall, none of those will tell you
that ip_masq is a stateful firewall.
> > 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.
>> i'm not.. :) ip_masq_ modules are not standalone. Linux 2.2 as a whole
> /does/ have stateful fw'ing thru ipchains+ip_masq
No, ipchains is a stateless firewall, ip_masq is a transparent proxy, that
does not define a stateful firewall.
> i'm purely talking about the pros and cons of keeping 'state' of onward
> network connections in kernel, however it may be implemented. Eg, NAT
> modules such as ip_masq keep state, the low-level kernel stateful filters
> that you refer to[1], user packet filter, etc.
Other proxies keep state, it's quite implicit when dealing with proxies which
act at a higher level than stateless firewalls. But just because they are
stateful, it does not mean that they are also firewalls.
> > 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?
>> if we speak specifically of linux ipchains, then that is not the job of
> the ip_masq module.
> Rather there are ipchains rules which must
> specifically match that service and target it for MASQing.
This is a stateless firewall solution, now a stateful firewall will also be
able to maintain state on every existing connection regardless of whether
there is a proxy for it or not, which unfortunately is beyond ipchains because
it is not stateful, and beyond ip_masq_* which are not firewalls.
> > Linux 2.2+ does not have stateful firewalling, you're still wrong
>> as far as ftp, icq, quake, irc, etc.. are concerned. Yes it does. (whether
> i like it or not is irrelevant)
Transparent proxies, I suppose if I run Squid on Linux IPchains I've a
stateful firewall aswell?
> > .... Have you experience with stateful firewalls?
>> i have worked with firewalling under linux.
I'll take that as a no, you do not have experience with stateful firewalls
> > Have you any benchmarks to justify the performance claims you have
> > made?
>> no. Cause as i said, 'stateful' firewalls could be anything from a
> simple linux firewall to a dedicated proprietary package that does
> extensive state keeping.
Yet you do not have a single benchmark for any of these many stateful
firewalls that you claim to exist (some of which do not)
> however, i did offer a rationale to back up this claim.
You have the rationale to back up a claim that a stateful firewall takes up
more memory, but not that a stateless firewall will run on an old 486 whereas
a stateful one will not, that would require more than rationale, maybe
something akin to a benchmark
> > Have you any hard evidence that I can look at and say like...
> > yes, Paul is right there.
>> no. cause this is a mailling list, to discuss stuff, educate people,
> establish consensus on best practices/implementations.
I'd like to base my education on some smidgeon of reality if that's not too
much of a bother for you
> > 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.
> >
>> so what are your credentials?
By virtue of having seen and used stateful firewalls, provided benchmarks
behind all performance claims and evidence or verifiable facts behind others,
I think I'm well ahead of you Paul, who has no experience with stateful
firewalls, makes claims on performance without even mildly relevant
benchmarks and statements on the topic at hand with little or no evidence to
back them up
> i called you a /possible/ troll after you
> said i was a "conjecturer" and that you were "more likely to be more
> correct", yet you offered no credentials to back this up apart from some
> net flight list mail. (however we've also seen a link to a post from alexy
> kutznekov absolutely refuting the nfr claims).
Can this be another wild statement made by Paul Jakma with no basis in
reality? I think so, prove me wrong, show me the mail where I mention net
flight list mail you libellous shite talker
> > but I think you just pulled an arbitrary figure out of your hat.
> > Have you any evidence at all to support that claim?
> >
>> (i did prefix that with a big "_IF irc_")
big "_IF irc_" you say? No factual information to back that up? I'll file
that under conjecture so
> suprised me too, but that's what i remember alan cox posting to
> linux-kernel, 64KB iirc[2].
lets not introduce anymore unsubstantiated recollections here OK? I'd rather
not beat around the bush with every made up memory you may or may not have
> cause not only do you need the structures to
> describe the IP and TCP information, then you need structures to describe
> the socket which needs struct file and struct inode and more.. plus the
> send and receive buffers. (at least 16KB there per default).
no you don't need send and receive buffers to keep state information, please
stop confusing this with proxies (transparent, masquerading or application)
> but that's for connected sockets. as you're going to say, a 'stateful'
> firewall would probably not need most of that information.
it most definitely does not need the send and receive buffers
> > No it does not have to maintain the data in a connection,
>> i didn't say it did. i said it might. In the case of UDP it would need to
> at least interpret the data. Else all it has to go on is src ip/port, dst
> ip/port, which is easily spoofed.
It is, but for the 3rd time, read previous posting on UDP DNS, it is the
difference between allowing one spoofed packet back to your DNS lookup port,
and any UDP packet from port 53 of any machine to any UDP port on a machine
inside the firewall, therein lies one big security difference that stateful
UDP automatically eliminates.
> > You've just demonstrated to me a serious lack of understanding of
> > TCP/IP.
>> i'm always open to education.
>> > To keep state of a UDP packet it must understand the application data?
>> not /must/.
Direct quote from Paul Jakma
"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)"
> but UDP by definition does not have much state information in the headers.
Hence the use of a stateful firewall in handling UDP state, bing!
> If there is any it's in the application data. You can try and track it by
> src/dst, but no more.
That is all that needs to be tracked to prevent a whole lot of common
stateless firewall holes.
> but then what's the advantage of that over bog standard ipchains rules?
I've used the same rather important example on numerous occasions, a couple
more in one of my original postings, I know your memory isn't infallible, but
surely your ILUG mail backlog doesn't serve to corrupt itself whenever there
is contra-linux material there.
> > 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.
>> if the packet can get through then why would you have to modify the
> firewall?
Oh you know, cus some idiots like to think that a firewall must understand
application data before keeping UDP state (all the biggest stateful firewall
manufacturers oddly enough having proven that wrong).
> however, the firewall isn't exactly keeping much in the way of
> state, and if it is - it's dangerous. Eg if the firewall is deciding
> whether to allow a UDP packet in on the basis of whether it's a reply to a
> UDP packet that was sent out, then that is dangerous. Wide open to
> spoofing.
> TCP on the other hand has state information, and a sequence number that
> should not be trivial to guess.
A stateful firewall allowing stateful outgoing UDP, would obviously only
create a state for an outgoing UDP session. If that is a UDP packet from
111.111.111.111:1 to 222.222.222.222:2 then only UDP packets from
222.222.222.222:2 to 111.111.111.111:1 will be accepted. There are 3 ways
that those IP/Port pairs can be retrieved. If the user can run netstat (or
equivalent) on the source host, if they can run netstat (or equivalent) on the
destination host, or if they are sniffing the network. Granted stateful
firewalls do not protect against situations 1 & 2 (gosh I'd love a firewall
that controlled executable ACLs myself), but if situation 3 existed, then an
attacker has your TCP sequence anyway, do you understand that?
> > 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.
> >
>> doesn't require. but it's pretty pointless if it doesn't.
I quote Paul Jakma
"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)"
I presume by "must have" you mean something akin to "require"
I've already spent painstaking postings explaining to you why it's not
pointless (and quite widely implemented by many modern firewalls) to implement
stateful UDP without application level data.
> > Linux with an ip_masq module does not make a stateful firewall, I cannot
> > stress this enough, it is a transparent proxy module.
>> argghh... no.... look at ip_masq_ftp.
argghh... yes.... read any definition of stateful firewall you sap, I've
looked at ip_masq_ftp, I've looked at the source, in no place is it even
implied that it is a firewall of any sort. They like to call it a
masquerading module. You know how Linux people differentiate between
masquerade modules and transparent proxy modules? Only by whether an address
is rewritten or not. Look I'm not at all unsympathetic to your points here,
and there are indeed similarities between stateless firewalls with transparent
proxies and stateful firewalls, but stateful firewalls can keep state for
anything specifiable in your firewall rules regardless of application layer
data (which is entirely optional), they dynamically create reciprocal firewall
rules to those which keep state in order to allow the corresponding packets
going in the opposite direction, ipchains & ip_masq_* do not do this, they do
not purport to do this, and no literature on ip_masq_* (that I have seen,
prove me wrong) claims that it does stateful firewalling. Also the new
iptables implementation uses nothing like ip_masq_* to perform stateful
firewalling, nor does any other stateful firewall that I've seen, stateful
firewalling is integrated in the firewall code, the only time you'll use an
external module is if you need to check the application data itself.
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!
