Abuse Desks

Tom Beecher beecher at beecher.cc
Wed Apr 29 17:49:14 UTC 2020


What if I am at home, and while working on a project, fire off a wide
ranging nmap against say a /19 work network to validate something
externally? Should my ISP detect that and make a decision that I shouldn't
be doing that, even though it is completely legitimate and authorized
activity? What if I fat fingered a digit and accidentally ran that same
scan against someone else's /19? Should that accidental destination of
non-malicious scans be able to file an abuse report against me and get my
service disconnected because they didn't like it?

Abuse departments should be properly handling LEGITIMATE abuse complaints.
Not crufty background noise traffic that is never going away.

On Wed, Apr 29, 2020 at 1:35 PM Mukund Sivaraman <muks at mukund.org> wrote:

> On Wed, Apr 29, 2020 at 09:50:42AM -0700, Stephen Satchell wrote:
> > On 4/29/20 9:24 AM, Mukund Sivaraman wrote:
> > > If there's a lock on my door, and someone tries to pick it, you can
> call
> > > me at fault for having a lock on my door facing outside all you
> > > want. But the thief picking it has no business doing so, and will be
> > > guilty of a crime if caught.
> >
> > This is a good start to an analogy.  Let's build on it, courtesy to
> > YouTube's "Lock Picking Lawyer".  In a video, the host shows how to
> improve
> > the security of a common easily-picked home lock: drill holes in the lock
> > body, such that if someone picks the lock and tries to turn the keyway,
> the
> > pins will fall into those carefully-placed holes and foil The Bad
> Guy(tm).
> >
> > In the networking world, we use an Access Control List to limit access to
> > the service.  Unlike the simple modification shown in LPL's video, the
> > "lock" is still usable by users from authorized IP addresses.  Or, we
> > require the use of certificates to validate access within the SSHD server
> > itself.
> >
> > Here's the deal:  just blocking access or requiring certificate-based
> access
> > is intrusion prevention.  Having a log event when there are unsuccessful
> > probes is intrusion [attempt] detection.  Sure, the ne'er-do-well is kept
> > out in the prevention cycle, but a persistent cracker lives by the axiom
> "if
> > at first you don't succeed, try something else."  You really want to
> stop an
> > attacker from making a large number of attempts, such as with a Joe
> script.
> >
> > I turn off root SSH access, pinhole 22/tcp to a limited number of IP
> > addresses, and monitor failed SUDO attempts.  As I build up my new
> firewall,
> > I'll turn off public SSH access completely, and instead use a robust VPN
> > implementation.  (Which has its own issues.)
>
> The previous criticism of running a public sshd reminds me of a person
> who claimed women should not wear sexy dresses and complain that they
> were molested. Though that may appear to be logical, it's blaming the
> victim rather than addressing the problem. It is no excuse.
>
> Our services are secured best as we can for our use-case. That's not
> what is being discussed.
>
> There are 2 things that are happening:
>
> (1) Service providers are allowing nefarious traffic to exit their
> network. They probably don't have tools to detect/prevent this because
> they probably have not budgeted it, or don't care because there are no
> consequences.
>
> (2) They don't want to handle a proportional level of abuse@ email that
> is directed back at them for the amount of crap that they inflict on the
> rest of the internet. They probably have not budgeted for handling it.
>
> All the explanation that has been offered, including whether one wants
> to pay $1000 for an internet connection are just excuses to deflect from
> the above two things, because they are not being held responsible to
> take action.
>
> Tt is a technical problem to detect scanning of TCP port 22, 587 of
> large swathes of IP address space from a host. If service providers were
> inclined to fix it by spending money on it, they could automatically
> detect them and stop them, even without abuse@ emails asking for manual
> investigation.  When there is no problem, there is no email to abuse@
> about it.
>
> This thread talks about the incentive to the service provider.. what is
> the incentive to us to let abuse@ know of a problem on their network?
> Trust that we don't make any money off it either. If I email an abuse@
> contact, what I expect is "Thank you." "Thank you for helping us detect
> nefarious activity from our network, that hurts the internet." instead
> of all the defence that this thread has posted.  That's how abuse
> reports should be handled. It doesn't matter if the report was emailed
> manually or by pigeons riding unicorns, as long as it provides some
> information that the abuse@ contact can act upon. It's not as if the
> host which had the address is suddenly going to become a good citizen
> that it is no longer detectable.
>
>                 Mukund
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200429/03c48f12/attachment.html>


More information about the NANOG mailing list