Troubleshooting of Linux Issues Part - 2

You can also just use the plain old more command to see one screen at a time of the entire log file without filtering with grep. Here is an example:

# more /var/log/messages

Similar commands can be applied to all log files. This is probably one of the best troubleshooting tools available in Linux. Another good command to use apart from tail is grep. grep will help you search for all occurrences of a string in a log file; you can pipe it through the more command so that you only get one screen at a time. Here is an example:

#grep eth /var/log/messages | more

#grep vga /var/log/messages | more

Certain applications will additionally log to their own application specific log files and directories independent of the syslog.conf file. Here are some common examples:

Files:

/var/log/maillog             : Mail

/var/log/httpd/access_log    : Apache web server page access logs

Directories:

/var/log

/var/log/samba                      : Samba messages

/var/log/mrtg                       : MRTG messages

/var/log/httpd                      : Apache webserver messages

Note: In some older versions of Linux the /etc/rsyslog.conf file was very sensitive to spaces and would recognize only tabs. The use of spaces in the file would cause unpredictable results. Check the formatting of your /etc/rsyslog.conf file to be safe.

Activating Changes to the syslog Configuration File

Changes to /etc/rsyslog.conf will not take effect until you restart syslog.

Managing the syslog daemon is easy to do, but the procedure differs between Linux distributions. Here are some things to keep in mind.

Firstly, different Linux distributions use different daemon management systems. Each system has its own set of commands to do similar operations. The most commonly used daemon management systems are SysV and Systemd.

Secondly, the daemon name needs to be known. In this case the name of the daemon is rsyslog.

Armed with this information you can know how to:

Start your daemons automatically on booting

Stop, start and restart them later on during troubleshooting or when a configuration file change needs to be applied.

For more details on this, please take a look at the "Managing Daemons" section of Chapter 6 "Installing Linux Software"

How to View New Log Entries as They Happen

If you want to get new log entries to scroll on the screen as they occur, then you can use this command:

[root@bigboy tmp]# tail -f /var/log/messages

Logging syslog Messages to a Remote Linux Server

Logging your system messages to a remote server is a good security practice. With all servers logging to a central syslog server, it becomes easier to correlate events across your company. It also makes covering up mistakes or malicious activities harder because the purposeful deletion of log files on a server cannot simultaneously occur on your logging server, especially if you restrict the user access to the logging server.

Configuring the Linux Syslog Server

By default syslog doesn't expect to receive messages from remote clients. Here's how to configure your Linux server to start listening for these messages.

As we saw previously, syslog checks its /etc/rsyslog.conf file to determine the expected names and locations of the log files it should create. It also checks the file /etc/sysconfig/syslog to determine the various modes in which it should operate. Syslog will not listen for remote messages unless the SYSLOGD_OPTIONS variable in this file has a -r included in it as shown below.

# Options to syslogd

# -m 0 disables 'MARK' messages.

# -r enables logging from remote machines

# -x disables DNS lookups on messages received with -r

# See syslogd(8) for more details

 SYSLOGD_OPTIONS="-m 0 -r"

# Options to klogd

# -2 prints all kernel oops messages twice; once for klogd to decode, and

#    once for processing with 'ksymoops'

# -x disables all klogd processing of oops messages entirely

# See klogd(8) for more details

KLOGD_OPTIONS="-2"

Note: In Debian / Ubuntu systems you have to edit the syslog startup script /etc/init.d/sysklogd directly and make the SYSLOGD variable definition become "-r".

# Options for start/restart the daemons

#   For remote UDP logging use SYSLOGD="-r"

#

#SYSLOGD="-u syslog"

SYSLOGD="-r"

You will have to restart syslog on the server for the changes to take effect. The server will now start to listen on UDP port 514, which you can verify using either one of the following netstat command variations.

[root@bigboy tmp]# netstat -a | grep syslog

udp        0      0 *:syslog                *:*

