ssh new rule to be added #864

octavsly · 2014-11-24T22:55:19Z

The following attack is not detected by fail2ban version 0.9.1 (gentoo)

Nov 24 23:46:39 weurope sshd[32686]: SSH: Server;Ltype: Version;Remote: 121.199.22.83-1780;Protocol: 2.0;Client: libssh2_1.4.3
Nov 24 23:46:40 weurope sshd[32686]: SSH: Server;Ltype: Kex;Remote: 121.199.22.83-1780;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
Nov 24 23:46:41 weurope sshd[32686]: SSH: Server;Ltype: Authname;Remote: 121.199.22.83-1780;Name: root [preauth]
Nov 24 23:46:43 weurope sshd[32686]: fatal: Read from socket failed: Connection reset by peer [preauth]

To detect it I did add in sshd.conf the following:
^.Remote: -.\n.*fatal: Read from socket failed: Connection reset by peer [preauth]$
This needs to be changed to a proper/better regexp.

sebres · 2014-11-25T00:47:39Z

I think, it is not really an attack... (can be just a closed connection);
@octavsly How often do you see it in the log?

But, during I tried to reproduce this situation, I found another one, that will not be detected from f2b:

Nov 25 01:33:13 srv sshd[...]: Received disconnect from <HOST>: 14: No supported authentication methods available [preauth]
Nov 25 01:34:12 srv sshd[...]: Received disconnect from <HOST>: 14: No supported authentication methods available [preauth]

And although without any known regexp of sshd-filter, such "authentication failed/error", "invalid user ...", "User ... not allowed" etc. Just this one line.

yarikoptic · 2014-11-25T02:53:48Z

On Mon, 24 Nov 2014, Serg G. Brester wrote:

I think, it is not really an attack... (can be just a closed connection);
@octavsly How often do you see it in the log?
But, during I tried to reproduce this situation, I found another one, that
will not be detected from f2b:

Nov 25 01:33:13 srv sshd[...]: Received disconnect from : 14: No supported authentication methods available [preauth]
Nov 25 01:34:12 srv sshd[...]: Received disconnect from : 14: No supported authentication methods available [preauth]

And although without any known regexp of sshd-filter, such "authentication
failed/error", "invalid user ...", "User ... not allowed" etc. Just this
one line.

both of those might be relevant for sshd-ddos where for now we have only

failregex = ^%(__prefix_line)sDid not receive identification string from <HOST>\s*$

Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

octavsly · 2014-11-25T06:07:09Z

I see this more than 8000 times. Furthermore,

the address is somewhere in China
I am running a personal server, so I should be the only one logging
I am running on a non standard port (thus not 22)

On November 25, 2014 3:53:51 AM CET, Yaroslav Halchenko notifications@github.com wrote:

On Mon, 24 Nov 2014, Serg G. Brester wrote:

I think, it is not really an attack... (can be just a closed
connection);
@octavsly How often do you see it in the log?
But, during I tried to reproduce this situation, I found another
one, that
will not be detected from f2b:

Nov 25 01:33:13 srv sshd[...]: Received disconnect from : 14:
No supported authentication methods available [preauth]
Nov 25 01:34:12 srv sshd[...]: Received disconnect from : 14:
No supported authentication methods available [preauth]

And although without any known regexp of sshd-filter, such
"authentication
failed/error", "invalid user ...", "User ... not allowed" etc.
Just this
one line.

both of those might be relevant for sshd-ddos where for now we have
only
failregex = ^%(__prefix_line)sDid not receive identification string
from <HOST>\s*$
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

Reply to this email directly or view it on GitHub:
#864 (comment)

sebres · 2014-11-25T08:31:34Z

@yarikoptic both of those might be relevant for sshd-ddos where for now we have only...

I think at least "No supported authentication methods available [preauth]" should be an expression in sshd-filter, because it occurred if I try to connect with invalid method (without key for user with key only or from host not allowed for this user etc.).
Furthermore I don't know how to reproduce an original issue reported @octavsly (strange "chinese" connect). Because the HOST address is not in line with "connection reset..." and sshd has a definitely single line logic. In addition this "second" entry occurred 2 seconds after line with HOST, so the sample multiline regexp given @octavsly is too hazardous - If between this two lines sshd will log some legal activity - it will ban a wrong host or will ban nothing at all.
I know other similar string sshd can produce for such connections, but it contains a host directly in line self:

Nov 25 01:30:57 srv sshd[...]: Received disconnect from <HOST>: Bye Bye [preauth]

octavsly · 2014-11-25T08:58:50Z

An option would be to write a feature request to openssh so they print the host on the same line with the error. Does it make sense?

On November 25, 2014 9:31:39 AM CET, "Serg G. Brester" notifications@github.com wrote:

@yarikoptic both of those might be relevant for sshd-ddos where for now we have only...

