On the topic of undesired traffic directed at my home network from the public internet, let’s look at unacknowledged SYN packets for the top offending autonomous systems (ASes) on a per-port basis, for just one day.
It’s worth noting a distinction between two classes of SYNs I don’t acknowledge: those directed at ports on which there is nothing listening and those directed at ports on which something is listening but from a source which I don’t acknowledge due to a history of nefarious activity. Nefarious activity to my web server, for example, might include looking for vulnerabilities I’ve never had (say ‘/login.php’ or ‘phpmyadminwhatever…’).
What’s interesting about looking at things from this perspective is just the different nature of probes from various host/cloud providers. For example, compare what comes from Cloudflare (just web traffic) to the skulduggery-only that comes from G-Core Labs S.A.. The difference is fairly astounding to find at this level of granularity (entire autonomous systems). And of course we see what we’d expect from Amazon and Google… mostly port 443 and 80 probes, but also scans of the entire 16-bit port range.
So let’s take a look…
First up, today’s leading offender: Microsoft. Most of the probing is directed at my web server.
| 8075 Microsoft Corporation (US) | |
| Port | Packets |
| 443 (https) | 5372 |
| 80 (http) | 936 |
| 587 (submission) | 7 |
| 2375 | 3 |
| 102 (iso-tsap) | 2 |
| 1521 | 1 |
| 2000 | 1 |
| 21 (ftp) | 1 |
| 3306 (mysql) | 1 |
| 5432 (postgresql) | 1 |
| 5985 | 1 |
| 6379 | 1 |
| 9000 | 1 |
In second place we have Huawei. All of it directed at my web server.
| 136907 Huawei (HK) | |
| Port | Packets |
| 443 (https) | 3793 |
| 80 (http) | 600 |
In third place we have G-Core Labs S.A.. Most of it login attempts. I recommend blocking this AS entirely. All of the traffic I’ve received from them is nefarious in nature. I only recently added all of their address space to my ‘deny’ lists, but parts of it had been blocked by automation before.
| 199524 G-Core Labs S.A. (LU) | |
| Port | Packets |
| 22 (ssh) | 936 |
| 143 (imap) | 930 |
| 993 (imaps) | 923 |
| 587 (submission) | 916 |
| 2222 | 166 |
| 443 (https) | 165 |
| 80 (http) | 162 |
In fourth place we have Amazon. Most of it is directed at my web server, but there are probes to every port.
| 16509 Amazon.com, Inc. (US) | |
| Port | Packets |
| 80 (http) | 2185 |
| 443 (https) | 1761 |
| 8414 | 2 |
| 3524 | 2 |
| 3092 | 2 |
| 1022 (exp2) | 2 |
| 96 (dixie) | 1 |
| 98 (tacnews) | 1 |
| 100 (newacct) | 1 |
| 106 (pop3pw) | 1 |
| 123 (ntp) | 1 |
| 263 (hdap) | 1 |
| 95 (supdup) | 1 |
| 448 (ddm-ssl) | 1 |
| 450 (tserver) | 1 |
| 502 (mbap) | 1 |
| 541 (uucp-rlogin) | 1 |
| 646 (ldp) | 1 |
| 88 (kerberos-sec) | 1 |
| … port scans of ALL ports … | |
In fifth place we have Cloudflare. All of their probes were directed at my web server.
| 13335 Cloudflare, Inc. (US) | |
| Port | Packets |
| 80 (http) | 1460 |
| 443 (https) | 406 |
In sixth place we have Brightspeed. All of their probes were directed at my web server.
| 19901 Brightspeed (US) | |
| Port | Packets |
| 443 (https) | 1787 |
| 80 (http) | 74 |
In seventh place we have SEMrush. All of their probes were directed at my web server.
| 209366 SEMrush CY LTD (CY) | |
| Port | Packets |
| 443 (https) | 1100 |
| 80 (http) | 425 |
In eighth place we have Google cloud.
| 396982 Google Cloud (US) | |
| Port | Packets |
| 80 (http) | 243 |
| 443 (https) | 125 |
| 8088 | 7 |
| 20257 | 7 |
| 20256 | 6 |
| 22 (ssh) | 6 |
| 3389 (ms-wbt-server) | 5 |
| 3000 | 5 |
| 10001 | 5 |
| 5000 | 5 |
| 8080 (http-alt) | 4 |
| 8888 | 4 |
| … scans of all ports … | |
In ninth place we have Facebook. All of their probes were directed at my web server.
| 32934 Facebook, Inc. (US) | |
| Port | Packets |
| 443 (https) | 695 |
| 80 (http) | 340 |
In 10th place we have PT Batanghari Baik Net. Pure skulduggery: ssh only.
| 141069 PT Batanghari Baik Net (ID) | |
| Port | Packets |
| 22 (ssh) | 964 |
I have this data, every day, for every AS, in 5 minute intervals. And then some, actually, since the data is at the IP address level and I can quickly and easily roll it up into per-AS data. And of course I can use it to make decisions about who I should block from my home network.