Ghost-NTP-Server unter Debian 8.6

16

Also haben das IT-Sicherheitsteam der Universität und ich ohne Unterbrechungen herumgespielt ... irgendjemand hat sich Gedanken darüber gemacht:

Ich habe vor kurzem einen kleinen Dateiserver für mein Labor eingerichtet, auf dem Debian 8.6 auf einem dedizierten Computer ausgeführt wird (Intel Avoton C2550-Prozessor - stellt bei Bedarf gerne weitere Hardwareinformationen zur Verfügung, halte dies jedoch für unnötig). Debian wurde ohne Probleme installiert, und zu der Zeit installierte ich auch Samba, NTP, ZFS und Python. Die Dinge schienen gut zu funktionieren, also ließ ich es ein paar Wochen in der Ecke des Labors sitzen und rennen.

Vor ungefähr zwei Wochen erhielt ich eine E-Mail vom IT-Team, in der darauf hingewiesen wurde, dass mein Server "kompromittiert" und anfällig für die Verwendung bei einem NTP-Amplification / DDoS-Angriff (NTP Amplification Attacks Using CVE-2013-5211, siehe https: //www.us-cert.gov/ncas/alerts/TA14-013A ). Das Zeichen, auf das sie zeigten, war viel NTPv2-Verkehr an Port 123. Seltsamerweise unterschied sich die IP-Adresse, die sie als von ( *.*.*.233) kommend identifiziert hatten, von der IP-Adresse, für die mein Server konfiguriert war und die sie über ifconfig ( *.*.*.77) meldeten . Einige grundlegende Fehlerbehebungsmaßnahmen haben jedoch ergeben, dass mein Computer tatsächlich diesen Datenverkehr auf Port 123 generiert hat (wie durch tcpdump angezeigt).

Hier begann die Bizarrheit. Ich habe zuerst die für CVE-2013-5211 empfohlenen "Fixes" durchgearbeitet (sowohl das Aktualisieren der NTP-Version 4.2.7 als auch das Deaktivieren der Monlist-Funktionalität). Beides störte den Verkehrsfluss nicht. Ich habe dann versucht, den UDP 123-Port über IP-Tabellen zu blockieren:

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

aber auch das hatte keinen einfluss auf den verkehr. Ich habe schließlich versucht, NTP aus dem System zu entfernen, aber das hatte auch keine Auswirkungen auf den Datenverkehr. Ab heute Nachmittag berichtete nmap noch:

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

Das ist alles sehr seltsam, da NTP seit Wochen aus dem System entfernt wird.

Nachdem ich auf diesem Weg eine Sackgasse erreicht hatte, begann ich über das gesamte Problem der Nichtübereinstimmung von IP-Adressen nachzudenken. Mein Computer schien auf beiden * .233- und * .77-IP-Adressen zu sitzen (was durch das erfolgreiche Pingen beider IP-Adressen mit angeschlossenem und nicht verfügbarem Ethernet-Kabel bestätigt wurde), aber * .233 wird in ifconfig nie angezeigt:

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

Da in / etc / network / interfaces kein Verweis auf * .233 vorhanden ist, sehe ich nicht, woher diese IP-Zuweisung stammt.

Ich hoffe also, dass mir zwei Fragen helfen können: 1) Wie kann ich verhindern, dass dieser NTP-Verkehr von meinem Server ausgeht, um die IT von meinem Rücken zu bekommen? 2) Was ist mit dieser zweiten IP-Adresse los, auf der sich mein Server befindet, und wie kann ich sie entfernen?

Danke Leute :)

UPDATE: Wie gewünscht: $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

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

UPDATE 2: Ich habe nicht erwähnt, dass zusätzlich zu der nicht übereinstimmenden IP-Adresse auch die MAC-ID nicht übereinstimmt. Das ließ mich zweimal darüber nachdenken, ob der Verkehr tatsächlich von meiner Maschine kam. Jedoch: (1) das Trennen meines Servers vom Netzwerk hat den Datenverkehr verschwinden lassen; (2) Wechseln Sie zu einem anderen Netzwerkport, und folgen Sie dem Datenverkehr. und (3) tcpdump port 123zeigten den abweichenden Verkehr:

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

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

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

(dh nichts)

$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

