Topic: Heavy attacs against sshd

[arne]

Today I have got houndreds or thousends logon attempts against the sshd deamon. This fills up the log files and I don't like it (even though noone have managed to log on, so far.)

So I opened the server-manager for logon from everywhere. I then log on via ssl/https and locks down / open up the sshd access as required.

Any reason that this is not a good choice ? (think about the public server-manager log on access.)

By the way hackers ip: 193.151.74.65, 66.182.17.4, 82.103.128.60, 157.27.14.93 210.240.55.2, 85.216.60.31

Best reg Arne.

[warren]

Hi Arne,
You did not mention what version of SME U are running ?
However look atthe the following links re ssh private-public keys to  further lock down ssh.

http://www.wellsi.com/sme/ssh/ssh.html

http://www.carrollweb.net/putty/putty-howto.html

[arne]

Thanks for info !

Sme is 6.0.1, I think (Latest before 6.5)

Is it possible to use the private-public keys to lock out unvanted logons ?? (Have allvays thought of this mechanism as some "encrypting the datastream only mechenism".

I think that the sshd logon attempts is made by some automated routines, possible running on a hacked machine.

The logon attempts has a frequency of approx 1 per second, and that should be to quick for a manual attempt. After some houndreds of attempts, it changes over to some other source ip and continues with the same.

Looks like some "distributed" or "coordinated" logon attempt possible performed by some infected PC's.

By the way it would be interesting to check out the operating system on the source PC's. Have not done that yet.

As the attack seems to be rather massive and automated from many source ip's I guess it is not directed against tne Sme server specificly, but that it is rather based on some broad general scans for sshd's on the net.

I should guess/beleive that to make the server-admin panel accessable from anyvere via ssl is a smaller risk as this will at least only be voluntary to specific sme server attacs ??

Arne.

[arne]

By the way, checked on the ip's a little bit. (But not to deep) Seems to be Linux/Unix machines all of them. .. So it is not Windows machines that happen to have got infected by some malware.

So it looks more like "real hackers" working on some "projects" from different PC's in the world.

Two of them:
http://85.216.60.31/
http://210.240.55.2/

I think this is a bit interesting because it can/will affect practically all of us.

Arne.

[chris burnat]

Over the past year or two, I have setup a few servers using sftp.  {I know... there are probably better way to give access to files, but to date, it has worked OK].  I allow rssh for selected users, and all was well until we started to be bombarded by robots trying to log onto all sort of users or root, or admin over ssh.  Last month, I changed port 22 to a higher port, say 2233 as an example. Magic! The logs now a quiet as a mouse, not a single attempt at ssh logon except for my users. chris.

[cc_skavenger]

I change the port that sshd listens on.  It has worked great.  I pick an obscure port and tell sshd to listen there.

Here is a howto:

http://www.ccskavenger.info/SME/Howtos/Changing-the-default-ssh-port.htm

HTH

[raem]

arne

> Is it possible to use the private-public keys to
> lock out unvanted logons ?? (Have allvays thought > of this mechanism as some "encrypting the
> datastream only mechenism".


You have missed the point totally.

Public/Private keys requires a code key on your originating Windows workstation that must be the partner of the code key on the server, for that particular user.
You do not even need to enter a password (if you choose to configure the key that way) as your login to the server will only be accepted if you have the partner key on your workstation.
You create the pair of keys initially using the ssh-keygen program, and then install the public key on the server and the private key on any workstation(s) you are accessing from. You should treat workstation security appropriately (password only logon and screen saver passwords etc).

The other important part of securing your server and stopping unwanted ssh login attempts, is to disable (ie set to No) the setting in server manager/Remote access/Secure Shell settings for "Allow secure shell access using standard passwords".
With this set at No, it's IMPOSSIBLE for anyone to login using ssh with normal passwords. Anyone can only access using public/private keys.
The hackers can try as much as they like but all attempts will not be accepted. There is no way they can get their public key onto your server.

I highly recommend you read the HOWTO by Ian Wells and implement public/private key access control.

http://www.wellsi.com/sme/ssh/ssh.html

[raem]

arne

> The other important part of securing your server
> and stopping unwanted ssh login attempts, is to
> disable (ie set to No) the setting in server
> manager/Remote access/Secure Shell settings
> for "Allow secure shell access using standard
> passwords".

To tighten security even further you could restrict access to local network connections only ie set the setting for Secure shell access to "Allow access only from local networks"
You would then VPN into the server, then connect using ssh with the hostname of http://serverIP, and connect using standard passwords or public/private keys as desired/preferred.

That way you can allow local LAN workstations to connect via ssh using standard passwords, and remote connections can use VPN/public-private keys. Attempts by hackers to logon using standard passwords will be blocked as no ssh connections directly from the Internet are allowed at all (only via VPN which is established first).

[arne]

Thanks for info !

Yes, I have to admit that I never had understod that things about the private and public keys ..

(Hopefully I understand it now

Can it be said easy like this:

There is two alternative methods for giving the right clients access:

1. The quick and easy with a password. The server key is the downloaded to the client for encryption og the data stream. (Right .. ??)

2. The methos of using a private and a public key. When the client has installed the right private key, no password is needed, and no hacker can log on using a password either.

Is this "approxemately" the way it work ??

(.. But is it then possible to combine the use of a private key and a password, or  .. ??)

Best reg Arne.

[raem]

arne

> 1. The quick and easy with a password.

This does not involve any public or private keys

The connection is made using ssh and that provides the security.


> 2. The method of using a private and a public key. > When the client has installed the right private
> key, no password is needed, and no hacker can log on using a password either.

Yes & no.
You have the public key installed on the server and the private key on the remote workstation.
Normal password access is still accessible unles you disable it. You would then be "forced" to use public/private keys as that will be the only way to ssh to your server, as normal password access is disabled.


> But is it then possible to combine the use of a
> private key and a password...

Ther are two parts to this answer.
1) Your p/p key can require you to enter a password when logging on if that is what you select when creating the pair of keys.
You can also create the key pair without requiring the use of a password.
Try generating some keys as an experiment using the HOWTO and you will see what I mean.

2) As far as using normal password ssh access and p/p key access, you can do both at the same time.
You need to keep normal passwords enabled, so you are back to the scenario of allowing anybody to test/crack your server with ssh login attempts using normal passwords and common account names.
If all your passwords are strong this should not really be a problem as all attempts will be rejected, but some people seem concerned when they see these attempts in the log files. Really strong passwords are the answer though.

If you want to block these attempts and still allow ssh normal password logins as well as key pair logins, then you would disable ssh access from Internet and only allow ssh access from the Local network (which means LAN or VPN connections). In this case a external user is forced to establish a VPN connection first and then use either normal passwords or key pair login.

It just depends how much security you want in place and how important security is to you, and whether or not you find the need to VPN first an inconvenience.

Personally I prefer to close all external connection possibilities and only allow connection to just about everything via LAN or VPN.
You need to enable VPN access for users before they can VPN to your server so you have full control over who is allowed to VPN. That also prevents anybody from making unauthorised VPN connections by testing various user names.

I personally don't find the inconvenience associated with any form of security a problem, and having to VPN in first allows me to sleep soundly at night.

If your user don't like it you just tell them that's the only way it can be, unless you want to get hacked !!

[HebsgaardS]

Today I have got houndreds or thousends logon attempts against the sshd deamon.

... <Stuff deleted>.

Best reg Arne.

I have seens similar attacks. My personal solution has been to add rules to iptables that simply drops network packets on the ssh port from the ip-addresses that are flooding my server. This has worked well even though it is probably not the "correct" way.

Stefan

[gordonr]

My personal solution has been to add rules to iptables that simply drops network packets on the ssh port from the ip-addresses that are flooding my server.

If you have e-smith-packetfilter-1.15.0-03 or above installed, you can do the following:

Code: [Select]

/sbin/e-smith/db configuration setprop sshd TCPPort 22
/sbin/e-smith/db configuration setprop sshd AllowHosts <list>
/sbin/e-smith/signal-event remoteaccess-update

where <list> is a comma separated list of IP addresses and/or netmasks (e.g. 16.17.18.19,203.14.64.0/24).

Ssh will then only be allowed from those IP addresses. The firewall code will drop ssh connections from any other hosts.

BTW: Changing the listen port is only a minor deterrent and (IMO) provides a false sense of security.

[mdo]

Gordon,

thanks for that information (and the contributed rpm).

Would that version of packet-filter also allow to restrict access for selected IP addresses only for MS terminal-server access which is an opened port (TCP 3389), forwarded onto a TS on the internal network?
That would be great to do it that way.

Michael Doerner

[gordonr]

Gordon,

thanks for that information (and the contributed rpm).

Would that version of packet-filter also allow to restrict access for selected IP addresses only for MS terminal-server access which is an opened port (TCP 3389), forwarded onto a TS on the internal network?
That would be great to do it that way.

Michael Doerner

Untested, but something like this should do it:

Code: [Select]

db configuration set msterminalserver service \
    TCPPort 3389 \
    access public \
    status enabled \
    AllowHosts 1.2.3.4

along with a TCP port forward to the internal host.

Naturally, this feature of e-smith-packetfilter is in 7.0. It might be good to have a DenyHosts property as well.

[mdo]

Many thanks for that Gordon.

I will test it this weekend and will let you know.

Michael