¿Los registros de Port Knock sugieren que la máquina ha sido comprometida?

Question

¿Los registros de Port Knock sugieren que la máquina ha sido comprometida?

#1 de Steffen Ullrich (1 votos)

2

En mi máquina CentOS, todos mis puertos se filtran con la regla de Iptables:

DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Por lo tanto, desde Internet, todos los tiempos de espera de puertos.

La única forma de ssh en la máquina, es hacer una secuencia de Port Knock de la siguiente manera:

6        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 53853 recent: SET name: KNOCK1 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "ssh port knocking 1 "
7        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 6663 recent: CHECK seconds: 15 name: KNOCK1 side: source mask: 255.255.255.255 recent: SET name: KNOCK2 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 2 "
8        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 96563 recent: CHECK seconds: 15 name: KNOCK2 side: source mask: 255.255.255.255 recent: SET name: KNOCK3 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 3 "
9        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 77799 recent: CHECK seconds: 15 name: KNOCK3 side: source mask: 255.255.255.255 recent: SET name: KNOCK4 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 4 "
10       x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 12263 recent: CHECK seconds: 15 name: KNOCK4 side: source mask: 255.255.255.255 recent: SET name: OPEN_SESAME side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 5 "
11       x   x ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example SSH REAL PORT state NEW,RELATED,ESTABLISHED recent: CHECK seconds: 15 name: OPEN_SESAME side: source mask: 255.255.255.255 
12       x   x ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Ahora, revisando los registros, cada vez que cambio la secuencia de puertos, encuentro en el registro de journalctl que se ha intentado un puerto específico en esos ejemplos knock 1, knock 2 ... etc. / p>

kernel: ssh port knocking 1 IN=eth0 OUT= MAC=example MAC SRC=Attacker IP, always the same DST=My IP LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=xxxx DF PROTO=TCP SPT=source DPT=**ANY SEQUENCE I CHOOSE** WINDOW=29200 RES=0x00 SYN

No hay registros para ningún otro puerto, ni ninguna otra sonda en absoluto.

Es como si el atacante supiera la secuencia cada vez que la cambio.

Ya que no hay absolutamente ningún otro registro para ningún otro intento, y el monitoreo de tcpdump no muestra que se estén realizando sondeos, es seguro asumir que el atacante conoce la secuencia porque la máquina está comprometida y obtiene el Información cada vez que la cambio?

attacks system-compromise ports scan

pregunta Jonas 08.07.2018 - 00:46

fuente

1 respuesta

Lea otras preguntas en las etiquetas attacks system-compromise ports scan

¿Los cifrados en cascada en Veracrypt son susceptibles al ataque en el medio? (MITM) ¿Es ssdeep FP-propenso o FN propenso?

score 1 · Answer 1

Su idea de eliminación de puertos básicamente funciona avanzando de una etapa de activación de puertos a la siguiente cuando la misma IP del cliente envía un paquete TCP al puerto secreto de la nueva etapa dentro de los 15 segundos posteriores a la última etapa.

Tenga en cuenta que no hay penalización por las conjeturas erróneas y no hay límite de tasa para las conjeturas (el límite de avg 5/min solo se aplica a las conjeturas correctas). Esto significa que todo lo que un atacante tiene que hacer para avanzar de una etapa a la siguiente es escanear todos los puertos de su máquina en 15 segundos, una tarea que puede lograrse fácilmente cuando se usan sockets en bruto (es decir, no esperar a que el protocolo de enlace TCP se realice). completa).

¿es seguro asumir que el atacante conoce la secuencia porque la máquina está comprometida y obtiene la información cada vez que la cambio?

Según la información que ha proporcionado hasta el momento, no se puede reclamar esto. Le sugiero que busque intentos de autenticación fallidos o exitosos desde esta dirección IP específica para ver si alguien realmente intentó iniciar sesión (y tal vez tuvo éxito) en lugar de solo realizar una exploración de puertos y solo activó accidentalmente sus reglas de eliminación de puertos. También tenga en cuenta que si la máquina está realmente comprometida y profundamente, no debe confiar en sus registros locales, ya que el atacante podría haberlos cambiado.

Aparte de eso:

No hay registros para ningún otro puerto, ni ninguna otra sonda en absoluto

En función de las reglas, usted muestra que solo registra si el puerto coincide, es decir, no se esperan otros registros.