|
Page 1 of 3 It’s inevitable: if your computer is Internet-connected you will have people coming a-knockin’. Fortunately Linux users are more savvy than to think any keep-alive ping or other piece of Internet flotsam is a hack attempt. Even so, it’s simply a matter of time before your router’s lights flash heavily and /var/log/auth.log (/var/log/secure on RedHat) fills with chilling messages like these:
$ tail /var/log/auth.log
Aug 1 20:23:41 zugzug sshd[15577]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.218.125.178
Aug 1 20:23:44 zugzug sshd[15577]: Failed password for invalid user edward from 210.48.230.5 port 43812 ssh2
Aug 1 20:23:46 zugzug sshd[15581]: Invalid user erik from 210.48.230.5
Aug 1 20:23:46 zugzug sshd[15581]: (pam_unix) check pass; user unknown
Aug 1 20:23:46 zugzug sshd[15581]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.218.125.178
Aug 1 20:23:49 zugzug sshd[15581]: Failed password for invalid user erik from 210.48.230.5 port 44088 ssh2
Aug 1 20:23:51 zugzug sshd[15585]: Invalid user eduardo from 210.48.230.5
Aug 1 20:23:51 zugzug sshd[15585]: (pam_unix) check pass; user unknown
Aug 1 20:23:51 zugzug sshd[15585]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.218.125.178
Aug 1 20:23:53 zugzug sshd[15585]: Failed password for invalid user eduardo from 210.48.230.5 port 44346 ssh2
The warnings are clear: someone is trying to log in via sshd, the secure shell daemon, trying random username and password combinations. And, as great as high-bandwidth is, the downside is that malicious forces can attempt thousands of login attempts in a very short time.
Now, the right term for a person who attempts to exploit security is a cracker, but “hacker” – rightfully an inquisitive and enthusiastic person – has been popularised as a malicious meddler. Nevertheless, at this point in time semantics are the last thing on your mind: whether you're being hacked or cracked you’ve got to secure your system and keep out the bad guys.
In fact, someone successfully logging in is only one of your worries. Firstly, each attempt adds several lines to your log files. In time, a lot of disk space is wasted and your logs become almost meaningless with other information you might be seeking being well hidden amongst the tens of thousands of repetitive entries.
And, more importantly, a high-speed multi-threaded attack runs the risk of denying your service by consuming all your bandwidth – let alone system resources. And if your system is too busy handling these connections, how will you log in, yourself?
So then - what do you do?
Lock down sshd
The very first step is to beef up the security on SSH itself. Firstly, you don’t want anyone logging in to your system as root. This gives unfettered power. This doesn’t stop you remoting in to your system using an ordinary user account and su’ing to root. Edit the /etc/ssh/sshd_config file and ensure it has an entry “PermitRootLogin no”. This means ssh will just prevent root logins; any attempt will fail even if the password is right. Best of all, the failure message gives no hint the connection failed because of this rule; it looks like any other bad username/password combo. This means your cracker has to guess a genuine username and password so their work is made much harder.
Depending on how flexible your network is, you might also consider changing the port number that SSH listens on. By default, it uses port 22 and this is the port crackers will be attempting to use. You could change this to some other arbitrary port. You will still be able to SSH in, specifying the appropriate port number, but others will have no success unless they realise firstly there’s another port open, and secondly that it is used for SSH (the fact a non-standard port is open gives no immediate information as to the protocol it uses.) Once again, edit /etc/ssh/sshd_config and set a customised port number on the ListenAddress line.
This is a good start. Yet, there’s still more to do. The biggest problem is there’s no built-in mechanism to stop repeated login attempts from the same IP address, even if it is failing continually.
|