เซิร์ฟเวอร์ Ghost NTP บน Debian 8.6


16

ดังนั้นทีมรักษาความปลอดภัยด้านไอทีของมหาวิทยาลัยและฉันก็เดินไปรอบ ๆ อย่างไม่หยุดหย่อน ... ใครมีความคิดในเรื่องนี้:

ฉันเพิ่งตั้งค่าไฟล์เซิร์ฟเวอร์ขนาดเล็กสำหรับห้องปฏิบัติการที่ใช้ Debian 8.6 บนคอมพิวเตอร์เฉพาะ (โปรเซสเซอร์ Intel Avoton C2550 - ยินดีที่จะให้ข้อมูลฮาร์ดแวร์เพิ่มเติมหากจำเป็น แต่ฉันคิดว่าไม่จำเป็น) Debian ติดตั้งโดยไม่มีปัญหาใด ๆ และในเวลานั้นฉันยังติดตั้ง Samba, NTP, ZFS และ python สิ่งต่าง ๆ ดูเหมือนจะใช้งานได้ดีดังนั้นฉันจึงปล่อยให้มันนั่งทำงานที่มุมห้องแล็บสองสามสัปดาห์

ประมาณสองสัปดาห์ที่ผ่านมาฉันได้รับอีเมลจากทีมไอทีแจ้งว่าเซิร์ฟเวอร์ของฉัน "ถูกโจมตี" และมีความเสี่ยงที่จะถูกใช้ในการขยาย NTP / การโจมตี DDoS (การโจมตีการขยาย NTP โดยใช้ 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 ถูกกำจัดออกจากระบบมาหลายสัปดาห์แล้ว

หลังจากกดปุ่ม Dead Dead บนเส้นทางนี้ฉันเริ่มคิดเกี่ยวกับปัญหาที่อยู่ IP ไม่ตรงกันทั้งหมด คอมพิวเตอร์ของฉันดูเหมือนว่าจะนั่งอยู่ทั้ง * .233 และ * .77 IP (ตามที่ได้รับการยืนยันโดยการกระตุกทั้งสองอย่างด้วยสายเคเบิลอีเทอร์เน็ตที่เชื่อมต่อและทั้งสองไม่สามารถใช้งานได้กับปลั๊กสายเคเบิล) แต่ * .333 ไม่ปรากฏขึ้นใน 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 ที่สองนี้ที่เซิร์ฟเวอร์ของฉันนั่งอยู่และฉันจะลบออกได้อย่างไร

ขอบคุณคน :)

ปรับปรุง: ตามที่ร้องขอ: $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 ID ยังไม่ตรงกัน นี่ทำให้ฉันคิดว่าสองครั้งเกี่ยวกับว่าปริมาณการใช้ข้อมูลมาจากเครื่องของฉันหรือไม่ อย่างไรก็ตาม: (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

อัปเดต 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

UPDATE 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)

3
ฟังดูเหมือนว่าคุณเป็นเครื่องจักรและพยายามซ่อนความจริงนั้น คือผลลัพธ์ที่เต็มรูปแบบของอะไรและiptables -L -v -n ip addr ls
Mark Wagner

2
@TimOtchy เพียงเพื่อชี้แจงเมื่อคุณถอดสายเคเบิลอีเธอร์เน็ตไปยังเซิร์ฟเวอร์คุณกำลังทำอยู่ที่ด้านหลังของเซิร์ฟเวอร์หรือที่สวิตช์? คุณมีสวิตช์สำรองและคุณสามารถเรียกใช้สายเคเบิลอีเธอร์เน็ตจากเซิร์ฟเวอร์ไปยังสวิตช์ แต่ไม่มีอะไรอื่น (นอกเหนือจากพลังงาน) เสียบเข้ากับสวิตช์ แนวคิดคือให้เปิดใช้งานลิงก์บนเซิร์ฟเวอร์ แต่แยกกันและดูว่า * 233 เข้าถึงได้หรือไม่
รัส

