Designing a firewall using Iptables for the Home User

In the previous post on iptables , I had given an introduction about iptables - the firewall installed by default in all Linux distributions. Here I will explain how to go about designing a firewall keeping in mind the needs of a home user. I am assuming that the typical home user will be having a single computer connected to the internet via a cable, DSL, Dialup or ISDN connection. There is no hard and fast rule in designing a firewall. What is good for one situation may not be good for another. But you can arrive at a common ground on certain things.

Here I will explain how you can make your home machine which is connected to the internet , which I am giving the name 'my_machine', more secure. First let us see what are the services that are running on the home machine (my_machine). Usually when you install Linux on your machine, you will be having some default services.

They are as follows:

• sshd - Secure Shell server
• portmap - Which is used by file services like NFS
• httpd - Apache web server
• ftp server - File Transfer Protocol server. This is not usually running on a home machine but just make sure about it by checking. In RedHat, you can check by running the command:
  

  # chkconfig --list |grep ftp

  If you have nmap installed on your machine, you can run the command :
  

  # nmap -sS your_ip_address

  ...to find all the open ports on your machine. The output for my_machine are as follows:
  

  
  Starting nmap 3.50 ( http://www.insecure.org/nmap/ )
  at 2005-10-19 09:41 IST
  Interesting ports on my_ip_address:
  (The 1653 ports scanned but not shown below
  are in state: closed)
  PORT      STATE SERVICE
  22/tcp    open  ssh
  80/tcp    open  http
  111/tcp   open  rpcbind
  3306/tcp  open  mysql
  6000/tcp  open  X11
  32774/tcp open  sometimes-rpc11
  
  Nmap run completed -- 1 IP address (1 host up)
  scanned in 1.205 seconds

  As seen above, I have apache webserver (http) , ssh, mysql server, X Server and rpcbind open to the outside world. rpcbind is used by NFS for mounting a remote drive. Usually a stand alone machine in our case my_machine need not open these services to the internet - except maybe ssh server which you might need to say - connect to your machine from a remote location - that too only if you have a static IP address, which is quite rare.
  

So lets get a pen and paper and decide how much or how little we want to open up our machine to the outside world. This is what I have decided:

1. I want full access to my_machine locally. That is all the services should be available for the localhost or IP address 127.0.0.1 .
2. New connections originating from a remote machine to Portmap, ssh, webserver and X server has to be blocked.
3. Established and related connections to my_machine has to be allowed. Here I would like to deviate from the topic to explain the terms 'new','established' and 'related'.For that you have to look at how TCP works. TCP is a connection-oriented protocol. Connection-oriented means that it makes sure all the packets reach the destination without any packet loss in transit. If a packet is lost, it re-sends the lost packet. This it achieves by using a set of flags. The flags are called SYN (Synchronize) and ACK (Acknowledge).
   
   When you click on a link in your web browser, your machine sends a SYN packet to the remote server which hosts the link. This process is called initiating a connection and is represented as NEW connection. When the remote server receives your request which has the flag SYN set, it sends a acknowledgment back to your machine by setting the SYN-ACK flag. And this is called a related connection.
   
   Once your machine receives the SYN-ACK packet, it responds with a final ACK packet which tells the remote machine that we have indeed received the packet. Then the connection is said to be established. This is called the three way handshake.
4. Restrict anyone initiating a new connection to my_machine from a remote location.
5. Allow all outgoing connections originating from my_machine.
6. Restrict all other incoming connections.
   

Now that we have jotted down what we want to achieve, let us write rules for achieving it.

I usually write the rules in a script file and then execute the file. This allows me to keep everything organized. Also if I make a mistake, I just have to go back and edit the script and re-execute it. One other thing though - all allow rules must precede the deny rules.

Iptables Rules:

Allow localhost access to everything

iptables -A INPUT -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -j ACCEPT

Allow all related and established tcp connections to my_machine.

iptables -A INPUT -p tcp -m state
        --state ESTABLISHED,RELATED
        -j ACCEPT

Allow all outgoing connections from my_machine.

iptables -A OUTPUT -j ACCEPT

... now start writing the deny rules.
Deny all new tcp connections from remote machines. And log the same.

iptables -A INPUT -p tcp -m state --state NEW -j LOG
iptables -A INPUT -p tcp -m state --state NEW -j DROP

Block the apache port on my_machine. See the nmap command listing above. Also log the traffic.

iptables -A INPUT -p tcp -s 0/0 --dport 80 -j LOG
iptables -A INPUT -p tcp -s 0/0 --dport 80 -j DROP

Note: LOG rule must precede the corresponding filter rule.

Block ssh to my_machine. Also log the traffic.

iptables -A INPUT -p tcp -s 0/0 --dport 22 -j LOG
iptables -A INPUT -p tcp -s 0/0 --dport 22 -j DROP

Finally Deny everything else.

iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP

Now execute the script to load the rules into kernel space. That is it. Now we have got a robust firewall in place. You can check the results by re-running the nmap command listed above.

Installing Ubuntu Linux alongside Windows OS

There are different flavors of Linux distributions ... Fedora, SUSE, Mandriva, Slackware ... the list goes on and on. Around a year back, a South African upstart company called Canonical, founded by the multimillionaire and space tourist Mark Shuttleworth created a new Linux distribution. They named it Ubuntu Linux. In African language, Ubuntu means 'Humanity to others'. They not only succeeded in creating a robust distribution based on Debian but also decided that they will distribute the CDs free of cost.

If you want a few CDs, just visit shipit.ubuntu.org, create an account and place an order for the free CDs. You can order any number of them for your use as well as passing over to friends and acquaintances. Ubuntu Linux has quickly grown to have a wide user base and excellent support. It is a distribution basically targeted at the desktop user. But recently a separate server version has also been released.

Ubuntu Linux comes with a enhanced text based installer which is claimed to be very easy to use. I came across this excellent step-by-step tutorial called - Ubuntu Dual Boot - which gives a very clear description about how to install Ubuntu Linux on your machine along side with Windows OS, which I would recommend to everyone who are interested in Ubuntu. It also has all the screen shots of the installer which makes installing this distribution a cake walk. Even though, I have installed Linux (though not Ubuntu) numerous times in the past, I was able to clarify a few of my doubts about partitioning by reading this tutorial.

Make a donation and support this project

I have been maintaining this site for the past one year. And this site has reached over a 100 posts all related to Linux - which includes configuring, troubleshooting and usage tips. This project was started with a personal goal of putting all my notes related to linux online so that it would become a place of reference not only for me but also for other like minded netizens. Now it has expanded and includes reviews of Linux distributions and related softwares I have tested.

Ways you can support this project

• Make a donation - You can send some money via PayPal in appreciation of this site. That will make me very very happy :) as it will help me in paying my Internet bills.
• Spread the word around - Talk about this site to all your friends, relatives, acquaintances and just about anybody you come across, who is even remotely interested in Linux.
• Participate by posting a comment - Even though I do not have plans to accept articles from others at this point of time (as some people had suggested); mainly because this site lists my personal experiences in using Linux. Also accepting articles from others will throw up a whole set of other problems which I am not ready to face at present. But you can post a comment telling your views about the topic I write. You can tell me what you like / dislike about my post, any mistakes I have made (all humans are prone to mistakes) and any new things you know about the article.
  

