11.6 Unix Network Defense

While insiders such as disgruntled employees commit most successful computer crimes, outsiders perpetrate the vast preponderance of attacks. Since the advent of modems in the 1970s ”and more significantly, since the broadband explosion of the late 1990s ”remote attacks have escalated.

For attackers , remote access offers many advantages over local hacking; not least, with remote access you cannot be physically identified and arrested on the spot. Perceived anonymity, jurisdictional restraints, and complex foreign laws make network attacks an attractive choice.

Unix integrated TCP/IP networking stacks early in its lifecycle. From the venerable r-commands (rsh, rlogin, rexec) that were used to access Unix system resources across TCP-based networks, to modern Virtual Private Networks (VPNs) and Secure Shell (SSH), the world of remote connectivity is rich in protocols and standards. Hence, it is also rich in complexity and inherent vulnerability.

Unix systems are reasonably well protected from network attacks, at least when they are configured by a capable network administrator. Network access controls should be enabled as a part of system hardening. Many Unix systems exposed to the Internet have withstood attacks for years , with no firewall protection, simply by relying on built-in commands (such as TCP wrappers) and minimal configuration.

In the following sections, we show you how to guard Unix systems from network attacks with methods such as network access controls, Unix built-in host firewalls, popular Unix application access controls, and other network security techniques. We cover standard Unix access control programs, examine application-specific access controls, address configuration issues, touch upon sniffing techniques, and then delve into the world of Unix host-based firewalls. This information may constitute a review for experienced Unix administrators.

Keeping your systems up to date with security patches is a fundamental aspect of network defense. For example, if you have to run an exposed FTP server, no amount of firewalling can keep attackers away: the FTP service has to be available to the world. In this circumstance, keeping the daemon updated is of paramount importance.

11.6.1 Advanced TCP Wrappers

TCP wrappers were covered earlier, in Section 11.4. Here, we demonstrate the advanced use of TCP wrappers to help you fine-tune their features for more security.

TCP wrappers can be used in two forms: as a binary (usually /usr/bin/tcpd , or anywhere else binaries are stored on a Unix system, such as /usr/ucb on Sun) or as a shared library ( /usr/lib/libwrap.so ).

11.6.1.1 tcpd

The binary form of TCP wrappers is used to "wrap" around network applications started from the Internet superdaemon inetd. In this case, the applications are configured in the /etc/inetd.conf file. The superdaemon starts the correct network application upon client connection to a specified port. The following is an excerpt from an /etc/inetd.conf file before TCP wrappers are added:

 ftp     stream    tcp    nowait    root    /usr/bin/in.ftpd     in.ftpd -l -a telnet  stream    tcp    nowait    root    /usr/bin/in.telnetd    in.telnetd shell   stream    tcp    nowait   root    /usr/bin/in.rshd    in.rshd talk     dgram    udp    wait     root    /usr/bin/in.talkd   in.talkd pop-3   stream    tcp    nowait   root    /usr/bin/ipop3d     ipop3d auth    stream    tcp     nowait   nobody    /usr/bin/in.identd    in.identd -l -e -o 

Next we see the same file, with the added protection of TCP wrappers:

 ftp    stream    tcp    nowait    root    /usr/sbin/tcpd    in.ftpd -l -a telnet stream    tcp    nowait    root    /usr/sbin/tcpd    in.telnetd shell  stream    tcp    nowait    root    /usr/sbin/tcpd    in.rshd talk    dgram    udp    wait      root    /usr/sbin/tcpd    in.talkd pop-3  stream    tcp    nowait    root    /usr/sbin/tcpd    ipop3d auth   stream    tcp    nowait    nobody  /usr/sbin/tcpd    in.identd -l -e -o 

TCP wrappers added two important benefits to the network services: security and improved logging. However, our TCP wrapper configuration is not yet complete. The files that define the denied and allowed hosts ( /etc/hosts.deny and /etc/hosts.allow ) need to be created. The simplest configuration that provides useful security is as follows ( /etc/hosts.deny is shown):

 ALL:ALL 

