[Top bar]
[Bottom bar]
This document is available in: English  Castellano  ChineseBig5  Deutsch  Francais  Nederlands  Portugues  Russian  Korean  

[Photo of the Author]
by Javi Polo
<javipolo(at)infomail.lacaixa.es>

About the author:
I am 18 and a suffering high-school student with Catalan pending for September. My passion is computer science, I hope be admitted at UIB to start a minor in Telecomunications Engineering and a major in Computer Science. I like hardcore music and I participate in a band named Niko-Chan's Kingdom. Besides this not much else to say, I have a great girlfriend called Xiska 0:)

Translated to English by:
Miguel Angel Sepulveda <sepulveda(at)linuxfocus.org>

 

TCPD and Firewalls using IPFWADM

[Ilustration]

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.

For example, the line:
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.

The format for both files is:
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

Now the wildcards are:
ALL stands for any possible value allowed in the entry
LOCAL coincides with any name without a ^Ó.^Ô
UNKNOWN stands for any machine whose name or IP address is unknown
KNOWN stands for any machine whose name and IP address are both known
PARANOID represents those machines whose name does not coincide with its IP address
The options available are:

allow means that a connection must be allowed to whatever matches the entry regardless of the contents of the files hosts.allow and hosts.deny. This option should be the last to appear in the line.
deny analogous to the previous option except that it denies the connection.
spawn launches a shell command when a connection request is received, for instance I like to execute a beep sound each time someone attemps a connection from outside into my machine
twist this is similar to the spawn option except that the connection is interrupted upon completion of the shell command. This option must also be the last one on the entry line.

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

%a address of the client machine
%c information about the client (it might be user@machine, or something else according to the client)
%d name of the daemon
%h name or IP address for the client provided it is available
%n name of the client
%p PID of the daemon
%s information about the server (daemon@machine or only daemon, it depends)
%u name of the client user
%% this is just a % character

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...

Examples:
#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.

Next let us pass to discuss the tool IPFWADM

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:

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

The options for these parameters are:

The 'important' parameters are:

-P specifies the protocol on which the list of rules apply. Protocols might be TCP, UDP, ICMP or all (to indicate any protocol)
-S specifies the origin address of the packet. The format is: ADDRESS[/MASK][PORT]   For example, a valid address would be 123.32.34.0/255.255.255.250 25 which stands for the IP range from 123.32.34.0 to 123.32.34.5
-D specifies the destination address and it follows the same format as -S

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

ipfwadm -I -i a -S 127.0.0.1

and to deny packets coming from 123.34.22.XXX :

ipfwadm -I -a d -S 123.34.22.0/255.255.255.0

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

ipfwadm -I -a a -P tcp -S 111.222.123.221 139
ipfwadm -I -a d -P tcp -D 0.0.0.0/0 139

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


Webpages maintained by the LinuxFocus Editor team
© Javi Polo, FDL
LinuxFocus.org
Translation information:
es --> -- : Javi Polo <javipolo(at)infomail.lacaixa.es>
es --> en: Miguel Angel Sepulveda <sepulveda(at)linuxfocus.org>

2002-10-22, generated by lfparser version 2.32