Einbruchversuch in meinen Rechner ...??

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Einbruchversuch in meinen Rechner ...??

Volker Wysk
Hallo!

Ich bekomme in der /var/log/auth.log eine Menge Meldungen, die so aussehen:

-----------------------
...
Aug 27 12:06:05 desktop sshd[7406]: PAM 2 more authentication failures;
logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:08 desktop sshd[7412]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:10 desktop sshd[7412]: Failed password for root from
221.194.44.218 port 48680 ssh2
Aug 27 12:06:15 desktop sshd[7412]: message repeated 2 times: [ Failed
password for root from 221.194.44.218 port 48680 ssh2]
Aug 27 12:06:16 desktop sshd[7412]: Received disconnect from 221.194.44.218
port 48680:11:  [preauth]
Aug 27 12:06:16 desktop sshd[7412]: Disconnected from 221.194.44.218 port
48680 [preauth]
Aug 27 12:06:16 desktop sshd[7412]: PAM 2 more authentication failures;
logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:19 desktop sshd[7418]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:21 desktop sshd[7418]: Failed password for root from
221.194.44.218 port 59535 ssh2
Aug 27 12:06:27 desktop sshd[7418]: message repeated 2 times: [ Failed
password for root from 221.194.44.218 port 59535 ssh2]
Aug 27 12:06:27 desktop sshd[7418]: Received disconnect from 221.194.44.218
port 59535:11:  [preauth]
Aug 27 12:06:27 desktop sshd[7418]: Disconnected from 221.194.44.218 port
59535 [preauth]
...
-----------------------

Das geht schon seit gestern so. Für mich sieht das so aus, als ob da jemand
versucht, über SSH einzubrechen, indem er viele mögliche Paßwörter
durchprobiert.

Ist das richtig?

Mein Paßwort ist in keinem Wörterbuch oder sonstwie naheliegend, so daß ich
mir keine großen Sorgen mache, daß der Einbruch gelingen könnte.

Volker


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Volker Wysk
Sorry for the wrong language. Here's the English translation:


Hello!

I get a log of messages in /var/log/auth.log, which look like that:

-----------------------
...
Aug 27 12:06:05 desktop sshd[7406]: PAM 2 more authentication failures;
logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:08 desktop sshd[7412]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:10 desktop sshd[7412]: Failed password for root from
221.194.44.218 port 48680 ssh2
Aug 27 12:06:15 desktop sshd[7412]: message repeated 2 times: [ Failed
password for root from 221.194.44.218 port 48680 ssh2]
Aug 27 12:06:16 desktop sshd[7412]: Received disconnect from 221.194.44.218
port 48680:11:  [preauth]
Aug 27 12:06:16 desktop sshd[7412]: Disconnected from 221.194.44.218 port
48680 [preauth]
Aug 27 12:06:16 desktop sshd[7412]: PAM 2 more authentication failures;
logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:19 desktop sshd[7418]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
Aug 27 12:06:21 desktop sshd[7418]: Failed password for root from
221.194.44.218 port 59535 ssh2
Aug 27 12:06:27 desktop sshd[7418]: message repeated 2 times: [ Failed
password for root from 221.194.44.218 port 59535 ssh2]
Aug 27 12:06:27 desktop sshd[7418]: Received disconnect from 221.194.44.218
port 59535:11:  [preauth]
Aug 27 12:06:27 desktop sshd[7418]: Disconnected from 221.194.44.218 port
59535 [preauth]
...
-----------------------

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.

Is this correct?

My password is in no dictionary, and is also not obvious in any other way, so
I don't worry much that the break-in might get successful.

Volker



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

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

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

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

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

5: If you will only be logging in from a limited set of other systems,
allow ssh logins only from those addresses (or subnets).

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.

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

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

9: Consider setting up portknocking.

> My password is in no dictionary

Don't bet on that.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Jonesy
On Sat, 27 Aug 2016 21:58:05 +1000, Karl Auer wrote:

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

  1.5: Disable root login via ssh

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

+1 !
I did that and in the 3 years since I've only had TWO (2!) singular hits
on my ssh port -- and both of those appeared to be innocent screwups
from the other end.  Before that I was getting hundreds (sometimes
1,000's) of ssh login attempts on port 20 per day.  
 
> 8: Consider setting up something like fail2ban, which will blacklist
> the IP address of anyone who tries (and fails) too frequently.

Recommended, also:  sshguard
Make sure you have at least one ssh login active before you start
messing around with the config files.  :-)

