Como as alterações em /etc/pam.d/common-session-noninteractive afetam o fail2ban e possivelmente outros programas / serviços?

2

Fail2Ban no Ubuntu 10,04

Arquivos de configuração

/etc/fail2ban/jail.local

[DEFAULT]

ignoreip = 127.0.0.1
bantime  = 10 # made for test purposes
maxretry = 3

backend = polling

destemail = [email protected]


banaction = iptables-multiport

mta = sendmail

protocol = tcp

action = %(action_mw)s

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3

[pam-generic]

enabled = true
filter  = pam-generic
port = all
banaction = iptables-allports
port     = anyport
logpath  = /var/log/auth.log
maxretry = 6

O restante das configurações do fail2ban são apenas as padrão.

padrão /etc/pam.d/common-session-noninteractive

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session required        pam_unix.so 
session optional                        pam_winbind.so 
session required        pam_loginuid.so 

alterou o /etc/pam.d/common-session-noninteractive

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
session required        pam_unix.so 
session optional                        pam_winbind.so 
session required        pam_loginuid.so 

Por favor, note que a única diferença é adicionar o serviço session [success = 1 default = ignore] pam_succeed_if.so no cron quiet use_uid .

Registros

extrair de /var/log/auth.log com o padrão /etc/pam.d/common-session-noninteractive

May 22 15:30:01 node1 CRON[16029]: pam_unix(cron:session): session opened for user root by (uid=0)
May 22 15:30:01 node1 CRON[16029]: pam_unix(cron:session): session closed for user root
May 22 15:35:01 node1 CRON[16514]: pam_unix(cron:session): session opened for user root by (uid=0)
May 22 15:35:01 node1 CRON[16514]: pam_unix(cron:session): session closed for user root

Resumo

  1. Se eu executar fail2ban-client set ssh banip 1.2.3.4 em 15:26, o IP será banido às 15:30. É por isso que o associo ao cron job listado acima.
  2. Se eu modificar /etc/pam.d/common-session-noninteractive e repetir o comando fail2ban-client, não receberei nenhuma entrada em /var/log/auth.log e nenhuma proibição.

Mais informações:

  1. padrão /etc/pam.d/common-session-noninteractive :

    fail2ban-client set ssh banip 1.2.3.4 - > o IP é banido por um cron job invisível , que é executado a cada 5 minutos. Eu verifiquei cada arquivo em /etc/cron* e /var/spool/cron/* e não havia tal trabalho presente. Conclusão: a proibição manual funciona com um atraso de até 5 minutos.

  2. adicionou session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid em /etc/pam.d/common-session-noninteractive como sugerido aqui :

    fail2ban-client set ssh banip 1.2.3.4 - > a tarefa cron invisível não é executada e não ocorre nenhuma proibição.

Minha pergunta:

como é que a alteração em /etc/pam.d/common-session-noninteractive impede que o cliente fail2ban banir um IP? E por quê?

Editar

  • Executando na depuração:
root@node1:~# fail2ban-client set loglevel 4
Current logging level is DEBUG
root@node1:~# fail2ban-client -vvv set ssh banip 1.2.3.4
DEBUG  Reading /etc/fail2ban/fail2ban
DEBUG  Reading files: ['/etc/fail2ban/fail2ban.conf', '/etc/fail2ban/fail2ban.local']
INFO   Using socket file /var/run/fail2ban/fail2ban.sock
DEBUG  OK : '1.2.3.4'
DEBUG  Beautify '1.2.3.4' with ['set', 'ssh', 'banip', '1.2.3.4']
1.2.3.4
root@zap:~# tail -f /var/log/fail2ban.log
2013-05-24 21:32:07,695 fail2ban.comm   : DEBUG  Command: ['set', 'ssh', 'banip', '1.2.3.4']
2013-05-24 21:32:07,696 fail2ban.filter : DEBUG  Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 21:32:07,696 fail2ban.filter : DEBUG  Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 21:32:07,696 fail2ban.filter : DEBUG  Currently have failures from 1 IPs: ['1.2.3.4']

Resultado: nenhuma proibição

  • Removendo quiet de session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid em /etc/pam.d/common-session-noninteractive :

Resultado: proibição bem-sucedida

/var/log/auth.log :

May 24 22:00:01 node1 CRON[22483]: pam_succeed_if(cron:session): requirement "service in cron" was met by user "root"
May 24 22:00:01 node1 CRON[22483]: pam_succeed_if(cron:session): requirement "service in cron" was met by user "root"

/var/log/fail2ban.log :

2013-05-24 21:56:07,955 fail2ban.comm   : DEBUG  Command: ['set', 'loglevel', '4']
2013-05-24 21:56:20,155 fail2ban.comm   : DEBUG  Command: ['set', 'ssh', 'banip', '1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG  Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG  Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG  Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 22:00:01,079 fail2ban.filter : DEBUG  /var/log/auth.log has been modified
2013-05-24 22:00:01,079 fail2ban.filter.datedetector: DEBUG  Sorting the template list
2013-05-24 22:00:01,853 fail2ban.filter : DEBUG  /var/log/auth.log has been modified
2013-05-24 22:00:01,853 fail2ban.filter.datedetector: DEBUG  Sorting the template list
2013-05-24 22:00:01,870 fail2ban.actions: WARNING [ssh] Ban 1.2.3.4
2013-05-24 22:00:01,870 fail2ban.actions.action: DEBUG  iptables -n -L INPUT | grep -q fail2ban-ssh
2013-05-24 22:00:01,876 fail2ban.actions.action: DEBUG  iptables -n -L INPUT | grep -q fail2ban-ssh returned successfully
2013-05-24 22:00:01,877 fail2ban.actions.action: DEBUG  iptables -I fail2ban-ssh 1 -s 1.2.3.4 -j DROP
2013-05-24 22:00:01,919 fail2ban.actions.action: DEBUG  iptables -I fail2ban-ssh 1 -s 1.2.3.4 -j DROP
2013-05-24 22:00:01,920 fail2ban.actions.action: DEBUG  
2013-05-24 22:00:01,923 fail2ban.actions.action: DEBUG   returned successfully
...

Versão do Fail2Ban

fail2ban 0.8.7.1-2 ~ ppa7 ~ lúcido de aqui . O estoque um (versão 0.8.4) continuou falhando com:

"global name 'time' is not defined"

que me pede para procurar uma versão mais recente.

    
por grs 23.05.2013 / 00:06

1 resposta

0

Eu acho (mas não confirmado) o que o fail2ban simplesmente espera por novas linhas no auth.log antes de aplicar o comando fail2ban-client, então a proibição é feita não por "um trabalho cron invisível, que executa a cada 5 minutos" mas "por infinito loop que lê 'logpath' ", auth.log no caso particular. Se isso for verdade, a mudança que você fez em /etc/pam.d/common-session-noninteractive não impede que o fail2ban-client proíba um IP, mas o adia até que qualquer nova linha apareça em auth.log. Novas linhas de log aparecem com menos frequência, porque você desativou as mensagens do cron e é necessário aguardar mais tempo pela proibição do IP.

    
por 27.09.2014 / 21:05