Networking Concepts Overview
What is a network? Ans: Computers (a.k.a. hosts) able to share information and resources. A network may be small (one geographical location) or may cover the globe. Different technologies are used in each case. For a LAN we use technology such as Ethernet, which broadcasts packets so every station sees them. For a WAN we use slower, error-prone serial links that connect one LAN to another (point-to-point connections).
Qu: What is needed physically? Media such as a cable between each pair of computers (called a mesh), or in a ring, or in a bus, or in a star. (Network topologies.) (Show bus/star with 4 hosts.)
Qu: What would happen if two or more hosts transmit at the same time? Ans: a collision. To permit communications all parties must agree to a set of rules, or protocols. Today the most common set of protocols for a LAN is called Ethernet.
In addition to media and protocols, you need some hardware to connect the host to the media. Called a NIC (Network Interface Card). In Linux these have names such as “eth#”, where “#”=0,1,2,... In Solaris, they have strange names such as “elx#” depending on the manufacturer/chipset of the NIC, but many modern NICs are simply known as “hme#”.
Your operating system needs the correct driver software to allow applications to send messages to the NIC. Then some application can send a message to another host by invoking the proper API function. The data will be passed to the NIC and then sent on its way.
Qu: (point to diagram) if this host wants to send a message to that host, how does it do that? Ans: each computer needs a unique address, so when one computer sends data to another, the intended recipient knows the data was meant for it. The other computers on the network are supposed (!) to ignore the message. In the old days, the administrator manually set each NIC with a unique number between 1 and 255. Today, NICs come configured with an address already, known as the MAC Address (or BIA, data-link address, ...). For Ethernet NICs, this address is 6 bytes (48 bits). The first three bytes uniquely identify the manufacturer, assigned by the IEEE. The last three bytes are a unique serial number.
For host A to send data to host B, host A must build a packet containing the data plus a packet header which contains the destination address and other information (e.g., packet length, type of data, ...). Besides the header and data, a checksum (FCS or frame check sequence) is appended to the end. This header and checksum are sometimes called framing, and these packets are sometimes called frames:
Overview of communication: Application invokes API function, passing it the address of the recipient and the data to send. API function builds the packet from this info and sends the packet to the NIC. The NIC sends out the packet onto the media, one bit at a time, according to the network protocol. If the data is very large, the API function will split it into several packets, which get reassembled at the destination. (Example: FTP a large file; Ethernet max packet size is 1518 bytes.)
Most NICs will examine only enough of the packet to see if it was intended for them or not. If not they stop looking at it. The destination NIC will read in the whole packet, compute a checksum, and compare it with the checksum at the end of the packet. If they don’t match, the packet is corrupted and must be sent again.
With media, NICs, protocols, addresses, and software, a network can function. But there are problems: What if one host on your network wants to send a message (a packet) to a host on a different network? Sending data between networks is called internetworking, and a collection of networks that are connected are called an internet. (“The Internet”, with a capital “I”, refers to the global internet that connects nearly every network with every other.)
The obvious solution of connecting both networks into one large network doesn’t work. The technology for LANs has strict size (number of hosts) and distance (meters not miles) limitations.
Instead a more complicated solution is used. A device called a router (sometimes called a gateway) with two or more NICs is used to connect the LANs. (Draw picture.) The sending host on the first LAN sends the packet to the router (to the NIC connected to its network). The router then sends the packet out a different NIC connected to the second LAN. Now all hosts on that LAN, including the destination host, see the packet. For this to work, every host must know the address of the router interface connected to its network. And when the packet is received by the router, it must somehow determine through which NIC to send the packet out. The router then needs a list of all addresses on all networks. The situation is made worse since not all networks connect to the same router. It is often necessary for the first router to forward the packet to another, and then another, etc., until the packet reaches the final network.
All hosts need to know the IP address of the router. This can be set with the route command. This IP address can be stored in a file and used with the route command automatically when the network is brought up. In Fedora use the file /etc/default-route, and in Solaris use /etc/defaultrouter. (This information is often stored in different files, even on Solaris and Linux!)
The most common protocol suite in use today for this is IPv4. A newer version called IPv6 is available, as are competitors such as IPX. The common name for the IP suite is TCP/IP.
For one host to send a packet to another, it must know the address of the destination host. This leads to a problem of finding out the addresses of all the hosts in the world. Why not use MAC (Ethernet) address? Huge unmanageable routing tables, administration problems (e.g., firewall configuration).
The most popular answer (there are others) is to assign an IP address to each NIC. IP addresses have two parts: network number and a host number. The idea is that routers only need to keep track of the various networks in the world, not all the host numbers. So, for one host to send a packet to another, it must have the IP address of the destination host. If the network number is the same for both hosts, the packet is just broadcast on the LAN as normal. If the destination is in a different network than the source, the sending host sends the packet to a router instead, trusting the router to forward the packet on its way.
IPv4 addresses are 32 bits long. (This isn’t a lot of addresses! This changed to 128 bits for IPv6; see RFC-3513.) They are most commonly written in dotted-decimal notation: 10.3.200.42. The 32 bits are divided into two parts: the network number and the host number. Each LAN must have a unique network number, assigned by your local ISP, who bought a block of them from a regional provider (ARIN), who in turn gets huge blocks of numbers from the IANA. ISPs lease them out to you and me.
A single host may have several NICs (so do routers). It is important to remember that it isn’t the host that has an address, it is the NIC. So a host with two NICs has two addresses. Also, a single NIC may have multiple addresses. This is known as IP aliasing. (e.g., eth0:0, eth0:1, ...)
The LANs still use Ethernet to sent packets locally. So how does the sending host lookup the MAC address of some other host, given only its IP address? One way is to keep a file of IP to MAC addresses on each host, and to update it regularly. A better way is to use ARP. The ARP protocol is used to map IP addresses to MAC addresses.
Illustrate this protocol: (1) source (local) host determines if destination (remote) host is on same network. If so, then (2) broadcast ARP request for destination host MAC address. If the destination host is on a different network, then broadcast an ARP request for the MAC address of the gateway (a router that connects one network to another). (3) wait for ARP reply. (4) now send packet to destination (or gateway).
Hosts maintain an ARP cache to save a lookup. To view the ARP cache, use the command arp -an.
RARP (which is related to BOOTP and DHCP protocols) does the reverse: Given a host’s MAC address (which is all the host typically knows when it boots up) it asks a server for its IP address. This is useful when you don’t wish to configure each and every host in your organization individually. You can do this of course, by putting the host’s IP address, the gateway router IP address, and other information in configuration files the host can use at boot time. But it is easier to have a single DHCP server on the LAN. When the host boots up it broadcasts a DHCP request packet containing its MAC address. The DHCP reply contains all the required network parameters.
Note your own computer has a virtual NIC with the address 127.0.0.1 (the loopback address, usually referred to by the name localhost).
Port numbers and Sockets
Sending a packet to a host isn’t enough. When the destination host gets the packet, what program should it send it to? (Web server? Email server? Telnet?) Part of the layer 4 header includes a port number to identify which program should receive the packet and which one sent the packet. These are 16-bit values. (Example: a web browser with two windows open. You click a line on one, switch to the other and click a different link. Each browser window’s HTTP request packet will use a different source port number so the replies will be sent to the correct window.)
When a host receives a packet, the kernel will check the port number to see to which process to send it.
So how does a client (say a web browser) know which port number corresponds to a server? The servers listen for a particular port number that all agree on (IANA). The standard servers use well known Port numbers in the range 0–1023. Which service (and its application level protocol) uses which port number is documented in the /etc/services file. These Ports are reserved for public services such as FTP (20 and 21), telnet (23), SMTP (25), and HTTP (80), HTTPS (443). This makes it easy for clients; to contact your web server the client will send the request packet to your IP address and destination port 80. Note that on a Unix system root-privileges are needed to listen in on a well-known Port. (This prevents a user from crashing your web server and then starting their own, fooling people who visit your web site!)
The range 1024-49151 are User (Registered) Ports, used for other public services (such as Unix rlogin or the w3c SSL services). These are also registered by IANA (as a public service.)
The Dynamic and/or Private Ports are those from 49152 through 65535. Clients will use any available port number higher than 1024; the kernel keeps track of which are in use. (Note: you can use a telnet application to connect to any port: debugging.)
A socket is the combination of an IP address and a port number. A pair of sockets will uniquely identify a network connection from a client application on one host to a server on another host.
Many servers are not started at boot time (ftp) although some are (httpd). (Q: Why?). Instead a “super-server” known as inetd (or xinetd on modern Linux systems) is started at boot time that listens for incoming packets with a variety of port numbers. Inetd then checks its configuration file to determine which server should get that packet, starts the server, and hands off the packet to it. Such network servers are often referred to as network daemons. Most spawn child processes for each incoming request. This important service is configured either by editing a file /etc/inetd.conf, editing files in a directory /etc/xinetd.d, or enabling and then starting a systemd socket.
fuser port/proto (ex: fuser ssh/tcp or fuser 22/tcp). lsof too.
Network sockets have proven so useful and easy to work with, that many types now exist. Besides the ones for TCP, UDP, and IP (“raw”), there are sockets that support other network protocols, sockets for kernel-to-process communications (netlink sockets, used for example by udev), and process-to-process communications (unix sockets, similar to named pipes). Sockets have been references throughout this course; now you know what they are.
TCP/IP Transports: Connection and Connectionless
The IP addresses are sufficient to route a packet from one computer to the destination. However two issues remain: How to identify the source process (client) and destination process (server)? The answer to this is to include another header (the transport layer header) that includes the source and destination port numbers as described above.
The other issue is dealing with errors that can occur. One common approach is to have the sending process expect an acknowledgment from the receiving process. If no such reply is found after a time-out period then the sender can resend the packet. Implementing this correctly for every client and server gets old fast!
Another solution is to have the network itself guarantee delivery of the packets. In this scheme, the two hosts set up a session, send the data, and tear down the session when done. The TCP/IP system handles the time-outs and other issues.
The first scheme is known as datagram or connectionless service and is called the UDP in TCP/IP protocol suite. The second scheme is known as a virtual circuit, or more commonly a connection-oriented service and is called TCP.
Sun developed a different scheme for connecting a server to a port number. Instead of using a well-known port number for each service, a single well-known port number (111) is used for the program portmapper (or portmap). This program assigns each RPC service a unique port number at each boot. A client wanting to use some RPC service sends a query to the portmapper, requesting the port number for that service. This scheme is full of security holes, and should be turned off on your server unless you are using RPC services. These include NFS and rlogin.
Configuring Basic Networking
The NIC must be configured at boot time with many parameters, such as an IP address and mask. In addition, your host will need a default gateway address to configure its routing table. To use DNS, your computer must be assigned a hostname, a default domain name, and must be configured with the IP address of a DNS server to use to translate names to IP addresses.
The easiest way to configure TCP/IP networking is to let someone else do it. One way to achieve this is to configure your system to use DHCP (dynamic host configuration protocol) for each NIC. When the system brings up the NIC (usually at boot time), it will send a broadcast DHCP request packet. If there is a DHCP server listening on that LAN, it responds with all the required networking parameters.
The other way to configure networking parameters is by manually editing various configuration files (or using some tool to edit those files). This is called static addressing.
For wireless laptops, Fedora Linux systems come with a newer networking system called NetworkManager. This software is poorly documented and doesn’t work well for static, wired networking. You can use chkconfig and service (or systemctl) to turn this daemon off and make sure it stays off, and then use those tools to turn on the older network service (you may have to install that). However, Red Hat has modified NetworkManager to use the standard (for Red hat) config files; see /etc/NetworkManager/NetworkManager.conf. (Debian has done something similar.) Thus, there is no real need to switch network services. Even the GUI config utility, nm-tool, will use the standard files.
The configuration of NICs on Red Hat systems is controlled by the file /etc/sysconfig/network-scripts/ifcfg-NameOfNIC. In many cases, NameOfNIC is eth0. On some systems, NICs are named differently (e.g., “p7p1”). In the directions that follow, be sure to change eth0 to your NIC’s actual name. (You can use dmesg to see what name the kernel gave your NIC.) To configure the system for DHCP, this file should look something like this:
Intel Corporation 82557/8/9 [Ethernet Pro 100]
This will cause the network system to configure everything using DHCP. For a static setup, this file should look like this:
Intel Corporation 82557/8/9 [Ethernet Pro 100]
That will configure the IP address and mask, and the default route. But not DNS. To configure the DNS system when not using DHCP, you must also edit the file /etc/resolv.conf, which should look something like the following:
You must first turn off DHCP, or changes to that file will be lost when DHCP does turn off. It may also pay to make a copy of that file first, so you can see the IP addresses of the nameservers from the copy.
Finally, you may need to set the hostname. The default of “localhost.localdomain” is fine for most purposes. If you do need to set a different hostname, use the hostname command. (There is no standard file to edit on a modern Linux system to set this, although many systems will pay attention to /etc/hostname. However, you should add an entry to /etc/hosts with your static IP address and hostname.)
At the host level, you have network security in several sub-systems: a packet filtering firewall (iptables on Linux and similar ones for other Unixes) is the first line of defense. This can be used to allow or deny incoming or outgoing packets, and to collect various statistics. TCP Wrappers can be used to examine incoming service requests and either allow or deny them (and log them). Note the packet filter can also be configured for this; however, TCP Wrappers can allow or deny access on information not in the packet (time of day, availability of some resource, the username making the request, etc.)
The various services that listen for incoming requests can generally also be configured for security. Additionally, any network services that authenticate users will likely use PAM.
Incoming data can such as FTP and WebDAV uploads, email, etc., can be scanned for viruses and other malware.
You can run network monitoring tools that look for known attacks or any suspicious activity, and block access to attacking hosts (as well as log and alert the SA).
Perfect security is an illusion! Even with all this security, attackers can get in. By setting up file permissions carefully and using service isolation techniques, you can limit or prevent a successful penetration from doing (much) harm to your server.
Network Trouble-Shooting Tools and Techniques
Common tools are ping, traceroute, top, ipcalc and ethtool or mii-tool (Linux), host, dig, and various log files.
Before using any tools, verify the problem exists and is network related (and not a turned off server).
Test with ping first, which tests layers <3 (i.e., basic IP connectivity). Then if that works, try nc (netcat) or telnet next (to say port 80 on a web server, or port 25 on a mail server). If that fails, the problem is usually a firewall between client and server blocking access.
If ping fails, try traceroute to localize the fault. The problem is almost always a bad cable, connector, or NIC, or some joker unplugged something.
If the problem appears to be with a host, use the command ifconfig to examine the NIC parameters and route to examine the routing table.
Also, examine the resolver files to check for DNS errors. Use nslookup and/or dig to check for DNS server errors (discussed in more detail below).
To examine the firewall setup (including masquerading) you use iptables -L [-v]; iptables -t nat -L [-v] to list all rules (if you use iptables and not firewalld).