Nohup command
Under Unix/Linux you can do this:

nohup java -Doptions mypackage.myclass args output 2>error &

& at the end tells the command shell to run the process in the background, that is, not to wait for it to terminate and go on.
"nohup" tells the process to ignore the hangup signal, that is, not to terminate when the shell exits from where it was started.

Unix/Linux下一般想让某个程序在后台运行，很多都是使用 & 在程序结尾来让程序自动运行。比如我们要运行mysql在后台：

/usr/local/mysql/bin/mysqld_safe --user=mysql &

　但是我们很多程序并不象mysqld一样可以做成守护进程，可能我们的程序只是普通程序而已，一般这种程序即使使用 & 结尾，如果终端关闭，那么程序也会被关闭。为了能够后台运行，我们需要使用nohup这个命令，比如我们有个start.sh需要在后台运行，并且希望在 后台能够一直运行，那么就使用nohup：

nohup /root/start.sh &

在shell中回车后提示：

[~]$ appending output to nohup.out

原程序的的标准输出被自动改向到当前目录下的nohup.out文件，起到了log的作用。

但是有时候在这一步会有问题，当把终端关闭后，进程会自动被关闭，察看nohup.out可以看到在关闭终端瞬间服务自动关闭。

咨询红旗Linux工程师后，他也不得其解，在我的终端上执行后，他启动的进程竟然在关闭终端后依然运行。

在第二遍给我演示时，我才发现我和他操作终端时的一个细节不同：他是在当shell中提示了nohup成功后还需要按终端上键盘任意键退回到 shell输入命令窗口，然后通过在shell中输入exit来退出终端；而我是每次在nohup执行成功后直接点关闭程序按钮关闭终端.。所以这时候会 断掉该命令所对应的session，导致nohup对应的进程被通知需要一起shutdown。

这个细节有人和我一样没注意到，所以在这儿记录一下了。

附：nohup命令参考

nohup 命令

　　用途：不挂断地运行命令。

　　语法：nohup Command [ Arg ... ] [　& ]

　　描述：nohup 命令运行由 Command 参数和任何相关的 Arg 参数指定的命令，忽略所有挂断（SIGHUP）信号。在注销后使用 nohup 命令运行后台中的程序。要运行后台中的 nohup 命令，添加 & （ 表示"and"的符号）到命令的尾部。

　　无论是否将 nohup 命令的输出重定向到终端，输出都将附加到当前目录的 nohup.out 文件中。如果当前目录的 nohup.out 文件不可写，输出重定向到 $HOME/nohup.out 文件中。如果没有文件能创建或打开以用于追加，那么 Command 参数指定的命令不可调用。如果标准错误是一个终端，那么把指定的命令写给标准错误的所有输出作为标准输出重定向到相同的文件描述符。

　　退出状态：该命令返回下列出口值：

　　126 可以查找但不能调用 Command 参数指定的命令。

　　127 nohup 命令发生错误或不能查找由 Command 参数指定的命令。

　　否则，nohup 命令的退出状态是 Command 参数指定命令的退出状态。

　　nohup命令及其输出文件

　　nohup命令：如果你正在运行一个进程，而且你觉得在退出帐户时该进程还不会结束，那么可以使用nohup命令。该命令可以在你退出帐户/关闭终端之后继续运行相应的进程。nohup就是不挂起的意思( n ohang up)。

　　该命令的一般形式为：nohup command &

　　使用nohup命令提交作业

　　如果使用nohup命令提交作业，那么在缺省情况下该作业的所有输出都被重定向到一个名为nohup.out的文件中，除非另外指定了输出文件：

　　nohup command > myout.file 2>&1 &

　　在上面的例子中，输出被重定向到myout.file文件中。

　　使用 jobs 查看任务。

　　使用 fg %n　关闭。

DU, DF , Quota

du (abbreviated from disk usage) is a standard Unix program used to estimate the file space usage; space used under a particular directory or files on a file system.

Sum of directories in Kbytes:

$ du -sk *
2800344 directoryOne
4270554 directoryTwo

du -sh Documents/
409M    Documents

disk usage of all subdirectories and files including hidden files within the current directory (sorted by filesize) :
$ du -sk .[A-z]* *|sort -n

