SSH - getting a lot hacking attempts

Associate
Joined
19 Jun 2003
Posts
1,675
Location
West Yorks, UK
Hi all,

I have a Ubuntu 6.06LTS Server running sshd. I have "real" users conencting and sending data to me, but i'm finding I am having a lot of break-in attempts too - people putting obvious names like "admin" and "test" and of course "root", and trying to break in.

I have opened port 22 on my firewall and forwarded it to the Linux server. The real users are connecting on port 22 - i've noticed the break-in attempts are on high ports around 3000-4500 or so. Unfortunately, my users don't have static WAN addresses, so I can't restrict access that way. Is there anything else I can do to protect the server and its data from being attacked?

Matt
 
Associate
Joined
4 May 2003
Posts
582
You can get applictions that will dynamicly configure iptables rules based on these attempts on your server, the name of them escapes me but google will give you more details.

You could try moving the sshd to run on an obscure port but this is bad security, you simply move the risk rather than reducing it.

As long as you are enforcing a strong password policy and have all the default accounts turned off you should be ok.

Attempts at compromise like this are just a product of having an internet facing service which doesnt have some form of filtering in place.

Oh and if the service is listening on port 22, how can they be attempting to gain access on the high ports you mention?

Just make sure all your users are using a secure password, one that is going to be hard to bruteforce.
 
Man of Honour
Joined
15 Nov 2005
Posts
2,124
Location
Basingstoke, UK
I switched my ssh listening port from 22 to something else and the attempts have pretty much stopped - mostly the script kiddies are just sniffing out port 22 and if they find an open port they'll try to hack it. If they tried to brute force an ssh attack on every port on every machine connected to the 'net it would take forever. Unless your server is of particular interest and they take a personal interest (rather than just running some kiddie scripts), your alternative ssh port is likely to get overlooked.

It's not the only step you should take but it certainly can help lower the chances of getting found :)
 
Associate
Joined
19 Jun 2003
Posts
1,675
Location
West Yorks, UK
Thanks guys. I'm not sure if I can change the port, as I am using a distribution of RSync for Windows to send the data - ill have to check that up.

I don't understand about the high ports thing either. Port 22 is open on the router, but in auth.log, the failed attempts all try to connect to port 3000-4500 or so. No idea how that works!

What are the default accounts that can be turned off? Root is set so that no remote logins are allowed for starters. Anything else I can disable?

Matt
 
Soldato
Joined
18 Oct 2002
Posts
7,139
Location
Ironing
Hang on, how do you know that people are breaking into port 3000-4500? It's only listening on 22, and wouldn't report any port number in the log.

*Unless* what you're seeing is the port the 'hackers' are connecting from their end? The high port numbers are reserved for outgoing connections usually, so it's entirely feasable that an ssh connection would originate at port 3xxx.

What you can do is enable key based authentication on sshd. Then, all clients must preset with the correct key file for their account, and you can configure a passphrase on that key as well. Then the server will just reject out flat any connections which don't preset with a key, and any system accounts which don't have the other half of the key configured in their ~/.ssh/authorised_keys file won't have any access allowed, as no key exists for them - effectively disabled from ssh login. A lot of automated stuff which needs ssh login supports key-based authentication these days, so it's worth looking at.
 
Last edited:
Associate
Joined
19 Jun 2003
Posts
1,675
Location
West Yorks, UK
The port numbers are reported in /var/log/auth.log - it tells me when authentication has failed, and what port they were connecting on.

I have installed the "Firestarter" firewall to try and monitor it a bit more, but I can't be bothered staying up until 3am when all these attacks happen ;)

Every real user has a /.ssh/authorized_keys file in their home folder, which was generated at their end with "ssh-keygen -t rsa", with no passphrase and then rsync'ed onto the server. Am I able therefore, to do what you are suggesting?
 
Soldato
Joined
18 Oct 2002
Posts
7,139
Location
Ironing
If you had a firewall, you wouldn't be able to see any clients initiate on any ports you weren't running services on. Sshd certainly wouldn't reply on any port other than what it's listening on. Can you give an example of a line from auth.log?

