> > 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/WA4G5P5K7FGJULBR4NTZZVPCGLKCSW42/
