Hello all,
Can anyone please help out with configuring PAM? I've checked a couple of tutorials online.. though most of them are related to Login though I want to set PAM up for SSH logins... I've set the max erroneous logins to just THREE and even after trying to login with an error pass I still can get in...
also is there a way I could enable the PAM module which uses crack library to check the strength of a users password?
any help with this is truly appreciated... thanks in advance
On Mon, Jan 4, 2010 at 12:42 PM, Roland Roland R_O_L_A_N_D@hotmail.comwrote:
Hello all,
Can anyone please help out with configuring PAM? I've checked a couple of tutorials online.. though most of them are related to Login though I want to set PAM up for SSH logins... I've set the max erroneous logins to just THREE and even after trying to login with an error pass I still can get in...
I use a combination of /etc/login.defs and the faillog utility to set this.
From the faillog manpage:
-m, --maximum MAX Set maximum number of login failures after the account is disabled to MAX. Selecting MAX value of 0 has the effect of not placing a limit on the number of failed logins. The maximum failure count should always be 0 for root to prevent a denial of services attack against the system.
also is there a way I could enable the PAM module which uses crack library to check the strength of a users password?
This should do it:
Roland Roland wrote on Mon, 4 Jan 2010 19:42:02 +0200:
though most of them are related to Login though I want to set PAM up for SSH logins...
AFAIK ssh already uses PAM, look in /etc/pam.d
I've set the max erroneous logins to just THREE and even after trying to login with an error pass I still can get in...
What *exactly* did you set where and what did you expect?
Kai
On 1/4/2010 12:42 PM, Roland Roland wrote:
also is there a way I could enable the PAM module which uses crack library to check the strength of a users password? any help with this is truly appreciated...
/etc/pam.d/system-auth-ac
The default is:
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so
A stronger version is:
# See: http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html password requisite pam_cracklib.so try_first_pass retry=3 minlen=20 difok=5 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok remember=36 password required pam_deny.so
(Note that the entire line that starts with "password" should be all on one line. It'll make sense when you view the system-auth-ac file. There are 3 password lines by default, and all you're going to do is add options to the first two lines.)
The key changes that I made to my setup are:
- Added "minlen=20", note that cracklib gives a bonus point if you use a number, symbol or different case character. So the minimum length is as short as 16 characters (4 less then what you set minlen to). But that minimum length is only achievable if you use both upper and lower case letters along with at least one symbol and at least one number. Minimum length should never be below 10 or 12 (in my opinion).
- The 'try_first_pass' tells cracklib to do some checking of the supplied password against a built-in word list. I don't remember the details behind how it works.
- Added "difok=5", which says that the new password (when the user changes it) has to be at least 5 letters different from the old password. In general, you'll want this to be about 1/3 to 1/4 of the minlen value.
- Added remember=36, which tells pam_unix to remember the last 36 passwords. So if a user wants to change their password, it can't be any of the past 36 passwords. Which is probably overkill to the Nth degree.
...
(Minor ramble about why I say minlen should be set to at least 10-12.)
My current estimate is that a $1500 PC can brute-force about 2-4 billion MD5 password hashes per second now. (Using NVIDIA Cuda in a 4-way SLI setup.) That's an offline attack where the attacker has a copy of your password hash. A completely random 8-char password can be found in about half a day. Add 2 more characters and it'll takes more like 2 years.
Things go a lot slower if they're simply doing a dictionary attack on the SSH port (where they don't have the MD5 hash). Those attacks typically go after low-hanging fruit using common usernames + common passwords. Plus you can throttle the SSH logins or do other things (at the risk of locking yourself out). Keep in mind that modern SSH dictionary attacks ping your machine about once every few minutes from thousands of different IP addresses. Locking out an IP address after 3 incorrect attempts only works against attackers that aren't using a slow-attack botnet.
So in situations where you can throttle the attacker, 8 random chars is probably enough. But if you want something a little easier to type, you'd best go for 10-12 chars and assume that the attacker has the hash.
For what do you need the hash? You don't supply the hash for logging in.
Kai
On 1/5/2010 7:31 AM, Kai Schaetzl wrote:
For what do you need the hash? You don't supply the hash for logging in.
In the case of SSH login, you are correct that the hash is not used to login. But the attacker may find a way to read the hash out of the /etc/shadow file, or the same password is used in other places and also stored with a md5 hash.
A lot of things would have to go wrong for a remote attacker to get access to /etc/shadow - but it's been known to happen.
(Personally, I always move the SSH port to something other then 22 and we only allow authentication via public keys over the external port.)