Sep 5, 2025 Current Resources

Re: Paging Unified Layer/AS46606 in re: NET-162-240-0-0-1 (162.240.0.0/15)

nanog mailing list archives

From: Mike Hammett via NANOG <nanog () lists nanog org>
Date: Thu, 4 Sep 2025 16:43:52 -0500 (CDT)

*nods* and certain things are appropriate in certain places, but not others.

The IX does very minimal blocking, and IXes are generally supposed to be neutral, but the retail end-user-facing ISP 
outright blocks 25, 145, etc. We don't need to monitor it because it isn't allowed to ingress our customer edge 
routers. We do need to do a better job of "watching" the things we don't outright block, though.

Thresholds (and what you do based on those thresholds) for someone's home would be different than a DIA, which would be 
different than an IX port, which would be different than a cloud VM\container\whatever, which...

I guess my position would be it's your responsibility to police your network, but don't be surprised when the community 
lets you know that you suck at policing your network.

There's also some intelligence that should go behind it. Know Your Customer is relatively easy for last-mile providers 
- you've been to their house. They're less likely to commit fraud themselves, but also not that hard to compromise. You 
might be more forgiving of issues inbound from that customer (though still work towards resolution). An IP in China 
signs up for an account at some VM host in Europe using an American credit card, and within 12 hours they peg 1k pps of 
outbound port 25...  one might take more swift action on more strict thresholds.

It doesn't even have to be entirely altruistic. If the community doesn't agree with "your" policing of your network, at 
some point, they'll increase the pain. How many people bought IP block transfers that were useless for a variety of 
functions due to past abuses. How many ASNs, prefixes, etc. are on permanent RBLs, or firewall signatures or... because 
of non-compliance with requests to stop abuse? The person with the bad policing now can't participate in many aspects 
of the Internet because they didn't act on those reports and their business suffers because of it.

Where's Goldilocks?



----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


----- Original Message -----
From: "Tom Beecher" <beecher () beecher cc>
To: "Mike Hammett" <nanog () ics-il net>
Cc: "Josh Luthman" <josh () imaginenetworksllc com>, "North American Network Operators Group" <nanog () lists nanog org>
Sent: Thursday, September 4, 2025 10:12:19 AM
Subject: Re: Paging Unified Layer/AS46606 in re: NET-162-240-0-0-1 (162.240.0.0/15)




Likewise, I'd also assume a network (whether first mile or last mile) has some kind of alerting rate limit for things. 
If you're seeing 1k pps going to port 25 coming from one of your customers (and they aren't Microsoft, Google, MailGun, 
etc.), you probably ought to open a ticket with them and handle it appropriately, blocking if they're uncooperative. 
Adjust and expand to appropriate ports and rates. 


Networks monitor and alert for plenty of things. That's not the problem. I'm going to pick on you here Mike as an 
example, not as a personal attack. 


You're a co-founder of FD-IX. Are you guys inspecting every bit that traverses through your fabric? Are you matching 
that traffic (that you can) against known 'bad stuff' signatures , and reaching out to any IX member that sends that 
traffic through? You're probably not, because it's a lot of work, and expensive to do that. At a certain level of 
traffic it's not even possible to SEE every flow anymore. All you can do is sample the best % that your equipment can 
handle. You're probably not operating on huge margins, and probably said 'we can't really afford the hardware / time to 
do that stuff so we won't'. 


What do you think would happen if you 'decided' that 1k pps of SMTP traffic from a member of your IX was 'abusive' and 
blocked them? They'd almost certainly have a port cancellation to you within hours. How did you decide that was your 
threshold? Was it just because you hadn't seen that volume before, or something else? 


'Abusive traffic' is very often a relative term. Is this constant flood of SSH login attempts abusive? Or did someone 
mess up a script they were working on and accidentally background process something with a while(1) loop while 
debugging? ( Not that I've ever done that before and left something trying to login every 30s for about 3 months.... ) 
I'll give you another perspective. Internally here, there have been countless times that one of our application teams 
has reached out to say they're seen a blast of 'abusive traffic' and asked for our help. Turned out it was another 
internal team starting to use that service and forgot to tell them when it was starting. 


Case 1 : "Someone is doing something that is knocking off my routers before I can filter the traffic" 


Case 2 : "Someone is doing something that is spamming my logs" 


Case 1 is ABUSE. No question. 


Case 2 is ANNOYING. Operators can , and should, deal with this on their own. Opening a ticket on this is effectively 
saying " My network is logging that it is working correctly and blocking this thing. I want you to spend resources so 
that it doesn't anymore. " 
























On Thu, Sep 4, 2025 at 10:18 AM Mike Hammett < nanog () ics-il net > wrote: 


You don't have to dedicate a lot of resources to it. I don't envision a body scrolling through logs looking for bad 
things, then handwriting a strongly worded letter. 

Likewise, I'd also assume a network (whether first mile or last mile) has some kind of alerting rate limit for things. 
If you're seeing 1k pps going to port 25 coming from one of your customers (and they aren't Microsoft, Google, MailGun, 
etc.), you probably ought to open a ticket with them and handle it appropriately, blocking if they're uncooperative. 
Adjust and expand to appropriate ports and rates. 