You can make a donation via "PayPal" button on the right hand side. I am looking forward to your valuable contributions.

iptables - The poor man's robust firewall for Linux

A firewall is a software which is used to control the movement of network traffic according to a set of rules. Linux ships with an excellent GPLed firewall called iptables. Here I will explain the rudimentary concepts in using iptables.

Iptables is a packet filter which supersedes the erstwhile ipchains. It forms the first point of contact for packets that flow into or out of your network. In fact the packets are checked in the following order when it reaches your computer.

+-----------+
| Incoming  |
|  packet   |
+-----------+
 |
 |
 v
+-----------+
| Iptables  | --> Block
+-----------+
 | Pass
 |-------> Forward to another system
 |
 |                Kernel Space
----------------------------------------
 |                User Space
 |
 v
+--------------+
| TCP Wrappers | --> Block
+--------------+
 | Pass
 |
 v
+--------------------+
| xinetd based rules | --> Block
+--------------------+
 | Pass
 |
 v
Onward journey
of the packet

As you can see in the above diagram, iptables works in the kernel space.

Here I will give a simple introduction to this very useful and powerful but cryptic form of securing ones network.

If you are using kernel 2.4 and above, you will be using iptables. Iptables functionality is directly compiled into the Linux kernel as a module (netfilter). The policies are checked at the layers 2, 3 and 4 of the OSI Reference Model. That is 'Datalink', 'Network' and 'Transport' layer. It is very fast because only the packet headers are inspected. There is a wonderful tutorial on configuring firewalls using iptables at Netfilter.org. But if you are lazy (like me :) ) to plod through over 130 pages of the tutorial, then read on ...

