Máy chủ Ghost NTP trên Debian 8.6


16

Vì vậy, nhóm bảo mật CNTT của trường đại học và tôi đã đi khắp nơi về vấn đề này mà không nghỉ ngơi ... bất cứ ai cũng có suy nghĩ về điều này:

Gần đây tôi đã thiết lập một máy chủ tệp nhỏ cho phòng thí nghiệm của mình chạy Debian 8.6 trên máy tính chuyên dụng (bộ xử lý Intel Avoton C2550 - vui lòng cung cấp thêm thông tin phần cứng nếu cần, nhưng tôi nghĩ không cần thiết). Debian đã cài đặt mà không gặp vấn đề gì, và tại thời điểm đó tôi cũng đã cài đặt Samba, NTP, ZFS và python. Mọi thứ dường như đang hoạt động tốt, vì vậy tôi để nó ngồi và chạy trong góc phòng thí nghiệm trong vài tuần.

Khoảng hai tuần trước, tôi nhận được một email từ nhóm CNTT nói rằng máy chủ của tôi đã bị "xâm phạm" và dễ bị sử dụng trong một cuộc tấn công khuếch đại NTP / DDoS (Tấn công khuếch đại NTP sử dụng CVE-2013-5211 như được mô tả trong https: //www.us-cert.gov/ncas/alerts/TA14-013A ). Dấu hiệu họ chỉ ra là rất nhiều lưu lượng NTPv2 trên cổng 123. Thật kỳ lạ, địa chỉ IP mà họ xác định này đến từ ( *.*.*.233) khác với địa chỉ IP mà máy chủ của tôi được định cấu hình và báo cáo qua ifconfig ( *.*.*.77). Tuy nhiên, một số khắc phục sự cố cơ bản cho thấy máy tính của tôi thực sự tạo ra lưu lượng truy cập này trên cổng 123 (như được tiết lộ bởi tcpdump).

Đây là nơi mà sự kỳ quái bắt đầu. Lần đầu tiên tôi chạy qua các "bản sửa lỗi" được đề xuất cho CVE-2013-5211 (cả cập nhật NTP phiên bản 4.2.7 vừa qua cũng như vô hiệu hóa chức năng danh sách đơn). Không bắt nguồn lưu lượng. Sau đó tôi đã thử chặn cổng UDP 123 thông qua các bảng 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

nhưng điều đó cũng không ảnh hưởng đến giao thông Cuối cùng tôi đã thử thanh lọc NTP khỏi hệ thống, nhưng điều đó cũng không ảnh hưởng đến lưu lượng. Cho đến chiều nay, nmap vẫn báo cáo:

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

Điều này thật kỳ lạ vì NTP đã bị thanh trừng khỏi hệ thống trong nhiều tuần nay.

Sau khi đi vào ngõ cụt trên con đường này, tôi bắt đầu suy nghĩ về toàn bộ vấn đề không khớp địa chỉ IP. Máy tính của tôi dường như đang ngồi trên cả hai IP * .233 và * .77 (như được xác nhận bằng cách ping thành công cả hai với cáp ethernet được gắn và cả hai đều không có sẵn với cáp được rút ra), nhưng * .233 không bao giờ xuất hiện trong 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 

Không có tài liệu tham khảo nào cho * .233 trong / etc / mạng / giao diện, vì vậy tôi không thấy việc chuyển nhượng IP này đến từ đâu.

Vì vậy, tôi có hai câu hỏi có khả năng liên quan. Tôi hy vọng ai đó có thể giúp tôi: 1) Làm cách nào tôi có thể loại bỏ lưu lượng NTP này khỏi việc phun ra từ máy chủ của tôi để đưa IT ra khỏi lưng? 2) Điều gì xảy ra với địa chỉ IP thứ hai này mà máy chủ của tôi đang ngồi và làm cách nào để xóa nó?

Cảm ơn ba mẹ :)

CẬP NHẬT: Theo yêu cầu: $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

CẬP NHẬT 2: Tôi không đề cập đến việc ngoài địa chỉ IP không khớp, ID MAC cũng không khớp. Điều này thực sự khiến tôi suy nghĩ hai lần về việc liệu lưu lượng truy cập có thực sự đến từ máy của tôi không. Tuy nhiên: (1) rút phích cắm máy chủ của tôi khỏi mạng khiến lưu lượng truy cập biến mất; (2) di chuyển đến một cổng mạng khác và lưu lượng theo sau; và (3) tcpdump port 123cho thấy lưu lượng truy cập bất thường:

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