I think at least "No supported authentication methods available
[preauth]" should be an expression in sshd-filter, because it occurred
if I try to connect with invalid method (without key for user with key
only or from host not allowed for this user etc.).
Furthermore I don't know how to reproduce an original issue reported
@octavsly (strange "chinese" connect). Because the HOST address is not
in line with "connection reset..." and sshd has a definitely single
line logic. In addition this "second" entry occurred 2 seconds after
line with HOST, so the sample multiline regexp given @octavsly is too
hazardous - If between this two lines sshd will log some legal activity

it will ban a wrong host or will ban nothing at all.
I know other similar string sshd can produce for such connections, but
it contains a host directly in line self:
Nov 25 01:30:57 srv sshd[...]: Received disconnect from <HOST>: Bye Bye
[preauth]
Reply to this email directly or view it on GitHub:
#864 (comment)

sebres · 2014-11-25T11:28:12Z

About sense of adding a host in error case: it would be always good, but I don't think you can get it quickly fixed with simple feature request :)
It make more sense, if at last sshd would log one unique string or prefix after connection failure, no matter why.
Something like:

Nov 25 01:33:13 srv sshd[...]: Failure from <HOST>: <here can be a reason why ...>

Or if sshd gets a system callback (like call_if_fails) with address of failed connection. Then we can self produce a failure for fail2ban.

About a subject self (as long as not fixed) - I believe, it can be an issue/bug by sshd, that can be easy avoided using simple config changes.
Just add to sshd_config a Ciphers should be allowed.
For details about this server "bug", see http://serverfault.com/questions/583355/ssh-issues-read-from-socket-failed-connection-reset-by-peer.

yarikoptic · 2014-11-28T18:28:47Z

@sebres re "unique" string, wouldn't daemon pid (logged as 32686 in the report) suffice?

sebres · 2014-11-28T18:33:13Z

@yarikoptic nope, because sshd will write many success/info messages with the same pid as well.

yarikoptic · 2014-11-29T15:06:21Z

that pid is per connection... if there are success/info msgs we would better ignore that anyways as you have described it is merely up to an sshd config tune up

but once again -- what should we do about it -- add to sshd-ddos? or not even bother at all since might be just a false positive at times

octavsly · 2014-12-13T22:46:47Z

created a feature request at openssh:
https://bugzilla.mindrot.org/show_bug.cgi?id=2327

marcosfrm · 2015-10-02T18:52:33Z

sshd[XXX]: error: Received disconnect from X.X.X.X: 14: No supported authentication methods available [preauth]

My server only allows pubkey auth. This error happens when one knows a valid user name but does not have the key.

I think it should be added.

… that is hard-anchored at end or precise sub expression after <HOST>; new ssh rule(s) added: - Connection reset by peer (multi-line line during authorization process); - No supported authentication methods available; Single line and multi-line expression optimized, added optional prefixes and suffix (logged from several ssh versions); closes fail2bangh-864

sebres · 2015-10-05T19:44:34Z

@octavsly, @marcosfrm tests of #1209 are welcome

… that is hard-anchored at end or precise sub expression after <HOST>; new ssh rule(s) added: - Connection reset by peer (multi-line rule during authorization process); - No supported authentication methods available; Single line and multi-line expression optimized, added optional prefixes and suffix (logged from several ssh versions); closes fail2bangh-864

octavsly · 2015-10-08T09:38:57Z

I have tested the patch with the code present at the beginning of the ticket, and it works.
It does match the HOST.
Thank you.

… that is hard-anchored at end or precise sub expression after <HOST>; new ssh rule(s) added: - Connection reset by peer (multi-line rule during authorization process); - No supported authentication methods available; Single line and multi-line expression optimized, added optional prefixes and suffix (logged from several ssh versions); closes fail2bangh-864

sshd-aggressive (new ssh rules added (gh-864) and code review...)

stevenengland · 2017-01-22T15:01:52Z

Hi there, using the current 0.10 build and running
fail2ban-regex -e UTF-8 /var/log/auth.log /etc/fail2ban/filter.d/sshd-aggressive.conf
to catch all lines with filter regex from sshd.conf
^%(__prefix_line_sl)sReceived disconnect from <HOST>%(__on_port_opt)s: 14: No supported authentication methods available%(__suff)s$
does not recognize lines like

Jan 22 12:27:55 ubuntu sshd[3625]: error: Received disconnect from 192.168.2.92 port 1684:14: No supported authentication methods available [preauth]

The (for testing-purposes) simplified version
^.*<HOST>.*14: No supported authentication methods available.*$
detects it. Can you please have a look?

UPDATE: The problem is the part
%(__on_port_opt)s: 14
The whitespace in front of "14" is too much for the logs like I receive them...

sebres · 2017-01-23T08:00:16Z

Fixed, Thx...

