Understanding auth.log and access attempts
At the moment, I don't fully understand all that's being reported in the log files. I've got some questions about some lines in auth.log.
Firstly, am I correct in thinking that it's not a good idea to post lines from this log file verbatim? I'll edit out any of the IP addresses and not post anything that gives anything away about the access done by me in person. I don't know how paranoid you have to be about these things.
I'm pretty sure the lines I see like this are expected:
Apr 27 19:09:01 CRON[11900]: pam_unix(cron:session): session closed for user root
Apr 27 19:17:01 CRON[11912]: pam_unix(cron:session): session opened for user root by (uid=0)
If I've got that right, it's just a cron job that pam_unix runs regularly for some reason (OT: why? is it just housekeeping).
However there are lines that are like this:
Apr 27 20:25:01 sshd[11944]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:03 sshd[11944]: Failed password for root from IP-DELETED port 35161 ssh2
Apr 27 20:25:05 sshd[11947]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:06 sshd[11947]: Failed password for root from IP-DELETED port 35449 ssh2
Apr 27 20:25:08 sshd[11949]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:10 sshd[11949]: Failed password for root from IP-DELETED port 35737 ssh2
Apr 27 20:25:11 sshd[11951]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:13 sshd[11951]: Failed password for root from IP-DELETED port 36037 ssh2
Apr 27 20:25:14 sshd[11953]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:16 sshd[11953]: Failed password for root from IP-DELETED port 36304 ssh2
Apr 27 20:25:17 sshd[11955]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:19 sshd[11955]: Failed password for root from IP-DELETED port 36594 ssh2
Apr 27 20:25:20 sshd[11957]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:23 sshd[11957]: Failed password for root from IP-DELETED port 36830 ssh2
Apr 27 20:25:25 sshd[11959]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:27 sshd[11959]: Failed password for root from IP-DELETED port 37144 ssh2
Apr 27 20:25:28 sshd[11961]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:30 sshd[11961]: Failed password for root from IP-DELETED port 37461 ssh2
Apr 27 20:25:31 sshd[11963]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:33 sshd[11963]: Failed password for root from IP-DELETED port 37718 ssh2
Apr 27 20:25:34 sshd[11965]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:36 sshd[11965]: Failed password for root from IP-DELETED port 37975 ssh2
Apr 27 20:25:37 sshd[11967]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:39 sshd[11967]: Failed password for root from IP-DELETED port 38195 ssh2
Apr 27 20:25:40 sshd[11969]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED user=root
Apr 27 20:25:41 sshd[11969]: Failed password for root from IP-DELETED port 38433 ssh2
Apr 27 20:25:43 sshd[11971]: Invalid user oracle from IP-DELETED
Apr 27 20:25:43 sshd[11971]: pam_unix(sshd:auth): check pass; user unknown
Apr 27 20:25:43 sshd[11971]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED
Apr 27 20:25:45 sshd[11971]: Failed password for invalid user oracle from IP-DELETED port 38676 ssh2
Apr 27 20:25:46 sshd[11973]: Invalid user test from IP-DELETED
Apr 27 20:25:46 sshd[11973]: pam_unix(sshd:auth): check pass; user unknown
Apr 27 20:25:46 sshd[11973]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP-DELETED
Apr 27 20:25:48 sshd[11973]: Failed password for invalid user test from IP-DELETED port 38935 ssh2
Given that this wasn't me (:)), I'm pretty sure this indicates someone trying to ssh into my server and (I'm fairly sure!) failing. An automated attack, maybe? I'm not sure how fast those scripts can be.
Given I'm all new to this, I'm wondering if I need to be concerned about stuff like that or whether it's par for the course. Do I need to be securing my ssh logins a bit tighter? (I've already disabled root logins for ssh). Closing ports? Not worrying quite so much?
12 Replies
If you haven't already, you should 1) change ssh to a non-default port, 2) disallow ssh logins from unknown addresses (iptables or frontend of choice), and perhaps disable tunneled passwords, only allowing preprepared ssh keys.
For other Linode newbies who are wanting to configure your ssh, there's a guide on the config file (for Debian at least) here: http://www.debian-administration.org/articles/455
The guide doesn't seem to say directly, but for Debian the config file is /etc/ssh/sshd_config. If you want ssh to accept the changes, restart it with /etc/init.d/ssh restart.
Big note: if you're playing with this, I think it's a good idea to have a backup terminal logged in with ssh. If you manage to make ssh a bit too secure, you won't be able to log back in! Check after you've made the changes whether you can log back in, but have another terminal logged in in case you need to make emergency changes.
The lines I've changed are:
Port yoursshport - change this from the default 22 to something higher. You'll probably need to specific the port when you log in with ssh from now on though (on MacOSX, it's now ssh
Protocol 2 - the newer protocol is more secure, so I don't need protocol 1
PermitRootLogin no - it's better to login as another user, then use su to change to root. Make sure you create a new user first!
AllowUsers yourlogin - if like me only you need access to the server, I think it makes sense to lock down access to just one account. You can always change to other accounts once you've logged in.
I'm currently debating whether I should lock the whole system down to public keys only. On the plus side, it's a step up in security. On the minus, if I lose my key then I'm completely locked out. The same applies to locking down to just certain ISP ranges - I just don't know if the one I use to log in with is going to change in the near future and possibly without my control. With all the other changes I'm thinking I might need to trade off accessibility for security there.
Any other SSH config changes I've missed?
Also: re: access attempts: should I just be monitoring them, or actively locking them down? Is there an easy way to do that?
Edit: And I guess the thing I'm most concerned about is someone logging in without me spotting it. I'm assuming that whatever they do they'll turn up in the logs, but I should look into fining ways to inform me about any shenanigans going on behind my back.
> On the minus, if I lose my key then I'm completely locked out.
Backup, backup, backup!
> The same applies to locking down to just certain ISP ranges
At the very least, you could lock it down to your closest block (unless you're planning on switching isp's soon ?) It can also be useful to place a rate limit on ssh connections.
> access attempts: should I just be monitoring them, or actively locking them down? Is there an easy way to do that?
Fail2ban, denyhosts, blockhosts etc. can be set to lock out persistent attackers, but often it's simpler to just restrict services & access beforehand.
> I'll edit out any of the IP addresses and not post anything that gives anything away about the access done by me in person. I don't know how paranoid you have to be about these things.
If it's one of your ip addresses, then yes, best comment it out.
If they belong to some miscreant doing a dictionary attack (knowingly or not), it could be considered a public service to leave as is.
@btmorex:
I don't usually change my ssh port, but I usually disable password authentication. Also, consider using something like fail2ban (
http://www.fail2ban.org/wiki/index.php/Main_Page ).
I suppose I've got a silly attachment to standard password authentication, what with my usual experiece of Unix-like interfaces being at university. If it all happens silently in the background it looks like it's not there. That's not a particularly good reason, is it?:)
Thanks for the ref to fail2ban. Would using public key access only invalidate the need for that, or in your opinion does it still help even if it just cleans up the logs?
>
@mjrich:
> On the minus, if I lose my key then I'm completely locked out.
Backup, backup, backup!
Heh. I guess I was just thinking of having the key as any old regular file on my system. I do have a regular backup system automated on my home computer which would catch something like a public key file and save it for me, but the issue I was worried about was time. In the event of a catastrophic computer failure it would take me a day or two to set everything up again, during which I'd be locked out.
But I realise there's nothing stopping me just burning a few CDs with the key on them to use as backups, so that's not a good enough reason either.
>
> The same applies to locking down to just certain ISP ranges
At the very least, you could lock it down to your closest block (unless you're planning on switching isp's soon ?) It can also be useful to place a rate limit on ssh connections.
I'm not sure I can rely on me sticking with the same ISP IP range. There's a fair chance I might switch soon. And there's also a fair chance I might have to use temporary ISPs as stop-gap measures. Recently our ISP has problems with water-logging in the cables and the connection used to be intermittent or go down completely for days. They've fixed the issue but I'm not sure I can rely on it 100%. There's always the chance I might need to use another dial-up system as a backup method in the future. So I'm a bit hesitant to lock myself to a very specific IP range.
> Fail2ban, denyhosts, blockhosts etc. can be set to lock out persistent attackers, but often it's simpler to just restrict services & access beforehand.
So if I'm savvy enough with my login security, I should be okay? (Well, for a security relative value of okay?)
@mjrich:
If they belong to some miscreant doing a dictionary attack (knowingly or not), it could be considered a public service to leave as is.
Well, it would tell people to look out for that IP, but in the off-chance it's a hapless zombie system it would also say it's easy pickings.;)
> I do have a regular backup system automated on my home computer which would catch something like a public key file
Best check that it is indeed being backed up. (I was caught by this ages ago, when I discovered that hidden files/directories were being skipped in one of the backup scripts).
> If it all happens silently in the background it looks like it's not there. That's not a particularly good reason, is it?
No
Some of the best things happen silently in the background. (A pet annoyance with that other common os, incidentally - it tells you whenever something actually works as requested. *NIX, by contrast, generally only lets you know when something fails to work).
> So if I'm savvy enough with my login security, I should be okay? (Well, for a security relative value of okay?)
Personally, I'd watch your logs carefully after locking everything down as much as possible, and then decide whether you want to install fail2ban etc.
@trazoi:
@btmorex:I don't usually change my ssh port, but I usually disable password authentication. Also, consider using something like fail2ban (
http://www.fail2ban.org/wiki/index.php/Main_Page ).
I suppose I've got a silly attachment to standard password authentication, what with my usual experiece of Unix-like interfaces being at university. If it all happens silently in the background it looks like it's not there. That's not a particularly good reason, is it?:) Thanks for the ref to fail2ban. Would using public key access only invalidate the need for that, or in your opinion does it still help even if it just cleans up the logs?
Yeah, if you disable password auth, you have nothing to worry about from a security perspective. I use fail2ban too mostly because I don't like having hundreds or thousands of failed attempts in my logs, which makes it harder to see actual problems.
Also, you save a small amount of server resources blocking these attempts via a firewall.
@trazoi:
And I guess the thing I'm most concerned about is someone logging in without me spotting it.
Almost automatically when I log into a server I run last -10 to see who's logged in recently. Especially helpful when figuring out who to blame for breaking some configuration setting. :-)
@Vance:
I Have Heard(TM) that changing sshd to a non-standard port generally forestalls the bot login attempts, making something like fail2ban or denyhosts unnecessary.
This is largely true, but won't stop malicious hosts that port scan your server to discover and identify open ports.
@mjrich:
Best check that it is indeed being backed up. (I was caught by this ages ago, when I discovered that hidden files/directories were being skipped in one of the backup scripts).
Thanks, that could have been an issue. I have a Mac as my local computer and I'm using Time Machine for my backups, and it was enitrely feasible that hidden directories like .ssh would have been left out of the loop. However it looks as if the latest Time Machine sweep has picked up the new keys, so it's all good. Besides which, I've also burnt a CD with the keys on them for emergencies which I'll store with my backups.
As for ssh logins: I've set PubkeyAuthentication to yes and set the AuthorisedKeyFile to the right place, checked I could log in using my local key and passphrase, and disabled PasswordAuthentication. It looks like I'm set.
@Vance:
Almost automatically when I log into a server I run last -10 to see who's logged in recently. Especially helpful when figuring out who to blame for breaking some configuration setting.
:-)
Thanks, that's a great command to know! It's good to see that the only logins so far have been from my ISP and the Linode reboot system.:)
I'll probably install fail2ban later once I've got everything else sorted out. It's on the list, but I'm mostly focusing on a base level of security and functionality to begin with. I can then ramp that up later once I'm comfortable with the basics. If the ssh login is safe enough now then that's the main issue.