As for the keys bit - that command should have generated two files - a public and a private. The public key gets kept on the server in the authorized_keys file, and the private key should be kept secure by the user who wants to log in. Then, depending on what ssh client the user is using, they can present the private key to the server, which matches it against their public key. If it's a match, they get access. A lot of services you can give a private key to and they'll use it when logging in via ssh too. Difficult to say more without knowing the exact details of your setup...
 
Associate
Joined
19 Jun 2003
Posts
1,675
Location
West Yorks, UK
Here are some sample lines from my Auth.log then:
Code:
Oct  6 02:52:40 localhost sshd[18243]: Failed password for invalid user delta from 202.54.138.5 port 1686 ssh2
Oct  6 02:52:45 localhost sshd[18248]: Failed password for invalid user admin from 202.54.138.5 port 1909 ssh2
Oct  6 02:52:51 localhost sshd[18253]: Failed password for invalid user test from 202.54.138.5 port 2066 ssh2
Oct  6 02:52:57 localhost sshd[18262]: Failed password for invalid user testing from 202.54.138.5 port 2266 ssh2
Oct  6 02:53:02 localhost sshd[18272]: Failed password for invalid user tester from 202.54.138.5 port 2432 ssh2
Oct  6 02:53:07 localhost sshd[18281]: Failed password for invalid user academy from 202.54.138.5 port 2585 ssh2
Oct  6 02:53:12 localhost sshd[18290]: Failed password for invalid user protector from 202.54.138.5 port 2747 ssh2
Oct  6 02:53:16 localhost sshd[18299]: Failed password for daemon from 202.54.138.5 port 2902 ssh2
Oct  6 02:53:21 localhost sshd[18307]: Failed password for invalid user skylyn from 202.54.138.5 port 3046 ssh2
Oct  6 02:53:27 localhost sshd[18316]: Failed password for invalid user guest from 202.54.138.5 port 3207 ssh2
Oct  6 02:53:32 localhost sshd[18326]: Failed password for invalid user webmaster from 202.54.138.5 port 3369 ssh2
Oct  6 02:53:36 localhost sshd[18336]: Failed password for invalid user master from 202.54.138.5 port 3516 ssh2
Oct  6 02:53:41 localhost sshd[18346]: Failed password for invalid user masters from 202.54.138.5 port 3669 ssh2
Oct  6 02:53:46 localhost sshd[18354]: Failed password for mysql from 202.54.138.5 port 3808 ssh2
Oct  6 02:54:00 localhost sshd[18364]: Failed password for invalid user oracle from 202.54.138.5 port 3966 ssh2
Oct  6 03:30:00 localhost sshd[21614]: reverse mapping checking getaddrinfo for host81-130-215-202.in-addr.btopenworld.com failed - POSSIBLE BREAKIN ATTEMPT!
Oct  6 03:41:54 localhost sshd[22588]: reverse mapping checking getaddrinfo for host81-130-215-202.in-addr.btopenworld.com failed - POSSIBLE BREAKIN ATTEMPT!

As you can see, the port numbers are all high up the range.

Matt
 
Associate
Joined
4 May 2003
Posts
582
I seriously doubt sshd is running on all of those ports, that must be the source port of the TCP connection.

In terminal enter the following command and see what port it is listening on.

netstat -l | grep ssh

You could always try port scanning your box on those high ports just to make sure, but as I have said, they look like source ports.

Implement the key solution mentioned in this thread and you should be fine.
 
Associate
Joined
19 Jun 2003
Posts
1,675
Location
West Yorks, UK
Heres the output:
Code:
netstat -l | grep ssh

tcp6       0      0 *:ssh                   *:*                     LISTEN
unix  2      [ ACC ]     STREAM     LISTENING     13078    /tmp/ssh-JsBqYL5726/a                                      gent.5726

Does the provide any clues? I'm a bit of a Newbie to all this ;)

Matt
 
Associate
Joined
4 May 2003
Posts
582
That shows that ssh is listening on the default port 22.

Try entering the following and see what other ports are open and what services are running on them.

netstat -l

