Abuse Desks

Mukund Sivaraman muks at mukund.org
Wed Apr 29 06:54:01 UTC 2020


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?

>From our perspecive, a dumb kid's attempts look no different to a
botnet's and we cannot distinguish. We don't know what kind of
customer/end user is generating this more than the party who has the IP
block. An exploit of a vulnerability whether it is performed by a dumb
kid or a botnet has similar consequences.

If this is generally about etiqutte of emailing abuse@, look at it from
our (target's) point of view. Assume "Joe Company"'s IP addresses send
nefarious scanning queries to our hosts. If we respond to their abuse@
contact with automated reports of such activity for TCP traffic, let's
assume 10% of those reports are false-positives. Which actor is
responsible for the worse etiquette here? Joe Company, whose IP block is
reponsible for the nefarious scanning, or us who who are reporting these
attempts using a program?

We are a small company with no CFO, CTO, CSO, CXO. We have little
resources to scan every attempt. We can ignore these attempts and turn a
blind eye, or we can automate. If there's a false positive report from
us, then use the stick and that would be fair.

		Mukund



More information about the NANOG mailing list