Note: this document is written in reference to Red Hat Linux 6.2+

PAM (Pluggable authentication module) is very diverse in the types of modules it provides. One could accomplish many authentication tasks using PAM. However PAM expands itself beyond typical authentication programs, as it allows an admin to employ other system-critical features such as resource limiting, su protection, and TTY restrictions. Much of PAM's features are not within the scope of this document, but for further reading you can refer to the links at the bottom of this document.

Firstly we must enable the pam_limits module, inside /etc/pam.d/login. Add the following to the end of the file:

session required /lib/security/pam_limits.so

After adding the line above, the /etc/pam.d/login file should look something like this:

#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session optional /lib/security/pam_console.so
session required /lib/security/pam_limits.so

The limits.conf file located under the /etc/security directory can be used to control and set resource policies. limits.conf is well commented and easy to use - so do take the time to skim over its contents. It is important to set resource limits on all your users so they can't perform denial of service attacks with such things as fork bombs, amongst other things it can also stop 'stray' server processes from taking the system down with it.

It is also a good idea to separate rules for users, admins, and other (other being everything else). This is important, cause take for instance a scenario where a user fork bombs the system - it could in effect disable an administrator's ability to login to the system and take proper actions, or worse crash the server.

Below is the default policy used on a server iv configured:

# For everyone (users and other)
* hard core 0
* - maxlogins 12
* hard nproc 50
* hard rss 20000

# For group wheel (admins)
@wheel - maxlogins 5
@wheel hard nproc 80
@wheel hard rss 75000

#End of file

The first set of rules say to prohibit the creation of core files - core 0 , restrict the number of processes to 50 - nproc 50, restrict logins to 12 - maxlogins 12, and restrict memory usage to 20MB - rss 20000 for everyone except the super user. The the later rules for admins, say to restrict logins to 5 - maxlogins 5, restrict the number of processes to 80 - nproc 80, and restrict the memory usage to 75MB - rss 75000.

All the above only concerns users who have entered via the login prompt on your system. The asterisk (*) defines all users and at wheel (@wheel) defines only users in group wheel. Make sure to add your administrative users into the wheel group (this can be done in /etc/group).

Finally edit the /etc/profile file and change the following line:

ulimit -c 1000000

to read:

ulimit -S -c 1000000 > /dev/null 2<&1

This modification is used to avoid getting error messages like 'Unable to reach limit' during login. On newer editions of Red Hat Linux, the later ulimit setting is default.

Further reading is available in The Linux-PAM System Administrators' Guide located at:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html

noone like my tuts :eek: ?

Your guide is so complete that nobody is able to add anything to it... :)

I have no fear of playing around with these settings, except for one thing, which is this: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-5.html#ss5.1