[root@bigboy tmp]# netstat -an | grep 514

udp        0      0 0.0.0.0:514             0.0.0.0:*

[root@bigboy tmp]#

Configuring the Linux Client

The syslog server is now expecting to receive syslog messages. You have to configure your remote Linux client to send messages to it. This is done by editing the /etc/hosts file on the Linux client named smallfry. Here are the steps:

1) Determine the IP address and fully qualified hostname of your remote logging host.

2) Add an entry in the /etc/hosts file in the format:

IP-address    fully-qualified-domain-name    hostname    "loghost"

E

xample:

192.168.1.100    bigboy.my-site.com    bigboy     loghost

Now your /etc/hosts file has a nickname of "loghost" for server bigboy.

3) The next thing you need to do is edit your /etc/rsyslog.conf file to make the syslog messages get sent to your new loghost nickname.

*.debug                                       @loghost

*.debug                                       /var/log/messages

You have now configured all debug messages and higher to be logged to both server bigboy ("loghost") and the local file /var/log/messages. Remember to restart syslog to get the remote logging started.

You can now test to make sure that the syslog server is receiving the messages with a simple test such as restarting the lpd printer daemon and making sure the remote server sees the messages.

Linux Client

[root@smallfry tmp]# systemctl restart lpd.service

Linux Server

[root@bigboy tmp]# tail /var/log/messages

...

...

Apr 11 22:09:35 smallfry lpd: lpd shutdown succeeded

Apr 11 22:09:39 smallfry lpd: lpd startup succeeded

...

...

[root@bigboy tmp]#

Syslog Configuration and Cisco Network Devices

syslog reserves facilities "local0" through "local7" for log messages received from remote servers and network devices. Routers, switches, firewalls and load balancers each logging with a different facility can each have their own log files for easy troubleshooting. Appendix 4 has examples of how to configure syslog to do this with Cisco devices using separate log files for the routers, switches, PIX firewalls, CSS load balancers and LocalDirectors.

Activating logrotate

The above logrotate settings in the previous section will not take effect until you issue the following command:

[root@bigboy tmp]# logrotate -f

If you want logrotate to reload only a specific configuration file, and not all of them, then issue the logrotate command with just that filename as the argument like this:

[root@bigboy tmp]# logrotate -f /etc/logrotate.d/syslog

Installing and Starting syslog-ng

You can install syslog-ng using standard Linux procedures.The syslog-ng and rsyslog packages cannot be installed at the same time. You have to uninstall one in order for the other to work. Here’s how you can install syslog-ng using RPM package files.

1.         Uninstall rsyslog using the rpm command. There are some other RPMs that rely on rsyslog so you will have to do this while ignoring any dependencies with the –nodeps flag.

[root@bigboy tmp]# rpm -e --nodeps rsyslog

2.         Install syslog-ng using yum.

[root@bigboy tmp]# yum -y install syslog-ng

3.         Start the new syslog-ng daemon immediately and make sure it will start on the next reboot.

Systems using sysvinit:

[root@bigboy tmp]# chkconfig syslog-ng on

[root@bigboy tmp]# service syslog-ng start

Starting syslog-ng: [  OK  ]

[root@bigboy tmp]#

Systems using systemd:

[root@bigboy tmp]# systemctl enable syslog-ng.service

[root@bigboy tmp]# systemctl start syslog-ng.service

Starting syslog-ng: [  OK  ]

[root@bigboy tmp]#

Your new syslog-ng package is now up and running and ready to go!

[root@bigboy tmp]# ifconfig -a

[root@bigboy tmp]# cat /proc/interrupts

Changing Your IP Address

[root@bigboy tmp]# ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up

[root@bigboy network-scripts]# ifdown eth0

[root@bigboy network-scripts]# ifup eth0

Multiple IP Addresses on a Single NIC

[root@bigboy tmp]# ifconfig wlan0:0 192.168.1.99 netmask 255.255.255.0 up