df (abbreviated from disk free) is a standard Unix computer program used to display the amount of available disk space for filesystems on which the invoking user has appropriate read access, df is usually implemented by reading the mtab file or using statfs.
$ df -k
Filesystem    1024-blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4            32768     16016   52%     2271    14% /
/dev/hd2          4587520   1889420   59%    37791     4% /usr
/dev/hd9var         65536     12032   82%      518     4% /var
/dev/hd3           819200    637832   23%     1829     1% /tmp
/dev/hd1           524288    395848   25%      421     1% /home
/proc                   -         -    -         -     -  /proc


/dev/hd10opt        65536     26004   61%      654     4% /opt

Install Perl Modules at your home directory
(1) install from the module package
Normally, the Perl5 module installation procedure includes commands something like these:

% perl5 Makefile.PL

% make

% make test

% make install

% make clean

The first command, perl5 Makefile.PL, directs perl5 to create a makefile for the new module you are installing. When installing a perl5 module locally you must designate the home directory of your perl5 installation on the command line. That information is used by perl5 to create the makefile. Substitute the following command for perl5 Makefile.PL:

% perl5 Makefile.PL PREFIX=/usr/home/USERNAME/usr/local

The value USERNAME above should be replaced with your Virtual Private Server primary user account name. So the complete installation process is:

% perl5 Makefile.PL PREFIX=/usr/home/USERNAME/usr/local

% make

% make test

% make install

% make clean

For older modules it may be necessary to designate several other variables on the command line during the module installation:

% perl5 Makefile.PL PREFIX=/usr/home/USERNAME/usr/local \
INSTALLPRIVLIB=/usr/home/USERNAME/usr/local/lib/perl5 \
INSTALLSCRIPT=/usr/home/USERNAME/usr/local/bin \
INSTALLSITELIB=/usr/home/USERNAME/usr/local/lib/perl5/site_perl \
INSTALLBIN=/usr/home/USERNAME/usr/local/bin \
INSTALLMAN1DIR=/usr/home/USERNAME/usr/local/lib/perl5/man \
INSTALLMAN3DIR=/usr/home/USERNAME/usr/local/lib/perl5/man/man3

To save yourself some typing you can create a file and put these variable assignments above in to a file (FILENAME) something like this:

PREFIX=/usr/home/USERNAME/usr/local \
INSTALLPRIVLIB=/usr/home/USERNAME/usr/local/lib/perl5 \
INSTALLSCRIPT=/usr/home/USERNAME/usr/local/bin \
INSTALLSITELIB=/usr/home/USERNAME/usr/local/lib/perl5/site_perl \
INSTALLBIN=/usr/home/USERNAME/usr/local/bin \
INSTALLMAN1DIR=/usr/home/USERNAME/usr/local/lib/perl5/man \
INSTALLMAN3DIR=/usr/home/USERNAME/usr/local/lib/perl5/man/man3

Then, each time you install a perl5 module you can use the following syntax:

