Failed login control on RHEL6 with pam_tally2

pam_tally2 module is available in RHEL and CentOS and it can be used to protect your system against bruteforce attacks.

Enabling pam_tally2

Edit /etc/pam.d/password-auth and add this line on top of the auth lines:
auth        required      pam_tally2.so onerr=fail deny=3 unlock_time=900

Then add following line on top of the account lines:
account required pam_tally2.so

Parameters to this module are simple:
onerr=fail
If something weird happens (like unable to open the file), return with PAM_SUCCESS if onerr=succeed is given, else with the corresponding PAM error code. 

deny=3 
Deny access if tally for this user exceeds 3 times.

unlock_time=900 
Allow access after 900 seconds (15 minutes) after failed attempt. If this option is used the user will be locked out for the specified amount of time after he exceeded his maximum allowed attempts. If this option is not set administrator will need to unlock user's account manually.

Check if you have following options set in /etc/ssh/sshd_config:
UsePAM yes
ChallengeResponseAuthentication yes

Testing pam_tally2

login as: pajarito
Using keyboard-interactive authentication.
Password:
Access denied
Using keyboard-interactive authentication.
Password:
Access denied
Using keyboard-interactive authentication.
Password:
Access denied
Using keyboard-interactive authentication.
Account locked due to 3 failed logins
Password:

As you can see after third attempt user's account was locked.

Verifying and unlocking users

To check current pam_tally2 statistics run pam_tally2 command:
# pam_tally2
Login           Failures Latest failure     From
jsmith              3    09/09/15 15:17:21  evil.attacker.com
To unlock a user use the "-r" flag:
# pam_tally2 -u pajarito -r
Login           Failures Latest failure     From
jsmith              3    09/09/15 15:20:49  evil.attacker.com
Finally if the output of pam_tally2 is empty it means that no account has been locked.

Securing ssh server from automated bot hacks

SSH server running on some quite popular hosting is exposed to many automated attacks these days.
There are more and more bots scanning the whole Internet and especially targeting popular hosting/VPS providers.

1. Changing the default sshd port number

In contrast to other well known services (ftp/mail/www) ssh server does not need to listen on the default port. It's being used by a fewer people, sometimes only you and changing the default port is yet another step in increasing your server security.
I have been using fail2ban software for some time. It scans the logs for failed login attempts and bans the attacker's IP if he fails to login too many times.
However, after a few days my firewall was full of banned IPs (good day - 5/10 IPs, bad day - more than 20).
From now on my ssh server is always running on a non-standard IP.
The number of failed login attempts has greatly decreased and the automated attacks are no longer spamming my logs.

Some useful settings from /etc/ssh/sshd_config file:
[root@server ~]# egrep "^Port|^PermitRootLogin|^MaxAuth"  /etc/ssh/sshd_config
Port 4321
PermitRootLogin no
MaxAuthTries 3

2. Logging incoming connections

Even with ssh daemon running on a different port you may find it useful to log all the connection attempts to it. You can catch it via following iptables rule:
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4321 -j LOG --log-prefix "iptables: "
Which should be inserted before accepting the connection on ssh port.
Next if you're using rsyslogd you can filter all the messages starting with "iptables :" and put them into a separate file:
[root@server ~]# cat /etc/rsyslog.d/iptables.conf
:msg, startswith, "iptables: " -/var/log/iptables.log
& ~
[root@server ~]# service rsyslog restart

[root@server ~]# cat /var/log/iptables.log
Dec 16 18:39:41 server kernel: iptables: IN=eth0 OUT= MAC=00:1c:14:01:30:de:00:16:83:76:07:29:08:00 SRC=10.23.189.14 DST=20.40.50.101 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=31528 DF PROTO=TCP SPT=44074 DPT=4321 WINDOW=29200 RES=0x00 SYN URGP=0

Intrusion detection tools on Linux - AIDE

AIDE is an opensource file integrity check tool. It can help you verifying files integrity in an easy way.

1. Install AIDE package on CentOS/RHEL:

# yum install -y aide

2. Check and adjust aide configuration file to fulfill your needs:

# vim /etc/aide.conf

3. Initialize AIDE database - it will scan all the files in folders that were included in the config file and save their hash as well as attributes info

4. You may consider keeping golden copy of AIDE database (default is set to /var/lib/aide/aide.db.gz) is secure and read-only location. It will allow you to compare current system integrity to the golden copy.

To check what changed run:

# aide -C

If you get "Couldn't open file /var/lib/aide/aide.db.gz for reading" error it means you need to move database generated in step 3 to this location:

#  mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz