Servidor Ghost NTP en Debian 8.6

16

Entonces, el equipo de seguridad de TI de la universidad y yo hemos estado dando vueltas y vueltas sobre esto sin interrupciones ... cualquiera tiene alguna idea sobre esto:

Recientemente configuré un pequeño servidor de archivos para mi laboratorio que ejecuta Debian 8.6 en una computadora dedicada (procesador Intel Avoton C2550, feliz de proporcionar más información de hardware si es necesario, pero creo que es innecesario). Debian se instaló sin problemas, y en ese momento también instalé Samba, NTP, ZFS y Python. Las cosas parecían estar funcionando bien, así que lo dejé reposar y correr en la esquina del laboratorio durante unas semanas.

Hace aproximadamente dos semanas, recibí un correo electrónico del equipo de TI que decía que mi servidor estaba "comprometido" y que era vulnerable al ser utilizado en un ataque de amplificación NTP / DDoS (Ataques de amplificación NTP usando CVE-2013-5211 como se describe en https: //www.us-cert.gov/ncas/alerts/TA14-013A ). La señal a la que apuntaban era mucho tráfico NTPv2 en el puerto 123. Extrañamente, la dirección IP de la que identificaron que provenía ( *.*.*.233) era diferente de la dirección IP para la que estaba configurado mi servidor y se informó a través de ifconfig ( *.*.*.77). Sin embargo, algunos problemas básicos revelaron que mi computadora estaba generando este tráfico en el puerto 123 (como lo reveló tcpdump).

Aquí es donde comenzó la extrañeza. Primero revisé las "soluciones" recomendadas para CVE-2013-5211 (tanto la actualización de la versión anterior de NTP 4.2.7 como la desactivación de la funcionalidad monlist). Ninguno de los dos contuvo el flujo del tráfico. Luego intenté bloquear el puerto UDP 123 a través de tablas IP:

$ /sbin/iptables -A INPUT -o eth0 -p udp --destination-port 123 -j DROP
$ /sbin/iptables -A OUTPUT -o eth0 -p udp --destination-port 123 -j DROP

pero eso tampoco tuvo efecto en el tráfico. Finalmente intenté purgar NTP del sistema, pero eso tampoco tuvo efecto en el tráfico. A partir de esta tarde, nmap seguía informando:

Starting Nmap 5.51 ( http://nmap.org ) at 2016-12-19 16:15 EST
Nmap scan report for *.233
Host is up (0.0010s latency).
PORT    STATE SERVICE
123/udp open  ntp
| ntp-monlist:
|   Public Servers (2)
|       50.116.52.97    132.163.4.101
|   Public Clients (39)
|       54.90.159.15    185.35.62.119   185.35.62.233   185.35.63.86
|       54.197.89.98    185.35.62.142   185.35.62.250   185.35.63.108
|       128.197.24.176  185.35.62.144   185.35.62.251   185.35.63.128
|       180.97.106.37   185.35.62.152   185.35.63.15    185.35.63.145
|       185.35.62.27    185.35.62.159   185.35.63.27    185.35.63.146
|       185.35.62.52    185.35.62.176   185.35.63.30    185.35.63.167
|       185.35.62.65    185.35.62.186   185.35.63.34    185.35.63.180
|       185.35.62.97    185.35.62.194   185.35.63.38    185.35.63.183
|       185.35.62.106   185.35.62.209   185.35.63.39    185.35.63.185
|_      185.35.62.117   185.35.62.212   185.35.63.43

Lo cual es muy extraño ya que NTP ha sido purgado del sistema durante semanas.

Después de llegar a un punto muerto en este camino, comencé a pensar en todo el problema de la falta de coincidencia de direcciones IP. Mi computadora parecía estar instalada en IP * .233 y * .77 (como se confirmó haciendo ping con éxito tanto con el cable de ethernet conectado como sin el cable desenchufado), pero * .233 nunca aparece en ifconfig:

Link encap:Ethernet  HWaddr d0:XX:XX:51:78:XX  
inet addr:*.77  Bcast:*.255  Mask:255.255.255.0
inet6 addr: X::X:X:X:787a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:23023571 errors:0 dropped:1362 overruns:0 frame:0
TX packets:364849 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:7441732389 (6.9 GiB)  TX bytes:44699444 (42.6 MiB)
Memory:df300000-df37ffff

No hay referencia a * .233 en / etc / network / interfaces, por lo que no veo de dónde proviene esta asignación de IP.

Entonces, tengo dos preguntas relacionadas con las que espero que alguien pueda ayudarme: 1) ¿Cómo puedo eliminar este tráfico NTP de mi servidor para quitarlo de mi espalda? 2) ¿Qué sucede con esta segunda dirección IP en la que se encuentra mi servidor y cómo puedo eliminarla?

