Server Ghost NTP su Debian 8.6

16

Quindi il team di sicurezza IT dell'università e io abbiamo fatto il giro del mondo senza interruzioni ... qualcuno ha pensato:

Di recente ho creato un piccolo file server per il mio laboratorio con Debian 8.6 su un computer dedicato (processore Intel Avoton C2550 - felice di fornire ulteriori informazioni sull'hardware se necessario, ma ritengo non necessario). Debian è stato installato senza problemi e all'epoca ho installato anche Samba, NTP, ZFS e python. Le cose sembravano funzionare bene, quindi l'ho lasciato sedere e correre nell'angolo del laboratorio per alcune settimane.

Circa due settimane fa, ho ricevuto un'e-mail dal team IT in cui mi diceva che il mio server è stato "compromesso" ed è vulnerabile nell'utilizzo di un amplificazione NTP / attacco DDoS (attacchi di amplificazione NTP usando CVE-2013-5211 come descritto in https: //www.us-cert.gov/ncas/alerts/TA14-013A ). Il segno che indicavano era un sacco di traffico NTPv2 sulla porta 123. Stranamente, l'indirizzo IP da cui avevano identificato questo ( *.*.*.233) era diverso dall'indirizzo IP per il quale il mio server era configurato e segnalato tramite ifconfig ( *.*.*.77). Tuttavia, alcuni problemi di base hanno rivelato che il mio computer stava effettivamente generando questo traffico sulla porta 123 (come rivelato da tcpdump).

Qui è dove è iniziata la stranezza. Ho prima verificato le "correzioni" consigliate per CVE-2013-5211 (sia aggiornando la versione 4.2.7 precedente di NTP che disabilitando la funzionalità monlist). Nessuno dei due ha bloccato il flusso del traffico. Ho quindi provato a bloccare la porta UDP 123 tramite tabelle 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

ma anche quello non ha avuto alcun effetto sul traffico. Alla fine ho provato a eliminare NTP dal sistema, ma questo non ha avuto alcun effetto sul traffico. A partire da questo pomeriggio, nmap segnalava ancora:

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

Il che è tutto molto strano da quando NTP è stato eliminato dal sistema da settimane ormai.

Dopo aver raggiunto un vicolo cieco in questo percorso, ho iniziato a pensare all'intero problema di mancata corrispondenza dell'indirizzo IP. Il mio computer sembrava essere su entrambi gli IP.

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

Non c'è alcun riferimento a * .233 in / etc / network / interfaces, quindi non vedo da dove provenga questa assegnazione IP.

Quindi, ho due probabili domande correlate che spero che qualcuno possa aiutarmi con: 1) Come posso eliminare questo traffico NTP dallo spargimento dal mio server per togliermi l'IT dalle spalle? 2) Cosa succede con questo secondo indirizzo IP sul quale è seduto il mio server e come posso rimuoverlo?

Grazie gente :)

AGGIORNAMENTO: Come richiesto: $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

E $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

AGGIORNAMENTO 2: Non ho menzionato il fatto che, oltre all'indirizzo IP non corrispondente, anche l'ID MAC non corrispondeva. Questo mi ha fatto riflettere due volte sul fatto che il traffico provenisse effettivamente dalla mia macchina. Tuttavia: (1) scollegare il mio server dalla rete ha fatto scomparire il traffico; (2) passare a un'altra porta di rete e il traffico seguito; e (3) ha tcpdump port 123mostrato il traffico 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

AGGIORNAMENTO 3: $ss -uapn 'sport = :123'

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

(cioè niente)

$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

AGGIORNAMENTO 4: Quei pacchetti erano tipici di qualche giorno fa. Oggi (ma sì, ancora molto 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ì, posso eseguire il ping dell'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, il MAC non corrisponde Il mio indirizzo MAC hardware è: d0: 50: 99: 51: 78: 7a Il traffico è associato al MAC: bc: 5f: f4: fe: a1: 00

AGGIORNAMENTO 5: Come richiesto, un port scan su * .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)

e su 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
fonte
3
Sembra che la tua macchina sia compromessa e cerchi di nascondere questo fatto. Qual è l'output completo di iptables -L -v -ne ip addr ls.
— Mark Wagner,
2
@TimOtchy Solo per chiarire, quando si scollega il cavo Ethernet al server, lo si fa sul retro del server o allo switch? Hai uno switch di riserva e potresti far passare un cavo ethernet dal server allo switch ma non hai nient'altro (a parte l'alimentazione) collegato allo switch. L'idea è di avere il collegamento abilitato sul server ma altrimenti isolato e vedere se * 233 è raggiungibile.
— Icaro,
3
Dato (server-> switch no_connection LAN) e puoi eseguire il ping sia dal server, sia (server no_connection LAN) e puoi solo eseguire il ping * .77 dal server, penso che possiamo concludere che anche il server sta servendo * .233. La prossima domanda, il "server" è una "grande" scatola? Sto pensando che forse ha una CPU di gestione del telaio separata o forse è un dispositivo x86 e ha un dispositivo di monitoraggio integrato. Sarei propenso a eseguire una scansione completa delle porte su * .233 e vedere quali porte sono aperte.
— Icaro,
2
Vedi en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface questa è una CPU separata, nulla a che fare con la CPU principale, il BIOS o il sistema operativo principale.
— Icaro
2
Sembra che la correzione dovrebbe riguardare il processore BMC (IPMI), che esegue ssh (e Linux secondo le ipotesi da nmap). Il sito Asrock ha software dal 23 marzo 2016, ma suppongo che ciò non aiuterà. Il mio pensiero è di vedere se riesci a scrivere nell'indirizzo * 233. Immagino che avresti bisogno di impostare un nome utente e una password, forse nelle impostazioni del BIOS sotto le opzioni BMC ???
— Icaro,

Risposte:

12

Questa è una macchina di classe server con IPMI. Il server NTP "fantasma" che sta causando il problema è in esecuzione sul processore BMC sul sistema e non sulla CPU principale.

— Icaro
fonte
Sono appena riuscito per 24 ore senza alcun nuovo traffico NTP da questo mac / IP. Assolutamente il processore BMC eseguiva una versione firmware molto vecchia e l'utilizzo di un pacchetto NTP era ancora vulnerabile all'exploit di amplificazione. Grazie per tutto il vostro aiuto nel risolvere questo problema!
— Tim Otchy,
8

Come è già stato detto, il tuo BMC IPMI è (probabilmente) il problema. Se non riesci ad accedere all'interfaccia web o all'interfaccia ssh dell'interfaccia IPMI, puoi provare ad accedere usando lo strumento IPMI sulla tua installazione Debian:

apt install ipmitool

Una volta installato, è possibile passare i comandi al BMC in questo modo (se si trova sulla porta 1):

ipmitool lan set 1 ipaddr 192.168.1.211

Ecco una risorsa per la configurazione della rete IPMI con IPMITool . man ipmitoolè sempre una buona lettura se rimani bloccato ...

Questa pagina contiene informazioni sul ripristino del BMC, se necessario.

In bocca al lupo!

— Punto interrogativo
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.