Forcing Password Complexity in Red Hat Linux

My requirement was to enforce the password complexity for all the users of my RHEL 5 server (This will works for RHEL 4/5 also). This would be helpful to you also.

Password complexity is a set of rules which define what set of characters and how many of each characters must be in a password. My policy requirement was to have:

• Minimum Length = 10
• Number of digits = 1
• At least one uppercase letter
• At least one lowercase letter
• At least one other character.

As a precautionary method, always I used to backup existing configuration file. To create a backup of the existing file:
$ cp /etc/pam.d/system-auth /root/system-auth

First I looked for the line containing the pam_cracklib module in the file /etc/pam.d/system-auth. In RHEL 5 and RHEL 6 it looks like this:
password requisite pam_cracklib.so try_first_pass retry=3

In RHEL 4 it looks like "password requisite /lib/security/$ISA/pam_cracklib.so"

This is the place where we need to edit and add my password policy configurations. I changed the line as given below to reflect the my password policy configuration requirements.

password requisite pam_cracklib.so try_first_pass retry=3 minlen=10 ucredit=-1 dcredit=-1 ocredit=-1 lcredit=-1

Same can be configured in RHEL 4 as "password requisite /lib/security/$ISA/pam_cracklib.so retry=3 minlen=10 ucredit=-1 dcredit=-1 ocredit=-1 lcredit=-1"

I had existing users on my system and I wanted to make sure they are complied with the password policy. They were enforced the change their password during the next login. To do this I needed to lock the user account, expire their password, and unlock the user account. Here are the simple step to accomplish this.

Lock the account:
$ usermod -L kushan

Expire their current password:
$ chage -d 0 kushan

Unlock the account:
$ usermod -U kushan

Check the status of their password. (This will show the current configuration of the user "kushan":
$ chage -l kushan

Description of the parameters used above is given below.

• retry=N: Prompt user at most N times before returning with error. The default is 1.
• minlen=N: The minimum acceptable size for the new password (plus one if credits are not disabled which is the default).
• reject_username: Check whether the name of the user in straight or reversed form is contained in the new password. If it is found the new password is rejected.
• dcredit=N: (N >= 0) This is the maximum credit for having digits in the new password. The default for dcredit is 1.
• lcredit=N: (N >= 0) This is the maximum credit for having lower case letters in the new password. If you have less than or N lower case letters, each letter will count +1 towards meeting the current minlen value. The default for lcredit is 1.
• ocredit=N: (N >= 0) This is the maximum credit for having other characters in the new password. The default for ocredit is 1.
• ucredit=N: (N >= 0) This is the maximum credit for having upper case letters in the new password. The default for ucredit is 1.

Read More

Blocking intrusion attempts using authentication module pam_tally2

It is possible to block these intrusions using the authentication module called "pam_tally2". This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

By default, pam_tally2 module is already installed on the most of the Linux distributions and it is controlled by PAM package itself. This is a guide to lock and unlock SSH accounts after reaching a certain failed number of login attempts.

For example I found the configuration file in my RHEL system at /etc/pam.d/password-auth.

I used ‘/etc/pam.d/password-auth‘ configuration file to configure login attempts accesses. First I opened this file and added the following AUTH configuration line to it at beginning of the ‘auth‘ section.

auth        required      pam_tally2.so  file=/var/log/tallylog deny=3 even_deny_root unlock_time=1800

Parameters of the above line is described below.

• file=/var/log/tallylog – Default log file is used to keep login counts.
• deny=3 – Deny access after 3 attempts and lock down user.
• even_deny_root – Policy is also apply to root user.
• unlock_time=1800 – Account will be locked till 30 Min.

I wanted to automatically unlock the account after 30mins. So I configured the unlock_time=1800 also. In order to block permanently till manually unlock, this needs to be removed.

Now, to verify or check the counter that auser attempts, I use the following command:

$ pam_tally2 --user=kushan

To reset or unlock the user account to enable access again, I use the following command:

$ pam_tally2 --user=kushan --reset

To verify login attempt is reset or unlocked, I use the command:

$ pam_tally2 --user=kushan

Reference
Do ‘man pam_tally2‘ from the command line inside RHEL to know more about pam_tally2.

Read More

How to Disable Directory Listings in IIS/Apache

The easiest way to disable directory listing is to create an index file. The name of the index file depends on the web server configuration. On Apache is called index.htm, index.html. On IIS is named default.asp, default.aspx, default.htm.

• On IIS directory listings are disabled by default.
• For Apache you need to edit the Apache configuration file (usually named httpd.conf) or create an .htaccess file. In the configuration file you will have the definition of the directory. Something like

Options Indexes FollowSymLinks
...
 
To disable directory listing for that directory you need to remove the ’Indexes’ option.

Reference
http://www.acunetix.com/blog/web-security-zone/directory-listing-information-disclosure/

Read More

DoS-ing & Countering Apache Web Link Saturation

Testing your webserver - DoS-ing

DoS, or Denial of Service attacks, are nothing new.  The main idea behind a DoS attack is to exhaust a devices resources (be it HTTP, some database backend, or any other form of  ‘service’) until it can’t respond to legitimate requests anymore. The most popular form of DoS (i.e. the ones you read about in the paper) is link saturation. The plan is to send a massive amount of requests to a server, much more than it normally receives, in order to saturate either the server or its link.

Recently, a new method of DoS-ing Apache HTTP servers has emerged. Recently a tool (Slowloris) has been developed by RSnake with help from John Kinsella to launch the attack. The tool works by exhausting Apache processes.  Apache comes configured to only allow a certain number of processes (default install is 256) and not answer any more requests when that limit is hit. This tool sends the first part of a HTTP request header. While Apache waits for the rest of the header, one of those 256 processes it taken up. By default, Apache will wait up to 5 minutes for those connections to complete.  Once the tool has taken up all the available connections the Apache server will not serve any new requests.

$ perl slowloris.pl -dns

Welcome to Slowloris – the low bandwidth, yet greedy and poisonous HTTP client

Defaulting to port 80.
Defaulting to a 5 second tcp connection timeout.
Defaulting to a 100 second re-try timeout.
Defaulting to 1000 connections.

This would help you to test whether your server is actually vulnerable to this kind of DoS attacks.

Countering
If you have a good baseline on your web servers and know the limits of expected traffic – there is a quick and dirty fix for this.  This fix assumes that the attack comes from the same source-ip.  The following iptables rule limits the amount of connections from the same source to 20 connections.

iptables -A INPUT -p tcp –dport 80 -m connlimit –connlimit-above 20 -j REJECT –reject-with tcp-reset

With this in place, Slowloris can only take up 20 connections per source ip, leaving the other connections open for legitimate users.



Reference

[1] Above content is mainly based on the article: http://www.redspin.com/blog/2009/06/21/dos-ing-over-dial-up/
[2] The tool is available at http://ha.ckers.org/slowloris/

Read More