Gracias amigos :)

ACTUALIZACIÓN: según lo solicitado: $iptables -L -v -n

Chain INPUT (policy ACCEPT 57 packets, 6540 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 27 packets, 2076 bytes)
 pkts bytes target     prot opt in     out     source               destination

Y $ip addr ls

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:50:99:51:78:7a brd ff:ff:ff:ff:ff:ff
    inet *.77/24 brd *.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet *.167/24 brd *.255 scope global secondary dynamic eth0
       valid_lft 24612sec preferred_lft 24612sec
    inet6 X::X:X:X:787a/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether d0:50:99:51:78:7b brd ff:ff:ff:ff:ff:ff

ACTUALIZACIÓN 2: no mencioné que, además de que la dirección IP no coincidía, la ID de MAC tampoco coincidía. Esto realmente me hizo pensar dos veces sobre si el tráfico realmente venía de mi máquina. Sin embargo: (1) desconectar mi servidor de la red hizo que desapareciera el tráfico; (2) pasar a un puerto de red diferente y el tráfico seguido; y (3) tcpdump port 123mostró el tráfico aberrante:

13:24:33.329514 IP cumm024-0701-dhcp-233.bu.edu.ntp > 183.61.254.77.44300: NTPv2, Reserved, length 440
13:24:33.329666 IP cumm024-0701-dhcp-233.bu.edu.ntp > 183.61.254.77.44300: NTPv2, Reserved, length 440
13:24:33.329777 IP cumm024-0701-dhcp-233.bu.edu.ntp > 183.61.254.77.44300: NTPv2, Reserved, length 296

ACTUALIZACIÓN 3: $ss -uapn 'sport = :123'

State      Recv-Q Send-Q                  Local Address:Port                    Peer Address:Port

(es decir, nada)

$sudo cat /proc/net/dev

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:  327357    5455    0    0    0     0          0         0   327357    5455    0    0    0     0       0          0
  eth1:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0: 13642399917 36270491    0 6522    0     0          0   2721337 45098276  368537    0    0    0     0       0          0

ACTUALIZACIÓN 4: Esos paquetes eran típicos de hace unos días. Hoy (pero sí, todavía muy alto):

20:19:37.011762 IP cumm024-0701-dhcp-233.bu.edu.ntp > 103.56.63.147.26656: NTPv2, Reserved, length 152
20:19:37.011900 IP cumm024-0701-dhcp-233.bu.edu.ntp > 202.83.122.78.58066: NTPv2, Reserved, length 152
20:19:37.012036 IP cumm024-0701-dhcp-233.bu.edu.ntp > 103.56.63.147.17665: NTPv2, Reserved, length 152
20:19:37.014539 IP cumm024-0701-dhcp-233.bu.edu.ntp > 202.83.122.78.27945: NTPv2, Reserved, length 152
20:19:37.015482 IP cumm024-0701-dhcp-233.bu.edu.ntp > 202.83.122.78.42426: NTPv2, Reserved, length 152
20:19:37.015644 IP cumm024-0701-dhcp-233.bu.edu.ntp > 103.56.63.147.16086: NTPv2, Reserved, length 152

$ sudo ss -uapn '( sport = :42426 or dport = :42426 )'
State       Recv-Q Send-Q                                                        Local Address:Port                                                          Peer Address:Port

Sí, puedo hacer ping a la IP * .233:

$ping 128.197.112.233
PING 128.197.112.233 (128.197.112.233) 56(84) bytes of data.
64 bytes from 128.197.112.233: icmp_seq=1 ttl=64 time=0.278 ms
64 bytes from 128.197.112.233: icmp_seq=2 ttl=64 time=0.282 ms
64 bytes from 128.197.112.233: icmp_seq=3 ttl=64 time=0.320 ms

