break-in attempt in my machine

[Joel Rees]

n Tue, Aug 30, 2016 at 7:34 AM, Karl Auer <kauer at biplane.com.au> wrote:
> On Tue, 2016-08-30 at 06:34 +0900, Joel Rees wrote:
>> I'm feeling ornery today.
>
> Clearly!

Yeah.

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

And my thought there was that skript kiddies are no longer the only
people we should worry about.

It's a good list to get started, but we should really be encouraging
users to understand what logging in means, how it is done, how these
attacks use our computers against us, and so forth.

> who are trying only
> passwords. Using publickey makes a successful ssh login with only a
> password impossible.

One thing that people miss is that the keyboard and the network are
two separate vectors. What's appropriate for one is not appropriate
for the other.

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

How confident can the average user who has been surfing random places
in the Internet be that one of the browser scripts, etc., that has
detached itself from a recent browser session is not, in fact, a
keylogger?

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

A quick browse through /etc/services is amusing.

So is a walk through a resource like

    https://www.sans.org/security-resources/idfaq/which-backdoors-live-on-which-ports/8/4

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

Actually, I was thinking of some time back when I moved home
workstation ssh port to something like 33561 and found I was living an
exciting life. So to speak. Not a neighborhood I had intended to be
in.

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

But we need to be thinking about whether the kiddies are the only
attackers we need to worry about.

I know I have nothing of value in my home network. My son might not be
so sure he has nothing of value in my network. Or some attacker might
think I look like I might have something valuable, just because I rant
strange things in my blogs from time to time.

Moving the port doesn't always make the attacks disappear. You need to
check your logs periodically. Of course, as you'll point out here,
attacks on an upper range port are something more of a cause for
concern than attacks on port 22.

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

It matters less, anyway. Still, sudo admin looks a lot more
interesting in a keylogger report than sudo tom.

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

It's the pwned boxes on the inside of the local network that we need
to think about, isn't it?

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

Well, if you can afford to go all-IPv6 now, I think you've just told
the attackers you have something interesting in you network.

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

So let's point at lessons in how to choose or make up hard, but useful
passwords and passphrases, because, even though, as you say,

> A bad passphrase on an ssh private key is much better than a bad
> password being used directly.

you still want good protection on your local keystore.

(Suggesting you add a little theory to your blogpost you linked to a
bit back. I know how easy it is to get offtrack when you dig into
theory. Some of my own technical blogposts tend to be so esoteric that
they may be more hindrance than help to the average user, but I think
it's important to try to help each other understand what's going on.)

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2016/06/econ101-novel-toc.html