Jonesy


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Karl Auer
In reply to this post by Karl Auer
On Sat, 2016-08-27 at 21:58 +1000, Karl Auer wrote:
> 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:

Here's a blog entry with more specifics on how do do the things I
suggested:

http://biplane.com.au/blog/?p=426

Thanks Jonesy for the sshguard suggestion. Looks quite a bit simpler
than fail2ban.

By the way, anyone that has ssh access open to the world MUST take
extra precautions. At an absolute minimum, any account that can log in
via ssh MUST have a VERY GOOD PASSWORD - twenty or thirty random
characters including numbers, punctuation and both cases. Otherwise you
WILL get hacked. But it would be a much better idea to read the above
blog entry and implement the first few ideas at least.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Kevin O'Gorman
I've had the similar experience with port 22.  When I had it open, I was deluged with login attempts.  I switched to another port, not even a very random one, and it went down to zero.  And stayed there.  Now it's more random, and NO password gets you in without my having your public key, and I only take keys from my own machines, so that's never going to be the main attack vector.

Nevertheless, I'm gonna read Karl's blog, and maybe tighten it up some more.  Portknocking?  sshguard?  We'll see.

On Sat, Aug 27, 2016 at 6:39 PM, Karl Auer <[hidden email]> wrote:
On Sat, 2016-08-27 at 21:58 +1000, Karl Auer wrote:
> 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:

Here's a blog entry with more specifics on how do do the things I
suggested:

http://biplane.com.au/blog/?p=426

Thanks Jonesy for the sshguard suggestion. Looks quite a bit simpler
than fail2ban.

By the way, anyone that has ssh access open to the world MUST take
extra precautions. At an absolute minimum, any account that can log in
via ssh MUST have a VERY GOOD PASSWORD - twenty or thirty random
characters including numbers, punctuation and both cases. Otherwise you
WILL get hacked. But it would be a much better idea to read the above
blog entry and implement the first few ideas at least.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users



--
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Kevin O'Gorman
I should add that I don't use the Linux configs to change the port.  I do that in my router.  It does NAT (network address translation) and sends particular incoming ports to different hosts, with a port change.  I had to do that anyway, to allow incoming traffic at all, so I saved a step.  Inside the router, it all looks like port 22.  Come to think of it, if I do port knocking I'll have to get the router involved in that as well or the knocks will never be seen.

On Sat, Aug 27, 2016 at 9:10 PM, Kevin O'Gorman <[hidden email]> wrote:
I've had the similar experience with port 22.  When I had it open, I was deluged with login attempts.  I switched to another port, not even a very random one, and it went down to zero.  And stayed there.  Now it's more random, and NO password gets you in without my having your public key, and I only take keys from my own machines, so that's never going to be the main attack vector.

Nevertheless, I'm gonna read Karl's blog, and maybe tighten it up some more.  Portknocking?  sshguard?  We'll see.

On Sat, Aug 27, 2016 at 6:39 PM, Karl Auer <[hidden email]> wrote:
On Sat, 2016-08-27 at 21:58 +1000, Karl Auer wrote:
> 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:

Here's a blog entry with more specifics on how do do the things I
suggested:

http://biplane.com.au/blog/?p=426

Thanks Jonesy for the sshguard suggestion. Looks quite a bit simpler
than fail2ban.

By the way, anyone that has ssh access open to the world MUST take
extra precautions. At an absolute minimum, any account that can log in
via ssh MUST have a VERY GOOD PASSWORD - twenty or thirty random
characters including numbers, punctuation and both cases. Otherwise you
WILL get hacked. But it would be a much better idea to read the above
blog entry and implement the first few ideas at least.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users



--
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.




--
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Karl Auer
On Sat, 2016-08-27 at 21:15 -0700, Kevin O'Gorman wrote:
> I should add that I don't use the Linux configs to change the
> port.  I do that in my router.  It does NAT (network address
> translation) and sends particular incoming ports to different hosts,
> with a port change.

Defence in depth: Each system should protect itself first, and any
others downstream if it can. So by all means implement what you can in
your router. However, most people will not have routers that are able
to do much.

But also configure your internal systems to resist attack. Change the
ports on them, allow publickey access only etc. That way they resist
internal attacks, do not rely on the router, and will not be
defenceless if one day you make a mistake configuring your router.

Also, for IPv6, the router will probably NOT be doing NAT or port
forwarding, so your systems will not be getting even that meagre
"protection".

> Come to think of it, if I do port knocking
> I'll have to get the router involved in that
> as well or the knocks will never be seen.