<small snippet> The most dramatic problem that is likely to be encountered when configuring Linux-PAM is that of deleting the configuration file(s): /etc/pam.d/* and/or /etc/pam.conf. This will lock you out of your own system!

Yikes! That’s one nasty punishment just for testing a couple of features. Maybe it’s just me, but I don’t find them clear on how exactly this can happen. I mean, no ones going to intentionally nuke their /etc/pam files, so what are they talking about here? Is this a random sort of unfortunate happenstance? Any further insight/ interpretation of this statement would be appreciated.

Thanks all!

Chances are, your server already has pam setup per default configuration. However yes, as the 'The Linux-PAM System Administrators' guide states, if you lose your pam.conf or pam.d/ configurations - you will probly be locked out of your system. Although this would be true if referenced to your shadow-utils (e.g: lose /etc/shadow) or any other system level utility (for the most part)

PAM is just another means to control and manage your systems resources/security - a very powerfull means at that. Its use should be cautioned just as the use of any other system level utility (e.g: usermod).

Thanks rfxn.

Correct you are. Pam is installed and operating. It’s not as easy as it looks though. For example, it claims that settings in the limit.conf file will effectively regulate individual groups, or global system resources. Hmm… I’m not sure if that would include httpd or not, but I don’t think it does.

My first test was enabling a group/user in the limit.conf file. The objective in this case was to limit processes spawned from the shell. Unfortunately, it didn’t seem to kill massively intense process I ran—the process just kept going forever.

Next, I started fooling around with the ulimit settings. Apparently, (I think), if you set a ulimit setting as root, then it’s applicable to all users/groups. Not so in this case. Using a setting of ulimit –t 30 would kill scripts in 30 seconds as root, but not if a group user was running a process. Also, I tried ulimit –h –s and whatever, which is supposed use the settings from PAM, but that didn’t work.

The next suggestion was to place the setting into the bash_conf (or whatever it’s called) file, which should load automatically upon all bash sessions, but that didn’t work either. Finally, (6-hours later), I dug up another suggestion from the Unix news groups, which suggested placing the ulimit settings into the /etc/profile, which worked!! All groups and SSH sessions are using my ulimit settings.

I’m still somewhat confused with this PAM thing though. Where and when is it supposed to work, and to what extent? One thing I find annoying, is that it states its CPU time in minutes, and not seconds. Is there a way to add seconds to it? For example, if you state 30- seconds in PAM, it views it as 30 minutes. Man, that’s strange. Who allows “minutes” of CPU time on a (per users basis) in a shared hosting environment? I tried .05 and all sorts of stuff like that, but it only responds to minutes.

Anyway, I’m still in the testing stages, and don’t know if whatever I’ve done here will limit processes being ran as “Nobody.’ Everything else, including anything running as root certainly is, which is great!

On another note:

This shared IP/name based hosting thing really has me wondering. My next task was to gain control over processes being spawned from httpd. ARRGHHH!….. After 8-hours of screwing around, I finally stumbled into the fact the Apache Rlimit features “are ignored” when inserting them into the container, IF the virtual host is under a shared IP. So, I created a dedicated IP account, and poof… Rlimit works as good as gold, (on a per user basis). Note: Rlimit will work as a “Global Setting” in a shared IP environment, but for all the good it does however.

Does anyone know why it’s doing this? If I can’t find a way to make this work, then I’ll have to forgo name based hosting. The trade off otherwise, would be not being able to implement resource management. After TONS of dooms day scenarios, I don’t fancy the idea of leaving the host in (unmanaged mode).

In any event, I like this PAM stuff. Literature on it can be somewhat complicated, but it has everything I’m looking for right here. All I need to do is figure out how to use it properly.

Enough babbling for now,

Thanks!

PS If I sound sort of junior, it’s because it’s my first dedicated host, so I’m still in the learning phases :D

PAM resource limits essentialy apply to users. The resource limits are passed to a users enviroment after login with /bin/login . If you do not login via /bin/login then the resource limits do not apply (oddly). However with some nifty kernel patches (grsecurity.net) you can make resource limits with PAM more global - in a sence. As such the limits would apply to services such as apache , mysql , named etc...

For the most part i use PAM resource limits to help keep my userspace incheck (e.g: limit logins, limit mem usage per/user etc..). Although PAM does have a mind of its own from what iv seen and is setup different across most OS's (e.g: freebsd, redhat, slackware) - so it may take some experimenting to get comfortable with PAM Resource Limiting.

That is so cool! Awesome! Thank you! I've run into various references to PAM-authetication, but never found an explanation for the benefits of PAM. I'll definitely be checking out more about this and grsecurity.net .

On another topic that has yeilded consistantly incomplete solutions, what is your approach toward auditing bandwidth usage?

Jake

Well i use the following to help me manage & audit bandwidth.

Bandmin (ideal for IP bandwidth monitoring):
ftp://missinglink.darkorb.net/pub/bandmin/

MRTG (with a patch for local interface monitoring):
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

NTOP (this is great to get a nice protocol breakdown of traffic, stats on were traffic is coming from/goin to, and much much more..)
http://www.ntop.org

As well, such tools as mod_throttle and mod_bandwidth could be used to regulate & monitor bandwidth for name based virtual hosting. Reference to mod_throttle/mod_bandwidth can be found at:
http://www.apache.org

Originally posted by rfxn
PAM resource limits essentialy apply to users. The resource limits are passed to a users enviroment after login with /bin/login . If you do not login via /bin/login then the resource limits do not apply (oddly). However with some nifty kernel patches (grsecurity.net) you can make resource limits with PAM more global - in a sence. As such the limits would apply to services such as apache , mysql , named etc...



Hmm… I’m not quite sure at the point I feel brave enough to alter the kernal, at least yet. But, essentially, what you’re saying is that PAM (as I have it setup now) is pretty much limited to protection of killer processes launched from the shell, correct?

I just tried running a killer cron job—the kind that would generally kill a server, and yep, ulimit, or PAM didn’t jump into save the day. Are there other ways to enforce limits for cron jobs, or Nobody based processes? I just hate leaving it open like that, as it incresses the possibility of a server crash, be it intentionally or accidentally. If there’s anything else I can try, please let me know.

Thanks again.

Ya PAM resource limiting is pretty much limited to processes spawned from shells (launched from /bin/login).

e.g: if you set a script in cron to run - it wont apply to the resource limits set.

But im working on a perl program now that will provide the same type of protection as PAM Resource Limiting but will apply to All running processes (and possibly have an option for a special GID to be excluded - i.e: wheel [10]).

My perl script will essentialy either be run from cron every 1 or 2 minutes - or i may make a small function to keep the script in a while loop (and sleep for xx seconds inbetween runs). Im hoping to finish my script by the end of the week but i also gota make a parser for the conf file (witch i want to keep similar to limits.conf).

As for other means of protection, check out the applications archive on linux.org and see if you can find some utils that are more 'proactive' in detouring resource abuse.

Sounds good. I don’t have anyone on the server yet, so if you want help with a small beta test, by all means, let me know :cool:

Thanks.

just thought id post that, if you use grsecurity.net's kernel patches you can enable a feature so PAM resource limits are checked against exec calls. This is a great bonus and helps kill 90% of fork bombs dead in the watter.

This is very useful info thanks. Ive recently been studying PAM and its nice to see some resources for me to play with :)

Thanks ryan