introduction to networking
(Written by Paul Cobbaut, https://github.com/paulcobbaut/, with contributions by: Alex M. Schapelle, https://github.com/zero-pytagoras/)
The contents of this entire chapter should be considerd to be obsolete. The commands and services that are discussed here no are no longer present in modern Linux distributions. The information is kept here for historical purposes only.
introduction to iptables
iptables firewall
The Linux kernel has a built-in stateful firewall named iptables
. To
stop the iptables
firewall on Red Hat, use the service
command.
root@linux:~# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
root@linux:~#
The easy way to configure iptables, is to use a graphical tool like
KDE\'s kmyfirewall
or
Security Level Configuration Tool
. You can find the latter in the
graphical menu, somewhere in System Tools - Security, or you can start
it by typing system-config-securitylevel
in bash. These
tools allow for some basic firewall configuration. You can decide
whether to enable or disable the firewall, and what typical standard
ports are allowed when the firewall is active. You can even add some
custom ports. When you are done, the configuration is written to
/etc/sysconfig/iptables
on Red Hat.
root@linux:~# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-F...NPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-F...NPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-F...NPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-F...NPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
root@linux:~#
To start the service, issue the service iptables start
command. You can configure iptables to start at boot time with
chkconfig.
root@linux:~# service iptables start
Applying iptables firewall rules: [ OK ]
root@linux:~# chkconfig iptables on
root@linux:~#
One of the nice features of iptables is that it displays extensive
status
information when queried with the service iptables status
command.
root@linux:~# service iptables status
Table: filter
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
root@linux:~#
Mastering firewall configuration requires a decent knowledge of tcp/ip. Good iptables tutorials can be found online here http://iptables-tutorial.frozentux.net/iptables-tutorial.html and here http://tldp.org/HOWTO/IP-Masquerade-HOWTO/.
practice : iptables
1. Verify whether the firewall is running.
2. Stop the running firewall.
solution : iptables
1. Verify whether the firewall is running.
root@linux ~# service iptables status | head
Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
2. Stop the running firewall.
root@linux ~# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
root@linux ~# service iptables status
Firewall is stopped.
xinetd and inetd
the superdaemon
Back when resources like RAM memory were limited, a super-server was
devised to listen to all sockets and start the appropriate daemon only
when needed. Services like swat
, telnet
and ftp
are typically served by such a super-server. The
xinetd
superdaemon is more recent than
inetd
. We will discuss the configuration both daemons.
Recent Linux distributions like RHEL5 and Ubuntu10.04 do not activate
inetd
or xinetd
by default, unless an application requires it.
inetd or xinetd
First verify whether your computer is running inetd
or xinetd
. This
Debian 4.0 Etch is running inetd
.
root@linux:~# ps fax | grep inet
3870 ? Ss 0:00 /usr/sbin/inetd
This Red Hat Enterprise Linux 4 update 4 is running xinetd
.
[root@linux ~]# ps fax | grep inet
3003 ? Ss 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
Both daemons have the same functionality (listening to many ports, starting other daemons when they are needed), but they have different configuration files.
xinetd superdaemon
The xinetd
daemon is often called a superdaemon because
it listens to a lot of incoming connections, and starts other daemons
when they are needed. When a connection request is received, xinetd
will first check TCP wrappers (/etc/hosts.allow and /etc/hosts.deny) and
then give control of the connection to the other daemon. This
superdaemon is configured through /etc/xinetd.conf
and
the files in the directory /etc/xinetd.d
. Let\'s first
take a look at /etc/xinetd.conf.
student@linux:~$ cat /etc/xinetd.conf
#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
student@linux:~$
According to the settings in this file, xinetd can handle 60 client
requests at once. It uses the authpriv
facility to log the host
ip-address and pid of successful daemon spawns. When a service (aka
protocol linked to daemon) gets more than 25 cps (connections per
second), it holds subsequent requests for 30 seconds.
The directory /etc/xinetd.d
contains more specific configuration
files. Let\'s also take a look at one of them.
student@linux:~$ ls /etc/xinetd.d
amanda chargen-udp echo klogin rexec talk
amandaidx cups-lpd echo-udp krb5-telnet rlogin telnet
amidxtape daytime eklogin kshell rsh tftp
auth daytime-udp finger ktalk rsync time
chargen dbskkd-cdb gssftp ntalk swat time-udp
student@linux:~$ cat /etc/xinetd.d/swat
# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
# to configure your Samba server. To use SWAT, \
# connect to port 901 with your favorite web browser.
service swat
{
port = 901
socket_type = stream
wait = no
only_from = 127.0.0.1
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = yes
}
student@linux:~$
The services should be listed in the /etc/services
file.
Port determines the service port, and must be the same as the port
specified in /etc/services. The socket_type
should be set to stream
for tcp services (and to dgram for udp). The log_on_failure +=
concats
the userid to the log message formatted in /etc/xinetd.conf. The last
setting disable
can be set to yes or no. Setting this to no
means
the service is enabled!
Check the xinetd and xinetd.conf manual pages for many more configuration options.
inetd superdaemon
This superdaemon has only one configuration file
/etc/inetd.conf
. Every protocol or daemon that it is
listening for, gets one line in this file.
root@linux:~# grep ftp /etc/inetd.conf
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot/tftp
root@linux:~#
You can disable a service in inetd.conf above by putting a # at the start of that line. Here an example of the disabled vmware web interface (listening on tcp port 902).
student@linux:~$ grep vmware /etc/inetd.conf
#902 stream tcp nowait root /usr/sbin/vmware-authd vmware-authd
practice : inetd and xinetd
1. Verify on all systems whether they are using xinetd or inetd.
2. Look at the configuration files.
3. (If telnet is installable, then replace swat in these questions with telnet) Is swat installed ? If not, then install swat and look at the changes in the (x)inetd configuration. Is swat enabled or disabled ?
4. Disable swat, test it. Enable swat, test it.
network file system
protocol versions
The older nfs
versions 2 and 3 are stateless (udp) by
default, but they can use tcp. Clients connect to the server using
rpc
(on Linux this is controlled by the
portmap
daemon. Look at rpcinfo
to
verify that nfs
and its related services are running.
root@linux:~# /etc/init.d/portmap status
portmap (pid 1920) is running...
root@linux:~# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32769 status
root@linux:~# service nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]
The same rpcinfo
command when nfs
is started.
root@linux:~# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32769 status
100011 1 udp 985 rquotad
100011 2 udp 985 rquotad
100011 1 tcp 988 rquotad
100011 2 tcp 988 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 udp 32770 nlockmgr
100021 3 udp 32770 nlockmgr
100021 4 udp 32770 nlockmgr
100021 1 tcp 32789 nlockmgr
100021 3 tcp 32789 nlockmgr
100021 4 tcp 32789 nlockmgr
100005 1 udp 1004 mountd
100005 1 tcp 1007 mountd
100005 2 udp 1004 mountd
100005 2 tcp 1007 mountd
100005 3 udp 1004 mountd
100005 3 tcp 1007 mountd
root@linux:~#
nfs version 4
requires tcp (port 2049) and supports
Kerberos
user authentication as an option. nfs
authentication only takes place when mounting the share. nfs
versions
2 and 3 authenticate only the host.
server configuration
nfs
is configured in /etc/exports
. Here is a sample
/etc/exports
to explain the syntax. You need some way (NIS domain or
LDAP) to synchronize userid\'s across computers when using nfs
a lot.
The rootsquash
option will change UID 0 to the UID of
the nfsnobody user account. The sync
option will write writes to disk
before completing the client request.
student@linux:~$ cat /etc/exports
# Everyone can read this share
/mnt/data/iso *(ro)
# Only the computers barry and pasha can readwrite this one
/var/www pasha(rw) barry(rw)
# same, but without root squashing for barry
/var/ftp pasha(rw) barry(rw,no_root_squash)
# everyone from the netsec.lan domain gets access
/var/backup *.netsec.lan(rw)
# ro for one network, rw for the other
/var/upload 192.168.1.0/24(ro) 192.168.5.0/24(rw)
You don\'t need to restart the nfs server to start exporting your newly
created exports. You can use the exportfs -va
command to
do this. It will write the exported directories to
/var/lib/nfs/etab
, where they are immediately applied.
client configuration
We have seen the mount
command and the
/etc/fstab
file before.
root@linux:~# mount -t nfs barry:/mnt/data/iso /home/project55/
root@linux:~# cat /etc/fstab | grep nfs
barry:/mnt/data/iso /home/iso nfs defaults 0 0
root@linux:~#
Here is another simple example. Suppose the project55 people tell you
they only need a couple of CD-ROM images, and you already have them
available on an nfs
server. You could issue the following command to
mount this storage on their /home/project55
mount point.
root@linux:~# mount -t nfs 192.168.1.40:/mnt/data/iso /home/project55/
root@linux:~# ls -lh /home/project55/
total 3.6G
drwxr-xr-x 2 1000 1000 4.0K Jan 16 17:55 RHELv8u1
drwxr-xr-x 2 1000 1000 4.0K Jan 16 14:14 RHELv8u2
drwxr-xr-x 2 1000 1000 4.0K Jan 16 14:54 RHELv8u3
drwxr-xr-x 2 1000 1000 4.0K Jan 16 11:09 RHELv8u4
-rw-r--r-- 1 root root 1.6G Oct 13 15:22 sled10-vmwarews5-vm.zip
root@linux:~#
practice : network file system
1. Create two directories with some files. Use nfs
to share one of
them as read only, the other must be writable. Have your neighbour
connect to them to test.
2. Investigate the user owner of the files created by your neighbour.
3. Protect a share by ip-address or hostname, so only your neighbour can connect.