Netfilter is divided into tables which in turn are divided into chains. And each chain can have different targets.

Netfilter tables :
There are three inbuilt tables. They are as follows:

1. filter - This is the default table if no table name is specified in the rule. The main packet filtering is performed in this table.
2. nat - This is where Network Address Translation is performed. For example, if you are using your machine as a router or sharing your internet connection with other machines on your network, you might use the NAT table in your rule.
3. mangle - This is where a limited number of 'special effects' can happen. This table is rarely used.
   

Netfilter chains :
I said above that each table has a number of inbuilt chains. These are as follows:
For filter table

1. INPUT - Handles packets destined for the local system, after the routing decision.
2. OUTPUT - This chain handles packets after they have left their sending process and before being processed by POSTROUTING (applicable to nat and mangle) chain.
3. FORWARD - This chain handles packets routed through the system but which are actually destined for another system on your LAN.
   

For the nat table

1. OUTPUT - see explanation above.
2. PREROUTING - This is the entry point of packets on their arrival. All packets first pass through this chain before even passing through the routing decision.
3. POSTROUTING - If PREROUTING is the first chain that a packet encounters, POSTROUTING is the final point of contact for any packet before it leaves the system.
   

For mangle table

• The mangle table contains a union of all the chains in the filter and nat tables.

Note: Over and above the builtin chains, you can also have custom user defined chains too. Usually you use a custom chain to group a series of actions together before passing it to one of the inbuilt chains.

Rule targets :

As I said above, each chain can have different targets. They are broadly classified into builtin and extension targets. The target names must be preceded by the option -j . -j as in jump. These are the targets:

Builtin targets

• DROP - As the name indicates, discards the packet. No message is relayed back to the sender of the packet.
• ACCEPT - Allows the packet to pass through the firewall.
• RETURN - This is a built in target which is created for convenience. Because most targets do not return. That is if a packet matches a rule, the checking of that packet ceases and the chain is exited.
  

Extension targets

• LOG - This is used to log messages to your system of offending or blocked packets. Usually, control is passed to the syslog facility which logs the message to the file /var/log/messages and then returns the control back to the iptables.
• REJECT - If this target is used, a notice is sent back to the sender. Like for example "you are denied access to this service" message.
• DNAT - Used for destination NAT ie rewriting the destination IP address of the packet.
• SNAT - Used for rewriting the source IP address of the packet.
• MASQUERADE - This is used to do either SNAT or DNAT. Basically this target is used to set up internet connection sharing in your network.
  

Note: All extension targets are usually implemented in special-purpose kernel modules. To know which all modules are loaded on your system, execute the command:

# lsmod |grep ipt

ipt_limit               1792  8
iptable_mangle          2048  0
ipt_LOG                 4992  8
ipt_MASQUERADE          2560  0
iptable_nat            17452  1 ipt_MASQUERADE
ipt_TOS                 1920  0
ipt_REJECT              4736  1
ipt_state               1536  6
ip_conntrack           24968  5 ipt_MASQUERADE,
iptable_nat,ip_conntrack_irc,ip_conntrack_ftp,ipt_state
iptable_filter          2048  1
ip_tables 13440 9 ipt_limit,iptable_mangle,ipt_LOG,
ipt_MASQUERADE,iptable_nat,ipt_TOS,ipt_REJECT,ipt_state,
iptable_filter

