Dear NANOG/IEPG Folks; As you should know by now from reading the papers, Panix, the first ISP in NYC, has come under a new denial of service attack. The Wall Street Journal quoted Bill Cheswick to the effect that the attack is "unstoppable". Almost, but not quite, true. It's true that there isn't anything that Panix can do on its own to stop this attack. It's true that it would be hard to verify source addresses at MAEs and NAPs. But we could all verify source addresses at the first hop entry points. And get default route and unauthorized transit protection to boot. I'd like to know what the community thinks can be done to deal with an escalation of these attacks should this occur. Are you doing any source address verification now? Are you doing anything to help Panix? Could you? How seriously do you take this threat? If Panix were to go out of business and Bob Metcalfe wrote a column on it, ( :-) do you think we would have to deal with it together then, or can we sit tight and expect it to blow over? After all, it's easy to dump chemicals in the reservoir, but we still drink the water, right? Thanks. --Kent ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe@6SigmaNets.com Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~
Kent,
Dear NANOG/IEPG Folks;
As you should know by now from reading the papers, Panix, the first ISP in NYC, has come under a new denial of service attack. The Wall Street Journal quoted Bill Cheswick to the effect that the attack is "unstoppable". Almost, but not quite, true.
... XXX ... Can you explain why you just don't block the IP address of the sender from your gateway routers. Is the sender using different IP source addresses in the IP packet? Does the attacker change IP source addresses? Does the attacker attack the same ports? Use random source addresses? This does not seem like a rocket science firewall firewall project, based on what I have read. Please explain what make this attack 'rocket science' to stop. Show me the topology, the router configurations of the gateways, and the format of the denial-of-service attack packets and I'll be surprised if I can't devise a scheme to stop it, even if the attacker changes source addresses frequently (and I'm happy to do it). Thanks and Regards, Tim
Tim Bass writes:
Can you explain why you just don't block the IP address of the sender from your gateway routers.
Because each and every forged SYN comes in with a different randomly generated sender address.
Is the sender using different IP source addresses in the IP packet?
Not just different from their own address -- different in each packet!
This does not seem like a rocket science firewall firewall project, based on what I have read.
Steve Bellovin and Bill Cheswick, who literally wrote the book on firewalls, don't agree with you. Ask them if you care to.
Please explain what make this attack 'rocket science' to stop.
Okay, the problem is that there is no a priori way to know that a packet with a forged source address is not a legitimate request being made to your HTTP server or mail server. Sure, you could just block all incoming TCP traffic of all sorts, but that sort of eliminates the entire point of being connected to the net, doesn't it.
Show me the topology, the router configurations of the gateways, and the format of the denial-of-service attack packets and I'll be surprised if I can't devise a scheme to stop it,
God, you're an arrogant @#$%, aren't you.
even if the attacker changes source addresses frequently (and I'm happy to do it).
Okay. Tell me how to block the packets. Please. I'm open minded. Some of the best minds I know of have thought about this problem long and hard, but maybe you are smarter. The best thing that we've come up with is piss poor and probably won't do much good with an educated attacker. There *are* ways to harden hosts against these attacks, but thats another story. Perry
Perry, There is no reason to be hostile to me, I'm not the attacker. But, now that we know the problem is random IP source addresses as guessed, the problem is more complex, but solvable.
Steve Bellovin and Bill Cheswick, who literally wrote the book on firewalls, don't agree with you. Ask them if you care to.
Great. I was building firewalls before B & C wrote the book, what should we do, bow three time and roll over and play dead. What mantra should we chant?
God, you're an arrogant @#$%, aren't you.
Yes, technically arrogant but not necessarily an @#$%. just an engineer with lots of hours with hands on experience and have not met many problems that were not solvable, okay fusion and time travel are tough and I can't build a Tokamak in my basement :-) Instead of being negative, I prefer to too at the problem and define it in detail. How does that sound? Or shall we just throw sticks and knives at one another and resort to name calling. That will certainly fix it, Perry! ------------- An attacker sends a stream of packets to (fill in the blanks) one hosts, two hosts, a subset of hosts in a network? And the packets arrive with a frequency of ------? and the average available bandwidth of the attack flow is -----? and the average time each packet changes the pseudo random IP source addreses are? And, has an analysis been done to determine are the bogus IP source addresses stochastically random? Or, I suspect, are the changing IP source addresses pseudo-random. Yes, I'm arrogant and believe that given the details and the specifications of the problem, we can solve it and yes I believe that whining about it does little to solve the problem or help make the IP work a better place. I, we, can't however, solve a problem if it is not clearly defined. I would be very surprised to learn that an analysis on the 'random' IP source addresses show the packets truely stochastically random. Is this rocket science? Ok, maybe it is? But non-the-less the problem is not impossible to solve. Sorry for the technical arrogance, but give the facts, not the hyperbola, you don't have to write summary books on firewalls to understand how to solve a problem. Best Regards, Tim
Tim Bass writes:
There is no reason to be hostile to me, I'm not the attacker.
You are, however, walking in when you are obviously quite unaware of the details of the situation and proclaiming that you know better than everyone else. You obviously do not understand the attacks. You do not know what people actually involved have been doing to try to solve them. You also proclaimed, in advance, that the problem is simple and by implication that the world class talent that has been looking at the problem is stupid. In short, you are arrogant and ignorant.
An attacker sends a stream of packets to (fill in the blanks) one hosts, two hosts, a subset of hosts in a network? And the packets arrive with a frequency of ------? and the average available bandwidth of the attack flow is -----? and the average time each packet changes the pseudo random IP source addreses are?
Has it occurred to you that even if there were characteristics that could be used to filter the packets that the attacker might change the characteristics of what he was sending to get around them? No set of characteristics is available for filtering, because no single set of characteristics will occur in all possible attacks. Any software that assumes that the attacker, say, incremented the port number by 10 every time, or what have you, would simply be evaded by the next attacker or by the same attacker on later attacks. Indeed, in the case in question, filtering was used against consistant characteristics of the attack and then failed when the attacker changed tactics to evade the filtering. This is an arms race that cannot be won. There is no consistant mechanism that can both filter the attacks and not hurt legitimate users.
I, we, can't however, solve a problem if it is not clearly defined.
Perhaps I, we, don't have any reason to tell you more details than you know.
Yes, I'm arrogant and believe that given the details and the specifications of the problem, we can solve it and yes I believe that whining about it does little to solve the problem or help make the IP work a better place.
Mr. Bass, I'd say what I think of you at this point, but this is a family mailing list. Before you lose all respect that anyone has for you, be quiet, go away for a few days, and learn that other people working on a problem are not necessarily imbeciles just because they aren't you. Very smart people have looked at the specific problems in question. There are some good answers to the problem -- origination filtering and hardening hosts by fixing the algorithms that manage the infant connection queues in kernels. People are now busily working on both of these. Your comments, however, belong more to the problem set than to the solution set. If you expect to get respect, you will first have to give some to others. Perry
On Mon, 16 Sep 1996, Tim Bass wrote: ==>Show me the topology, the router configurations of the gateways, ==>and the format of the denial-of-service attack packets and I'll ==>be surprised if I can't devise a scheme to stop it, even if ==>the attacker changes source addresses frequently (and I'm ==>happy to do it). Okay, here you go... come up with a plan. I have a machine, X. It is directly off FastEthernet 1/1 of my 7513, Y. My net connection is a T1, off Serial0/0 of Y, to my provider's router, Z. X is 172.30.15.5/28, Y's Fast1/1 is 172.30.15.1/28, Y's Serial0/0 is 192.168.1.2/30, and Z's serial interface to me is 192.168.1.1/30. Configuration is standard, only access list on my router is an outbound access-list filtering my source addresses to make sure only packets with sources of 172.30.0.0/16 get out. It's applied in this fashion: access-list 115 permit ip 172.30.0.0 0.0.255.255 any access-list 115 deny ip any any log interface Serial0/0 ip access-group 115 out The SYN flood coming towards my host X looks like this, at approximately 2,000 PPS: 182.58.239.2.1526 -> 172.30.15.5.80 TCP SYN 19.23.212.4.10294 -> 172.30.15.5.80 TCP SYN 93.29.233.68.4355 -> 172.30.15.5.80 TCP SYN [... on and on ...] Tell me how to filter this. /cah
The SYN flood coming towards my host X looks like this, at approximately 2,000 PPS:
182.58.239.2.1526 -> 172.30.15.5.80 TCP SYN 19.23.212.4.10294 -> 172.30.15.5.80 TCP SYN 93.29.233.68.4355 -> 172.30.15.5.80 TCP SYN [... on and on ...]
Tell me how to filter this.
I don't think you can, there's no pattern. You could rotate your server address using a very short DNS TTL, though the attacker can follow the changes using DNS so this isn't all that useful even if it would be fun. The filtering has to be done at the leaf that's sending you this. If a provider knows they have only delegated address space PREFIX/LEN to some downstream provider, then they can put a source address filter on all traffic coming up the link such that if the source isn't in the delegated block, the packet is dropped. There are three reasons why this isn't practical either: (1) the number of such leaf points is very, very high; (2) the intelligence required to do the filtering is somewhat rare; (3) complete and correct coverage is the only way to stop this. Therefore we are focusing on a more reactive strategy, which is to find a way to trace these back to the source, and then effect countermeasures. The leaf provider who's allowing these in probably does not know they are being used in this way, and they are probably not within the sound of my voice. If Cisco routers had TCPDUMP capability this would be a lot simpler. If all the routers in the universe had TCPDUMP, and all the router operators had eachother's phone numbers, we could track this to the source in less than five minutes. Alas, the misfit teenagers of the underworld have caught us without any of the tools we need be able to track this down. Damned clever. Now I guess we'll all switch to X.25 after all. We were so close, too. Rats.
Paul A Vixie writes...
[...]
I don't think you can, there's no pattern. You could rotate your server address using a very short DNS TTL, though the attacker can follow the changes using DNS so this isn't all that useful even if it would be fun.
But if the attacker also followed the changes, then he'd have to be constantly querying a name server that presumably is somewhat easier to monitor than some router at some other provider. Although, I guess a smart attacker would compile a list of thousands of servers that he could randomly select from that would happily forward the request for him, so we're back to pretty much the same old random random source problem. It almost seems like it could be a good idea. -- Matt Ranney - mjr@eit.com This is how I sign all my messages.
Paul A Vixie writes:
If Cisco routers had TCPDUMP capability this would be a lot simpler. If all the routers in the universe had TCPDUMP, and all the router operators had eachother's phone numbers, we could track this to the source in less than five minutes. Alas, the misfit teenagers of the underworld have caught us without any of the tools we need be able to track this down.
The attacks will show up in Cisco netflow switching exports though. ftp://ftp.net.ohio-state.edu/users/maf/priv/flow.tar is the start of a toolkit. -- mark
On Mon, 16 Sep 1996, Paul A Vixie wrote: ==>If Cisco routers had TCPDUMP capability this would be a lot simpler. If ==>all the routers in the universe had TCPDUMP, and all the router operators ==>had eachother's phone numbers, we could track this to the source in less ==>than five minutes. Alas, the misfit teenagers of the underworld have ==>caught us without any of the tools we need be able to track this down. cisco routers do have tcpdump capability. lab-2503#debug ip packet detail ? <1-199> Access list <cr> You can show all IP packets flowing through the router (with source address/port/interface, dest address/port/interface, flags, sequence number, and window size; or limit it based on an access-list (which you'd want to do in case of a very busy router). Based on the source interface, you'd trace it to the next link, and go back from there. The debug output looks like this: IP: s=172.30.119.242 (Ethernet0), d=204.245.15.11 (BRI0), g=172.30.112.129, len 60, forward TCP src=1059, dst=80, seq=74416335, ack=0, win=8192 SYN Translation: A packet sourced from 172.30.19.242 which came in on ethernet0, had a destination of 204.245.15.11. The route-table lookup says our next hop is not directly connected (hence the g=172.30.12.129), and sent it out to 172.30.12.129 via interface BRI0. It was a TCP packet with source port of 1059, destination port of 80, sequence number of 74416335, wasn't ACKing any packet, had a window size of 8192 bytes, and had the SYN flag on. This helps tremendously in tracking down bogus packets (as long as the hacker keeps the attack up long enough for you to determine the edge of the network/the next provider in the attack). /cah ---- Craig A. Huegen CCIE #2100 || || Network Analyst, IS-Network/Telecom || || cisco Systems, Inc., 250 West Tasman Drive |||| |||| San Jose, CA 95134, (408) 526-8104 ..:||||||:..:||||||:.. email: chuegen@cisco.com c i s c o S y s t e m s
looks like the cisco access-list debugger doesn't show enough detail. as soon as the path to the attacker crosses a MAE, you need to know the source MAC level address of the router that's splattering you.
Paul A Vixie writes:
looks like the cisco access-list debugger doesn't show enough detail. as soon as the path to the attacker crosses a MAE, you need to know the source MAC level address of the router that's splattering you.
The ability to record a couple of minutes of packets, complete with MAC layer data, and examine the packets post mortem, is really important for this kind of work. tcpdump lets you do that and more. Cisco stuff isn't really in that league, though as I said its better than nothing. Perry
On Mon, 16 Sep 1996, Paul A Vixie wrote: ==>looks like the cisco access-list debugger doesn't show enough detail. ==>as soon as the path to the attacker crosses a MAE, you need to know the ==>source MAC level address of the router that's splattering you. Paul is correct; I left out the caveat that you have to go "hunting" once you get to a multi-access media network. However, a good tool at this point becomes the monitor option/port found on certain switches which will redirect traffic bound for a certain port to also appear on the monitor port for sniffing. I don't know if the GIGAswitches have such a monitoring option or port; if so, cooperation from the various IXP operators would be a great help in determining the hop. (I also think implementing a MAC-level packet debug would be very beneficial to help find culprits in this case, not to mention help troubleshoot other problems). /cah ---- Craig A. Huegen CCIE #2100 || || Network Analyst, IS-Network/Telecom || || cisco Systems, Inc., 250 West Tasman Drive |||| |||| San Jose, CA 95134, (408) 526-8104 ..:||||||:..:||||||:.. email: chuegen@cisco.com c i s c o S y s t e m s
On Mon, 16 Sep 1996, Craig A. Huegen wrote: |} Paul is correct; I left out the caveat that you have to go "hunting" |} once you get to a multi-access media network. I've already tossed most of the messages from this thread, but someone mentioned using Cisco's flow statistics to track the attacker. Mark even offered the URL to an analysis toolkit he's been working on. After using either flow or accounting data to track down the attacker, further flow data can be extracted to provide next hop and/or AS_path information. AS_path could direct you to the final ISP or organization in the path of the network address. (This doesn't take into account if the attacker has hacked an account, etc. :) This should severely limited the ammunition required to go hunting, but it does have the requirement of using Cisco's NetFlow feature(s). |} However, a good tool at this point becomes the monitor option/port |} found on certain switches which will redirect traffic bound for a |} certain port to also appear on the monitor port for sniffing. I don't |} know if the GIGAswitches have such a monitoring option or port; if so, |} cooperation from the various IXP operators would be a great help in |} determining the hop. I don't recall if the Gigaswitch supports this or not (a scan of the "Manager's Guide" doesn't mention anything), but even if it did; each port would have to be replicated independantly, eating alot of the IXP operators' time. Jonathan Heiliger \|/ _____ \|/ I S I VP, Research & Development @~/ . . \~@ Internet Systems, Inc. ________________________________/_( \___/ )_\____________________________ \__U__/ E-Mail: loco@isi.net Phone: 415.943.2915
Maybe I'm missing something here, but wouldn't these Denial of Service attacks cause a severe mismatch in the numbers of SYNs and SYN-ACKs on a given router interface? If so, then couldn't we just sweet-talk cisco into providing 5 minute counts of syns and syn-acks on an interface? You know something like: 5 minute SYNS: 123423 5 minute SYN-ACKS: 50000 Then, if the ratio got too high, it can start yelping about "Potential SYN D-O-S Atttack in progress on Interface Serial 1" In this manner "good" isp's wouldn't unknowingly carry these attacks. I envision this being done on the somewhat bigger isp's where putting inbound filters on their customer interfaces would be not a good idea (Sprint, MCI, Net 99, etc.). If the feature was enabled by default, some smaller ISPs would probably notice it--if they are watching their cisco logs at all. Personally, I know that these attacks aren't going to originate at our site, as I have the filters on. However, I am quite concerned about getting hit with one... -forrestc@imach.com
Maybe I'm missing something here, but wouldn't these Denial of Service attacks cause a severe mismatch in the numbers of SYNs and SYN-ACKs on a given router interface?
If so, then couldn't we just sweet-talk cisco into providing 5 minute counts of syns and syn-acks on an interface? You know something like:
5 minute SYNS: 123423 5 minute SYN-ACKS: 50000
Then, if the ratio got too high, it can start yelping about "Potential SYN D-O-S Atttack in progress on Interface Serial 1"
Interesting. Asymmetry might mean that it'd go undetected, except towards the site being affected (except towards the site being attacked, if they're singly-homed). What you'd *really* like is a count of SYNS by source MAC address at (i.e. at an exchange point), but what you suggest is interesting.
In this manner "good" isp's wouldn't unknowingly carry these attacks. I envision this being done on the somewhat bigger isp's where putting inbound filters on their customer interfaces would be not a good idea (Sprint, MCI, Net 99, etc.). If the feature was enabled by default, some smaller ISPs would probably notice it--if they are watching their cisco logs at all.
Personally, I know that these attacks aren't going to originate at our site, as I have the filters on. However, I am quite concerned about getting hit with one...
-forrestc@imach.com
Avi
Your suggestion has two flaws: 1. missed SYN ACKs due to asymmetric routing. 2. missed SYN ACKs due to diode routes. One could argue, of course, that notification of this condition (without speculating on whether the condition is any of an asymmetric route, a diode route, or a SYN attack) might be worthwhile... I'm gonna have to go digging in my archives for the messages I sent to the CERT and the IETF about this potential problem after it happened to me at Apple, three years ago, due to a diode route. I publically recommended to the IETF mailing list that the edges of the network be filtered, and I privately recommended to the CERT that they begin flogging the systems vendors for robustness in the face of precisely this denial of service attack in their hosts. You can imagine the incredible levels of enthusiastic "can do" attitude I got... Erik Fair
In message <v03007814ae643a8d0173@[198.68.110.3]>, "Erik E. Fair" writes:
Your suggestion has two flaws:
1. missed SYN ACKs due to asymmetric routing.
On the order of 1,000 pps worth?
2. missed SYN ACKs due to diode routes.
Again. On the order of 1,000 pps worth? Remeber that a corrected kernel needs on the order of 1,000 pps on SYNs to have an effect (much more if the timer is dropped from 75 seconds). With the hashed PCBs the host doesn't even slow down all that much either. OTOH if the attacked host has a listen queue of 8 or something real small, it only takes one packet every 8 seconds or so to keep the queue full with a 75 second timer. Curtis
On Tue, 17 Sep 1996, Curtis Villamizar wrote:
In message <v03007814ae643a8d0173@[198.68.110.3]>, "Erik E. Fair" writes:
Your suggestion has two flaws:
1. missed SYN ACKs due to asymmetric routing.
On the order of 1,000 pps worth?
The other option here is to log SYNS and ACK's (both going in the same direction) - They will definately BOTH been seen at the same interface - regardless of routing topology, unless you are talking about some form of load balancing where packets are spewed down somewhat random paths. This doesn't account for "null0" routes and attempted connections to down machines, but.... What we're watching for is 1000 pps of excessive SYNS with no ACKS. Even if you set the trigger level at 500 SYN/NO ACK per sec, you'd catch an interface where you've got an excessive level of these going on. The real drawback, which I meant to mention in my original post (but didn't) and has been mentioned by a cisco person here, is that this requires going a little deeper into the packets than normal - For those routers which switching is implemented in silicon, this might be a problem. It also increases CPU load. I also want to make it clear that in my opinion, where possible, EVERYONE should be doing filtering on their customer-facing interfaces. (yes, all my PPP customers have a filter which permits stuff from THEIR IP and only THEIR IP.) However, in a situation where you have downstreams which are running dynamic (BGP4) routing, filtering may not be practical. This would provide an additional tool to determine if these attacks are occuring, and to track them to the source. -forrestc@imach.com
"Forrest W. Christian" writes:
Maybe I'm missing something here, but wouldn't these Denial of Service attacks cause a severe mismatch in the numbers of SYNs and SYN-ACKs on a given router interface? [...] Then, if the ratio got too high, it can start yelping about "Potential SYN D-O-S Atttack in progress on Interface Serial 1"
In this manner "good" isp's wouldn't unknowingly carry these attacks.
I think it is easier to just block the attacks completely by source filtering your own network, at which point you can't carry such an attack, knowingly or unknowingly.
I envision this being done on the somewhat bigger isp's where putting inbound filters on their customer interfaces would be not a good idea (Sprint, MCI, Net 99, etc.).
What you propose is actually much harder to build than filters are.
Personally, I know that these attacks aren't going to originate at our site, as I have the filters on. However, I am quite concerned about getting hit with one...
Please help, then, in convincing people that it is important to turn on filtering on all leaf networks. Perry
In message <Pine.LNX.3.91.960917030857.17180B-100000@IMgate.iMach.com>, "Forres t W. Christian" writes:
Maybe I'm missing something here, but wouldn't these Denial of Service attacks cause a severe mismatch in the numbers of SYNs and SYN-ACKs on a given router interface?
If so, then couldn't we just sweet-talk cisco into providing 5 minute counts of syns and syn-acks on an interface? You know something like:
5 minute SYNS: 123423 5 minute SYN-ACKS: 50000
Then, if the ratio got too high, it can start yelping about "Potential SYN D-O-S Atttack in progress on Interface Serial 1"
In this manner "good" isp's wouldn't unknowingly carry these attacks. I envision this being done on the somewhat bigger isp's where putting inbound filters on their customer interfaces would be not a good idea (Sprint, MCI, Net 99, etc.). If the feature was enabled by default, some smaller ISPs would probably notice it--if they are watching their cisco logs at all.
Personally, I know that these attacks aren't going to originate at our site, as I have the filters on. However, I am quite concerned about getting hit with one...
-forrestc@imach.com
That's a really good idea. Cutting the sample interval (60 seconds, configurable) and generating an SNMP trap would be a good idea too. You'd also want absolute and percent threshholds on the traps. This shouldn't be tough except at the very high end router vendors hate looking inside each packet for anything (especially if they have ASICs helping with some of the forwarding work). Just need the protocol number in the IP field and the TCP SYN and ACK bits and two counters. Curtis
"Craig A. Huegen" writes:
==>If Cisco routers had TCPDUMP capability this would be a lot simpler. If ==>all the routers in the universe had TCPDUMP, and all the router operators ==>had eachother's phone numbers, we could track this to the source in less ==>than five minutes. Alas, the misfit teenagers of the underworld have ==>caught us without any of the tools we need be able to track this down.
cisco routers do have tcpdump capability.
Not really. You can dump packets, but you can't do what you really need to do, which is snapshot all the packets in a binary format with microsecond timestamps and then run BPF style filters over them to isolate small sections of the traffic you are interested in. If you can't run automated tools over the raw packets its hard to catch some of the needed subtleties. Of course, what you have is indeed better than nothing. Perry
On Mon, 16 Sep 1996, Craig A. Huegen wrote:
The SYN flood coming towards my host X looks like this, at approximately 2,000 PPS:
182.58.239.2.1526 -> 172.30.15.5.80 TCP SYN 19.23.212.4.10294 -> 172.30.15.5.80 TCP SYN 93.29.233.68.4355 -> 172.30.15.5.80 TCP SYN [... on and on ...]
Tell me how to filter this.
The only thing that comes close to the concept of "filtering" is to build a SYN proxy that replies with SYN-ACK and hangs onto SYN packets until the ACK is received from the net before actually letting the packets through to your server. This may require sequence number munging on every packet but that's generally the kind of thing proxies do. Of course, such a proxy does not yet exist except possibly as somebody's home-built box based on some stripped down BSD-ish UNIX kernel with various modifications. But assuming that you can build a box with enough horsepower to handle 100baseTx/FDDI/whatever in and 100baseTx/FDDI/whatever out, then this is in the realm of possibility. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
How exactly proxy is supposed to behave when it "hangs onto" say 10.000 + unfinished TCP connections ? Will it deny new ones (because resources are always limited) ? Looks like it's the only thing it will be able to do and as soon as first packet is denied, hacker's won. As hard as it is to be implemented the only way to fight this is have every single ISP to filter outgoing packets. Assuming big players have enough desire they can do it quickly by making an offer smaller ISPs can't refuse, the same kind Sprint made when it started filtering small CIDRs. It's certainly harder to catch those who don't comply though ... Interestingly enough, the source IP's could be valid, then it becomes even harder to see if the TCP connection request is valid or bogus. And once again, source filtering by ea and every AS looks like the only solution.
On Mon, 16 Sep 1996, Craig A. Huegen wrote:
The SYN flood coming towards my host X looks like this, at approximately 2,000 PPS:
182.58.239.2.1526 -> 172.30.15.5.80 TCP SYN 19.23.212.4.10294 -> 172.30.15.5.80 TCP SYN 93.29.233.68.4355 -> 172.30.15.5.80 TCP SYN [... on and on ...]
Tell me how to filter this.
The only thing that comes close to the concept of "filtering" is to build a SYN proxy that replies with SYN-ACK and hangs onto SYN packets until the ACK is received from the net before actually letting the packets through to your server. This may require sequence number munging on every packet but that's generally the kind of thing proxies do.
In message <Pine.BSI.3.93.960916191246.3265P-100000@sidhe.memra.com>, Michael D illon writes: : :The only thing that comes close to the concept of "filtering" is to build :a SYN proxy that replies with SYN-ACK and hangs onto SYN packets until the :ACK is received from the net before actually letting the packets through :to your server. This may require sequence number munging on every packet :but that's generally the kind of thing proxies do. : :Of course, such a proxy does not yet exist except possibly as somebody's :home-built box based on some stripped down BSD-ish UNIX kernel with :various modifications. But assuming that you can build a box with enough :horsepower to handle 100baseTx/FDDI/whatever in and :100baseTx/FDDI/whatever out, then this is in the realm of possibility. : A beefed up application level firewall would probably work well in this situation. --Chris :Michael Dillon - ISP & Internet Consulting :Memra Software Inc. - Fax: +1-604-546-3049 :http://www.memra.com - E-mail: michael@memra.com ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say blizzard@nysernet.org | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig -------------------------------------------------------------------
Craig:
2,000 PPS:
182.58.239.2.1526 -> 172.30.15.5.80 TCP SYN 19.23.212.4.10294 -> 172.30.15.5.80 TCP SYN 93.29.233.68.4355 -> 172.30.15.5.80 TCP SYN [... on and on ...]
Tell me how to filter this.
Okay, the way this *might* be filtered involves a couple of steps: (1) Set up logging (as you have done) dump the data saving the IP addresses (with port numbers); then (2) Using documented stochastic methods, look for the hidden pattern in the pseudo-random sequences. There are computer programs to do this, sorry, I would have to do a search to find one (the exist, however); Note: The sequence above is too short to determine any pseudo-random pattern (of course). But keep in mind, all computer generated 'random number' sequences are not truly random and there are generally determinate. Also, if a file is being used as a basic for the attack, perhaps it repeats itself (this is the easy case, not-likely ;) (3) Given it is possible to break the code, hack together some telnet 'update the router access-lists' based on the predictive algorithm. (another chapter, yet to be documented) However, George is right in his conjecture that the problem becomes more difficult when you consider that there is 'good traffic' as well. Hence, the problem becomes a signal processing exercise of determining the signal (the good source addresess) from the noise (the bad source addresses). Admittedly, it is difficult (but hey, you ISPs wanted to get into the business and make the big bucks, so deal with it, and put those big profits to use, like all the other telecom folks have to do to protect their services :-) ANYWAY, this type of counter-measure is not easily done, and I'm not sure that discussing the details in public is a good idea. I have already been called 'irresponsible' in private for discussing this technique. BTW, do all the attacks have the same port and destination? Thanks, Tim
On Mon, 16 Sep 1996, Tim Bass wrote: ==>(1) Set up logging (as you have done) dump the data saving the ==>(2) Using documented stochastic methods, look for the hidden ==>(3) Given it is possible to break the code, hack together some This would be a great thing, if only the tools were written. Unfortunately, at this time, it would take a lot of human work just to build the tools to look for patterns (or for the humans to look for patterns themselves). (BTW, most source-address spoofing code I've seen involves the random() function, and seeds the random-number generator frequently as well--you'd really have to have sophisticated hardware to analyze all of this) At this point, the only REAL solution we have is to take the following steps and ask our neighboring NSP's/direct providers to: 1) Educate customers and ask their commitment to add out-bound access-list's allowing only those packets sourced from their CIDR blocks (for stub networks). 2) dedicate some resources to tracing these attacks and pressuring the upstream providers involved in attacks to do the same. ==>BTW, do all the attacks have the same port and destination? Yes, they do. However, so does all legitimate traffic to my web server. /cah ---- Craig A. Huegen CCIE #2100 || || Network Analyst, IS-Network/Telecom || || cisco Systems, Inc., 250 West Tasman Drive |||| |||| San Jose, CA 95134, (408) 526-8104 ..:||||||:..:||||||:.. email: chuegen@cisco.com c i s c o S y s t e m s
Tim Bass writes:
(2) Using documented stochastic methods, look for the hidden pattern in the pseudo-random sequences.
I will point out that this is not possible in the general case.
(3) Given it is possible to break the code, hack together some telnet 'update the router access-lists' based on the predictive algorithm. (another chapter, yet to be documented)
Let me get this straight. You are being sprayed with over 200 packets a second in a random sequence. You are to reload your Cisco's access lists 200 times a second over a telnet based expect script or something similar? This doesn't strike you as impractical?
Admittedly, it is difficult
It is impossible using the stated methods. Perry
On Mon, 16 Sep 1996, Kent W. England wrote:
How seriously do you take this threat? If Panix were to go out of business and Bob Metcalfe wrote a column on it, ( :-) do you think we would have to deal with it together then, or can we sit tight and expect it to blow over? After all, it's easy to dump chemicals in the reservoir, but we still drink the water, right?
I think we all have learned to live with Bob, and I have plenty of bottled water in the basement. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
On Mon, 16 Sep 1996, Kent W. England wrote:
I'd like to know what the community thinks can be done to deal with an escalation of these attacks should this occur. Are you doing any source address verification now? Are you doing anything to help Panix? Could you?
Have a look at the firewalls mailing list archive for more info http://www.greatcircle.com/firewalls/archive/firewalls.9609.Z There are at least three things you can do to protect yourself from such attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers of incomplete socket connections. One is to have another machine or your network issue RST's for sockets that it thinks are part of the SYN flood attack. And one is to install a SYN proxy machine between your net and the Internet which catches all SYN packets and holds them until an ACK is received at which point the SYN and the ACK are passed on to your network. Such a proxy can be built to handle HUGE numbers of incomplete conections. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Have a look at the firewalls mailing list archive for more info http://www.greatcircle.com/firewalls/archive/firewalls.9609.Z
There are at least three things you can do to protect yourself from such attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers of incomplete socket connections. One is to have another machine or your network issue RST's for sockets that it thinks are part of the SYN flood
I like this.
attack. And one is to install a SYN proxy machine between your net and the Internet which catches all SYN packets and holds them until an ACK is received at which point the SYN and the ACK are passed on to your network.
I like this even more, but the potential for disaster if the box goes down is just too huge...
Such a proxy can be built to handle HUGE numbers of incomplete conections.
Michael Dillon - ISP & Internet Consulting
Avi
Micheal Dillon suggests:
There are at least three things you can do to protect yourself from such attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers of incomplete socket connections. One is to have another machine or your network issue RST's for sockets that it thinks are part of the SYN flood attack. And one is to install a SYN proxy machine between your net and the Internet which catches all SYN packets and holds them until an ACK is received at which point the SYN and the ACK are passed on to your network. Such a proxy can be built to handle HUGE numbers of incomplete conections.
Great suggestion Mike! Much quicker to do than a stochastic analysis of the pseudo-random nature of the attack (unless your the US goverment :-) and much cheaper to implement (unless your the US goverment :-) Certainly the UNIX proxy hack is easier than resorting to code-breaking, stochastic methods. Hats off to you, Tim
Tim writes:
There are at least three things you can do to protect yourself from such attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers of incomplete socket connections. One is to have another machine or your network issue RST's for sockets that it thinks are part of the SYN flood attack. And one is to install a SYN proxy machine between your net and the Internet which catches all SYN packets and holds them until an ACK is received at which point the SYN and the ACK are passed on to your network. Such a proxy can be built to handle HUGE numbers of incomplete conections.
Great suggestion Mike! Much quicker to do than a stochastic analysis of the pseudo-random nature of the attack (unless your the US goverment :-) and much cheaper to implement (unless your the US goverment :-) Certainly the UNIX proxy hack is easier than resorting to code-breaking, stochastic methods. Hats off to you,
I'm not sure it's even possible to analyze the pseudo-random shifting attack (among other problems, there will be legitimate traffic in the stream, so knowing what SYNs are bad is a pain) in anything approaching realtime, so yes, one of the other methods is a much better choice 8-) -george william herbert gherbert@crl.com
I'm not sure it's even possible to analyze the pseudo-random shifting attack (among other problems, there will be legitimate traffic in the stream, so knowing what SYNs are bad is a pain) in anything approaching realtime, so yes, one of the other methods is a much better choice 8-)
-george william herbert gherbert@crl.com
There are other things that one might look at besides trying to analyze and predict the pseudo-randomness in certain sequences of fields. But I'm convinced hardening hosts and getting more providers to filter packets with bogus source IPs is the best way to attack the problem. Avi
Michael Dillon writes:
There are at least three things you can do to protect yourself from such attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers of incomplete socket connections.
Also, hashing the incoming PCBs is a big win.
One is to have another machine or your network issue RST's for sockets that it thinks are part of the SYN flood attack.
Thats not particularly useful, since automatically detecting these things can't be done in the general case and processing the RSTs costs. This is ISS's approach and I don't really like it.
And one is to install a SYN proxy machine between your net and the Internet which catches all SYN packets and holds them until an ACK is received at which point the SYN and the ACK are passed on to your network. Such a proxy can be built to handle HUGE numbers of incomplete conections.
That breaks TCP, and often badly. In fact, the problem isn't so bad with a properly designed kernel. The initial experiments say that increasing the size of the incoming connection queue, hashing the queue, and adaptively lowering the timeout on infant connections should permit you to survive pretty intense attack without stopping service. This is probably the best approach for people to unilaterally take. However, in general, it would be very nice for providers to start filtering their customers so that they could not send forged packets from network numbers they don't own. Perry
Michael Dillon writes:
There are at least three things you can do to protect yourself from such attacks. One is to patch your UNIX/BSD kernel to allow much higher numbers of incomplete socket connections.
Also, hashing the incoming PCBs is a big win.
Or not even creating PCBs and socket structures for the un-acknowledged SYNs. Keep them in a data structure that stores the pertinent info and reconstruct the packets when the ack comes in (when you create the mbufs/ PCB/socket).
That breaks TCP, and often badly. In fact, the problem isn't so bad with a properly designed kernel. The initial experiments say that increasing the size of the incoming connection queue, hashing the queue, and adaptively lowering the timeout on infant connections should permit you to survive pretty intense attack without stopping service. This is probably the best approach for people to unilaterally take.
Here here.
However, in general, it would be very nice for providers to start filtering their customers so that they could not send forged packets from network numbers they don't own.
Here here here.
Perry
Avi
Date: Mon, 16 Sep 1996 16:14:14 -0700 From: "Kent W. England" <kwe@6SigmaNets.com> Sender: owner-nanog@merit.edu Dear NANOG/IEPG Folks; As you should know by now from reading the papers, Panix, the first ISP in NYC, has come under a new denial of service attack. The Wall Street Journal quoted Bill Cheswick to the effect that the attack is "unstoppable". Almost, but not quite, true. Not only is it difficult to stop, but difficult to trace since it requires the *immediate* cooperation of all intervening providers. It's true that there isn't anything that Panix can do on its own to stop this attack. It's true that it would be hard to verify source addresses at MAEs and NAPs. But we could all verify source addresses at the first hop entry points. And get default route and unauthorized transit protection to boot. I'd like to know what the community thinks can be done to deal with an escalation of these attacks should this occur. Are you doing any source address verification now? Are you doing anything to help Panix? Could you? We just put in source address filters. Being a single homed site with only 3 CIDR blocks made that quick and easy. I think we need to make it as easy as possible for ISP's with little technical knowledge to do the same. Has someone come up with instructions on how to do source address filtering/verification for different brands of routers? It would be good if someone could put up a web page with complete instructions on how to do this. If this could be done quick enough we could possibly get the URL some publicity due to the current Panix attack. Another item that may be usefull would be a list of providers that do perform source address verification. Is there an easy way to verify from an outside host that the filtering is being done? Without verification we couldn't trust the list of sites that claim to filter. Operating system changes may also minimize the impact of this type of attack and those changes should be encouraged. Changes like an adaptive SYN timout along with more dynamic table allocation. How seriously do you take this threat? If Panix were to go out of business and Bob Metcalfe wrote a column on it, ( :-) do you think we would have to deal with it together then, or can we sit tight and expect it to blow over? After all, it's easy to dump chemicals in the reservoir, but we still drink the water, right? How likely is Panix to go under from this? Admittedly incomming connections are seriously effected, but if Panix were to filter out incoming SYN's at their entry points could their customers still do outbound browsing? They could open and close the door periodically to try and receive incoming e-mail or move MX records around to get mail in. Their Web customers would seem to be the most heavily effected as their pages can't be seen. Bottom line, exactly how is this attack effecting Panix servers and what are they able to do to at least operate in a degraded fashion during these attacks? What could *I* do if my site were attacked? Thanks. --Kent ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe@6SigmaNets.com Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ -- David.Schmidt@on-ramp.ior.com Internet On-Ramp, Inc. (509)624-RAMP (7267) Spokane, Washington http://www.ior.com/ (509)323-0116 (fax)
"David J. Schmidt" writes:
How likely is Panix to go under from this? Admittedly incomming connections are seriously effected, but if Panix were to filter out incoming SYN's at their entry points could their customers still do outbound browsing?
Panix makes a considerable fraction of their income from web hosting, which is an incoming operation. Luckily, the situation was palliated by hardening the system kernels and also the attacks have subsided, possibly because they were no longer particularly effective.
Bottom line, exactly how is this attack effecting Panix servers and what are they able to do to at least operate in a degraded fashion during these attacks? What could *I* do if my site were attacked?
Right now? If you don't have system source to your kernels I would say you are hosed. I would suggest trying to work to get lots of ISPs to filter outgoing packets. Its the surest defense for everyone. Additionally, if you do have sources to your kernel there may be fixes that can be made in advance of vendors announcing patches. BTW, if anyone is actually being attacked right now, please get in touch with me. Perry
On Mon, 16 Sep 1996, Perry E. Metzger wrote: ==>Right now? If you don't have system source to your kernels I would say ==>you are hosed. I would suggest trying to work to get lots of ISPs to ==>filter outgoing packets. Its the surest defense for ==>everyone. Additionally, if you do have sources to your kernel there ==>may be fixes that can be made in advance of vendors announcing ==>patches. As part of a task force studying this problem, I have called some of the major hardware vendors (namely SGI, HP, and Sun). SGI told one of the team members "we're not allowed to really talk about this". Sun and HP have both said "we've formed a council that has been evaluating the situation, and will make available anything we have done to help alleviate or prevent the problems". /cah
On Mon, 16 Sep 1996, David J. Schmidt wrote:
Has someone come up with instructions on how to do source address filtering/verification for different brands of routers? It would be good if someone could put up a web page with complete instructions on how to do this. If this could be done quick enough we could possibly get the URL some publicity due to the current Panix attack.
I would certainly publicize such a website. Although I think it would be best if it was placed at some other site with info that ISP's should see like perhaps www.ra.net. So far I've only seen Cisco filters posted. We still need to see instructions for Livingston IRX, Bay, and Linux/FreeBSD ipfwadm Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
On Mon, 16 Sep 1996 19:53:12 -0700 (PDT), michael@memra.com writes:
On Mon, 16 Sep 1996, David J. Schmidt wrote:
Has someone come up with instructions on how to do source address filtering/verification for different brands of routers? It would be good if someone could put up a web page with complete instructions on how to do this. If this could be done quick enough we could possibly get the URL some publicity due to the current Panix attack.
I would certainly publicize such a website. Although I think it would be best if it was placed at some other site with info that ISP's should see like perhaps www.ra.net.
So far I've only seen Cisco filters posted. We still need to see instructions for Livingston IRX, Bay, and Linux/FreeBSD ipfwadm
Filters for Bay routers are not very difficult, owing to the graphical configuration tools. On one of my ethernet segments, all source addresses should be in the 167.142.0.0 range. Here is how I built a filter for this interface: In Site Manager, select the circuit that the filter will be applied to. Filters are built for traffic coming IN to the interface, so in this case I applied the filter to my ethernet interface. Once the interface is selected, select "Edit Circuit", then pull down Protocols->Edit IP->Traffic Filters. If this is the first filter of this type that you're creating, you'll need to create a filter template first. This template gets stored on your hard drive, so you can jump over to another router and apply the same filter template, just changing the appropriate addresses. Once you create a new template, you'll want to choose the following: Condition->IP Source Address 0.0.0.0 - 167.142.0.0 167.142.255.255 - 255.255.255.255 Action->Drop Action->Detailed Log (this is optional.. I use it) That's all there is to it. Once you create this template, then go back to the "IP Filters" screen and actually create the filter. When prompted for a template, use the one you just created. This method tells the router to allow that which you do not specifically deny. You can also create two filters, one saying "drop everything" and the other one telling it specifically what you want to allow. Personally, I prefer the first method because it seems more efficient.. Perhaps someone from Bay will comment on the optimal way to do this. No, it's not as easy to post instructions for a Bay Router as it is for a Cisco. On the other hand, it's *extremely* easy to create and manage filters using Site Manager. If anyone has questions on this, feel free to ask me or call me (515 830 0389). I've done it plenty of times and would be happy to help. -Jon ----------------------------------------------------------------- * Jon Green * Wide-Area Networking Technician * * jon@netINS.net * Iowa Network Services, Inc. * * Finger for Geek Code/PGP * 312 8th Street, Suite 730 * * #include "std_disclaimer.h" * Des Moines, IA 50309 * -------------------------------------------------------------------------
Has someone come up with instructions on how to do source address filtering/verification for different brands of routers? It would be good if someone could put up a web page with complete instructions on how to do this. If this could be done quick enough we could possibly get the URL some publicity due to the current Panix attack.
I would certainly publicize such a website. Although I think it would be best if it was placed at some other site with info that ISP's should see like perhaps www.ra.net.
So far I've only seen Cisco filters posted. We still need to see instructions for Livingston IRX, Bay, and Linux/FreeBSD ipfwadm
Simple for Livingstons... create a filter "internet.out" Contents: three lines for each net block you have: permit 1.2.3.4/20 tcp permit 1.2.3.4/20 udp permit 1.2.3.4/20 icmp final line to log (optional) MUST COME AFTER permit list for netblocks: deny log The final line will have the router syslog a message any time someone tries to send from an address outside your blocks, as defined in the rest of the filter. This is optional. Keep in mind that the panix attack would probably have flooded your syslog machine's disk space with syslog info in this case. Hardening that is an issue for another day, however. Apply this to all outbound ports on your gateway IRX routers. You can do similar things with inbound ports on customer connections or other internal routers if you desire to start filtering earlier than your border gateway machines. For example, if 1.2.3.0/21 is your block for your St Louis hub and 2.3.11.0/24 and 2.3.22.0/26 are customer nets there, then the outbound interface for your St Louis IRX could have the following filter on its outbound interface(s): permit 1.2.3.0/21 tcp permit 1.2.3.0/21 udp permit 1.2.3.0/21 icmp permit 2.3.11.0/24 tcp permit 2.3.11.0/24 udp permit 2.3.11.0/24 icmp permit 2.3.22.0/26 tcp permit 2.3.22.0/26 udp permit 2.3.22.0/26 icmp deny log Alternatively you can filter on incoming ports with the same syntax. -george william herbert gherbert@crl.com Random Disclaimer time, since InterNIC asked me recently: I have not been a CRL employee for nearly 2 years. My opinions are of course my own.
I have to stand somewhat corrected.
create a filter "internet.out" Contents: three lines for each net block you have:
permit 1.2.3.4/20 tcp permit 1.2.3.4/20 udp permit 1.2.3.4/20 icmp
The more appropriate format would be: permit 1.2.3.4/20 0.0.0.0/0 tcp permit 1.2.3.4/20 0.0.0.0/0 udp permit 1.2.3.4/20 0.0.0.0/0 icmp You are *supposed* to use a src/dest netblock pair, though I have set up and used w/o a dest address and it worked.
final line to log (optional) MUST COME AFTER permit list for netblocks: deny log
If you choose not to log, then you need a line: deny Otherwise that which falls through isn't denied, obviously. Doing router filters while fatigued is often a problematic process. Try and work on them when you aren't so tired, unlike me when I sent my first mail 8-) -george william herbert gherbert@crl.com
George Herbert writes:
Simple for Livingstons...
create a filter "internet.out" Contents: three lines for each net block you have:
permit 1.2.3.4/20 tcp permit 1.2.3.4/20 udp permit 1.2.3.4/20 icmp
Actually, a single "permit 1.2.3.4/20" line will do. In Livingston command line syntax: set filter internet.out 1 permit 1.2.3.4/20
final line to log (optional) MUST COME AFTER permit list for netblocks: deny log
The final line will have the router syslog a message any time someone tries to send from an address outside your blocks, as defined in the rest of the filter. This is optional. Keep in mind that the panix attack would probably have flooded your syslog machine's disk space with syslog info in this case. Hardening that is an issue for another day, however.
Logging denies will fill up your log anyway. Packets arriving for a dialup user after he/she hangs up fall through to the default route back out of the box. They are then _outbound_ packets with source address off the network and destination address on the network. Dialup providers who want to log denies based on a source address being on their network should have a preceding unlogged deny based on the destination address being on their network: set filter internet.out 1 permit 1.2.3.4/20 set filter internet.out 2 deny 0.0.0.0/0 1.2.3.4/20 set filter internet.out 3 deny log -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Albany/Saratoga/Glens Falls/North Creek/Lake Placid/Blue Mountain Lake First Internet service based in the 518 area code
George Herbert writes:
Simple for Livingstons...
create a filter "internet.out" Contents: three lines for each net block you have:
permit 1.2.3.4/20 tcp permit 1.2.3.4/20 udp permit 1.2.3.4/20 icmp
Actually, a single "permit 1.2.3.4/20" line will do. In Livingston command line syntax: set filter internet.out 1 permit 1.2.3.4/20
final line to log (optional) MUST COME AFTER permit list for netblocks: deny log
The final line will have the router syslog a message any time someone tries to send from an address outside your blocks, as defined in the rest of the filter. This is optional. Keep in mind that the panix attack would probably have flooded your syslog machine's disk space with syslog info in this case. Hardening that is an issue for another day, however.
Logging denies will fill up your log anyway. Packets arriving for a dialup user after he/she hangs up fall through to the default route back out of the box. They are then _outbound_ packets with source address off the network and destination address on the network. Dialup providers who want to log denies based on a source address being on their network should have a preceding unlogged deny based on the destination address being on their network: set filter internet.out 1 permit 1.2.3.4/20 set filter internet.out 2 deny 0.0.0.0/0 1.2.3.4/20 set filter internet.out 3 deny log -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Albany/Saratoga/Glens Falls/North Creek/Lake Placid/Blue Mountain Lake First Internet service based in the 518 area code
participants (20)
-
Avi Freedman -
Christopher Blizzard -
Craig A. Huegen -
Curtis Villamizar -
David J. Schmidt -
Dick St.Peters -
Erik E. Fair -
Forrest W. Christian -
George Herbert -
Jon Green -
Jonathan Heiliger -
Kent W. England -
Mark A. Fullmer -
Matt Ranney -
Michael Dillon -
Nathan Stratton -
Paul A Vixie -
Perry E. Metzger -
Rashid Karimov -
Tim Bass