[PATCH] ipsec esp ipfw interaction
Hello,
in early January this year there was a discussion about the way ipfw
interacts with ipsec. Last November ipfw was changed to process ipsec
datagrams twice: Once before and a second time after the decoding
procedure. This makes life easier for people who use gif tunnels with
ipsec transport mode, but it makes life harder for people (like myself)
who use native ipsec tunnel mode.
Someone suggested to make the ipfw behavior adjustable through a sysctl,
another approach was to port the Open(/Net)BSD enc0 virtual interface.
I made up a refined sysctl solution for a FreeBSD machine that is acting
as a IPsec tunnel endpoint for roadwarriors in a WLAN environment. The idea
is simple: I introduced a new sysctl "net.inet.ip.fw.ipsec_reinject" which
defaults to "1". The value is an integer and defines at which rule number
ipsec datagrams should be reinjected into the ipfw ruleset. Set it to "0",
and it won't be reinjected at all. Set it to "1" (default) and the datagram
would be reinjected at the very beginning. You also can put your post ipsec
filter rules put at 1+ and set the sysctl to "1". Flexible?
This is a first patch against -STABLE to demonstrate the concept.
Any comments?
I may provide a patch that includes ip_fw2.c and check whether it applies
to -CURRENT.
"
Bjorn Fischer
diff -ur sys/netinet/ip_fw.c /sys/netinet/ip_fw.c
--- sys/netinet/ip_fw.c Thu Nov 21 01:27:30 2002
+++ /sys/netinet/ip_fw.cWed Jan 15 17:48:23 2003
@@ -106,6 +106,8 @@
&fw_verbose, 0, "Log matches to ipfw rules");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW,
&fw_verbose_limit, 0, "Set upper limit of matches of ipfw rules logged");
+SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, ipsec_reinject, CTLFLAG_RW,
+&fw_ipsec_reinject, 1, "Reinject decoded IPsec datagrams at this rule");
/*
* Extension for stateful ipfw.
@@ -1088,7 +1090,7 @@
u_short src_port = 0, dst_port = 0;
struct in_addr src_ip, dst_ip;
u_int8_t proto= 0, flags = 0;
- u_int16_t skipto;
+ u_int16_t skipto = 0;
u_int16_t ip_len=0;
int dyn_checked = 0 ; /* set after dyn.rules have been checked. */
@@ -1106,9 +1108,18 @@
} else
hlen = ip->ip_hl << 2;
+#ifdef IPSEC
+ if (ipsec_gethist(*m, NULL) &&
+ args->divert_rule == 0 &&
+ fw_ipsec_reinject > 1)
+ skipto = fw_ipsec_reinject - 1;
+#endif
+
/* Grab and reset cookie */
- skipto = *cookie;
- *cookie = 0;
+ if (*cookie != 0) {
+ skipto = *cookie;
+ *cookie = 0;
+ }
#define PULLUP_TO(len) do {\
if ((*m)->m_len < (len)) { \
diff -ur sys/netinet/ip_fw.h /sys/netinet/ip_fw.h
--- sys/netinet/ip_fw.h Tue Jul 9 09:11:42 2002
+++ /sys/netinet/ip_fw.hWed Jan 15 16:56:38 2003
@@ -367,6 +367,7 @@
extern ip_fw_ctl_t *ip_fw_ctl_ptr;
extern int fw_one_pass;
extern int fw_enable;
+extern int fw_ipsec_reinject;
extern struct ipfw_flow_id last_pkt;
#define IPFW_LOADED(ip_fw_chk_ptr != NULL)
#endif /* _KERNEL */
diff -ur sys/netinet/ip_input.c /sys/netinet/ip_input.c
--- sys/netinet/ip_input.c Mon Nov 25 05:23:00 2002
+++ /sys/netinet/ip_input.c Wed Jan 15 17:01:58 2003
@@ -193,6 +193,7 @@
ip_fw_chk_t *ip_fw_chk_ptr;
int fw_enable = 1 ;
int fw_one_pass = 1;
+int fw_ipsec_reinject = 1;
/* Dummynet hooks */
ip_dn_io_t *ip_dn_io_ptr;
@@ -422,6 +423,11 @@
* - Wrap: fake packet's addr/port
* - Encapsulate: put it in another IP and send out.
*/
+
+#ifdef IPSEC
+ if (ipsec_gethist(m, NULL) && fw_ipsec_reinject == 0)
+ goto pass;
+#endif
iphack:
/*
Weak port system or how can I attract attention to my PRs?
Hi! For a long time I'v been disapointed with features in ports system. No ports conflicts checking and other stuff. Last year I'v begun make some things - I'v found obsoleted bin/13649 and ports/13650 PRs that introduce a ports conflics checking, I'v asked in freebsd-ports and portmgr about this patches fortune. I'v got an answer from portmgr: "it's good features and could I adapt this patches for current bsd.port.mk and pkg_tools?" I'v spend a weekend for rewriting patches (many changes really was done) and send it as followup to the PRs. It was 1 December 2002. Till now there is no reactions. I'v wrote a few mails to portmgr but I'v just ignored. Now I decide to make a new my own PRs: bin/47145 and ports/47156. Is there a chance somebody look on it and commit it? I'v got more ideas about improvement of bsd.ports.mk. Is interesting my patches to team? May be I'v just spend a time for nothing? I'd like to hear some reaction somebody of team. Comments, advises or so. Who can I talk about bsd.ports.mk improvements? Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Weak port system or how can I attract attention to my PRs?
Hmmm. This looks interesting. I'll review your patches this weekend, OK? - Jordan On Thursday, January 16, 2003, at 09:15 AM, Sergey Matveychuk wrote: Hi! For a long time I'v been disapointed with features in ports system. No ports conflicts checking and other stuff. Last year I'v begun make some things - I'v found obsoleted bin/13649 and ports/13650 PRs that introduce a ports conflics checking, I'v asked in freebsd-ports and portmgr about this patches fortune. I'v got an answer from portmgr: "it's good features and could I adapt this patches for current bsd.port.mk and pkg_tools?" I'v spend a weekend for rewriting patches (many changes really was done) and send it as followup to the PRs. It was 1 December 2002. Till now there is no reactions. I'v wrote a few mails to portmgr but I'v just ignored. Now I decide to make a new my own PRs: bin/47145 and ports/47156. Is there a chance somebody look on it and commit it? I'v got more ideas about improvement of bsd.ports.mk. Is interesting my patches to team? May be I'v just spend a time for nothing? I'd like to hear some reaction somebody of team. Comments, advises or so. Who can I talk about bsd.ports.mk improvements? Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer 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
Re: Weak port system or how can I attract attention to my PRs?
On Thu, Jan 16, 2003 at 08:15:44PM +0300, Sergey Matveychuk wrote: > It was 1 December 2002. Till now there is no reactions. > I'v wrote a few mails to portmgr but I'v just ignored. You've forgotten that we've been deep in the middle of a release cycle for the past several months. I want to look at your patches after the release. Kris msg39230/pgp0.pgp Description: PGP signature
4.7 on 2 Xeons SMP?
Hello, Is there any possibility of helping me to get started FreeBSD with SMP option (and "no SMP" works okay) on modern 2 Xeon procs server? I have about two weeks for accomplishing that, after that machine either goes under Linux, or even under Windows, as there is a complementary (and very nasty) problem -- getting Oracle 9i installed there (that is unsolved yet, although there can be some clues). I tried both 4.7-RELEASE srs/sys and that of January 14. That's what I get when booting with SMP enabled (copied from screen): Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 AP #1 (PHY# 6) failed panic y/n? mp_lock = 0001; cpuid = 0; lapic_id = (sorry, forgot to save dmesg from non-SMP boot) Does the 5.0 solve the problem? 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 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 PROTECT
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=firewall&apropos=0&sektion=0&manpath=FreeBSD+4.7-stable&format=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 ha
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: > > 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- 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: Soundcard problems on laptop
Bernard van Gastel wrote, On 01/13/03 22:12: Secondly: I have sound card problems on my laptop (Celeron 850, bla bla bla). I get a strange message when I start the system : pcm0: irq 10 at device 31.5 on pci0 pcm0: unable to map IO port space device_probe_and_attach: pcm0 attach returned 6 Try to compile new kernel with PCI_ENABLE_IO_MODES option. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[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 ?
> 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 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. As for my experience it is OK for xl interfaces and 5 rules. And 200 rules ruleset is probably a lot for 15K p/s for 500Mhz Celeron But it is probably OK for 2000+ AMD -- @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 ?
> 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
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
nswap
in : extern int nswap; /* size of swap space */ in : static int nswap; /* first block after the interleaved devs */ Is the extern pointing to this variable? (It seems so, don't see any other such variable in the three) If so, is there any problem with making nswap non-static? Thanks Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM 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: > > > > > > 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- 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
Maestro2E Problem (pcm bug?)
Hello!
I have found that Maestro2E refuses to produce sound if the total
buffer size is <16kB. For example, look at the following program:
int main(int argc,char *argv)
{
int I,J,K,SoundFD;
char Buf[256];
SoundFD=open("/dev/dsp",O_WRONLY);
if(SoundFD<0) return(1);
J=AFMT_U8;
ioctl(SoundFD,SNDCTL_DSP_SETFMT,&J);
J=0;
ioctl(SoundFD,SNDCTL_DSP_STEREO,&J);
J=44100;
ioctl(SoundFD,SNDCTL_DSP_SPEED,&J);
J=11|(8<<16); // <--- 8x2048 buffers
ioctl(SoundFD,SNDCTL_DSP_SETFRAGMENT,&J);
for(J=0;J<256;J++) Buf[J]=J&1? 0:127;
for(J=0;J<1;J++) write(SoundFD,Buf,256);
close(SoundFD);
return(0);
}
When I set the fragmentation to 64x256 or 8x2048 or some other similar
value, I get the sound. Otherwise, the driver reports "channel dead"
and there is silence. My suspicion is that the DMA buffer has to be
allocated at a 16kB segment boundary, which does not always happen when
its size is <16kB. Unfortunately, I do not know FreeBSD kernel well enough
to verify and fix this problem.
Could somebody with enough expertise please look at it and try fixing
the problem? Because of this, I can't test several programs planned for
release.
System specifications:
SYSTEM: FreeBSD 4.6.2-RELEASE
MACHINE:Toshiba Portege 3380
SOUND: ESS Maestro2E
PS: Posted this to "mobile" and "multimedia" lists some time ago with
no success.
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