This file denies access from all hosts (the second ALL ) to all services on our server (the first ALL ). Who can use the machine? To define permissions, use /etc/hosts.allow :

 ALL: 127.0.0.1 LOCAL in.telnetd: [e-mail] sshd: manager.example.edu in.ftpd: .example.edu 10.10.10. in.pop3d: .com .org .net EXCEPT msn.com 

You can even set TCP wrappers to alert you in real time when connections from particular ports occur. The old TCP wrapper manpages provide the following example ( /etc/hosts.deny ):

 in.tftpd: ALL: (/some/where/safe_finger -l @%h  \            /usr/ucb/mail -s %d-%h root) & 

or even:

 sshd \   : ALL@.sunysb.edu ALL@calph ALL@insti \   : spawn (safe_finger -l @%h  mail -s 'SSHED FROM INTERNET %d-%c!!' anton) & \   : ALLOW 

The last example shows an alternative format for the hosts.allow file in which the action (allow or deny) is specified on a per-command-line basis, rather than a per-file basis.

One potential weakness with this setup is that it can subject you to email flooding ”even to the point of disk overflow. Chapter 12 addresses this issue in the section on Unix denial-of-service attacks.

11.6.1.2 libwrap

The libwrap.so system library provides the same functionality as a tcpd wrapper. If you have access to the application source code, you can streamline the access control process and incorporate access control file checking by the library. However, this requires significant changes to the application code base. This method is used in OpenSSH and in sendmail. If compiled with the libwrap.so library, the application itself will check the configuration files ( /etc/hosts.allow and /etc/hosts.deny ) to determine whether to allow or deny access. An example implementation is to control spam.

In addition, the inetd daemon has been rewritten to become xinetd, with advanced access control features. xinetd is used by some popular Linux distributions, including Red Hat. xinetd is controlled by its configuration file (usually /etc/xinetd.conf ) or sometimes via a configuration directory containing service-specific files. The configuration files below (similar to those used by Red Hat Linux) use a global configuration file and directory.

 # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/ defaults {         instances               = 60         log_type                = SYSLOG authpriv         log_on_success          = HOST PID DURATION         log_on_failure          = HOST RECORD USERID  } includedir /etc/xinetd.d 

This configuration file shows service defaults and logging defaults, and it refers to the configuration directory for details ( /etc/xinetd.d ). The file also provides some protection from resource exhaustion by limiting the number of child processes (FTP, email, or other network programs) started by xinetd.

The following example entry configures the popular File Transfer Protocol (FTP) implementation written by Washington University (WU-FTPD). This file lists protocol options similar to inetd.conf (such as type of service), server arguments, priority (keyword nice ), and system-logging options, but it also lists options for more granular access control.

 service ftp {         socket_type             = stream         wait                    = no         user                    = root         server                  = /usr/sbin/in.ftpd         server_args             = -l -a -i -o         log_on_success          += DURATION USERID         log_on_failure          += USERID         nice                    = 10 } 

The above file can contain the following access control options:

only_from

Specifies hosts that are allowed to have connections (adds another layer to TCP wrappers). The option can use IP addresses, hostnames, network names , or wildcards.

access_times

Lists the times when access is allowed in the format hour:min- hour :min , such as 10:00-18:00. At other times the "access denied" message is returned.

xinetd provides improvements to the classic inetd for enhanced flexibility and granularity in access controls. Unfortunately, it is standard on Linux only, and therefore you must compile and deploy it on other Unix flavors.

11.6.2 Application-Specific Access Controls

What if an application is not started from /etc/inetd.conf or /etc/xinetd.conf and its code cannot be modified to support libwrap? In this case, you can hope that the application has its own access control facility. Let's consider some known applications with their own network access controls.

11.6.2.1 BIND (DNS daemon)

BIND (Berkeley Internet Name Domain) DNS daemon software provides domain name resolution services for the majority of Internet hosts. Historically, BIND has passed through some major revisions (Versions 4, 8, and 9). While early versions had no network access controls due to their origin in the small and trusted Internet of the 1970s and 1980s, modern versions have an advanced granular access control facility.

