break-in attempt in my machine

[Karl Auer]

On Tue, 2016-08-30 at 06:34 +0900, Joel Rees wrote:
> I'm feeling ornery today.

Clearly!

> > 1: Turn off password access; require a publickey login.
> Does not get rid of the password problem, just moves it. Be aware how
> the management issues change, particularly that this doesn't help
> against keyloggers.

No. But it helps a LOT against the script kiddies, who are trying only
passwords. Using publickey makes a successful ssh login with only a
password impossible.

As to keyloggers: That's a whole different class of attack, and it is
just confusing the issue here.

> We really do need tokens to be different according to the login
> device, but nobody is focusing on that.

There are a thousand things one could and should do. I gave a list of
the most important ones, *in the context of script-kiddy attacks*.

> > 2: Move ssh to a different port.
> Check commonly used port definitions. Watch your logs to be sure you
> don't acidentally use a port used by malware, etc.

That's why I said to use ports higher than 1024. Whatever port you use
does have to be allowed to reach your ssh server though, and I guess
that's what you are getting at when you mention malware.

> In other words, this is helpful against non-targeted attacks, not so
> much against targeted attacks.

It's security through obscurity, but it is *extremely* effective
against script-kiddy automated attacks. Move off port 22, and watch the
attacks disappear.

> Especially make sure root ssh access is off, as someone mentioned,
> and don't use obvious userids like "admin", as I think someone else
> made a reference to.

If you are allowing only publickey access, it doesn't matter a bean
what your user names are.

> > 5: If you will only be logging in from a limited set of other
> > systems, allow ssh logins only from those addresses (or subnets).
> And remember that IP addresses can be spoofed.

Yes they can be. But they mostly aren't, and you have still massively
reduced the range of potential source networks for the script-kiddy
attacks. Also, unless the spoof is coming from a very close-by (or
local) network, it's unlikely to be able to complete an ssh handshake,
because the return packets will not reach the spoofer.

> > 7: If you are IPv6 capable, turn off IPv4 access.
> Why? Are all the skript kiddies staying away from IPV6?

Because it reduces the potential sources. And oddly enough, yes, most
of the script kiddies DO seem not to use IPv6. I have not had a SINGLE
such attack on my IPv6-capable networks. Doesn't mean others are not
seeing them. When IPv6 becomes more widespread, I guess it will pick
up, but for now this is a simple way to reduce the opportunities for
such attacks if you are lucky enough to be able to use IPv6.

> > > My password is in no dictionary
> > Don't bet on that.
> r0C<3t5c!ensN0+?
> 
> Yeah. Unfortunately, L337$pe4< can be partially automated these days.

It's more that people are really bad at choosing good passwords. Even
people who are trying hard to choose good ones end up choosing bad
ones. A bad passphrase on an ssh private key is much better than a bad
password being used directly.

Regards, k.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4