# Various netblocks which appear to believe there is such a thing as # (to quote one netblock's data) "scanning for LEGIT purposes". # # At least some of these appear to also fall into the "please volunteer # _your_ resources to improve _our_ commercial offerings" bucket too. # RIPE networks NET-3-163, 89.248.163.0/24 (but for some reason broken # into two /25s in RIPE's database), and NET-2-165, 89.248.165.0/24. 89.248.163.0/24 89.248.165.0/24 # RIPE netblocks # INTERNETMEASUREMENT-A (193.163.125.0/25) # INTERNETMEASUREMENT-B (193.163.125.128/25) # INTERNETMEASUREMENT-C (87.236.176.0/25) # INTERNETMEASUREMENT-D (87.236.176.128/25) 87.236.176.0/24 193.163.125.0/24 # ARIN netblock ACDRESEARCH, 104.156.155.0/24. 104.156.155.0/24 # RIPE netblock CH-KS-INNOVATION. 185.35.62.0/23 # RIPE netblock INTERNET-RESEARCH-NET 45.83.64.0/22 # ARIN netblocks (all called CENSY!). 162.142.125.0/24 167.94.138.0/24 167.248.133.0/24 199.45.154.0/23 206.168.32.0/22 # ARIN netblock ARBORN, NET-146-88-240-0-1. They replied to my # question, making it clear they consider what they're doing # acceptable. They even have the gall to offer an opt-out, apparently # thinking it reasonable for victims to have to ask in order to be # exempted from their abuse attempts. 146.88.240.0/20 # ARIN netblock 67.21.36.0/24, NET-67-21-36-0-1 (RGnet) and # NET-67-21-36-0-2 (UCBerkeley). Both RGnet and UCB replied and # consider the behaviour acceptable, inviting me to opt out. As if # victims ever should have to ask to not be abused. 67.21.36.0/24 # shadowserver.org 184.105.139.64/26 184.105.247.192/26 216.218.206.64/26 74.82.47.0/26 65.49.20.64/26 64.62.197.0/24 65.49.1.0/24 64.62.156.0/24 # internet-census.org 45.156.128.0/23 109.105.210.0/24 185.180.140.0/23 # Blocks which appear to be "please volunteer your resources to improve # our commercial offerings" outfits. # crawler%03d.deepfield.net, apparently a branch of Nokia. 104.234.115.0/24 # semrush.com # # Among other issues, this is a RIPE netblock but its "country" is # "US" and two of the contact persons have the same address but phone # numbers with different country codes. And of course there's the # basic problem this whole file section is for. 85.208.96.0/24 185.191.171.0/24 # I'm not sure whether these belong more in the "scanning is OK" or the # "please volunteer your resources" blocks. # Netblocks hosting *.probe.onyphe.net hosts, which have been, well, # probing my infrastructure. Onyphe has a list of network ranges, but # they rather obnxiously hide it behind HTTPS. This list was fetched # with the help of a work machine. 137.74.181.240/28 139.99.35.32/28 149.202.99.192/28 15.204.37.16/28 15.204.37.80/28 15.235.189.144/28 178.32.72.208/28 195.184.76.0/24 213.32.32.80/28 45.43.33.210/32 45.43.33.218/32 5.135.58.192/28 5.196.200.240/28 51.178.236.240/28 51.254.49.96/28 51.81.144.32/28 51.81.181.160/28 51.81.215.64/28 51.91.174.240/28 79.137.65.46/32 91.134.185.80/28 91.196.152.0/24 94.23.117.80/28 # Their list, claimed to be complete (see the RIPE record for # 195.184.76.0/24), isn't. I've also seen attempts from: 149.202.132.192/28 # More onyphe. I haven't bothered finding a work machine to check # these blocks against their current published list. The above is # what the list had when I checked; these are later discoveries. 91.230.168.0/24 91.231.89.0/24 # Blocks which appear to be uninterested in handling abuse reports, or # are handling them (IMO) wrong, or the like. # RIPE netblock HETZNER-fsn1-dc10, 144.76.32.128/27. They host # 144.76.32.151, which reverses to # discovery-crawler11.blex.seranking.com, which doesn't crosscheck. # I asked Hetzner what other addresses this customer had with them; # they were unwilling to say, passing my message to their customer, # who also were apparently unwilling to say, expecting those who don't # want to have their resources leeched to opt out. (seranking.com # belongs in the "please volunteer your resources..." block; this is # here because I'm blocking the whole Hetzner block because of their # (mis)handling of my question. As far as I can tell seranking.com # doesn't publish a list of their probe-from addresses; if I see some # from outside this block I may add them.) 144.76.32.128/27 # Digital Ocean, who apparently can't be bothered to staff their abuse # desk enough to handle the level of abuse they emit. Their abuse@ # autoresponse says abuse@ mail is "processed with automated tooling # due to the high volume of abuse submissions [they] receive", with no # apparent awareness of just how self-damning that is. They demand # X-ARF, "tools such as fail2ban" (with no indication of where to find # what syntax they're looking for; apparently the "such as" doesn't # cover independently written tools), or jumping through some Webpage # hoop. If they can't be bothered to either keep a lid on the abuse # they emit or staff their abuse desk enough to handle the resulting # complaints, I have negative interest in accepting their traffic. # (Yes, that would doubtless mean increasing their staffing costs and # thus prices. Cry me a frickin' river; asking the rest of the net to # subsidize their customers via their abuse-handling costs earns them # negative points with me.) # # They also host numerous *.internet-measurement.com hosts, one of the # "please volunteer _your_ resources to improve _our_ commercial # offerings" outfits. # 107.170.0.0/16 128.199.0.0/16 146.190.0.0/16 157.245.0.0/16 159.65.0.0/16 162.243.0.0/16 165.227.0.0/16 167.99.0.0/16 185.247.137.0/25 206.189.0.0/16 45.55.0.0/16 67.207.64.0/19 64.227.0.0/17 64.227.128.0/18 67.207.64.0/19 # Linode. Their abuse address autoresponse says outright they are # ignoring(!!) it in favour of some Web crap. They also explicitly # say that "security researchers" operate on their platform, from # which I think it valid to infer that they consider what these # "researchers" are doing is acceptable. (They also, of course, give # no indication of even whether, much less how, they've vetted that # these "researchers" aren't black hats.) # # They also mention that they host Tor exit nodes. This is a Good # Thing, and I regret that these blocks mean that those exit nodes # won't be able to reach me. But that's one of the prices of # choosing somewhere with no working abuse-reporting address for # hosting your exit nodes. # 172.104.0.0/16 172.105.0.0/17 172.105.128.0/20 172.105.144.0/23 172.105.146.0/24 # Amazon. I tried to report doorknob-rattlers in these blocks and they # rejected my report (which was sent to the abuse-reporting address # for this netblock as given by ARIN) # ... while talking to inbound-smtp.us-west-2.amazonaws.com.: # >>> RCPT To: # <<< 550 5.7.1 TLS 1.2+ required by recipient # 550 trustandsafety@support.aws.com... User unknown # If they're uninterested in handling abuse reports - IMO second to # only postmaster@ in "should accept mail from as many senders as # possible" - just because I didn't jump through a TLS hoop to send # them, I'm thoroughly uninterested in their traffic. (Some of their # blocks also claim that "All abuse reports MUST include" a list of # things including "Your contact details (phone and email)", trying to # pretend that "Without these we will be unable to identify the # correct owner of the IP address at that point in time".) # # Since getting the above bounce (which was 2026-02-27), I've been # adding on sight any block with trustandsafety@support.aws.com as its # abuse address, without bothering to check that it's still broken. # 3.0.0.0/9 15.196.0.0/14 15.200.0.0/16 18.32.0.0/11 18.64.0.0/10 18.128.0.0/9 54.144.0.0/12 54.160.0.0/11 54.192.0.0/12 54.208.0.0/13 54.216.0.0/14 54.220.0.0/15 # ovh.net ranges. Their abuse address autoresponse had no # Message-ID and had Content-Type: multipart/mixed with # Content-Transfer-Encoding: base64 (this is relevant because # multipart content-types with encodings other than 7bit or 8bit are # specifically forbidden; also of note, it was not in fact # base64-encoded). It also says that the information I provided "does # not allow [them] to identify the customer or service corresponding # to [my] report"; if they can't look up a customer that's been # sending me multiple packets per day for months by IP, they're too # incompetent or too lazy to do their job. Either way, buh-bye. 51.38.184.0/21 51.75.16.0/20 51.89.0.0/16 54.39.0.0/16 57.129.80.0/23 148.113.0.0/16 # Other netblocks I'm router-blocking. # APNIC blocks with ipas@cnnic.cn as abuse contact. APNIC WHOIS output # actually says right out that "ipas@cnnic.cn is invalid", but # apparently that's not reason enough to revoke the blocks. (A good # example of how disastrously broken modern Internet governance is. # In a civilized net that would get their address-space assignments # revoked.) 116.128.0.0/10 121.37.0.0/16 202.46.32.0/19 49.51.0.0/16 # APNIC blocks with anti-spam@chinatelecom.cn as abuse contact. When I # try to send reports to them, they reject the mail # ... while talking to oa-mta.21cn.net.: # >>> DATA # <<< 501 Invalid Client IP # 451 anti-spam@chinatelecom.cn... reply: read error from oa-mta.21cn.net. # 554 anti-spam@chinatelecom.cn... Service unavailable # I have negative interest in traffic from a netblock that broken. 180.152.0.0/13 # These are a bit odd. ARIN says they're RIPE's; RIPE repudiates them: # ARIN says this is RIPE's RIPE repduiates this # 81.0.0.0/8 81.68.0.0/14 # 146.174.128.0/18 146.174.0.0/16 # I have negative interest in talking with any block nobody is willing # to give _any_ info on. 146.174.128.0/18 81.68.0.0/14 # RIPE network CY-STARCRECIUM, which has 9 addresses which tripped my # address range scanning border test on 2021-03-02 - and then kept # pecking away enough to stay in my border blacklist until 2021-03-21, # a total of some 51 to 52 thousand packets each. 45.146.166.0/23