Re: [mod-security-users] Working Around Race Conditions in Persistent Storage
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] Working Around Race Conditions in Persistent Storage
|
From: Jose P. V. L. <pab...@gm...> - 2016-09-08 22:56:47
|
In this link you will find a iptables rule for dos prevention: http://blog.bodhizazen.net/linux/prevent-dos-with-iptables/ iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT "Lets break that rule down into intelligible chunks. -p tcp --dport 80 => Specifies traffic on port 80 (Normally Apache, but as you can see here I am using nginx). -m state NEW => This rule applies to NEW connections. -m limit --limit 50/minute --limit-burst 200 -j ACCEPT =>This is the essence of preventing DOS. “--limit-burst” is a bit confusing, but in a nutshell 200 new connections (packets really) are allowed before the limit of 50 NEW connections (packets) per minute is applied." Kind regards El jue., 8 de septiembre de 2016 22:15, Jose Pablo Valcárcel Lázaro < pab...@gm...> escribió: > Hi all. Sorry for not replying during all this time but I was fired from > my job after years of mobbing from work companions. > > There are scripts that protect your server from ddos attacks like this > one: > http://www.fractalizer.ru/frpost_25/linux-installing-automatic-protection-from-dos-and-ddos-attacks-to-your-server/ > > I know that you are talking about dos attacks that are different from ddos > attacks. Anyway time ago you could set in iptables how many times a ip > could reach your server in a frame time and also you can set iptables rules > forcing correct packet receiving so you can avoid fragmentation attacks and > also syn flood attacks. Also there are firewalls able to check ip spoofing > and fase ips, so with all these "screening" like juniper firewalls > screening that you can configure in firewall you can add additional > protection against dos attacks and another attack types. You can search for > those attack types in iptables and add those rules to iptables because > probably those rules are already written (or in firewall-cmd in redhat 7) > > Greetings > > El jue., 8 de septiembre de 2016 22:03, Reindl Harald < > h.r...@th...> escribió: > >> >> >> Am 08.09.2016 um 21:48 schrieb Barry Pollard: >> >> the idea protect a application from DOS attacks by some code inside >> the attacked application is simply a pervert one - is, was and ever will be >> > >> > The idea of protecting the webserver itself from DoS attacks from >> within the webserver is indeed wrong. >> > >> > However the idea of protecting the application (which typically has a >> much lower DoS threshold) using the webserver that sits in front of it is >> not so crazy... >> >> not really - i need to protect my server from accept more requests and >> connections that it can handle, independent of the single application >> >> playing around with some "dos prevention for the poor" inside the >> application *will lower* that numbers by the added overhead >> >> yes, you may have some applications in a mixed load which are more >> problematic, but that won't change the problem bringing persistent >> collections for rate-controls insidne the application layer will have a >> negtaive impact for the whole server >> ___________________________ >> >> most of your problems are solved by rules like below on the application >> host *combined* with a firewall in front with higher bounds to keep away >> real attacks from the server at all >> >> 0 0 DROP tcp -- !lo * 0.0.0.0/0 >> 0.0.0.0/0 ctstate NEW recent: UPDATE seconds: 2 hit_count: >> 100 name: DEFAULT side: source mask: 255.255.255.255 >> 0 0 DROP tcp -- * * !192.168.196.0/24 >> 0.0.0.0/0 tcp flags:0x17/0x02 #conn src/32 > 50 >> 0 0 DROP tcp -- * * !192.168.196.0/24 >> 0.0.0.0/0 tcp flags:0x17/0x02 #conn src/24 > 150 >> 0 0 DROP tcp -- * * !192.168.196.0/24 >> 0.0.0.0/0 tcp flags:0x17/0x02 #conn src/16 > 250 >> 0 0 DROP tcp -- * * !192.168.196.0/24 >> 0.0.0.0/0 tcp flags:0x17/0x02 #conn src/8 > 500 >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: >> http://www.modsecurity.org/projects/commercial/rules/ >> http://www.modsecurity.org/projects/commercial/support/ >> > |
