Date: Thu, 7 Oct 2004 22:26:03 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Cody Baker <cody@wilkshire.net> Cc: freebsd-isp@freebsd.org Subject: Re: Reduce effects of DDoS attack ... Message-ID: <20041007222434.P935@ganymede.hub.org> In-Reply-To: <4165673B.7030805@wilkshire.net> References: <20041007120946.K2822@ganymede.hub.org> <416564C8.1080506@wilkshire.net> <4165673B.7030805@wilkshire.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually, found out earlier today that this does, in fact, appear to be closer to the problem ... MS-SQL servers taht were infected by virii were on the network that was flooding us ... so what you describe below sounds like what probably happened :( On Thu, 7 Oct 2004, Cody Baker wrote: > Another little note: Are you absolutely positive that the other network is > clean and not the cause rather than the victim. We had a computer in our PC > repair bay that a technician accidentally cconnected to the web before a > virus scan. It had a virus which ran a syn flood against some gaming > website. It was horrendously difficult to track down because it created a > MASSIVE amount of traffic. This traffic which is bleeding over could be ARP > traffic from a virus scanning through subnets. It would generate one ARP > request for every IP address it attempts to contact, a scary thought when you > have a virus scanning a few thousand IPs/second. This huge amount of ARP > traffic would be very detrimental to your router as well.. > > Thank you, > > Cody Baker > cody@wilkshire.net > 330.934.0659 > http://www.wilkshire.net > > > Cody Baker wrote: > >> The packets your 200.046.204 machines are receiving are most likely ARP >> packets, which are Ethernet level broadcast. They can't really be stopped >> with out dividing the physical network in to two pieces or VLANs. If your >> router supports VLANs, you can divide your subnet to one portion of that >> catalyst switch, and the offending network to another portion. This is a >> good policy in terms of security, but it's not going to fix your problem. >> Unless you're extremely well connected to the Internet (something greater >> than 10MB/s), you're problem has nothing to do with anything on your >> network, rather the pipe between your network and the world is just >> congested. The other possibility is that your router isn't able to keep up >> with the load. I would suggest that your best bet is to talk to your >> upstream provider, see if they can't block the attack in anyway. >> >> In regards to Matthew's response, the Cisco switch should be capable of >> handling all but the most intense attacks. In terms of the Linksys, the >> only thing it's going to be seeing is the ARP packets, and while those >> network wide broadcasts are detrimental, they're not going to be the cause >> of 70% packet loss. >> >> Thank you, >> >> Cody Baker >> cody@wilkshire.net >> 330.934.0659 >> http://www.wilkshire.net >> >> Marc G. Fournier wrote: >> >>> >>> I've got 5 servers sitting on a 10/100 unmanaged switch right now ... last >>> night, a DDoS attack against a network "beside us" cause 70+% packet loss >>> on our network, and I'm trying to figure out if there is anything I can do >>> from my side to "compensate" for this ... >>> >>> I run ipaudit on all our servers, and a normal 30 minute period looks >>> like: >>> >>> neptune# gzcat 2004-10-06-22:00.txt.gz | grep 200.046.204 | wc -l >>> 12107 >>> neptune# gzcat 2004-10-06-22:00.txt.gz | grep -v 200.046.204 | wc -l >>> 112 >>> neptune# gzcat 2004-10-06-22:00.txt.gz | wc -l >>> 12219 >>> >>> where 200.046.204 is our C-class ... >>> >>> Now, when the DDoS attack is running, those stats change to: >>> >>> neptune# gzcat 2004-10-06-17:30.txt.gz | grep 200.046.204 | wc -l >>> 5815 >>> neptune# gzcat 2004-10-06-17:30.txt.gz | grep -v 200.046.204 | wc -l >>> 594189 >>> neptune# gzcat 2004-10-06-17:30.txt.gz | wc -l >>> 600004 >>> >>> We're getting *alot* of traffic on our network that just is not ours ... >>> >>> Now, I can login to the servers, and load is negligible ... but packet >>> loss is anywhere from 50->90%, so pretty much unusable ... >>> >>> Now, the shared 'switch' between our networks is a Cisco Catalyst 2900xl >>> ... is there something that should be set on that so that I don't see that >>> network traffic? Basically, the only network traffic that I should/want >>> to see is that for my network .. in this case, 200.46.204? >>> >>> Baring that ... is there anything that I can do on the FreeBSD side of >>> things to reduce the impact of the "extra packets"? Some way of >>> "absorbing them"? For instance, if the packet is coming in, and it isn't >>> for that server, then I imagine it has to 'bounce' it back out again, >>> compounding the problem, no? >>> >>> Also ... since the FreeBSD servers do seem to be handling the load, is it >>> possible that the unmanaged switch that i have in place between the >>> FreeBSD box and the Cisco switch is 'buckling under the load'? Not able >>> to handle the packets fast enough, and therefore just drop'ng them? >>> >>> The unmanage switch is a 10/100 Linksys Switch ... >>> >>> Thanks for any responses ... >>> >>> ---- >>> Marc G. Fournier Hub.Org Networking Services >>> (http://www.hub.org) >>> Email: scrappy@hub.org Yahoo!: yscrappy ICQ: >>> 7615664 >>> _______________________________________________ >>> freebsd-isp@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-isp >>> To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" >> >> >> >> _______________________________________________ >> freebsd-isp@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-isp >> To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-isp@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041007222434.P935>