Some more information about my "quest".The sites are schools in our "district" and all of our Web sites are hosted elsewhere. The attacks are against our main gateway which acts as a DNS server as well.
On Wed, Mar 23, 2016 at 11:32 AM, Chris McEniry <cmcen...@mit.edu> wrote: > Part of the reason DDoS mitigation advice doesn't have a whole lot of > concretes is because it really depends on your own traffic and secondarily > on your attacker - so summarizing them all becomes problematic. DDoS > Mitigation stems from the theoretical question of "How do you only allow > 'good' traffic to make it through?" which means a lot about knowing what is > "good" traffic so that you don't over mitigate it. Practically, the > question usually ends up being "How much do we need to spend so that we can > or could head off a determine/resourced attacker?" Basically, makes it a > whitelist/blacklist approach crossed with . With that said... > > Based on the broad swipe of "sites", I'm going to assume that that means > HTTP/HTTPS based site, and highly recommend you go the way of a CDN > provider (based on "it's one of the things we do"). Even if you don't use > any caching, it'll stave off volumetric bandwidth attacks and most have > some form of L7 scrubbing. "Nobody got fired for going with Akamai" but > I'll also pitch CloudFlare (I work for none of the above). Doing a lot of > others will lead to an arms race if you've got a determined/resourceful > attacker. If you don't, it might make sense to do something as "small" as > applying border ACLs to stop the majority of reflection attacks against > you; or to drop certain regions of traffic that you don't do business with > if that applies. Again "it depends..." > > For the specific, what are others doing... We're using a combination of L7 > reverse proxy provider (aka CDN), a L3/L4 traffic scrubber service, > internal IPS (acting as L3/L4 traffic scrubbers), stateless border ACLs > (letting in only potential good traffic), internal and external L7 traffic > scrubbers (Web Application Firewalls), and a whole variety of home grown > traffic analyzers/scrubbers inside of load balancers and application tier - > as we've seen attacks that can get around any one of the above so we've got > a bunch of layers to our onion. (Can do specifics vendors off thread if you > want...) > > --mac > > PS And just to promote something... > > > https://www.usenix.org/conference/lisa15/conference-program/presentation/matheson > > > > > On 3/23/16 7:45 AM, john boris wrote: > >> Here at $WORK a few of our sites that use the same ISP have been targets >> of DOS attacks at random times. Part of my department handles the >> network to our sites and the ISPs answer has been to just change the >> external IP. Which stems the tide for a bit but it will rear its head >> again in a short time. The attacks continue for a time then stop then >> start up again. >> >> I have been searching the net on this topic but I have not found what I >> am looking for. We are a fledgling group in this area (By way of >> reorganization and decentralization) and as the Grey Beard of the group >> I have taken it on the roll as the person looking for solutions. >> >> What I am looking for is what people have done to try and stave off an >> attack. I know it is a moving target but I am looking for tools that >> help monitoring the traffic to alert us when the traffic gets to a >> certain point, also best practices on setting up a good defense. >> >> I have read a bunch of articles that tell me what to do but I would like >> to see how its done. >> Example: >> 1. Use this tool to monitor traffic >> 2. Setup the firewall this way to this if A happens , B if this IP etc. >> >> If you want to talk offline on this it is fine. I just want to find a >> better way than changing our Public IP for our ISP each time. That just >> strikes me as changing my phoe number to stop crank calls. >> >> Thanks in advance. >> >> -- >> John J. Boris, Sr. >> >> >> >> _______________________________________________ >> Tech mailing list >> Tech@lists.lopsa.org >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >> >> _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > -- John J. Boris, Sr.
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/