[ILUG] Firewall Overhead.

[Paul Jakma]

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).

> 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.

(the word games are tedious, let's give that a rest)

> 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. 

> 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

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.

> 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.

eg:

[root at firewall bin]# ipchains -L forward
Chain forward (policy DENY):
target     prot opt     source                destination           ports
MASQ       all  ------  mymachine.itg.ie         !192.168.0.0/24    n/a
REJECT       all  ------  anywhere             anywhere              n/a

so in the above if mymachine.itg.ie tries to connect to
ftp-server.com:ftp, the firewall will match that to the first rule and
masquerade it (using any ip_masq_ modules that are applicable, eg
ip_masq_ftp).

any connection not from mymachine is rejected. you could make those rules
more fine grained if you wanted.

> 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)

> .... Have you experience with stateful firewalls?

i have worked with firewalling under linux.
  
> 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.

however, i did offer a rationale to back up this claim.

> 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. 

however it's not profesional or meant to be. So it's mainly going to boil
down to opinions and rational informed discussion, with benchmarks only
presented where they are easily available. (eg have equipment/time or
found a webpage).

if you were my boss and you gave me the money to buy the equipment needed
i would benchmark it 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? 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).

note the /possible/, if you weren't trolling then at the very least you
need to calm down a little and try discuss things in a more considered and
less aggressive manner.

> 64K to keep state per TCP connection?  Forgive me for being sceptical,

i was pretty amazed too.

> 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_")

suprised me too, but that's what i remember alan cox posting to
linux-kernel, 64KB iirc[2]. 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).

but that's for connected sockets. as you're going to say, a 'stateful'
firewall would probably not need most of that information. 

> 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.

or else how can it maintain state?

> 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.
> 

didn't claim. i said _IF irc_ i saw a post from alan cox saying this.

1. my memory is fallible
2. however my intent is not malicious, and it was a large figure.

> 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/. but UDP by definition does not have much state information in
the headers. If there is any it's in the application data. You can try and
track it by src/dst, but no more.

but then what's the advantage of that over bog standard ipchains rules?

> 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? 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. 

> 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.

> 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. 

> 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.

ah well...

--paulj


[1]. can you give me a URL to a specific stateful filter, one that you
would recc'd? like to learn more about it, and i'd like to see exactly
what you mean by a stateful firewall, ie to what degree.

[2]. ii don't rc then it was still a considerable figure, many KB
anyway. i'll try find the original post.