Re: [PLUG] Linux tip: Log IP addresses, not hostnames, for use by fail2ban...

["Keith C. Perry" <kperry@daotechnologies.com>]

"AWS has been a chronic, systemic source of brute-force attacks (against
ssh, for example) and abuse for years.  AWS refuses to accept complaints
via RFC 2142-mandated role addresses, preferring instead to force victims
of its incompetence and negligence to jump through hoops and fill out a form
that doesn't actually facilitate accurately reporting the complaint.  And
when that's done, they ignore the complaints.  (This is now so well known
that nobody with any clue even bothers filing them any more.)"

YES... this need to go on a billboard or at least be shouted from on high.

I gave up on this before the obsession with cloud and even though I take a different approach, I fully support network and security professionals that refuse to give in and allow traffic from problem networks, even if that problem network is the "popular" kid.


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Managing Member, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167 
www.daotechnologies.com

----- Original Message -----
From: "Rich Kulawiec" <rsk@gsp.org>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Monday, August 27, 2018 4:41:35 PM
Subject: Re: [PLUG] Linux tip: Log IP addresses, not hostnames, for use by fail2ban...

On Sat, Aug 25, 2018 at 02:31:34PM -0400, Fred Stluka wrote:
> I'm just trying to block hackers without losing the ability to know
> who they are, where they come from, and what tricks they are
> trying.??

As I said, if you're doing research, then fine.  A good way to do that
is to stand up a hardened server running something like OpenBSD and
run dummy servers for things like SMTP, HTTP, etc., log every packet,
and go to work.

And if you want to invest the massive quantity of time that it'll
take to do that: be my guest.  But unless you invest heavily in
research, you probably won't learn anything that we don't already know...
which I can summarize for you as "expect every form of attack against
every service you run from hundreds of millions of IP addresses
scattered across companies, ISPs, universities, etc. in Chinese IP space.
Expect it to go on nonstop for decades.  Expect your complaints to
be ignored or met with reliation (because you've either sent them to
the abusers or to people who will forward them to the abusers)."

I'm not knocking the intellectual exercise: I do quite a bit of
research in this area myself.  But it's not appropriate for a production
operation.  There, the right approach is to firewall and forget, because
we now live in a world of 0-days and the tomorrow could be the day that
an attack arrives for which there exists no defense...other than
preventing it from reaching its target(s).

It's one thing succumb to an attack that came from Dallas.
It's quite another to succumb to one when it came from Quito and
you had absolutely no operational requirement whatsoever to ever
permit a single packet from Ecuador to get anywhere near your servers
*and* you could have stopped it cold years before it happened with
a few minutes' work.

Let me pause to note that I don't like this.  Not at all.  This isn't
the Internet that I hoped for, all those years ago.  But this is the
Internet we have, and no amount of wishful thinking will change that.
The default-permit philosophy that we used for a very long time is
no longer viable, and default-deny needs to be the rule.

> If I block all of China, I lose the ability to learn how best
> to allow some of China in safely, which I may need to know for a
> client some day.

No.  You don't.  If you need to allow a network in China in, then
you look up the relevant allocation and add that network to an
exemption list.  It's trivial.

Although: should you find yourself in that situation, you really
might want to consider standing up a separate server solely to handle
traffic from dubious IP space, and isolating it from the rest of
your operation.  I've done that (although not with China): there's
a proxy mail server out there which isn't reachable from most of the
Internet but *is* reachable from a few select networks that would otherwise
be blocked.  It's bandwidth-throttled, it's hardened, it's not able to
initiate outbound connections to anything, etc., and its job is to
carefully (and slowly) accept the small amount of SMTP traffic that
it needs to.

> Also, I'd guess that these days most hackers have access to
> botnets that span multiple countries [...]

Yes, they do.  But (1) hold that thought for a moment and (2) the
existence of multinational botnets does not invalidate the per-country
blocking approach even a little bit.

> And if so, what other countries should I block entirely?

You should block *any* country that you can, precisely because of
the observation you just made.  In fact, if you can block the planet
(from certain or all services) you should, and then only allow the
countries that you must.  For example: an awful lot of US-based
operations do not need to allow incoming ssh connections from anywhere
but the US.  Best practice is therefore to block all, then allow
US-only modulo things like the DROP list, Digital Ocean, etc.

(Yes, I know people travel.  Open up a hole for the applicable
countries for the applicable duration, then close it.  This isn't hard.)

> BTW, what's your beef with AWS anyhow???

AWS has been a chronic, systemic source of brute-force attacks (against
ssh, for example) and abuse for years.  AWS refuses to accept complaints
via RFC 2142-mandated role addresses, preferring instead to force victims
of its incompetence and negligence to jump through hoops and fill out a form
that doesn't actually facilitate accurately reporting the complaint.  And
when that's done, they ignore the complaints.  (This is now so well known
that nobody with any clue even bothers filing them any more.)

And one of the things that I like to point out is that sustained outbound
abuse and attacks from any operation are a surface indicator of underlying
security issues.   (Because secure, well-run operations *do not exhibit
this behavior on a chronic/systemic basis*.)  They don't tell you what
those issues are.  They don't tell you why they exist.  They don't tell
you who's exploiting them.  But they're an existence proof.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug