Servidor de registro comprometido (IptabLes e IptabLex)

Question

Servidor de registro comprometido (IptabLes e IptabLex)

#1 de DrTech (2 votos)
#2 de Erik (1 votos)
#3 de bast1aan (0 votos)
#4 de Nick (0 votos)

2

Estoy tratando de averiguar cómo fue comprometido. Instalaron IptabLes e IptabLex en /boot .
También agregaron /etc/init.d/IptabLes y /etc/init.d/IptabLex que simplemente llaman a los respectivos archivos /boot . Parece que este ataque usa una gran cantidad de ancho de banda (probablemente un DDoS); Lo noté de inmediato.

El servidor ejecuta CentOS 6.5 con todas las actualizaciones más recientes.
Ejecuta logstash , redis , ElasticSearch y Cherokee servidor web que sirve Kibana.
Estoy pensando que debe ser ElasticSearch o el servidor web Cherokee.

El puerto ElasticSearch (9200) estaba abierto al mundo, porque Kibana lo requiere para ver los buenos gráficos. Los puertos Redis (6379) estaban restringidos a solo 5 hosts conocidos a través de iptables.
El servidor web Cherokee se ejecuta en el puerto (8080), no es el predeterminado de 80 y estaba abierto al mundo.

SSH no parece estar comprometido. El servidor usa claves y no autentica contraseña.
esta permitido. Ejecutamos SSH en el puerto 2020, que aparece como (xinupageserver) en iptables.

Aquí están las reglas de iptables. Aviso redis está restringido a servidores web,
pero http a través de Cherokee (webcache) y ElasticSearch (wap-wsp) están abiertos.

➜  ~  iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             loopback/8          reject-with icmp-port-unreachable 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:xinupageserver 
ACCEPT     tcp  --  web1.mydomain.com     anywhere            tcp dpt:6379 
ACCEPT     tcp  --  web2.mydomain.com    anywhere             tcp dpt:6379 
ACCEPT     tcp  --  web3.mydomain.com     anywhere            tcp dpt:6379 
ACCEPT     tcp  --  web4.mydomain.com     anywhere            tcp dpt:6379 
ACCEPT     tcp  --  web5.mydomain.com     anywhere            tcp dpt:6379 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:wap-wsp 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:webcache 
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

Muchas gracias por la ayuda.

iptables

pregunta Justin 28.05.2014 - 01:43

fuente

4 respuestas

Lea otras preguntas en las etiquetas iptables

¿Hay un informe de encuesta técnica relacionado con BitLocker y TPM? ¿Qué es DVNC y cómo funciona?

score 2 · Answer 1

Nunca deberías dejar Elasticsearch abierto al mundo, de la misma manera que no dejarías ningún servidor de base de datos abierto al mundo. Siempre ponga un proxy delante de él y use (al menos) autenticación HTTP. Preferiblemente, su proxy debe limitar lo que se puede hacer desde el exterior, por ejemplo, solo permite solicitudes GET, de lo contrario, cualquier usuario podría eliminar todos sus datos o cerrar sus servidores.

A partir de la versión 1.2.0, el script dinámico (que pasa un script como parte de, por ejemplo, una solicitud de búsqueda) se ha deshabilitado de forma predeterminada. En versiones anteriores, está habilitado de forma predeterminada, lo que significa que cualquier usuario externo podría hacer cualquier cosa en su servidor que el usuario de Elasticsearch pueda hacer.

Si está ejecutando una versión anterior, desea agregar esto a su config/elasticsearch.yaml :

script.disable_dynamic: true

Consulte enlace para más y enlace

score 1 · Answer 2

@Justin tengo el mismo problema. Tengo un servidor de monitoreo en DigitalOcean que también utiliza ElasticSearch.

Creo que el problema no está en ssh porque mi servidor usa claves y no autenticación de contraseña e inicio de sesión deshabilitado para usuarios root.

Algunos usuarios de DO tuvieron el mismo problema con ElasticSearch: enlace

EIDT: Aquí está la solución para limpiarla enlace pero no soluciona el problema en un futuro

score 0 · Answer 3

