break-in attempt in my machine

Thu Sep 1 11:55:57 UTC 2016

If you have a /64 or a /48 IPv6 available, Just use one of them _only_  for ssh. With the millions possible adresses, even kiddies Won't find them accidentally.
And with the first failure, just change your AAAA entry.

Verstuurd vanaf mijn iPhone

> Op 30 aug. 2016 om 06:09 heeft Joel Rees <joel.rees at gmail.com> het volgende geschreven:
>
> 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
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
>

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.