15

Can someone tell what does this mean? I tried a command like lastb to see last user logins and I see some strange logins from China (server is EU, I am in EU). I was wondering if these could be login attempts or successfull logins?

These seem to be very old and usually I lock port 22 to my IPs only, I think I had the port open for a while, last log is in July.

root     ssh:notty    222.92.89.xx     Sat Jul  9 12:26 - 12:26  (00:00)
root     ssh:notty    222.92.89.xx     Sat Jul  9 12:04 - 12:04  (00:00)
oracle   ssh:notty    222.92.89.xx     Sat Jul  9 11:43 - 11:43  (00:00)
gary     ssh:notty    222.92.89.xx     Sat Jul  9 11:22 - 11:22  (00:00)
root     ssh:notty    222.92.89.xx     Sat Jul  9 11:01 - 11:01  (00:00)
gt05     ssh:notty    222.92.89.xx     Sat Jul  9 10:40 - 10:40  (00:00)
admin    ssh:notty    222.92.89.xx     Sat Jul  9 10:18 - 10:18  (00:00)
  • 1
    Do you see these names together with that IP in /var/log/auth too? – ott-- Jun 17 '12 at 16:09
19

lastb only shows login failures. Use last to see successful logins.

| improve this answer | |
6

It shows people trying to upload or download content. The "notty" part means no tty (where tty is short for teletype) which these days means no monitor or gui, and the ssh indicates port 22, which taken together mean something like scp or rsync.

So not hacking or login attempts, but wrong or mistyped passwords. It might be some content was located via google, but required a password which someone tried to guess.

Actually, on reflection, the above is not right. They could be failed login attempts via ssh, as the questioner suspected; and (as I missed first time) they are at regular 21 or 22 minute intervals which suggests a degree of automation, but lastb shows failures by definition, so these results would need to be compared against last to see if any were successful.

| improve this answer | |
3

Close port 22. Configure your sshd to listen on a different port, and install and run denyhosts.

| improve this answer | |
2

Why dont use last ?? Please use the 'last' command, and look for ips from china or outside usa.

Also... man is your friend man lasttb

Lastb is the same as last, except that by default it shows a log of the file /var/log/btmp, which contains all the bad login attempts.

| improve this answer | |
1

Yes those appear to be login attempts as the same IP used multiple usernames to attempt entry. Most likely a Brute Force attack.

To resolve this:

Install Fail2Ban and block failed login attempts with a -1 this makes their ban permanent.

Add a jail file to protect SSH. Create a new file with the Nano editor or vi , vim

nano /etc/fail2ban/jail.d/sshd.local

To the above file, add the following lines of code.

[sshd]

enabled = true

port = ssh

"#"action = firewallcmd-ipset

logpath = %(sshd_log)s

maxretry = 5

bantime = -1

| improve this answer | |
-1

RE: lastb

"ssh:notty" /var/log/btmp entries indicate failed login attempts from the SSH port number assigned in "/etc/ssh/sshd_config".

For security reasons, the SSH port will usually have been changed to a number other than "22". So, "ssh", in this context, merely means the currently assigned (non-22) SSH port number.

Because a successful SSH certificate handshake SHOULD always be required to reach the login screen, any "ssh:notty" log entries likely result from your own failed login attempts; usually from a mistyped username. Note the IP address associated with the log entry ... it's probably your own!

"notty" means "no tty".

Learn basic security, how it works, where the logs are and how to interpret them, and where the various config files are and what the directives mean, and how to configure IPTables, before you setup and use a Linux server. Restrict logins to a "static IP address" and limit/restrick login attemps:

BASIC SSH config directives which restrict logins and only allow logins from particular users and IP addresses:

LoginGraceTime 30
MaxStartups 3:50:10
MaxAuthTries 4
PermitRootLogin no
AllowUsers YourUserName@YourIPAddress
PubkeyAuthentication yes
AuthorizedKeysFile   %h/.ssh/authorized_keys
PasswordAuthentication no

Don't forget to "restart" the SSH service after editing.

BASIC IPTables rules which only allow SSH connections from a particular static IP address:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW                                 -j DROP
-A INPUT -m state --state INVALID -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp -s YourStaticIPAddress -m multiport --dports SSHPortNumber -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
COMMIT

Dont' forget to "restore" IP tables after changes.

On a LAN, or in a "hosted" cloud environment, don't forget to secure the "private" side (network adapter). Your enemies often already have access to your network and come in through the back door.

If you are in a cloud environment such as RackSpace or DigitalOcean, and you foul up the configurations and lock yourself out, you can always go in through the console and fix it. ALWAYS MAKE COPIES OF CONFIG FILES BEFORE EDITING THEM !!!

| improve this answer | |

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.