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 20:15:56
|
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/ > |
