Linux Intranet Configuration


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 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 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 contains only the entry localhost.localdomain localhost, other entries are invalid and may cause unexpected behavior in when resolving

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:


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


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