Ping
UFW 奇怪的 ICMP 日誌記錄 - Ping 被阻止
在下面的日誌記錄中，我將我的 eth MAC 地址替換
ETH_MAC_ADDRESS為我的伺服器的 IP，MY_SERVER_IP並將其他 IP 替換為STRANGE_IP加號以區分。Jan 29 15:11:48 cld kernel: [140229.731612] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_1 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=53 ID=46005 PROTO=ICMP TYPE=3 CODE=3 [SRC=MY_SERVER_IP DST=STRANGE_IP_1 LEN=79 TOS=0x00 PREC=0x00 TTL=233 ID=55136 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.790143] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47474 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=43802 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.803157] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47475 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=36766 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.816160] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47476 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=26493 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.831386] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47477 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=3269 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.844130] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47478 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=20707 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.856986] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_4 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0x00 TTL=52 ID=29529 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_4 LEN=79 TOS=0x00 PREC=0x00 TTL=242 ID=33191 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.844130] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_2 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0xC0 TTL=57 ID=47478 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_3 LEN=79 TOS=0x00 PREC=0x00 TTL=247 ID=20707 PROTO=UDP SPT=30910 DPT=389 LEN=59 ] Jan 29 15:11:48 cld kernel: [140229.856986] [UFW BLOCK] IN=eth0 OUT= MAC=ETH_MAC_ADDRESS SRC=STRANGE_IP_4 DST=MY_SERVER_IP LEN=107 TOS=0x00 PREC=0x00 TTL=52 ID=29529 PROTO=ICMP TYPE=3 CODE=1 [SRC=MY_SERVER_IP DST=STRANGE_IP_4 LEN=79 TOS=0x00 PREC=0x00 TTL=242 ID=33191 PROTO=UDP SPT=30910 DPT=389 LEN=59 ]如您所見，目標 IP 在記錄的第一部分始終是我的伺服器 IP，而源 IP 是第二部分。所有其他IP都不相同。
這持續了大約4個小時。在那段時間裡，伺服器的 CPU 負載非常低，甚至 SSH 連接都斷開了。
ping 被 ufw 防火牆的前規則阻止。
這是DDos攻擊嗎？值得一提的是，幾天前我們遇到了 DDos 攻擊，而前一天我們嘗試了 DDos 攻擊，我們在 Cloudflare 儀表板中添加了防火牆規則來阻止該攻擊。
有人可以解釋如何辨識括號中的第二部分
$$ $$日誌中的每條記錄？ 貓 /etc/ufw/before.rules
# # rules.before # # Rules that should be run before the ufw command line added rules. Custom # rules should be added to one of these chains: # ufw-before-input # ufw-before-output # ufw-before-forward # # Don't delete these required lines, otherwise there will be errors *filter :ufw-before-input - [0:0] :ufw-before-output - [0:0] :ufw-before-forward - [0:0] :ufw-not-local - [0:0] # End required lines # allow all on loopback -A ufw-before-input -i lo -j ACCEPT -A ufw-before-output -o lo -j ACCEPT # quickly process packets for which we already have a connection -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # drop INVALID packets (logs these in loglevel medium and higher) -A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny -A ufw-before-input -m conntrack --ctstate INVALID -j DROP # ok icmp codes for INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP -A ufw-before-input -p icmp --icmp-type source-quench -j DROP -A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP -A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP -A ufw-before-input -p icmp --icmp-type echo-request -j DROP # ok icmp code for FORWARD -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-forward -p icmp --icmp-type source-quench -j ACCEPT -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT # allow dhcp client to work -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT # # ufw-not-local # -A ufw-before-input -j ufw-not-local # if LOCAL, RETURN -A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN # if MULTICAST, RETURN -A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN # if BROADCAST, RETURN -A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN # all other non-local packets are dropped -A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny -A ufw-not-local -j DROP # allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above # is uncommented) -A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT # allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above # is uncommented) -A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT # don't delete the 'COMMIT' line or these rules won't be processed COMMITUFW的規則。
ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 20/tcp ALLOW IN Anywhere 21/tcp ALLOW IN Anywhere 22/tcp ALLOW IN Anywhere 25/tcp ALLOW IN Anywhere 53/tcp ALLOW IN Anywhere 80/tcp ALLOW IN Anywhere 110/tcp ALLOW IN Anywhere 143/tcp ALLOW IN Anywhere 443/tcp ALLOW IN Anywhere 587/tcp ALLOW IN Anywhere 993/tcp ALLOW IN Anywhere 995/tcp ALLOW IN Anywhere 3306/tcp ALLOW IN Anywhere 8080/tcp ALLOW IN Anywhere 8081/tcp ALLOW IN Anywhere 10000/tcp ALLOW IN Anywhere 53/udp ALLOW IN Anywhere 3306/udp ALLOW IN Anywhere 2408/tcp ALLOW IN 173.245.48.0/20 2408/tcp ALLOW IN 103.21.244.0/22 2408/tcp ALLOW IN 103.22.200.0/22 2408/tcp ALLOW IN 103.31.4.0/22 2408/tcp ALLOW IN 141.101.64.0/18 2408/tcp ALLOW IN 108.162.192.0/18 2408/tcp ALLOW IN 190.93.240.0/20 2408/tcp ALLOW IN 188.114.96.0/20 2408/tcp ALLOW IN 197.234.240.0/22 2408/tcp ALLOW IN 198.41.128.0/17 2408/tcp ALLOW IN 162.158.0.0/15 2408/tcp ALLOW IN 104.16.0.0/12 2408/tcp ALLOW IN 172.64.0.0/13 2408/tcp ALLOW IN 131.0.72.0/22 22/tcp (OpenSSH) ALLOW IN Anywhere 143/tcp (Dovecot IMAP) ALLOW IN Anywhere 993/tcp (Dovecot Secure IMAP) ALLOW IN Anywhere 25/tcp (Postfix) ALLOW IN Anywhere 465/tcp (Postfix SMTPS) ALLOW IN Anywhere 587/tcp (Postfix Submission) ALLOW IN Anywhere 20/tcp (v6) ALLOW IN Anywhere (v6) 21/tcp (v6) ALLOW IN Anywhere (v6) 22/tcp (v6) ALLOW IN Anywhere (v6) 25/tcp (v6) ALLOW IN Anywhere (v6) 53/tcp (v6) ALLOW IN Anywhere (v6) 80/tcp (v6) ALLOW IN Anywhere (v6) 110/tcp (v6) ALLOW IN Anywhere (v6) 143/tcp (v6) ALLOW IN Anywhere (v6) 443/tcp (v6) ALLOW IN Anywhere (v6) 587/tcp (v6) ALLOW IN Anywhere (v6) 993/tcp (v6) ALLOW IN Anywhere (v6) 995/tcp (v6) ALLOW IN Anywhere (v6) 3306/tcp (v6) ALLOW IN Anywhere (v6) 8080/tcp (v6) ALLOW IN Anywhere (v6) 8081/tcp (v6) ALLOW IN Anywhere (v6) 10000/tcp (v6) ALLOW IN Anywhere (v6) 53/udp (v6) ALLOW IN Anywhere (v6) 3306/udp (v6) ALLOW IN Anywhere (v6) 22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6) 143/tcp (Dovecot IMAP (v6)) ALLOW IN Anywhere (v6) 993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN Anywhere (v6) 25/tcp (Postfix (v6)) ALLOW IN Anywhere (v6) 465/tcp (Postfix SMTPS (v6)) ALLOW IN Anywhere (v6) 587/tcp (Postfix Submission (v6)) ALLOW IN Anywhere (v6) 2408/tcp ALLOW IN 2400:cb00::/32 2408/tcp ALLOW IN 2606:4700::/32 2408/tcp ALLOW IN 2803:f800::/32 2408/tcp ALLOW IN 2405:b500::/32 2408/tcp ALLOW IN 2405:8100::/32 2408/tcp ALLOW IN 2a06:98c0::/29 2408/tcp ALLOW IN 2c0f:f248::/32更新：
還有一些奇怪的 SSH(?) 連接：
網路統計-nt | 握力：22
tcp 0 69 MYSERVERIP:22 STRANGEIP_1:44930 FIN_WAIT1 tcp 0 68 MYSERVERIP:22 STRANGEIP_2:37007 ESTABLISHED tcp 0 1 MYSERVERIP:22 STRANGEIP_3:40132 LAST_ACK tcp 0 68 MYSERVERIP:22 STRANGEIP_4:50132 ESTABLISHED tcp 0 68 MYSERVERIP:22 STRANGEIP_5:38939 ESTABLISHED tcp 0 0 MYSERVERIP:22 MYIP:52118 ESTABLISHED tcp 0 68 MYSERVERIP:22 STRANGEIP_6:43152 ESTABLISHED tcp 0 68 MYSERVERIP:22 STRANGEIP_7:39321 ESTABLISHED tcp 0 64 MYSERVERIP:22 MYIP:52001 ESTABLISHED tcp 0 68 MYSERVERIP:22 STRANGEIP_8:39732 ESTABLISHED網路統計-nputw | grep ‘sshd’
tcp 0 68 MYSERVERIP:22 STRANGEIP_2:37007 ESTABLISHED 2525/sshd: unknown tcp 0 68 MYSERVERIP:22 STRANGEIP_5:38939 ESTABLISHED 2558/sshd: unknown tcp 0 0 MYSERVERIP:22 MYIP:52118 ESTABLISHED 15911/sshd: root@no tcp 0 68 MYSERVERIP:22 STRANGEIP_7:39321 ESTABLISHED 2466/sshd: root [pr tcp 0 64 MYSERVERIP:22 MYIP:52001 ESTABLISHED 15554/sshd: root@pt tcp 0 68 MYSERVERIP:22 STRANGEIP_8:39732 ESTABLISHED 2596/sshd: unknown以上是現在，但伺服器似乎沒有問題，並且 UFW 沒有記錄初始請求。
簽入 /var/log/auth.log 後，上面的內容只是
authentication failure. 我不知道他們出現在 netstat 中。最好的祝福
這些是標準的 ICMPv4 響應。您可以通過類型和程式碼準確判斷目標主機正在向您的主機發送什麼響應。
在這兩種情況下，類型都是 3，無法到達目的地。第一種情況的程式碼是3，埠不可達，第二種情況的程式碼是1，主機不可達。第一個 ICMP 響應將導致程序返回（可能更熟悉的）錯誤
Connection refused，第二個將返回錯誤No route to host。諸如此類的 ICMP 響應會返回導致響應的數據包的副本。此處，該數據包顯示在方括號中。它在目標埠 389 上顯示從您的 IP 地址到每個遠端伺服器的UDP 流量。
由於每個數據包的源埠都相同，因此該流量很可能被欺騙：它很可能來自某個不可知的地方，並且是專門發送的，以便這些 ICMP 響應到達您的系統。這可能是一次拒絕服務的嘗試，但如果是這樣，那是一次非常糟糕的嘗試。這也可能是試圖通過虛假流量向您的服務提供商提出濫用投訴。也可能是有人試圖攻擊那些遠端系統，並且不小心使用了您的 IP 地址而不是他自己的 IP 地址作為源。
雖然它很可能是欺騙性流量，但它實際上有可能確實來自您的系統。但是，如果有，防火牆會將它們視為對系統發起的流量的響應，並且不會阻止它們。您可能仍希望查看您的系統以確保您已處理任何可能的安全漏洞。