On Thu, Aug 28, 2025 at 10:42 AM Shawn Bakhtiar <[email protected]> wrote:
> [...] > > I am truly curious as to the communities opinion on this (and I'm going to > do my homework as you suggested) given the conditions we are facing in > 2025. There are times my instances are spending more CPU cycles dealing > with this overt abuse, than dealing with actual real business. > > Since you asked... For sites I administer, when I start seeing wordpress probes in my logs, I just put an inbound deny ACL for the subnet. I start with the /32. If I see a second probe from the same /24, I update the deny line to be the whole /24. If I see another probe from within the same /16, I update the deny line to be the whole /16. Takes a few minutes each week to update the ACLs, and reduces the impact on the servers quite nicely. So far, I've not yet received a "hey, I can't reach your site anymore" complaint. I think trying to make explicit rules about how quickly abuse contacts have to respond to email complaints is going to backfire horribly; it's far too easy to game the system. It's rather like the US banking system, where the account holder gets hit with a service charge for bounced checks, but there's no input validation on check deposits. So, I can dump 100 bogus checks into a night deposit drop at a bank with your account number on the deposit slip, and you'll get dinged with 100 bounced check charges against your account, even though you never deposited any bad checks yourself. The "protection" feature can end up being used to cause real harm to the legitimate person, without incurring any risk or penalty to the bad actor. Similarly, if we start putting rules in that say all messages sent to the abuse@ email account for a resource holder must be responded to within 24 hours or the resources can be reclaimed, then all I need to do is to start overwhelming your abuse handling system to the point where it can't keep up with the demand, and incoming complaints don't get a response within 24 hours, and then go to ARIN and say "look, you have to take these resources away because they aren't responding to abuse notifications." There's no way to shield the resource holder from abuse like that, and if we then trigger resource reclamation based on slow response, it's going to quickly become a barren battlefield where only the largest entities can survive, simply by being able to absorb bogus complaints and generate ticket numbers in response faster than any botnet can generate complaints. Right now, we have a similar problem with CAN-SPAM and mailing list signup abuse. Sure, you can fire off unsubscribe requests as fast as the spam comes in; but these days they all say "may take up to 10 days to remove your name from our lists" -- and in the meantime, now they know they have a real person monitoring a real mailbox, and for the next 10 days, they're going to pummel you with as much spam as they can, all the while pointing to the "but we're obeying the law and removing your name from our mailing list as fast as our system will let us". And then they file your email address on a "do not spam for 30 days" list, and on the 31st day, whammo, you're back on the list getting flooded with spam; you click unsubscribe again, they tell you again it's going to take 10 days to remove you, you get 10 more days of getting hammered with spam, and then 30 days of no spam...from that list. If you're a spammer, and maintain a collection of 31 mailing lists, you can keep a given email address front and center of your spam cannon continuously, by simply shifting the start of each 30+10 day cycle by one day for each mailing list. That is to say, in a long-winded way, it's nigh on impossible to write policy rules that accomplish what you want without having even more potential to be abused within the rules to cause more pain than they alleviate. :( Best of luck! Matt
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
