Ghost NTP-сервер на Debian 8.6

Таким образом, команда ИТ-безопасности в университете и я обходились вокруг этого без перерывов … у кого-нибудь есть мысли по этому поводу:

Недавно я установил небольшой файловый сервер для своей лаборатории, на которой работает Debian 8.6 на выделенном компьютере (процессор Intel Avoton C2550 – с удовольствием предоставит больше информации о аппаратном обеспечении, если это необходимо, но я считаю ненужным). Debian установлен без проблем, и в то время я также установил Samba, NTP, ZFS и python. Казалось, что все работает нормально, поэтому я позволил ему сидеть и бегать в углу лаборатории в течение нескольких недель.

Около двух недель назад я получил электронное письмо от ИТ-специалиста, в котором говорилось, что мой сервер был «взломан» и уязвим для использования в NTP-усилении / DDoS-атаке (NTP Amplification Attacks с использованием CVE-2013-5211, как описано в https: //www.us-cert.gov/ncas/alerts/TA14-013A ). Знак, на который они указали, был большим количеством трафика NTPv2 на порте 123. Как ни странно, IP-адрес, который они идентифицировали, исходя из ( *.*.*.233 ), отличался от IP-адреса, на который был настроен мой сервер и сообщил через ifconfig ( *.*.*.77 ). Тем не менее, некоторые основные способы устранения неполадок показали, что мой компьютер действительно генерировал этот трафик на порту 123 (как показано tcpdump).

Здесь началась странность. Сначала я воспользовался «исправлениями», рекомендованными для CVE-2013-5211 (как обновление NTP прошлой версии 4.2.7, так и отключение функций списка). Ничто не препятствовало потоку трафика. Затем я попытался заблокировать порт UDP 123 через таблицы 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 

но это тоже не повлияло на трафик. Я, наконец, попытался очистить NTP от системы, но это также не повлияло на трафик. С сегодняшнего дня nmap все еще сообщал:

 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 

Это очень странно, так как NTP уже очищается от системы уже несколько недель.

После того, как я зашел в тупик по этому пути, я начал думать о проблеме несоответствия IP-адресов. Мой компьютер, казалось, сидел на обоих IP-адресах * .233 и * .77 (что подтверждается успешным пингом как с подключенным кабелем Ethernet, так и с недоступным при отсоединении кабеля), но * .233 никогда не появляется в 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 

Ссылка на * .233 отсутствует в / etc / network / interfaces, поэтому я не вижу, откуда это назначение IP.

Итак, у меня есть два вероятных связанных вопроса. Я надеюсь, что кто-то может мне помочь: 1) Как я могу устранить этот трафик NTP из-за извержения с моего сервера, чтобы избавиться от меня? 2) Что случилось с этим вторым IP-адресом, на котором мой сервер сидит, и как его удалить?

Спасибо, ребята 🙂

UPDATE: по запросу: $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 

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

ОБНОВЛЕНИЕ 2: Я не упомянул, что помимо IP-адреса, не совпадающего, MAC-идентификатор также не совпал. Это действительно заставило меня дважды подумать о том, действительно ли трафик поступает с моей машины. Однако: (1) отсоединение моего сервера от сети привело к исчезновению трафика; (2) переход на другой сетевой порт и последующий трафик; и (3) tcpdump port 123 показал аберрантный трафик:

 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 

(т. е. ничего)

$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 

ОБНОВЛЕНИЕ 4: Эти пакеты были типичными для нескольких дней назад. Сегодня (но да, все еще очень высокий):

 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 

Да, я могу выполнить ping * .233 IP:

 $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 

Нет, MAC не совпадает. Мой аппаратный MAC-адрес: d0: 50: 99: 51: 78: 7a Трафик ассоциируется с MAC: bc: 5f: f4: fe: a1: 00

ОБНОВЛЕНИЕ 5: в соответствии с запросом сканирование портов на * .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) 

и по 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) 

Это машина класса сервера с IPMI. «Призрачный» NTP-сервер, который вызывает проблему, работает на процессоре BMC в системе, а не на главном CPU.

Как уже было сказано, ваш IPMI BMC (вероятно) является проблемой. Если вы не можете перейти на веб-интерфейс или интерфейс ssh интерфейса IPMI, вы можете попытаться получить доступ с помощью IPMI Tool на вашей установке Debian:

 apt install ipmitool 

После установки вы можете передавать команды в BMC, как это (если он находится на порту 1):

 ipmitool lan set 1 ipaddr 192.168.1.211 

Вот ресурс для настройки сети IPMI с помощью IPMITool . man ipmitool всегда хорошо читает, если вы застряли …

На этой странице есть информация о сбросе BMC, если вам нужно.

Удачи!