From owner-freebsd-isp@FreeBSD.ORG Fri Oct 8 02:21:32 2004 Return-Path: Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795B116A4CE for ; Fri, 8 Oct 2004 02:21:32 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EAFD43D39 for ; Fri, 8 Oct 2004 02:21:32 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id AB0C570DF22; Thu, 7 Oct 2004 23:21:25 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 35452-05; Fri, 8 Oct 2004 02:21:27 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by hub.org (Postfix) with ESMTP id 69AA670DE89; Thu, 7 Oct 2004 22:26:01 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 6C47E3946E; Thu, 7 Oct 2004 22:26:03 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 53E2E391FD; Thu, 7 Oct 2004 22:26:03 -0300 (ADT) Date: Thu, 7 Oct 2004 22:26:03 -0300 (ADT) From: "Marc G. Fournier" To: Cody Baker In-Reply-To: <4165673B.7030805@wilkshire.net> Message-ID: <20041007222434.P935@ganymede.hub.org> References: <20041007120946.K2822@ganymede.hub.org> <416564C8.1080506@wilkshire.net> <4165673B.7030805@wilkshire.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org cc: freebsd-isp@freebsd.org Subject: Re: Reduce effects of DDoS attack ... X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2004 02:21:32 -0000 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