he commands to activate and deactivate the alias interface would therefore be:

[root@bigboy tmp]# ifup wlan0:0

[root@bigboy tmp]# ifdown wlan0:0

How to Activate/Shut Down Your NIC

[root@bigboy tmp]# ifdown eth0

[root@bigboy tmp]# ifup eth0

How to View Your Current Routing Table

[root@bigboy tmp]# netstat -nr

[root@bigboy tmp]# netstat -nr

How to Change Your Default Gateway   ----Temporary Default Gateway Assignment

[root@bigboy tmp]# route add default gw 192.168.1.1 wlan0

Permanent Default Gateway Assignment

Remember, the previous command is temporary and its effects will be lost after the next reboot. There are many ways to do this.

Note: In Debian based systems the default gateway is permanently defined in the /etc/network/interfaces file. See the section "Debian / Ubuntu Network Configuration" later in this chapter for more details.

The /etc/sysconfig/network file

Once done, you'll need to update your /etc/sysconfig/network file to reflect the change. This file is used to configure your default gateway each time Linux boots.

# /etc/sysconfig/network

NETWORKING=yes

HOSTNAME=bigboy

GATEWAY=192.168.1.1

The /etc/sysconfig/network-scripts/ifcfg-<interface> file

Adding Temporary Static Routes

[root@bigboy tmp]# route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.254 wlan0

[root@bigboy tmp]# route add -host 10.0.0.1 gw 192.168.1.254 wlan0

Adding Permanent Static Routes

In Fedora Linux, permanent static routes are added on a per interface basis in files located in the /etc/sysconfig/network-scripts directory. The filename format is route-interface-name so the filename for interface wlan0 would be route-wlan0.

The format of the file is quite intuitive with the target network coming in the first column followed by the word via and then the gateway's IP address. In our routing example, to set up a route to network 10.0.0.0 with a subnet mask of 255.0.0.0 (a mask with the first 8 bits set to 1) via the 192.168.1.254 gateway, we would have to configure file /etc/sysconfig/network-scripts/route-wlan0 to look like this:

# File /etc/sysconfig/network-scripts/route-wlan0

#

10.0.0.0/8 via 192.168.1.254

How to Delete a Route

Here's how to delete the routes added in the previous section.

root@bigboy tmp]# route del -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.254 wlan0

The file /etc/sysconfig/network-scripts/route-wlan0 will also have to be updated so that when you reboot the server will not reinsert the route. Delete the line that reads:

10.0.0.0/8 via 192.168.1.254

IP TABLES ( FIREWALL ) - 3

What is IP Tables iptables Tutorial

iptables is a tool used in linux distributions to control kernel's netfilter's firewall. Here is a tutorial on iptables.

iptables firewall contains 3 tables, every table contains chains. Those chains are default. User is able to define new chains and link from default chains to those user defined chains.


1. iptables tables
--------------------iptables contains 3 tables:
a. filter table
b. nat table
c. mangling table


a. filter tableThis table is used to filter packets that pass the firewall. Its purpose is only packet filtering, and will filter packets that comes to the machine (incoming), packets that goes out (outgoing) and packets that are forwarded between network cards (filtering), in case that machine has two or more network cards.

That table contains 3 chains: INPUT chain, OUTPUT chain and FORWARD chain.

INPUT chain - used to filter incoming packets
OUTPUT chain - used to filter outgoing packets
FORWARD chain - used to filter forwarded packets (between network cards). 

b. nat tableThis table is used to change source of the IP. 
PREROUTING chain - used to change IP before forwarding take place
POSTROUTING chain - used to change IP after forwarding take place
OUTPUT chain - used to filter on outgoing

c. mangle
This tables is used to modify packets.


2. Syntax of a iptables rule:
------------------------------------
iptables name_of_table name_of_chain layer3_object layer4_object jump_target

