Internet Control Message Protocol
Type: 3 (Destination unreachable) Code: 3 (port unreachable) Checksum: 0xa821 [correct] [Checksum Status: Good] Unused: 00000000
ICMP destination unreachable packets are "generated by the host or its inbound gateway to inform the client that the destination is unreachable for some reason." There is a "code" field that follows the "type" field in an ICMP packet. If the code is 3, then it indicates a port unreachable error (the designated protocol is unable to inform the host of the incoming message). When I checked the destination port at the server end, I saw it was 22, which is the well-known port for the Secure Shell (SSH) protocol.
Transmission Control Protocol, Src Port: 37946, Dst Port: 22, Seq: 247143363 Source Port: 37946 Destination Port: 22 Sequence number: 2474143363 [Stream index: 4755] Sequence number: 2474143363 (relative sequence number) Acknowledgment number: 0 Header Length: 40 bytes
The server that was sending the "port unreachable" messages back to the 116.31.116.41 address functions as an SSH server, but also runs the intrusion detection system (IDS) software Fail2Ban, so I assumed Fail2ban had blocked any futher connection attempts to port 22 because of failed SSH login attempts from the 116.31.116.41 IP address.
I went to the American Registry for Internet Numbers (ARIN) website at www.arin.net to determine the geographic location associated with that IP address. I found that the IP address is within a block of IP addresses assigned to the Asia-Pacific Network Information Centre (APNIC), which is the Regional Internet Registry (RIR) for the Asia Pacific region. When I looked up the IP address at the www.apnic.net site, the APNIC Whois Search for 116.31.116.41 returned the following information:
| inetnum: | 116.16.0.0 - 116.31.255.255 |
| netname: | CHINANET-GD |
| descr: | CHINANET Guangdong province network |
| descr: | China Telecom |
| descr: | No.31,jingrong street |
| descr: | Beijing 100032 |
| country: | CN |
| admin-c: | CH93-AP |
| tech-c: | IC83-AP |
| mnt-by: | APNIC-HM |
| mnt-lower: | MAINT-CHINANET-GD |
| mnt-routes: | MAINT-CHINANET-GD |
| status: | ALLOCATED PORTABLE |
| remarks: | -------------------------------------------------------- |
| remarks: | To report network abuse, please contact mnt-irt |
| remarks: | For troubleshooting, please contact tech-c and admin-c |
| remarks: | Report invalid contact via www.apnic.net/invalidcontact |
| remarks: | -------------------------------------------------------- |
| source: | APNIC |
| mnt-irt: | IRT-CHINANET-CN |
| changed: | hm-changed@apnic.net 20070307 |
When I performed an online search on the IP address to see if others were reporting similar attempts to compromise their systems via illegitimate SSH logins, I found the IP address was among those listed in Rutgers Univeristy's IP List of SSH Brute force attackers. That list also contained numerous other IP addresses from the 116.16.0.0 - 116.31.255.255 IP address range. list. That list contained IP addresses from 116.16.31.4 to 116.16.31.52. A site that maintains information on IP addresses associated with brute-force attacks , the BruteForcers blacklist, also listed the IP address at 116.31.116.41 brute force attempt details.
| INTERNAL ID | ATTACK DATE | IP ADDRESS | TYPE | COUNTRY | ORGANISATION |
| 8581 | 2016-06-04 | 116.31.116.41 | SSH | China | ChinaNet Guangdong Province Network |
I also found the IP address listed at the AbuseIPDB site, which is "a project dedicated to helping systems administrators and webmasters check and report IP addresses that are involved in malicious activity such as spamming, hack attempts, DDoS attacks, etc." That site notes in its Frequently Asked Questions (FAQ) page that the site owner(s) "provide a free API for both reporting malicious IP addresses detected on your systems, and checking IP addresses for reported malicious activity." The database entry for 116.31.116.41 shows repeated SSH brute-force login attempts from that IP address.
When I checked the Fail2ban log for all of the IP addresses banned on the server which I monitor since the beginning of the log on Christmas, December 25, 2016, I saw the following IP addresses listed:
# awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | sort | uniq -c | sort -n
1 103.212.91.118
1 106.35.34.154
1 107.150.94.6
1 108.61.122.221
1 108.61.122.51
1 108.61.123.81
1 109.187.187.175
1 112.217.150.112
1 112.238.76.73
1 112.85.42.103
1 113.4.47.183
1 113.6.52.186
1 114.236.63.13
1 114.240.125.228
1 114.80.200.67
1 114.93.49.20
1 118.123.246.81
1 118.244.206.144
1 119.193.140.172
1 119.193.140.184
1 119.193.140.189
1 120.11.210.31
1 120.41.90.52
1 121.134.178.234
1 121.137.56.3
1 121.23.192.9
1 121.236.180.181
1 122.135.62.47
1 122.189.156.134
1 122.191.120.139
1 122.191.207.46
1 122.53.179.137
1 123.202.10.41
1 123.28.12.192
1 124.2.53.250
1 125.26.60.21
1 125.92.250.98
1 128.69.104.54
1 131.255.132.136
1 139.199.45.89
1 139.219.235.53
1 140.246.166.13
1 14.210.230.203
1 14.33.99.171
1 147.75.104.129
1 147.75.99.113
1 148.3.230.228
1 151.50.109.23
1 153.99.182.4
1 1.55.221.37
1 1.58.211.46
1 159.122.133.224
1 167.250.185.249
1 170.79.150.251
1 175.196.155.216
1 175.42.4.108
1 176.209.201.38
1 176.209.254.221
1 176.210.150.246
1 176.210.22.59
1 177.32.4.232
1 178.129.82.81
1 181.174.141.123
1 182.100.67.4
1 182.53.119.61
1 182.53.19.161
1 183.77.138.236
1 183.95.175.227
1 1.84.122.143
1 185.110.132.10
1 185.56.82.66
1 185.82.138.97
1 187.72.126.186
1 193.201.225.128
1 194.126.182.185
1 201.16.178.157
1 201.213.164.27
1 203.219.130.108
1 209.161.5.171
1 212.35.127.70
1 213.111.129.106
1 213.21.96.242
1 218.109.241.122
1 218.65.30.124
1 218.65.30.43
1 221.223.96.90
1 221.223.98.213
1 221.229.196.201
1 221.236.123.120
1 222.101.189.111
1 223.68.96.28
1 24.127.37.106
1 2.60.20.177
1 27.191.198.30
1 27.219.142.8
1 27.250.18.149
1 31.163.142.193
1 31.173.108.6
1 31.173.90.61
1 31.204.180.122
1 37.21.81.138
1 37.221.133.44
1 37.221.165.196
1 39.163.163.47
1 39.75.6.44
1 46.160.141.196
1 46.166.188.230
1 46.209.55.241
1 46.214.227.137
1 46.9.193.213
1 49.74.35.108
1 5.13.7.67
1 5.140.128.7
1 5.141.176.25
1 5.160.168.8
1 5.42.80.216
1 5.61.166.189
1 58.100.132.62
1 58.227.194.254
1 58.246.141.198
1 59.61.185.173
1 59.63.166.80
1 59.63.166.81
1 60.189.152.147
1 60.216.236.8
1 60.246.81.1
1 61.150.72.113
1 61.159.13.178
1 61.200.68.128
1 61.228.220.131
1 61.233.76.154
1 61.237.231.103
1 61.52.73.162
1 62.210.36.151
1 69.70.47.74
1 77.46.131.190
1 78.111.26.247
1 79.176.4.69
1 79.37.204.231
1 80.220.243.128
1 81.171.229.66
1 82.241.225.215
1 83.169.220.74
1 83.77.123.205
1 84.198.155.206
1 85.17.80.229
1 85.30.187.151
1 85.90.175.165
1 86.109.216.90
1 91.200.12.17
1 91.250.22.133
1 92.124.106.189
1 93.39.252.194
1 94.51.149.108
1 94.51.49.76
1 95.188.202.124
1 95.31.163.63
1 95.78.38.123
1 97.76.138.174
1 98.29.136.197
2 122.194.229.6
2 182.100.67.119
2 93.99.210.115
3 108.61.122.160
3 123.85.190.139
3 218.2.0.16
3 91.224.160.131
4 218.65.30.61
4 59.63.166.83
18 116.31.116.7
23 116.31.116.30
30 116.31.116.34
70 116.31.116.45
81 116.31.116.41
104 116.31.116.49
118 116.31.116.48I saw that most of the banned IP addresses since the start of the log were within the 116.31.116.0/26 CIDR block (you can convert IP address ranges to CIDR at CIDR). Rather than block all of the 116.16.0.0 - 116.31.255.255 address range, i.e., 116.16.0.0/12, assigned to China Telecom, I decided to block just a smaller subnet that would encompass the range of IP addresses from which I had seen attempted break-ins. Since the system is a CentOS 7 system running the Firewalld firewall software, I used the command below to block any connectivity from any IP address in the 116.31.116.0/26 range, i.e., 116.31.116.0 through 116.41.116.63.
# firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='116.31.116.0/26' reject" success #
To have the new permanent rule take effect, I needed to restart the Firewalld service, which I did from the user account I logged in under. Once I restarted the service the rule showed up in the list of "rich-rules".
$ firewall-cmd --list-rich-rules rule family="ipv4" source address="183.3.202.184" reject rule family="ipv4" source address="183.3.202.183" reject $ systemctl restart firewalld.service ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units === Authentication is required to manage system services or units. Authenticating as: root Password: ==== AUTHENTICATION COMPLETE === $ firewall-cmd --list-rich-rules rule family="ipv4" source address="183.3.202.184" reject rule family="ipv4" source address="183.3.202.183" reject rule family="ipv4" source address="116.31.116.0/26" reject
However, that resulted in the Fail2Ban-related rule disappearing from the running firewall configuration, which I restored by restarting Fail2Ban.
Related articles: