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.conf > > 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
