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

[Fred Stluka <fred@bristle.com>]

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