Notes:
- by default if name of table is not specify (with "-t nat" for example, for nat table, or "-t mangle" for mangle table), default table is used: filter table;
- layer4_object is not mandatory; 

iptables Examples:
iptables -A INPUT -s 192.168.0.1 -j DROP       # will drop all packets that comes from IP 192.168.0.1


3. Chain management
-----------------------------
List tables and chains:
iptables -L                                   # will list all rules from all chains from filter table
iptables -L -v #                            # will list all rules from all chains from filtering table, in verbose mode, 
                                                    # showing also packets and bytes that matched that rules
iptables -L -v --line-numbers       # will show above and also rule numbers

iptables -L INPUT                        # will show all rules from INPUT chain from filter table

iptables -L -t nat                          # will show all rules from all chains from nat table
iptables -t nat -L PREROUTING   # will show all rules from PREROUTING chain from nat table

iptables -L -t mangle                   # will show all rules from all chains from mangle table


Adding rules to chains:To add a rule to a chain use:
iptables -A INPUT -s 192.168.0.1 -j ACCEPT     # will allow traffic from source IP 192.168.0.1
iptables -A INPUT -p tcp --dport 22 -j DROP      # will drop all traffic to destination port 22 (our ssh port)

iptables -A will append rule at the end of rules list  in your specified chain. if you want to insert a rule on a specific position in your chain, then you must use -I.

iptables -I INPUT 1 -s 192.168.0.1 -j ACCEPT    # will add rule in position 1 in your INPUT chain
iptables -I INPUT 10 -p tcp --dport 22 -j DROP   # will add a rule in position 10 of your INPUT chain.

Rules are evaluated from first to last rule. On ACCEPT or DROP rules, if a rule is matched, it will not be evaluated to next rules.

Note 1:  if you want to block traffic that comes to your machine you must add rule on INPUT chain. If you want to block traffic to a destination IP from your machine you must add rule in OUTPUT chain. Also you must have networking knowledge and you must understand how firewall works.

Note 2: Each chain have a default policy. Policy can be ACCEPT or DROP, by default all CHAIN have ACCEPT policy.

Note 3: When adding a rule -j parameter (jump) can have the following values: ACCEPT, DROP, REJECT, DENY, LOG.

Delete all rules from all chains:iptables -F                                 # will delete all rules from filter table
iptables -F -t nat                       # will delete all rules from nat table
iptables -F -t mangle                 # will delete all rules from mangle table


Deleting a rule from a chain:To delete a rule from a chain you have two posibilities: to delete a rule using rule number or to delete using syntax used when rule was added:

iptables -D INPUT 10                          # will delete rule 10 from INPUT chain
iptables -D PREROUTING 10 -t nat     # will delete rule 10 from PREROUTING chain from nat table

iptables -D INPUT -s 192.168.0.1 -j ACCEPT      # will delete rule that was added with iptables -A INPUT -s 192.168.0.1 -j ACCEPT

Note: On our previous example, the first rule that match that syntax will be deleted. If are many similar rules, only first will be deleted. To delete all rules that match that syntax, you must use previous command multiple times until you delete all rules.

To delete all rules you can also use (on some old versions of linux, it will not work with -F but with --flush, because of some bugs):
iptables --flush

Saving / Restoring iptables rules:iptables-save >rules.txt
iptables-restore 

(If iptables is not in your path, you can use absolute paths: /sbin/iptables-save, and /sbin/iptables-restore).
Running iptables-save will output rules on standard output (usualy this is screen, so because of that you must use redirections).

4. Chain policy
As I said previously, each chain have a default policy that can be ACCEPT or DROP and by default all CHAIN have ACCEPT policy.
To change chain policy use:

iptables -P INPUT DROP

Note 1: If you are logged to your machine remotely via SSH (and you are not at console) be careful when you change default policy to drop, to not lock you out. Usualy when sysadmins tests firewall remotely it is a good practice to add to your CRON service a rule that will open the firewall, and you enable that script to run every half an hour or 15 minutes, so if you will lock out of your box, after 15 minutes the firewall will be opened.