General BIND configuration is a complex subject. In this section, we focus on the access control features to illustrate possible solutions for this problem.

The BIND configuration file is located in the /etc directory and is usually called /etc/named.conf . In this file, the administrator can specify which machines or domains can query the server for DNS information (keyword allow-query ), which can update the DNS zone status change (keyword allow-notify ), and which can perform DNS zone transfers (keyword allow-transfer ). Using the above keywords, the DNS daemon can be shielded from malicious attempts to update information or to map an organization's network (using complete DNS zone transfers).

The DNS daemon has a history of security bugs , and access control will help to increase your confidence in this mission-critical software.

11.6.2.2 sendmail (some versions)

sendmail can be compiled with TCP wrapper support. In addition, sendmail can use one of several built-in access control facilities. It's important to have reliable access controls for sendmail, since the SMTP protocol can be abused in many ways.

The purpose of sendmail access controls is to restrict mail-sending capability to authorized users only. The SMTP protocol currently used to send mail lacks a standard accepted authentication method. While some proposals exist (see RFC 2554 and RFC 2222), vendor support is lacking. As a result, network access control is the only solution.

As in the case of the BIND daemon, sendmail configuration is not for the weak of heart. The main sendmail configuration file ( /etc/sendmail.cf ) presents a confusing mess of regular expressions and unfriendly options. In fact, an additional directory is usually allocated ( /etc/mail ) to hold additional configuration files, including those used for access control. While simpler methods of configuring sendmail exist (such as by using the m4 macros for common options in sendmail.mc and then converting to sendmail.cf automatically), they are still less than intuitive.

sendmail can refer to an access database (not to be confused with a Microsoft Access database) in order to determine the privileges of the connected host. The connection can be refused if /etc/mail/access contains a REJECT keyword for the connected host or for the entire domain. Hosts can also be granted additional privileges, such as the ability to RELAY mail (i.e., send email to a third party). Such configuration files might look like:

 evilhacker.org    REJECT .edu        RELAY 

To make matters worse , the sendmail daemon does not check the /etc/mail/access file, but rather checks the binary database version of it. To convert the file from its plain-text human-editable form to the form readable by sendmail, execute the following command:

 makemap hash /etc/mail/access < /etc/mail/access 

Overall, compiling sendmail with TCP wrappers might be easier than sorting out the intricacies of the proprietary access control facilities of your software.

11.6.2.3 SSH daemon (sshd)

A commercial Secure Shell daemon, as well as the free OpenSSH, can be compiled with TCP wrappers. The SSH daemon also has a built-in access control. Both major versions of Secure Shell can be configured to block connections from specific hosts or even users.

The commercial SSH configuration file (usually /etc/sshd/sshd_config or /etc/sshd2/sshd2_config ) can contain keywords such as AllowUsers ( DenyUsers ) or AllowHosts ( DenyHosts ). The keywords work as follows: the configuration file can only contain one of the "Allow" or "Deny" keywords. If, for example, AllowHosts is present, all the hosts not explicitly mentioned in the AllowHosts directive are denied. On the other hand, if DenyHosts is in the configuration file, all the other hosts will be allowed to access the server.

Here's a sample directive:

 AllowHosts      localhost, example.edu 

In the case of commercial SSH2, you can use built-in regular expression syntax to create fairly complicated rules for host access. For example, the configuration setting:

 AllowHosts      go..example.\..* 

allows only specific hosts to access the server.

11.6.2.4 Apache web server

The most popular web server in the world is the open source Apache web server by the Apache Software Foundation. While web servers are primarily used to provide public access to resources over the Web, the need for access control often arises. In this section, we describe some of the ways of restricting access to web resources using Apache controls.

Apache has two main types of access control: username/password-based (basic or digest authentication) and host-based authentication.

The simplest form of access control is host or domain restriction . Various Apache configuration files (such as the main configuration file, usually located in /etc/httpd and called httpd.conf ) can contain directives to limit accesses from various hosts and domains. "Allow from" and "Deny from" are used for this purpose. Both can appear within the same file. To avoid confusion, the recommended method is to configure one directive with the target of "all" and use the second directive to grant or take away privileges.

