LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 07-14-2008, 08:34 AM   #1
SecondMet
LQ Newbie
 
Registered: Jul 2008
Posts: 8

Rep: Reputation: 0
Faillog does not count failed login attempts


Hi!

I try to use pam_tally to count failed login attempts.

I am using RHEL 4 and have the following setup for /etc/pam.d/system-auth

Code:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        required      /lib/security/$ISA/pam_warn.so
auth        required      /lib/security/$ISA/pam_tally.so onerr=fail deny=5
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_warn.so
account     required      /lib/security/$ISA/pam_tally.so onerr=fail deny=5
account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_localuser.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_permit.so

password    required      /lib/security/$ISA/pam_warn.so
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so
session     required      /lib/security/$ISA/pam_warn.so

The file /var/log/faillog exists and has the access rights:

[root@rt pam.d]# ls -la /var/log/faillog
-rw-r--r-- 1 root root 16032 Jul 14 13:20 /var/log/faillog


When I try to login to the system with a valid user account name, but with a wrong password and afterwards check the faillog in a SSH-session as root user, the faillog -a only reports 0 login failures.

I did not login as the user with correct password between trying to log in with the wrong and checking the faillog, so the entries should not have been reset.

What might be wrong here?
 
Old 07-15-2008, 06:02 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
Quote:
Originally Posted by SecondMet View Post
What might be wrong here?
I don't know but maybe you're able to see the right mix of options from these examples. I can verify that:
* for remote logins using SSH on CentOS-3 using pam-0.75-72 the following entries in /etc/pam.d/ssh work:
Code:
auth         required     pam_tally.so onerr=fail file=/var/log/faillog no_magic_root
account    required     pam_tally.so onerr=fail file=/var/log/faillog no_magic_root per_user no_lock_time deny=3
* for console logins on CentOS-5 using pam-0.99.6.2-3.27.el5 the following entries in /etc/pam.d/login work:
Code:
auth       required     pam_tally.so onerr=fail file=/var/log/faillog audit deny=3 lock_time=10 unlock_time=10 no_reset per_user
auth       required     pam_tally.so onerr=fail file=/var/log/faillog audit no_reset
"Work" here meaning the faillog counter gets incremented, the entries get logged in /var/log/secure and the login gets blocked after the configured amount of attempts. Note that in both cases I specified the 'faillog -m' maximum login count beforehand, that I specified every option even if default behaviour and that I'm using service configuration files instead of the global system-auth.*.


