Re: [mod-security-users] RBL lookup/block not working
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] RBL lookup/block not working
|
From: Christian B. <ch...@jw...> - 2016-07-20 12:45:25
|
Hi Riemann, Robert is probably right. You need to redirect any DNS requests of your ModSecurity machine, which is related to "rbl.localnet" to the jwall-rbld server. It is quite tricky to do this without the help of software like dnsmasq. I've created a new version of jwall-rbld, which now allows for forwarding all queries to some "real DNS server", such as 8.8.8.8 (default), but intercepts queries to "rbl.localnet" to check these against its internal RBL list. This version can be found at https://download.jwall.org/jwall-rbld/0.5/ It is sort of a beta-testing release. So any bug reports would be helpful. Starting this version on port 53 and settings the "forward=8.8.8.8" property in the configuration file will provide you with a local (non-caching) DNS server that recognizes "rbl.localnet" or whatever your configured RBL domain is, to match the block list. With this version of jwall-rbld running, you need then to use it as your primary DNS server. Feel free to test this and drop me a line if you need further help. Best regards, Chris > Am 20.07.2016 um 01:08 schrieb Robert Paprocki <rpa...@fe...>: > > @RBL lookups use the DNS servers defined on your host (via /etc/resolv.conf on linux machines, and via the network config nonsense that is windows). Those resolvers need to be configured to forward as appropriate (e.g. using something like 8.8.8.8 probably wont work). > > How are you testing via dig? What commands are you sending? How about testing via tcpdump - what DNS traffic do you see to and from your system? How is that different via your manual dig tests? > > On Tue, Jul 19, 2016 at 1:46 PM, Riemann . <rie...@gm...> wrote: > Trying to troubleshoot further, I tried to simplify what I'm doing by using the following rule from "The Web Application Defender's Cookbook" near the top of both my CRS_15 and at the end of my CRS_48 file: > > SecRule REMOTE_ADDR "@rbl rbl.localnet" "id:'999027',phase:1,deny,status:403,log,msg:'Client denied by local RBL!'" > > I can send dig requests to block and query jwall-rbld, and everything works as expected with jwall-rbld when testing manually. ModSec continually shows this in the debug log: "RBL lookup of 29.255.17.172.rbl.localnet failed at REMOTE_ADDR." I've manually issued the same request via dig and it works fine. It really seems like the request isn't getting sent by ModSec. Does anyone else have a local RBL working in Windows? Is there any other configuration required within ModSec, besides the rule itself? I do have a GPO applied that prevents inbound requests for all be a few remote hosts and ports (via Windows Firewall), but it doesn't seem to affect localhost connections (e.g. I can hit Apache w/o issue). > > Again, outside of ModSec, I have DNS cache service stopped, Unbound.exe configured to forward DNS requests for localnet to jwall-rbld port 15353, and I'm allowing 127.0.0.1 and ::1 to query, block and unblock via the jwall-rbld config. I'm testing on Windows 7, with ModSec 2.8 binaries. > > Thanks in advance for any help. This has been driving me crazy! > > On Mon, Jul 18, 2016 at 1:07 PM, Riemann . <rie...@gm...> wrote: > I'm working on setting up a RBL using Christian Bockermann's jwall-rbld. I've turned off the Windows DNS Client service, installed Unbound locally (Windows) and used it to forward requests to jwall-rbld (which is running on localhost for now). The jwall config file allows localhost to update (e.g. block/unblock) via dig request. Everything with jwall-rbld works as expected when used manually (e.g. via dig/telnet from terminal). > > > I don't know if this is the issue, but instead of IP addresses or hostnames, I'm trying to add hexEncoded sha1 hashes to the RBL. I'm basically trying to create a way to share data between nodes without setting up a memcached server. Again, this all works manually (using telnet or dig I can lookup, block and unblock based on a hash entry). > > > An example of the rules I'm using look something like this: > > ... > SecRule ARGS:Foobar ".*" "phase:2,log,pass,msg:'Hashing data',t:sha1,t:hexEncode,setvar:tx.hash=%{matched_var},id:'1000805'" > SecRule tx:hash "@rbl rbl.localnet" "phase:2,log,pass,logdata:'%{tx.hash}',skipAfter:GO_TO_NEXT,id:'1000806'" > SecRule tx:hash "@rbl block-600.rbl.localnet" "phase:2,log,pass,id:'1000807'" > SecMarker GO_TO_NEXT > ... > > From the debug, I can see both lookups (1000806 and 1000807) fail. Using Microsoft Message Analyzer, it appears the requests is never being sent from ModSecurity. > > ------------------------ [[ debug log ]] -------------------------------------- > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][9] Match -> mode NEXT_RULE. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Recipe: Invoking rule 2cad328; [file "C:/shared/Apache2x/conf/modsecurity/0-48/modsecurity_crs_15_customrules.conf"] [line "64"] [id "1000806"]. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][5] Rule 2cad328: SecRule "tx:hash" "@rbl rbl.localnet" "phase:2,log,logdata:%{tx.hash},skipAfter:GO_TO_NEXT,id:1000806" > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Transformation completed in 0 usec. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Executing operator "rbl" with param "rbl.localnet" against TX:hash. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][9] Target value: "febfe593c825cd16f1db113833eb02e0a4be4fe1" > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][5] RBL lookup of febfe593c825cd16f1db113833eb02e0a4be4fe1.rbl.localnet failed at TX:hash. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Operator completed in 117606 usec. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Rule returned 0. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][9] No match, not chained -> mode NEXT_RULE. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Recipe: Invoking rule 2cae818; [file "C:/shared/Apache2x/conf/modsecurity/0-48/modsecurity_crs_15_customrules.conf"] [line "65"] [id "1000807"]. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][5] Rule 2cae818: SecRule "tx:hash" "@rbl block-600.rbl.localnet" "phase:2,log,pass,id:1000807" > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Transformation completed in 0 usec. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Executing operator "rbl" with param "block-600.rbl.localnet" against TX:hash. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][9] Target value: "febfe593c825cd16f1db113833eb02e0a4be4fe1" > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][5] RBL lookup of febfe593c825cd16f1db113833eb02e0a4be4fe1.block-600.rbl.localnet failed at TX:hash. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Operator completed in 127804 usec. > [13/Jul/2016:17:07:22 --0500] [computer_name/sid#3caefa0][rid#41c5220][/C30008_tsa/tapp][4] Rule returned 0. > ---------------------- [[ end debug log ]] ------------------------------------ > > I realize this is not a typical use case. From the debug it appears the lookup is formed correctly, so I'm hoping it's a misconfiguration/error on my part and not just that ModSec is limited to using predefined server variables like REMOTE_ADDR. Any input or suggestions would be more than welcome. I've fought this for three days last week, before figuring I'd ask for help. > > Thanks! > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > 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/ > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev_______________________________________________ > 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/ |