Hi Joao, On Sat, Dec 14, 2019 at 11:30 PM Joao Morais <[email protected]> wrote:
> > > > Em 13 de dez de 2019, à(s) 10:09, Christopher Faulet < > [email protected]> escreveu: > > > > Le 10/12/2019 à 05:24, Igor Cicimov a écrit : > >> > >> Testing with Haproxy 2.0.10 but same result with 1.8.23. The versions > of ModSecurity is 2.9.2 and the OWASP rules v3.0.2 > >> What am I doing wrong? Can anyone provide a request that should confirm > if the module is working or not from or share the experience from their own > setup? > > > > Hi Igor, > > > > First of all, I don't know how the modsecurity agent really work. But > I'm surprised to see it returns -101. In the code, -1, 0 or an HTTP status > code is expected. And only 0 or the HTTP status code is returned to > HAProxy. I don't know if -101 is a valid return value from modsecurity > point of view. But it is not from the agent one. > > > > Then, You don't have an error 403 because the variable txn.modsec.code > is negative, so the deny http-request rule is never triggered. So, I guess > your error 400 comes from your webserver. You can enabled HTTP log to have > more information. > > > > Finally, I notice some requests to the SPOA agent seems to have failed. > The variable is not set (- in the logs). You can try to enable SPOE logs in > your SPOE engine configuration. Take a look at the SPOE documentation > (doc/SPOE.txt) for more information. > > > Hi, perhaps this thread helps: > > https://www.mail-archive.com/[email protected]/msg30061.html > > And perhaps this building of ModSecurity SPOA will also help: > > > https://github.com/jcmoraisjr/modsecurity-spoa/blob/v0.5/rootfs/Dockerfile > > ~jm > First thanks for your reply, I've been following your work on haproxy-ingress for Kubernetes (where I can see you have incorporated ModSecurity) and your input is certainly appreciated on this matter. I had some time today to quickly run the test again after enabling the log for SPOE: [modsecurity] spoe-agent modsecurity-agent log global messages check-request option var-prefix modsec option continue-on-error timeout hello 100ms timeout idle 30s timeout processing 1s use-backend spoe-modsecurity spoe-message check-request args unique-id method path query req.ver req.hdrs_bin req.body_size req.body event on-frontend-http-request and can see that the empty values coming from SPOE are legit and are due to SEARCH method that is not allowed by Haproxy: Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.accept(000a)=0016 from [127.0.0.1:53206] ALPN=<none> Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.clireq[0016:ffffffff]: SEARCH / HTTP/1.1 Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.clihdr[0016:ffffffff]: user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.clihdr[0016:ffffffff]: content-type: application/x-www-form-urlencoded Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.clihdr[0016:ffffffff]: content-length: 1 Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.clihdr[0016:ffffffff]: host: localhost:9080 Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001343:my-front.srvcls[0017:0013] Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001343:my-front.clicls[0017:0013] Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001343:my-front.closed[0017:0013] Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.srvrep[0016:0013]: HTTP/1.1 405 Method Not Allowed Dec 17 00:40:01 ip-172-31-17-121 haproxy[21508]: SPOE: [modsecurity-agent] <EVENT:on-frontend-http-request> sid=4933 st=0 0/0/0/0/0 4/4 0/0 0/2768 Dec 17 00:40:01 ip-172-31-17-121 haproxy[21508]: The txn.modsec.code is: - Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.srvhdr[0016:0013]: server: ecstatic-3.3.2 Dec 17 00:40:01 ip-172-31-17-121 haproxy[21508]: The txn.modsec.code is: - Dec 17 00:40:01 ip-172-31-17-121 haproxy[21508]: SPOE: [modsecurity-agent] <EVENT:on-frontend-http-request> sid=4935 st=0 0/0/0/0/0 4/4 0/0 0/2769 Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.srvhdr[0016:0013]: date: Tue, 17 Dec 2019 00:40:01 GMT Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.srvhdr[0016:0013]: content-length: 0 Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.srvcls[0016:0013] Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.clicls[0016:0013] Dec 17 00:40:01 ip-172-31-17-121 haproxy[17468]: 00001345:my-front.closed[0016:0013] and some other methods like TRACK, PROPFIND, DEBUG that NIkto tries out. Apart from that, I'm still equally stumped as I was before about the rules not working as expected. For example this request: $ curl -I -H "User-Agent: nikto" http://localhost:9080/ HTTP/1.1 200 OK server: ecstatic-3.3.2 cache-control: max-age=3600 last-modified: Wed, 28 Feb 2018 04:52:41 GMT etag: W/"280517-2853-2018-02-28T04:52:41.000Z" content-length: 2853 content-type: text/html; charset=UTF-8 date: Tue, 17 Dec 2019 01:08:58 GMT should return 403 since Nikto is on the list of scanners in OWASP rules: $ grep -i nikto /etc/modsecurity/owasp-modsecurity-crs/rules/scanners-user-agents.data $ https://cirt.net/Nikto2 nikto Regarding the link you sent, I'm seeing the same symptoms that you described in the thread except I do have the SecDefaultAction set in the CRS file. Thanks, Igor