With IPv6 they sure will... and those ssh script kiddies will have
DIRECT access to ssh unless you take steps. With IPv4 and port
forwarding, they effectively already do, so once again: Configure each
system to protect itself. It's not hard.

Regards, K.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Chris Green
My defence is simply that of only allowing ssh logins from two
specific IPs.  I allow logins from my TsoHost hosting (where I have
ssh access) and from another system 'out there' where I have ssh
access.

Both 'intermediate' systems have strong passwords and so does my
system at home.

Using a ProxyCommand in the .ssh/config makes the login fairly
painless, one just enters one password after the other.

Thus most of the defending against ssh attempts on port 22 is exported
to systems where it's their bread and butter to handle the problem.

--
Chris Green

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

J.Witvliet
In reply to this post by Volker Wysk
No problem with that.
Some further suggestions....
You Can limit the amount of incoming calls with iptables (against continously dictionaire attacks)

Even better, there is a patch for openssh, that you Can use PKI certificates , like those stored on smartcards

You Can also add Google-two stap authentication....

Verstuurd vanaf mijn iPhone

> Op 27 aug. 2016 om 12:56 heeft Volker Wysk <[hidden email]> het volgende geschreven:
>
> Sorry for the wrong language. Here's the English translation:
>
>
> Hello!
>
> I get a log of messages in /var/log/auth.log, which look like that:
>
> -----------------------
> ...
> Aug 27 12:06:05 desktop sshd[7406]: PAM 2 more authentication failures;
> logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
> Aug 27 12:06:08 desktop sshd[7412]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
> Aug 27 12:06:10 desktop sshd[7412]: Failed password for root from
> 221.194.44.218 port 48680 ssh2
> Aug 27 12:06:15 desktop sshd[7412]: message repeated 2 times: [ Failed
> password for root from 221.194.44.218 port 48680 ssh2]
> Aug 27 12:06:16 desktop sshd[7412]: Received disconnect from 221.194.44.218
> port 48680:11:  [preauth]
> Aug 27 12:06:16 desktop sshd[7412]: Disconnected from 221.194.44.218 port
> 48680 [preauth]
> Aug 27 12:06:16 desktop sshd[7412]: PAM 2 more authentication failures;
> logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
> Aug 27 12:06:19 desktop sshd[7418]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.194.44.218  user=root
> Aug 27 12:06:21 desktop sshd[7418]: Failed password for root from
> 221.194.44.218 port 59535 ssh2
> Aug 27 12:06:27 desktop sshd[7418]: message repeated 2 times: [ Failed
> password for root from 221.194.44.218 port 59535 ssh2]
> Aug 27 12:06:27 desktop sshd[7418]: Received disconnect from 221.194.44.218
> port 59535:11:  [preauth]
> Aug 27 12:06:27 desktop sshd[7418]: Disconnected from 221.194.44.218 port
> 59535 [preauth]
> ...
> -----------------------
>
> 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.
>
> Is this correct?
>
> My password is in no dictionary, and is also not obvious in any other way, so
> I don't worry much that the break-in might get successful.
>
> Volker
>
>
>
> --
> ubuntu-users mailing list
> [hidden email]
> 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.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

No Spam
Hi,

and you should disable root login and users like admin eg,
to make it harder for skript kiddies.

if you use obfuscation techniques eg non standard port, be aware that
you are only protected from kiddies and not a personalized hack!

disable password only, eg setup a authentification setting to combine
2FA ( google-authenticator) and password / better public key

Greets


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Kevin O'Gorman
In reply to this post by Karl Auer
On Sat, Aug 27, 2016 at 10:35 PM, Karl Auer <[hidden email]> wrote:
On Sat, 2016-08-27 at 21:15 -0700, Kevin O'Gorman wrote:
> I should add that I don't use the Linux configs to change the
> port.  I do that in my router.  It does NAT (network address
> translation) and sends particular incoming ports to different hosts,
> with a port change.

Defence in depth: Each system should protect itself first, and any
others downstream if it can. So by all means implement what you can in
your router. However, most people will not have routers that are able
to do much.

But also configure your internal systems to resist attack. Change the
ports on them, allow publickey access only etc. That way they resist
internal attacks, do not rely on the router, and will not be
defenceless if one day you make a mistake configuring your router.
 
Of course.  That's why I disable password logins, which would be enough by itself in a perfect world.
 
Also, for IPv6, the router will probably NOT be doing NAT or port
forwarding, so your systems will not be getting even that meagre
"protection".

