2

I've set up a public-facing Debian server on a well-known web hosting provider and am trying to determine if hackers are breaking in. I know very little about securing web servers but I am trying to learn. I've configured my server to disallow root logins over SSH and I've also disabled password logins via SSH. All users must use SSH key authentication. I've also installed Fail2ban. I have an account but there aren't any other users so no one else should be logging in but me.

When I run the command "sudo last -f /var/log/btmp" to view bad login attempts I see entries like the following:

ubnt   ssh:notty   <ipaddress1>   <date1> 16:55 - 17:22  (00:27)
admin  ssh:notty   <ipaddress2>   <date2> 11:56 - 16:55  (04:58)
user   ssh:notty   <ipaddress3>   <date3> 07:47 - 08:24  (00:36)
pi     ssh:nottyp  <ipaddress4>   <date4> 10:46 - 11:11  (00:24)

Do these entries really indicate that hackers have been able to log in despite my precautions?

What I also don't understand is that if I run the command "sudo lastb -f /var/log/btmp", I'll see the same entries as above except that the "time in" and "time out" entries are all the same. In other words, instead of this:

# sudo last -f btmp
ubnt   ssh:notty   <ipaddress1>   <date1> 16:55 - 17:22  (00:27)

I see this:

# sudo lastb -f btmp
ubnt   ssh:notty   <ipaddress1>   <date1> 16:55 - 16:55  (00:00)

After reading the man page for last, lastb, the problem may be that I shouldn't be running last against btmp but that I should be running lastb against it instead. Perhaps just because you can specify a "-f " parameter for each command, that doesn't mean the commands are interchangable.

I should also add that there aren't any accounts in my /etc/passwd file with the usernames shown above. If people are still logging in without my knowledge, what other things can I do to prevent this?

Thanks.

  • If you changed the question to "why are there non-zero durations in btmp", it would be more focused on the interesting part. There should be an answer for that, but I don't know what it is. – Wumpus Q. Wumbley Aug 15 '16 at 17:01
  • Good advice. I've changed the title. – Jim Aug 15 '16 at 17:57
1

btmp is failed login attempts. Those user accounts do not have to exist to appear in that log. If you start to see weird entries in wtmp or utmp, then you should start to worry.

1

BTMP is in fact, failed login attempts. To give you a better understanding, here is an example of a brute force attack on someones login from here:

berrie ssh:notty 121.130.202.148 Thu Jul 2 06:02 - 06:02 (00:00)
berrie ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:02 (00:00)
berri ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berri ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berni ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berni ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
brenice ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
brenice ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berni ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berni ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernhard ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernhard ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernardo ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernardo ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernardi ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernardi ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernard ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernard ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernadin ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernadin ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernadin ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernadin ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernadet ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernadet ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernaden ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
bernaden ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berna ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berna ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)
berget ssh:notty 121.130.202.148 Thu Jul 2 06:01 - 06:01 (00:00)

You can see the same, excessive IP's trying to login and also the different variations of text they are using to login. It's that simple, and by the looks of yours there is nothing to worry about.

What you can do to prevent this is make sure your passwords are complex as possible. Follow this guide here to create such a password. Keep an eye on any future attempts, if any, and deny them any sort of access to the server - flag their IP and configure your firewall to prevent incoming connections.

Edit:

In reply to your comment on my post, your worry of someone logging in and staying in isn't happening in your case. They haven't logged in with the same details multiple times and neither have they used the same login twice. So, you are fine.

  • Thank you. What was making me think that someone had actually managed to log in was the last fields for each entry. In your example, you show each attempt with (00:00) in the last field. In my btmp file, I'm seeing (00:27), (04:58), etc. These non-zero durations are what is making me think someone is actually getting and staying in for some period of time. – Jim Aug 15 '16 at 16:38
  • Yes. Pay attention to that consistency, good you noticed that. You can change your current password to the server to login with. First clear your logs and check it's not yourself that's adding these logs. – iZodiac Aug 15 '16 at 16:39
  • Thanks for your edit. The problem is, I didn't show my whole btmp file. Just a couple of representative entries. If I see the same username from the same IP address with non-zero durations (the last field) multiple times in the file, should I then assume they're logging in somehow? I'll have to research this to find out what more I can do if I've already disabled logins via SSH. – Jim Aug 15 '16 at 17:01
  • Make sure to check this isn't you logging in, and are your own logs. Check your IP Address and make sure that it isn't your own either. If they aren't, I would absolutely assume that someone else is logging in. Check with the company that are hosting your server too, since they may perform updates and maintenance checks. If not that, change your password and implement better security. – iZodiac Aug 15 '16 at 17:04
  • The best way is to not use passwords at all and rely on SSH keys or client certificates. For customer-facing apps where passwords are a requirement consider using 2-factor authentication, but there is really no valid reason for administrative SSH access to use passwords. – André Borie Aug 15 '16 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.