Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

ENH: added multiline filter for sshd filter #457

Merged
merged 2 commits into from Nov 29, 2013

Conversation

Projects
None yet
5 participants
Contributor

grooverdan commented Nov 25, 2013

(from John Thoe on mailing list)

Coverage Status

Coverage remained the same when pulling 227f27c on grooverdan:ssh-multiline into 84f915c on fail2ban:0.9.

@yarikoptic yarikoptic commented on the diff Nov 25, 2013

fail2ban/tests/files/logs/sshd
@@ -117,3 +117,10 @@ Sep 29 17:15:02 spaceman sshd[12946]: Failed password for user from 127.0.0.1 po
# failJSON: { "time": "2004-11-11T08:04:51", "match": true , "host": "127.0.0.1", "desc": "Injecting on username ssh 'from 10.10.1.1'@localhost" }
Nov 11 08:04:51 redbamboo sshd[2737]: Failed password for invalid user from 10.10.1.1 from 127.0.0.1 port 58946 ssh2
+
+
+
+# failJSON: { "match": false }
+Nov 23 21:50:19 sshd[8148]: Disconnecting: Too many authentication failures for root [preauth]
+# failJSON: { "time": "2004-11-23T21:50:37", "match": true , "host": "61.0.0.1", "desc": "Multiline match for preauth failures" }
+Nov 23 21:50:37 sshd[8148]: Connection closed by 61.0.0.1 [preauth]
@yarikoptic

yarikoptic Nov 25, 2013

Owner

looks good to me (and you beat me to remove 2.5 from travis setup ;) ) -- but may be worth adding a test-case where PID would differ thus should not result in the match? just to make sure we would not start banning other connections? also how likely it would be for the same PID to get reused on a busy server thus leading to false positives or there is no other case where "Connection closed by" would appear for some legit connections (please remind me)?

@grooverdan

grooverdan Nov 25, 2013

Contributor

looks good to me (and you beat me to remove 2.5 from travis setup ;) )

np

-- but may be worth adding a test-case where PID would differ thus should not result in the match?

Yep. I did this with sendmail-spam. Waiting for feedback on the mail list to ensure that the pids do match.

also how likely it would be for the same PID to get reused on a busy server thus leading to false positives

Within the same maxlines in the log output? virtually none.

or there is no other case where "Connection closed by" would appear for some legit connections (please remind me)?

Not with an authentication fail match in the came connection.

Coverage Status

Coverage remained the same when pulling b157be2 on grooverdan:ssh-multiline into 84f915c on fail2ban:0.9.

@grooverdan grooverdan merged commit b157be2 into fail2ban:0.9 Nov 29, 2013

1 check failed

default The Travis CI build could not complete due to an error
Details

@grooverdan grooverdan deleted the grooverdan:ssh-multiline branch Nov 29, 2013

I stumbled upon this as I was researching the "too many authentication failure" message which currently hammer my logs. It's good to see that multi-line matching is going into 0.9. However I'm not sure the new filter would be effective to trigger a ban in the SSH case. Am I correct in that PIDs are used to establish the connection between an IP-containing log entry and the "too many auth. failures" entries? The "prefix" group seems to imply this. However, with my OpenSSH 6.4p1-1, the "connection closed" PID and the "too many failure" PIDs are -- contrary to the new filter tests -- never the same.

After all, the "too many auth. failures" message also states "disconnecting", so it would make sense to assume that the process exited at that point.

[...] # hundreds of auth. attempts
Dec 28 20:21:59 eigengrau sshd[8923]: Disconnecting: Too many authentication failures for root [preauth]
Dec 28 20:22:11 eigengrau sshd[8925]: Disconnecting: Too many authentication failures for root [preauth]
Dec 28 20:22:19 eigengrau sshd[8929]: Disconnecting: Too many authentication failures for root [preauth]
Dec 28 20:22:29 eigengrau sshd[8932]: Disconnecting: Too many authentication failures for root [preauth]
Dec 28 20:25:00 eigengrau sshd[8959]: Connection closed by 1.93.27.46 [preauth]
Contributor

grooverdan commented Jan 4, 2014

Am I correct in that PIDs are used to establish the connection between an IP-containing log entry and the "too many auth. failures" entries?

Yes

I'm having trouble reproducing the log messages.

Can you take a clone on the github repository.

git checkout 0.9; export PYTHONPATH=pwd;
(note pwd is in backtick quotes) and then bin/fail2ban-regex /var/log/ssh.log config/filter.d/sshd.conf and see if it does match.

I'm having trouble reproducing the log messages.

Do you mean that sshd keeps the PID constant in your logs, or are you trying to trigger those logs yourself? I believe what triggers them for me is people offering MaxAuthRetries (default = 6) invalid public keys within a single session. After this the connection is dropped and the new connection will have a new PID, thus circumventing the idea of the multi-line filter. :( Otherwise multi-line filtering is a great feature, but the new SSHd rule won't work.

Accordingly, fail2ban-regex (-m "systemd-journal") on 0.9 gives me no hits at all for the new "too many auth. failures" rule.

Contributor

kwirk commented Jan 5, 2014

I've got some similar lines, although very few:

$ journalctl --since "2013-12-29 21:00:00" --until "2013-12-29 22:00:00" -a _COMM=sshd
Dec 29 21:27:21 host sshd[20498]: User root not allowed because account is locked
Dec 29 21:27:21 host sshd[20498]: input_userauth_request: invalid user root [preauth]
Dec 29 21:27:23 host sshd[20498]: Disconnecting: Too many authentication failures for root [preauth]

There was no other attempts in this example ±30mins, but regardless there certainly isn't any information on the IP address this came from 😦
Seems that the regex does indeed not work as PID changes, and on its own, there is no IP information…

I don't suppose too much will come off it, but I've filed a bug with OpenSSH to always include the remote host in auth failure log messages.

https://bugzilla.mindrot.org/show_bug.cgi?id=2199

Contributor

kwirk commented Feb 12, 2014

from helmut on IRC:


hi. I ran into #457 as well, but I would like to suggest a partial remedy. have a look at http://bugs.debian.org/417136. once you raise LogLevel to VERBOSE you get this: http://paste.debian.net/81607/ observe how the pids match now.

would it be worth to add the paste as a testcase? that would at least make fail2ban work with a verbose sshd until https://bugzilla.mindrot.org/show_bug.cgi?id=2199 is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment