break-in attempt in my machine

[Joel Rees]

I'm feeling ornery today.

2016/08/27 20:58 "Karl Auer" <kauer at biplane.com.au>:
>
> On Sat, 2016-08-27 at 12:54 +0200, Volker Wysk wrote:
> > This already goes on like this since yesterday. For me, this looks
> > like someone tries to break in my machine via SSH, by trying many
> > possible passwords.
>
> Almost certainly yes.
>
> Having ssh open to the world is better than having most other things
> open to the world. but there are quite a few things you can do to make
> a successful attack less likely. In order of goodness:
>
> 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.

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

> 2: Move ssh to a different port. Choose a random number between 1024
> and 65000 and put ssh on that port.

Check commonly used port definitions. Watch your logs to be sure you
don't acidentally use a port used by malware, etc. Also, remember that
port sniffing occurs and network traffic monitoring (Boxes do get
pwned on the LAN.) will reveal the accesses even if they can't decode
them.

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

> 3: Turn off ssh access for any accounts on your system that do not need
> it

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.

> 4: If you only need external access for certain commands, lock ssh down
> to permitting only those commands.

Or even just build custom apps that don't need a shell. We do way too
much building fancy hammers to drive screws with.

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

> 6: If you know you will only be logging in at certain times of the day
> or on certain days, turn off ssh access outside those times.

Similar issues to the time-controlled vaults at the bank, of course.
Be careful not to lock legitimate exceptional/emergency accesses out.

> 7: If you are IPv6 capable, turn off IPv4 access.

Why? Are all the skript kiddies staying away from IPV6?

> 8: Consider setting up something like fail2ban, which will blacklist
> the IP address of anyone who tries (and fails) too frequently.

This one is important, and helpful against both targeted and
non-targeted attacks. Just be careful how you tune it, and make sure
you won't be locking yourself out in an emergency when you are
fumble-fingered.

> 9: Consider setting up portknocking.

Port-knocking was once thought to be the best way to deal with a LAN
you couldn't trust, but I think the current thought is that it may
well be in the domain of diminishing returns. You need to understand
what is happening and why it might be useful, and consider the
implementation carefully.

> > My password is in no dictionary
>
> Don't bet on that.

r0C<3t5c!ensN0+?

Yeah. Unfortunately, L337$pe4< can be partially automated these days.