3
ได้รับ (เซิร์ฟเวอร์ -> สลับ no_connection LAN) และคุณสามารถ ping ได้ทั้งจากเซิร์ฟเวอร์และ (เซิร์ฟเวอร์ no_connection LAN) และคุณสามารถ ping * .77 จากเซิร์ฟเวอร์เท่านั้นฉันคิดว่าเราสามารถสรุปได้ว่าเซิร์ฟเวอร์ยังให้บริการ * .233 ด้วย คำถามต่อไปคือ "เซิร์ฟเวอร์" เป็นกล่อง "ใหญ่" หรือไม่ ฉันคิดว่าบางทีมันอาจมีซีพียูในการจัดการแชสซีแยกต่างหากหรืออาจเป็นอุปกรณ์ x86 และมีอุปกรณ์ตรวจสอบในตัว ฉันมีแนวโน้มที่จะเรียกใช้การสแกนพอร์ตแบบเต็มกับ * .233 และดูว่าพอร์ตใดเปิดอยู่
รัส

2
ดูen.wikipedia.org/wiki/Intelligent_Platform_Management_Interfaceนี่เป็นซีพียูแยกต่างหากไม่มีส่วนเกี่ยวข้องกับซีพียูหลักไบออสหรือระบบปฏิบัติการหลัก
รัส

2
ดูเหมือนว่าการแก้ไขควรจะอยู่หน่วยประมวลผล BMC (IPMI) ซึ่งกำลังเรียกใช้ ssh (และ linux ตามการเดาจาก nmap) เว็บไซต์ Asrock มีซอฟต์แวร์ตั้งแต่วันที่ 23 มีนาคม 2559 แต่ฉันเดาว่านั่นจะไม่ช่วย ความคิดของฉันคือการดูว่าคุณสามารถ ssh ลงในที่อยู่ * 233 ฉันเดาว่าคุณจะต้องตั้งค่าชื่อผู้ใช้และรหัสผ่านบางทีในการตั้งค่า BIOS ภายใต้ตัวเลือก BMC ???
รัส

คำตอบ:


12

นี่เป็นเครื่องคลาสเซิร์ฟเวอร์ที่มี IPMI เซิร์ฟเวอร์ NTP "ghost" ที่เป็นสาเหตุของปัญหากำลังทำงานบนตัวประมวลผล BMC บนระบบไม่ใช่ CPU หลัก


ทำได้เพียงตลอด 24 ชั่วโมงโดยไม่มีการรับส่งข้อมูล NTP ใหม่จาก mac / IP นี้ ตัวประมวลผล BMC อย่างแน่นอนนั้นใช้เวอร์ชั่นเฟิร์มแวร์ที่เก่ามากและการใช้แพ็คเกจ NTP ยังคงมีช่องโหว่ต่อการขยายช่องโหว่ ขอบคุณสำหรับความช่วยเหลือในการแก้ไขปัญหานี้!
Tim Otchy

8

ตามที่ได้กล่าวไปแล้ว IPMI BMC ของคุณอาจเป็นปัญหา หากคุณไม่สามารถเข้าถึงเว็บอินเตอร์เฟสหรืออินเตอร์เฟส ssh ของอินเทอร์เฟซ IPMI ได้คุณสามารถลองเข้าถึงโดยใช้เครื่องมือ IPMI ในการติดตั้ง Debian ของคุณ:

apt install ipmitool

เมื่อติดตั้งแล้วคุณสามารถส่งคำสั่งไปยัง BMC เช่นนี้ (ถ้าอยู่ในพอร์ต 1):

ipmitool lan set 1 ipaddr 192.168.1.211

นี่เป็นทรัพยากรสำหรับการกำหนดค่าเครือข่าย IPMI กับ IPMITool man ipmitoolเป็นการอ่านที่ดีเสมอหากคุณติดอยู่ ...

หน้านี้มีข้อมูลเกี่ยวกับการรีเซ็ต BMCหากคุณต้องการ

โชคดี!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.