Modsecurity IIS remote_address empty in case of IPv6 address - IPmatch: bad IPv4 specification

[erikvdijk]

Using Modsecurity 2.9.3 with IIS and OWASP-CRS in combination with IPv6, the IPv6 address does not show up in remote_address and thereby always false-positive.

Auditlog: {"transaction":{"time":"24/Dec/2018:10:29:11 +0100","transaction_id":"17221764977212260572","remote_address":"","remote_port":80,"local_address":"127.0.0.1","local_port":80},"request":{"request_line":"GET / HTTP/1.1","headers":{"Connection":"keep-alive","Content-Length":"0","Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","Accept-Encoding":"gzip, deflate","Accept-Language":"nl,en-GB;q=0.7,en;q=0.3","Host":"inter.testipv6.waf","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0","DNT":"1","Upgrade-Insecure-Requests":"1"}},"response":{"protocol":"HTTP/1.1","status":0,"headers":{}},"audit_data":{"messages":["IPmatch: bad IPv4 specification \"\".","Rule processing failed (id=, msg=)."],"handler":"IIS","stopwatch":{"p1":15626,"p2":31254,"p3":0,"p4":0,"p5":0,"sr":0,"sw":0,"l":0,"gc":0},"producer":["ModSecurity for IIS (STABLE)/2.9.3 (http://www.modsecurity.org/)","OWASP_CRS/3.1.0"],"server":"ModSecurity Standalone","engine_mode":"ENABLED"}}

It looks like it is something here: https://github.com/SpiderLabs/ModSecurity/blob/v2/master/iis/mymodule.cpp#L91 https://github.com/SpiderLabs/ModSecurity/blob/v2/master/iis/mymodule.cpp#L123

Or can this be config?

Reproducable on different machines.

[mujiansu]

the function GetIpAddr should provide the ability to handle IPV6, below is my code, it's not fully tested, but worked

char *GetIpAddr(apr_pool_t *pool, PSOCKADDR pAddr)
{
    DWORD addrSize = pAddr->sa_family == AF_INET ? sizeof SOCKADDR_IN : sizeof SOCKADDR_IN6;
    char* buf = (char*)apr_palloc(pool, NI_MAXHOST);
    if (buf == NULL)
        return "";
    buf[0] = 0;
    GetNameInfo(pAddr, addrSize, buf, NI_MAXHOST, NULL, 0, NI_NUMERICHOST);
    return buf;
}

[airween]

I know this is a very old issue, but now a contributor (@A13501350) sent a PR (#3443) which fixes it.

Can we close this one?