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: Riemann . <rie...@gm...> - 2016-09-08 14:39:35
|
Thanks Christian. We only use Windows servers in production, so I haven't tried this under Unix. It might be that this specific behavior is specific to the Windows install (which probably isn't the most typical for ModSec users). I appreciate your suggestions--and I'll definitely look into using a custom Apache log and trying to parse and alert on that as an alternative option. On Thu, Sep 8, 2016 at 8:08 AM, Christian Folini < chr...@ne...> wrote: > Hello Riemann, > > The SDBM access tends to become fragile under high pressure. I have not > really seen the sort of behaviour which you describe, but I am by no > means surprised. Have you tried it under unix? Maybe that makes > difference - or maybe it's just a prejudice against the stability of > the core turning on Windows. > > If you try out the lua option which you outlined, then please keep us > posted about the progress of the project. > > Generally, I agree that ModSecurity on an Apache Reverse Proxy is the > better option than fixing the DoS within the application. But it's still > not really optimal. I think ModSec can be the sensor, but the logic is > better located outside Apache. > > You could pull this off as follows: You have Apache write a custom log > with the IP and the username. Then you have an external process monitor > that log and if it finds any suspicious IP address, then you blacklist > it immediately on the firewall. > > As immediate steps against DoS on the login: > - Enforce the correct referer for the POST > - Make the client eat a cookie first and check for the > cookie in the POST > - Temporary captcha (during the attack) > > Good luck! > > Cheers, > > Christian > > > On Wed, Sep 07, 2016 at 06:01:28PM -0500, Riemann . wrote: > > Hi Barry, > > > > Thanks for your response and the link to the previous discussion. I do > see > > the error you mentioned in my debug log. > > > > This is a bummer. In the ModSec Handbook, Ivan seems to infer the > > double-retrieve/write-lock mechanism should prevent race conditions with > > numerical data being stored (pg 129-130), but this just doesn't seem to > be > > the case. > > > > Maybe this is a bad idea, but as an alternative to using persistent > > storage, would it be crazy to try to implement some of these rules by > > passing variables to a Lua script that reads from and writes to an > > instance-specific SQLite or enterprise-class database? Are there any > other > > ideas as to how this can be acheived? > > > > Of course, it would be ideal to integrate some of these types of things > > directly into the application, but it's a lot faster to turn rules out > with > > ModSec, than to try to get them fit into a release cycle that may be a > few > > months (or more away), depending on development's other priorities. > > > > Thanks, > > Riemann > > > > > > > > On Wed, Sep 7, 2016 at 4:29 PM, Barry Pollard <bar...@ho... > > > > wrote: > > > > > Are you seeing any errors like this in your logs?: > > > > > > Message: collections_remove_stale: Failed deleting collection > > > > > > I'm really not convinced this works using disk based collections file - > > > especially under stress (like brute force attacks). So ultimately don't > > > think ModSecurity is right solution for this - at least until a better, > > > memory based collections store is available. > > > > > > See more details when this was discussed before on this list here: > > > https://sourceforge.net/p/mod-security/mailman/message/34392875/ > > > > > > Thanks, > > > Barry > > > > > > On 7 Sep 2016, at 22:05, Riemann . <rie...@gm...> wrote: > > > > > > Hello, > > > > > > I'm trying to write rules to track and log (not block) brute force > login > > > attempts. I've initialized the Global and IP collection in CRS_10, and > have > > > created a separate rule/config file for horizontal brute force > attempts. > > > I've included my attempt at a horizontal brute force rule below ("rule > > > one"). The rule works exactly as I'd expect if I use Burp Intruder to > > > simulate a brute force attack, sending POST requests to login.jsp, with > > > "username" and "password" parameters in the request body, and changing > only > > > the username on each request. > > > > > > If I run the exact same 'attack,' but this time with five threads, I > run > > > into problems. My counter may equal '1' for five consecutive requests, > and > > > then jump to '6', but only show two usernames are stored in IP.username > > > (for example). I've also tried using rules similar to the horizontal > brute > > > force rules in The Web Application Defender's Cookbook (recipe 7-2, pg > > > 269-271), and found I had similar issues with multi-threaded attacks > for > > > those rules too. > > > > > > I know SDBM allows for concurrent access, and I've read (and re-read) > > > about how collections work in Chapter 8 of the ModSecurity Handbook > > > (including the parts about storing non-numeric values in SDBM, and race > > > conditions). In light of that I've attempted to use only numeric > values by > > > eliminating all stored variables except the counter, as seen in "rule > two" > > > below (and completely eliminating the tracking of unique usernames). > Still, > > > I had issues where multi-threading a brute force attack resulted in the > > > counter value not being correct for several requests in a row. > > > > > > So my questions: > > > > > > 1. Am I missing something, or doing something fundamentally wrong in > > > how I'm using persistent storage? > > > 2. I realize the potential for race conditions with SDBM, especially > > > with non-numeric data, but is what I'm describing entirely expected > > > behavior? Numeric values in persistent storage seem to be fairly > unreliable > > > on a per-request basis (in logs, my counter is wrong more than it > is right). > > > 3. Is there a better approach to accomplish what I'm trying to do, > > > which is track horizontal (by IP addr and username), and eventually > > > vertical (by IP addr and password hash) brute force attempts? For > example, > > > using Lua, or some other persistent storage mechanism (memcached > isn't an > > > option). > > > > > > If it matters, I'm currently testing with ModSec 2.9.1 on Apache > 2.4.23, > > > running on Windows. > > > > > > Thanks, > > > Riemann > > > > > > ######################################## > > > # 'Rule' One # > > > ########### > > > > > > SecRule REQUEST_FILENAME "!@pm login.jsp" \ > > > "phase:2,t:none,pass,nolog, \ > > > id:999321, \ > > > skipAfter:END_BRUTE_FORCE" > > > SecRule REQUEST_METHOD "!@streq POST" \ > > > "phase:2,t:none,pass,nolog, \ > > > id:999322, \ > > > skipAfter:END_BRUTE_FORCE" > > > > > > SecRule ARGS:username|ARGS:user ".+" \ > > > "chain,phase:2,t:none,t:lowercase,pass,nolog, \ > > > id:999323, \ > > > skipAfter:LOGIN_TEST" > > > SecRule ARGS:password|ARGS:pass ".+" \ > > > "t:none,t:lowercase" > > > > > > SecAction \ > > > "phase:2,pass,nolog, \ > > > skipAfter:END_BRUTE_FORCE, \ > > > id:'1000950'" > > > > > > SecMarker LOGIN_TEST > > > SecRule IP:username_ct "@ge 5" \ > > > "phase:5,t:none,log,pass, \ > > > id:'1000951', \ > > > msg:'Multiple Username Violation - Too Many Usernames Submitted from > > > %{REMOTE_ADDR}.' \ > > > logdata:'Usernames Attempted Count: %{IP.username_ct}, Attempted > > > Usernames: %{IP.username}.', \ > > > setvar:IP.clear_username=1" > > > SecRule &IP:CLEAR_USERNAME "@eq 1" \ > > > "phase:5,pass,nolog, \ > > > id:'1000952', \ > > > setvar:!IP.KEY" > > > SecRule &IP:username_ct "@eq 0" \ > > > "chain,phase:2,pass,nolog, \ > > > id:'1000953'" > > > SecRule ARGS:username|ARGS:user ".+" \ > > > "t:none,t:lowercase, \ > > > setvar:IP.username_ct=+1, \ > > > expirevar:IP.username_ct=300, \ > > > setvar:IP.username=%{matched_var}, \ > > > expirevar:IP.username=300" > > > > > > SecRule &IP:username_ct "@ge 1" \ > > > "chain,phase:2,pass,nolog, \ > > > id:'1000954'" > > > SecRule ARGS:username|ARGS:user "!@within %{IP.username}" \ > > > "t:none,t:lowercase, \ > > > setvar:IP.username_ct=+1, \ > > > expirevar:IP.username_ct=300, \ > > > setvar:'IP.username=%{IP.username},%{matched_var}', \ > > > expirevar:IP.username=300" > > > SecMarker END_BRUTE_FORCE > > > > > > ######################################## > > > # 'Rule' Two # > > > ########### > > > > > > SecRule REQUEST_FILENAME "!@pm login.jsp" \ > > > "phase:2,t:none,pass,nolog, \ > > > id:999321, \ > > > skipAfter:END_BRUTE_FORCE" > > > SecRule REQUEST_METHOD "!@streq POST" \ > > > "phase:2,t:none,pass,nolog, \ > > > id:999322, \ > > > skipAfter:END_BRUTE_FORCE" > > > > > > SecRule ARGS:username|ARGS:user ".+" \ > > > "chain,phase:2,t:none,t:lowercase,pass,nolog, \ > > > id:999323, \ > > > skipAfter:LOGIN_TEST" > > > SecRule ARGS:password|ARGS:pass ".+" \ > > > "t:none,t:lowercase" > > > > > > SecAction \ > > > "phase:2,pass,nolog, \ > > > skipAfter:END_BRUTE_FORCE, \ > > > id:'1000950'" > > > > > > SecAction \ > > > "phase:2,pass,log, \ > > > id:'1000959', \ > > > logdata:'Usernames Attempted Count: %{IP.username_ct}.'" > > > SecRule IP:username_ct "@ge 7" \ > > > "phase:2,t:none,log,pass, \ > > > id:'1000951', \ > > > msg:'Multiple Username Violation - Too Many Usernames Submitted from > > > %{REMOTE_ADDR}.' \ > > > logdata:'Usernames Attempted Count: %{IP.username_ct}.', \ > > > setvar:IP.clear_username=1" > > > SecRule &IP:CLEAR_USERNAME "@eq 1" \ > > > "phase:2,pass,nolog, \ > > > id:'1000952', \ > > > setvar:!IP.KEY" > > > SecRule ARGS:username|ARGS:user ".+" \ > > > "t:none,t:lowercase,pass,nolog, \ > > > id:'1000953', \ > > > setvar:IP.username_ct=+1, \ > > > expirevar:IP.username_ct=300" > > > SecMarker END_BRUTE_FORCE > > > > > > ------------------------------------------------------------ > > > ------------------ > > > > > > _______________________________________________ > > > 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/ > > > > > > > > > ------------------------------------------------------------ > > > ------------------ > > > > > > _______________________________________________ > > > 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/ > > > > > > > > > ------------------------------------------------------------ > ------------------ > > > _______________________________________________ > > 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/ > > > -- > https://www.feistyduck.com/training/modsecurity-training-course > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > 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/ > |