These are the modules that are loaded on my system. As you can see, all modules that start with the name 'ipt_' are extension modules. So in the above listing, iptable_nat module uses a extension module called ipt_MASQUERADE . And to use the LOG extension target, you should have loaded the ipt_LOG extension module. So on and so forth :) .

A few examples to whet your appetite

# iptables -t filter -A INPUT -p tcp -s 192.168.0.5 -j DROP

The above rule can be read as follows. In the filter table (-t), append (-A) to the INPUT chain the rule that, all packets using the protocol (-p) tcp and originating (-s) from the remote machine with IP address 192.168.0.5 should be dropped (-j DROP).

# iptables -A FORWARD -s 0/0 -p TCP -i eth0 -d 192.168.5.5  
        -o eth1 
        --sport 1024:65535 --dport 80 -j ACCEPT

This rule reads as follows: Append (-A) to the FORWARD chain, the rule that all packets coming from anywhere (-s 0/0) using the protocol (-p) TCP and using unreserved ports (--sport 1024:65535), incoming (-i) through the interface eth0 , and destined (--dport) for port 80 on address (-d) 192.168.5.5 and outgoing (-o) through the interface eth1 should be accepted.

# iptables -L

List (-L) all the rules in the iptables.

# iptables -F

Flush (-F) all the rules from iptables. Now you can start afresh.

# iptables -A OUTPUT -j LOG
# iptables -A INPUT -j LOG

Log all incoming and outgoing rules in the filter table to the file /var/log/messages.

I hope you have got the drift ;) . Iptables is a very powerful and flexible tool and can be used to block anything or everything that comes into or goes out of your computer.

Wait there is one more thing ...

Usually the commands that you executed above will reside in memory but will not persist across rebooting. Which means, once you reboot, all your rules are lost and you have to start all over. So to avoid this, you save your rules into a file which is read by the OS when you reboot your machine.

In RedHat/Fedora, the iptables rules are saved in the file /etc/sysconfig/iptables . You save it using the programs iptables-save as follows:

# iptables-save > /etc/sysconfig/iptables 

or do the following :

# service iptables save 

There is another script called iptables-restore which can be used to load the rules from a file into memory.

Different ways of locking a user's account in Linux

You can disable a user's account in the following different ways:

First Method
Open /etc/passwd file and find the line containing the user's name.

# vi /etc/passwd 

Or if you are on a system used by lots of people, there is a very secure form of opening the /etc/passwd file for editing :

# vipw 

... which also opens the /etc/passwd file for editing in the vi editor - but in a more secure manner.

#FILE: /etc/passwd
...
ravi:x:500:500:Ravi Kumar:/home/ravi:/bin/bash
...

Now change the shell /bin/bash to /sbin/nologin .

#FILE: /etc/passwd
...
ravi:x:500:500:Ravi Kumar:/home/ravi:/sbin/nologin
...

Save and exit the file.

Second Method

Enter /etc/passwd file and move to the line containing the user's name. Now enter a '!' (bang) or '*' (asterisk) just before the 'x' in the second field. Save and exit the file.

Note: The fields in the file /etc/passwd are separated by ':' (colons) .

#FILE: /etc/passwd
...
ravi:*x:500:500:Ravi Kumar:/home/ravi:/bin/bash
...

Note: If you are not using shadow passwords (highly unlikely), you will have the password in encrypted format in the second field instead of an x. Unlocking the account is the reverse of what you did above.

Important: One guy told me that if you use the above method, a disabled user can login through the network using SSH. I have not checked it out though.

Third Method

You can use the command chage to lock a user's account. You do this by changing the expiry date to any date before the current date.

# chage -E 2005-10-01 ravi

The above command will set the expiry date of ravi's account to 'Oct 1st 2005' which is a previous date. So when the next time ravi tries to login to his account, he will get the message that his account is disabled.

