mod_security v2 rule doesn't work for IPv6

This forum is only for reproducible bugs with csf and lfd (i.e. not iptables problems, lack of understanding how to use a feature, etc). Posts must be accompanied with full technical details of the problem and how it can be recreated. Any posts not adhering to this, or not considered bugs, will be moved to the General Discussion (csf) forum.
6 posts Page 1 of 1
samedwards
Junior Member
Posts: 7
Joined: 16 Mar 2017, 01:06


The mod_security v2 (apache) regex (line 335 of RegexMain.pm) has a bug that prevents it from working with IPv6 addresses.

The rule matches the first [client] block in the log entry, which contains the source port appended to the client IP. The rule does attempt to remove this source port, but only does so if splitting the IP by the ':' character returns a list of size 2. Obviously, this won't work for an IPv6 address, which will have 7 colons in it (plus the one separating the port from the address). I believe that changing this check to strip the source port to look for a list size of 2 (IPv4) or a list size of 9 (IPv6) should solve the problem and let the rule work as intended for both IPv4 and IPv6.

Thanks,
Sam
ForumAdmin
Moderator
Posts: 1415
Joined: 01 Oct 2008, 09:24


Thank you for reporting this. We'll fix it in the next release.
samedwards
Junior Member
Posts: 7
Joined: 16 Mar 2017, 01:06


Thanks for the quick turnaround on this one. Looking in to this a little more though, there's a problem with my suggestion. Although a full IPv6 address with a source port would be split into a list with 9 elements, contiguous zeros in an IPv6 address can be represented by double colons (::), making no easy check based only on split possible.

I presume that there's a reason for this check in the first place, as sometimes the logs may contain a source port, and sometimes they won't? If that's the case, then the only other simple way I can think of to check this is to see if the number after the colon is a valid source port, but not a valid IPv6 hex group (ie. > 4 digits). But of course a TCP stack can be set to use a source port that would overlap, so again, not foolproof.

I've just now gone waaaaayyyy down the rabbit hole in to the Apache 2.2 and 2.4 source, and it appears that Apache 2.2 does not (and since the error log format can't be changed in 2.2, can never) contain a source port, while 2.4 will always contain it, even if the format is customized, as the format string contains both. Still though, that doesn't really get us any further unless there's another tell in the log line of Apache 2.2 vs 2.4.
ForumAdmin
Moderator
Posts: 1415
Joined: 01 Oct 2008, 09:24


It is indeed a rabbit hole. I may look into assuming that there will be a port and test for a valid PUBLIC IPv6 from the result. It may be the case that it could have problems with Apache v2.2. We'll look into it further.
ForumAdmin
Moderator
Posts: 1415
Joined: 01 Oct 2008, 09:24


Hopefully v11.04 should now address this:
https://blog.configserver.com
samedwards
Junior Member
Posts: 7
Joined: 16 Mar 2017, 01:06


Thanks, this looks good to me!
6 posts Page 1 of 1