Fred Stluka on 31 Aug 2018 14:33:48 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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


Rich,

You may have blocked all of AWS a little too long, and gotten
to be out of date.  Don't take offense -- it's happened to me
a couple of times over the years.

From my experience, very few attacks currently come from AWS,
and when they do, I report them.  Within a couple days I get a
reply from AWS saying it's been investigated and dealt with, and
the attacks from that IP address stop.

Meanwhile, active security measures like fail2ban mean that the
attacker wasn't really going to get in anyhow.  That's why I can't
imagine ever turning off something as nimble, specific, and
effective as fail2ban, regardless of any coarser country-level
blocks I might use.

You sound very frustrated with AWS, which is likely due to valid
bad experiences on your part.  I sound the same way whenever
I talk about Microsoft.  But, it's possible that my perception of
MS is dated -- no longer accurate if it's true that the new CEO
Satya Nadella has cleaned up much of the sloppy, poorly-written
software and unethical company ethos that Bill Gates and Steve
Ballmer encouraged for so long.  Hard to tell.  I still refuse to
use their software, but I'm trying to rein in my tendency to bash
them, since I haven't used any MS software for a decade or so,
and I honestly don't know whether they've improved.

Maybe AWS has improved?  How long ago did you last confirm
your bad impression of them?

--Fred
------------------------------------------------------------------------
Fred Stluka -- Bristle Software, Inc. -- http://bristle.com
#DontBeATrump -- Make America Honorable Again!
------------------------------------------------------------------------

On 8/27/18 4:41 PM, Rich Kulawiec wrote:
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