Re: FreeBSD firewall for high profile hosts - waste of time ?
On Sun, 19 Jan 2003, Darren Pilgrim wrote:
[snip-a-bit]
DP By the way, is (moderately complex) aggregated rule faster than mix of simple
DP rules? (for now, we drop accounting issues)
DP
DP I'm not sure if the {a.b.c.0/24 or e.f.g.0/20} part is valid, but in theory
DP this rule should require fewer ops on average than 8 seperate rules. What I
DP meant when I said aggregate is that if you have a contiguous block of IPs,
DP say 1.2.3.1 through 1.2.3.63, most need ports 22, 25, 80, and 443 open, then
DP create one rule:
DP
DP pass tcp from any to 1.2.3.0/26 22,25,80,443
Yeah, I suppose we both got the point ;-)
The only side note I have for now is: it would be _extremely_ useful to
describe firewall tuning either in firewall.7 or security.7 or even excplicit
manpage as well as bring it under attention into the Handbook. However, not
being native speaker and/or kernel deep-knowledge-man, /me just silently
crouches into his corner ;-)
Anyway, thank you all the Crew and congrats for 5.0 releasing!
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Dmitry Morozovsky wrote:
On Thu, 16 Jan 2003, Darren Pilgrim wrote:
DP There is sorting that you can do, like putting the highest-traffic rules
DP near the top. ipfw terminates the search on the first matching rule except
DP for count and skipto. Also, the fewer items that have to be checked the
DP faster the rule is. Perhaps there is some aggregation that can be done with
DP the rules themselves?
By the way, is (moderately complex) aggregated rule faster than mix of simple
rules? (for now, we drop accounting issues)
So, will
permit tcp from {a.b.c.0/24 or e.f.g.0/20} to any 22,25,80,443 setup
perform measurably better than set of 8 corresponding rules?
I'm not sure if the {a.b.c.0/24 or e.f.g.0/20} part is valid, but in theory
this rule should require fewer ops on average than 8 seperate rules. What I
meant when I said aggregate is that if you have a contiguous block of IPs,
say 1.2.3.1 through 1.2.3.63, most need ports 22, 25, 80, and 443 open, then
create one rule:
pass tcp from any to 1.2.3.0/26 22,25,80,443
Then turn on the tcp.blackhole sysctl on the machines and you have the same
effect with just one rule instead of 60 or configure firewalls with just two
rules:
allow tcp from any to me porta,portb,portc
allow tcp from me to any
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Terry Lambert wrote: Yury Tarasievich wrote: [...info and pointers greatly appreciated...] Now: Most of the reasons this stuff is not in FreeBSD is NIH (not being the pet research project of a committer), license, the need to productize the code from research, etc.. For the complaints about scalability... Linux has a project that they are very proud of, in order to obtain 10,000 simultaneous TCP connections. With respect, I personally achieved 1,600,000 simultaneous TCP connections on a modified FreeBSD box with 4G of RAM. During this process, I found a credentials reference count overflow bug (since fixed in FreeBSD), which occurred on close, after opening more than 32,763 connections in one process. No one else reported this bug, so I have to assume that no one else ever ran FreeBSD up to that number of connections, before. So... the primary reason is that no one is using FreeBSD under the loads necessary to cause the problems to exhibit themselves. You have to have a need in order to be interested in a way of satifying a need. 8-). I wasn't explicit with my question, although with your explanations my question(s) seems rather rhetoric -- but I'd like to know your opinion: - what is the *real* *reason* for stuff that good not going into FreeBSD? and - doesn't all that mean that the supposed plentiness of choice turn out to be rather its opposite? has one not belonging to the inner circle *any* chance of influencing things course? You were also saying in same post that: The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). And throttling the FlagFeature??? That sort of thing has to be there, for FreeBSD to be interesting as a reasearch OS, so that additional work occurs on the platform; that's pretty much a given. You wouldn't have someone as well-known as Sam Leffler donating code, if that code was unlikely to get in, since it would be a waste of his time and effort (the same reason some people have left the project, actually). That I didn't understand. People left because they couldn't get their code in or because they couldn't stop code of well-known persons getting in? So even if you don't like feature creep or bloat, when it impacts top end performance, top end performance really doesn't matter to most people who are doing the coding (i.e. how many OC3's do you have to your computer? How many would you need to have to saturate even a single gigabit ethernet?). I wasn't precise in wording. Possibly, one cannot even see the real impact of worsening of network processing. I just do not see the good reason for *actually* making network processing capability -- the most praised feature of free *nixes -- worse, not better. And I think it's bad press, too. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
On Thu, 16 Jan 2003, Darren Pilgrim wrote:
DP There is sorting that you can do, like putting the highest-traffic rules
DP near the top. ipfw terminates the search on the first matching rule except
DP for count and skipto. Also, the fewer items that have to be checked the
DP faster the rule is. Perhaps there is some aggregation that can be done with
DP the rules themselves?
By the way, is (moderately complex) aggregated rule faster than mix of simple
rules? (for now, we drop accounting issues)
So, will
permit tcp from {a.b.c.0/24 or e.f.g.0/20} to any 22,25,80,443 setup
perform measurably better than set of 8 corresponding rules?
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
RE: FreeBSD firewall for high profile hosts - waste of time ?
What is the size of your pipe? If the pipe is big, then so should your BSD box be. The only time i've used something as small as 500ghz Celery it was for a puny 10mbit. What kind of network adapters are you using? I cant recommend using anything other than Intel. The drivers suck for the other cards. Have you applied POLLING (man polling)? If the computer in itself chokes, this will in almost every case prevent that. ( Requires cards such as Intel ) Do you filter outgoing packets so that your pipe wont be filled with ICMP's or RST's on exit? Dummynet is good for that. If the incoming attack isnt large enough to completely block your pipe one way, it often blocks on exit as the responses go back. Do you limit the amount of ICMP responses on each of the servers? May i suggest using creative routing for packets on exit going to unassigned or unroutable nets? How about getting a (perhaps smaller/cheaper) secondary pipe that also announce your network often the attacks go in on one pipe but let the other pipe go free. - This applies mainly when you are the one announcing the networks through BGP or in same provider cases - OSPF. But yes, in my opinion, a FreeBSD firewall is worth using your time with. --- Med vennlig hilsen / Best regards Sten Daniel Sørsdal --- -Original Message- From: Josh Brooks [mailto:[EMAIL PROTECTED]] Sent: 16. januar 2003 23:42 To: Matthew Dillon Cc: Nate Williams; [EMAIL PROTECTED] Subject: Re: FreeBSD firewall for high profile hosts - waste of time ? If attacks are a predominant problem for you, I recommend sticking a machine in between your internet connection and everything else whos Actually this is what I already do - my ISP does all the routing, and it feeds in one interface of my freebsd machine, and everything else is on the other side of the freebsd machine. My freebsd machine does _nothing_ but filter packets and run ssh. ONLY purpose is to deal with attacks. With an entire cpu dedicated to dealing with attacks you aren't likely to run out of CPU suds (at least not before your attackers fills your internet pipe). This allows you to use more reasonable rulesets on your other machines. You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Terry Lambert wrote: FreeBSD is actually adding pointers and other complexity to its stack [...etc.] So you are referring to common features of stacks of both 4.* and 5.*, right? As far as I understand the matter, this all have to be (and I guess actually is) provable. Now, you were saying that 5.* is even worse, I quote: FreeBSD 5.x network performance is really poor, relative to 4.x; I do not recommend using FreeBSD 5.x in a production environment. Then I wonder *what* were the reasons for not working on matters pointed out??? You were also saying in same post that: The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). And throttling the FlagFeature??? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Yury Tarasievich wrote: Terry Lambert wrote: FreeBSD is actually adding pointers and other complexity to its stack [...etc.] So you are referring to common features of stacks of both 4.* and 5.*, right? Mostly 5.x for the mbuf metadata modifications; they haven't been back-ported to the 4.x branch, AFAIK. The IPv4 IPSEC problems for no-IPSEC-using connections are 4.x and 5.x both, and so are the timer and the livelock issues. As far as I understand the matter, this all have to be (and I guess actually is) provable. Yes. Duke University and Rice University have both done papers in this area (see Scala server or lazy receiver processing in a search engine; I recommend http://citeseer.nj.nec.com/cs for technical papers). Now, you were saying that 5.* is even worse, I quote: FreeBSD 5.x network performance is really poor, relative to 4.x; I do not recommend using FreeBSD 5.x in a production environment. Then I wonder *what* were the reasons for not working on matters pointed out??? The SMP-ification and the use of the interrupt threads model, etc., adds latency to packet processing. Additional latency translates into additional pool retention time, latency in response after the processing finally happens, and reduced reuse rate. The number that was posted by someone who had done benchmarking as -65% for flat network performance, going from 4.x to 5.x. The reality is that this is probably a little exaggerated, if you take into account common real-world operations, instead of benchmarking. One actual good benchmark is connections per second; using a combination of soft interrupt coelescing, hard interrupt coelescing, and lazy receiver processing, you get the following: Connections per second: Well tuned stock FreeBSDWell tuned modified FreeBSD --- 7,200 32,126 This is on a FreeBSD *without* a SYN cache. Most of the reasons this stuff is not in FreeBSD is NIH (not being the pet research project of a committer), license, the need to productize the code from research, etc.. For the complaints about scalability... Linux has a project that they are very proud of, in order to obtain 10,000 simultaneous TCP connections. With respect, I personally achieved 1,600,000 simultaneous TCP connections on a modified FreeBSD box with 4G of RAM. During this process, I found a credentials reference count overflow bug (since fixed in FreeBSD), which occurred on close, after opening more than 32,763 connections in one process. No one else reported this bug, so I have to assume that no one else ever ran FreeBSD up to that number of connections, before. So... the primary reason is that no one is using FreeBSD under the loads necessary to cause the problems to exhibit themselves. You have to have a need in order to be interested in a way of satifying a need. 8-). You were also saying in same post that: The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). And throttling the FlagFeature??? That sort of thing has to be there, for FreeBSD to be interesting as a reasearch OS, so that additional work occurs on the platform; that's pretty much a given. You wouldn't have someone as well-known as Sam Leffler donating code, if that code was unlikely to get in, since it would be a waste of his time and effort (the same reason some people have left the project, actually). So even if you don't like feature creep or bloat, when it impacts top end performance, top end performance really doesn't matter to most people who are doing the coding (i.e. how many OC3's do you have to your computer? How many would you need to have to saturate even a single gigabit ethernet?). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
FreeBSD firewall for high profile hosts - waste of time ?
Hi, If I have a large network with high profile hosts (50+ shell servers, 50 or more different ircds running) am I wasting my time trying to hack and tweak a FreeBSD host-based firewall running ipfw ? I am getting hammered by a different (D)DoS attack every single day - it's always something new. I am thinking of buying a netscreen, but on the other hand I really like FreeBSD, I really like a host-based firewall, and I hate to admit defeat. So do any of those efnet servers use a FreeBSD firewall ? Are there people out there that know what they are doing to such a degree that they can successfully use a host-based FreeBSD system to firewall high profile network targets ? Or is it generally accepted that if you have that kind of targets on your network that you just have to get an appliance - that is, even if the guy that wrote ipfw and knows the fbsd kernel inside and out still wouldn't even try to make that work ? OR, would a very expert FreeBSD developer and network code guy scoff at wasting money on a netscreen or PIX, knowing that if you really knew what you were doing you could do it all with a fbsd host-based firewall with ipfw ? Any comments appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: If I have a large network with high profile hosts (50+ shell servers, 50 or more different ircds running) am I wasting my time trying to hack and tweak a FreeBSD host-based firewall running ipfw ? I am getting hammered by a different (D)DoS attack every single day - it's always something new. I am thinking of buying a netscreen, but on the other hand I really like FreeBSD, I really like a host-based firewall, and I hate to admit defeat. You cannot protect yourself against DDOS. In the limit, the attacker will fill up your communications pipes, so no matter what you do, in terms of load-shedding, you will still end up with the attack being effective. You've posted previously that you want to do some things, like characterizing packet options (e.g. MSS), and dropping certain packets with or without these options. This is merely a load-shedding strategy, and it is, in fact, one which will not be successful, if you make your choices in this regard public, since you will provide information to your attacker as to why his attack, previously effective, is not ineffective. Th bad news is that, even if you do not make this information public, an attacker can infer your rules and tighten up the attack, to make it look more like legitimate traffic, to avoid your rules changes (e.g. adding the MSS option to SYN packets used in attacks, etc.). In the worst case, the attacker will merely flood your pipes, if you are effective in stopping attack packets at your border firewall. The only really effective mechanisms for defending against DDOS attacks are: 1) Have a bigger pipe than the aggregate of all your attackers robots -- this has the negative effect of your attacker, whi;le being unable to take you off the air, they can still cost you money (e.g. the war dialer attack on 1-800 numbers of SPAM'mers and televangelists, who get charged for call completion). 2) DPOS - Distributed Provision Of Service. A DDOS attack can only work against a small number of targets. As the number of targets approaches the number of robots, the DDOS attack becomes ineffective. 3) Identify the attackers, and have them arrested. There are all sorts of laws which are being violated by a DDOS attack, but police agencies aren't very sophisticated, mostly because of their hiring standards, and therefore you have to do much of their work for them. 4) Host something politically or militarily sensitive on the same server farm. The Men In Black will make your attackers disappear (unlike police agencies, the intelligence agencies *are* effective). Or is it generally accepted that if you have that kind of targets on your network that you just have to get an appliance - that is, even if the guy that wrote ipfw and knows the fbsd kernel inside and out still wouldn't even try to make that work ? The only thing a firewall can do for you is shed load, even if it's God's Own Firewall(tm). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Thank you for that advice - it is very well taken. Obviously, my goal is to mitigate as much as possible - I have accepted that I cannot stop all DDoS - my question is, do serious people ever attempt to do the mitigation/load shedding with a host-based firewall (in this case fbsd+ipfw) ? Or would all serious people interested in mitigating attacks use an appliance, like a netscreen ? I will say this - 9/10 attacks that hurt me do not do anything interesting - in fact they are even low bandwidth (2-3 megabits/s) but they have a packet/second rate that just eats up all my firewall cpu and no traffic goes through - and as soon as the attack goes away the firewall is fine. So, I am looking at putting in more sophisticated traffic shaping (limiting packets/s from each IP I have) and skipto rules to make the ruleset more efficient ... but this is going to be a lot of work, and I want to know if it is all just a waste because no matter how good I get at a freebsd firewall, a netscreen 10 will always be better ? thanks. On Thu, 16 Jan 2003, Terry Lambert wrote: Josh Brooks wrote: If I have a large network with high profile hosts (50+ shell servers, 50 or more different ircds running) am I wasting my time trying to hack and tweak a FreeBSD host-based firewall running ipfw ? I am getting hammered by a different (D)DoS attack every single day - it's always something new. I am thinking of buying a netscreen, but on the other hand I really like FreeBSD, I really like a host-based firewall, and I hate to admit defeat. You cannot protect yourself against DDOS. In the limit, the attacker will fill up your communications pipes, so no matter what you do, in terms of load-shedding, you will still end up with the attack being effective. You've posted previously that you want to do some things, like characterizing packet options (e.g. MSS), and dropping certain packets with or without these options. This is merely a load-shedding strategy, and it is, in fact, one which will not be successful, if you make your choices in this regard public, since you will provide information to your attacker as to why his attack, previously effective, is not ineffective. Th bad news is that, even if you do not make this information public, an attacker can infer your rules and tighten up the attack, to make it look more like legitimate traffic, to avoid your rules changes (e.g. adding the MSS option to SYN packets used in attacks, etc.). In the worst case, the attacker will merely flood your pipes, if you are effective in stopping attack packets at your border firewall. The only really effective mechanisms for defending against DDOS attacks are: 1)Have a bigger pipe than the aggregate of all your attackers robots -- this has the negative effect of your attacker, whi;le being unable to take you off the air, they can still cost you money (e.g. the war dialer attack on 1-800 numbers of SPAM'mers and televangelists, who get charged for call completion). 2)DPOS - Distributed Provision Of Service. A DDOS attack can only work against a small number of targets. As the number of targets approaches the number of robots, the DDOS attack becomes ineffective. 3)Identify the attackers, and have them arrested. There are all sorts of laws which are being violated by a DDOS attack, but police agencies aren't very sophisticated, mostly because of their hiring standards, and therefore you have to do much of their work for them. 4)Host something politically or militarily sensitive on the same server farm. The Men In Black will make your attackers disappear (unlike police agencies, the intelligence agencies *are* effective). Or is it generally accepted that if you have that kind of targets on your network that you just have to get an appliance - that is, even if the guy that wrote ipfw and knows the fbsd kernel inside and out still wouldn't even try to make that work ? The only thing a firewall can do for you is shed load, even if it's God's Own Firewall(tm). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Obviously, my goal is to mitigate as much as possible - I have accepted that I cannot stop all DDoS - my question is, do serious people ever attempt to do the mitigation/load shedding with a host-based firewall (in this case fbsd+ipfw) ? Or would all serious people interested in mitigating attacks use an appliance, like a netscreen ? Why don't use a freebsd firewall in-front of the host? That way, the freebsd box is acting like an appliance, and thus it 'filters' out the DDOS loads and as such leaves the host CPU free to server the DDOS attacks that make it past your appliance. This is what I do, and because my pipe is fairly small and my site is mostly unknown, the 486/66 box that I use has *way* more than enough power to deal with the simple task of filtering packets, since it has nothing else it needs to do. I will say this - 9/10 attacks that hurt me do not do anything interesting - in fact they are even low bandwidth (2-3 megabits/s) but they have a packet/second rate that just eats up all my firewall cpu and no traffic goes through - and as soon as the attack goes away the firewall is fine. Is your firewall also doing the WWW hosting? If so, then the amount of CPU it needs is much higher than a dedicated firewall. If it's eating up all the CPU and you're using a dedicated firewall, methinks that your rules need tweaking to 'optimize' them. It's *very* easy to generate firewall rules that work fine, but are very unoptimal when put under load. So, I am looking at putting in more sophisticated traffic shaping (limiting packets/s from each IP I have) and skipto rules to make the ruleset more efficient ... but this is going to be a lot of work, and I want to know if it is all just a waste because no matter how good I get at a freebsd firewall, a netscreen 10 will always be better ? See above. A poorly configured netscreen will perform no better than a poorly equipped freebsd dedicated firewall. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Again, thank you very much for your advice and comments - they are very well taken. I will clarify and say that the fbsd system I am using / talking about is a _dedicated_ firewall. Only port 22 is open on it. The problem is, I have a few hundred ipfw rules (there are over 200 machines behind this firewall) and so when a DDoS attack comes, every packet has to traverse those hundreds of rules - and so even though the firewall is doing nothing other than filtering packets, the cpu gets all used up. I have definitely put rules at the very front of the ruleset to filter out bad packets, and obvious attacks, but there is a new one devised literally every day. -- 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 ? thanks. On Thu, 16 Jan 2003, Sean Chittenden wrote: If I have a large network with high profile hosts (50+ shell servers, 50 or more different ircds running) am I wasting my time trying to hack and tweak a FreeBSD host-based firewall running ipfw ? The suggestion later on to use a FreeBSD appliance is likely the best advice you've gotten. The only thing I'd suggest is to use ipfw in bridging mode that way your firewall is non-existant as far as the rest of the world is concerned. Don't do anything stateful and just filter out crap (where your definition of crap is left up to you). I've used PIX's before and have even gone so far as to work for Cisco for a while, so while I'm not allowed to say anything negative about the product (and won't ::wink::), I will suggest that you stick with FreeBSD as your firewall. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Again, thank you very much for your advice and comments - they are very well taken. I will clarify and say that the fbsd system I am using / talking about is a _dedicated_ firewall. Only port 22 is open on it. Ah, OK. That wasn't clear from your emails. The problem is, I have a few hundred ipfw rules (there are over 200 machines behind this firewall) and so when a DDoS attack comes, every packet has to traverse those hundreds of rules - and so even though the firewall is doing nothing other than filtering packets, the cpu gets all used up. If you've created your rules well, then you should only have to traverse a couple of dozen at rules at most for the majority of packets. I have definitely put rules at the very front of the ruleset to filter out bad packets, and obvious attacks, but there is a new one devised literally every day. Agreed, but establishing good rules and optimizing them helps to mitigate both current *and* future attacks. As an example of something that tends to help, adding rules that apply *ONLY* to the external (internet) interface helps out a ton. Otherwise, the packet has to traverse both rulesets (once as it passes the external interface, and again for the internal interface). This is but one *very* easily implemented rule that many do not realize. To be honest, I just recently implemented in my ruleset, having been made aware of it, despite the fact that my firewall is not CPU bound. A good idea is a good idea, and I strive to keep my firewall as optimized as I can, as long as I can maintain protection of my internal machines. On that matter, I've been following this and other threads, and are doing some 'research' into tightening up my firewall against the more common DOS/DDOS attacks. However, as Terry pointed out, for the most part there is little that can be done in a 'dedicated' attack if the attacker can fill up your pipe. Ultimately, all you can do is keep from responding to the attacker (thus causing needless/unecessary that is created at your end), or at least do things to slow the attacker down (in some case the attack relies on responses from your machines). The bottom line is that there's a good chance that *IF* your firewall is CPU bound under attack, your firewall ruleset could use some optimizing. In my experience, it's hard to wipe out a well configured firewall. Now, it is possible to saturate a network link, but generally it doesn't take out the firewall, but it certainly makes it difficult for 'valid' traffic to get through due to packet loss and other 'niceties' that typically occur in a saturated network. :( 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 ? IMHO, they would perform similarly, depending on the hardware used on both appliances. Now, if you're firewall is a 386sx/15, and the netscreen has a P4-3.0Ghz CPU in it, their would certainly be a difference in performance. :) :) :) As far as the suggestion to use the FreeBSD box in bridging mode, I can't speak to that. My attempts to do so were less than successful, so I stuck with the more 'common' router/firewall combination. FWIW, I now have two firewalls in my rather 'puny' network. One is used to connect my 'DMZ' LAN to my ISP via a wireless link, which uses a *very* simple ruleset to ensure that only traffic destined for my network is passed in, and that traffic with a source address from my network is passed out. There are also some simply 'spoofing' rules in place, but the ruleset is less than 2-dozen rules. (Again, it's optimized by interface, so that packets only need to visit the rules once). This keeps a bunch of Windows/broadcast crap that lives on my ISP's network from cluttering up my firewall logs, and also sanitizes the traffic both to/from my network so that my firewall doesn't have to mess with it. On my 'real' firewall, I have a copy of these rules in place as well, but that's because paranoia runs deep, but these rules are rarely hit. I suspect I could do without the 'outer' firewall, but since it's got nothing else to do besides pass packets from one interface to the other, I figured it wouldn't hurt to give it *something* else to do. :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
As far as the suggestion to use the FreeBSD box in bridging mode, I can't speak to that. My attempts to do so were less than successful, so I stuck with the more 'common' router/firewall combination. In case you are still interested in running an ipfw-based FreeBSD firewall in bridging mode: http://www.kozubik.com/published/freebsd_bridging_ipfw.txt - John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Nate, So you are saying that if I put in: ipfw add 1 deny tcp from any to 10.10.10.10 6667 That an incoming packet for 10.10.10.10 on port 6667 will go through the rule set _twice_ (once for each interface) ? I don't understand this - if it comes in on the external and hits that rule, it is immediately dropped - at what time does it then traverse the rules for the internal NIC ? Or are you saying that rules I have in place that _allow_ traffic should have their _allowance_ apply to the external, because then they pass through the firewall without ever checking the ruleset for the internal interface they have to pass through ? - Also, if you don't mind, could you post your paranoia rules: network is passed out. There are also some simply 'spoofing' rules in place, but the ruleset is less than 2-dozen rules. (Again, it's optimized by interface, so that packets only need to visit the rules once). Thanks! On Thu, 16 Jan 2003, Nate Williams wrote: Again, thank you very much for your advice and comments - they are very well taken. I will clarify and say that the fbsd system I am using / talking about is a _dedicated_ firewall. Only port 22 is open on it. Ah, OK. That wasn't clear from your emails. The problem is, I have a few hundred ipfw rules (there are over 200 machines behind this firewall) and so when a DDoS attack comes, every packet has to traverse those hundreds of rules - and so even though the firewall is doing nothing other than filtering packets, the cpu gets all used up. If you've created your rules well, then you should only have to traverse a couple of dozen at rules at most for the majority of packets. I have definitely put rules at the very front of the ruleset to filter out bad packets, and obvious attacks, but there is a new one devised literally every day. Agreed, but establishing good rules and optimizing them helps to mitigate both current *and* future attacks. As an example of something that tends to help, adding rules that apply *ONLY* to the external (internet) interface helps out a ton. Otherwise, the packet has to traverse both rulesets (once as it passes the external interface, and again for the internal interface). This is but one *very* easily implemented rule that many do not realize. To be honest, I just recently implemented in my ruleset, having been made aware of it, despite the fact that my firewall is not CPU bound. A good idea is a good idea, and I strive to keep my firewall as optimized as I can, as long as I can maintain protection of my internal machines. On that matter, I've been following this and other threads, and are doing some 'research' into tightening up my firewall against the more common DOS/DDOS attacks. However, as Terry pointed out, for the most part there is little that can be done in a 'dedicated' attack if the attacker can fill up your pipe. Ultimately, all you can do is keep from responding to the attacker (thus causing needless/unecessary that is created at your end), or at least do things to slow the attacker down (in some case the attack relies on responses from your machines). The bottom line is that there's a good chance that *IF* your firewall is CPU bound under attack, your firewall ruleset could use some optimizing. In my experience, it's hard to wipe out a well configured firewall. Now, it is possible to saturate a network link, but generally it doesn't take out the firewall, but it certainly makes it difficult for 'valid' traffic to get through due to packet loss and other 'niceties' that typically occur in a saturated network. :( 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 ? IMHO, they would perform similarly, depending on the hardware used on both appliances. Now, if you're firewall is a 386sx/15, and the netscreen has a P4-3.0Ghz CPU in it, their would certainly be a difference in performance. :) :) :) As far as the suggestion to use the FreeBSD box in bridging mode, I can't speak to that. My attempts to do so were less than successful, so I stuck with the more 'common' router/firewall combination. FWIW, I now have two firewalls in my rather 'puny' network. One is used to connect my 'DMZ' LAN to my ISP via a wireless link, which uses a *very* simple ruleset to ensure that only traffic destined for my network is passed in, and that traffic with a source address from my network is passed out. There are also some simply 'spoofing' rules in place, but the ruleset is less than 2-dozen rules. (Again, it's optimized by interface, so that packets only need to visit the rules once). This keeps a bunch of Windows/broadcast crap that lives on my ISP's network from cluttering up my firewall logs, and also sanitizes the traffic both to/from my network so that my
Re: FreeBSD firewall for high profile hosts - waste of time ?
So you are saying that if I put in:
ipfw add 1 deny tcp from any to 10.10.10.10 6667
That an incoming packet for 10.10.10.10 on port 6667 will go through the
rule set _twice_ (once for each interface) ?
No, that much is true. However, you want to optimize your firewall for
packets that *do* go through, so your 'typical' packets (which are
passed) go through two sets of rules before they are dropped.
You don't want to stick the 'block abnormal packets' rules at the top of
the list, IMO. You want those at the end, since abnormal packets are
*usually* the exception. Optimize for the standard case.
Or are you saying that rules I have in place that _allow_ traffic should
have their _allowance_ apply to the external, because then they pass
through the firewall without ever checking the ruleset for the internal
interface they have to pass through ?
Exactly.
Also, if you don't mind, could you post your paranoia rules:
Sure. This set of rules probably won't work, as I've massaged it and
added/removed some rules so that it makes more sense.
-cut here-
# Netif is my external interface's address. If this box has no external
# services on it, the rules related to it can be removed.
netif=fxp0
myeip=10.0.9.2
mynet=10.0.10.0/24
mybcast=10.0.10.255
# Only in rare cases do you want to change this rule
/sbin/ipfw add 10 pass all from any to any via lo0
/sbin/ipfw add 15 deny log all from any to 127.0.0.0/8
/sbin/ipfw add 20 deny log all from 127.0.0.0/8 to any
# Don't allow packets with source addresses from my boxes 'in'.
/sbin/ipfw add 100 deny log all from ${mynet} to any via ${netif} in
/sbin/ipfw add 110 deny log all from ${myeip} to any via ${netif} in
# RFC 1918 unroutable hosts shouldn't be generating incoming/outgoing packets.
/sbin/ipfw add 200 deny log all from 192.168.0.0/16 to any via ${netif}
/sbin/ipfw add 205 deny log all from any to 192.168.0.0/16 via ${netif}
/sbin/ipfw add 210 deny log all from 172.16.0.0/12 to any via ${netif}
/sbin/ipfw add 215 deny log all from any to 172.16.0.0/12 via ${netif}
/sbin/ipfw add 220 deny log all from 10.0.0.0/8 to any via ${netif}
/sbin/ipfw add 225 deny log all from any to 10.0.0.0/8 via ${netif}
# Multicast source stuff addresses. Don't send out multicast packets, and
# ignore incoming TCP multicast packets (which are bogus).
/sbin/ipfw add 230 deny log all from 224.0.0.0/8to any via ${netif}
/sbin/ipfw add 235 deny log tcp from any to 224.0.0.0/8 via ${netif}
# Other misc. netblocks that shouldn't see traffic
# 0.0.0.0/8 should never be seen on the net
# 169.254.0.0/16 is used by M$ if a box can't find a DHCP server
# 204.162.64.0/23 is an old Sun block for private cluster networks
# 192.0.2.0/24 is reserved for documentation examples
/sbin/ipfw add 240 deny log all from 0.0.0.0/8 to any via ${netif}
/sbin/ipfw add 245 deny log all from any to 0.0.0.0/8 via ${netif}
/sbin/ipfw add 250 deny log all from 169.254.0.0/16 to any via ${netif}
/sbin/ipfw add 260 deny log all from 204.152.64.0/23 to any via ${netif}
/sbin/ipfw add 270 deny log all from 192.0.2.0/24to any via ${netif}
###
# Ignore/block (don't log) broadcast packets.
/sbin/ipfw add 400 deny all from ${mynet} to ${mybcast} via ${netif} out
###
# Ensure that outgoing packets have a source address from my machine now.
/sbin/ipfw add 500 pass all from ${mynet} to any via ${netif} out
/sbin/ipfw add 510 pass all from ${myeip} to any via ${netif} out
###
# Packets should be sanitized from invalid addresses at this point.
/sbin/ipfw add 600 pass all from any to ${mynet} via ${netif} in
/sbin/ipfw add 610 pass all from any to ${myeip} via ${netif} in
###
# Hmm, time to go kill something on my network that is using an invalid
# address. However, we 'actively' reject packets from internal boxes.
/sbin/ipfw add 700 log reject all from ${myeip} to any via ${netif} out
###
# Catch-all to see what I've missed.
/sbin/ipfw add 700 log deny all from any to any via ${netif} in
-cut here-
Note the use of 'deny' vs. reject. I don't want externally generated
packets to generate anything from my end. Stupid packet don't even
deserve a response to use up *MY* bandwidth.
The above are just the start, and are my 'first line of defense', since
it doesn't require any stateful inspection in the firewall.
There much more there, but these along with some local customizations
are what seemd to have worked for me and my previous employers. I use
logging to verify that I've caught things, and I monitor the box
regularly with tcpdump and such to ensure that I'm catching these.
This and email spam protection is something that I have to keep vigilant
on...
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Re: FreeBSD firewall for high profile hosts - waste of time ?
The 'firewall' manual page is a must-read. http://www.freebsd.org/cgi/man.cgi?query=firewallapropos=0sektion=0manpath=FreeBSD+4.7-stableformat=html I recommend that you first construct your firewall without worrying too much about optimizing it. Let it run a while, then use 'ipfw -v list' to see which rules are being triggered. Then, based on that information, optimize your ruleset. As long as you are careful to maintain the any sensitive rule orderings you should be able to construct an efficient ruleset (for example, anti-spoofing rules have to come before anything else). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
You don't want to stick the 'block abnormal packets' rules at the top of the list, IMO. You want those at the end, since abnormal packets are *usually* the exception. Optimize for the standard case. Wow - that is _very interesting_ that you say this. We were having a similar discussion on -network a few days back where the consensus was the exact opposite - and based on that I have actually stuck my 10-15 deny rules at the very front of my ruleset. Things like: deny tcp from any to any tcpflags syn tcpoptions !mss deny tcp from any to any tcpflags syn,rst deny tcp from any to any tcpflags fin,syn,rst,psh,ack and so on. The thinking is this (and you may find this interesting): During normal traffic, yes, there are now 5 extra rules that every single packet has to go through in addition to whatever other portion of the ruleset they would have to go through. But, in normal traffic - even if the bandwidth is getting up to 8-12 megabits/s, the packets/s rate is still fairly low, and thus the firewall is not taxed. However, in an attack, the bandwidth might go as high as double normal situations BUT the packets/s can climb as high as 100 times the rate you normally see. So now you have 100x normal packets/s going through 200 rules to get to the special case deny rules (like the ones above). Therefore, by putting the special case deny rules at the very beginning, yes you add a very small amount of extra work for normal traffic, but you imporve your situation _dramatically_ in the case of suddenly ramping up to 12,000 packets/s of SYN flood ... and by kicking these out immediately at the top of the ruleset you at least buy yourself some time. My problem is that every time I add a new rule to the top, a new kind of attack is used, and gets through just fine - so I have 12K packets/s coming through all 300 rules of mine no matter what I put in :) thanks again for your help and comments. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
:My problem is that every time I add a new rule to the top, a new kind of :attack is used, and gets through just fine - so I have 12K packets/s :coming through all 300 rules of mine no matter what I put in :) : :thanks again for your help and comments. If attacks are a predominant problem for you, I recommend sticking a machine in between your internet connection and everything else whos ONLY purpose is to deal with attacks. With an entire cpu dedicated to dealing with attacks you aren't likely to run out of CPU suds (at least not before your attackers fills your internet pipe). This allows you to use more reasonable rulesets on your other machines. Also, having a machine in the middle gives you a platform which you can dedicate not only to attack surpression, but also attack analysis. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: Thank you for that advice - it is very well taken. Obviously, my goal is to mitigate as much as possible - I have accepted that I cannot stop all DDoS - my question is, do serious people ever attempt to do the mitigation/load shedding with a host-based firewall (in this case fbsd+ipfw) ? Or would all serious people interested in mitigating attacks use an appliance, like a netscreen ? I will say this - 9/10 attacks that hurt me do not do anything interesting - in fact they are even low bandwidth (2-3 megabits/s) but they have a packet/second rate that just eats up all my firewall cpu and no traffic goes through - and as soon as the attack goes away the firewall is fine. So, I am looking at putting in more sophisticated traffic shaping (limiting packets/s from each IP I have) and skipto rules to make the ruleset more efficient ... but this is going to be a lot of work, and I want to know if it is all just a waste because no matter how good I get at a freebsd firewall, a netscreen 10 will always be better ? That depends on what you're asking of the machine. The routing information that will need to be held is the biggest one I can see, since the netscreens have defined limits. A FreeBSD box, in theory, doesn't have these limitations. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
You don't want to stick the 'block abnormal packets' rules at the top of the list, IMO. You want those at the end, since abnormal packets are *usually* the exception. Optimize for the standard case. Wow - that is _very interesting_ that you say this. We were having a similar discussion on -network a few days back where the consensus was the exact opposite - and based on that I have actually stuck my 10-15 deny rules at the very front of my ruleset. Things like: deny tcp from any to any tcpflags syn tcpoptions !mss deny tcp from any to any tcpflags syn,rst deny tcp from any to any tcpflags fin,syn,rst,psh,ack and so on. The thinking is this (and you may find this interesting): I watched that discussion, but I don't remember folks saying that the rules should go at the top. Apparently I didn't play close enough attention. :( During normal traffic, yes, there are now 5 extra rules that every single packet has to go through in addition to whatever other portion of the ruleset they would have to go through. But, in normal traffic - even if the bandwidth is getting up to 8-12 megabits/s, the packets/s rate is still fairly low, and thus the firewall is not taxed. However, in an attack, the bandwidth might go as high as double normal situations BUT the packets/s can climb as high as 100 times the rate you normally see. So now you have 100x normal packets/s going through 200 rules to get to the special case deny rules (like the ones above). Therefore, by putting the special case deny rules at the very beginning, yes you add a very small amount of extra work for normal traffic, but you imporve your situation _dramatically_ in the case of suddenly ramping up to 12,000 packets/s of SYN flood ... and by kicking these out immediately at the top of the ruleset you at least buy yourself some time. Yep, you dump things as quick as possible. My problem is that every time I add a new rule to the top, a new kind of attack is used, and gets through just fine - so I have 12K packets/s coming through all 300 rules of mine no matter what I put in :) It may be time to look at things differently. Rather than trying to generate a rule for every attack, it may be time to start thinking about only allowing 'valid' packets through. I know this is a bit harder than it may sound, but you may be suprised to find that it works. Kind of like how the people who look for counterfeits do. Rather than spend their time trying to find a counterfeit, they analyze what a 'good' bill is, so that when a counterfeit arrives, it's immediately obvious. Again, this may be beyond what ipfw can do today, but it's certainly something to think about. At this point, without more details to what your rules look like, I'm still of the opinion that it can be optimized to handle the higher loads. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
If attacks are a predominant problem for you, I recommend sticking a machine in between your internet connection and everything else whos Actually this is what I already do - my ISP does all the routing, and it feeds in one interface of my freebsd machine, and everything else is on the other side of the freebsd machine. My freebsd machine does _nothing_ but filter packets and run ssh. ONLY purpose is to deal with attacks. With an entire cpu dedicated to dealing with attacks you aren't likely to run out of CPU suds (at least not before your attackers fills your internet pipe). This allows you to use more reasonable rulesets on your other machines. You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: Thank you for that advice - it is very well taken. Obviously, my goal is to mitigate as much as possible - I have accepted that I cannot stop all DDoS - my question is, do serious people ever attempt to do the mitigation/load shedding with a host-based firewall (in this case fbsd+ipfw) ? Or would all serious people interested in mitigating attacks use an appliance, like a netscreen ? No one seriously mitigates with a host-based system. By the time the packet has gotten to the back-end host, it has to have already been mitigated. This is basically the same reason people use SSL accelerators, if they can find them: if you do both sets of processing (serving and SSL... or in your case, serving and firewalling) on the same host, then you detract from the ability of that host to handle the load that it needs to handle. It's no mistake that only the login to HotMail is SSL, and then only if you go out of your way to ask for it. Consider that an unaccelerated host can handle - maybe - 200 SSL connections per second, at 100% CPU load. In fact, most people use a load balancer to mitigate DDOS attacks; load banacers that proxy connections usually permit you to limit the number of simultaneous connections to the back end servers; you degrade gracefully to maximum load, and then you degrade no farther. FreeBSD is really not ideal for doing this type of thing, without custom code. The FreeBSD stack, by default, has a number of issues that make it perform poorly in this situation. The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). For the most part, Linux has the same problems FreeBSD does, or worse, with a few obscure exceptions (e.g. QLinux). The best place to stop an attack is your router... preferrably, on your NSP's side of the link, before the packets get into your pipe, since your pipe is smaller than your NSP's pipe. I will say this - 9/10 attacks that hurt me do not do anything interesting - in fact they are even low bandwidth (2-3 megabits/s) but they have a packet/second rate that just eats up all my firewall cpu and no traffic goes through - and as soon as the attack goes away the firewall is fine. FreeBSD 4.x can handle full Gigabit pipe packet rates, though a 1GHz CPU goes to near 100%. The real issue that bites you ends up being your bus bandwidth, not anything to do with the OS -- assuming you have tuned the OS correctly. The modifications for this are, I think, relatively minor and will be obvious if you have the necessary profiling capability. FreeBSD 5.x network performance is really poor, relative to 4.x; I do not recommend using FreeBSD 5.x in a production environment. If you insist on using it, make sure it's behind something else that isn't as limited (like a FreeBSD 4.x box) that has been properly configured to do load shedding (both stack mods and tuning; the best tuning yo can do, in most cases, is to turn off SYN cookie, and crank up maxfiles, preboot, tune up the number of ports that can be used, set the KVA to 3G and the UVA to 1G, and then add RAM). So, I am looking at putting in more sophisticated traffic shaping (limiting packets/s from each IP I have) and skipto rules to make the ruleset more efficient ... but this is going to be a lot of work, and I want to know if it is all just a waste because no matter how good I get at a freebsd firewall, a netscreen 10 will always be better ? In your position, I'd buy a Cisco CSS. Jon Mini (hi, Jon!) might recommend an F5 box, since he works for them now. Actually, in your position, I'd demo a Cisco CSS, and see if it did what I wanted (protect itself, and, by count-limiting, protects your back-end boxes). A lot of these type of boxes are based on older versions of FreeBSD, plus modifications that they may or may not have tried to get back into the mainline source tree. Load shedding is different from Netscreen or other firewalls, in that it doesn't attempt to differentiate attacks from regular traffic. You can't do that, except in the grossest way, and a cookbook attacker will just switch software, if they find that their attack is no longer effective. If you can live with a low granularity classification system, or are OK with source IP limiting (which doesn't work against a well-distributed DDOS, since you'd only get one packet from each attacker), which is mostly just a way to screw people who are behind a NAT from having a large number of connections based on actually needing a large number of connections, then a Netscreen or similar product is OK (I guess). Bottom line is that you need to limit it before it gets to the local wire, especially if it's an amplification or reflection attack against an internal host, that uses your own resources against you (e.g. ping of death-type attacks); I have a hard time believing
Re: FreeBSD firewall for high profile hosts - waste of time ?
:per second down its throat, it chokes _hard_. You think that optimizing :my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw :firewall with 1-200 rules running on it ? : :thanks. Run 'ipfw -v list' on it. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Again, thank you very much for your advice and comments - they are very
well taken.
I will clarify and say that the fbsd system I am using / talking about is
a _dedicated_ firewall. Only port 22 is open on it.
Do not open this port outside
The problem is, I have a few hundred ipfw rules (there are over 200
machines behind this firewall) and so when a DDoS attack comes, every
packet has to traverse those hundreds of rules - and so even though the
firewall is doing nothing other than filtering packets, the cpu gets all
used up.
Try this simple ruleset:
possible deny log tcp from any to any setup tcpoptions !mss
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
where your.c.net{x,y,z,so on...} is your /24 net and list
of hosts in this net.
If you have more then one /24 net use one rule
per each (see man ipfw).
Does this cover your needs?
(as I wrote accounting is different task)
I have definitely put rules at the very front of the ruleset to filter out
bad packets, and obvious attacks, but there is a new one devised literally
every day.
I have 3000+ users with 1 or more IP each.
typical reconfiguration rate of one router:
0sw~(3)#zcat /var/log/all.0.gz | grep 'config now' | wc -l
91
0sw~(4)#zcat /var/log/all.1.gz | grep 'config now' | wc -l
90
0sw~(5)#zcat /var/log/all.2.gz | grep 'config now' | wc -l
92
_per day_
and it is very easy ... with ISPMS/ISPDB based on PostgreSQL
Do you interested?
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Run 'ipfw -v list' on it. Yes .. I do that ... and it shows me a list of my firewall rules. I usually use `ipfw show`. What is the difference, and what does this accomplish ? Sorry if I am missing somthing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: Again, thank you very much for your advice and comments - they are very well taken. I will clarify and say that the fbsd system I am using / talking about is a _dedicated_ firewall. Only port 22 is open on it. The problem is, I have a few hundred ipfw rules (there are over 200 machines behind this firewall) and so when a DDoS attack comes, every packet has to traverse those hundreds of rules - and so even though the firewall is doing nothing other than filtering packets, the cpu gets all used up. There is sorting that you can do, like putting the highest-traffic rules near the top. ipfw terminates the search on the first matching rule except for count and skipto. Also, the fewer items that have to be checked the faster the rule is. Perhaps there is some aggregation that can be done with the rules themselves? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Try this simple ruleset:
possible deny log tcp from any to any setup tcpoptions !mss
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
I'd limit these to the outside interface, for performance rules.
# Whatever the interface is...
outif=fxp0
ipfw add allow ip from any to any out via ${outif}
ipfw add allow ip from any to your.c.net{x,y,z,so on...} via ${outif}
ipfw add deny log ip from any to any via ${outif}
etc...
Or, you could do.
# The internal interface is not filtered
intif=fxp1
ipfw add allow all from any to any via ${inif}
# Everything else only applies to the external interface
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
: : : Run 'ipfw -v list' on it. : :Yes .. I do that ... and it shows me a list of my firewall rules. I :usually use `ipfw show`. What is the difference, and what does this :accomplish ? Sorry if I am missing somthing. What I mean is, post the results. There might be some obvious things that can be made more efficient. Or, if you are uncomfortable posting the results to the general list, you could email them to just Nate, Terry, and me. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
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. Except that it's acting as a router, and as such there is no 'setup' except for the one he is using to configure/monitor the firewall via SSH. In essence, a no-op in a dedicated firewall setup. 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). Again, you're missing the point. This is a dedicated firewall, not a firewall being used at the point of service. [ The rest of the irrelevant descriptions deleted ] Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
On Thu, 16 Jan 2003, Josh Brooks wrote: stuff about inserting a machine snipped You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? You and I read the snipped statement differently -- I _thought_ he was saying that you should have two chained firewalls isp-fw1-fw2-internal net Have fw1 only do 'deny' things on attacks (with a default allow) and have fw2 do only 'allow' for valid traffic with a 'default deny' for everything else. The class of machine you are talking about can be purchased used for under $100 right now so it wouldn't be that much of an investment money-wise... In fact, fw1 could be a transparent bridge that just dropped dos stuff... Perhaps I'm wrong in my reading, but this might work anyway... Also note that much beefier iron can be purchased for under $500 if you are willing to do a bit of digging and assembly. You might also look at the network cards you have and replace them with different ones. Some driver/card combos are much more efficient than others. I dont know what you have, and I dont know which ones you should consider getting. I use intel (fxp) cards a lot and like them. Can anyone else recommend a NIC that is efficient, at least when used by FreeBSD's drivers? Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Nate Williams wrote: Except that it's acting as a router, and as such there is no 'setup' except for the one he is using to configure/monitor the firewall via SSH. In essence, a no-op in a dedicated firewall setup. He doesn't want just a dedicated firewall, since it won't save him from an attack like the ones he's getting. The only reasonable way to shed load is at L4/L7 interaction; if all he's doing is L3, then his firewall will likely not save him. According to most of the stuff he posted, though, he's running L4 rules in his firewall (peeking into TCP packets). A Netscreen is a stateful firewall, which will (in effect) be providing applicaiton layer proxies for the connections... this is also the way a load balancer acts, in order to shed load by limiting simultaneous connections (L4/L7). In any case, he's got something else strange going on, because his load under attack, according to his numbers, never gets above the load you'd expect on 10Mbit old-style ethernet, so he's got something screwed up; probably, he has a loop in his rules, and a packet gets trapped and reprocessed over and over again (a friend of mine had this problem back in early December). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
In any case, he's got something else strange going on, because his load under attack, according to his numbers, never gets above the load you'd expect on 10Mbit old-style ethernet, so he's got something screwed up; probably, he has a loop in his rules, and a packet gets trapped and reprocessed over and over again (a friend of mine had this problem back in early December). You are correct that the network load is very low (less than 10 megabits/s when getting attacked) but if the packets/s is extremely high .. isn't it expected if some extremely large number of packets per second traverses 2-300 properly constructed rules that the CPU is going to choke ? When I say properly constructed I just mean there is nothing blatantly wrong, like a rule loop - obviously the _efficiency_ of the ruleset could always be improved. My main question is, given that I get attacked a lot in a lot of different ways, am I wasting my time trying to find that greater efficienct ? That is, will freebsd+ipfw always be worse in a ~10 meg/s throughput network that gets attacked all the time than a purpose-built appliance like a netscreen ? I would sure like to stick with a freebsd firewall...so much nicer to use, and with all the unix tools right there... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Try this simple ruleset:
possible deny log tcp from any to any setup tcpoptions !mss
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
I'd limit these to the outside interface, for performance rules.
# Whatever the interface is...
outif=fxp0
ipfw add allow ip from any to any out via ${outif}
ipfw add allow ip from any to your.c.net{x,y,z,so on...} via ${outif}
ipfw add deny log ip from any to any via ${outif}
etc...
Your above ruleset seems to be correct ... if add
some rule for outcoming traffic.
I was too fast and keep in mind only incoming traffic.
Effectivity depends on number of interfaces.
If I remember right, one external and one internal.
If such, the ruleset without interfaces defined
for allow rules is not worse then without interfaces IMHO.
Or, you could do.
# The internal interface is not filtered
intif=fxp1
ipfw add allow all from any to any via ${inif}
# Everything else only applies to the external interface
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
Agreed
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
will freebsd+ipfw always be worse in a ~10 meg/s throughput network that gets attacked all the time than a purpose-built appliance like a netscreen ? I think its' been said that in general, the answer is no. It should behave as well, and is some cases better. There are cases where it will perform worse, but in 'general' it should behave similarly. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Try this simple ruleset:
possible deny log tcp from any to any setup tcpoptions !mss
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
I'd limit these to the outside interface, for performance rules.
# Whatever the interface is...
outif=fxp0
ipfw add allow ip from any to any out via ${outif}
ipfw add allow ip from any to your.c.net{x,y,z,so on...} via ${outif}
ipfw add deny log ip from any to any via ${outif}
etc...
Your above ruleset seems to be correct ... if add
some rule for outcoming traffic.
I was too fast and keep in mind only incoming traffic.
Effectivity depends on number of interfaces.
If I remember right, one external and one internal.
If such, the ruleset without interfaces defined
for allow rules is not worse then without interfaces IMHO.
Not true. The packets still pass through 'both' interfaces, and as such
the number of rules it must traverse is doubled (once for the internal,
one for the external). Halving the # of ipfw rules is an easy way to
decrease the load on a CPU. :)
For most people, it makes little difference, but the user in question
has a firewall that's overloaded, so 2x decrease in the # of rules might
make the difference, since the 'load' is caused by packets that
shouldn't be getting through..
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Nate Williams wrote: Except that it's acting as a router, and as such there is no 'setup' except for the one he is using to configure/monitor the firewall via SSH. In essence, a no-op in a dedicated firewall setup. He doesn't want just a dedicated firewall, since it won't save him from an attack like the ones he's getting. The only reasonable way to shed load is at L4/L7 interaction; if all he's doing is L3, then his firewall will likely not save him. According to most of the stuff he posted, though, he's running L4 rules in his firewall (peeking into TCP packets). A Netscreen is a stateful firewall, which will (in effect) be providing applicaiton layer proxies for the connections... this is also the way a load balancer acts, in order to shed load by limiting simultaneous connections (L4/L7). In any case, he's got something else strange going on, because his load under attack, according to his numbers, never gets above the load you'd expect on 10Mbit old-style ethernet, so he's got something screwed up; probably, he has a loop in his rules, and a packet gets trapped and reprocessed over and over again (a friend of mine had this problem back in early December). If I remember correctly he has less then 10Mbit uplink and a lot of count rules for client accounting. It is reason I recommend him to use userland accounting. And as far as I understand a lot of count rules is the reason for trouble. I saw something similar a lot ago at the begin of my career :-) -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
In any case, he's got something else strange going on, because his load under attack, according to his numbers, never gets above the load you'd expect on 10Mbit old-style ethernet, so he's got something screwed up; probably, he has a loop in his rules, and a packet gets trapped and reprocessed over and over again (a friend of mine had this problem back in early December). If I remember correctly he has less then 10Mbit uplink and a lot of count rules for client accounting. Ahh, I remember now. Good point. It is reason I recommend him to use userland accounting. Or another (separate) box inline with the original firewall for accounting. And as far as I understand a lot of count rules is the reason for trouble. If this is the case, then I agree. A firewall that is under attack should only be used as a firewall, not an accounting tool. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
If I remember correctly he has less then 10Mbit uplink and a lot of count rules for client accounting. It is reason I recommend him to use userland accounting. And as far as I understand a lot of count rules is the reason for trouble. I removed all the count rules a week or so ago. Now I just have 2-300 rules in the form: [ Snip ] Seriously, if you want more help, you're going to have to give more details than 'of the form'. Send a couple of us (not the entire list) your rules to look at, and maybe something will jump out. At this point, we can only guess, and spin our wheels trying to help you out. allow tcp from $IP to any established allow tcp from any to $IP established allow tcp from any to $IP 22,25,80,443 setup deny ip from any to $IP Seems like overkill to me, when you can do something simpler with a single rule, although depending on that rule is risky with ipfw, since it *can* be spoofed (as you are well aware). ;( and I have that same set in there about 50-70 times - one for each customer IP address hat has requested it. That's it :) Yikes. Can't you simply allow in *all* the packets for an entire netblock, and let them bounce around in the network for any 'non-listening' host? So each packet I get goes through about 5 rules at the front to check for bogus packets, then about 70 sets of the above until it either matches one of those, or goes out the end with the default allow rule. If you've got a default allow rule, what's the point of the above rules? Again, specific details (ie; your rules list) would certainly go a long way. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: I removed all the count rules a week or so ago. Now I just have 2-300 rules in the form: allow tcp from $IP to any established allow tcp from any to $IP established allow tcp from any to $IP 22,25,80,443 setup deny ip from any to $IP and I have that same set in there about 50-70 times - one for each customer IP address hat has requested it. That's it :) You have got to be frigging kidding... Q1) Are all customers who have requested it running the same rule set? Q2) Have you ever head of skipto? So each packet I get goes through about 5 rules at the front to check for bogus packets, then about 70 sets of the above until it either matches one of those, or goes out the end with the default allow rule. No, each packet goes through 2-300 rules at the front, in which the IP address does not match and the rule does not take effect. Ugh. 1) Seperate inbound and outbound, per what Nate told you. 2) Have a rule for the IP... preferrable for a block of them, instead of one per IP 3) Skip to a common rule set 4) Be happy PS: I still think that if your CPU pegs, you've got a loop in there somewhere. Most common case is a reject or deny. Try changing all of them to drop, instead, and see if that fixes it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Try this simple ruleset:
possible deny log tcp from any to any setup tcpoptions !mss
ipfw add allow ip from any to any out
ipfw add allow ip from any to your.c.net{x,y,z,so on...}
ipfw add deny log ip from any to any
I'd limit these to the outside interface, for performance rules.
# Whatever the interface is...
outif=fxp0
ipfw add allow ip from any to any out via ${outif}
ipfw add allow ip from any to your.c.net{x,y,z,so on...} via ${outif}
ipfw add deny log ip from any to any via ${outif}
etc...
Your above ruleset seems to be correct ... if add
some rule for outcoming traffic.
I was too fast and keep in mind only incoming traffic.
Effectivity depends on number of interfaces.
If I remember right, one external and one internal.
If such, the ruleset without interfaces defined
for allow rules is not worse then without interfaces IMHO.
Not true. The packets still pass through 'both' interfaces, and as such
the number of rules it must traverse is doubled (once for the internal,
one for the external). Halving the # of ipfw rules is an easy way to
decrease the load on a CPU. :)
For most people, it makes little difference, but the user in question
has a firewall that's overloaded, so 2x decrease in the # of rules might
make the difference, since the 'load' is caused by packets that
shouldn't be getting through..
The point is that DDOS goes against existing IP
addresses in internal net and will be passed through, so then faster
ruleset passes DOS packet then better ... for firewall :-)
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
why don't you read the ipfw manpage, install IPFW2, and rewrite
the ruleset using ipfw2 features (specifically the new syntax to
specify address sets) and dynamic rules:
something like
hosts={4,6,44,52,12,99,130,21,244}
ports=22,25,80,443
allow proto tcp src-ip 1.2.3.${hosts}/24 dst-port $ports setup keep-state
deny tcp from any to any
should reduce the 200+ rules that you have to the 4-lines/2-rules above.
Similar approach for UDP.
I think a lot of this discussion would have been saved if you
had given a good read to the ipfw manpage instead of trying to
tickle the ego of the list readers suggesting that the netwhatever
thing might perform better than FreeBSD on your task.
And i am stepping out of the discussion now...
cheers
luigi
On Thu, Jan 16, 2003 at 03:56:43PM -0800, Josh Brooks wrote:
If I remember correctly he has less then 10Mbit
uplink and a lot of count rules for client accounting.
It is reason I recommend him to use userland accounting.
And as far as I understand a lot of count rules is
the reason for trouble.
I removed all the count rules a week or so ago. Now I just have 2-300
rules in the form:
allow tcp from $IP to any established
allow tcp from any to $IP established
allow tcp from any to $IP 22,25,80,443 setup
deny ip from any to $IP
and I have that same set in there about 50-70 times - one for each
customer IP address hat has requested it. That's it :)
So each packet I get goes through about 5 rules at the front to check for
bogus packets, then about 70 sets of the above until it either matches one
of those, or goes out the end with the default allow rule.
I _could_ put a ruleset like the above in for every customer, but then I
would have about 2000 rules - so I only put them in for the customers that
ask. But again, even though every day I put in more and more special
blocks for DoS packets, every day there is some new DoS packet that I have
never seen before that hits me at thousands of packets per second, and all
of them flow through that entire ruleset.
-
So I am going to:
a) do the thing where I specify the interface for all my allow rules -
that sounds like it will help a lot - 3 out of the 4 rules in the set
above are allow rules - might as well push them through as soon as they
get there.
b) get better at blocking bogus packets every day :)
c) start getting more complicated rate shaping with ipfw to limit icmp
echo response and RSTs, etc.
But I still don't know if any of that helps if I get a 20,000
packet/second UDP flood to a valid port on an internal machine...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? No I'm just plain confused... 15,000 packets/second is just not that much load: Minisize15000 * 64B * 8b= 7,680,000b/S ...just less than 10 megabits/second. Maxsize 15000 * 1500B * 8b = 180,000,000b/S ...just less than 200 megabits/second. I don't understand where you are spending your CPU time, even if the packets are being written to disk before they are sent on... What's your external link speed to the Internet? Are you maybe getting an aplification attack against your router? That's just not that much in the way of packet processing overhead. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
PS: I still think that if your CPU pegs, you've got a loop in there somewhere. Most common case is a reject or deny. Try changing all of them to drop, instead, and see if that fixes it. FWIW, deny == drop. The 'reject' rule is the one that sends out ICMP and RST packets. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
On Thu, 16 Jan 2003, Josh Brooks wrote: stuff about inserting a machine snipped You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? You and I read the snipped statement differently -- I _thought_ he was saying that you should have two chained firewalls isp-fw1-fw2-internal net The load in case is really low, so one box with more powerful CPU is better then two boxes with anaemic CPUs. Have fw1 only do 'deny' things on attacks (with a default allow) and have fw2 do only 'allow' for valid traffic with a 'default deny' for everything else. The class of machine you are talking about can be purchased used for under $100 right now so it wouldn't be that much of an investment money-wise... In fact, fw1 could be a transparent bridge that just dropped dos stuff... Perhaps I'm wrong in my reading, but this might work anyway... Also note that much beefier iron can be purchased for under $500 if you are willing to do a bit of digging and assembly. You might also look at the network cards you have and replace them with different ones. Some driver/card combos are much more efficient than others. I dont know what you have, and I dont know which ones you should consider getting. I use intel (fxp) cards a lot and like them. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: My freebsd machine does _nothing_ but filter packets and run ssh. ONLY purpose is to deal with attacks. With an entire cpu dedicated to dealing with attacks you aren't likely to run out of CPU suds (at least not before your attackers fills your internet pipe). This allows you to use more reasonable rulesets on your other machines. You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? In my opinion, besides trying to optimize the filtering ruleset as suggested by other folks, you could do yourself a favor by purchasing a more decent CPU and faster DDRAM. It is obvious that at 20.000 pps or even more (with typical DoS small-sized packets) your machine won't hit the PCI bus limits, so you won't need any fancy and expensive PCI-X motherboards and/or NICs, just go for higher CPU clock, more cache, and more RAM bandwidth. Another thing to consider if your system is experiencing livelock under attacks would be using the polling mode instead of interrupts, see http://info.iet.unipi.it/~luigi/polling/ for details. Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Terry Lambert wrote: Josh Brooks wrote: You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with 256 megs ram ... and normally `top` says it is at about 80% idle, and everything is wonderful - but when someone shoves 12,000-15,000 packets per second down its throat, it chokes _hard_. You think that optimizing my ruleset will change that ? Or does 15K p/s choke any freebsd+ipfw firewall with 1-200 rules running on it ? No I'm just plain confused... 15,000 packets/second is just not that much load: Minisize15000 * 64B * 8b= 7,680,000b/S ...just less than 10 megabits/second. Maxsize 15000 * 1500B * 8b = 180,000,000b/S ...just less than 200 megabits/second. I don't understand where you are spending your CPU time, even if the packets are being written to disk before they are sent on... At 20.000 pps you have only 50 usec for forwarding each packet, without doing any other work on the system. With 500 MHz CPU this translates to 25.000 clock cycles per packet. Subtract some general interrupt and IP processing overhead, divide that by 200 ipfw rules, and you are left with only around 100 clock cycles per ipfw rule. Having in mind you are running on a system with a limited CPU cache, you'll certainly wait a lot for accessing the code/data in RAM, it's clear that this is becomes an impossible mission. So, obviously you don't need any ruleset loops as you are suggesting for such configuration to livelock... Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: The problem is, I have a few hundred ipfw rules (there are over 200 machines behind this firewall) and so when a DDoS attack comes, every packet has to traverse those hundreds of rules - and so even though the firewall is doing nothing other than filtering packets, the cpu gets all used up. I wonder if it would help to run two separate FreeBSD appliance firewalls: a 'front' one that just screens obvious attacks using stateless packet filtering, and a 'rear' one that handles more CPU-consuming stateful filtering. If carefully done, that might help a lot to alleviate the CPU bottleneck. Just a thought, Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
At 2003-01-16T18:52:00Z, Josh Brooks [EMAIL PROTECTED] writes: If I have a large network with high profile hosts (50+ shell servers, 50 or more different ircds running) am I wasting my time trying to hack and tweak a FreeBSD host-based firewall running ipfw ? Out of curiosity, have you tried FreeBSD + ipfilter (or even OpenBSD + pf, for that matter)? I've really come to appreciate ipfilter's syntax and flexibility, and it's statefulness always seemed to work better than IPFW's for me for some odd reason. Note that I mentioned statefulness. You should really, really investigate the potential useful of a stateful firewall. The massive win there is that once a connection is accepted, it gets added to a known-good list which is searched before incoming packets get sent through the filter list, and usually much more quickly. In other words, each accept rule will only get processed once *per connection*, rather than once *per packet*. Finally, I'm not sure of the lastest hardware recommendations, but I'd put the absolute best NICs in that machine that I could afford. Anyone know what the current king of the FreeBSD hill is? -- Kirk Strauser In Googlis non est, ergo non est. msg39271/pgp0.pgp Description: PGP signature