He tenido el mismo problema (troyano IpTablex) en una caja de Debian 7 con solo ssh abierto a través de la conexión DSL. Solo ejecutaba un servidor de base de datos postgresql que solo escuchaba conexiones internas. La causa más probable fue una contraseña de root débil, el inicio de sesión de raíz ssh estaba abierto. La única otra causa podría ser una máquina de Windows comprometida utilizada para iniciar sesión en la máquina con ssh, pero no hemos visto ninguna otra máquina infectada donde se hayan usado las computadoras con Windows.

La única buena solución es averiguar la causa de la infección, hacer una copia de seguridad de sus datos importantes y volver a instalar todo el sistema y corregir la causa de la infección. Los scripts que eliminan solo / boot / IpTablex y los archivos relacionados no son una solución, ya que no garantizan que no haya otro rootkit en otra parte del sistema y no soluciona la causa de la infección.

score 0 · Answer 4

Bueno, inmediatamente, veo una gran falla en tu postura de seguridad:

➜  ~  iptables -L Chain INPUT (policy ACCEPT) 
target     prot opt   source    destination
ACCEPT     all  --    anywhere  anywhere

Su primera regla en ENTRADA es aceptar cualquier conexión entrante en cualquier puerto ... por lo que su rechazo al final (y, de hecho, ninguna de sus otras reglas de ENTRADA) es importante ...

Por lo tanto, cualquiera de sus servicios de ejecución / escucha en el servidor podría haber sido dirigido, solo para su información.

[ EDIT ] Vea la prueba a continuación

Script started on Sun 27 Jul 2014 11:32:04 AM EDT
]0;nick@fakeit:/tmp[?1034h[nick@fakeit tmp]$ sudo iptables -L
[sudo] password for nick: 
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
The authenticity of host '172.16.16.110 (172.16.16.110)' can't be established.
RSA key fingerprint is fc:86:c7:f6:1a:31:5b:9b:4d:a7:85:ca:7c:f2:29:ec.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.16.110' (RSA) to the list of known hosts.

[email protected]'s password: 
Last login: Sun Jul 27 11:30:55 2014 from localhost

]0;iptables_demo@fakeit:~[?1034h[iptables_demo@fakeit ~]$ echo "I got in with a default INPUT policy of DROP, an explict DROP ALL at the end, but an ACCEPT ALL rule at the beginning"
I got in with a default INPUT policy of DROP, an explict DROP ALL at the end, but an ACCEPT ALL rule at the beginning
]0;iptables_demo@fakeit:~[iptables_demo@fakeit ~]$ exit
logout
Connection to 172.16.16.110 closed.


]0;nick@fakeit:/tmp[nick@fakeit tmp]$ sudo iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
[email protected]'s password: 
Last login: Sun Jul 27 11:32:52 2014 from 172.16.16.110

]0;iptables_demo@fakeit:~[?1034h[iptables_demo@fakeit ~]$ echo "I got in with an ACCEPT ALL as the first rule, an ACCEPT HTTP as the second rule, and a DROP ALL as the end rule with a default policy of DROP"
I got in with an ACCEPT ALL as the first rule, an ACCEPT HTTP as the second rule, and a DROP ALL as the end rule with a default policy of DROP
]0;iptables_demo@fakeit:~[iptables_demo@fakeit ~]$ exit
logout
Connection to 172.16.16.110 closed.


]0;nick@fakeit:/tmp[nick@fakeit tmp]$ sudo iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
ssh: connect to host 172.16.16.110 port 22: Connection timed out

]0;nick@fakeit:/tmp[nick@fakeit tmp]$ echo "I was unable to connect when the only ACCEPT rule was for HTTP and a default DROP policy and an explicit DROP rule"
I was unable to connect when the only ACCEPT rule was for HTTP and a default DROP policy and an explicit DROP rule



]0;nick@fakeit:/tmp[nick@fakeit tmp]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
ssh: connect to host 172.16.16.110 port 22: Connection timed out

]0;nick@fakeit:/tmp[nick@fakeit tmp]$ echo "I was unable to connect with the only ACCEPT rule being HTTP and a default ACCEPT policy but an explicit DROP rule at the end of the INPUT filter"
I was unable to connect with the only ACCEPT rule being HTTP and a default ACCEPT policy but an explicit DROP rule at the end of the INPUT filter
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ exit



Script done on Sun 27 Jul 2014 11:38:54 AM EDT