ver. 0.9.7 (2017/05/11) - awaiting-victory ----------- 0.9.x line is no longer heavily developed. If you are interested in new features (e.g. IPv6 support), please consider 0.10 branch and its releases. * Fixed a systemd-journal handling in fail2ban-regex (fail2bangh-1657) * filter.d/sshd.conf - Fixed non-anchored part of failregex (misleading match of colon inside IPv6 address instead of `: ` in the reason-part by missing space, fail2bangh-1658) (0.10th resp. IPv6 relevant only, amend for fail2bangh-1479) * config/pathes-freebsd.conf - Fixed filenames for apache and nginx log files (fail2bangh-1667) * filter.d/exim.conf - optional part `(...)` after host-name before `[IP]` (fail2bangh-1751) - new reason "Unrouteable address" for "rejected RCPT" regex (fail2bangh-1762) - match of complex time like `D=2m42s` in regex "no MAIL in SMTP connection" (fail2bangh-1766) * filter.d/sshd.conf - new aggressive rules (fail2bangh-864): - Connection reset by peer (multi-line rule during authorization process) - No supported authentication methods available - single line and multi-line expression optimized, added optional prefixes and suffix (logged from several ssh versions), according to fail2bangh-1206; - fixed expression received disconnect auth fail (optional space after port part, fail2bangh-1652) and suffix (logged from several ssh versions), according to fail2bangh-1206; * filter.d/suhosin.conf - greedy catch-all before `<HOST>` fixed (potential vulnerability) * filter.d/cyrus-imap.conf - accept entries without login-info resp. hostname before IP address (fail2bangh-1707) * Filter tests extended with check of all config-regexp, that contains greedy catch-all before `<HOST>`, that is hard-anchored at end or precise sub expression after `<HOST>` * New Actions: - action.d/netscaler: Block IPs on a Citrix Netscaler ADC (fail2bangh-1663) * New Filters: - filter.d/domino-smtp: IBM Domino SMTP task (fail2bangh-1603) * Introduced new log-level `MSG` (as INFO-2, equivalent to 18) * tag '0.9.7': (33 commits) Preparing for 0.9.7 release Added newly added files to MANIFEST update ChangeLog filter.d/exim.conf: added new reason for "rejected RCPT" regex: Unrouteable address try to fix travis integration of pypy3: setuptools recently dropped support for Python 3.0 - 3.2, but old pypy3 based on Python 3.2.5 filter.d/exim.conf: cherry-picked from 0.10, match complex time like `D=2m42s` (closes fail2bangh-1766) Update ChangeLog fail2ban#1757 filter.d/exim.conf: optional part `(...)` after host-name before `[IP]`, normalized over whole config file. BF: specify explicit time offset not a time zone name to avoid needing tzdata during testing Update ChangeLog amend resp. restore of change from 59c35bc (fail2bangh-129): - logging of "Log rotation detected" with new MSG level - introduces new log-level MSG (as INFO-2, 18) Update mysqld-auth.conf Update ChangeLog filter.d/cyrus-imap.conf: fixed `failregex` - accept entries without login-info resp. hostname before IP address evil symlink removed: does not supported by some file systems (e. g. development over net share) sshd-amend: optional space after port part suhosin.conf: removed greedy match sshd.conf: fixed expression "received disconnect ... auth fail" - optional space after port part (fail2bangh-1652) change log update after rebase sshd: additionally aggressive filter rules - no matching cipher resp. no matching key exchange method (fail2bangh-1545, fail2bangh-1117) ...

sebres mentioned this issue Oct 5, 2015

sshd-aggressive (new ssh rules added (gh-864) and code review...) #1209

Merged

octavsly closed this as completed Oct 8, 2015

sebres added a commit that referenced this issue Jan 21, 2017

Merge pull request #1209 from sebres/ssh-filter-new-regexp

3ccb026

sshd-aggressive (new ssh rules added (gh-864) and code review...)

ssh new rule to be added #864

ssh new rule to be added #864

octavsly commented Nov 24, 2014

sebres commented Nov 25, 2014

yarikoptic commented Nov 25, 2014

octavsly commented Nov 25, 2014

sebres commented Nov 25, 2014

octavsly commented Nov 25, 2014

sebres commented Nov 25, 2014

yarikoptic commented Nov 28, 2014

sebres commented Nov 28, 2014

yarikoptic commented Nov 29, 2014

octavsly commented Dec 13, 2014

marcosfrm commented Oct 2, 2015

sebres commented Oct 5, 2015

octavsly commented Oct 8, 2015

stevenengland commented Jan 22, 2017 •

edited by sebres

sebres commented Jan 23, 2017

ssh new rule to be added #864

ssh new rule to be added #864

Comments

octavsly commented Nov 24, 2014

sebres commented Nov 25, 2014

yarikoptic commented Nov 25, 2014

octavsly commented Nov 25, 2014

sebres commented Nov 25, 2014

octavsly commented Nov 25, 2014

sebres commented Nov 25, 2014

yarikoptic commented Nov 28, 2014

sebres commented Nov 28, 2014

yarikoptic commented Nov 29, 2014

octavsly commented Dec 13, 2014

marcosfrm commented Oct 2, 2015

sebres commented Oct 5, 2015

octavsly commented Oct 8, 2015

stevenengland commented Jan 22, 2017 • edited by sebres

sebres commented Jan 23, 2017

stevenengland commented Jan 22, 2017 •

edited by sebres