sshd failing to match against x.x.x.x-y #643

Closed
666threesixes666 opened this Issue Mar 13, 2014 · 9 comments

Projects

None yet

4 participants

y being a rotating number, but x.x.x.x are all the same number. my servers getting hammered extremely hard on sshd. HOSTS> is not helping me. the regex should be num dot num dot num dot num to extract host ip addresses only.

http://bpaste.net/show/188261/

i have disabled root login via password in ssh, but this should be addressed immediately as i know its happening to servers out in the wild. (re accusations of arrogance on irc) im not being arrogant, im reporting critical exploitable bugs. admins can look through their logs and get a 98% hit rate, with 2% false negatives. (which i expect to jump drastically unless repaired)

fail2ban-client --version
Fail2Ban v0.8.12

http://www.fail2ban.org/wiki/index.php/Talk:Asterisk <--- this explains the issue exactly.
""New REGEX for Asterisk 1.8 Asterisk 1.8 includes the port number in the log entry so it broke the existing regex for detecting the host IP."" same problem, sshd this time, not addressed properly the 1st time around. its with a dash instead of a colon.

fail2ban should be fetching ip via xxx.xxx.xxx.xxx numbers only, and xx:xx:xx:xx:xx:xx num-f using regular expressions extracting only the ip limiting to 3 or less on ip v4 place holders, or 2 or less place holders for ip v6. regex (if it uses regex) is hidden somewhere within the package. im marking fail2ban as insecure as of v0.8.12 with critical bugs.

discovered on gentoo > syslog-ng 3.4.2 > openssh 6.4_p1-r1 > fail2ban 0.8.12

wiki reporting this issue surfaced @ nov, 5 2010 this issue is 4 years old.

"danblack> i find demands of "but this should be addressed immediately." really offensive
threesixes> i know if its happening to me, its happening to production servers in the wild, i find lulling a false sense of security far more offensive
danblack> don't care. you can wait for your arrogence.
danblack> your sence of false security is your own problem"

public notice on arch, and gentoo wiki... cent 6 also affected.

Contributor
kwirk commented Mar 13, 2014

@666threesixes666 Sorry, but you've approached this like a bull in a china shop. Please try and be clear on issues you're having, rather than jumping to conclusions. And also be considerate that like many open source projects, this is maintained by volunteers in their spare time.

It appears those SSH: Server;Ltype log lines are from HPN openssh patch. Therefore, they are non standard for openssh…It also appears from the logs, like this is pre-authentication issue already seen: #243.

FYI the Asterisk issue is different and not applicable.

Also, could you think about amending your wiki changes. Thanks 😄

@kwirk kwirk closed this Mar 13, 2014

i will not change the wiki edits until the regex extracting ip info is properly addressed.... i was polite the first time around in irc. ["192.168.0.1"]-:; should ban all the same. bull in china shop, hardly the issue is 4 years old cropping up in 1 way or another, even worse recurring.

i understand its a volunteer thing, false negatives are no joking matter in server security packages. non standard, so what the second someone else changes a package upstream security provided by fail2ban is compromised.

Contributor
kwirk commented Mar 13, 2014

@666threesixes666: The IP address on the Received disconnect from… line should be fine to match with. The extra lines from the HPN patch do not add any more detail.

you're failing to see the point that HOST must be an ip address only or else fail2ban fails to ban. it parses logs, which may or may not have verbose debugging information attached to them. sshguard blocks the ip in question in the logs. id prefer fail2ban work though. i really like the package and run them side by side now, but id prefer to purge ssh guard. sorry i couldnt write a patch and am confused by the swamp of code going on with fail2ban.

Contributor
kwirk commented Mar 13, 2014

The <HOST> tag also has to match domain names, which it then looks up the IP via a DNS query. So unfortunately it can't be limited to match IPs only.

Regardless, using a regex with <HOST>-[0-9]+; should force the port number to not be matched as part of the host/IP.

Contributor

http://www.fail2ban.org/wiki/index.php/Talk:Asterisk <--- this explains the issue exactly.
""New REGEX for Asterisk 1.8 Asterisk 1.8 includes the port number in the log entry"

This was fixed 10 months ago. 0f7b609#diff-b30bc54c8f3216fb0ec029a9ec098477
We need to do strict regexes to prevent DoS vulnerabilities.

The sample there was broken because it was in syslog format rather than a direct log - fixed in 476d79d.

On expecting ssh to be protectable by fail2ban see the front of the fail2ban home page "Fail2Ban is able to reduce the rate of incorrect authentications attempts however it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services."

As kirk said "Please try and be clear on issues you're having, rather than jumping to conclusions."

If you have any factual bugs from wikis, blogs, obscure notes written under pillows that you have discovered you may actually help by doing a polite factual bug report here. Looking forward to your positive contribution.

ok heres my positive contribution... =D

http://bpaste.net/show/188261/ <--- fail2ban is running, not banning. as of this moment i do use said security procedures keys, disabled root login, disabled password login, lock account out after so many failed attempts via pam, ufw limit directive. sshguard catches offender in question..... running fail2ban-regex sshbpastelog sshfilter produces 500 misses. i don't mind my server but i do mind others getting false negatives in the wild. ultimately its a scrap VM thats getting deleted.

its not my problem anymore, ive evaded the issue by other means. provide proper regex blocking ill test then revert the wiki warning commits, as anyone else seeing this behavior could google the issue and land here.

Contributor
kwirk commented Mar 14, 2014

As far as I can tell, SSHGuard uses the following regexs1:

  • Invalid user .+ from
  • User .+ from <ssh_notallowed> not allowed because .+
  • Failed none for <invalid username> from <ssh_notallowed> port .+
  • Failed [^ ]+ for [^ ]+ from <ssh_notallowed> port .+
  • error: PAM: [aA]uthentication (error|failure) for (illegal user )?.+ from
  • reverse mapping checking getaddrinfo for [^\[]*[<ssh_reversemap>] .*POSSIBLE BREAK-IN ATTEMPT!
  • Did not receive identification string from
  • Bad protocol version identification.* from

As far as I can tell none of these match the log sample you sent, so I'm a bit confused which regex you'd like added? Your log sample only appears to have connects and disconnects with no authentication attempts. Please note that Fail2Ban is fully configurable, so you are more than welcome to add a regex to match those log lines.

when you connect but trying using ssh authkeys this is what happens if the authkeys are incorrect.
afaict this is an issue with ssh not logging the fact that ssh authkeys are invalid

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