TCPD and Firewalls using IPFWADM

Abstract: This article describes very briefly how to configure the inetd services in order to improve security on your system. We concentrate in the of the tool IPFWADM to administer and configure inetd services.

To begin we must have clear what inetd is. Basically inetd is a daemon that controls the services provided by the system to hosts connected through the network. It is possible that inetd is not configured in a given system to control all the services by default, so the first thing to do is go to /etc/inetd.conf and check what services are currently under its control (lines without the "#" character at the beginning of the line). The first piece of good advice to follow is not to activate more services than those we really need to, it is the best way to prevent attacks through bugs in daemons we never use. I assume the reader has a copy of his inetd.conf file at hand, so let me explain a few things about what it means.

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a

The first word is the name of the service offered (in this case "ftp", and we can next check in the file /etc/services to what port it is connected).

The second field is the type of socket opened, these can be: stream (like in the example), dgram, raw, rdm and seqpacket.

Next field is the protocol to be used. It must be declared in the file /etc/protocols, like in our first example where TCP protocol should be already declared in this file.

After the protocol comes the field wait/nowait. It should always be nowait except for datagram (dgram) type sockets. For the last type of sockets we must indicate nowait if the server supports multiple threads or wait if the server only supports a single thread. The reason is that for multithreaded systems when the server receives a request it launches a new process, then it frees the sockect so that inetd can continue to listen for further requests, therefore using nowait. In case of single threaded system we must indicate wait because the server always attends to the same socket and can not launch connections in separate processes. Furthermore there is one more variation, we could have written nowait.50 -- meaning 50 is the maximum number of daemons that can be launched (or requests that can be accepted, according to the point of view) in one minute. The default is 40.

The fifth field indicates the name of the user under which the daemon runs, in this example ftp runs under userid root.

The sixth and succesive fields are the programs launched followed by the parameters passed to the program. In the example given, the daemon tcpd is launched and as arguments the daemon in.ftpd and the parameters -l -a. Here comes the most interesting part of this section, the issue of TCPD.

Well tcpd is a daemon that filters requests, and does one or another thing according to the daemon to be launched as a response to the IP address requesting the service. These decisions are based on the configuration files /etc/hosts.allow and /etc/hosts.deny

In principle /etc/hosts.deny is used to indicate who is denied services in the server and /etc/hosts.allow to indicate who is allowed access to services.

DAEMON: IP[: OPTION1 [: OPTION2 ]]

where DAEMON can be the daemon to launch, like in the example given in.ftpd, or it can also be the predefined constant ALL, which refers to all daemons.

IP may be either a specific IP, a URL, a range of IPs (or URLs), or it can include any of the wildcards that I will discuss in a moment.

In order to specify a range of IP addresses, for example we can write: `123.32.' This notation represents all IPs of the form 123.32.XXX.XXX; similary a range of URLs can be specified as say `.ml.org' which represents all subdomains of ml.org

A more traditional form of specifying a range of IPs is as IP/MASK. In this fashion, for instance the range 127.0.0.0 to 127.0.255.255 is specified as 127.0.0.0/255.255.0.0

The last two options allow the use of the expansion characters proper to tcpd, these are:

With these expansions and the last options you can do many things already, for example I know of someone who sends a teardrops automatically whenever someone attemps to enter via telnet to his system :)

NOTE: A teardrop is a DoS (Denial of Service, an attack to provoke a reboot or reinitialization of the system). It is based in a bug in the defragmentation of TCP packets that most Operating Systems have (or rather had since most kernels have been patched against it already) Information sent through the InterNet uses the protocol TCP/IP ( this protocol is also in other type of networks, like for example intranets), these are actually two protocols: TCP takes care of fragmenting the information into packets and the passing it to the IP protocol which sends it to the destination machine; once it reaches the other site the TCP protocol checks that all the packets are there and re-assembles them to recover the original information. Well the mentioned attack (and many based on it) exploits the fact that many Operating Systems do not check whether the packets before defragmentation are too small, if they are the machine becomes confused at the time of putting them together. Obviously I am not completely sure of the full explanation here so any kind of critics or advise are welcome. Well after this short explanation let us go on...

#hosts.allow 

ALL: 127.0.0.1 # Allows localhost to enter for everything

in.ftpd: ALL: spawn (wavplay /usr/share/sounds/intruder.wav & )
# lets anyone enter via ftp, but it launches a
# wav sound (so that I get an alert)

in.telnetd:  ALL: twist ( teardrop %h %h )
# send a teardrop back to anyone who
# tries to enter via telnet

#fin

#hosts.deny

ALL: `.bsa.org'   # it forbids entrance to anyone from the domain bsa.org

in.fingerd: ALL	  # The fingerd service is denied for all :)

#fin

This is all what I have to say about tcpd, I already mentioned by knowledge was not great. My recommendation is to try and experiment with several configurations and read the manual pages ( tcpd, host_access(5) ), I am sure the reader will learn much more from them than I can teach.

A first requisite is to have IP Firewalling support in the Kernel ( Networking -> Network firewalls + IP: firewalling ). Then, after compilation and reinitialization of the system we are ready to use this tool.

IPFWADM let us manage the entry and exit of TCP, UDP and ICMP packets among other things (these applications are the only ones I will discuss in this article). In short the administrator can establish what packets are allow to enter, even specifying from which IP or IP range of addresses, in which specific port they should be allowed, with what specific protocol and all possible combinations of these possibilities... Similarly we have the same degree of administrative control over outgoing packets.

ipfwadm has several main parameters:

• -A specifies the accounting rules
• -I specifies the rules for incoming packets
• -O specifies the rules for outgoing packets
• -F specifies forwarding rules for packets
• -M is for the administration of the IP masquareding

In this article I will only discuss the parameters -I and -O. Both follow the same sintax.

• -a adds one or more rules to the end of the list
• -i adds one or more rules to the beginning of the list
• -d deletes one or more rules from the list
• -l shows the rules on the list
• -f deletes all rules from the list
• -p to indicate if the packets must be acceppted (a), denied (d) or rejected (r)
• -c checks what set of rules would be followed by a packet
• -h help

Basically these are all the fundamental parameters, therefore to allow all frames from my system to reach my own system I add the rule:

and to deny packets coming from 123.34.22.XXX :

then if I want to deny ANY access to the netbios port, except for the IP 111.222.123.221:

Well I think this will be all my article, a bit poor but by knowledge is also limited O:)

Translated by Miguel Angel Sepulveda