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