> Come to think of it, if I do port knocking
> I'll have to get the router involved in that
> as well or the knocks will never be seen.

With IPv6 they sure will... and those ssh script kiddies will have
DIRECT access to ssh unless you take steps. With IPv4 and port
forwarding, they effectively already do, so once again: Configure each
system to protect itself. It's not hard.


I wasn't going to worry about IPv6 until my ISP starts handling IPv6 packets.  Come to think of it, I don't think my router handles them either.
 
Regards, K.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users



--
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Joel Rees
In reply to this post by Karl Auer
I'm feeling ornery today.

2016/08/27 20:58 "Karl Auer" <[hidden email]>:

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

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Joel Rees
n Tue, Aug 30, 2016 at 7:34 AM, Karl Auer <[hidden email]> 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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Karl Auer
On Tue, 2016-08-30 at 13:07 +0900, Joel Rees wrote:
> And my thought there was that skript kiddies are no longer the only
> people we should worry about.

Here's a lesson learned from a zillion hours of training people: Don't
try to do everything at once.

The OP had a specific problem, recognisable as script kiddy attacks. My
response addressed that, and anyone following through on the first few
of my suggestions will have a robust system, which will see very few
script kiddy attacks if any, and those they do see will not succeed.

They will have a robust system; not an impervious one.

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

Well, you go do that. But please don't do it by muddying the waters
around what was a simple problem with easy-to-implement solutions.

When someone wants to learn how to make toast, you don't immediately
try to sell them a fully kitted-out professional kitchen and start
telling them how vitally important it is to understand everything about
the use and abuse of automated chrome-plated fuel-injected turnip-
twaddlers.

> A quick browse through /etc/services is amusing.

Pick a random port number >1024 and the chances are very good that it
will be a port number you can use. Simple advice, easily followed.
Unlike "do a thousand hours of research to locate the optimally suited
set of port numbers".

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

What? Who said "all-IPv6"? If you can access your network via IPv6, as
an increasing proportion of the civilised world can, then turning off
IPv4 access to ssh is a simple and VERY effective way to stop script
kiddies (and a pretty large number of other attacks, too). So far,
anyway.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Kevin O'Gorman
Another data point.  I've got two machines, listening for ssh on two different arbitrary ports.  I took a look at /var/log/auth.log on both machines, and found bad stuff on both.  Nothing bad happened, because of other measures, but there's certainly more activity now than I though there'd be.  Here are the snippets of bad stuff:

Aug 29 02:36:56 Plato sshd[15693]: Bad protocol version identification '\003' from 108.175.157.187 port 64816
Aug 29 05:09:20 Plato sshd[24656]: Bad protocol version identification '\003' from 75.145.88.253 port 58685
Aug 29 05:09:20 Plato sshd[24657]: Bad protocol version identification '\003' from 75.145.88.253 port 58707
Aug 29 05:09:21 Plato sshd[24658]: Bad protocol version identification '\003' from 75.145.88.253 port 58728
Aug 29 05:44:01 Plato sshd[26704]: Bad protocol version identification '\003' from 99.252.214.204 port 65191
Aug 29 05:44:01 Plato sshd[26710]: Bad protocol version identification '\003' from 99.252.214.204 port 65206
Aug 29 05:44:02 Plato sshd[26711]: Bad protocol version identification '\003' from 99.252.214.204 port 65216
Aug 31 10:31:19 Plato sshd[20442]: Bad protocol version identification '\003' from 185.93.185.235 port 51162

and