No, el MAC no coincide La dirección MAC de mi hardware es: d0: 50: 99: 51: 78: 7a El tráfico está asociado con MAC: bc: 5f: f4: fe: a1: 00

ACTUALIZACIÓN 5: según lo solicitado, un escaneo de puertos contra * .233:

Starting Nmap 6.00 ( http://nmap.org ) at 2016-12-20 20:38 EET
NSE: Loaded 17 scripts for scanning.
Initiating SYN Stealth Scan at 20:38
Scanning cumm024-0701-dhcp-233.bu.edu (128.197.112.233) [1024 ports]
Discovered open port 22/tcp on 128.197.112.233
Completed SYN Stealth Scan at 20:38, 9.79s elapsed (1024 total ports)
Initiating Service scan at 20:38
Scanning 1 service on cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
Completed Service scan at 20:38, 0.37s elapsed (1 service on 1 host)
Initiating OS detection (try #1) against cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
Initiating Traceroute at 20:38
Completed Traceroute at 20:38, 0.10s elapsed
NSE: Script scanning 128.197.112.233.

[+] Nmap scan report for cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
Host is up (0.083s latency).
Not shown: 1013 filtered ports

PORT    STATE  SERVICE VERSION
21/tcp  closed ftp
22/tcp  open   ssh     OpenSSH 5.5p1 Debian 6+squeeze1 (protocol 2.0)
23/tcp  closed telnet
25/tcp  closed smtp
43/tcp  closed whois
80/tcp  closed http
105/tcp closed unknown
113/tcp closed ident
210/tcp closed z39.50
443/tcp closed https
554/tcp closed rtsp

Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:kernel:2.6
OS details: DD-WRT v24-sp2 (Linux 2.6.19)
Uptime guess: 45.708 days (since Sat Nov  5 03:39:36 2016)
Network Distance: 9 hops
TCP Sequence Prediction: Difficulty=204 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel


TRACEROUTE (using port 25/tcp)
HOP RTT      ADDRESS
1   0.95 ms  router1-lon.linode.com (212.111.33.229)
2   0.70 ms  109.74.207.0
3   1.09 ms  be4464.ccr21.lon01.atlas.cogentco.com (204.68.252.85)
4   1.00 ms  be2871.ccr42.lon13.atlas.cogentco.com (154.54.58.185)
5   63.45 ms be2983.ccr22.bos01.atlas.cogentco.com (154.54.1.178)
6   63.60 ms TrusteesOfBostonUniversity.demarc.cogentco.com (38.112.23.118)
7   63.55 ms comm595-core-res01-gi2-3-cumm111-bdr-gw01-gi1-2.bu.edu (128.197.254.125)
8   63.61 ms cumm024-dist-aca01-gi5-2-comm595-core-aca01-gi2-2.bu.edu (128.197.254.206)
9   90.28 ms cumm024-0701-dhcp-233.bu.edu (128.197.112.233)

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 20.73 seconds
           Raw packets sent: 557 (25.462KB) | Rcvd: 97 (8.560KB)

y en UDP:

Starting Nmap 6.00 ( http://nmap.org ) at 2016-12-20 20:44 EET
NSE: Loaded 17 scripts for scanning.
Initiating Ping Scan at 20:44
Scanning 128.197.112.233 [4 ports]
Completed Ping Scan at 20:44, 1.10s elapsed (1 total hosts)
Initiating UDP Scan at 20:44
Scanning cumm024-0701-dhcp-233.bu.edu (128.197.112.233) [1024 ports]
Completed UDP Scan at 20:44, 6.31s elapsed (1024 total ports)
Initiating Service scan at 20:44
Scanning 1024 services on cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
Service scan Timing: About 0.39% done
Service scan Timing: About 3.12% done; ETC: 22:12 (1:25:46 remaining)
Service scan Timing: About 6.05% done; ETC: 21:53 (1:04:39 remaining)
Service scan Timing: About 8.98% done; ETC: 21:46 (0:56:03 remaining)
Discovered open port 123/udp on 128.197.112.233
Discovered open|filtered port 123/udp on cumm024-0701-dhcp-233.bu.edu (128.197.112.233) is actually open
Completed Service scan at 21:31, 2833.50s elapsed (1024 services on 1 host)
Initiating OS detection (try #1) against cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
Retrying OS detection (try #2) against cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
NSE: Script scanning 128.197.112.233.
Initiating NSE at 21:31
Completed NSE at 21:31, 10.02s elapsed

[+] Nmap scan report for cumm024-0701-dhcp-233.bu.edu (128.197.112.233)
Host is up (0.089s latency).
Not shown: 1023 open|filtered ports

PORT    STATE SERVICE VERSION
123/udp open  ntp?

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port123-UDP:V=6.00%I=7%D=12/20%Time=58597D5C%P=x86_64-unknown-linux-gnu
SF:%r(NTPRequest,30,"\xe4\x02\x04\xee\0\0\x8a\xff\0:t\xd9\x84\xa3\x04e\xdb
SF:\xcaeEX\xdbC'\xc5O#Kq\xb1R\xf3\xdc\x03\xfb\xb8\+>U\xab\xdc\x03\xfb\xb8\
SF:+T\xd1\xe9")%r(Citrix,C,"\xde\xc0\x010\x02\0\xa8\xe3\0\0\0\0");

Too many fingerprints match this host to give specific OS details
Network Distance: 9 hops

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 2863.89 seconds
           Raw packets sent: 175 (6.720KB) | Rcvd: 50 (10.088KB)
debian ip network-interface tcpdump ntp Tim Otchy
fuente
3
Parece que su máquina está comprometida e intenta ocultar ese hecho. ¿Cuál es la salida completa de iptables -L -v -ny ip addr ls.
Mark Wagner
2
@TimOtchy Solo para aclarar, cuando desconecta el cable de Ethernet al servidor, ¿lo está haciendo en la parte posterior del servidor o en el conmutador? ¿Tiene un conmutador de repuesto y podría pasar un cable de Ethernet desde el servidor al conmutador pero no tiene nada más (aparte de la alimentación) conectado al conmutador. La idea es tener el enlace habilitado en el servidor pero de otro modo aislado, y ver si se puede acceder a * 233.
icarus
3
Dado (server-> switch no_connection LAN) y puede hacer ping tanto desde el servidor como (server no_connection LAN) y solo puede hacer ping a * .77 desde el servidor, creo que podemos concluir que el servidor también está sirviendo * .233. Siguiente pregunta, ¿es el "servidor" un cuadro "grande"? Estoy pensando que tal vez tenga una CPU de administración de chasis separada o tal vez sea un dispositivo x86 y tenga un dispositivo de monitoreo incorporado. Me inclinaría a ejecutar un escaneo completo de puertos contra * .233 y ver qué puertos están abiertos.
icarus
2
Consulte en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface. Esta es una CPU separada, nada que ver con la CPU principal, la BIOS o el sistema operativo principal.
icarus
2
Parece que la solución debería dirigirse al procesador BMC (IPMI), que ejecuta ssh (y Linux de acuerdo con la suposición de nmap). El sitio de Asrock tiene software desde el 23 de marzo de 2016, pero supongo que eso no ayudará. Mi pensamiento es ver si puedes ingresar a la dirección * 233. ¿Supongo que necesitarías configurar un nombre de usuario y contraseña, tal vez en la configuración del BIOS en las opciones de BMC?
icarus

Respuestas:

12

Esta es una máquina de clase de servidor con IPMI. El servidor NTP "fantasma" que está causando el problema se ejecuta en el procesador BMC del sistema y no en la CPU principal.

Ícaro
fuente
Acabo de pasar las 24 horas sin ningún tráfico NTP nuevo desde este mac / IP. Absolutamente, el procesador BMC ejecutaba una versión de firmware muy antigua y hacía uso de un paquete NTP aún vulnerable a la explotación de amplificación. ¡Gracias por toda su ayuda para solucionar esto!
Tim Otchy
8

Como ya se ha dicho, su IPMI BMC es (probablemente) el problema. Si no puede acceder a la interfaz web o ssh de la interfaz IPMI, puede intentar obtener acceso utilizando la herramienta IPMI en su instalación de Debian:

apt install ipmitool

Una vez instalado, puede pasar comandos al BMC de esta manera (si está en el puerto 1):

ipmitool lan set 1 ipaddr 192.168.1.211

Aquí hay un recurso para la configuración de red IPMI con IPMITool . man ipmitoolsiempre es una buena lectura si te quedas atascado ...

Esta página tiene información sobre cómo restablecer el BMC si es necesario.

¡Buena suerte!

Questionmark
fuente