*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" <[email protected]> To: "Mike Hammett" <[email protected]> Cc: "Josh Luthman" <[email protected]>, "North American Network Operators Group" <[email protected]> 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 < [email protected] > 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" < [email protected] > To: "North American Network Operators Group" < [email protected] > Cc: "Josh Luthman" < [email protected] >, "Mike Hammett" < [email protected] > 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 < [email protected] > wrote: Until it isn't. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Luthman" < [email protected] > To: "North American Network Operators Group" < [email protected] > Cc: "Mike Hammett" < [email protected] > 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 < [email protected] > 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" < [email protected] > To: "North American Network Operators Group" < [email protected] > Cc: [email protected] 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 < [email protected] > 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: >> >> [email protected] <mailto: [email protected] > >> 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/[email protected]/message/6CFCYFIP5FHUL4PBZQNOUV2SW6DNK44U/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/A2ZFPUI7XEE4YHM7QJ433TWBRCLMYAYA/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/ZDCAEF7Z72EHJC3QWNFHTAPTIZ76VF6O/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/RQS3GC62R2VMDBG74NUUNN3SQVBXMIYD/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/IBMBISDDUFVK7YTBGGXHP7I7X56AOCV3/
