Abuse Desks

Wed Apr 29 17:33:15 UTC 2020

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