Now, if you're not managing those things and someone on the Internet notices your lack of management, then you deserve 
to receive abuse reports and shame. 



----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


----- Original Message ----- 
From: "Tom Beecher" < beecher () beecher cc > 
To: "North American Network Operators Group" < nanog () lists nanog org > 
Cc: "Josh Luthman" < josh () imaginenetworksllc com >, "Mike Hammett" < nanog () ics-il net > 
Sent: Thursday, September 4, 2025 9:02:50 AM 
Subject: Re: Paging Unified Layer/AS46606 in re: NET-162-240-0-0-1 ( 162.240.0.0/15 ) 



Internet background radiation has existed since the day it was turned on. It will only ever increase. 


It's part of the price of admission when you connect to the internet at large. While annoying, playing whack a mole 
with every burst of stupid in logs is the absolute definition of trying to empty the ocean with a spoon. It's probably 
wise to focus that time on the bigger things. 


On Thu, Sep 4, 2025 at 9:45 AM Mike Hammett via NANOG < nanog () lists nanog org > wrote: 


Until it isn't. 



----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


----- Original Message ----- 
From: "Josh Luthman" < josh () imaginenetworksllc com > 
To: "North American Network Operators Group" < nanog () lists nanog org > 
Cc: "Mike Hammett" < nanog () ics-il net > 
Sent: Thursday, September 4, 2025 8:43:37 AM 
Subject: Re: Paging Unified Layer/AS46606 in re: NET-162-240-0-0-1 ( 162.240.0.0/15 ) 


Why bother putting out the small fire? It's only a small fire. 


On Thu, Sep 4, 2025 at 9:40 AM Mike Hammett via NANOG < nanog () lists nanog org > wrote: 


and yet just being okay with background radiation only encourages the background radiation to no longer just lurk in 
the background. 



----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


----- Original Message ----- 
From: "nanog--- via NANOG" < nanog () lists nanog org > 
To: "North American Network Operators Group" < nanog () lists nanog org > 
Cc: nanog () immibis com 
Sent: Thursday, September 4, 2025 3:05:55 AM 
Subject: Re: Paging Unified Layer/AS46606 in re: NET-162-240-0-0-1 ( 162.240.0.0/15 ) 

Who even bothers to complain about internet background radiation? Unless you're seeing a high volume or you know you 
have weak passwords... Otherwise there are plenty of machines out there searching for default SSH passwords. Just 
ignore them if they don't affect you. 

Many people configure SSH to run on a non-default port number to cut down on background noise. Or you can filter IPs as 
already suggested. Or you can know that you're using a strong authentication method and you're patched for 
CVE-2024-6387/6409, and leave it be. 

Please note that reporting abuse for non-incidents is itself an attack. There was an attack last year where someone 
sent spoofed port 22 SYN packets from IP addresses of Tor relays, resulting in a flood of trigger-happy "security" 
companies writing abuse emails to hosts of Tor relays who weren't involved, risking taking down large parts of the Tor 
network. 



On 4 September 2025 03:16:17 CEST, Rich Kulawiec via NANOG < nanog () lists nanog org > wrote:

Who puts a quota on an abuse mailbox...and then allows that quote to 
be reached?

Date: Tue, 2 Sep 2025 12:38:24 +0000 

Delivery has failed to these recipients or groups: 

abuse () bluehost com <mailto: abuse () bluehost com > 
The recipient's mailbox is full and can't accept messages now. Please try r= 
esending your message later, or contact the recipient directly.


I've got nothin': my usual string of exasperated profanities has failed me. 

Anyway, y'all have attackers using various VPS instances on your network 
to conduct coordinated brute-force ssh attacks, and you should make that 
stop yesterday. 

Details? Logs? Yes, yes, I know, I did try to send them to you -- but 
see the above for the explanation covering why you didn't receive them. 

Also: for the love of dog, fix this nonsense. 

---rsk 
_______________________________________________ 
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/6CFCYFIP5FHUL4PBZQNOUV2SW6DNK44U/

_______________________________________________ 
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/A2ZFPUI7XEE4YHM7QJ433TWBRCLMYAYA/ 


_______________________________________________ 
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZDCAEF7Z72EHJC3QWNFHTAPTIZ76VF6O/ 

_______________________________________________ 
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/RQS3GC62R2VMDBG74NUUNN3SQVBXMIYD/ 


_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/IBMBISDDUFVK7YTBGGXHP7I7X56AOCV3/