I would be *very* surprised if ssh was running on anything but port 22 if you haven't modified the sshd configuration.
 
Associate
Joined
19 Jun 2003
Posts
1,675
Location
West Yorks, UK
Result of netstat -l. Seems to be a lot of ports opened?:
Code:
:~$ netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 localhost:mysql         *:*                     LISTEN
tcp        0      0 localhost:submission    *:*                     LISTEN
tcp        0      0 *:5900                  *:*                     LISTEN
tcp        0      0 localhost:60335         *:*                     LISTEN
tcp        0      0 *:ftp                   *:*                     LISTEN
tcp        0      0 localhost:ipp           *:*                     LISTEN
tcp        0      0 localhost:smtp          *:*                     LISTEN
tcp        0      0 localhost:43737         *:*                     LISTEN
tcp6       0      0 *:www                   *:*                     LISTEN
tcp6       0      0 *:ssh                   *:*                     LISTEN
udp        0      0 *:xdmcp                 *:*
udp        0      0 192.168.8.6:ntp         *:*
udp        0      0 localhost:ntp           *:*
udp        0      0 *:ntp                   *:*
udp6       0      0 *:ntp                   *:*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     STREAM     LISTENING     669443   /var/run/acpid.socket
unix  2      [ ACC ]     STREAM     LISTENING     11141    /tmp/.gdm_socket
unix  2      [ ACC ]     STREAM     LISTENING     11187    /tmp/.X11-unix/X0
unix  2      [ ACC ]     STREAM     LISTENING     12556    /var/run/sendmail/mta/smcontrol
unix  2      [ ACC ]     STREAM     LISTENING     13078    /tmp/ssh-JsBqYL5726/agent.5726
unix  2      [ ACC ]     STREAM     LISTENING     13102    /tmp/orbit-administrator/linc-168f-0-79c398cb729d0
unix  2      [ ACC ]     STREAM     LISTENING     13112    /tmp/orbit-administrator/linc-165e-0-97c11b18580c
unix  2      [ ACC ]     STREAM     LISTENING     13248    /tmp/.ICE-unix/5726
unix  2      [ ACC ]     STREAM     LISTENING     13257    /tmp/keyring-wvgLv2/socket
unix  2      [ ACC ]     STREAM     LISTENING     13269    /tmp/orbit-administrator/linc-1694-0-7ab299b892d35
unix  2      [ ACC ]     STREAM     LISTENING     13293    /tmp/orbit-administrator/linc-1696-0-299946a2e4541
unix  2      [ ACC ]     STREAM     LISTENING     13301    /tmp/.esd-1000/socket
unix  2      [ ACC ]     STREAM     LISTENING     13329    /tmp/orbit-administrator/linc-169d-0-43920cf28254c
unix  2      [ ACC ]     STREAM     LISTENING     13384    /tmp/orbit-administrator/linc-16a0-0-58108cb1bd899
unix  2      [ ACC ]     STREAM     LISTENING     13413    /tmp/orbit-administrator/linc-16a7-0-73c5cd747e460
unix  2      [ ACC ]     STREAM     LISTENING     13435    /tmp/orbit-administrator/linc-16ab-0-73c5cd74a83a9
unix  2      [ ACC ]     STREAM     LISTENING     13463    /tmp/orbit-administrator/linc-16a9-0-66eba9bc889b
unix  2      [ ACC ]     STREAM     LISTENING     13497    /tmp/orbit-administrator/linc-16b2-0-66eba9bc533c6
unix  2      [ ACC ]     STREAM     LISTENING     13520    /tmp/orbit-administrator/linc-16bb-0-74ff9523770fb
unix  2      [ ACC ]     STREAM     LISTENING     13549    /tmp/orbit-administrator/linc-16b4-0-66eba9bc8f8c2
unix  2      [ ACC ]     STREAM     LISTENING     13575    /tmp/orbit-administrator/linc-16b7-0-66eba9bcbf7fd
unix  2      [ ACC ]     STREAM     LISTENING     13604    /tmp/orbit-administrator/linc-16c7-0-14bed6423d0f2
unix  2      [ ACC ]     STREAM     LISTENING     13651    /tmp/mapping-administrator
unix  2      [ ACC ]     STREAM     LISTENING     13675    /tmp/orbit-administrator/linc-16d4-0-28702d117d0bc
unix  2      [ ACC ]     STREAM     LISTENING     13709    /tmp/orbit-administrator/linc-16df-0-49865172866b1
unix  2      [ ACC ]     STREAM     LISTENING     535945   /tmp/orbit-administrator/linc-5ac1-0-531952d392348
unix  2      [ ACC ]     STREAM     LISTENING     17918    /tmp/orbit-administrator/linc-879-0-65084d8d998a8
unix  2      [ ACC ]     STREAM     LISTENING     17956    /tmp/orbit-administrator/linc-87d-0-25785a3762eec
unix  2      [ ACC ]     STREAM     LISTENING     18011    /tmp/orbit-administrator/linc-887-0-439944c22f9f4
unix  2      [ ACC ]     STREAM     LISTENING     18063    /tmp/orbit-root/linc-88c-0-2da618e07fbae
unix  2      [ ACC ]     STREAM     LISTENING     18070    /tmp/orbit-root/linc-888-0-ca575e28222a
unix  2      [ ACC ]     STREAM     LISTENING     18092    /tmp/.esd-0/socket
unix  2      [ ACC ]     STREAM     LISTENING     11396    @/tmp/hald-local/dbus-Ucvpayl5wU
unix  2      [ ACC ]     STREAM     LISTENING     20035    /tmp/orbit-administrator/linc-f03-0-1f113e16ecf63
unix  2      [ ACC ]     STREAM     LISTENING     20067    /tmp/orbit-administrator/linc-f06-0-4ddddf4b41b4f
unix  2      [ ACC ]     STREAM     LISTENING     20108    /tmp/orbit-administrator/linc-f0a-0-7309d16378d92
unix  2      [ ACC ]     STREAM     LISTENING     11373    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     13083    @/tmp/dbus-ZoyHwRCksy
unix  2      [ ACC ]     STREAM     LISTENING     12668    /var/run/sdp
unix  2      [ ACC ]     STREAM     LISTENING     1203595  /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     17292    /var/run/cups/cups.sock
unix  2      [ ACC ]     STREAM     LISTENING     11397    @/tmp/hald-runner/dbus-2fdQHjiBZC

