Once the GNU/Linux kernel has loaded, it executes the init command, which, in turn, reads the configuration file /etc/inittab and begins the start up process. Generally, the inittab has sequences such as: si::sysinit: /etc/init.d/boot, which represents the name of the commands file (script) that controls the booting sequences. Generally, this script calls the other scripts, which include the network startup script.
Example 6-10. Example
In Debian, etc/init.d/network is executed to configure the network interface, depending on the boot level; For example, in boot level 2, all the S* files in directory /etc/rc2.d (which are links to the /etc/initd directory) will execute, and on the boot down level, all the K* files in the same directory. In this way, the script is only there once (/etc/init.d) and, depending on the services required in that status, a link is created in the directory corresponding to the node-status.
The network devices are created automatically when the corresponding hardware starts up. For example, the Ethernet driver creates the eth[0..n] interfaces sequentially, when the corresponding hardware is located.
The network interface may be configured as of that moment, which requires two steps: assign the network address to the device and boot the network parameters to the system. The command used for this is ifconfig (interface configure). An example might be:
ifconfig eth0 192.168.110.23 netmask 255.255.255.0 up
Which indicates that the eth0 device should be configured with IP address 192.168.110.23 and netmask 255.255.255.0. Up indicates that the interface will be activated (to deactivate it, execute ifconfig eth0 down). If no values are specified, the command assumes that the default values should be used. In the previous example the kernel will configure this machine as a C-Type machine with IP=192.168.110.23 and the broadcast address=192.168.110.255.
There are commands, such as ifup and ifdown, that make it possible to configure/unconfigure the network more simply using the /etc/network/interfaces file to obtain all the necessary parameters (consult man interfaces for syntax).
In Debian, there is another simpler method for configuring the network (considered high-level), which uses the abovementioned commands ifup, ifdownand the /etc/network/interfaces file. If we decide to use these commands, we should not configure the network at low-level, as these commands are sufficient for configuring/unconfiguring the network.
In order to modify the parameters of the eth0 interface network, we can (consult man interfaces in section 5 of the Unix manual included with the operating system for more information):
Let us suppose that we wish to configure an eth0 interface in Debian, which has a fixed IP address 192.168.0.123 and has 192.168.0.1 as the gateway. We must edit /etc/network/interfaces so that it includes a section such as:
iface eth0 inet static address 192.168.0.123 netmask 255.255.255.0 gateway 192.168.0.1
If we have installed the resolvconf packet, we can add lines to specify the DNS information. For example:
iface eth0 inet static address 192.168.0.123 netmask 255.255.255.0
gateway 192.168.0.1 dns-search remix.org dns-nameservers 220.127.116.11 18.104.22.168
After the interface has been activated, the command line arguments of the options dns-search and dns-nameservers are available for resolvconf for inclusion in resolv.conf. The command line argument remix.org of the dns-search option corresponds to the argument of the search option in resolv.conf (we will look at this in more detail later) and the arguments 22.214.171.124 and 126.96.36.199 of the dns-nameservers option corresponds to the arguments of the nameserver options in resolv.conf (consult man resolv.conf). It is also possible to configure the network at low-level through the ip command (which is equivalent to ifconfig and route). Although this command is much more versatile and powerful (it can be used to establish tunnels, alternate routings etc.), it is more complex and it is recommendable to use the preceding procedures for basic network configurations.
Red Hat and Fedora use a different file structure for network configuration: /etc/sysconfig/network. For example, to configure the network statically:
To configure using DHCP, it is necessary to delete the GATEWAY line, as it will be assigned by the server. And if NIS is to be incorporated, a line with the server domain must be added: NISDOMAIN=NISProject1
To configure interface eth0 in the file
|ONBOOT=yes Activates the network on boot.|
|From FC3 on, it is also possible to add:|
Or else, for configuring using DHCP :
To disable DCHP, change BOOTPROTO=dhcp to BOOTPROTO=none. Any change in these files must restart the services with service network restart (or, otherwise, /etc/init.d/network restart).
The following three steps must be taken to change the hostname:
1) Command hostname new-name.
2) Change the network configuration in /etc/sysconfig/network editing HOSTNAME=new-name.
3) Restoring all the services (or rebooting):
•service network restart(or executing /etc/init.d/network restart) • Restarting the desktop by passing into console modeinit 3and changing to GUI modeinit 5.
Verifying if the name is not registered in /etc/hosts. The hostname may be changed during execution time with sysctl -w kernel.hostname="new-name".
In order to configure Wi-Fi interfaces, we basically use the wireless-tools package (as well as ifconfig or ip). This package uses the iwconfig command to configure a wireless interface, but this can also be carried out through /etc/network/interfaces.
Example 6-12. Example: Configure WiFi in Debian Sarge (Etch) (similar in FC6)
Let's assume that we wish to configure an Intel Pro/Wireless 2200BG wireless network card (very common in many laptops, such as Dell, HP...). The software that controls the cards is usually divided into two parts: the software module that will be loaded in the kernel through the modprobe command and the firmware that is the code that will be loaded in the card and which is given to us by the manufacturer (consult the Intel site for this model). As we are discussing modules, it is interesting to use the Debian module-assistant package which allows us to create and install a module easily (another option would be to install the sources and create the corresponding module). We will compile and install the software (which we can find on the manufacturers' website and is called ipw2200) using the m-a command in the module-assistant package.
aptget install module-assistant (install the package) m-a -t update m-a -t -f get ipw2200 m-a -t -build ipw2200 m-a -t install ipw2200
We can download the compatible firmware version from the site address provided by the manufacturer (in the product documentation) along with the version of the driver we need, which in our case, would be driver version 1.8 and firmware version 2.0.4, obtained from the following address:
We should then decompress and install the firmware:
tar xzvf ipw2200fw2.4.tgz C /tmp/fwr/ cp /tmp/fwr/*.fw /usr/lib/hotplug/firmware/
This will copy three packages (ipw2200-bss.fw, ipw2200-ibss.fw and ipw2200-sniffer.fw). The module is then loaded with: modprobe ipw2200, the system reboots and then, from the console, we can execute the dmesg | grep ipw command, which will show us some lines similar to the ones below and which indicate that the module is loading (this can be checked with lsmod):
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git1.0.8 ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection ...
We should then download the wireless tools package that contains iwconfig in order to install wireless tools with aptget, among others, and if we execute iwconfig, something similar to the following will display:
eth1 IEEE 802.11b ESSID:"Name-of-the-Wifi" Mode:Managed Frequency:2.437 GHz Access Point:00:0E:38:84:C8:72 Bit Rate=11 Mb/s TxPower=20 dBm Security mode:open ...
We must then configure the network file, for example, gedit /etc/network/interfaces, and add the eth1 wifi interface, for example:
iface eth1 inet dhcp pre-up iwconfig eth1 essid "Name of the Wifi" pre-up iwconfig eth1 key open XXXXXXXXXX
The pre-up lines execute the iwconfig command before activating the interface. This configuration is used if we wish to use the service in DHCP mode (automatic IP assignation, as we shall see). Instead of DHCP, the word static should be used and the following lines, as an example, must be entered (as in a cable card):
address 192.168.1.132 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.1.1
Another method for configuring the interface is:
iface eth1 inet dhcp wireless-essid "Name of the Wifi" wireless-key 123456789e
We can then start up the network with ifup eth1 and we will be given information on the connection and the state and quality of reception. In order to scan the available WiFi networks (access points), we can use iwlist scan, which will show us information on the available networks, and if we want to connect to a different network, we can use the iwconfig command to change the network or Access Point.
The next step is to configure the name resolver, which changes names like pirulo.remix.com to 192.168.110.23. The /etc/resolv.conf file is used for this. The format is very simple (one line of text per sentence). There are three key words for this purpose: domain (local domain), search (list of alternate domains) and name server (IP address of the domain name server).
Example 6-13. Example of /etc/resolv.conf
domain remix.com search remix.com piru.com name server 192.168.110.1 name server 192.168.110.65
This list of name servers often depends on the network environment, which may change depending on where the machine is or where it is connected. The programs for connecting to telephone lines (pppd) or obtaining IP addresses automatically (dhclient) can modify resolv.conf to insert or delete servers; but these characteristics do not always work properly and they can sometimes generate conflicts or incorrect configurations. The resolvconf package adequately solves the problem and allows us to configure the name servers easily and dynamically. resolvconf is designed to work without the user having to configure anything manually; however, the package is quite new and may require some manual assistance to make it work properly. For more information:
Another important file is /etc/host.conf, which can be used to configure the behaviour of the name resolver. This file is very important because it indicates where the node address or name is first resolved. This can be consulted in the DNS server or the local tables within the existing machine (/etc/hosts).
This configuration indicates that /etc/hosts should be verified first consulting the DNS and it also indicates (2nd line) that all valid addresses found in /etc/hosts should be returned. Consequently, the /etc/hosts file is where the local addresses are placed and it can also be used to access the nodes without having to consult the DNS.
The consulting process is much faster, but the disadvantage is that, if the node changes, the address will be incorrect. In a system that is properly configured, only the local node and an input for the loopback interface should appear.
Example 6-15. Example of /etc/hosts
127.0.0.1 localhost loopback 192.168.1.2 pirulo.remix.com pirulo
Aliases may be used for the name of a machine; this means that this machine may have different names for the same IP address. The loopback interface is a special type of interface that makes it possible for a node to connect to itself (for example, to verify that the network subsystem is working without accessing the net). By default, the IP address 127.0.0.1 has specifically been assigned to the loopback (a telnet 127.0.0.1 command will connect with the same machine). Configuring aliases is very easy (generally, the network startup script configures them).
In version 2 of the GNU library, there is an important replacement with regard to the functions of the host.conf. file. This improvement includes the centralisation of information on different services for name resolution, which provides many advantages for the network administrator. All the information on name and service consultations has been centralised in the /etc/nsswitch.conf file, which allows the administrator to configure the order and the databases in a very simple manner. In this file, each service appears, one per line, with a set of options, such as the node name resolution option. This indicates that the order for consulting the databases for obtaining the node's IP or its name will be first through the DNS service (which uses the /etc/resolv.conf file to determine the IP of the DNS node) and then, if it cannot be obtained here, the databases of the local (/etc/hosts) will be used. Other options for this could be nis or nisplus, which are other information services that are explained in subsequent units. The method for each consultation may also be controlled through actions (between ), for example:
hosts: xfn nisplus dns [NOTFOUND = return] files
This indicates that, when the DNS is consulted, if there is no registry for this consultation, the program that made the consultation will return a zero. The '!' may be used to deny the action, for example:
hosts dns [!UNAVAIL = return] files
Another aspect that has to be configured is the routing. Although the process is considered to be very complex, in general, the routing requirements are very simple. In a node with multiple connections, routing consists of deciding where to send and what to receive. A simple node (one single network connection) also needs routing, given that all the nodes have a loopback and a network connection (for example, Ethernet, PPP, SLIP...). As we have explained, there is a table known as a routing table that contains rows with various fields, three of which are especially important: destination address, interface through which the message will be sent and IP address, which will take the next step in the gateway.
The route command can be used to modify this table so as to carry out the appropriate routing tasks. When a message arrives, the destination address is examined, compared with the entries in the table and sent through the interface with the address that most resembles the packet's destination. If a gateway is specified, it is sent to the appropriate interface.
Let us assume, for example, that our node is in a C class network with the address 192.168.110.0 and the address is 192.168.110.23; and the router connected to the Internet is 192.168.110.3. The configuration will be:
First, the interface:
ifconfig eth0 192.168.110.23 netmask 255.255.255.0 up
Subsequently, indicate that all the datagrams for nodes with 192.168.0.* addresses must be sent to the network device:
route add -net 192.1 ethernetmask 255.255.255.0 eth0
-net indicates that it is a network route but -host 192.168.110.3. may also be used. This configuration will allow it to connect with all the nodes within a network segment (192.1), but, what would happen if we wanted to connect with another node outside this segment? It would be very difficult to have all the appropriate entries for all the machines to which we wish to connect. To simplify this task, we have the default route, which is used when the destination address does not match any of the entries in the table. One configuration possibility would be:
route add default gw 192.168.110.3 eth0
(the gw is the IP or name of a gateway or router node).
Another method of doing this would be:
ifconfig eth0 inet down disable the interface ifconfig lo Link encap:Local Loopback ... (no entries for eth0 will appear) route ... (no entry in the routing table will appear)
Subsequently, the interface is enabled with another IP and a new route:
ifconfig eth0 inet up 192.168.0.111 \ netmask 255.255.0.0 broadcast 192.168.255.255 route add -net 10.0.0.0 netmask 255.0.0.0 \ gw 192.168.0.1 dev eth0
The bar (\) indicates that the command continues on the following line. The result:
ifconfig eth0 Link encap:Ethernet HWaddr 08:00:46:7A:02:B0 inet addr:192.168.0.111 Bcast: 192.168.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ... lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 ... route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.0.0 U 0 0 0 eth0 10.0.0.0 192.168.0.1 255.0.0.0 UG 0 0 0 eth0
For more information, see the ifconfig (8) and route (8) commands.
The next step in the configuration of the network is to configure the servers and services that will allow another user to access the local machine or its services. The server programs will use the ports to listen to the requests from the clients, which will be sent to this service as IP:port. The servers may work in two different ways: standalone (in which the service listens to the assigned port and is always active) or through inetd.
The inetd is a server that controls and manages the network connections of the services specified in the /etc/inetd.conf file, which, when a service request is made, starts up the appropriate server and transfers the request.
Two important files must be configured: /etc/services and /etc/inetd.conf. In the first file, we associate the services, the ports and the protocol, and in the second, the server programs that will respond to a request to a determined port. The /etc/services format is name port/protocol aliases, where the first field is the service name, the second is the port where the service is attended and the protocol that it uses, and the next field is an alias of the name. There is a series of default pre-configured services. We will now show an example of /etc/services (# indicates that what follows is a comment):
The /etc/inetd.conf file is the configuration for the master network service (inetd server daemon). Each line contains seven fields separated by spaces: service socket_type proto flags user server_path server_args, where service is the service described in the first column in /etc/services, socket_type is the type of socket (possible values are stream, dgram, raw, rdm, or seqpacket), proto is the protocol that is valid for this input (it must match that in /etc/services), flags indicates the action that should be taken when there is a new connection on a service that is attending another connection, (wait tells inetd not to start up a new server or nowait means that inetd must start up a new server). user will be the local user-name with which the client that has started up the service is identified, server_path is the directory where the server is located and server_args are possible arguments that will be passed to the server. An example of some /etc/inetd.conf lines is (# is a comment, so if a service has # before the name, it means that it is not available):
|telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd|
|ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd|
|# fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd|
|shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd|
|login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind|
|# exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd...|
As of Debian Woody 3.0 r1, the inetd function has been replaced by xinetd (recommendable), which needs the /etc/xinetd.conf configuration file (see end of unit). If we wish to start up the inetd service, we must execute (and create the appropriate links in the /etc/rcX.d directories) /etc/init.d/inetd.real start (see the end of this chapter for examples of configurations).
Apart from the inetd or xinetd configuration, the typical configuration of network services in a desktop or basic server environment might also include (some of these services will be examined in the chapter on servers):
ssh: secure interactive connection to replace telnet that includes two configuration files /etc/ssh/ssh_config (for the client) and /etc/ssh/sshd_config (for the server)
exim: multi transfer agent (MTA), includes configuration files: /etc/exim/exim.conf, /etc/mailname, /etc/aliases, /etc/email-addresses.
fetchmail: daemon for downloading the mail from a POP3 account, /etc/fetchmailrc
procmail: program for filtering and distributing local mail, ~/.procmailrc
tcpd: Filtering services for enabled and disabled machines and domains for connecting to the server (wrappers): /etc/hosts.allow, /etc/hosts.deny
DHCP. Service for managing (server) or obtaining an IP (client), /etc/dhcp3/dhclient.conf (client), /etc/default/dhcp3-server (server), /etc/dhcp3/dhcpd.conf (server)
CVS: system for managing concurrent versions, /etc/cvs-cron.conf, /etc/cvs-pserver.conf
NFS: network file system, /etc/exports
Samba: network file system and sharing printers in Windows networks, /etc/samba/smb.conf
lpr: daemon for the printing system, /etc/printcap (for the Ipr system -not CUPS-)
Apache and Apache2: Web Server, /etc/apache/* and /etc/apache2/*
squid: Server proxy-cache, /etc/squid/*
There are other configuration files that are hardly ever used, but that can be interesting. The /etc/protocols is a file that shows the protocol identifiers with the protocol names; in this way, the programmers can specify the protocols by their names in the programs.
The /etc/networks file has a function similar to /etc/hosts, but where the networks are concerned, it shows the network names in relation to its IP address (the route command will show the name of the network and not its address in this case).
It is important to take into account the security aspects in network connections, as a significant amount of attacks occur through the network. We will discuss this subject in more detail in the unit on security; however, there are some basic recommendations that should be taken into account in order to minimise the risks immediately before and after configuring the network in our computer:
Do not activate services in /etc/inetd.conf that will not be used, insert an # before the name to avoid sources of risk.
Modify the /etc/ftpusers file to deny access to certain users who may have an FTP connection to your machine.
Modify the /etc/securetty file to indicate from which terminals (a name per line), for example: tty1 tty2 tty3 tty4, it will be possible for the root superuser to connect. The root superuser will not be able to connect from any of the remaining terminals.
Use the tcpd program. This server is a wrapper that makes it possible to allow/deny a service from a given node and it is placed in /etc/inetd.conf as a service intermediary. The tcpd verifies certain access rules in two files: /etc/hosts.allow /etc/host.deny.
If the connection is accepted, it starts up an appropriate service passed as an argument (for example, the FTP service line shown earlier in inetd.conf:
ftp stream tcp nowait root /usr/sbin/tcpd/usr/sbin/in.ftpd.
tcpd first search /etc/hosts.allow and then inside of /etc/hosts.deny. The hosts.deny file contains the rules on which nodes do not have access to a service within this machine. A restrictive configuration is ALL: ALL, as it will only allow access to the services from the nodes declared in /etc/hosts.allow.
The /etc/hosts.equiv file permits access to this machine without having to enter the password. Using this mechanism is not recommended; users should be advised not to use the equivalent from the user account, through the .rhosts file.
In Debian, it is important to configure /etc/security/access.conf, the file that indicates the rules on who and from where it is possible to log in to this machine. This file has a line by command with three fields separated by a ':' of the permission type: Users: origin. The first will be an +o- (allow or deny), the second a user name/user names, group or user@host, and the third will be the name of a device, node, domain, node or networks addresses or ALL.
There are further options with regard to IP traffic that we should mention. This is configured by starting up the corresponding file in the /proc/sys/net/ipv4/ directory. The file name is the same as the command and a 1 must be placed in the file to activate them, or a 0 to deactivate them.
Example 6-22. Example
For example, if we wish to activate ip_forward, we have to execute:
echo 1 > /proc/sys/net/ipv4/ip_forward
The most widely used are: ip_forward used for routing between interfaces or with IP Masquerading; ip_default_ttl, which is the lifetime for an IP packet (64 milliseconds, by default) ip_bootp_agent logical variable (BOOLEAN) which accepts packets (or not) with the origin address of the 0.b.c.d type and the destination of this node, broadcast or multicast.
If there are problems in the configuration of the network, we can begin by verifying the output of the following commands to obtain an initial idea:
ifconfig cat /proc/pci cat /proc/interrupts dmesg | more
In order to verify the network connection, we can use the following commands (netkit-ping, traceroute, dnsutils, iptables and net-tools must be installed):
ping uoc.edu # verifies the Internet connection traceroute uoc.edu # scans IP packets ifconfig # verifies the host configuration route -n # verifies the routing configuration dig [@dns.uoc.edu] www.uoc.edu # verifies the registries in # on the dns.uoc.edu server. iptables -L -n |less # verifies packet filtering (kernel >=2.4) netstat -a # shows all the open ports netstat -l --inet # shows all the listening ports netstat -ln --tcp # shoos the listening tcp ports (number)