[OFFTOPIC] Problema con Fail2ban a la hora de banear las IP en mi centralita Asterisk
814 views
Skip to first unread message
Miguel Alberto Sanz Pardo
Nov 12, 2014, 12:29:19 PM11/12/14
to aster...@googlegroups.com
Hola buenas tardes,
Desde ayer dejé abierto el puerto 5060 de mi centralita, permitiendo que algún usuario de mi empresa pueda conectarse de forma remota.
El caso es que de todas las medidas de seguridad que he implementado tengo una duda con la herramienta fail2ban.
En el archivo jail.conf tengo un contexto de este estilo:
[asterisk-iptables]
enabled = true
filter = asterisk
action = iptables-allports[name=ASTERISK, protocol=all]
sendmail-whois[name=ASTERISK, dest=mico...@gmail.com,sender=fail2ban@localhost]
# Si usamos el canal security
logpath = /var/log/asterisk/security
# Si no usamos el canal security
#logpath = /var/log/asterisk/messages
# Si un usuario comete 3 fallos en 24 horas, se le baneará de todo el servidor durante otras 24 horas.
# Esto limita a los atacantes a hacer un máximo de 3 intentos al día.
maxretry = 3
bantime = 86400
findtime = 86400
De tal manera fail2ban se encarga de contrastar los mensajes que aparecen en /var/log/asterisk/security con respecto al filtro /etc/fail2ban/filter.d/asterisk.conf
En caso de que algún usuario malintencionado trate de conectarse, al tercer intento fallido el fail2ban debe de banear al usuario ejecutando la acción iptables-allports[name=ASTERISK, protocol=all] correspondiente.
Contenido de /etc/fail2ban/action.d/iptables-allports.conf:
...
actioncheck = iptables -n -L <chain> | grep -q 'fail2ban-<name>[ \t]'
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
El caso es que a lo largo de las últimas 24 horas ha habido 3 intentos de registro en mi centralita, los cuáles han sido fallidos. Al parecer el fail2ban los ha baneado pero me he dado cuenta de algo:
En el momento que fail2ban banea la IP si ejecutas iptables -L dicha IP aparece DROPEADA en las reglas
[...@asterisk ~]# iptables -L --line-number
Chain INPUT (policy DROP)
num target prot opt source destination
1 fail2ban-ASTERISK all -- anywhere anywhere
2 ACCEPT all -- anywhere anywhere
3 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
4 ACCEPT udp -- anywhere anywhere udp dpt:sip
5 ACCEPT udp -- anywhere anywhere udp dpts:ndmp:dnp
6 ACCEPT tcp -- anywhere anywhere tcp dpt:35210
Chain FORWARD (policy DROP)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain fail2ban-ASTERISK (1 references)
num target prot opt source destination
1 DROP all -- 107.150.44.218 anywhere
2 RETURN all -- anywhere anywhere
Pero al cabo de unos minutos si vuelves a ejecutar iptables -L dicha IP ya no aparece DROPEADA pero sin embargo si que aparece como baneada si ejecutas:
[...@asterisk ~]# fail2ban-client status asterisk-iptables
Status for the jail: asterisk-iptables
|- filter
| |- File list: /var/log/asterisk/security
| |- Currently failed: 0
| `- Total failed: 56
`- action
|- Currently banned: 2
| `- IP list: 107.182.20.226 107.150.44.218
`- Total banned: 5
Quería saber si realmente está baneada o no ya que no aparece en el iptables.
Si miro el log del fail2ban (/var/log/fail2ban.log) aparece algo de este estilo:
2014-11-12 05:09:24,223 fail2ban.actions: WARNING [asterisk-iptables] Ban 107.182.20.226
2014-11-12 05:09:24,234 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]' returned 100
2014-11-12 05:09:24,235 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
2014-11-12 05:09:24,247 fail2ban.actions.action: ERROR iptables -D INPUT -p all -j fail2ban-ASTERISK
iptables -F fail2ban-ASTERISK
iptables -X fail2ban-ASTERISK returned 100
2014-11-12 09:47:27,184 fail2ban.filter : INFO Log rotation detected for /var/log/asterisk/security
2014-11-12 09:47:30,792 fail2ban.actions: WARNING [asterisk-iptables] Ban 107.150.44.218
2014-11-12 09:47:30,803 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]' returned 100
2014-11-12 09:47:30,804 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
2014-11-12 09:47:30,815 fail2ban.actions.action: ERROR iptables -D INPUT -p all -j fail2ban-ASTERISK
iptables -F fail2ban-ASTERISK
iptables -X fail2ban-ASTERISK returned 100
Aparecen varios errores, que me dan que están relacionados con que desparezca la regla del iptables asociada al fail2ban
¿Alguien que me confirme y/o me pueda echar una mano?
Un saludo y gracias por vuestra colaboración
Miguel Sanz
PD: Mientras no tengo claro si han sido baneadas o no realmente esas IP he cogido y las he baneado a mano desde mi script asociado a iptables, pero claro, no es plan de banearlas a mano cada 2 por 3.
Raúl Alexis Betancor Santana
Nov 12, 2014, 1:15:02 PM11/12/14
to aster...@googlegroups.com
Vamos a ir linea a linea ...
> ----- Mensaje original -----
> De: "Miguel Alberto Sanz Pardo" <miguels...@gmail.com>
> Para: aster...@googlegroups.com
> Enviados: Miércoles, 12 de Noviembre 2014 17:29:18
> Asunto: [Asterisk-ES] [OFFTOPIC] Problema con Fail2ban a la hora de banear las IP en mi centralita Asterisk
> De tal manera fail2ban se encarga de contrastar los mensajes que aparecen en /var/log/asterisk/security con respecto al filtro /etc/fail2ban/filter.d/asterisk.conf
>
> En caso de que algún usuario malintencionado trate de conectarse, al tercer intento fallido el fail2ban debe de banear al usuario ejecutando la acción iptables-allports[name=ASTERISK, protocol=all] correspondiente.
>
> Contenido de /etc/fail2ban/action.d/iptables-allports.conf:
> ...
> actioncheck = iptables -n -L <chain> | grep -q 'fail2ban-<name>[ \t]'
> actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
> actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
>
>
>
> El caso es que a lo largo de las últimas 24 horas ha habido 3 intentos de registro en mi centralita, los cuáles han sido fallidos. Al parecer el fail2ban los ha baneado pero > me he dado cuenta de algo:
>
> En el momento que fail2ban banea la IP si ejecutas iptables -L dicha IP aparece DROPEADA en las reglas
>
> [...@asterisk ~]# iptables -L --line-number
> Chain INPUT (policy DROP)
> num target prot opt source destination
> v1 fail2ban-ASTERISK all -- anywhere anywhere
>
>
> Quería saber si realmente está baneada o no ya que no aparece en el iptables.
>
> Si miro el log del fail2ban (/var/log/fail2ban.log) aparece algo de este estilo:
> 2014-11-12 05:09:24,223 fail2ban.actions: WARNING [asterisk-iptables] Ban 107.182.20.226
> 2014-11-12 05:09:24,234 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]' returned 100
PETADA!!!
> 2014-11-12 05:09:24,235 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
Y como PETA, lo siguiente que hace es 'restore a sane environment'
> 2014-11-12 05:09:24,247 fail2ban.actions.action: ERROR iptables -D INPUT -p all -j fail2ban-ASTERISK
> iptables -F fail2ban-ASTERISK
> iptables -X fail2ban-ASTERISK returned 100
Que dicha 'restauración' consiste en cargarse y flushear el chain donde están las reglas ... por eso en cuanto te intentan putear por segunda vez ... lo que hace es borrar todo lo que había antes. Con este fallo ... nunca tendrás más de una IP bloqueada.
> 2014-11-12 09:47:27,184 fail2ban.filter : INFO Log rotation detected for /var/log/asterisk/security
> 2014-11-12 09:47:30,792 fail2ban.actions: WARNING [asterisk-iptables] Ban 107.150.44.218
> 2014-11-12 09:47:30,803 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]' returned 100
> 2014-11-12 09:47:30,804 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
> 2014-11-12 09:47:30,815 fail2ban.actions.action: ERROR iptables -D INPUT -p all -j fail2ban-ASTERISK
> iptables -F fail2ban-ASTERISK
> iptables -X fail2ban-ASTERISK returned 100
Lo mismo otra vez ...
>
> Aparecen varios errores, que me dan que están relacionados con que desparezca la regla del iptables asociada al fail2ban
¡Equiricua! ...
>
>
>
>
> ¿Alguien que me confirme y/o me pueda echar una mano?
Ejecuta tú los comandos a manopla ... y verifica que error dan, intuyo que lo de '[ \t]' te sobra ..
Saludos.
> ----- Mensaje original -----
> De: "Miguel Alberto Sanz Pardo" <miguels...@gmail.com>
> Para: aster...@googlegroups.com
> Enviados: Miércoles, 12 de Noviembre 2014 17:29:18
> Asunto: [Asterisk-ES] [OFFTOPIC] Problema con Fail2ban a la hora de banear las IP en mi centralita Asterisk
>
> Hola buenas tardes,
>
>
> Desde ayer dejé abierto el puerto 5060 de mi centralita, permitiendo que algún usuario de mi empresa pueda conectarse de forma remota.
>
> El caso es que de todas las medidas de seguridad que he implementado tengo una duda con la herramienta fail2ban.
>
>
> En el archivo jail.conf tengo un contexto de este estilo:
>
> [asterisk-iptables]
> enabled = true
> filter = asterisk
> action = iptables-allports[name=ASTERISK, protocol=all]
> sendmail-whois[name=ASTERISK, dest=mico...@gmail.com,sender=fail2ban@localhost]
> # Si usamos el canal security
> logpath = /var/log/asterisk/security
> # Si no usamos el canal security
> #logpath = /var/log/asterisk/messages
>
> # Si un usuario comete 3 fallos en 24 horas, se le baneará de todo el servidor durante otras 24 horas.
> # Esto limita a los atacantes a hacer un máximo de 3 intentos al día.
> maxretry = 3
> bantime = 86400
> findtime = 86400
Yo pondría un chequeo de 3 fallos en 5 minutos ... y baneo de 1 semana. Quien se conecta a tu central ... tiene las credenciales ... y va a a tener 0 fallos de autenticación ... ;)
> Hola buenas tardes,
>
>
> Desde ayer dejé abierto el puerto 5060 de mi centralita, permitiendo que algún usuario de mi empresa pueda conectarse de forma remota.
>
> El caso es que de todas las medidas de seguridad que he implementado tengo una duda con la herramienta fail2ban.
>
>
> En el archivo jail.conf tengo un contexto de este estilo:
>
> [asterisk-iptables]
> enabled = true
> filter = asterisk
> action = iptables-allports[name=ASTERISK, protocol=all]
> sendmail-whois[name=ASTERISK, dest=mico...@gmail.com,sender=fail2ban@localhost]
> # Si usamos el canal security
> logpath = /var/log/asterisk/security
> # Si no usamos el canal security
> #logpath = /var/log/asterisk/messages
>
> # Si un usuario comete 3 fallos en 24 horas, se le baneará de todo el servidor durante otras 24 horas.
> # Esto limita a los atacantes a hacer un máximo de 3 intentos al día.
> maxretry = 3
> bantime = 86400
> findtime = 86400
> De tal manera fail2ban se encarga de contrastar los mensajes que aparecen en /var/log/asterisk/security con respecto al filtro /etc/fail2ban/filter.d/asterisk.conf
>
> En caso de que algún usuario malintencionado trate de conectarse, al tercer intento fallido el fail2ban debe de banear al usuario ejecutando la acción iptables-allports[name=ASTERISK, protocol=all] correspondiente.
>
> Contenido de /etc/fail2ban/action.d/iptables-allports.conf:
> ...
> actioncheck = iptables -n -L <chain> | grep -q 'fail2ban-<name>[ \t]'
> actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
> actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
>
>
>
> El caso es que a lo largo de las últimas 24 horas ha habido 3 intentos de registro en mi centralita, los cuáles han sido fallidos. Al parecer el fail2ban los ha baneado pero > me he dado cuenta de algo:
>
> En el momento que fail2ban banea la IP si ejecutas iptables -L dicha IP aparece DROPEADA en las reglas
>
> [...@asterisk ~]# iptables -L --line-number
> Chain INPUT (policy DROP)
> num target prot opt source destination
> 2 ACCEPT all -- anywhere anywhere
> 3 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> 4 ACCEPT udp -- anywhere anywhere udp dpt:sip
> 5 ACCEPT udp -- anywhere anywhere udp dpts:ndmp:dnp
> 6 ACCEPT tcp -- anywhere anywhere tcp dpt:35210
>
> Chain FORWARD (policy DROP)
> num target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> num target prot opt source destination
>
> Chain fail2ban-ASTERISK (1 references)
> num target prot opt source destination
> 1 DROP all -- 107.150.44.218 anywhere
> 2 RETURN all -- anywhere anywhere
>
>
> Pero al cabo de unos minutos si vuelves a ejecutar iptables -L dicha IP ya no aparece DROPEADA pero sin embargo si que aparece como baneada si ejecutas:
> [...@asterisk ~]# fail2ban-client status asterisk-iptables
> Status for the jail: asterisk-iptables
> |- filter
> | |- File list: /var/log/asterisk/security
> | |- Currently failed: 0
> | `- Total failed: 56
> `- action
> |- Currently banned: 2
> | `- IP list: 107.182.20.226 107.150.44.218
> `- Total banned: 5
Ahora verás porqué ... te lo señalo en el log ...
> 3 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> 4 ACCEPT udp -- anywhere anywhere udp dpt:sip
> 5 ACCEPT udp -- anywhere anywhere udp dpts:ndmp:dnp
> 6 ACCEPT tcp -- anywhere anywhere tcp dpt:35210
>
> Chain FORWARD (policy DROP)
> num target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> num target prot opt source destination
>
> Chain fail2ban-ASTERISK (1 references)
> num target prot opt source destination
> 1 DROP all -- 107.150.44.218 anywhere
> 2 RETURN all -- anywhere anywhere
>
>
> Pero al cabo de unos minutos si vuelves a ejecutar iptables -L dicha IP ya no aparece DROPEADA pero sin embargo si que aparece como baneada si ejecutas:
> [...@asterisk ~]# fail2ban-client status asterisk-iptables
> Status for the jail: asterisk-iptables
> |- filter
> | |- File list: /var/log/asterisk/security
> | |- Currently failed: 0
> | `- Total failed: 56
> `- action
> |- Currently banned: 2
> | `- IP list: 107.182.20.226 107.150.44.218
> `- Total banned: 5
>
>
> Quería saber si realmente está baneada o no ya que no aparece en el iptables.
>
> Si miro el log del fail2ban (/var/log/fail2ban.log) aparece algo de este estilo:
> 2014-11-12 05:09:24,223 fail2ban.actions: WARNING [asterisk-iptables] Ban 107.182.20.226
> 2014-11-12 05:09:24,234 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]' returned 100
> 2014-11-12 05:09:24,235 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
> 2014-11-12 05:09:24,247 fail2ban.actions.action: ERROR iptables -D INPUT -p all -j fail2ban-ASTERISK
> iptables -F fail2ban-ASTERISK
> iptables -X fail2ban-ASTERISK returned 100
> 2014-11-12 09:47:27,184 fail2ban.filter : INFO Log rotation detected for /var/log/asterisk/security
> 2014-11-12 09:47:30,792 fail2ban.actions: WARNING [asterisk-iptables] Ban 107.150.44.218
> 2014-11-12 09:47:30,803 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]' returned 100
> 2014-11-12 09:47:30,804 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
> 2014-11-12 09:47:30,815 fail2ban.actions.action: ERROR iptables -D INPUT -p all -j fail2ban-ASTERISK
> iptables -F fail2ban-ASTERISK
> iptables -X fail2ban-ASTERISK returned 100
>
> Aparecen varios errores, que me dan que están relacionados con que desparezca la regla del iptables asociada al fail2ban
>
>
>
>
> ¿Alguien que me confirme y/o me pueda echar una mano?
Saludos.
Miguel Alberto Sanz Pardo
Nov 14, 2014, 12:00:24 PM11/14/14
to aster...@googlegroups.com
Hola de nuevo Raul,
He probado a ejecutar directamente desde la consola: # iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]'
y no aparece ningún error por pantalla.En /var/log/fail2ban.log tampoco aparece nada.
Sin embargo, si hago un service restart iptables sí que puedo ver el error en /var/log/fail2ban.log
Si modifico la línea de /etc/fail2ban/action.d/iptables-allports.conf de manera que sea "iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK'" y hago un service fail2ban restart sigue apareciendo el mismo error en el /var/log/fail2ban.log
Si ejecuto desde la consola: #iptables -D INPUT -p all -j fail2ban-ASTERISK aparece este mensaje:
iptables v1.4.7: Couldn't load target `fail2ban-ASTERISK':/lib/xtables/libipt_fail2ban-ASTERISK.so: cannot open shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
Adjunto los ficheros de configuración y el log por si puedes ver algo que se me esté escapando.
un saludo y gracias por tu ayuda
Miguel sanz
He probado a ejecutar directamente desde la consola: # iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK[ \t]'
y no aparece ningún error por pantalla.En /var/log/fail2ban.log tampoco aparece nada.
Sin embargo, si hago un service restart iptables sí que puedo ver el error en /var/log/fail2ban.log
Si modifico la línea de /etc/fail2ban/action.d/iptables-allports.conf de manera que sea "iptables -n -L INPUT | grep -q 'fail2ban-ASTERISK'" y hago un service fail2ban restart sigue apareciendo el mismo error en el /var/log/fail2ban.log
Si ejecuto desde la consola: #iptables -D INPUT -p all -j fail2ban-ASTERISK aparece este mensaje:
iptables v1.4.7: Couldn't load target `fail2ban-ASTERISK':/lib/xtables/libipt_fail2ban-ASTERISK.so: cannot open shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
Adjunto los ficheros de configuración y el log por si puedes ver algo que se me esté escapando.
un saludo y gracias por tu ayuda
Miguel sanz
Miguel Alberto Sanz Pardo
Nov 15, 2014, 11:12:13 AM11/15/14
to aster...@googlegroups.com
A lo largo de esta madrugada trataron de entrar desde 5 IP en mi sistema:
4 desde España
37.29.207.29 92.58.202.111 37.29.189.208 88.22.170.87
1 desde Francia
94.23.23.78
Hasta ahora solo me habían atacado desde USA 3 veces y desde Francia 1 vez.
En una semana (desde que abrí los puertos) me han atacado ya 9 veces...espero que no consigan entrar.
Por ahora los ataques han sido tratar de registrarse con las extensiones 100 y 101 las cuáles ni siquiera existen en mi sistema...
También desde las diferentes IP españolas trataban de registrarse con el usuario 195...
Una de las IP francesas trataba de registrarse con el usuario 972595161852 y multiples combinaciones (además del mítico 100), no sé porque intentaba registrarse con esta ID pero bueno
A ver si consigo automatizar el fail2ban para asegurarme de que realmente están baneados y no tener que estar baneando IP a mano cada vez que me avisa el fail2ban...
rfernandezmx
Nov 15, 2014, 11:36:08 AM11/15/14
to aster...@googlegroups.com
Hola! te mando los parametros que a mi me funcionan y para enriquecer esto (en mi humilde opinion) tambien instala el portsentry, hay dos tipos de ataques que hemos descubierto:
1.- el atacante con portscanner
2.- el atacante con scriptbot que apunta al puerto especifico
comunmente ya me toco a mi que cuando baneas a un tio con el fail2ban, su siguiente movimiento es mandar un nmap para ver que tienes abierto
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< CORTA AQUI>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Version de mi asterisk: 1.8
logger.conf del asterisk:
messages => notice,warning,error
en mi jail.conf:
[asterisk]
1.- el atacante con portscanner
2.- el atacante con scriptbot que apunta al puerto especifico
comunmente ya me toco a mi que cuando baneas a un tio con el fail2ban, su siguiente movimiento es mandar un nmap para ver que tienes abierto
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< CORTA AQUI>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Version de mi asterisk: 1.8
logger.conf del asterisk:
messages => notice,warning,error
en mi jail.conf:
[asterisk]
enabled = true
filter = asterisk
action = iptables-multiport[name=asterisk-udp, port="5060,5061", protocol=udp]
sendmail-whois[name=PBX, dest=mim...@dominio.com, sender=p...@dominio.com]
logpath = /var/log/asterisk/messages
maxretry = 5
bantime = 604800
en el filter.d:
[Definition]
#_daemon = asterisk
# 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 "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<HOST>\S+)
# Values: TEXT
#
failregex = NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - ACL error (permit/deny)
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - ACL error (permit/deny)
NOTICE.* <HOST> failed to authenticate as '.*'$
NOTICE.* .*: No registration for peer '.*' \(from <HOST>\)
NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
NOTICE.* .*: Failed to authenticate user .*@<HOST>.*
NOTICE.* .*: Sending fake auth rejection for device .*@<HOST>.*
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
y cuando doy el iptables -L -n me da esto:
Chain INPUT (policy ACCEPT)
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW recent: CHECK seconds: 600 hit_count: 20 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW recent: CHECK seconds: 180 hit_count: 5 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW recent: CHECK seconds: 60 hit_count: 3 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 600 hit_count: 20 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 300 hit_count: 10 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 180 hit_count: 5 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 60 hit_count: 3 TTL-Match name: SIP side: source
tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 recent: SET name: ftpattack side: source
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW recent: CHECK seconds: 60 hit_count: 4 name: ftpattack side: source reject-with tcp-reset
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state RELATED,ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state RELATED,ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 STRING match "REGISTER sip:servidor1.dyndns.net" ALGO name bm TO 65535
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 STRING match "REGISTER sip:servidor2.dyndns.net" ALGO name bm TO 65535
ACCEPT udp -- 200.76.0.0/16 0.0.0.0/0 udp dpt:5060
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000
DROP icmp -- 0.0.0.0/0 0.0.0.0/0
DROP tcp -- !127.0.0.1 0.0.0.0/0 tcp dpt:25
DROP tcp -- !127.0.0.1 0.0.0.0/0 tcp dpt:5038
DROP tcp -- !127.0.0.1 0.0.0.0/0 tcp dpt:3306
Chain FORWARD (policy ACCEPT)
sendmail-whois[name=PBX, dest=mim...@dominio.com, sender=p...@dominio.com]
logpath = /var/log/asterisk/messages
maxretry = 5
bantime = 604800
en el filter.d:
[Definition]
#_daemon = asterisk
# 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 "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<HOST>\S+)
# Values: TEXT
#
failregex = NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>(:[0-9]{1,5})?' - ACL error (permit/deny)
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
NOTICE.* .*: Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - ACL error (permit/deny)
NOTICE.* <HOST> failed to authenticate as '.*'$
NOTICE.* .*: No registration for peer '.*' \(from <HOST>\)
NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
NOTICE.* .*: Failed to authenticate user .*@<HOST>.*
NOTICE.* .*: Sending fake auth rejection for device .*@<HOST>.*
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
y cuando doy el iptables -L -n me da esto:
Chain INPUT (policy ACCEPT)
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW recent: CHECK seconds: 600 hit_count: 20 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW recent: CHECK seconds: 180 hit_count: 5 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW recent: CHECK seconds: 60 hit_count: 3 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 600 hit_count: 20 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 300 hit_count: 10 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 180 hit_count: 5 TTL-Match name: SIP side: source
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state NEW recent: CHECK seconds: 60 hit_count: 3 TTL-Match name: SIP side: source
tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 recent: SET name: ftpattack side: source
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW recent: CHECK seconds: 60 hit_count: 4 name: ftpattack side: source reject-with tcp-reset
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state RELATED,ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:55060 state RELATED,ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 STRING match "REGISTER sip:servidor1.dyndns.net" ALGO name bm TO 65535
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 STRING match "REGISTER sip:servidor2.dyndns.net" ALGO name bm TO 65535
ACCEPT udp -- 200.76.0.0/16 0.0.0.0/0 udp dpt:5060
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000
DROP icmp -- 0.0.0.0/0 0.0.0.0/0
DROP tcp -- !127.0.0.1 0.0.0.0/0 tcp dpt:25
DROP tcp -- !127.0.0.1 0.0.0.0/0 tcp dpt:5038
DROP tcp -- !127.0.0.1 0.0.0.0/0 tcp dpt:3306
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-SSH (1 references)
target prot opt source destination
target prot opt source destination
REJECT all -- 195.154.241.15 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 195.154.241.15 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
REJECT all -- 195.154.241.15 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Elio Rojano
Nov 18, 2014, 7:39:26 AM11/18/14
to aster...@googlegroups.com
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Página web: http://www.sinologic.net/
Twitter: http://twitter.com/hellc2
LinkedIn: http://es.linkedin.com/in/rojano
Miguel Alberto Sanz Pardo
Nov 19, 2014, 5:09:20 AM11/19/14
to aster...@googlegroups.com
Pues sí Elio voy a probarlo, ya lo tenía pensado hacer, pero no quería rendirme con la configuración de fail2ban, aunque a este paso...
Ya corregí el error que daba con el actioncheck pero aun así sigue dándome problemas. Analicé el comando actiocheck como me indicó Raul: actioncheck = iptables -n -L <chain> | grep -q 'fail2ban-<name>[ \t]'
Y lo modifiqué de esta forma de manera que ya no daba error y devolvía un mensaje por pantalla: actioncheck = iptables -n -L fail2ban-<name>
Puse incuso el failban.log a nivel 4 (debug), antes lo tenía a nivel 3, por si veía alguna información adicional más. El caso es que ya no aparece ningún error y durante un rato aparece la IP baneada en el iptables:
iptables -n -L
Chain INPUT (policy DROP)
target prot opt source destination
fail2ban-AsteriskIPC all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-AsteriskIPC (1 references)
target prot opt source destination
DROP all -- 216.155.138.226 0.0.0.0/0
pero al rato la entrada desaparece del Iptables y si miras el log no
hay errores, desaparece del iptables by the face(al menos yo no he visto
nada en el log):
iptables -n -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 192.168.0.0/21 0.0.0.0/0 tcp dpt:35210
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-AsteriskIPC (0 references)
target prot opt source destination
He estado investigando por internet y he leído acerca de
este problema, pero a mí en principio ya no me da errores al haber
hecho esta modificacion del actioncheck:
http://oschgan.com/drupal/index.php?q=node/52
http://blog.laimbock.com/2013/01/11/fail2ban-error-invariant-check-failed/
También he encontrado algo acerca de que las reglas del fail2ban podían entrar en conflicto con las del firewall y que se recomendaba usar el comando route
un saludo
Miguel Sanz
Miguel Alberto Sanz Pardo
Nov 19, 2014, 5:17:14 AM11/19/14
to aster...@googlegroups.com
Por cierto, en mi centralita tengo instalada una distribucion CentOS release 6.5 (Final) con kernel Linux 2.6.32-431.1.2.0.1.el6.i686, no se si esto también influenciará de alguna forma en el fail2ban. El fail2ban lo tengo actualizado a la última versión, la fail2ban-0.8.14-1.el6.noarch
un saludo
Miguel Sanz
un saludo
Miguel Sanz
Miguel Alberto Sanz Pardo
Nov 20, 2014, 4:14:38 AM11/20/14
to aster...@googlegroups.com
Una duda Elio,
Según https://www.python.org/ftp/python/ las última versiones disponibles son: 2.7.8 y 3.4.2
Antes de instalarlo he leído en tu web que:
"SIPCheck2 es compatible con Python 2.7 o superior, por lo que algunos sistemas CentOS o Elastix deberán instalar la versión 2.7 o superior en sus sistemas, y tener así dos versiones: Python 2.4 (con la que funcionan algunas herramientas del sistema) y Python 2.7 o superior. Nuestro colega Eloy Coto nos ayuda un poco indicándonos cómo se puede hacer: https://gist.github.com/eloycoto/9abceacffb9fea1195ea"
En estos momentos ¿me recomendarías instalar alguna versión de python en concreto?Según https://www.python.org/ftp/python/ las última versiones disponibles son: 2.7.8 y 3.4.2
un saludo
Miguel Sanz
El martes, 18 de noviembre de 2014 13:39:26 UTC+1, Elio Rojano escribió:
Elio Rojano
Nov 20, 2014, 8:07:35 AM11/20/14
to aster...@googlegroups.com
La versión 2.4 es muy, muy antigua, por lo que cualquier versión por encima de Python 2.6 podría estar "bien".
Lo ideal (e imagino que cualquiera que trabaje con Python te dirá) es que instales la última 3.X.X.
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
SiscoCasasempere
Nov 20, 2014, 10:17:27 AM11/20/14
to aster...@googlegroups.com
Hola,
Saludos
Miguel Alberto Sanz Pardo
Nov 21, 2014, 6:16:41 AM11/21/14
to aster...@googlegroups.com
Por lo que veo tengo instalada la versión Python 2.6.6 (r266:84292) , lo que ya no recuerdo es cuando la instalé :)
Creo que probaré con la 2.7.8 y si veo que funciona bien por ahora no actualizo más el python.
Por cierto, comentaros que ya he conseguido solucionar el problema, resulta que un cron del portsentry me estaba puteando y reiniciaba el iptables cada vez que el fail2ban baneaba a alguien(de manera que borraba mis reglas del fail2ban). Agradecer de nuevo a Raul su ayuda ;) , porque sino aún sigo volviendome loco sin saber qué es lo que estaba pasando
un saludo y gracias a todos por vuestra ayuda
Creo que probaré con la 2.7.8 y si veo que funciona bien por ahora no actualizo más el python.
Por cierto, comentaros que ya he conseguido solucionar el problema, resulta que un cron del portsentry me estaba puteando y reiniciaba el iptables cada vez que el fail2ban baneaba a alguien(de manera que borraba mis reglas del fail2ban). Agradecer de nuevo a Raul su ayuda ;) , porque sino aún sigo volviendome loco sin saber qué es lo que estaba pasando
un saludo y gracias a todos por vuestra ayuda
El jueves, 20 de noviembre de 2014 14:07:35 UTC+1, Elio Rojano escribió:
La versión 2.4 es muy, muy antigua, por lo que cualquier versión por encima de Python 2.6 podría estar "bien".Lo ideal (e imagino que cualquiera que trabaje con Python te dirá) es que instales la última 3.X.X.
Reply all
Reply to author
Forward
0 new messages