% perl5 Makefile.PL `cat FILENAME

% make

% make test

% make install

% make clean

You also can have a few different local module installation procedures, for example one for production perl and another for development:

% perl5 Makefile.PL `cat FILENAME.production`

or

% perl5 Makefile.PL `cat FILENAME.development`

(2) Install the module from CPAN at your home directory
You should copy

   /usr/lib/perl5/5.6.1/CPAN/Config.pm

to

   /home/users/xytang/.cpan/CPAN/MyConfig.pm

And change the new MyConfig.pm so all references to /root/.cpan are
changed to /home/users/xytang/.cpan with your favourite editor.

Installing Perl5 Modules yourself on your Virtual Private Server can be a tricky
exercise. Utilities for installing Perl5 modules generally assume that the installation is being done in the root area of
the file system of the host machine. As a Virtual Private Server user you do not have access to the root area of the host
machine. So, you must install Perl5 modules locally, within your Virtual Private Server file system.

Check library dependence

Does any guru know how to exam the library dependency?
ldd 
/sbin/ldconfig - configure dynamic linker run time bindings
ld.so, ld-linux.so* - dynamic linker/loader

Hardware Abstraction Layer on Linux

Used in most operating systems to enable device drivers etc to be written more easily.

Under Linux there is a HAL daemon that allows easy userspace device management with UDev and D-BUS.

Clarification: Who Does What

• D-BUS is purely a channel for communication between different processes. It can be used for lots of purposes besides keeping track of system hardware.
• The job of HAL is to act as a dynamic central repository of information about the current hardware configuration. The structure of this repository is quite open-ended; in particular it is possible to attach any additional attributes you like to objects, by setting up appropriate rules in the HAL configuration. Other processes can register their interest with HAL, so that they get notifications (via D-BUS) of any configuration changes.

ain entries in the /dev directory, nothing more. As hardware is added, the appropriate device special files are created; as the hardware is removed, those files are deleted. What is done with those entries (e.g. automounting of removable drives) has to be handled elsewhere. You can customize the behaviour of udev by writing rules, so that, for instance, your USB flash drive always gets the same device name assigned, regardless of what other USB devices might or might be already plugged in.

Note that udev is part of the Linux kernel project, while HAL and D-BUS are not. Thus, udev knows nothing about HAL or D-BUS.

I think (but am not sure) that, in current Linux kernel versions, HAL and udev actually operate in parallel, independently of each other; they both receive notifications about hardware changes from the kernel, and perform their own individual actions in response.

A Simple Linux Firewall Script

The following shell script sets up a firewall, and stores it so that it is automatically loaded when computer boots. When you need to modify the firewall, just edit the script and run it again. The right moment to install a firewall is before computer is plugged to network for the first time. Simple per-host iptables firewall.

#!/bin/sh
# firewall.sh - Configurable per-host firewall for workstations and
# servers.(c) 2003 Tero Karvinen - tero karvinen at iki fi - GPL
# Cleanup old rules # All the time firewall is in a secure, closed state
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables --flush # Flush all rules, but keep policies
iptables --delete-chain
## Workstation Minimal firewall ###
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -A INPUT -i lo --source 127.0.0.1 --destination 127.0.0.1 -j ACCEPT
iptables -A INPUT -m state --state "ESTABLISHED,RELATED" -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
####### HOLES ####### Edit holes below, then run this script again
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT
#iptables -A INPUT -p tcp --dport http -j ACCEPT
#iptables -A INPUT -p tcp --dport https -j ACCEPT
##################### Edit above
iptables -A INPUT -j LOG -m limit --limit 40/minute
iptables -A INPUT -j DROP
# Save
iptables-save > /etc/sysconfig/iptables
echo ": Done."

#!/bin/sh
# firewall.sh - Configurable per-host firewall for workstations and
# servers.(c) 2003 Tero Karvinen - tero karvinen at iki fi - GPL
#
# Made into an init.d script by Torstein Krause Johansen

stop_fw()
{
   echo -n "stopping `basename $0`..."
   iptables --flush
   iptables --delete-chain
   iptables -P FORWARD ACCEPT
   iptables -P INPUT ACCEPT
   iptables -P OUTPUT ACCEPT
   echo "done."
}

start_fw()
{
   echo -n "starting `basename $0`..."
   # Cleanup old rules # All the time firewall is in a secure, closed state
   iptables -P INPUT DROP
   iptables -P FORWARD DROP
   iptables --flush        # Flush all rules, but keep policies
   iptables --delete-chain
   ## Workstation Minimal firewall ###
   iptables -P FORWARD DROP
   iptables -P INPUT DROP
   iptables -A INPUT -i lo --source 127.0.0.1 --destination 127.0.0.1 -j ACCEPT
   iptables -A INPUT -m state --state "ESTABLISHED,RELATED" -j ACCEPT
   iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
   iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
   iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
   iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
   ####### HOLES ####### Edit holes below, then run this script again
   iptables -A INPUT -p tcp --dport ssh -j ACCEPT
   iptables -A INPUT -p tcp --dport http -j ACCEPT
   iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
   ##################### Edit above
   iptables -A INPUT -j LOG -m limit --limit 40/minute
   iptables -A INPUT -j DROP
   # Save
   # iptables-save > /etc/sysconfig/iptables
   echo "done."
}

fw_status()
{
  iptables -L
}

case "$1" in
   start)
       start_fw
       ;;
   stop)
       stop_fw
 ;;
   status)
       fw_status
       ;;
   *)
       echo "Usage:" $0 "{start|stop|status}"
       exit 1
       ;;
esac

exit 0

"TCP Wrappers vs ipTable"
Written by Bart Eers
Wednesday, 12 January 2005
Most people are familiar with the term firewall and realize that it is a device or system that keeps unwanted people and data out of computer systems or networks. However, the word means slightly different things to different people. This can lead to difficulty when discussing the concept. If you ask home users whether they have a firewall, they will probably think first of a software program installed on their home computers, like BlackICE Defender or ZoneAlarm, referred to as personal firewalls. At most they might have a Linksys dedicated router/firewall. These utilities range in price from $50 to 100. Ask a small office network administrator about firewall, and the person will probably think of something like the NETGEAR or NetScreen router/firewall, or a stronger, dedicated router/firewall system running software like SmoothWall or Astaro Linux. These are often referred to as small office/home office (SOHO) firewalls and cost anywhere from $100 to a few hundred dollars. Meanwhile, if an enterprise security specialist is asked what firewall means, he or she will think more of the heavy-duty enterprise network firewall systems such as a Cisco PIX, Check Point, or SunScreen, costing hundreds to thousands of dollars.



The enterprise-level firewalls include heavy-duty network authentication, DMZ (demilitarized zone) functionality, and even intrusion prevention, antispam, and antivirus technology. As firewall technology improves, however, many of these features filter down to the smaller, cheaper firewall systems. For example, many SOHO and personal firewalls now offer Virtual Private Network support, Denial of Service protection, and stateful packet inspection (SPI). Now even Linux software firewall distros such as Astaro are including cutting-edge enterprise type functionality that only the big players had before.

Stateful packet inspection, or SPI, is the method used by most modern firewalls to determine whether incoming traffic is related to an existing protocol connection state, and thus if such incoming traffic is related and permitted through or new/unrelated and rejected by the firewall. The state is determined by the packet-level inspection of several protocol-centric variables as compared to previous incoming/related packet variables that are stored in a state table maintained by the firewall, which tracks said protocol-sensitive states (such as with FTP and NFS).

Firewall Theory

In the most general sense, firewalls look at incoming data packets, examine their source or destination addresses and ports, and make decisions about those packets based on a set of configured rules. Before you can set up a firewall, you must create these rules. To do so, you need to determine which services (or ports) on your network are required in or through your network, and should be left open, and which services or ports should be locked down.

In this section of the article, we describe the various ports and port ranges found on a standard Linux machine. If you have some port knowledge, consider reading this section anyway-port terminology and standard ranges have changed in the last few years and your basic understanding may be somewhat outdated.

Ports and the IP Stack

Every IP address has 65,535 ports associated with it. Ports are used to associate a network connection with a service and protocol running on a machine attached to a TCP/IP-based network. Ports are often described as windows or doors in an office building: if you want to see Person A, you open the door to Person A's office. In the same way, if you want to get a web page from a particular server with the http protocol, you request services through port 80 on that server.

In the past few years, port assignments on UNIX-based operating systems have changed from their original locations. Here is a list of current Red Hat-based Linux port assignments:

# Ports 0-1,023: The Well-Known or Reserved ports are standardized and controlled by IANA, the Internet Assigned Numbers Authority. These ports are generally used for standard incoming system and protocol interactions.
# Ports 1,024-49,151: The Registered ports are also used for incoming services, but are not regulated as strictly as the first 1,024 ports (remember, under UNIX, 0 counts as a number). These ports are controlled by community standards, not by dictated rules.
# Ports 32,768-61,000: These Ephemeral or Dynamic port assignments are specific to the Linux 2.4 kernel, but can very by distro. They are used by outgoing client requests and programs to establish connections with other servers. On some systems, Ephemeral ports range up to 65,535. You can see this kernel setting on your Linux 2.4 kernel by looking at the kernel's proc filesystem


# cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000


You may have noticed the overlap of ports from 32,768 to 49,151. This is not particularly critical to the average Linux administrator, and is a legacy issue that is documented in RFC's and in IANA's own internal documentation. It does not affect regular Linux use in any significant way. The more of these Dynamic or Ephemeral ports that you open for use, the more simultaneous outgoing connections your server can make. This keeps busy servers from fighting over limited outgoing server resources, and on such servers the additional ~24k outgoing ports can speed things up a bit (when talking about max outgoing connections per second such as a large mail server).

IANA is the regulatory group that controls IP address allocations, top-level domains, port assignments below 1,024, and other Internet-related public standards. The IANA port list (www.iana.org/assignments/port-numbers) shows both the regulated Reserved or Well-Known ports, as well as a list of industry common Registered ports.

Port Assignments

To see the human-readable service names that your server associates with port numbers, look the /etc/services file. This file lists the most commonly used ports and the protocols or programs associated with each one. For example, this command's output lists the TCP ports associated with several common Internet protocols:

$ cat /etc/services | grep -e ^http -e ^ftp -e ^ssh|grep tcp
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
http 80/tcp www www-http # WorldWideWeb HTTP
https 443/tcp # Mcom

If you'd like to see the daemons that are currently bound to your various IP addresses by a specific service name, instead of simply the number or the port, issue this command and use grep to look at the one service that you're interested in:

$ netstat -at|grep "http "
tcp 0 0 *:http *:* LISTEN

Leave off the grep to see all such bindings.

TCP/IP Packet Structures

With a basic understanding of port allocation under your belt, take a closer look at TCP and IP packet structures.

When on a TCP/IP-based network, each packet you send out has either a TCP packet wrapped or encapsulated in an IP datagram, or a UDP packet wrapped in an IP datagram. The former is a TCP/IP packet and the latter is called a UDP/IP datagram. You look at the information contained in a TCP/IP packet (in most of our examples in this article) to determine where the packet came from, where it's going, and what protocols are being used or requested. This is the very nitty-gritty nature of TCP/IP firewalling. But before we can get much further into this discussion, we need to take a quick peek inside these data structures to speak intelligently about how we're using this information.

These TCP and IP structures can be used in various ways to trigger on and control the different types of traffic that flow across your network or into/out of your server.

If you plan to take full advantage of these packet-level mechanisms, you'll want to use the iptables form of Linux firewalling rules as opposed to the older, less powerful TCP wrappers-which is really more of a service/host ACL than a real firewall control system

TCP and IP structures are defined by RFC 793 and RFC 791. The basic layout for TCP looks like this:


TCP Header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Reading from left to right you will see the packets that actually get transmitted across the wire.

Although there is a great deal of information in this TCP packet diagram, the easiest elements to identify and use from a firewalling perspective are probably the TCP packet's source and destination ports. In short, this identifies what protocols are being used or requested. Also, when setting up firewall rules and allowing or denying access to services (remember, services = ports), you might want to use the sequence number to track session-based protocols. This idea of session and protocol tracking is the basis for SPI or session tracking for bidirectional transfer protocols like FTP or NFS. Doing session tracking is pretty much automatic in iptables after you enable it.

In the IP structure, as shown following, you'll also want to be able to trigger on the IP source and destination addresses (who it's coming from and who it's going to). Triggering on and allowing or denying access based on these addresses (as well as the attributes we already covered) is, in essence, what firewalling is all about.

Let's take a closer look at the IP datagram structure and see what useful information firewall administrators would use from this low-level protocol. The IP datagram looks like this


IP Datagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version| IHL |Type of Service | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification | Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The main aspects of the IP datagram interesting to the firewall administrator are source and destination addresses and the protocol. These elements are important for both TCP wrappers and iptables-based firewalls. However, some of the other fields are useful when setting up a dual-homed firewall with NAT and masquerading, such as TTL (as described in the following section).

Firewalls in Action

No matter how complex the firewall is, in its most simple form, a firewall allows and disallows access to specific services based on host addresses, networks, or other such trigger criteria.

If the services that you want to allow or disallow access to are running on a server connected to a trusted network or LAN, you can use either TCP wrappers or iptables to set up your local server-side service access control (personal firewall). That said, TCP wrappers is really not considered to be a true hardened firewall grade form of access control because incoming data is allowed past the networking stack into what's called user space. This is where many Internet worms and attacks are launched to strike, and this in turn means that you can still be cracked if your TCP wrappers-based system is attacked with a known TCP wrappers exploit. Armed with this knowledge, if you have a single server on an untrusted network or directly on the Internet and you wish to run a serious single host-based firewall configuration, iptables should be your only real choice for a real firewall.

If you're already on a secure network and you just want to allow/disallow services to various IP addresses, hosts, or networks within your network, then TCP wrappers might be easier for you to use.

As you read more about firewalls, you will come across the terms trusted and untrusted interfaces. These terms are used in relation to network and security boundaries. A dual-homed (or two network card) firewall is usually placed between a trusted and an untrusted network, and so the two interfaces on the firewall that physically connect to these networks get their names accordingly. If you have a trusted network interface (for example, eth0) and an untrusted network interface (such as eth1), you need to use iptables (along with ip forwarding) to control network access through your firewall from one interface to the other.

Linux Firewall Mechanisms

Most Linux distributions, including Fedora Core, provide two forms of service access control: TCP wrappers and iptables. I use the term access control and not firewalling because TCP wrappers should really not be referred to as a firewall per se. The older TCP wrappers offers centralized daemon host access control in one nice and easy to edit file. It can be configured to monitor incoming requests for a range of daemons, works in tandem with xinetd, and changes to it are instantly applied. TCP wrappers is somewhat insecure if used on an untrusted network, is not very powerful, and so should only really be used on trusted networks or where very specific requirements demand it. iptables is the newer Linux form of true firewalling. Its technology is generally referred to as netfilter, as it exists on several OS platforms. iptables itself is a packet/kernel-level, system-wide, user space control system that allows control of the real-time network filter rule sets in the running kernel. These rules allow for multinetwork SPI, control, modification, and redirection. It is much more powerful than TCP wrappers, but can also be more complex to use. It can be used on trusted or untrusted networks and so makes a perfect multihome, multinetwork firewall/router solution.

As the network client requests come in through the network card, they encounter the iptables portion of the kernel. In Red Hat and Fedora Core systems, this config is controlled from the /etc/sysconfig/iptables file. If the clients pass these tables of filters and rule-chains, they then pass through to the TCP wrappers level of the system, assuming that the requested daemon is compiled with TCP wrapper's libwrap support. If the service or daemon has libwrap support compiled in, and thus can even be controlled by TCP wrappers, TCP wrappers then allows the client requests to pass or blocks them per the allow/deny files. The final layer of network client restriction is sometimes configurable by the daemon via the daemon's own internal configuration file (for example, Apache = httpd.conf and FTP = vsftpd.conf). These last two levels of TCP wrappers and daemon level config file service security are not considered true firewall quality forms of network protection, but are usually just used as a convenient way for an administrator to allow or deny daemon-level access on a trusted network. Although many administrators sometimes use wrappers and deamon config allow/deny settings on untrusted networks (such as the Internet), such configurations are not recommended. These older and less secure forms of access control only form a quick and easy service/host access system for trusted networks and should really not be considered a real firewall

TCP Wrappers

As previously stated, TCP wrappers does not actually function as a firewall. Instead, it is a simple and effective application-level daemon wrapper. TCP wrappers is a set of libraries that xinet.d and other daemons are compiled against. Among other things, it lets you form simple service/host-based access control lists (ACLs) based rule sets that control which hosts or networks are allowed to access your various daemons. Daemons that are compiled against the libwrap library like this can then be controlled through the host access control files /etc/hosts.allow and /etc/hosts.deny.

Several, but not all, of the network daemons in Fedora Core and other Linux distributions are already compiled against libwrap. To determine which of your daemons have libwrap support, locate them with the following command:


# egrep libwrap /sbin/* /usr/sbin/*| sort
Binary file /usr/sbin/in.tftpd matches
Binary file /usr/sbin/mailstats matches
Binary file /usr/sbin/makemap matches
Binary file /usr/sbin/praliases matches
Binary file /usr/sbin/rpc.rquotad matches
Binary file /usr/sbin/sendmail.sendmail matches
Binary file /usr/sbin/smrsh matches
Binary file /usr/sbin/snmpd matches
Binary file /usr/sbin/snmptrapd matches
Binary file /usr/sbin/sshd matches
Binary file /usr/sbin/stunnel matches
Binary file /usr/sbin/vsftpd matches
Binary file /usr/sbin/xinetd matches


Because they have libwrap support, these daemons should be able to be controlled through the /etc/hosts.allow and /etc/hosts.deny files.

Is TCP wrappers the appropriate service solution for you? If you're running a services-based server (from which services are being offered) on a trusted network, and all of your running daemons use libwrap, and you're already protected by a full-blown internetwork firewall, then TCP wrappers can be a quick and simple way for you to control which machines and networks have access to services on your server. If you need more security on your services-based server, more feature-rich or complex firewalling rules like session tracking, or stateful inspection, or you're running a network firewall in a multiple network card (multi-home) NAT configuration, then you definitely need the strength of iptables.

Remember, if you're just running a basic FTP or sendmail mail relay server or the like, then TCP wrappers can be used if you're on a trusted network. But a true firewall cannot, nor can it be used to limit access through a network firewall.

iptables

iptables is essentially the fourth generation of a packet filter system for the Linux kernel called netfilter. Packet filtering was originally released on BSD via ipfw and was integrated into the Linux kernel in version 2.0. When the 2.2 version of the Linux kernel was released, packet filtering was controlled by a user-space tool, ipchains. With the 2.4 and newer kernels, we have the modern iptables tool and related kernel modules that offer complete control over almost every piece of network data that comes into or leaves our networks.

To summarize, iptables is a stateful packet network control, filtering, modification, and redirection system that is one of the more advanced and readily available implementations of netfilter available today. Plus, it's free. Unfortunately, iptables can be somewhat difficult to learn for the uninitiated, or for those who do not have a firm grip on the packet-level operations of networking protocols, especially so if you want to control iptables manually via flat configuration files or scripts rather than via a graphical tool. Some people find it easier to use such graphical control tools to do stuff, then look at the iptable config output, and learn the inner workings of iptables this way, while others prefer to just dive right into the command line syntax. In this article we mainly use the command line approach, but feel free to download one of the graphic tools discussed later and check out the GUI approach.

At its most basic level, a packet filter is a program that scans network traffic as it flows through the system and then makes decisions about each packet. Based on the filters or rule tables that the administrator configures, iptables can DROP (discard) or ACCEPT a given packet. In addition, iptables offers more sophisticated tools like Network Address Translation, masquerading, and the ability to forward packets to other machines or networks. This is why Linux and iptables is such a perfect fit for high-powered firewall configurations, and why we're starting to see this combination secretly appear in several commercial and SOHO firewall products such as the SnapGear PCI635 (www.cyberguard.com/snapgear/pci635.html), theProWall (www.protectix.com/prowallspecs.html), and others. It's powerful, small, and cheap.

If simply using raw iptables isn't functionally enough for you, you can add other Open Source firewall GUI tool solutions atop the system to increase your Linux firewall's flexibility and ease of use. You can either go the enterprise route and pay for full-featured commercial firewall distros/tools and get enterprise-level support contracts (such as with some CD bootable firewall distros). However, if you're looking for a free or noncommercial solution, you can download free, Open Source "bolt-on" firewall GUI tools that will transform your raw, hand-crafted iptables rule creation into a to sleek, web-based, secure, iptable-firewall enterprise network/router firewall appliance.

For the latter, there are a number of streamlined commercial-grade, but free iptables configuration graphical tools available at little or no cost, such as SmoothWall Express or Guarddog, These packages are called firewall tools and run on top of your Linux/iptables installation. We introduce some of these programs, including CD-bootable firewalls.

Anyone with a machine or network that interacts with the Internet should have a firewall in place. Firewalls block unwanted or unknown traffic while letting legitimate packets gain access to valid services or systems.

At Last

Under Linux, there are three ways of controlling service access by hosts or networks: iptables, TCP wrappers, or individual daemon config settings. The first is the only method that can both be considered a truly hardened method of limiting service access on an untrusted network (personal firewall) and be used in either a stand-alone server or a full-blown network firewall configuration. It can be difficult to master, but there are various GUI tools to assist you in this journey. The other two methods of service access control are good for trusted networks and setting up quick departmental restrictions to various services on stand-alone server installs, but technically cannot be classified as firewalling.

Just remember three important points:

# The more ports you open up in a firewall, the less secure your system is.

# To be truly effective, firewalls and external security systems must be built on top of systems that already have best practice foundational security elements in place.

# Security that you don't both fully understand and fully control is just an illusion

Resources

TCP/IP resources

Daryl's TCP/IP Primer
www.ipprimer.com/section.cfm

TCP: RFC793
www.faqs.org/rfcs/rfc793.html

IP: RFC791
www.faqs.org/rfcs/rfc791.html

Linux Firewall and Proxy Server HOWTO
www.tldp.org/HOWTO/Firewall-HOWTO.html

Article By Stanley (c) 2005