Ah, right. Sorry, I assumed you already had lrexlib installed. I will update the comments in the modsecurity_crs_41_advanced_filters.conf file for the SecRuleScript line.
Let me know if you run into any more issues and also how the Lua script/rules work. -Ryan On 2/21/11 2:17 PM, "Chris Swanson" <[email protected]> wrote: >Here is the solution to the problem: > >After installing BitOp which Ryan suggested in a previous message >(http://bitop.luajit.org/download.html) we we're still getting the same >error. The Lua script also has a require for rex_pcre, which we were >missing. > >This isn't available out of the Debian repo for Lenny so I've installed >it from the Ubuntu Lucid repo. > >liblua5.1-rex-pcre0_2.4.0-1_amd64.deb >liblua5.1-rex-pcre-dev_2.4.0-1_amd64.deb > >dependencies: > >libpcre3_7.8-3build1_amd64.deb >libpcre3-dev_7.8-3build1_amd64.deb >libpcrecpp0_7.8-3build1_amd64.deb > >Again, here is the original error: > >Unknown | Lua: Script execution failed: attempt to call a nil value >Unknown | Rule processing failed. > >I'm not sure if BitOp and rex_pcre are stated as requirements outside of >the script, but it might be worth adding. (Apologies if I've missed it) > >Thanks again for the assistance. >-Chris > >On Mon, 2011-02-07 at 11:09 -0800, Chris Swanson wrote: >> Hi, we haven't had any luck with this issue, just wondering if anyone >> else has seen this or knows a solution? >> >> Here is the original email and a response follow up with some >> suggestions. >> >> Thanks >> -Chris >> >> >> >> >> On Wed, 2011-01-26 at 16:37 -0800, Chris Swanson wrote: >> > Hi, we're having a hard time with the new update(s) and Lua in our >> > testing environment. Here's the error we're seeing in Audit Console, >> > this is opening up a single transaction: >> > >> > Unknown | Lua: Script execution failed: attempt to call a nil value >> > Unknown | Rule processing failed. >> > >> > >> > This is happening with modsecurity 2.5.13 and modsec CRS 2.1.1 on >> > our >> > Debian 5 servers, apache is configured with: >> > >> > ./configure --prefix=/usr/local/apache --disable-userdir >> > --enable-rewrite --enable-so --enable-info --enable-status >> > --enable-ssl >> > --enable-cgi --enable-unique-id --enable-mime-magic >> > --with-included-apr >> > --with-pcre=/usr/bin/pcre-config --enable-deflate --enable-expires >> > --enable-headers >> > >> > modsecuirty cofigured with: >> > >> > ./configure --with-apxs=/usr/local/apache/bin/apxs >> > --with-apr=/usr/local/apache/bin/apr-1-config >> > >> > >> > I've narrowed it down to the include in our http.conf for >> > modsecurity_crs_41_advanced_filters.conf, which was previously >> > working >> > as the phpids rules. Even further, by commenting out this section at >> > the >> > top of the 41_advanced_filters file everything works fine: >> > >> > # Lua script to normalize input payloads >> > # Based on PHPIDS Converter.php code >> > # Reference the following whitepaper - >> > # http://docs.google.com/Doc?id=dd7x5smw_17g9cnx2cn >> > # >> > SecRuleScript ../lua/advanced_filter_converter.lua >> > "phase:2,t:none,pass" >> > SecRule TX:/centrifuge_ratio/ ".*" >> > "phase:2,t:none,log,capture,msg:'Centrifuge Threshold Alert - Ratio >> > Value is: %{tx.0}'" >> > >> > >> > Here is the modsecurity includes in our http.conf >> > >> > #modsecurity Rules >> > Include conf/modsecurity.conf >> > Include conf/modsecurity-crs_2.1.1/*.conf >> > Include >> > >>conf/modsecurity-crs_2.1.1/experimental_rules/modsecurity_crs_41_advanced >>_filters.conf >> > Include >> > >>conf/modsecurity-crs_2.1.1/optional_rules/modsecurity_crs_25_cc_known.con >>f >> > Include conf/modsecurity-crs_2.1.1/base_rules/*conf >> > >> > >> > With the same setup and versions Modsecurity/Apache, CRS 2.0.10 >> > worked >> > perfectly. We could move forward without Lua functionally, but I'm >> > lost >> > as to why such a big addition would be broken from the get-go. >> > Haven't >> > been able to find anyone posting with a similar issue so any help >> > would >> > be greatly appreciated. >> > >> > >> > Thanks, >> > -Chris >> > >> >> >> > A couple questions - >> > >> > 1) Did you modify the path to Lua in the script to point to your >> local >> > version? >> > 2) Did you install the additional bitop Lua module? >> > http://bitop.luajit.org/ >> > It is specified at the top of the script in a require statement. >> > This >> > is needed for the Octal to Decimal conversions. >> >> I was missing Bitop, I've installed it from source, changed the >> install >> path for Debian, and I believe it's working as we can run the included >> bitbench.lua with no errors. The Lua problem still exists. >> >> > 3) What was the request that triggered this error? >> >> It triggers on any request, the one I've been using the most is >> accessing the page via IP instead of hostname, here's a breakdown of >> all >> the information regarding the request: >> >> ---------------------- >> >> >> Alert Messages: >> The following messages have been raised for this event: >> Severity >> Rule ID >> Message >> UNKNOWN >> >> Lua: Script execution >> failed: attempt to call >> a nil value >> Rule-Message: >> >> UNKNOWN >> >> Rule processing failed. >> Rule-Message: >> >> >> >> Rules Section >> >> The following rules have been fired for this event: >> SecAction phase:1 t:none nolog pass >> setvar:tx.anomaly_score_blocking=on >> SecAction phase:1 t:none nolog pass setvar:tx.critical_anomaly_score=5 >> setvar:tx.error_anomaly_score=4 setvar:tx.warning_anomaly_score=3 >> setvar:tx.notice_anomaly_score=2 >> SecAction phase:1 t:none nolog pass >> setvar:tx.inbound_anomaly_score_level=5 >> SecAction phase:1 t:none nolog pass >> setvar:tx.outbound_anomaly_score_level=4 >> SecAction phase:1 t:none nolog pass setvar:tx.paranoid_mode=0 >> SecAction phase:1 t:none nolog pass setvar:tx.max_num_args=255 >> SecAction phase:1 t:none nolog pass setvar:'tx.allowed_methods=GET >> HEAD >> POST OPTIONS' >> >>setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded >> multipart/form-data text/xml application/xml application/x-amf' >>setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1' >>setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ >>.bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ >>.csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ >>.ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ >>.pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ >>.webinfo/ .xsd/ .xsx/' setvar:'tx.restricted_headers=/Lock-Token/ >>/Content-Range/ /Translate/ /via/ /if/' >> SecRule REQUEST_HEADERS:User-Agent @rx ^(.*)$ phase:1 t:none pass >> nolog >> t:sha1 t:hexEncode setvar:tx.ua_hash=%{matched_var} >> SecAction phase:1 t:none pass nolog initcol:global=global initcol:ip= >> %{remote_addr}_%{tx.ua_hash} >> SecAction phase:4 t:none nolog skipAfter:END_KNOWN_CC_OUTBOUND_CHECK\ >> >> >> Request >> >> GET / HTTP/1.1 >> Host: >> 172.16.100.191 >> Connection: >> keep-alive >> Accept: >> application/xml,application/xhtml >> +xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 >> User-Agent: >> Mozilla/5.0 (X11; U; Linux x86_64; >> en-US) AppleWebKit/534.10 (KHTML, >> like Gecko) Chrome/8.0.552.200 >> Safari/534.10 >> Accept-Encoding: >> gzip,deflate,sdch >> Accept-Language: >> en-US,en;q=0.8 >> Accept-Charset: >> ISO-8859-1,utf-8;q=0.7,*;q=0.3 >> >> >> ---------------------- >> >> > You can still run it in this manner but since it will NOT be >> > normalizing >> > data in the same way as PHPIDS, there will be a higher % of false >> > positives/false negatives. >> > We did put this in the experimental directory after all ;) >> >> True enough! >> >> > Seriously, we >> > need more people to field test this new, advanced functionality. I >> > applaud you for jumping in! Don't give up on it, hopefully we can >> get >> > it >> > working for you. >> > >> > -Ryan >> >> Glad we can help out, we will keep on it until it's resolved. >> >> -Chris >> > >> > >_______________________________________________ >Owasp-modsecurity-core-rule-set mailing list >[email protected] >https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
