UFW Weird ICMP log record - Pinging is blocked

Question

In the log records below I have replace my eth MAC address with ETH_MAC_ADDRESS the IP of my server with MY_SERVER_IP and other IPs with STRANGE_IP plus a number to distingue.

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 ]

As you can see the destination IP is always my server IP in the first part of the record and the Source IP is the second part. All other IPs are not the same.

This lasted for around 4 hours. During that time the servers CPU load was extremely low and even the SSH connection dropped.

The pinging is blocked via before rules of ufw firewall.

Is this a DDos attack? Worth mentioning that a couple of days ago we had a DDos attack and a day ago we had an attempt of DDos attack that we preventing with Firewall rules added in Cloudflare dashboard.

Can someone explain how to identify the second part in brackets [] of each record in log?

cat /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
COMMIT

The rules of the UFW.

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

UPDATE:

There are some weird SSH(?) connections as well:

netstat -nt | grep :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

netstat -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

~~The above is right now but the server seems that has no issues and the UFW does not log the initial request~~.

After checking in /var/log/auth.log the above are just authentication failure. I don't know they appear established in netstat.

Best regards

score 1 · Accepted Answer · answered Jan 30 '21 at 14:13

These are standard ICMPv4 responses. You can tell by the type and code exactly what response is being sent from the destination host to your host.

In both cases the type is 3, Destination unreachable. The code in the first case is 3, Port unreachable, and in the second case 1, Host unreachable. The first ICMP response would result in a program returning the (possibly more familiar) error Connection refused, and the second would return the error No route to host.

ICMP responses such as this return a copy of the packet which caused the response. Here that packet is shown in square brackets. It shows UDP traffic from your IP address to each of the remote servers, on a destination port of 389.

Since the source port is the same for every packet, this traffic is probably spoofed: it most likely originated from some unknowable place, and was sent specifically so that these ICMP responses would reach your system. It might have been an attempt at a denial of service, but if so it was a very poor attempt. It may also have been an attempt at generating an abuse complaint toward your service provider with fake traffic. It could also be someone was trying to attack those remote systems and accidentally used your IP address as the source instead of his own.

While it's most likely spoofed traffic, there is a possibility that it actually did originate from your system. However, if it had, the firewall would have seen them as responses to traffic originated by your system and would not have blocked them. You may still wish to give your system a look to ensure that you've dealt with any possible security vulnerabilities.

Hello. Thank you for your response. I added some information. — fat_mike, Jan 30 '21 at 14:31
@fat_mike That's completely unrelated to the ICMP traffic you asked about. It's also to be expected since you are on the Internet. People are going to try to break in. — Michael Hampton, Jan 30 '21 at 17:42
I'm just trying to identify the root of these messages as it lasted a lot of hours causing to lose connectivity even via SSH from time to time. — fat_mike, Jan 31 '21 at 19:03
I mark this as the correct answer as it helped me figure out what the issue was. My server was attacked with an amplified reflection DDoS. That is why my server responded to many different ping requests. More info in case someone else is a victim of such attack : https://youtu.be/5bWPTTFYsD8 — fat_mike, Apr 01 '21 at 15:18

UFW Weird ICMP log record - Pinging is blocked

1 Answers1