Aug 29 02:36:59 camelot-x sshd[5250]: Bad protocol version identification '\003' from 108.175.157.187 port 64815
Aug 29 05:08:21 camelot-x sshd[6895]: Bad protocol version identification '\003' from 184.68.81.210 port 52326
Aug 29 05:08:21 camelot-x sshd[6896]: Bad protocol version identification '\003' from 184.68.81.210 port 52353
Aug 29 05:08:21 camelot-x sshd[6897]: Bad protocol version identification '\003' from 184.68.81.210 port 52375
Aug 29 05:43:10 camelot-x sshd[7271]: Bad protocol version identification '\003' from 23.91.71.35 port 62831
Aug 29 05:43:10 camelot-x sshd[7272]: Bad protocol version identification '\003' from 23.91.71.35 port 62849
Aug 29 05:43:10 camelot-x sshd[7273]: Bad protocol version identification '\003' from 23.91.71.35 port 62857
Aug 29 13:19:09 camelot-x sshd[13493]: Bad protocol version identification 'GET / HTTP/1.1' from 79.1.32.105 port 50161
Aug 29 19:10:12 camelot-x sshd[17326]: Bad protocol version identification 'GET / HTTP/1.1' from 187.110.211.33 port 37036
Aug 30 21:20:29 camelot-x sshd[27845]: Bad protocol version identification 'GET / HTTP/1.1' from 38.122.48.158 port 36990
Aug 31 07:48:48 camelot-x sshd[2885]: Bad protocol version identification 'GET / HTTP/1.1' from 167.249.144.2 port 44935
Aug 31 08:29:30 camelot-x sshd[3313]: Bad protocol version identification 'GET / HTTP/1.1' from 181.118.134.45 port 42856
Aug 31 12:58:45 camelot-x sshd[6483]: Bad protocol version identification 'GET / HTTP/1.1' from 203.159.10.103 port 49502
Aug 31 14:14:10 camelot-x sshd[7309]: Bad protocol version identification 'GET / HTTP/1.1' from 186.211.108.26 port 41155

Running whois(1) on these IP numbers yields a variety of ISPs from all over the world.

I don't know what the \003 things are doing.  The GET is a web page request.
My web server is on port 80, but the query seen above just gets you a static page with no links.  But no matter what you request,
none of the pages take any input other than clicks, so I'm not worried. The text for page they requested reads

It works!

This far, anyway.

This is the default web page for the kosmanor.com server.

You will need a more specific URL to see any content.





On Mon, Aug 29, 2016 at 9:33 PM, Karl Auer <[hidden email]> wrote:
On Tue, 2016-08-30 at 13:07 +0900, Joel Rees wrote:
> And my thought there was that skript kiddies are no longer the only
> people we should worry about.

Here's a lesson learned from a zillion hours of training people: Don't
try to do everything at once.

The OP had a specific problem, recognisable as script kiddy attacks. My
response addressed that, and anyone following through on the first few
of my suggestions will have a robust system, which will see very few
script kiddy attacks if any, and those they do see will not succeed.

They will have a robust system; not an impervious one.

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

Well, you go do that. But please don't do it by muddying the waters
around what was a simple problem with easy-to-implement solutions.

When someone wants to learn how to make toast, you don't immediately
try to sell them a fully kitted-out professional kitchen and start
telling them how vitally important it is to understand everything about
the use and abuse of automated chrome-plated fuel-injected turnip-
twaddlers.

> A quick browse through /etc/services is amusing.

Pick a random port number >1024 and the chances are very good that it
will be a port number you can use. Simple advice, easily followed.
Unlike "do a thousand hours of research to locate the optimally suited
set of port numbers".

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

What? Who said "all-IPv6"? If you can access your network via IPv6, as
an increasing proportion of the civilised world can, then turning off
IPv4 access to ssh is a simple and VERY effective way to stop script
kiddies (and a pretty large number of other attacks, too). So far,
anyway.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
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




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users



--
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

J.Witvliet
In reply to this post by Karl Auer
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 <[hidden email]> het volgende geschreven:
>
> n Tue, Aug 30, 2016 at 7:34 AM, Karl Auer <[hidden email]> 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
> [hidden email]
> 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.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Mark Haney-3
I'm a bit late to the party, and I'm not sure if this has been mentioned, but this is where Fail2Ban is ideal. I never put in a production web server (or ANY public server) without having Fail2Ban configured to block stuff like this.  Doesn't really fix this problem, but it will avoid a LOT of this in the future.


On Thu, Sep 1, 2016 at 7:55 AM, <[hidden email]> wrote:
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 <[hidden email]> het volgende geschreven:
>
> n Tue, Aug 30, 2016 at 7:34 AM, Karl Auer <[hidden email]> 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
> [hidden email]
> 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.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users



--

Mark Haney ::: Senior Systems Engineer

VIF International Education
P.O. Box 3566 ::: Chapel Hill, N.C. 27515 ::: USA
919-265-5006 office

Global learning for all.
www.viflearn.com
Find VIF on Facebook | Twitter | LinkedIn

Recognized as a ‘Best for the World’ B Corp!


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: break-in attempt in my machine

Volker Wysk
In reply to this post by Jonesy
Am Samstag, 27. August 2016, 22:50:49 CEST schrieb Jonesy:
> > 1: Turn off password access; require a publickey login.
>
>   1.5: Disable root login via ssh

This would also disable root login via sftp. You cant't do a "sudo -s" in
sftp...

Volker


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
12