Quote:
Originally Posted by SecondMet View Post
I did not login as the user with correct password between trying to log in with the wrong and checking the faillog, so the entries should not have been reset.
If that is an assumption you should verify that with the docs. At least with pam-0.75-72 the README.*tally.* explicitly says:
Quote:
The (4.0 Redhat) utilities seem to do funny things with uid, and I'm
not wholly sure I understood what I should have been doing anyway so
the `keep a count of current logins' bit has been #ifdef'd out and you
can only reset the counter on successful authentication
, for now.
PAM behaviour changed between release 3 and 5 and not all options (or combos of) may be that intuitive. Two other things that might help are tailing /var/log/secure to see if lines get logged and checking your PAM version against what's available in terms of updates.
 
Old 07-15-2008, 10:08 AM   #3
SecondMet
LQ Newbie
 
Registered: Jul 2008
Posts: 8

Original Poster
Rep: Reputation: 0
The problem is, the system I have to configure allows no updates to the OS or libraries. Thus I must get along with what is available.

But that might be a problem, if for 4.0 these functions are not available.

Anyhow, thanks, I will try to check the secure-log and see what gets logged there.
 
Old 07-17-2008, 02:54 AM   #4
SecondMet
LQ Newbie
 
Registered: Jul 2008
Posts: 8

Original Poster
Rep: Reputation: 0
Another strange thing is happening now:

When I start the "faillog" command, it gives its report like e.g.:

Username Failures Maximum Latest
testuser 0 5 Thu Jul 17 07:50:35 +0000 2008 on c1.srv.1.gc


But it does not return to the command prompt. I have to stop it with CTRL + C.

Does anybody have an idea what is wrong here??
 
Old 07-17-2008, 07:32 AM   #5
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
I did not say that functions aren't available. I showed you that pam_tally *will* work on RHEL-3 equivalent, so if your version of pam_tally doesn't work as advertised and you can not make it work as advertised by configuring it well, then it could be a software version problem. But if the system allows no updates that will override anything else and this ceases to be a security-related configuration issue. Wrt your recent post I have no idea what's wrong because you've show earlier on it worked but have not shown what you did between that point and now. Maybe backup and then zap the faillog and make certain it has proper ownership and access rights.
 
Old 07-18-2008, 01:16 AM   #6
SecondMet
LQ Newbie
 
Registered: Jul 2008
Posts: 8

Original Poster
Rep: Reputation: 0
The problem with the faillog does not seem to be related to the pam-configuration.

What I observed is that the /var/log/faillog file has a size of 128 GB.

I then deleted the file using rm /var/log/faillog and rebooted the system.
I then created a new faillog using "touch /var/log/faillog".

Then I tried to configure the maximum number of failed logins using:

faillog -m 5

After that the file is immediately back to the size of 128 GB.

What could that be?
 
Old 07-18-2008, 06:57 AM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
Quote:
Originally Posted by SecondMet View Post
The problem with the faillog does not seem to be related to the pam-configuration. (..) After that the file is immediately back to the size of 128 GB.
Investigate if this applies to your situation?:
Quote:
Originally Posted by shadow-utils-4.0.3-63 --changelog
* Mon Aug 06 2007 Peter Vrabec <pvrabec@redhat.com> 2:4.0.3-63.RHEL4
- do not create huge /var/log/faillog
- Resolves: rhbz#213347
If it applies and still does not warrant a change of policy wrt upgrading, then what is your *real* problem with upgrading?
 
Old 07-21-2008, 01:16 AM   #8
SecondMet
LQ Newbie
 
Registered: Jul 2008
Posts: 8

Original Poster
Rep: Reputation: 0
The problem with upgrading is that the configuration is done for a customer who has explicitly agreed on one version which may not been changed.
 
Old 07-21-2008, 08:53 AM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
That still does not make things clear. I'm willing to help you come up with arguments but if you are really willing to counter that you have to know the exact reasons for not changing it.
 
Old 07-22-2008, 01:06 AM   #10
SecondMet
LQ Newbie
 
Registered: Jul 2008
Posts: 8

Original Poster
Rep: Reputation: 0
With our customers it is sometimes very bureaucratic. You see at the beginning of the project a list of software versions was agreed on by some administrative people and now this list is binding for everyone in the project. Nothing may be used, that is not on the list. An the OS-version is also fixed due to this list. Since many developers from all over Europe work on it, this assures all have the same basis. So if I would change something there somebody else might get problems with that version perhaps. Who knows..
Thus it is not an option to change any version.
 
Old 07-22-2008, 04:38 PM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
No, I wouldn't describe it as "bureaucratic". When you're doing a project it makes perfect sense to fixate dependencies. It also makes perfect sense to have your observation validated by the project leader (in other words make him / her responsable for determining if it is a problem and if a fix is necessary). IMHO it breaks down to two things: a working pam_tally being a base requirement and other project parts requiring a perfectly working pam_tally. If it needs to be fixed then you can report how it can be fixed. Other project parts requiring it just makes it a higher priority issue. So IMHO the only other two things standing in the way of a fix are any dependencies in pam_tally and upgrade regime. The first one can be dealth with by recompiling it and the second one could be "sold to the customer as an added value service". If OTOH it doesn't need to be fixed then the PL will have to have it documented. Either way, by using proper project handoff tactics, the problem should be off your plate...
 
Old 04-19-2010, 05:11 AM   #12
romero
LQ Newbie
 
Registered: Apr 2010
Posts: 1

Rep: Reputation: 0
Post

Quote:
Originally Posted by SecondMet View Post
The problem with the faillog does not seem to be related to the pam-configuration.

What I observed is that the /var/log/faillog file has a size of 128 GB.

I then deleted the file using rm /var/log/faillog and rebooted the system.
I then created a new faillog using "touch /var/log/faillog".

Then I tried to configure the maximum number of failed logins using:

faillog -m 5

After that the file is immediately back to the size of 128 GB.

What could that be?
Try this

Verify that it's the large sparse files which are causing the problem. A sparse file is one that has allocated (reserved) some amount of space, but has only used a small portion of it.

The typical culprit files in this situation are

/var/log/lastlog
and
/var/log/faillog

use "ls -lh" to find how much space these files have allocated, and "du -h" to see how much they have actually used.


root@host:/var/log # ls -lh lastlog faillog
-rw------- 1 root root 132M Jul 17 12:26 faillog
-rw-r--r-- 1 root tty 1.2G Jul 17 12:26 lastlog
.......................^^^^
.......................space allocated

root@host:/var/log # du -h lastlog faillog
12K lastlog
12K faillog
^^^
space used

In this example, the 2 files combined have over 1.2GB of space allocated, but are using only 24K !


2) Either remove or compress the sparse files.

/var/log/lastlog keeps track of the last successfull login of each user on the system, and
/var/log/faillog maintains a count of login failures and the limits for each account.

If the customer does not want to keep this information you can simply zero out the files. Issue the following commands to do so


root@host:/var/log # > /var/log/lastlog
root@host:/var/log # > /var/log/faillog

root@host:/var/log # ls -l lastlog faillog
-rw-r--r-- 1 root tty 0 Jul 17 12:30 lastlog
-rw------- 1 root root 0 Jun 17 12:30 faillog

If the customer wants to save the files, you will need to compress them instead.


root@host:/var/log # gzip lastlog
root@host:/var/log # gzip faillog

Note: This may take a long time depending on the "ls -l" size of these files.

3) Perform the vm&f upgrade.

4) If you gzip'd the files in step #2, you should now uncompress them on BOTH BEs.
If you zero'd the files in step #2, you can skip this step.

Unfortunately, since gzip does not know how to deal with sparse files, we will need to use some trickery to get around that.

First on the current running BE ...


root@host:/var/log # zcat lastlog.gz | cp --sparse=always /dev/stdin /var/log/lastlog
root@host:/var/log # zcat faillog.gz | cp --sparse=always /dev/stdin /var/log/faillog

Note: This may take a long time depending on the "ls -l" size of these files.


root@host:/var/log # ls -lh lastlog faillog
-rw------- 1 root root 132M Jul 17 12:36 faillog
-rw------- 1 root root 1.2G Jul 17 12:35 lastlog

root@host:/var/log # du -h lastlog faillog
12K lastlog
12K faillog

We see that the files are restored, and are still sparse.

Now use vmf_sh to switch to the new ABE and do the same.


root@host:/var/log # vmf_curr <<< show currently running boot environment
BE1
root@host:/var/log # vmf_sh BE2 <<< open a shell on the ABE

vmf_sh: WARNING: You will not be able to run any other VM&F
processes on the ACTIVE Boot Environment while this SHELL is active.
In order to perform other VM&F operations on the ACTIVE Boot Environment
you will have to exit this SHELL.
Also, all commands run from this shell are running under chroot on
the INACTIVE Boot Environment that was specified

BE2: cd /var/log

BE2: zcat lastlog.gz | cp --sparse=always /dev/stdin /var/log/lastlog
BE2: zcat faillog.gz | cp --sparse=always /dev/stdin /var/log/faillog

BE2: ls -lh lastlog faillog
-rw------- 1 root root 132M Jul 17 12:55 faillog
-rw-r--r-- 1 root tty 1.2G Jul 17 12:54 lastlog

BE2: du -h lastlog faillog
12K lastlog
12K faillog

BE2: exit
exit
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
script to keep 'count' of failed login attempts hattori.hanzo Linux - Newbie 7 04-02-2008 10:23 PM
How to set delay between failed login attempts? handydan MEPIS 2 02-24-2007 11:08 PM
Constant failed login attempts... seanferd Linux - Security 8 11-09-2006 08:42 AM
Timeout between failed login attempts wuicci Linux - Security 3 06-01-2006 04:40 AM
Failed SSH login attempts Capt_Caveman Linux - Security 38 01-03-2006 03:22 PM


All times are GMT -5. The time now is 02:37 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration