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

[Rich Kulawiec <rsk@gsp.org>]

On Tue, Aug 28, 2018 at 02:53:02PM -0400, Rich Freeman wrote:
> 2.  Maybe at some point an openssh zero day comes out, and it takes
> more than a few connection attempts to exploit it.  Fail2ban could
> save your bacon.  While I also don't advocate for blocking all of
> China/etc, I do have to admit that this could help protect you from
> zero days that require a single attempt to work [snip]

To be clear, I'm suggesting that the best approach (unless you have
an operational requirement to do otherwise) is to drop *all* traffic
that you can from China (and Korea, and from other countries and
networks elsewhere), not merely ssh.

If you don't need it, then all possible outcomes of allowing it are
bad for you and potentially good for attackers -- who, by the way,
can do far more than just exploit 0-days.  They can perform
reconaissance, slow/distributed brute-force attacks, redirection
attacks, etc.

Of course, attackers with highly distributed resources may be
able to find ways around it.  But (a) that's not a valid reason
for making their lives easier (b) depending on their methodology
and resources, they may not (c) greatly reducing the volume of incoming
attacks makes it much easier to see the remaining ones (d) and to
take action on them.  (Do not underestimate the value of (c) and (d).)

This seems an apropos time to share the wisest thing I've ever read
on the NANOG mailing list.  Unsurprisingly, it comes from one of the
most experienced people on the 'net:

	If you give people the means to hurt you, and they do it, and
	you take no action except to continue giving them the means to
	hurt you, and they take no action except to keep hurting you,
	then one of the ways you can describe the situation is "it isn't
	scaling well".
		--- Paul Vixie


Let me give you a timely example of what I mean in the first paragraph
above.  This is a tiny snippet of a much larger log, and I've edited it
to conceal some of the information.

	ssh	root	valid	invalid	address
	---	---	---	---	---
	8	1	0	7	104.248.A.B
	8	1	0	7	104.248.C.D
	8	1	0	7	104.248.E.F
	8	1	0	7	104.248.G.H

That happened within a 24-hour period.  Four distinct addresses
within the same /16 (which belongs to Digital Ocean) made exactly 8
attempts against ssh, exactly 1 each against root and exactly 7 each
against invalid user names.

Some pointed questions (rhetorical "you" throughout):

1. Do you think this is a coincidence?

2. Do you think this was a blind brute-force attack?

3. Do you think this system was the only target?

4. Do you think that this indicates a security problem inside that /16?

5. Do you think that this is the first time I've observed a problem
like this emanating from one of the Digital Ocean's allocations?

6. Do you think, given that I can see (part of) the attack arriving at my
operation, that they can see it leaving theirs?  Hint: netflows

7. Do you think this will happen again?

8. Given the answers to 1-7, should I respond to this by deploying
a half-ass measure like fail2ban that will let this happen over
and over and over again, or should I just cut to the chase and
permanently firewall the entire /16?  (...just like the other other
24 Digital Ocean allocations that I've already firewalled)

9. On reading this, what do you think *you* should do?  Should you
sit on your hands and wait for your turn to be attacked from the
festering sewer that is Digital Ocean, or maybe, should you drop
104.248.0.0/16 into your firewall configuration and refuse all ssh
connections from it?

---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