Note: For chage to work, you should be using shadow passwords (most distros use this by default). You can re-enable the user's account by running the same command but changing the date to a value greater than the current date.

Fourth Method
Execute the following command:

# passwd -l ravi

This will lock ravi's account. Now to unlock the account, do:

# passwd -u ravi

Check the logs

All failed logins will be audited and logged to the file /var/log/messages. To see who all have unsuccessfully tried to login to their account, try the following:

# grep "FAILED LOGIN" /var/log/messages

Also if you have a file called /var/log/faillog check that out too. It contains a history of all failed login details. This file is used when you use PAM (Pluggable Authentication Modules) for enforcing password policies.

You can change the default password policies by editing the file /etc/login.defs . But any changes will be applicable to only to those user accounts created after the modification of the file.

3dDesktop - The Desktop switcher on steroids

I am amazed when people pass comments like - Linux is drab, graphic applications in Linux are primitive and so on. These comments may have had some validity a few years back; But not any longer. For one, OpenGL which is a well developed graphics engine has strong support on the Linux platform. One just have to look at any application which uses OpenGL libraries to understand the true power behind this graphics engine. I tell each and everyone even remotely interested in computers that Linux has come of age and it is definitely going to be a real threat to its commercial counterparts.

Here I will describe a nifty utility which can be used to switch your desktop - that is right, Linux has multiple desktops (4 by default). This utility is called 3dDesktop. 3D-Desktop is a program for switching virtual desktops in a seamless 3-dimensional manner on Linux. The current desktop is mapped into a fullscreen 3D environment where you may choose other screens.It uses OpenGL for rendering the special effects. If you are running 3dDesktop, you can have quite a number of special effects in the same leagues as those in Mac OSX.

But first the prerequisites:

For successfully running any application using OpenGL, you need a good graphics card having atleast 64 MB memory. If your PC does not have a graphics card, your experience of running 3dDesktop will be atmost crappy. For example, I have a NVIDIA Graphics card installed in my machine.

3dDesktop is usually shipped with all major Linux distributions. But if it is not installed on your machine, you can download it from its website and install it.

The 3dDesktop package installs amoung others, three important files. They are :

1. 3ddeskd - Which is the server (daemon) which should work in the background
2. 3ddesk - The client which is used to show the special effects to the user. And
3. 3ddesktop.conf - which is the system wide configuration file which contains details like what kind of special effects need to be shown and so on. The contents of this file could be overridden.
   

How to make it work
First fire up xterm and start the 3ddesktop server (3ddeskd).

$ 3ddeskd --wm=fluxbox --acquire --texturesize=1024 &

In the above command, I have passed the type of window manager I am using with the --wm option, acquire screenshots of all my desktops with the --acquire option and used a texture size of 1024 (must be multiples of 2 with a minimum value of 128) with the --texturesize option. I have used Fluxbox as my window manager. But you can pass the name of the window manager in which you are working, in the --wm option.

From now on, when ever you want to switch the desktop, you run the client part of the package which is 3ddesk. It can be passed a few options; the important ones being :

--view - This option decides the kind of graphics effects to show. The different values being goright, goleft, slide, zoom, nozoom, linear, linearzip and bigmoney.

--mode - This option sets the arrangement of the special effects. The effects being carousel (which is the default), cylinder, linear, viewmaster, priceisright, flip or random.

Of course, you can also run 3ddesk without passing any options in which case, it reads the default options from the /etc/3ddesktop.conf configuration file.

Here are a few examples of how to start the show.

$ 3ddesk

... accepts the default options.

$ 3ddesk --mode=cylinder --view=zoom

... the desktop takes the shape of a cube.

$ 3ddesk --view=bigmoney

... Vertical rotation

Once you execute any of the above commands, try switching the desktop by rotating the mouse wheel or clicking the left or right mouse buttons. And select the desktop by clicking the middle button (wheel).You can also rotate the desktop by using the arrow keys on your keyboard and then select your desktop by pressing enter.

Mapping a Key Sequence to start 3ddesk

This utility becomes really useful when you map a key sequence to execute the 3ddesk (client) program in your window manager. In KDE and GNOME, it is a snap. Here I will explain how to map a key sequence in Fluxbox (my window manager of choice) to start 3ddesk.

