3 ms·

I haven't manually reviewed my lists for a while, but I did similar checks for X IP addresses detected from within a /24 block to determine whether I should jus

I haven't manually reviewed my lists for a while, but I did similar checks for X IP addresses detected from within a /24 block to determine whether I should just block the whole /24. Manual reviewing like this also helped me find a bunch of organisations that just probe the entire IPv4 range on a regular basis, trying to map it for 'security' purposes. Fuck them, blocked! P.S. I wholeheartedly support your choice of blocking for your reasons.

kees99 8mo ago
> bunch of organisations that just probe the entire IPv4 range on a regular basis Yep, #1 source of junk traffic, in my experience. I set those prefixes go right into nullroute on every server I set up: https://raw.githubusercontent.com/UninvitedActivity/UninvitedActivity/main/02_InternetScanners/02_ZZInternetScannersSingleList.txt https://raw.githubusercontent.com/UninvitedActivity/Uninvite... #2 are IP ranges of Azure, DO, OVH, vultr, etc... A bit harder to block those outright.
- miyuru 8mo ago
  In my servers I dont have IPv4 at all, just IPv6 only. On the plus side, it does not waste CPU cycles used to block unwanted IPv4 traffic.
  - kees99 8mo ago
    That helps a bit, true. But not that much, unfortunately. Those same "cYbeRseCUrITy" orgs also ingest SSL transparency logs, resolve A and AAAA for all the names in the cert, then turn around and start scanning those addresses. In my experience, it only takes a few hours from getting an SSL certificate to junk traffic to start rolling in, even for IPv6-only servers. Small percentage of that could be attributed directly, based on "BitSightBot", "CMS-Checker", "Netcraft Web Server Survey", "Cortex-Xpans" and similar keywords in user-agent and referer headers. And purely based on timing, there's a lot more of that stuff where scanners try and blend in.
efilife 8mo ago
> trying to map it for 'security' purposes. Yes. Fucking censys and internet-measurement and the predatory "opt-out" of scans. What about opting-in to scan my website? Fuck you, i'm blocking you forever

kees99 8mo ago

> bunch of organisations that just probe the entire IPv4 range on a regular basis Yep, #1 source of junk traffic, in my experience. I set those prefixes go right into nullroute on every server I set up: https://raw.githubusercontent.com/UninvitedActivity/UninvitedActivity/main/02_InternetScanners/02_ZZInternetScannersSingleList.txt https://raw.githubusercontent.com/UninvitedActivity/Uninvite... #2 are IP ranges of Azure, DO, OVH, vultr, etc... A bit harder to block those outright.

miyuru 8mo ago
In my servers I dont have IPv4 at all, just IPv6 only. On the plus side, it does not waste CPU cycles used to block unwanted IPv4 traffic.
- kees99 8mo ago
  That helps a bit, true. But not that much, unfortunately. Those same "cYbeRseCUrITy" orgs also ingest SSL transparency logs, resolve A and AAAA for all the names in the cert, then turn around and start scanning those addresses. In my experience, it only takes a few hours from getting an SSL certificate to junk traffic to start rolling in, even for IPv6-only servers. Small percentage of that could be attributed directly, based on "BitSightBot", "CMS-Checker", "Netcraft Web Server Survey", "Cortex-Xpans" and similar keywords in user-agent and referer headers. And purely based on timing, there's a lot more of that stuff where scanners try and blend in.

efilife 8mo ago

> trying to map it for 'security' purposes. Yes. Fucking censys and internet-measurement and the predatory "opt-out" of scans. What about opting-in to scan my website? Fuck you, i'm blocking you forever