Note 2: When you design firewall rules to allo access to your machine and block everything else, take in consideration that traffic goes both ways. If you allow traffic on INPUT chaing but your OUTPUT chain block everything, your rule will not work. Usualy is a good practice when you protect your machine to allow everything on OUTPUT ( you want to be able from your machine to do anything), and block everything on INPUT (incoming) for connections that are not initiated from your machine. If your machine run public services, like for example a web server, or a mail server then you must allow connections from outside on INPUT only on ports used by those services (for example allow incoming on port 80 - http, port 25 - smtp, port 110 - pop3 and 143 -imap, mail services.) So as a conclusion when you design your firewall, setup your default policy on INPUT to drop all packets and on OUTPUT leave it default, to allow everything. And then design your firewall.

Note 3: If your machine is not only connected to Internet, but is also a router for your LAN clients, then you must also filter connections from LAN. It is recommended to change policy on FORWARD chain to DROP and then allow only IPs you want from LAN to be able to access Internet.

How to Change MySql Data Directory In Linux

Let’s say your second HDD is mounted as /home2

1. The first step is to stop MySQL so that all your data gets copied correctly.
$ /etc/rc.d/init.d/mysql stop
- or -
$ service mysql* stop

2. Create the new database directory in the second HDD and for this let’s say it’s named as mysqldata
$ mkdir /home2/mysqldata

3. Copy the database files from the first HDD to the second HDD
$ cp -R /var/lib/mysql/ /home2/mysqldata

4. Set the correct owner and group, permissions of the new database directory on the 2nd HDD
$ chown -R mysql.mysql /home2/mysqldata/

5. Rename your old database directory
$ mv /var/lib/mysql/ /var/lib/mysql_old

6. Create a symbolic link from the old database directory to the new one for any programs that rely on the default location
$ ln -s /home2/mysqldata/ /var/lib/mysql

7. Set the correct owner and group on the symbolic link
$ chown mysql.mysql /var/lib/mysql

8. Edit the configuration file (/etc/my.cnf) to update the changes
Comment out the old settings and add a line for the new one as you can see below
[mysqld]
#datadir=/var/lib/mysql
datadir=/home2/mysqldata
#socket=/var/lib/mysql/mysql.sock
socket=/home2/mysqldata/mysql.sock
#basedir=/var/lib
basedir=/home2
save my.cnf and exit your text editor
Note that for MySQL version 5 you have to remove the line basedir. The basedir line is only for those who are using MySQL version 4.

9. Restart MySQL
$ /etc/rc.d/init.d/mysql start
- or -
$ service mysql* start

10. If MySQL refuses to start look in /var/log/mysqld.log for the reason

What is Mysql Data Directory?

Mysql data directory is important part where all the mysql databases storage location.By default MySQL data default directory located in /var/lib/mysql.If you are running out of space in /var partition you need to move this to some other location.

Note:- This is only for advanced users and before moving default directory make a backup of your mysal databases.

Procedure to follow
Open the terminal
First you need to Stop MySQL using the following command

/etc/init.d/mysql stop

Now Copy the existing data directory (default located in /var/lib/mysql) using the following command

cp -R -p /var/lib/mysql /path/to/new/datadir

All you need are the data files, so delete the others with the command

rm /path/to/new/datadir

Note:- You will get a message about not being able to delete some directories, but that’s what you want.
Now edit the MySQL configuration file with the following command

Vim /etc/mysql/my.cnf

Look for the entry for “datadir”, and change the path (which should be “/var/lib/mysql”) to the new data directory.

you’ll never be able to restart MySQL with the new datadir location.
In the terminal, enter the command

vim /etc/apparmor.d/usr.sbin.mysqld