If you are running fluxbox as your window manager, you will have a hidden directory by name .fluxbox in your home directory.

$ ls -al | grep fluxbox

This hidden directory contains the configuration files for this window manager. Now open the file ~/.fluxbox/keys in your favorite editor and insert the following lines.

#FILE: ~ravi/.fluxbox/keys
# Use 3ddesk to change desktop
Mod4 KP_6 :ExecCommand 3ddesk   --gotoright
Mod4 Right :ExecCommand 3ddesk  --gotoright --nozoom
Mod4 KP_4 :ExecCommand 3ddesk   --gotoleft
Mod4 Left :ExecCommand 3ddesk   --gotoleft --nozoom
Mod4 Down :ExecCommand 3ddesk   --mode=viewmaster

The above lines map a key sequence to execute 3ddesk program. For example, if I press the [Windows key] and the 6 in the keypad simultaneously, it will automatically execute the 3ddesk command on the first line in the above listing. Here,

Mod4 - Window Key on your keyboard
KP_6 - The 6 on your number pad.
Mod1 - Alt key

Now you reload the configuration file in fluxbox. That is it. Now to switch your desktop, you just have to press [WindowKey + left arrow]. Or try [Win Key + Down arrow].

Figure 1 : Vertical Flip

Figure 2 : Vertical flip continued

Figure 3: Viewmaster mode

Figure 4: Bigmoney mode

Figure 5: Cylindrical mode

Note: For the 3ddeskd daemon to start each time you boot into Linux, you have to set it up in the configuration file. I have inserted the following line in the ~ravi/.fluxbox/startup file.

# FILE: /home/ravi/.fluxbox/startup
if [ -x /usr/bin/3ddeskd ]; then
3ddeskd
fi

All code in the file /home/ravi/.fluxbox/startup will be executed when you log into fluxbox. So that does the trick of starting the 3ddeskd daemon automatically.

Next time if anybody starts giving you a sermon about the beauty of Mac OSX, direct them to this article. :)

Using TCP Wrappers to secure Linux

TCP Wrappers can be used to GRANT or DENY access to various services on your machine to the outside network or other machines on the same network. It does this by using simple Access List Rules which are included in the two files /etc/hosts.allow and /etc/hosts.deny .

Let us consider this scenario: A remote machine remote_mc trying to connect to your local machine local_mc using ssh.

When the request from the remote_mc is received by the tcp wrapped service (SSH in this case), it takes the following basic steps:

1. It checks the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule , it allows the connection. If no rule is found, it moves on to step 2.
2. It checks the /etc/hosts.deny file and if a matching rule is found, it deny's the connection.
   

Points to remember

• Rules in hosts.allow takes precedence over rules in hosts.deny . Which means if a matching rule is found in hosts.allow file, the remote_mc is allowed access to the service even if there is a matching deny rule in hosts.deny file.
• You can have only one rule per service in hosts.allow and hosts.deny file.
• If there are no matching rules in either of the files or if the files don't exist, then the remote_mc is allowed access to the service.
• Any changes to hosts.allow and hosts.deny file takes immediate effect.
  

Rule Syntax
The syntax for both hosts.allow and hosts.deny file takes the following form:

daemon : client [:option1:option2:...]

Where daemon can be a combination of ssh daemon, ftp daemon, portmap daemon and so on. Basically any service which has support for libwrap.a library compiled into it is a good candidate for utilizing the services of TCP Wrappers.

client is a comma separated list of hostnames, host IP addresses, special patterns or special wildcards which identify the hosts effected by that rule.

options is an optional action like say sending mail to the administrator when this rule is matched, log to a particular file and so on. It can be a colon separated list of actions too.

Examples of using TCP Wrappers

I want to allow SSH access to hosts in a particular domain say xyz.com and deny access to all the others. I enter the following rule in the hosts.allow file.

sshd : .xyz.com

... and in the hosts.deny file I include the rule:

sshd : ALL

