Bug#404487: Please improve the ssh regex
Since 0.7.6, approx when it is going to be released? As soon as I finish cleaning the configuration files. Between this evening and tomorrow I hope. I thought that it might be useful to keep it as a separate jail since someone with poor connection might experience 'legal' similar connection drop outs. Also some missconfigured firewalls can lead to similar behavior http://www.vmware.com/community/message.jspa?messageID=253323 I guess those guys will become real unfortunate if they also get banned immediately ;-) I am not sure how that situation is often though... I just want to find agreement/final decision before I upload to Debian to close the bug... Ok, I will add this into a new file. In this case, multiple filter for single jail would be useful. Shouldn't be a problem to implement but I keep this for 0.9 ;) Cheers, Cyril -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
Hi Amaya, (Now, if it was only a bit better documented.. maybe this is where I could return some of the good karma and provide some patches or a quick walkthrough). The wiki is very nice, though. I know that the documentation s*** :( I try to improve it but as I'm not a native English speaker, I take me ages to write something (almost) readable :( And programming is so much interesting than writing documentation ;) But I try to do my best about this. Cheers, Cyril Jaquier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
> >Cyril - find attached a patch to ban ssh-ddos attacks. And indeed, we > >should have some beer together -- users are complaining! ;-) > Since 0.7.6, approx when it is going to be released? > several regular expressions are accepted in "failregex". So I will > simply add the corresponding regular expression to "sshd.conf". Thank > you :) I thought that it might be useful to keep it as a separate jail since someone with poor connection might experience 'legal' similar connection drop outs. Also some missconfigured firewalls can lead to similar behavior http://www.vmware.com/community/message.jspa?messageID=253323 I guess those guys will become real unfortunate if they also get banned immediately ;-) I am not sure how that situation is often though... I just want to find agreement/final decision before I upload to Debian to close the bug... > Yes, we should have some beer together ;) Probably not tomorrow but who > knows!? And don't worry, I drink your part too :P ;-) > >Happy Holidays! Happy Holidays to you too (myself I need to go to court tomorrow to fight traffic ticket... heh heh) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
Hi all, Cyril - find attached a patch to ban ssh-ddos attacks. And indeed, we should have some beer together -- users are complaining! ;-) Since 0.7.6, several regular expressions are accepted in "failregex". So I will simply add the corresponding regular expression to "sshd.conf". Thank you :) Yes, we should have some beer together ;) Probably not tomorrow but who knows!? And don't worry, I drink your part too :P Happy Holidays! Happy New Year! Cheers, Cyril Jaquier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
Hi there, Yaroslav and Cyril, First of all, thanks for the terribly good job you are both doing in fail2ban. It rocks! Yaroslav Halchenko wrote: > Just ICQ virtual drinks may be ;-) Or most of the time I just drink > his part myself ;) > > Cyril - find attached a patch to ban ssh-ddos attacks. And indeed, we > should have some beer together -- users are complaining! ;-) Should we ever meet in RL (Debconf, maybe?) the beers are on me. > Thanks - I got them and will look into them although it seems that > fail2ban is somewhat effective ;-) so we are good ;) Read above! fail2ban makes my life so much easier! (Now, if it was only a bit better documented.. maybe this is where I could return some of the good karma and provide some patches or a quick walkthrough). The wiki is very nice, though. Happy holidays! -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com
Bug#404487: Please improve the ssh regex
Aha - so majority of failures come from such really bad hosts -- good. I think default value of 6 or maxfailures will be ok ;-) 11363 84.197.215.6 11246 84.122.103.178 6903 84.75.165.67 6229 84.57.82.198 6018 84.74.141.2 Thank you for the information! > > that would be difficult - he is in Europe and I am in the states ;-) > So you guys do not have beer together? What a boring upstream! ;) Just ICQ virtual drinks may be ;-) Or most of the time I just drink his part myself ;) Cyril - find attached a patch to ban ssh-ddos attacks. And indeed, we should have some beer together -- users are complaining! ;-) > Ok, I'll just email you all the logs, privately Thanks - I got them and will look into them although it seems that fail2ban is somewhat effective ;-) so we are good ;) Happy Holidays! -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] #! /bin/sh /usr/share/dpatch/dpatch-run ## 10_ssh-ddos_section.dpatch by Yaroslav Halchenko <[EMAIL PROTECTED]> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad fail2ban-0.7.4~/config/filter.d/sshd-ddos.conf fail2ban-0.7.4/config/filter.d/sshd-ddos.conf --- fail2ban-0.7.4~/config/filter.d/sshd-ddos.conf 1969-12-31 19:00:00.0 -0500 +++ fail2ban-0.7.4/config/filter.d/sshd-ddos.conf 2006-12-26 21:59:03.0 -0500 @@ -0,0 +1,22 @@ +# Fail2Ban configuration file +# +# Author: Yaroslav Halchenko +# +# $Revision: 471 $ +# + +[Definition] + +# Option: failregex +# Notes.: regex to match the password failures messages in the logfile. The +# host must be matched by a group named "host". The tag "" can +# be used for standard IP/hostname matching. +# Values: TEXT +# +failregex = sshd\[\S*\]: Did not receive identification string from + +# Option: ignoreregex +# Notes.: regex to ignore. If this regex matches, the line is ignored. +# Values: TEXT +# +ignoreregex = diff -urNad fail2ban-0.7.4~/config/jail.conf fail2ban-0.7.4/config/jail.conf --- fail2ban-0.7.4~/config/jail.conf2006-10-19 16:13:01.0 -0400 +++ fail2ban-0.7.4/config/jail.conf 2006-12-26 22:00:03.0 -0500 @@ -33,6 +33,15 @@ logpath = /var/log/sshd.log maxretry = 5 +[ssh-ddos-iptables] + +enabled = false +filter = sshd-ddos +action = iptables[name=SSH, port=ssh, protocol=tcp] + mail-whois[name=SSH, [EMAIL PROTECTED] +logpath = /var/log/sshd.log +maxretry = 5 + [proftpd-iptables] enabled = false
Bug#404487: Please improve the ssh regex
Yaroslav Halchenko wrote:
> > Then I copied the attached sshd-ddos.conf to /etc/fail2ban/filter.d/
> > and restarted fail2ban.
> I would also run
> fail2ban-client status ssh-ddos
> to make sure that it is up ;-)
[EMAIL PROTECTED]> fail2ban-client status ssh-ddos
Status for the jail: ssh-ddos
|- filter
| |- Currently failed: 2
| `- Total failed: 28
`- action
|- Currently banned: 2
`- Total banned: 2
> > I am still looking at what is happening, so that this gets tested
> > before you and upstream have some beer ;)
>
> that would be difficult - he is in Europe and I am in the states ;-)
So you guys do not have beer together? What a boring upstream! ;)
> zgrep "Did not receive identification string from"
> /var/log/auth.log*gz | grep -v UNKNOWN | awk '{print $12;}' | sort |
> uniq -c | sort -n -r | awk '{print $1;}'
Attached and compressed.
[EMAIL PROTECTED]>zgrep "Did not receive identification string from"
/var/log/auth.log*gz | grep -v UNKNOWN | awk '{print $12;}' | sort | uniq -c |
sort -n -r | awk '{print
$1;}' > ips_log
[EMAIL PROTECTED]>grep "Did not receive identification string from"
/var/log/auth.log | grep -v UNKNOWN | awk '{print $12;}' | sort | uniq -c |
sort -n -r | awk '{print
$1;}' > ips_log
auth.log auth.log.0 auth.log.1.gz auth.log.2.gz auth.log.3.gz
auth.log.4.gz auth.log.5.gz auth.log.6.gz
[EMAIL PROTECTED]>grep "Did not receive identification string from"
/var/log/auth.log /var/log/auth.log.0 | grep -v UNKNOWN | awk '{print $12;}' |
sort | uniq -c | sort -n -r | awk '{print
$1;}' > ips_log_recent
> or may be just send me those all lines - so I could see how they are
> arranged in time
Ok, I'll just email you all the logs, privately
A bit of success and happiness here:
Dec 29 16:53:39 aenima snoopy[3852]: [amaya, uid:0 sid:14809]:
/etc/init.d/fail2ban start
Dec 29 16:53:39 aenima snoopy[3853]: [amaya, uid:0 sid:14809]:
/usr/bin/fail2ban-client status
Dec 29 16:53:39 aenima snoopy[3854]: [amaya, uid:0 sid:14809]:
start-stop-daemon --start --quiet --chuid root --exec /usr/bin/fail2ban-client
-- start
Dec 29 16:53:39 aenima snoopy[3854]: [amaya, uid:0 sid:14809]:
/usr/bin/fail2ban-client start
Dec 29 16:53:39 aenima snoopy[3855]: [amaya, uid:0 sid:14809]: fail2ban-server
-b -s /tmp/fail2ban.sock
Dec 29 16:53:39 aenima snoopy[3855]: [amaya, uid:0 sid:14809]: fail2ban-server
-b -s /tmp/fail2ban.sock
Dec 29 16:53:39 aenima snoopy[3904]: [amaya, uid:0 sid:14809]: /usr/bin/tput
hpa 60
Dec 29 16:53:39 aenima snoopy[3905]: [amaya, uid:0 sid:14809]: /usr/bin/tput
setaf 1
Dec 29 16:53:39 aenima snoopy[3906]: [amaya, uid:0 sid:14809]: /usr/bin/tput
setaf 1
Dec 29 16:53:39 aenima snoopy[3907]: [amaya, uid:0 sid:14809]: /usr/bin/tput op
Dec 29 16:53:40 aenima snoopy[3909]: [(null), uid:0 sid:3856]: iptables -N
fail2ban-ssh
Dec 29 16:53:40 aenima snoopy[3910]: [(null), uid:0 sid:3856]: iptables -A
fail2ban-ssh -j RETURN
Dec 29 16:53:40 aenima snoopy[3908]: [(null), uid:0 sid:3856]: iptables -I
INPUT -p tcp --dport ssh -j fail2ban-ssh
Dec 29 16:53:40 aenima snoopy[3912]: [(null), uid:0 sid:3856]: iptables -N
fail2ban-ssh-ddos
Dec 29 16:53:40 aenima snoopy[3913]: [(null), uid:0 sid:3856]: iptables -A
fail2ban-ssh-ddos -j RETURN
Dec 29 16:53:40 aenima snoopy[3911]: [(null), uid:0 sid:3856]: iptables -I
INPUT -p tcp --dport ssh -j fail2ban-ssh-ddos
Dec 29 16:53:40 aenima snoopy[3914]: [(null), uid:0 sid:3914]: /usr/sbin/sshd -R
Dec 29 16:53:40 aenima sshd[3914]: Did not receive identification string from
84.197.215.6
Dec 29 16:53:41 aenima snoopy[3915]: [(null), uid:0 sid:3915]: /usr/sbin/sshd -R
Dec 29 16:53:41 aenima sshd[3915]: Did not receive identification string from
84.197.215.6
Dec 29 16:53:42 aenima snoopy[3916]: [(null), uid:0 sid:3916]: /usr/sbin/sshd -R
Dec 29 16:53:42 aenima sshd[3916]: Did not receive identification string from
84.197.215.6
Dec 29 16:53:43 aenima snoopy[3917]: [(null), uid:0 sid:3917]: /usr/sbin/sshd -R
Dec 29 16:53:43 aenima sshd[3917]: Did not receive identification string from
84.197.215.6
Dec 29 16:53:44 aenima snoopy[3918]: [(null), uid:0 sid:3918]: /usr/sbin/sshd -R
Dec 29 16:53:44 aenima sshd[3918]: Did not receive identification string from
84.197.215.6
Dec 29 16:53:45 aenima snoopy[3920]: [(null), uid:0 sid:3856]: iptables -L INPUT
Dec 29 16:53:45 aenima snoopy[3921]: [(null), uid:0 sid:3856]: grep -q
fail2ban-ssh-ddos
Dec 29 16:53:45 aenima snoopy[3922]: [(null), uid:0 sid:3856]: iptables -I
fail2ban-ssh-ddos 1 -s 84.56.170.141 -j DROP
Dec 29 16:53:46 aenima snoopy[3923]: [(null), uid:0 sid:3923]: /usr/sbin/sshd -R
Dec 29 16:53:46 aenima sshd[3923]: Did not receive identification string from
84.197.215.6
Dec 29 16:53:46 aenima snoopy[3925]: [(null), uid:0 sid:3856]: iptables -L INPUT
Dec 29 16:53:46 aenima snoopy[3926]: [(null), uid:0 sid:3856]: grep -q
fail2ban-ssh-ddos
Dec 29 16:53:46 aenima snoopy[3927]: [(null), uid:0 sid:3856]: iptables -I
fail2ban-ssh-d
Bug#404487: Please improve the ssh regex
> Then I copied the attached sshd-ddos.conf to /etc/fail2ban/filter.d/ and
> restarted fail2ban.
I would also run
fail2ban-client status ssh-ddos
to make sure that it is up ;-)
> I am still looking at what is happening, so that this gets tested before
> you and upstream have some beer ;)
that would be difficult - he is in Europe and I am in the states
;-)
> Just for the sake of detail, my ssh server listens on two ports: 22 and
> 443 (don't ask, you really don't want to know), so this could either
> trigger false positives or miss some "attacks", but this is my local
> problem, and I have read your doc about multi-port module support in
> iptables, so I understand this problem is not easy to solve, and none of
> your bussiness really.
Actually multiple port banning should not be difficult at all...
hm... might be worth creating iptables-multiport action... hm...
actually README multiport entry is a bit outdated since 0.6 version of
fail2ban... since now we have nice infrastructure for different actions
- I will add iptables-multiport ;-) hold on... actually there is an
issue which forbids easy multiport adoption at the moment... I will
buzz upstream and I think we will come up with some nice solution ;)
For now I would suggest to make action
iptables-noport
where to remove --dport completely - so you will check all the traffic
and ban hosts completely... or manually craft iptables-sshports and
hardcode ports into iptables rules as
-m multiport --dports 22,443
> Would it be helpful if I did that? I would be very glad to.
for me it would be helpful if you send me smth like
zgrep "Did not receive identification string from" /var/log/auth.log*gz | grep
-v UNKNOWN | awk '{print $12;}' | sort | uniq -c | sort -n -r | awk '{print
$1;}'
(mention that I am to use awk not cut -d " " since that one screwed
your results -- " " would be split twice...)
That would give me idea what maxretry should be (I hope)
or may be just send me those all lines - so I could see how they are
arranged in time
> Cheers!
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
Hi there! Yaroslav Halchenko wrote: > Have you tried fail2ban solution I've sent? does it work? what > maxretry is a reasonable one? I copied this section into my /etc/fail2ban/jail.conf: [ssh-ddos] enabled = true port= ssh filter = sshd-ddos logpath = /var/log/auth.log maxretry = 6 Then I copied the attached sshd-ddos.conf to /etc/fail2ban/filter.d/ and restarted fail2ban. I am still looking at what is happening, so that this gets tested before you and upstream have some beer ;) Just for the sake of detail, my ssh server listens on two ports: 22 and 443 (don't ask, you really don't want to know), so this could either trigger false positives or miss some "attacks", but this is my local problem, and I have read your doc about multi-port module support in iptables, so I understand this problem is not easy to solve, and none of your bussiness really. But, I can easily do some iptables magic in my main fw for ssh to only listen on port 22, so that this test becomes more accurate. Would it be helpful if I did that? I would be very glad to. Cheers! -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com
Bug#404487: Please improve the ssh regex
On Wed, 27 Dec 2006, Amaya wrote: > > Ok - convinced now ;) > I knew you would help me, because you rock! > :) Thank you ;-) I am not sure where such assurance comes from but I kinda like it ;-) > I can happily wait until next upload, I have been doing some nasty > shell-scripting that deals with the DoS outside of fail2ban, but in line > with the social contract, our users are our first priority, and my ugly > hack doesn't help anyone but me. This is why I filed this bug, to have > other less skilled users protected too. Have you tried fail2ban solution I've sent? does it work? what maxretry is a reasonable one? Happy holidays! -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
Yaroslav Halchenko wrote: > Ok - convinced now ;) I knew you would help me, because you rock! :) > Due to its specificity I would prefer to have it as an additional > filter/jail as opposed to integrating it into existing ssh one. I think this is even a better solution, that can be easily adapted on a system basis to other DoS-es that might come in the future. > The package is in the middle of fixing another bug, so I want to > preclude uploading before I settle the solution for it with upstream. Please finish your bug, have a beer with upstream, no hurry :) This is just a whishlist (and answer you just gave me is exactly why I say you rock). I can happily wait until next upload, I have been doing some nasty shell-scripting that deals with the DoS outside of fail2ban, but in line with the social contract, our users are our first priority, and my ugly hack doesn't help anyone but me. This is why I filed this bug, to have other less skilled users protected too. Thanks a lot for your work in Debian, it is highly appreciated! -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com
Bug#404487: Please improve the ssh regex
tag 494487 + pending thanks Ok - convinced now ;) Due to its specificity I would prefer to have it as an additional filter/jail as opposed to integrating it into existing ssh one. So, please find attached filters.d file and relevant config for jails.local is smth like following piece NB feel free to tune maxretry up to your liking and please let me know what is the sensible one - ie how many times a single IP triggers such log lines on average. Please let me know so I tune it in shipped jail.conf before uploading [ssh-ddos] enabled = true port= ssh filter = sshd-ddos logpath = /var/log/auth.log maxretry = 6 The package is in the middle of fixing another bug, so I want to preclude uploading before I settle the solution for it with upstream. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] # Fail2Ban configuration file # # Author: Yaroslav Halchenko # # $Revision: 471 $ # [Definition] # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "" can # be used for standard IP/hostname matching. # Values: TEXT # failregex = sshd\[\S*\]: Did not receive identification string from # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
Bug#404487: Please improve the ssh regex
Yaroslav Halchenko wrote: > If you agree - close the bug. If not - bring your arguments ;-) In my case it is a distributed DoS: [EMAIL PROTECTED]>grep "Did not receive identification string from" /var/log/auth.log /var/log/auth.log.0 | grep -v UNKNOWN | cut -f 12 -d " "| sort -u | wc -l 94 [EMAIL PROTECTED]>zgrep "Did not receive identification string from" /var/log/auth.log*gz | grep -v UNKNOWN | cut -f 12 -d " "| sort -u | wc -l 521 That's 615 different IP addresses, and really hammering badly, not counting the attepmts from UNKNOWN, and the attepmpts to exploit vulnerabilities by sending strange escape chars, I attach examples in a logfile. There should be a way, maxretry and bantime look exactly the way, to stop this without banning legitimate ssh clients. So, no, please do not close this bug, unless you ate least document how to stop this in README:Debian :) Thanks for you great job -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com ssh_hammering.gz Description: Binary data
Bug#404487: Please improve the ssh regex
I am afraid that this would be also a case for some valid clients which go through some bad connection. Or in other words, this string does not necessarily mean an attempt to get unauthorized access. If you agree - close the bug. If not - bring your arguments ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404487: Please improve the ssh regex
Package: fail2ban Version: 0.7.5-2 Severity: wishlist I am seeing a lot of "Did not receive identification string from " at my /var/log/auth.log and fail2ban fails to catch them. Thanks for your wonderful work! -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Versions of packages fail2ban depends on: ii iptables1.3.6.0debian1-5 administration tools for packet fi ii lsb-base3.1-22 Linux Standard Base 3.1 init scrip ii python 2.4.4-2 An interactive high-level object-o ii python-central 0.5.12 register and build utility for Pyt ii python2.4 2.4.4-1 An interactive high-level object-o fail2ban recommends no packages. -- no debconf information -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com