UPDATE 4: Diese Pakete waren typisch für einige Tage zuvor. Heute (aber ja, immer noch sehr hoch):

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

Ja, ich kann die * .233 IP anpingen:

$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

Nein, der MAC stimmt nicht überein Meine Hardware-MAC-Adresse lautet: d0: 50: 99: 51: 78: 7a Der Datenverkehr wird mit MAC: bc: 5f: f4: fe: a1: 00 verknüpft

UPDATE 5: Auf Wunsch ein Port-Scan gegen * .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)

und auf 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
quelle
3
Klingt so, als ob Ihre Maschine kompromittiert ist und versucht, diese Tatsache zu verbergen. Was ist die volle Leistung von iptables -L -v -nund ip addr ls.
Mark Wagner
2
@TimOtchy Nur um zu verdeutlichen, wenn Sie das Ethernet-Kabel vom Server trennen, tun Sie dies auf der Rückseite des Servers oder am Switch? Haben Sie einen Ersatz-Switch und Sie könnten ein Ethernet-Kabel vom Server zum Switch führen, aber nichts anderes (außer Strom) an den Switch anschließen. Die Idee ist, den Link auf dem Server zu aktivieren, aber ansonsten zu isolieren und zu prüfen, ob * 233 erreichbar ist.
Ikarus
3
Wenn (server-> switch no_connection LAN) und Sie sowohl vom Server als auch (server no_connection LAN) pingen können und Sie nur * .77 vom Server pingen können, können wir davon ausgehen, dass der Server auch * .233 bedient. Nächste Frage, ist der "Server" eine "große" Box? Ich denke, dass es möglicherweise eine unterschiedliche Chassis-Management-CPU hat oder möglicherweise es ein x86-Gerät ist und ein eingebautes Überwachungsgerät hat. Ich wäre geneigt, einen vollständigen Port-Scan für * .233 durchzuführen und festzustellen, welche Ports offen sind.
Ikarus
2
Siehe en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface Dies ist eine separate CPU, die nichts mit der Haupt-CPU, dem BIOS oder dem Haupt-Betriebssystem zu tun hat.
Ikarus
2
Es sieht so aus, als ob das Update den BMC (IPMI) -Prozessor ansprechen sollte, auf dem ssh (und Linux laut der Schätzung von nmap) ausgeführt wird. Die Asrock-Site enthält Software vom 23. März 2016, aber ich vermute, dass das nicht helfen wird. Mein Gedanke ist, zu sehen, ob Sie in die * 233-Adresse ssh können. Ich würde vermuten, dass Sie einen Benutzernamen und ein Passwort einrichten müssen, vielleicht in den BIOS-Einstellungen unter BMC-Optionen?
Ikarus

Antworten:

12

Dies ist eine Maschine der Serverklasse mit IPMI. Der "Ghost" -NTP-Server, der das Problem verursacht, wird auf dem BMC-Prozessor des Systems und nicht auf der Haupt-CPU ausgeführt.

icarus
quelle
Ich habe gerade 24 Stunden ohne neuen NTP-Verkehr von diesem Mac / IP überstanden. Auf jeden Fall wurde auf dem BMC-Prozessor eine sehr alte Firmware-Version ausgeführt, und die Verwendung eines NTP-Pakets war immer noch anfällig für den Amplification-Exploit. Vielen Dank für all Ihre Hilfe bei der Behebung dieses Problems!
Tim Otchy
8

Wie bereits gesagt, ist Ihr IPMI-BMC (wahrscheinlich) das Problem. Wenn Sie nicht auf die Web-Oberfläche oder die ssh-Oberfläche der IPMI-Oberfläche zugreifen können, können Sie versuchen, mit dem IPMI-Tool auf Ihre Debian-Installation zuzugreifen:

apt install ipmitool

Nach der Installation können Sie Befehle wie folgt an den BMC übergeben (wenn er sich an Port 1 befindet):

ipmitool lan set 1 ipaddr 192.168.1.211

Hier finden Sie eine Ressource für die IPMI-Netzwerkkonfiguration mit IPMITool . man ipmitoolist immer eine gute Lektüre, wenn Sie stecken bleiben ...

Auf dieser Seite finden Sie Informationen zum Zurücksetzen des BMC, falls erforderlich.

Viel Glück!

Fragezeichen
quelle