Copy the lines beginning with “/var/lib/mysql”, comment out the originals with hash marks (“#”), and paste the lines below the originals.
Now change “/var/lib/mysql” in the two new lines with “/path/to/new/datadir”. Save and close the file.
Restart the AppArmor profiles with the command

 /etc/init.d/apparmor reload

Restart MySQL with the command

 /etc/init.d/mysql restart

Now MySQL should start with no errors, and your data will be stored in the new data directory location.

Setup SSH Key Authentication

Setup ssh key authentication for password-less login between servers.  For use by ssh/sftp users or scripts.

Source Server (or local system)

Generate RSA key for user on this system, you can also use DSA.  This asks for key pass-phrase but you can leave it blank.

ssh-keygen -t rsa

This asks for location to place the generated key, by default it will be your home directory (ex: /home/your_username/.ssh/).  This generates two files:  id_rsaand id_rsa.pub.  Content of id_rsa.pub is what we need to copy to destination server.

Destination Server (or remote server)

Check if you have the directory .ssh on your home (ex: /home/username/.ssh/), if not, create that directory.

ls  ~/.ssh
mkdir  ~/.ssh
Check if you have existing file authorized_keys on your .ssh directory, if not create it.

ls  ~/.ssh/ authorized_keys
touch   ~/.ssh/ authorized_keys

Copy content of id_rsa.pub that you created from your source/local server, or execute this command from your source/local server:

scp  ~/.ssh/id_rsa.pub username@remote_host:~/.ssh/authorized_keys

Test your password-less login from source to destination server.

Restricted Web Access with HTaccess

1. What is Restricted Access and HTaccess?
1. Username/password level access authorization. This method requires a user to enter a valid username and password to access a certain web page.

2. Rejection or acceptance of connections based on Internet address, hostname or domain name of the Web client.

3. A combination of both above.

Access is having restrictions on who is able to access a certain directory in a site. One of the ways of doing it is using HTaccess. HTaccess uses two ways to restrict access:

* Note: Neither of these ways is foolproof.

2. Single User Access
1. Create a file called .htaccess (the dot is required), in the directory Personal, with the following format:

AuthUserFile fullpathname/.htpasswd AuthGroupFile /dev/null AuthName "AnyNameYouWant" AuthType Basic <Limit GET POST> require user mysecret </Limit>

AuthUserFile-- Replace fullpathname with the full path name of the directory in which the password file (which will be created after this) resides. To find out the full path name of a certain directory, type pwd at the prompt.
AuthGroup File--For a single user access, a .htgroup file does not exist. So, we specify /dev/null which is the standard UNIX way to say this file does not exist.
AuthName-- This can be anything. It will be displayed on the browser when the password is prompted. If nothing is entered, it will default as ByPassword. The name(s) must be between double quotes.
AuthType-- This should be set to Basic, since we are using Basic HTTP Authentication. This means that the password is passed over the network not encrypted but not as plain text either.
In the LIMIT directive, only the method GET is restricted in this example. Other methods (especially in CGI directories) can also be limited by specified by putting a space between each of them. For example:
<Limit GET POST PUT> require user mysecret </Limit>
2. After creating the .htaccess file, create a .htpasswd file by typing this command below in the restricted directory or in this case in the Personal directory.

htpasswd -c .htpasswd mysecret

3. After typing this command there should be instructions that require you to type in the password for the user twice. In this example, we will type in dontell twice. If you open up the file, it should look something like this:

mysecret:vlCg6/UxAqH9M

4. Now change the permissions of the files that you just created so that the world can read it (necessary to have it working) by typing the following commands:

chmod 744 .htaccess
chmod 744 .htpasswd

Suppose you want to restrict access in a directory named Personal to a single user with a username mysecret and password dontell. Below are the instructions on how to do it.

Example .htaccess
AuthUserFile /web/decs/web/single/.htpasswd
AuthGroupFile /dev/null
AuthName Single_User
AuthType Basic

<Limit GET>
require user mysecret
</Limit>

Example .htpasswd
mysecret:EQbTKu5OI7p5I

3. Multiple Users Access
1. Add additional users to the .htpasswd file.

Use the htpasswd command again but this time without the -c flag. For example you want to add tom, dick and harry to the list of people accessing that directory. Just type the following command at the prompt:
htpasswd fullpathname/.htpasswd tom
htpasswd fullpathname/.htpasswd dick
htpasswd fullpathname/.htpasswd harry

fullpathname is just the full path name of the directory in which the .htpasswd file is in. If you are already in that directory, fullpathname is not required.

*You can have different passwords for each member of the group or just one password for all the members.
2. Create a group file called .htgroup (remember the dot).

The .htgroup should look something like this:
my-users : tom dick harry

Where tom, dick and harry are the people to whom you want to give access. You can replace my-users with any name you like for a group.

3. Then, modify your .htaccess file.

Below is an example of a .htaccess file for a group.
AuthUserFile fullpathname/.htpasswd AuthGroupFile fullpathname/.htgroup AuthName AnyNameYouWant AuthType Basic <Limit GET> require group my-user
</Limit GET>

AuthGroupFile--This should be the full path name of your .htgroup file

Change user mysecret to group my-user (any the name of your group) so that only people in that specific group can gain access.

4. Don't forget to change the permissions to 744.

The way to have multiple username/password pairs is the same as having a single username/password pair, but just with a few additional steps.
Do the following extra steps:

Example .htgroup
mybuddy: tom dick harry

Example .htaccess
AuthUserFile /web/decs/web/multiple/.htpasswd
AuthGroupFile /web/decs/web/multiple/.htgroup
AuthName Multiple_User
AuthType Basic

<Limit GET>
require group mybuddy
</Limit>

4. Domain Name Access
Besides providing access to only single or multiple users, you can also give access to clients from a certain domain for example, egr.msu.edu. This is an example of how the .htaccess should look like:

AuthUserFile /dev/null AuthGroupFile /dev/null AuthName
AllowFromEgrMsuOnly AuthType Basic <Limit GET> order deny, allow deny from all allow from 35.9 </Limit>

Example .htaccess
AuthUserFile /web/decs/web/single/.htpasswd
AuthGroupFile /dev/null
AuthName Single_User
AuthType Basic

<Limit GET>
require user mysecret
</Limit>

5. Domain Name Access - Exclusion
You may just want to exclude clients from just one domain. Then, the .htaccess file would look like this:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName
DenyFromEgrMsuOnly AuthType Basic <Limit GET> order allow, deny allow from all deny from 35.9 </Limit>

Example .htaccess
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName DenyFromEgrMsuOnly
AuthType Basic

<Limit GET>
order allow,deny
allow from all
deny from 35.9
</Limit>

6. Combinational Access
To get a combination of the three kinds of access methods, the .htaccess should look something like this:

AuthUserFile fullpathname/.htpasswd AuthGroupFile
fullpathname/.htgroup AuthName AnyAccess AuthType Basic order deny, allow deny from all allow from egr.msu.edu require group mybuddy satisfy any

Use 'satisfy all' to restrict access by domain/addresses AND passwords.

PAM!!Intro to Linux Pluggable Authentication Modules

Every time you log into a Linux system, you’re using the Pluggable Authentication Modules (PAM) behind the scenes. PAM simplifies Linux authentication, and makes it possible for Linux systems to easily switch from local file authentication to directory based authentication in just a few steps. If you haven’t thought about PAM and the role it plays on the system, let’s take a look at what it is and what it does.

Actually, PAM is about more than logging into the system itself. Applications can use the PAM libraries to share authentication — so users can use a single username and password for many applications. The rationale behind PAM is to separate authentication from granting privileges. It should be up to the application how to handle granting an authenticated user privileges, but authentication can be handled separately.

A simple way of looking at this. Imagine going to an all-ages show at a local club. At the door, the bouncer checks ID and tickets. If you’ve got a valid ticket and ID that shows you’re over 21, you get a green wristband. If you’ve got a valid ticket and an ID that shows you’re under 21, you get a red wristband. Once in the club, it’s up to the bartender to grant privileges to buy alcohol (or not), and the club staff to grant seating privileges or direct you to the floor for general admission.

There’s no beer or music involved, but PAM is meant to work in a similar fashion.

Understanding PAM

Out of the box, most Linux installations are configured to use file-based authentication. Note that other systems also have PAM implementations, but for the purpose of this article we’ll stick to Linux.

For file-based authentication on modern Linux systems, users log in and their username and password combination is compared against /etc/shadow. Traditionally this was held in/etc/passwd, but the problem was that many programs needed to be able to read/etc/passwd. This meant that, in effect, anyone with local access could attempt to crack passwords — and without going into the details here, it was not beyond the realm of possibility that they’d be successful. This is doubly true when users are allowed to pick their own passwords and with no form of password policy enforcement.

So now user passwords are held in /etc/shadow, while things like the user shell and group are stored in /etc/passwd.

For single-user systems or small shops, this sort of file-based authentication is manageable. If you’re working with a small number of users on a handful of machines, it’s not difficult at all to deal with user account creation and user management manually using the standard tools provided by the distros.

But imagine if you have a 50-server environment which requires user synchronization across all systems. Suddenly you start dealing with issues of scale. You want to be able to use a directory service like OpenLDAP, or Microsoft’s Active Directory. But how? By switching away from the standard *nix password file method, and switching to an authentication module that supports the method you want to use.

Writing a module for PAM is well beyond the scope of this article. You shouldn’t need to anyway — plenty of modules exist already for any solution you’d want to use.

Take a look under /etc on a Linux system. On most popular distributions like Ubuntu Linux or Red Hat Enterprise you’ll find a directory, pam.d that has several files. Sometimes the configuration is held in /etc/pam.conf, but on many systems it’s broken out into several files by application. Remember, PAM is about more than just the initial login — it can also be used by other system applications that require authentication.

Let’s stick with login for now. Look at /etc/pam.d/login. This is the file used for the shadow login service. Here you’ll see quite a few directives for configuring the types of logins allowed, the type of authentication to be used, how long to delay another login if one fails, and much more. Here’s an example:

auth optional pam_faildelay.so delay=3000000

Basically, you’re calling the pam_faildelay module on authentication. If the user fails the attempt, it sets a delay so that any attacker trying to brute-force the way into a system will spend more time trying user/password combinations. Other PAM modules exist such aspam_succeed_if which will only allow an authentication to occur when an additional requirement such as being member of a certain group or your UID is within a certain range.

What if you want to change the type of authentication the system is using? Then you want to look at /etc/pam.d/common-auth, which defines the type of authentication being used to log into the system. It’s what points the system to /etc/shadow in the first place.

Here you can configure the system to use OpenLDAP, or other directory services. But there’s one more piece that needs to be changed, /etc/nsswitch.conf. This file tells the system what name services and directories to use for authentication, as well as where to look for protocol information (usually /etc/protocols, logically enough) and more. It’s sort of like your system’s Little Black Book, or the index to a Little Black Book.

Again, this goes back to the days when systems had One True Login and One True DNS, rather than a bunch of options. Now you can configure things so that the system uses OpenLDAP or Microsoft Active Directory (via Likewise, or Centrify) for authentication rather than static files. Another benefit of PAM is that it logs both successful and failures in common places, which allows you to use products specializing in reporting functionality to track whether logins are succeeding or failing.

As you can see, there’s a lot going on behind the scenes with PAM. You may have thought that Linux authentication was a simple affair, but there’s a lot of hidden (we hope) complexity and flexibility running the system when you provide your username and password. You’ll also find that Linux is very flexible, and can accommodate just about any authentication mechanism you’d like to use