CẬP NHẬT 3: $ss -uapn 'sport = :123'

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

(tức là không có gì)

$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

CẬP NHẬT 4: Những gói đó là điển hình của một vài ngày trước. Hôm nay (nhưng có, vẫn còn rất cao):

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 

Có, tôi có thể ping 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

Không, MAC không khớp với địa chỉ MAC phần cứng của tôi là: d0: 50: 99: 51: 78: 7a Lưu lượng truy cập được liên kết với MAC: bc: 5f: f4: fe: a1: 00

CẬP NHẬT 5: Theo yêu cầu, quét cổng so với * .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)

và trên 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)

3
Âm thanh như máy của bạn bị xâm phạm và cố gắng che giấu sự thật đó. Sản lượng đầy đủ của iptables -L -v -nvà là gì ip addr ls.
Đánh dấu Wagner

2
@TimOtchy Chỉ cần làm rõ, khi bạn ngắt kết nối cáp ethernet với máy chủ, bạn đang thực hiện việc đó ở phía sau máy chủ hay tại công tắc? Bạn có công tắc dự phòng không và bạn có thể chạy cáp ethernet từ máy chủ đến công tắc nhưng không có gì khác (ngoài nguồn) được cắm vào công tắc. Ý tưởng là để liên kết được kích hoạt trên máy chủ nhưng nếu không thì nó sẽ bị cô lập và xem * 233 có thể truy cập được không.
icarus

3
Được cung cấp (máy chủ-> chuyển no_connection LAN) và bạn có thể ping cả từ máy chủ và (máy chủ no_connection LAN) và bạn chỉ có thể ping * .77 từ máy chủ, tôi nghĩ rằng chúng tôi có thể kết luận rằng máy chủ cũng đang phục vụ * .233. Câu hỏi tiếp theo, "máy chủ" có phải là hộp "lớn" không? Tôi nghĩ rằng có thể nó có CPU quản lý khung gầm riêng hoặc có thể nó là thiết bị x86 và có thiết bị giám sát sẵn có. Tôi sẽ có xu hướng chạy quét toàn bộ cổng so với * .233 và xem cổng nào đang mở.
icarus

2
Xem en.wikipedia.org/wiki/Intellect_Pl platform_Quản lý_Interface đây là một CPU riêng biệt, không liên quan gì đến cpu chính, bios hoặc HĐH chính.
icarus

2
Có vẻ như bản sửa lỗi phải xử lý bộ xử lý BMC (IPMI) đang chạy ssh (và linux theo phỏng đoán từ nmap). Trang web Asrock có phần mềm từ ngày 23 tháng 3 năm 2016 trên đó, nhưng tôi đoán là điều đó sẽ không giúp ích gì. Tôi nghĩ là để xem liệu bạn có thể ssh vào địa chỉ * 233 không. Tôi đoán rằng bạn sẽ cần phải thiết lập tên người dùng và mật khẩu, có lẽ trong cài đặt BIOS trong tùy chọn BMC ???
icarus

Câu trả lời:


12

Đây là một máy chủ lớp máy chủ với IPMI. Máy chủ NTP "ma" gây ra sự cố đang chạy trên bộ xử lý BMC trên hệ thống chứ không phải CPU chính.


Chỉ cần thực hiện trong vòng 24 giờ mà không có bất kỳ lưu lượng NTP mới nào từ mac / IP này. Hoàn toàn là bộ xử lý BMC chạy phiên bản phần sụn rất cũ và việc sử dụng gói NTP vẫn dễ bị khai thác khuếch đại. Cảm ơn tất cả sự giúp đỡ của bạn trong việc sửa lỗi này!
Tim Otchy

8

Như đã nói, IPMI BMC của bạn (có lẽ) là vấn đề. Nếu bạn không thể truy cập vào giao diện web hoặc giao diện ssh của giao diện IPMI, bạn có thể thử truy cập bằng Công cụ IPMI trên bản cài đặt Debian của mình:

apt install ipmitool

Sau khi cài đặt, bạn có thể truyền lệnh cho BMC như thế này (nếu nó ở cổng 1):

ipmitool lan set 1 ipaddr 192.168.1.211

Đây là một tài nguyên cho cấu hình mạng IPMI với IPMITool . man ipmitoolluôn luôn là một đọc tốt nếu bạn gặp khó khăn ...

Trang này có thông tin về việc đặt lại BMC nếu bạn cần.

Chúc may mắn!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.