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

Reply via email to