Friday, November 17, 2006

IndySec 2 Recap - Landon Style

We had 13 (make that 14, according to Allen) people at IndySec 2 last night. Landon gave a great presentation on HoneyNets. A super sharp guy. I am glad he could be our first speaker at IndySec.

Scott Orr, the IUPUI linux admin legend, was also in attendance . In fact, he said he has space on his 149 Beowulf server cluster for our IndySec mailing list. I blushed. Seriously though, he was one of my best professors, ever.

In the very near future, you - the IndySec reader (all 13 of us), may elect to subscribe to our yet-to-be created listserv.

I would also like to send a big thank you to Sean Krulewitch for his help in getting the room reserved. The new IT building on the IUPUI campus is quite nice, thank you for sharing and providing a home for IndySec 2.

We had guests from the Indianapolis Motor Speedway, Midwest ISO, Sallie Mae, Crowe Chizek, IUPUI and more.

Great people, great learning, and a great grass-roots event. Thank you.

Look for information on IndySec 3 in the near future.

PAM: Overview. No, no not that PAM!

I wrote this sometime ago and never put it anywhere... excuse the formatting if it's off some, I had to paste it out of a PDF and blogger didnt like half of it.

Background:
If you have logged into a Linux box in the past five years or so you have implicitly used PAM (Pluggable Authentication Modules). PAM was originally created by Sun and licensed to a few other Unices (HP­UX and AIX). Later, like many applications, PAM was brought to other Linux and BSD distributions where it gained most of its popularity. Linux­PAM star ted its own project that is distributed with most Linux flavors used today. DARPA funded another project OpenPAM, which joined XSSO (X/Single Sign­On Service) and Linux­PAM (GNU version) along with the original Sun implementation. OpenPAM remains the default in most BSD distributions.

In a nut shell:
When applications are compiled with the PAM library support, authentication schemes on the back­end can seamlessly change. More specifically, you can configure multiple sources to transparently authenticate accounts for one or more applications (stack), and conveniently map them to authentication domains. Outside of just authentication you can also manage password policies (complexity, number of characters, etc), manage device usage (quotas, cpu, memory, etc), and ease administration with initial account management (creation, removal,
setting environment variables). A variety of modules are available that inter face with PAM and offer the flexibility to enforce granular controls on accounts and applications. Below I will show some examples of PAM and its configuration files.

Technical Details:
There are two different methods for configuring PAM, both are pretty straight forward. Older Unix/Linux systems use the method of putting all configuration information in /etc/pam.conf file (shown in Figure 1a). Newer Unix/Linux systems use the /etc/pam.d/ directory which contain the module-name as a file and the configuration for each module contained within those files (shown in Figure 1b and Figure 1c). If no configurations exist for a specific PAM module it uses the /etc/pam.d/other file. The syntax across both older and newer systems
remains the same (listed below Figure 1a) with the only difference being the service_name.

Figure 1a.
--------
# /etc/pam.conf
#
# service_name module_type control_flag module_path options
ssh auth required pam_env.so
ssh account required pam_unix.so
ssh password required pam_unix.so nullok obscure min=4 max=8 md5
ssh session required pam_unix.so
ssh session optional pam_motd.so
ssh session optional pam_mail.so standard noenv
ssh session required pam_limits.so
other auth required pam_unix.so
other account required pam_unix.so
other password required pam_unix.so
other session required pam_unix.so
--------

Figure 1b.
--------
# /etc/pam.d/other
#
# module_type control_flag module_path options
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
--------

Figure 1c.
--------
# /etc/pam.d/ssh
#
# module_type control_flag module_path options
auth required pam_env.so
account required pam_unix.so
password required pam_unix.so nullok obscure min=4 max=8 md5
session required pam_unix.so
session optional pam_motd.so
session optional pam_mail.so standard noenvsession required pam_limits.so
--------

Wrapping Up:
This article only briefly describes PAM and ways to configure it. With this brief overview you should be able to quickly run through the default configuration files distributed with your favorite flavor of Linux and understand it. Many how­to's and examples of configurations with third­party authentication schemes exist, but go outside this brief overview. Check the pam-usb module for the cheapest/home-made two-factor authentication solution.

Thursday, November 09, 2006

IndySec 2 Meeting Location

We have a home for IndySec 2!
A special thanks goes to Sean Krulewitch, Deputy IT Security Officer, IU for the help.

What: IndySec 2, with 100% of your daily requirement of Landon Lewis and Honeynets!

When
: Thursday, November 16th @ 6:30 PM

Where: IT building at Michigan and West street (535 W. Michigan St.) IUPUI campus.

Room Number: IT303, however everyone will need to meet in the lobby so we can get the up to the room. Room phone number will be provided at the security desk for those who are late. Someone will come down and get you (probably me).

Food: Bring your own, but I / we might want to order some pizza with some others.

Parking options:
There are a few parking meters in the parking lot SW of the building (on the yellow strip on the east side of the lot).

Visitors can also park at the North St Parking Garage

There is free parking at 1200 Stadium Dr with a free shuttle to the
IUPUI campus Park in nearby downtown and walk over, or take the free Red-line bus.

Share with your friends and let us know if you have any questions.

This will be a great meeting.