An example of such a configuration is as follows:

 Order Deny, Allow Deny from all Allow from goodbox.example.org example.edu 

These lines allow access only to a certain web resource (such as a directory on a web server) from a single machine ("goodbox") within example.org and from the entire example.edu domain.

On the other hand, if certain "bad" hosts should be disallowed to access web resources, the following configuration may be used:

 Order Allow, Deny Allow from all Deny from badbox.example.org 

In this case, the machine "badbox" from the domain example.org is not allowed to access the pages.

More advanced access controls make use of usernames and passwords. These are well covered in the existing literature and on the Apache web server web site (http://httpd.apache.org/docs/howto/auth.html).

11.6.3 System Configuration Changes

This section deals with network- related OS hardening. There are many hacks aimed at increasing Unix system resistance to network attacks, including both denial-of-service attacks and unauthorized accesses.

To begin with, let us examine Linux SYN cookies. A SYN cookie is an ingenious method for mitigating the SYN-flood type of denial-of-service attack. Briefly, a SYN flood causes the exhaustion of machine resources by requesting too many TCP connections. For each connection, the receiving box allocates an entry in a special kernel table. If the table is exhausted, no more new connections can be established. While it is possible to make the table larger, an attacker can always cause the larger table to overflow by sending more packets. SYN cookies encode some connection information in the packet itself, thus avoiding the server-side storage requirement.

While it is more effective to block TCP/IP directed broadcasts at the network perimeter (such as on the router or the firewall), you can accomplish the same task at the host level to provide in-depth defense. Be sure to disable packet forwarding on all hosts not used for routing.

Routing protocols can be abused in several ways. Source routing is the most dangerous, albeit rarely seen on modern networks. Source routing IP options allow you to specify the exact path the packet should take to get to its destination. Most firewalls can be configured to block such packets, as they never serve a benign purpose.

11.6.3.1 Security from eavesdropping

Network attacks through eavesdropping are as common as ever. While telnet has lost a lot of ground as the Unix remote access protocol of choice, it is not yet dead. Secure Shell has made a lot of progress since its inception in the mid-1990s, but it has not become as ubiquitous as the encrypted web protocol HTTPS (SSL or TLS-based).

A sniffer is a part of every cracker's rootkit. Successful attackers leave hidden sniffers to collect unencrypted telnet, FTP, and POP3 passwords. Fortunately, protection against such network eavesdropping is trivial using encryption. However, as with many other security measures, it is often easier said than done. For example, replacing telnet with SSH on a large network is a process with many challenges, not the least of which is user compliance. While it might seem that typing "ssh hostname.example.edu" is simpler than "telnet hostname.example.edu", the three saved keystrokes might take a long time to actually implement in a large environment of users accustomed to unsafe computing habits. Unix vendors who do not include or enable Secure Shell exacerbate the difficulty. All Linux distributions are shipped with SSH ready for operation, but some commercial Unix vendors are lagging behind.

In this section, we look at protection from sniffers using freely available open source tools. Table 11-3 shows a list of common protocols used in Unix networking and their vulnerability to sniffing.

Table 11-3. Unix network protocols

Protocol or network application	Purpose	Plain-text communication	Plain-text authentication
FTP	File transfer	Yes	Yes
telnet	Remote access	Yes	Yes
POP3	Remote email retrieval	Yes	Yes, with no security enhancements
IMAP	Remote email box access	Yes	Yes
SMTP	Sending email	Yes	None needed
HTTP	Web page access	Yes	Yes, if basic authentication is used
r-commands (rsh, rlogin, rcp)	Remote access	Yes	Yes or no authentication
TFTP	File transfer	Yes	None provided
talk	Chat	Yes	None needed
syslog	Remote logfile transfer	Yes	None needed
NIS	Distributed authentication data	Yes	None provided
NFS	Remote filesystem	Yes	Yes or none provided
X11	Remote GUI access	Yes	Yes, with no security add-ons

A cursory glance at this list is startling. All classic Unix protocols are vulnerable to sniffing. What is available to protect Unix networks from sniffers? Encryption comes to the rescue. The Secure Sockets Layer (SSL) protects web connections, various authentication schemes (KPOP, APOP) shield email passwords, and SSH replaces telnet and FTP. SSL wrappers and SSH can be used to tunnel almost any TCP-based network protocol. X11 connections can be protected by SSH as well. Next, we consider SSH in more detail.

11.6.3.2 Secure Shell

SSH is one of the most flexible network security measures available today. It can be used to secure many network operations, such as remote access, email sending and retrieval, X Windows traffic, and web connections. SSH was promoted as a replacement for Unix telnet and rlogin/rsh remote-access protocols (which use plain-text communications vulnerable to sniffing and traffic analysis), but it now reaches far beyond Unix remote access.

SSH consists of client software, server software, and a protocol for their interaction. The interaction protocol includes authentication, key exchange, encryption, passphrase caching, as well as other components .

Currently, there are two major versions of the SSH protocol in use. SSH Version 1 has more supported platforms and probably even more users. However, SSH1 is known to have security problems (which will be described later), so you should avoid it. Significant differences between Versions 1 and 2 arise in their respective session-encryption protocols. SSH1 supports DES, 3DES, IDEA, and Blowfish, while SSH2 uses 3DES, Blowfish, Twofish, CAST128, and RC4. For authentication algorithms, SSH1 utilizes RSA, while SSH2 relies on the open-standard DSA. There are also other major implementation differences that cause these two protocol versions to be incompatible. However, OpenSSH (the open source version of the protocol) implements both protocols in one piece of software.

SSH uses several authentication options: regular passwords, RSA (for SSH1) or DSA (for SSH2) cryptographic keys for host or user authentication, and host or user trust files (such as the hosts.equiv and .rhosts that gave r-commands a bad name and were dropped in SSH2). Plug-in modules with other authentication methods, such as RSA SecurID card, Kerberos, or one-time passwords, can be used as well. Secure Shell can also compress all data for faster access on slow links.

There are several popular implementations of the SSH protocol. The most famous are SSH, by SSH Communications Security, and OpenSSH, by the OpenBSD development team. Many Linux distributions ship with SSH configured to run at startup. All you need are a valid user account and login.

Let's review how SSH can be used to secure other plain-text protocols. Suppose you have a POP3 (or IMAP) email server from which you read your messages. You are already aware that whenever you connect to a server to read email, your exposed username and password are transmitted in plain text over the Internet. Fortunately, SSH allows you to set up your mail client (such as the infamous Outlook Express, which spread the email worms of recent years) to connect only to the local machine. In this case, no information is leaked to the outside network. All the connections between your computer and the server are encrypted with Secure Shell.

The process is as follows: the SSH client software first establishes a regular connection to an SSH daemon running on the server machine. Next, it requests a connection to a required server port (port 110, in the case of POP3) from a remote machine. Then the SSH client starts to listen on the local client port. As a result, the tunnel from a local machine email port to a remote machine email port is set.

Password-less authentication is also of great value for POP3 tunneling, since you won't have to enter the password every time the email program wants to check for new email on the server.

On a Unix client, perform the following:

 $  ssh -f -L 1100:localhost:110 [e-mail]  

This command establishes a secure tunnel. Now, point your email client to retrieve mail from "localhost", port 1100 (instead of "pop3.mail.server.com", port 110). A higher-numbered port is used to avoid the need for root privileges. Usually, the email program has a configuration section that provides a space to enter incoming and outgoing mail servers. When using tunneling, your incoming mail server will be set to "localhost" or an IP address of 127.0.0.1. The -f option causes the ssh to fork in the background.

If you want to prevent anyone from eavesdropping on your outgoing email traffic on its way to a remote machine, do the same for an SMTP connection:

 $  ssh -f -L 25:smtp.mail.server.com:25 [e-mail]  

Although no passwords are transmitted in the case of SMTP, it still might be useful to tunnel SMTP mail by sending the connection over Secure Shell (as shown above).

Tunneling FTP is a bit more complicated, since FTP uses two pairs of TCP ports with dynamic allocation of port numbers . However, you can still implement it by using passive mode FTP and forwarding the data (port 20) and command (port 21) channels separately. scp (part of Secure Shell) can be used to provide the same functionality.

SSH can also be set to never send passwords over the network, even in the encrypted form, and this is highly recommended. The local password still needs to be set to protect the private key.

SSH uses a public key encryption scheme to authenticate users and hosts. To make use of this public key encryption, a user should create a key pair for authentication. The public key is then uploaded to the SSH server, and the private key is kept on the user's client machine.

To create a key pair in Unix/Linux, perform the following steps:

1. Run ssh-keygen (in the case of SSH1) or ssh-keygen2 (SSH2).

2. The program creates two files containing the private and public RSA keys from the pair and informs you what files they were written in (depending on the SSH version).

3. You are prompted for a password during private key creation. This password is used to encrypt your private key. It is not required, but in the case of empty passwords, all the responsibility for safeguarding the private key rests on your shoulders. Use empty passwords only if your machine is very secure and you are sure nobody else is using it. This practice is highly discouraged on public machines, since anybody who takes over your account will be able to connect to other machines for which you have created keys.

4. Next, upload the public key (usually found in the file identity.pub for SSH1) to the server in a secure manner. Either use scp or a floppy disk to transfer the key.

5. On the server, the key should be copied into the authorized_keys file located in your home directory ( ~/.ssh/ authorized_keys ). Note that other versions of SSH use different file locations (check the manpage for more information).

6. Attempt the connection to the server. You should not be prompted for a password. If you are still prompted for a password, check the filenames and locations, then confirm that the server allows the public key authentication of the correct type (SSH1 and SSH2 keys are not compatible). To troubleshoot, use SSH with a debugging flag ( -v ), which causes SSH to show the details of the connection and the protocol handshake.

From the very beginnings of SSH, the protocol was designed for secure file transfer as well as remote access. Since SSH was developed as a replacement for the Unix r-commands, the remote copy command (rcp) was replaced by secure copy (scp). scp can be used to copy files from one machine running SSH to another.

To use SSH for secure file copying on Unix/Linux, execute the following command:

 $  scp [e-mail]:~/data.tar .  

This command copies the data.tar file located in the home directory of the user "rusername" on the machine "server.example.com" to the current directory on the local machine (indicated by a trailing dot). If you have not set up public key authentication, you will be prompted for a password:

 $  scp /tmp/data.tar [e-mail]:~/  

The default remote directory is your home directory, so "~" is redundant. It is shown for demonstration purposes only. Also, the trailing slash is required for some SSH versions. This command copies the data.tar file from the /tmp directory on the current machine to the home directory of the user "rusername" on the machine "server.example.com". If you have not set up a public key authentication, you will be prompted for a password. You can also specify multiple filenames, as long as your last entry on the command line is a directory (indicated by a slash).

Learning to use Secure Shell is a good investment of your time, since it is vital to maintaining a secure network.

11.6.4 Host-Based Firewalls

In this section, we examine the quintessential host protection from network attacks: the host-based firewall . Analogous to Windows "personal firewalls," this tool shields workstations and servers from network attacks that penetrate company firewalls. Host-based firewalls are also extremely useful for Unix workstation users connected to the Net via broadband connections.

This section is structured around an example of a simple, one-host firewall setup for Linux and OpenBSD. Most free Unix flavors (Linux, *BSD, etc.) include ready-to-use firewalling code, whereas most commercial Unix flavors do not. An exhaustive description of Linux and OpenBSD firewalls would take an entire book (in fact, such a book exists; please see Section 11.7 at the end of this chapter for more information). Here, we cover only an example of effective host-based protection.

11.6.4.1 Linux iptables and ipchains

Packet-filtering firewalls work by restricting the free flow of network traffic according to predefined rules to allow or deny TCP/IP packets. iptables are an example of packet-filtering firewalls with some stateful features and some content-inspection features. iptables provide a set of rules (organized into groups called chains) that handle incoming and outgoing network traffic.

Linux firewalling code has come a long way since ipfwadm was introduced in kernel 1.2. Recent changes in Linux firewalling code include the netfilter architecture, which was introduced in kernel 2.4. netfilter/iptables are a reimplementation of Linux's firewalling code that remains fully backward compatible, due to the use of ipchains and ipfwadm loadable kernel modules. iptables offer the benefits of stateful firewalls: i.e., the firewall has a memory of each connection that passes through. This mode is essential for effective configuration of FTP ( especially active FTP) and DNS, as well as many other network services. In the case of DNS, the firewall keeps track of the requests and only allows responses to those requests, not other DNS packets. iptables can also filter packets based on any combination of TCP flags and based on MAC (i.e., hardware) addresses. In addition, iptables help block some DoS attacks by using rate limiting for user-defined packet types.

Below is a simple setup for a home firewall, inspired by the "Iptables HOWTO" document. The comment lines ( marked with the "#" symbol) within the script provide explanation:

 #!/bin/bash #cleanup - remove all rules that were active before we run the script iptables -F iptables -X #new chain to block incoming iptables -N allinput #NOW WE ALLOW SOME TRAFFIC #packets returning to connections initiated from inside are accepted iptables -A allinput -m state --state ESTABLISHED,RELATED -j ACCEPT #allow ssh incoming for management - we allow secure shell for remote server management iptables -A allinput --source 10.11.12.13 --protocol tcp --destination-port 22  -j  ACCEPT #this machine serves as a system log server - thus we allow UDP for systlog iptables -A allinput --source 10.11.12.0/24 --protocol udp --destination-port 514  -j  ACCEPT #allow X Windows connection for remote GUI iptables -A allinput --source 10.11.12.13 --protocol tcp --destination-port 6000  -j  ACCEPT #web server is public - but we do not like some people from 168 subnet (so they are   denied) iptables -A allinput --source ! 168.10.11.12 --protocol tcp  --destination-port 80 -j  ACCEPT #allow incoming from 127.0.0.1 BUT only if the interface is local (not the Ethernet card) iptables -A allinput --source 127.0.0.1 -i lo -j ACCEPT #DENY - all the rest are denied QUIETLY (with no reject message) iptables -A allinput -j DROP #these important lines control the flow of packets that enter our machine from outside #we send them to our control chain  iptables -A INPUT -j allinput iptables -A FORWARD -j allinput #test - display the rules that were enforeced iptables -nL 

Running the code produces the following output:

 Chain INPUT (policy ACCEPT) target     prot opt source               destination          allinput   all  --  0.0.0.0/0            0.0.0.0/0           Chain FORWARD (policy ACCEPT) target     prot opt source               destination          allinput   all  --  0.0.0.0/0            0.0.0.0/0           Chain OUTPUT (policy ACCEPT) target     prot opt source               destination          Chain allinput (2 references) target     prot opt source               destination          ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED  ACCEPT     tcp  --  10.11.12.13          0.0.0.0/0          tcp dpt:22  ACCEPT     udp  --  10.11.12.0/24        0.0.0.0/0          udp dpt:514  ACCEPT     tcp  --  10.11.12.13          0.0.0.0/0          tcp dpt:6000  ACCEPT     tcp  -- !168.10.11.12         0.0.0.0/0          tcp dpt:80  ACCEPT     all  --  127.0.0.1            0.0.0.0/0           DROP       all  --  0.0.0.0/0            0.0.0.0/0 

While a simpler setup is possible, this one is easier to manage, since you can always see what is allowed, from where and on which port/protocol. It also makes the default deny policy more visible.

Detailed iptables configuration is complicated. The standard Unix reference (the manpage) gives information on options, and online guides (such as those located at http://www.netfilter.org) provide more than enough information about the internal structure of iptables (user-space and kernel code) and proposed usage.

The example setup is very restricted. As the comments above point out, we only accepted the connection for a limited number of services. The rest are silently dropped. The remote attackers will not even be able to fingerprint the OS remotely using tools such as nmap, since all packets from hosts other than those allowed are dropped. As a result, our Linux machine is now well protected from network attacks.