mpalmer at hezmatt.org
Wed Apr 29 11:48:51 UTC 2020
On Wed, Apr 29, 2020 at 12:24:01PM +0530, Mukund Sivaraman wrote:
> On Tue, Apr 28, 2020 at 11:40:16PM -0700, Matt Corallo wrote:
> > Sadly dumb kids are plentiful. If you have to nag an abuse desk every
> > time they sell a server to a kid who’s experimenting with nmap for the
> > first time then.... we’ll end up exactly where we are - abuse contacts
> > are not a reliable way to get in touch with anyone, and definitely not
> > a reliable way to do so fast or with any reasonably large
> > network. Please don’t clog the otherwise-useful system.
> > If you have trouble sleeping at night, I’d recommend the
> > “PasswordAuthentication no” option in sshd_config.
> Yes we use that, and PermitRootLogin no and an AllowUsers list.
> I asked in my first email, if with security practices as above and use
> of fail2ban to filter attempts, should we just ignore this problem and
> think that nobody is ultimately reponsible to get rid of this activity?
In theory, no. In practice, unfortunately, yes.
The typical service provider has so much low-level "noise" going on that if
everyone reported everything to them, they'd semi-literally drown.
Certainly, there's no possible way they could economically handle all that
abuse reporting -- hiring all the people to examine, determine the veracity
of, and act upon the reports would cost a fortune, because you better
believe there's no One True Format for automated abuse notifications, nor
will there ever likely be one, so it's all humans, all the time.
Now, you could argue that they should clean up their network so they don't
have that volume of abuse reports coming in -- and you'd be right, in
theory. But there's a *lot* of low-level stuff that it isn't practical to
stop, in and of itself.
Consider your own reports. What is it, exactly, that you expect a provider
to do with your report of a few failed SSH login attempts to stop the
activity? Say it's a residential ISP, or an IaaS provider. They have only
a few very large hammers at their disposal -- they can (maybe) filter the
destination port, filter your destination IP, or disconnect the customer.
Any of those will very possibly result in a support call, or lost customer.
That's a very large cost you're expecting them to pay for something which
has, let's face it, cost you practically nothing.
Forcing disconnection for a port scan is also, by the way, a *great* way to
create an absolute gold-plated A+ denial-of-service: send in a
plausible-looking report of shenanigans to the ISP of someone you don't
like, and *boom* their Internet connection's cut off. WINNAH!
So what are you left with, action-wise? An ISP could keep a tally of abuse
reports by customer, and take action on whoever's at the top of the pile,
but that would then require a large and expensive army of humans to receive,
check, classify, and record all incoming abuse reports. Do *you* want to
pay $1,000/month for your home Internet connection to cover the cost of all
those extra ISP staff? Because, as I said before, there's no One True
Format for reporting abuse, and there never will be.
Not that it would work, anyway -- any sort of "threshold" system for abuse
ends up being gamed, anyway. You only need to look at how Twitter users
with an axe to grind gang up to send in malicious reports about some other
Twitter they don't like, which trips Twitter's "lots of reports => autoban"
logic, to see how that would end if you started applying it to Internet
Finally, because nobody is ever convinced by rhetoric, here's an appeal to
your self-interest: "crying wolf" is never a good idea. In the event that
you *do* have a real problem that needs to be dealt with some time in the
future, do you want to have your e-mail address, IP address, and whatever
else associated with a thousand previous GWF ("goober with firewall")
reports? Any abuse desk who has seen your hundreds of previous unactionable
reports will almost certainly round-file that important one, and then you're
*really* up the creek sans paddle. Far better to keep your powder dry and
be ready for when you actually need assistance from whoever you're
More information about the NANOG