Matt
 
Soldato
Joined
18 Oct 2002
Posts
7,139
Location
Ironing
feenster99 said:
Here are some sample lines from my Auth.log then:
Code:
Oct  6 02:52:40 localhost sshd[18243]: Failed password for invalid user delta from 202.54.138.5 port 1686 ssh2

As you can see, the port numbers are all high up the range.

Matt

Those port numbers are all the port numbers that the connection was initiated from. In the example, someone at 202.54.138.5 connected to your ssh port. The local port they connected from is usually meaningless and just happened to be 1686 in the above case. You're just seeing the originating connection ip and port numbers.

From netstat, you have http, sshd, ftp and something on 5900 open to the world. Everything else is either only available to localhost, or is udp, or is a unix socket.
 
Associate
Joined
10 Mar 2003
Posts
285
Some other things you can do. Only allow the users you want, in the sshd_config file AllowUsers user1 user2... etc and DenyUsers user3 user4...etc to any you explicitly don't want to connect.

You can also add IP addresses or ranges in the /etc/hosts.allow and /etc/host.deny (if your users will connect from the same range/ISP/IP every time)
sshd: host.domain.here single.ip.address ip.address/range

sshd: ALL in /etc/hosts.deny

And lastly install denyhosts and play around with the configuration.
 

Una

Una

Associate
Joined
26 Nov 2004
Posts
2,471
Location
Reading / Lake District
You will be in for a lot of work if you are going to try to blacklist every ip.
There is a huge number of "attacks" (not to mention false positives) that will be generated in the logs (especially if you have an IDS (Snort etc)). In general they are nothing to worry about so long as you keep your box updated and follow the usual security precausions.
 
Top Bottom