Reduce effects of DDoS attack ...

Thu Oct 7 19:21:32 PDT 2004

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 at 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 at 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 at hub.org           Yahoo!: yscrappy              ICQ: 
>>> 7615664
>>> _______________________________________________
>>> freebsd-isp at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
>>> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>> 
>> 
>> 
>> _______________________________________________
>> freebsd-isp at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
>> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>
>
> _______________________________________________
> freebsd-isp at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy at hub.org           Yahoo!: yscrappy              ICQ: 7615664