| View previous topic :: View next topic |
| Author |
Message |
goatman
n00b
Joined: 31 Aug 2014
Posts: 11
|
 Posted: Sat Jan 03, 2015 11:59 pm Post subject: fail2ban issues and break-in attempts |
 |
|
Hi,
I am having some issues following a restart - I am not exactly sure where to start.
After upgrading to kernel 3.17 I did a reboot, I had a look at fail2ban and I saw this:
| Code: | | 2015-01-03 06:46:23,431 fail2ban.transmitter [16613]: WARNING Command ['set', 'ssh-iptables', 'maxretry', 'None'] has failed. Received ValueError("invalid literal for int() with base 10: 'None'",) |
I have checked and double checked /etc/fail2ban/jail.d/sshd.conf and /etc/fail2ban/jail.conf and maxretry(s) are fine.
Could someone elaborate more on this one?
Secondly, I look at /var/log/messages and I see a few thousand of these, from a half-dozen different IPs:
| Code: | Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: SSH: Server;Ltype: Version;Remote: 62.210.180.72-38929;Protocol: 2.0;Client: PUTTY
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: SSH: Server;Ltype: Kex;Remote: 62.210.180.72-38929;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: SSH: Server;Ltype: Authname;Remote: 62.210.180.72-38929;Name: root [preauth]
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: PAM unable to dlopen(/lib64/security/system-remote-login): /lib64/security/system-remote-login: cannot open shared object file: No such file or directory
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: PAM adding faulty module: /lib64/security/system-remote-login
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: error: PAM: Module is unknown for root from 62-210-180-72.rev.poneytelecom.eu
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: error: PAM: Module is unknown for root from 62-210-180-72.rev.poneytelecom.eu
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: error: PAM: Module is unknown for root from 62-210-180-72.rev.poneytelecom.eu
Jan 3 07:52:01 dedi-fr-25112 sshd[12529]: Received disconnect from 62.210.180.72: 11: [preauth]
Jan 3 07:52:01 dedi-fr-25112 sshd[12536]: SSH: Server;Ltype: Version;Remote: 62.210.180.72-41328;Protocol: 2.0;Client: PUTTY
Jan 3 07:52:01 dedi-fr-25112 sshd[12536]: SSH: Server;Ltype: Kex;Remote: 62.210.180.72-41328;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
Jan 3 07:52:02 dedi-fr-25112 sshd[12536]: SSH: Server;Ltype: Authname;Remote: 62.210.180.72-41328;Name: root [preauth]
Jan 3 07:52:02 dedi-fr-25112 sshd[12536]: PAM unable to dlopen(/lib64/security/system-remote-login): /lib64/security/system-remote-login: cannot open shared object file: No such file or directory
|
What does this mean?
Does this confirm that fail2ban isn't working?
fail2ban is configured with a sshd jail as per wiki.
I am completely lost at this point. |
|
| Back to top |
|
 |
Pearlseattle
Apprentice
Joined: 04 Oct 2007
Posts: 162
Location: Switzerland
|
| Posted: Fri Jan 23, 2015 8:53 pm Post subject: |
|
|
Hi
Concerning problem #1:
I have as well a server and I am sticking to kernel 3.14 because (from what I remember) sometimes between 3.14 and 3.17 Linux dropped iptables in favour of something else (don't remember the name of the new "thing").
I read long time back that there was some kind of wrapper that was supposed to provide for the transition phase the exact same functionality of iptables.
Maybe (in the case that the above is correct) the wrapper does not work exactly as advertised?
I did not try them (iptables & fail2ban) out on >3.14 yet, so I am sorry that I cannot give you any "real" informations - just this hint. |
|
| Back to top |
|
|
juggling_ben
n00b
Joined: 25 Nov 2007
Posts: 15
|
| Posted: Sun Jan 25, 2015 3:33 am Post subject: |
|
|
| Pearlseattle wrote: | Hi
Concerning problem #1:
I have as well a server and I am sticking to kernel 3.14 because (from what I remember) sometimes between 3.14 and 3.17 Linux dropped iptables in favour of something else (don't remember the name of the new "thing").
|
The new thing is nftables. However, it will be a very long time before the kernel actually 'drops' support for iptables. I'm using 3.18 and everything is still fine. Heck, doesn't the kernel have support still for ipchains (which was before iptables)?
The error is almost definitely a configuration error. Do you have a jail.local file you forgot to look at? Maybe there's a typo? (maxretries vs. maxrety)
The second error (about pam) is odd. That has nothing to do with fail2ban/iptables. It looks like pam is looking in the wrong place for system-remote-login. It is actually in /etc/pam.d (for me). Is the /lib64/security path hardcoded is some other files in /etc/pam.d (ie /etc/pam.d/sshd)? |
|
| Back to top |
|
|
Pearlseattle
Apprentice
Joined: 04 Oct 2007
Posts: 162
Location: Switzerland
|
| Posted: Sun Jan 25, 2015 1:11 pm Post subject: |
|
|
As juggling_ben wrote, the same is true on my PC:
| Code: | find / -name system-remote-login
/etc/pam.d/system-remote-login |
|
|
| Back to top |
|
|
trumee
Guru
Joined: 02 Mar 2003
Posts: 551
Location: London,UK
|
| Posted: Sat Jan 31, 2015 4:54 pm Post subject: |
|
|
I too have the issue. It seems fail2ban crashes after sometime and thus stops working. If you try to restart using "/etc/init.d/fail2ban restart" you will see it has crashed.
Seems like this is needed. |
|
| Back to top |
|
|
duh
n00b
Joined: 14 Jul 2003
Posts: 27
Location: Utrecht
|
| Posted: Mon Feb 09, 2015 5:49 pm Post subject: |
|
|
I just configured fail2ban and ran into the same issue... I was using the example from the wiki (the syslog-ng & ufw example for sshd):
| Quote: | [ssh-iptables]
enabled = true
filter = sshd
action = ufw[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/messages
maxretry = 5 # Override the default of 3 |
However this particular configuration file is resulting in the following error (the same as mentioned in the original post):
| Quote: |
2015-02-09 18:40:36,979 fail2ban.transmitter [15356]: WARNING Command ['set', 'ssh-iptables', 'maxretry', 'None'] has failed. Received ValueError("invalid literal for int() with base 10: 'None'",)
|
It is actually an easy fix, just delete the extra spaces in the variable declarations and the issue will go away:
| Quote: |
[ssh-iptables]
enabled=true
filter=sshd
action=ufw[name=SSH, port=ssh, protocol=tcp]
logpath=/var/log/messages
maxretry=5
|
And all is well... |
|
| Back to top |
|
|
|
Networking & Security
