# fail2ban issues and break-in attempts

## goatman

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:

```
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:

```
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.

----------

## Pearlseattle

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.

----------

## juggling_ben

 *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)?

----------

## Pearlseattle

As juggling_ben wrote, the same is true on my PC:

```
find / -name system-remote-login

/etc/pam.d/system-remote-login
```

----------

## trumee

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.

----------

## duh

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
> ...

 

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
> ...

 

And all is well...

----------