The next rule denys FTP access to all the hosts in the abc.co.in domain as well as hosts in the 192.168.1.0 network.

#FILE: /etc/hosts.deny
vsftpd : 192.168.1. , .abc.co.in : spawn /bin/echo  `/bin/date` access denied >> /var/log/vsftpd.log : deny

The backslash (\) in the above rule is used to break the line and prevents the failure of the rule due to length.

spawn and deny are options. Spawn launches a shell command as a child process. In the above rule, spawn logs a message to the vsftpd log file each time the rule matches. deny is optional if you are including this rule in the hosts.deny file.

Note: The last line in the files hosts.allow and hosts.deny must be a new line character. Or else the rule will fail.

For example, you can use spawn option to send mail to the admin when ever a deny rule is matched.

Wildcards

You can use wildcards in the client section of the rule to broadly classify a set of hosts. These are the valid wildcards that can be used.

• ALL - Matches everything
• LOCAL - Matches any host that does not contain a dot (.) like localhost.
• KNOWN - Matches any host where the hostname and host addresses are known or where the user is known.
• UNKNOWN - Matches any host where the hostname or host address are unknown or where the user is unknown.
• PARANOID - Matches any host where the hostname does not match the host address.
  

Patterns
You can also use patterns in the client section of the rule . Some examples are as follows:

ALL : .xyz.com

Matches all hosts in the xyz.com domain . Note the dot (.) at the beginning.

ALL : 123.12.

Matches all the hosts in the 123.12.0.0 network. Note the dot (.) in the end of the rule.

ALL : 192.168.0.1/255.255.255.0

IP address/Netmask can be used in the rule.

ALL : *.xyz.com

Asterisk * matches entire groups of hostnames or IP addresses.

sshd : /etc/sshd.deny

If the client list begins with a slash (/), it is treated as a filename. In the above rule, TCP wrappers looks up the file sshd.deny for all SSH connections.

sshd : ALL EXCEPT 192.168.0.15

If the above rule is included in the /etc/hosts.deny file, then it will allow ssh connection for only the machine with the IP address 192.168.0.15 and block all other connections. Here EXCEPT is an operator.

Note: If you want to restrict use of NFS and NIS then you may include a rule for portmap . Because NFS and NIS depend on portmap for their successful working. In addition, changes to portmap rules may not take effect immediately.

Suppose I want to log all connections made to SSH with a priority of emergency. See my previous post to know more on logging. I could do the following:

sshd : .xyz.com : severity emerg

Note: You can use the options allow or deny to allow or restrict on a per client basis in either of the files hosts.allow and hosts.deny

in.telnetd : 192.168.5.5 : deny
in.telnetd : 192.168.5.6 : allow

Shell Commands

As mentioned above, you can couple the rules to certain shell commands by using the following two options.

spawn - This option launches a shell command as a child process. For example, look at the following rule:

sshd : 192.168.5.5 : spawn /bin/echo `/bin/date` from %h >> /var/log/ssh.log : deny

Each time the rule is satisfied, the current date and the clients hostname %h is appended to the ssh.log file.

twist - This is an option which replaces the request with the specified command. For example, if you want to send to the client trying to connect using ssh to your machine, that they are prohibited from accessing SSH, you can use this option.

sshd : client1.xyz.com : twist /bin/echo "You are prohibited from accessing this service!!" : deny

When using spawn and twist, you can use a set of expressions. They are as follows :
%a — The client's IP address.
%A — The server's IP address.

%c — Supplies a variety of client information, such as the username and hostname, or the username and IP address.

%d — The daemon process name.
%h — The client's hostname (or IP address, if the hostname is unavailable).
%H — The server's hostname (or IP address, if the hostname is unavailable).

%n — The client's hostname. If unavailable, unknown is printed. If the client's hostname and host address do not match, paranoid is printed.

%N — The server's hostname. If unavailable, unknown is printed. If the server's hostname and host address do not match, paranoid is printed.

%p — The daemon process ID.

%s — Various types of server information, such as the daemon process and the host or IP address of the server.

%u — The client's username. If unavailable, unknown is printed.