This means people are trying to brute-force your passwords (common on any public-facing server).
It shouldn't cause any harm to clear out this file.
One way to reduce this is to change the port for SSH from 22 to something arbitrary. For some additional security, DenyHosts can block login attempts after a certain number of failures. I'd highly recommend installing and configuring it.
fail2ban can also be a great help for machines that must keep internet facing, port 22 SSH. It can be configured to use hosts.allow or iptables with flexible thresholds.
You could also examine the file with the lastb command and determine the IP number and maybe block the IP number or network from further accessing your machine. This will also provide information as to the account being hacked. Most likely it will be root but you never know
What I do, although I script it, is use the command like so:
lastb -a | awk '{print $10}' | grep -v ^192 | sort | uniq | sed '/^$/d'
**the "^192" is my local network first octet (non-routable)
I automate this (also scripted) like so:
for i in `lastb -a | awk '{print $10}' | grep -v ^192 | sort | uniq | sed '/^$/d'`; do iptables -A INPUT -s $i -j DROP ; done
iptables-save
Or
for i in `lastb -a | awk '{print $10}' | grep -v ^192 | sort | uniq | sed '/^$/d'`
do
iptables -A INPUT -s $i -j DROP
done
iptables-save
Just different look for visibility...
This works well for me
As for the size of the /var/log/btmp file you need to enable logrotate for that- look at you logrotate conf file for a similar file being rotated for how to do that- usually in /etc/logrotate.d/ - look at the syslog or yum for the format, and man logrotate will show you all the options.
C4
There is one potentially serious problem that can be caused by a huge /var/log/btmp file:
Some Linux distributions enable PAM's pam_lastlog.so with the showfailed option. What this option does is to print a message like "NNN failed login attempts since the last successful login". What they don't tell you is that there is no counter storing this NNN efficiently - instead what pam_lastlog.so does during each successful login is to read the entire /var/log/btmp file. Because this file only grows (when attackers try to guess your password), after several years on the open Internet it can easily grow to several gigabytes, and this can delay each login by many seconds - in my experience as much as a minute! This is not a security risk, but it's very very annoying for users - imagine every single ssh or scp attempt getting delayed by a minute...
Here is the relevant issue on the PAM bug tracker:
This means people are trying to brute-force your passwords (common on any public-facing server).
It shouldn't cause any harm to clear out this file.
One way to reduce this is to change the port for SSH from 22 to something arbitrary. For some additional security, DenyHosts can block login attempts after a certain number of failures. I'd highly recommend installing and configuring it.
fail2ban can also be a great help for machines that must keep internet facing, port 22 SSH. It can be configured to use hosts.allow or iptables with flexible thresholds.
You could also examine the file with the lastb command and determine the IP number and maybe block the IP number or network from further accessing your machine. This will also provide information as to the account being hacked. Most likely it will be root but you never know
What I do, although I script it, is use the command like so:
**the "^192" is my local network first octet (non-routable) I automate this (also scripted) like so:
Or
Just different look for visibility... This works well for me
As for the size of the /var/log/btmp file you need to enable logrotate for that- look at you logrotate conf file for a similar file being rotated for how to do that- usually in /etc/logrotate.d/ - look at the syslog or yum for the format, and man logrotate will show you all the options. C4
echo '' > /var/log/btmp
That will regain the space. Leave for a little to populate a bit then implement iptables, change ssh port or install and configure fail2ban
There is one potentially serious problem that can be caused by a huge
/var/log/btmp
file:Some Linux distributions enable PAM's
pam_lastlog.so
with theshowfailed
option. What this option does is to print a message like "NNN failed login attempts since the last successful login". What they don't tell you is that there is no counter storing this NNN efficiently - instead whatpam_lastlog.so
does during each successful login is to read the entire/var/log/btmp
file. Because this file only grows (when attackers try to guess your password), after several years on the open Internet it can easily grow to several gigabytes, and this can delay each login by many seconds - in my experience as much as a minute! This is not a security risk, but it's very very annoying for users - imagine every single ssh or scp attempt getting delayed by a minute...Here is the relevant issue on the PAM bug tracker:
https://github.com/linux-pam/linux-pam/issues/270
I actually had problems with fail2ban and tested sshguard https://www.sshguard.net/ Installed it and it just worked zero configuration.