Date: Thu, 16 Jan 2003 15:01:37 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Josh Brooks <user@mail.econolodgetulsa.com> Cc: Sean Chittenden <sean@chittenden.org>, freebsd-hackers@freebsd.org, nate@yogotech.com Subject: Re: FreeBSD firewall for high profile hosts - waste of time ? Message-ID: <3E2739D1.5402B7A6@mindspring.com> References: <20030116124254.J9642-100000@mail.econolodgetulsa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Josh Brooks wrote: > So, you say that a poorly configured netscreen is no better than a poorly > configured freebsd+ipfw ... but what about the best possibly configured > netscreen vs. the best possibly configured freebsd+ipfw ? The answer to that particular question depends on what you mean by "configured". Netscreen hs integral load shedding in its stack. FreeBSD is actually adding pointers and other complexity to its stack, to attribute packets with metadata for mandatory access controls, and for some of the IPSEC and other stuff that Sam Leffler has been doing. If you have IPSEC compiled into your kernel at all, each coneection setup for IPv4, and the per connection overhead for IPv4, is very, very high, because the IPSEC code allocates a context, even if IPSEC is never invoked, rather than using a default context. FreeBSD timers used in the TCP stack to not scale well (this is relative to your point of view, e.g. they don't scale well to 1,000,000 connections, but can be tuned to be "OK" for 10,000 connections). The hash lookups degraqde to nearly linear time, very quickly (e.g. ~5000 connections). FreeBSD does not RED-queue requests. The UDP fragment reassembly algorithm is poor, and can be attacked fairly easily, because it does not perform discard on atomic sequences with persistent missing fragments. The use of NETISR makes the stack subject to interrupt-transition receiver livelock. The fact that application live in user space, and there are not socket queue depth probes to delay interrupt reenabling makes the stack subject to user-space-transition receiver livelock. Socket creation time is O(N^2). Per process open file table expansion is O(loge(2^N)). Socket reuse is linear search, because there is no free-listing, and the hash allocation does not do a preferntial insertion sort based on specific IP binding vs. INADDR_ANY for outbound connections. This simultaneously limits you to 65K of outbound connections, even after the best tuning, unless you jump through some pretty bizarre hoops. Etc. All of these things are things that commercial network products have addressed in their code, but which would require modification of the code in FreeBSD in order to address -- not merely tuning, and not merely "the right ipfw rules". Do you need a commercial product? I don't know. I don't know, because I don't know which, if any, of these issues in the FreeBSD stack are being exploited by your attackers, so I can't tell you if a commercial product will "save" you (and even if it does today, it may open you up to some attacks that *aren't* effective against FreeBSD's network stack). If you can, stop them at the router, on your ISP's side of the connection, before they even get to you. If you can't, then stop them at your router, and live with the fact that they can saturate your pipe to that point, but keep them off the local network, to prevent amplification. If you can't do that, then stop them at a firewall machine. You complained about packet processing load being "too high"; if that's your major concern, then you can probably get by without a commercial product, or just using a load balancer, instead of something more sophisticated, and just shedding load. Legitimate traffic will retry, and only see degradation equivalent to the ratio between the legitimate traffic and the attack, or the percentage of pipe size, if the pipe gets saturated. If you think a Netscreen will save you, demo one and see if it does what you tink it will. Don't overthink the problem: try it and see if it works, and then move on. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E2739D1.5402B7A6>