Serveur NTP fantôme sur Debian 8.6

16

Donc, l'équipe de sécurité informatique de l'université et moi avons fait le tour de la question sans interruption ... tout le monde a des réflexions à ce sujet:

J'ai récemment installé un petit serveur de fichiers pour mon laboratoire exécutant Debian 8.6 sur un ordinateur dédié (processeur Intel Avoton C2550 - heureux de fournir plus d'informations sur le matériel si nécessaire, mais je pense que ce n'est pas nécessaire). Debian s'est installée sans aucun problème, et à l'époque j'avais également installé Samba, NTP, ZFS et python. Les choses semblaient bien fonctionner, alors je l'ai laissé reposer et courir dans le coin du laboratoire pendant quelques semaines.

Il y a environ deux semaines, j'ai reçu un e-mail de l'équipe informatique m'informant que mon serveur était "compromis" et qu'il était vulnérable lors d'une attaque par amplification NTP / DDoS (NTP Amplification Attacks Using CVE-2013-5211 comme décrit dans https: //www.us-cert.gov/ncas/alerts/TA14-013A ). Le signe vers lequel ils pointaient était un trafic NTPv2 important sur le port 123. Bizarrement, l'adresse IP qu'ils identifiaient en provenance de ( *.*.*.233) était différente de l'adresse IP pour laquelle mon serveur était configuré et signalé via ifconfig ( *.*.*.77). Néanmoins, un dépannage de base a révélé que mon ordinateur générait effectivement ce trafic sur le port 123 (comme l'a révélé tcpdump).

C'est là que la bizarrerie a commencé. J'ai d'abord parcouru les "correctifs" recommandés pour CVE-2013-5211 (à la fois la mise à jour de la version 4.2.7 de NTP et la désactivation de la fonctionnalité de monlist). Ni l'un ni l'autre n'a endigué la circulation. J'ai ensuite essayé de bloquer le port UDP 123 via des tables 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

mais cela aussi n'a eu aucun effet sur le trafic. J'ai finalement essayé de purger NTP du système, mais cela n'a eu aucun effet sur le trafic non plus. Depuis cet après-midi, nmap rapportait toujours:

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

Ce qui est très étrange depuis que le NTP a été purgé du système depuis des semaines maintenant.

Après avoir atteint une impasse sur ce chemin, j'ai commencé à penser à tout le problème de non-correspondance des adresses IP. Mon ordinateur semblait être à la fois sur les adresses IP * .233 et * .77 (comme confirmé en réussissant à cingler à la fois avec un câble Ethernet connecté et à la fois non disponible avec un câble débranché), mais * .233 n'apparaît jamais dans 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

Il n'y a aucune référence à * .233 dans / etc / network / interfaces, donc je ne vois pas d'où vient cette attribution IP.

Donc, j'ai deux questions probablement liées que j'espère que quelqu'un pourra m'aider: 1) Comment puis-je éliminer ce trafic NTP de cracher de mon serveur pour obtenir l'informatique de mon dos? 2) Que se passe-t-il avec cette deuxième adresse IP sur laquelle mon serveur est assis et comment puis-je la supprimer?

Merci les amis :)

MISE À JOUR: Comme demandé: $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

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

MISE À JOUR 2: J'ai omis de mentionner qu'en plus de l'adresse IP ne correspondant pas, l'ID MAC ne correspondait pas non plus. Cela m'a vraiment fait réfléchir à deux fois si le trafic provenait effectivement de ma machine. Cependant: (1) débrancher mon serveur du réseau a fait disparaître le trafic; (2) se déplacer vers un port réseau différent et le trafic a suivi; et (3) a tcpdump port 123montré le trafic aberrant:

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

MISE À JOUR 3: $ss -uapn 'sport = :123'

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

(c.-à-d. rien)

$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

MISE À JOUR 4: Ces paquets étaient typiques d'il y a quelques jours. Aujourd'hui (mais oui, toujours très élevé):

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

Oui, je peux envoyer une requête ping à l'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

Non, le MAC ne correspond pas Mon adresse MAC matérielle est: d0: 50: 99: 51: 78: 7a Le trafic est associé à MAC: bc: 5f: f4: fe: a1: 00

MISE À JOUR 5: Comme demandé, une analyse de port par rapport à * .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)

et sur 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
source
3
On dirait que votre machine est compromise et essaie de cacher ce fait. Quelle est la sortie complète de iptables -L -v -net ip addr ls.
— Mark Wagner
2
@TimOtchy Juste pour clarifier, lorsque vous déconnectez le câble Ethernet du serveur, le faites-vous à l'arrière du serveur ou au niveau du commutateur? Avez-vous un commutateur de rechange et vous pouvez exécuter un câble Ethernet du serveur au commutateur, mais rien d'autre (à part l'alimentation) branché sur le commutateur. L'idée est d'avoir le lien activé sur le serveur mais il est autrement isolé, et voir si * 233 est accessible.
— icare
3
Étant donné (serveur-> commutateur no_connection LAN) et vous pouvez envoyer une requête ping à la fois depuis le serveur, et (serveur no_connection LAN) et vous ne pouvez exécuter une commande ping que * .77 depuis le serveur, je pense que nous pouvons conclure que le serveur sert également * .233. Question suivante, le "serveur" est-il une "grande" boîte? Je pense qu'il a peut-être un processeur de gestion de châssis séparé ou peut-être qu'il s'agit d'un périphérique x86 et d'un périphérique de surveillance intégré. Je serais enclin à exécuter une analyse complète des ports par rapport à * .233 et à voir quels ports sont ouverts.
— icare
2
Voir en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface c'est un CPU séparé, rien à voir avec le processeur principal, le bios ou le système d'exploitation principal.
— icare
2
Il semble que le correctif devrait concerner le processeur BMC (IPMI), qui exécute ssh (et linux selon l'hypothèse de nmap). Le site Asrock a un logiciel à partir du 23 mars 2016, mais je suppose que cela n'aidera pas. Ma pensée est de voir si vous pouvez ssh dans l'adresse * 233. Je suppose que vous auriez besoin de configurer un nom d'utilisateur et un mot de passe, peut-être dans les paramètres du BIOS sous les options BMC ???
— icarus

Réponses:

12

Il s'agit d'une machine de classe serveur avec IPMI. Le serveur NTP "fantôme" à l'origine du problème s'exécute sur le processeur BMC du système et non sur le processeur principal.

— icare
source
Je viens de passer 24 heures sans nouveau trafic NTP à partir de ce mac / IP. Le processeur BMC exécutait absolument une très ancienne version de firmware et utilisait un package NTP encore vulnérable à l'exploit d'amplification. Merci pour toute votre aide pour résoudre ce problème!
— Tim Otchy
8

Comme cela a déjà été dit, votre IPMC BMC est (probablement) le problème. Si vous ne pouvez pas accéder à l'interface Web ou à l'interface ssh de l'interface IPMI, vous pouvez essayer d'obtenir l'accès à l'aide de l'outil IPMI sur votre installation Debian:

apt install ipmitool

Une fois installé, vous pouvez passer des commandes au BMC comme ceci (s'il est sur le port 1):

ipmitool lan set 1 ipaddr 192.168.1.211

Voici une ressource pour la configuration du réseau IPMI avec IPMITool . man ipmitoolest toujours une bonne lecture si vous êtes coincé ...

Cette page contient des informations sur la réinitialisation du BMC si nécessaire.

Bonne chance!

— Point d'interrogation
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.