Introduction
Linux provides a stable and cost efficient solution in many situations and it supports an unparalleled amount of network configurations, protocols, and services. Basic Linux intranet configuration suitable for a small or medium-sized network can be done within an hour providing a secure and reliable network infrastructure. Additional features can be added later if a need arises without disturbing the existing network or its users. This document explains a general purpose intranet infrastructure design, configurations for firewall, DNS, DHCP, NFS, NIS, SSH, NTP, and lists needed services to enable the configured features in the network. Such a network is suitable for software development, office application use, and many other tasks.
Reader is expected to be familiar with basic terms and concepts of networked Linux/Unix environments. The purpose of this document is to provide a compact and quick guide for setting up a Linux intranet, not to explain in detail each service and feature. More detailed instructions about each service can be found from the referenced documents. Provided configuration files have been tested on Red Hat based distributions (Red Hat Enterprise Linux, CentOS, and Fedora Core) but most of them are suitable for any distribution. Each configuration file is well commented and has a header specifying its location, permissions, and purpose. If a service depends on several configuration files and not all of them are mentioned here it indicates that the other configuration files provided with Red Hat based distributions are suitable to be used alongside with the provided ones. It is expected that needed software packages are installed prior configuration of a service. All RPMs related to configured services are mentioned.
Network Infrastructure
This section specifies the basics of the network and its most essential configurations. The following sections expect the network being built and configured as specified in this section if relevant for a particular service or functionality.
The intranet has one server that is connected to a outer network
10.0.0.0/255.0.0.0 and all workstations are connected to
the outer network via this server. The server provides NAT (Network
Address Translation) and IP
packet forwarding for the workstations to allow them to access the outer
network. This scheme is sometimes referred as IP masquerading. The intranet where all the
workstations are connected to has domain name intra and it
uses private address space 192.168.1.0/255.255.255.0. The
server has two NICs (Network Interface Cards), one
(eth0) connected to the outer network and one
(eth1) to the intra intranet. One NIC, eth0, is needed
per workstation. It is crucial that the only physical connection between
the intranet and the outer network is the server so that the
workstations cannot bypass the server when connecting to other networks
and, more importantly, no connections from other networks are allowed
into the intranet without proper authentication and authorization at the
server. The server and the workstations shall all be connected to a
common switch that provides needed physical connections for the
intranet. The workstations use the server both as a gateway and as a
nameserver. Should the outer network environment ever change only the
server's network settings need to be adjusted for the changes, the
intranet and the workstations' configurations do not require any
modifications in such a situation.
Configuration files: network, ifcfg-eth0, ifcfg-eth1 for the server and network, ifcfg-eth0 for the workstations. Note
that the server eth0 and gateway settings must
match your outer network environment and on each workstation
eth0 configuration must use unique IP address. Please note that all these files provide
only basic network settings; firewall and routing will be configured in the next section.
Required services to be started: network at the server and
the workstations. Related RPMs: several, all required ones should be available by
default after installation of the operating system.
Firewall Configuration
Firewall set up in the intranet relies, of course, on the netfilter packet filtering framework. The iptables command is used to configure the packet filtering ruleset. The configuration provides both routing/NAT functionality and also protection against DoS attacks. The configuration implements what was described in the section Network Infrastructure. Each rule has a comment explaining its meaning and some rules that additionally might be needed are in comments. For additional information about netfilter and iptables(8) please refer to netfilter/iptables documentation.
Configuration files: iptables, sysctl.conf for the server and iptables, sysctl.conf for the workstations. With
other than Red Hat based distributions the provided
iptables configuration can easily be used with the
iptables-restore(8) utility.
Required services to be started: iptables at the server and
the workstations. Related RPMs: iptables.
DNS Configuration
DNS configuration in
a smaller intranet is most easily done by using dnsmasq, a
lightweight and easy to configure DNS forwarder. The DNS configuration is actually done just by maintaining
the file /etc/hosts at the server and dnsmasq
will automatically take care of everything else. dnsmasq
itself requires no special configuration but it is recommended to set it
to listen only to the intranet interface eth1.
dnsmasq binaries for Red Hat based distributions can found
for example from Dag Wieers' RPM
repository.
Other required configurations are for the file
/etc/resolv.conf that defines name servers to be used and
for the file /etc/host.conf that specifies how names are
resolved. No additional services will be required for resolver since the
functionality is part of the standard C library.
Note that it is important that the first line in the
/etc/hosts configuration for the host
127.0.0.1 contains only the entry
localhost.localdomain localhost, other entries are invalid
and may cause unexpected behavior in when resolving
127.0.0.1.
Configuration files: hosts, dnsmasq.conf, resolv.conf for the server and hosts, resolv.conf for the workstations. Note
that the server resolv.conf must match your outer
network environment. Common configuration file: host.conf.
Required services to be started: dnsmasq at the server.
Related RPMs:
dnsmasq.
At this stage network connections from the intranet to the outer network should be working properly. If not so, you must investigate the problem. Most useful network diagnostic utilities include ping(8), ifconfig(8), route(8), traceroute(8), and netstat(8), among others.
DHCP Configuration
To support mobile hosts that are not permanently connected to the
intranet DHCP server is set
up. On Red Hat based distributions, two files are configured: one for
controlling on which interfaces the DHCP daemon is listening to and one for
the actual daemon configuration. eth0 at the server is
connected to the outer network where no DHCP daemon should be run so only
eth1 will be listened by the daemon. Daemon configuration
uses the intranet address space specified in the section Network Infrastructure.
Server configuration files: interface, daemon.
Required services to be started: dhcpd at the server.
Related RPMs:
dhcp.
NFS Configuration
Configuring NFS server is
done by editing the file /etc/exports at the server. For
the workstations NFS mount
points must be defined in the file /etc/fstab. The
presented configuration relies on version 3 of the NFS protocol.
The provided server configuration file exports users' home directories
from the directory /home and miscellaneous shared files
from the directory /net. The directory /net
must be created at the server before exporting it and at the
workstations before mounting it. The directory /home
exported from the server will be mounted over the existing directory
/home at the workstations. This is no problem since no
local users are added at the workstations, as all user administration
will be done at the server as will be described in the
next section.
Configuration files: server, workstation. Note that the workstation
configuration must be appended to the existing
/etc/fstab file, do not overwrite the
existing file with this one.
Required services to be started: portmap,
nfslock, nfs at the server and
portmap, nfslock, netfs at the
workstations. Related RPMs:
portmap, nfs-utils. rpcbind is
used instead of portmap on newer distributions.
NIS/YP Configuration
Users and groups are centrally and easily administrated at the server by
using NIS/YP. At the
server administrator creates users normally and then updates the NIS maps that are used by the
NIS server. The user
accounts created can then be used from the server and the workstations.
Users are added at the server with useradd(8) command and the
NIS maps are updated by
issuing the command make -C /var/yp while the service
ypserv is running.
Setting up NIS server
requires that both portmap and ypserv services
are running at the server and NISDOMAIN is set
before starting the service ypserv. (Newer
distributions use rpcbind instead of portmap.)
It is not recommended to use the DNS domain name for NISDOMAIN for security
reasons so a different name should be chosen. To set
NISDOMAIN on Red Hat based distributions the following line
must be added to the file /etc/sysconfig/network if not
already present:
NISDOMAIN=intranis
The main ypserv configuration file is
/etc/ypserv.conf. Shadow password usage with NIS should be enabled by
adjusting the file /var/yp/Makefile by preventing merging
of shadow data to other maps. All the needed modifications are included
in this file. For security reason also
the file /var/yp/securenets should be configured before starting
ypserv. After ypserv is finally running, the
command /usr/lib/yp/ypinit -m must be run. Follow the given
instructions (you probably just want to hit Control-D
followed by Enter) and you should see how NIS maps are being built.
After that the remaining configuration files mentioned below should be
placed in correct locations and yppasswdd and
ypbind services can be started. Note that
NISDOMAIN must be set also at the workstations
before starting the service ypbind.
By default NIS/YP does not allow users to change their
shells but the provided yppasswdd configuration will enable
the usage of the command ypchsh(1). ypbind is
configured and run also at the server so that the command
yppasswd(1) can be used at all hosts by users to change their
passwords. To also make the command passwd(1) NIS aware a small change in
PAM
configuration is needed: in the main PAM configuration file
/etc/pam.d/system-auth one must add into the
password section for module pam_unix.so the
additional parameter nis. After this change
passwd(1) will change NIS password if no local password for the user is
present. An administrator may also instruct users to always use the
command yppasswd(1) to change their passwords or perhaps even
force this by using a small wrapper
script in place of real /usr/bin/passwd.
One final important configuration file that needs to be adjusted is
/etc/nsswitch.conf that is used by NSS.
NSS defines databases for user
and group information, network protocols, and mail aliases, to name a
few. If the file is not properly updated, NIS will not be used even if all required
NIS related services
would be running. No additional services will be required for NSS since the functionality is part
of the standard C library.
Server configuration files: ypserv.conf, Makefile, securenets, yppasswdd. Common configuration files: yp.conf, nsswitch.conf. If
NISDOMAIN was added earlier to the file
/etc/sysconfig/network then there is no need for these
files but there are provided here for reference: server, workstation.
Required services to be started: portmap,
ypserv, yppasswdd, ypbind at the
server and portmap, ypbind at the
workstations. Related RPMs:
portmap, ypserv, ypbind,
yp-tools. rpcbind is used instead of
portmap on newer distributions.
SSH Configuration
SSH configuration
is easily done by adjusting two files at the server and the
workstations. At the server the SSH
daemon configuration is slightly more restricted as the server is
connected to the outer network that may have rogue users. Specifically,
root logins into the workstations are permitted but into the server,
they are not. Only protocol version 2 is supported at the server and the
workstations. X11 traffic is enabled everywhere. Users can naturally use
the file ~/.ssh/config to further control their
ssh(1) settings. Users may also find ssh-agent(1)
and keychain(1) to be useful utilities in many occasions.
Configuration files: server, workstation, common.
Required services to be started: sshd at the server and the
workstations. Related RPMs:
openssh, openssh-server,
openssh-clients.
NTP Configuration
In many situations it is essential that clocks in a network are set precisely to the same time, e.g., to prevent build errors caused by clock skews with make(1). This can easily be done with NTP. The server is used as the time source and the workstations adjust their clocks with the server. If needed, the server could easily be configured to adjust its clock with some external NTP server.
Please note that if the NTP
server at the server has just been started, starting ntpd
at the workstations immediately after that may cause synchronization
with the timeserver to fail as the server clock is still calibrating
itself. This is harmless, as the synchronization will happen later when
the server clock is ready for it.
Server configuration file: ntp.conf. Workstation configuration files: ntp.conf, step-tickers.
Required services to be started: ntpd at the server and the
workstations. Related RPMs:
ntp.
Services Configuration
The lists below contain all the required services that need to be running on Red Hat based distributions to support all the services that have been configured above and also some other basic functionality. The services are explained briefly. It is recommended to disable services that are not necessarily needed.
Common services:
- acpi (for ACPI functionality)
- anacron (for scheduled jobs)
- atd (for scheduled jobs)
- crond (for scheduled jobs)
- gpm (for console mouse support)
- haldaemon (for hardware support)
- iptables (for firewall support)
- messagebus (for application messaging support)
- network (for basic networking support)
- nfslock (for NFS file locking support)
- nscd (for name service caching support)
- ntpd (for NTP support)
- portmap (for NFS/NIS support, rpcbind on newer distributions)
- sendmail (for MTA support)
- sshd (for SSH server support)
- syslog (for system logging facilities support, rsyslog on newer distributions)
- ypbind (for NIS client support)
Workstation specific services:
- netfs (for mounting remote filesystems)
Server specific services:
- dhcpd (for DHCP server support)
- dnsmasq (for DNS server support)
- nfs (for NFS server support)
- yppasswdd (for NIS password changing support)
- ypserv (for NIS server support)
Enabled services can be checked using the chkconfig(8)
utility or by examining symbolic links in the /etc/rcX.d/
directory where X is the current runlevel. Current runlevel
may be checked with the command runlevel(8) and the runlevel
to which the system is started after boot can be checked from the file
/etc/inittab.
Conclusion
This document provided a guide to design, set up, and configure a Linux intranet providing all essential services as well as centralized user administration and basic security features. The presented configuration is suitable for small and medium-sized networks and many individual configuration files can also be utilized in larger networks or at a standalone host. There are numerous enhancements and customizations that could be made depending on the size of a network or special needs for a particular network. List of possible enhancements and improvements could include some of the following: VPN support, LDAP authentication, printing support, Windows connectivity, better laptop and mobility support, IPv6 support, enhanced security, tuning server and workstations for better performance depending on applications used, thin clients support, automated backups, automated software installations and updates, local web portal for intranet users, and so forth. These kinds of configurations are, however, outside of scope of this document.
All the configuration files mentioned are browsable and available for download.
Comments and feedback can be sent to oss(at)segetech.com. We would kindly like to note that we cannot promise a personal reply to all e-mails received, especially to those asking for help in some unrelated configuration problems. Inquiries about possible cooperation should be done via addresses listed at our Contact page.
This document was last updated on 2009-03-10.