<HOST> expression results in a portion of IPv6 address being matched

[brianjmurrell]

Environment:

• Fail2Ban version (including any possible distribution suffixes): 0.9.3-1.el7
• OS, including release name/version: CentOS 7.2
• Fail2Ban installed via OS/distribution mechanisms
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)

Created my own iptables matching filters but they use to match IP addresses.

The issue:

The current match RE is too generous and ends up matching and returning a portion of an IPv6 address. This results in the following kind of log messages:

2016-03-26 14:39:12,988 fail2ban.filter         [24765]: WARNING Determined IP using DNS Lookup: 2605 = ['0.0.10.45']

The 2605 is the first portion of an IPv6 address.

Steps to reproduce

Create or use any kind of filter with in it and then trigger the filter with an IPv6 address.

Expected behavior

Since IPv6 is not yet supported, IPv6 addresses should be ignored.

Observed behavior

2016-03-26 14:39:12,988 fail2ban.filter         [24765]: WARNING Determined IP using DNS Lookup: 2605 = ['0.0.10.45']

An RE of the format (?:::f{4,6}:)?(?P<host>(\d{1,3}\.){3}\d{1,3}) seems to be much more restrictive about only matching IPv4 addresses.

[sebres]

Currently <HOST> will match not IP addresses only, but also a host name (DNS), therefore I'm assuming, that the expression left-right around <HOST> may be not correct.

Which filter/jail?
Which log entry match this filter (expression)?

[da2x]

Example log entry from httpd that triggers this problem:

2001:db8::dead:e1f - - [17/Apr/2016:12:35:01 +0000] "GET /xmlrpc.php HTTP/1.1" 405 42 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

[sebres]

Well, the fail2ban does not officially support IPv6 currently. A possible "solution" in this direction coming soon (hopefully with #1374, for the master plan see #1123).

[brianjmurrell]

@sebres: So then the match RE should be written to specifically exclude IPv6 addresses. That's kind of the whole reason I opened this ticket.

fail2ban should only be consuming log entries that are IPv4 if it doesn't support IPv6. The fact that fail2ban doesn't yet support IPv6 is a whole other can of worms, but until the years of debate about supporting it can finally be resolved, it needs to ensure that it does not falsely match IPv6 addresses.

[sebres]

I can repeat only, that the whole regular expression you have use is not "good", I mean that our <HOST> should match not IPs only, but hosts, dns (also numerical, because are legal). In your case it is any greedy catch-all, not anchored or something similar, what eats the part of IPv6 before or hereafter.
That is evil, not the HOST expression self.

So I ask AGAIN:

• Which filter/jail (or your custom regex)?
• Which log entry match this filter (expression)?

[brianjmurrell]

OK. So my regex is no good. That doesn't change the nature of this ticket, that the current <HOST> expression is matching portions IPv6 address and returning those, resulting in bad bans.

I would request that the ticket be reopened on that basis.

[sebres]

Improve your expression around <HOST> and it will not "matching portions IPv6 address".

I've wrote already 2 times, that <HOST> matches not IPs only, but hosts also, example:
abcd or 1234 are both legal hosts, and at the same time a portion of IPv6. But only if the expression left and right around <HOST> is even not good.

So I don't see any occasion, to reopen this issue.

BTW. We've a new branch 0.10, that support IPv6 addresses, so these would be also banned there.
The expression is more complex as in 0.9 and can be easy ported (without IPv6 part) to master, but as already said - it's all other reason (even to match IPv6).

I emphasize: the issue is because your expression allows <HOST> to match a portion.

[yarikoptic]

BTW, since we should care to match hostname only if usedns is set, and in general we should not rely on hostnames, I wondered if we should change the default in 0.10 to not do name resolving, and use more specific regex for HOST if usedns is false?

On May 14, 2016 11:10:46 AM EDT, "Serg G. Brester" notifications@github.com wrote:

Improve your expression around <HOST> and it will not "matching
portions IPv6 address".

I've wrote already 2 times, that <HOST> matches not IPs only, but
hosts also, example:
abcd or 1234 are both legal hosts, and at the same time a portion
of IPv6. But only if the expression left and right around <HOST> is
even not good.

So I don't see any occasion, to reopen this issue.

BTW. We've a new branch 0.10, that support IPv6 addresses, so these
would be also banned there.
The expression is more complex as in 0.9 and can be easy ported
(without IPv6 part) to master, but as already said - it's all other
reason (even to match IPv6).

I emphasize: the issue is because your expression allows <HOST> to
match a portion.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1375 (comment)

Sent from a phone which beats iPhone.

[sebres]

The extenstion of regex for HOST was required:

• to match an IPv6, so add : to regex, but...
• to not match :port together with IPv4

How it was done, you can see here:
https://github.com/fail2ban/fail2ban/blob/0.10/fail2ban/server/failregex.py#L76

[sebres]

Where indeed, would be not bad to have a HOST dependent on usedns, resp. at all configurable in [DEFAULT] or even per jail (I've already a todo);