# Data Networking/Fall 2014/Dearnetworks

LINUX Project - TELE5330 - D.E.A.R
This page was created in order to explain the procedures for completing LINUX Project
1. The Folks
Robert Kley Lageano de Oliveira NUID:001797253
Eady Alnaqi NUID:001726045
Nidhi Kurup NUID:001776021
Arman Muratbayev NUID:001777022
2. Motivation
Learn how to design and implement a network for a start up company that needs a DHCP server and DNS server as well as a Web server for its applications. implementing the concepts learnt in class to real life scenarios and experiencing the challenges faced while setting up a network for a small scale start-up.
3. Understanding the Protocol
DNS
DNS stands for Domain Name Service and is basically a service that can resolve an IP address into a Domain name and vice versa. The DNS is a distributed database implemented in hierarchy of DNS servers, an application-layer protocol that allows hosts to query the distributed database. Moreover, DNS servers are often UNIX machines running the Berkeley Internet Name Domain or simply BIND software. It is also important to highlight that the DNS protocol runs over UDP and uses port 53.
In a DNS protocol, there are basically two types of message involved in the process. The DNS query and the DNS reply messages are involved in a DNS request. The semantics of a DNS message is as follows:
1. The first 12 bytes is the header section, which has a number of fields. The first field is a 16-bit number that identifies the query. This identifier is copied into the reply message to a query, allowing the client to match received replies with sent queries. There are a number of flags in the flag field. A 1-bit query/reply flag indicates wether the message is a query(0) or a reply(1). A 1-bit authoritative flag is set in a reply message when a DNS server is authoritative server for a queried name. A 1-bit recursion-desired flag is set when a client (host or DNS server) desires that the DNS server perform recursion qhen it doesn't have the record. A 1-bit recursion available field is set in a reply if the DNS server supports recursion. In the header, there are also four number-of fileds. These fields indicates the number of occurrences of the four types of data section that follow the header.
2. In the question section that are information about the query that is being made. This section includes a name field that contains the name that is being queried and a type of field that indicates the type of question being asked about the name.
3. In a reply from the DNS server, the answer section contains the resource records for the name that was queried.
4. The authoritative section contains records of other authoritative servers.
5. The additional section contains other helpful records. For example, information about canonical hostnames.
The various steps involved are:
Step 1: The client first send a DNS query message to its local server, this query message contains the hostname that needs to be translated.
Step 2: The local DNS server forwards the query message to the root server, if needed.
Step 3: The DNS server then analyzes the suffix and returns a list of IP addresses for TLD (Top Level Domain) servers that responsible for the domain.
Step 4: Finally the local DNS server resends the query message directly to the DNS server responsible for the hostname which responds with the IP address of it.
DHCP
DHCP stands for Dynamic Host Configuration Protocol.
As the name suggests, DHCP is used to control the network configuration of a host through a remote server. DHCP functionality comes installed as a default feature in most of the contemporary operating systems. DHCP is an excellent alternative to the time-consuming manual configuration of network settings on a host or a network device. DHCP works on a client-server model. Being a protocol, it has it’s own set of messages that are exchanged between client and server.
1. DHCPDISCOVER It is a DHCP message that marks the beginning of a DHCP interaction between client and server. This message is sent by a client (host or device connected to a network) that is connected to a local subnet. It’s a broadcast message that uses 255.255.255.255 as destination IP address while the source IP address is 0.0.0.0
2. DHCPOFFER It is DHCP message that is sent in response to DHCPDISCOVER by a DHCP server to DHCP client. This message contains the network configuration settings for the client that sent the DHCPDISCOVER message.
3. DHCPREQUEST This DHCP message is sent in response to DHCPOFFER indicating that the client has accepted the network configuration sent in DHCPOFFER message from the server.
4. DHCPACK This message is sent by the DHCP server in response to DHCPREQUEST recieved from the client. This message marks the end of the process that started with DHCPDISCOVER. The DHCPACK message is nothing but an acknowledgement by the DHCP server that authorizes the DHCP client to start using the network configuration it received from the DHCP server earlier.
5. DHCPNAK This message is the exact opposite to DHCPACK described above. This message is sent by the DHCP server when it is not able to satisfy the DHCPREQUEST message from the client.
6. DHCPDECLINE This message is sent from the DHCP client to the server in case the client finds that the IP address assigned by DHCP server is already in use.
7. DHCPINFORM This message is sent from the DHCP client in case the IP address is statically configured on the client and only other network settings or configurations are desired to be dynamically acquired from DHCP server.
8. DHCPRELEASE This message is sent by the DHCP client in case it wants to terminate the lease of network address it has be provided by DHCP server.
The steps involved in the client receiving an IP address from the DHCP server are:
Step 1: When the client computer (or device) boots up or is connected to a network, a DHCPDISCOVER message is sent from the client to the server. As there is no network configuration information on the client so the message is sent with 0.0.0.0 as source address and 255.255.255.255 as destination address. If the DHCP server is on local subnet then it directly receives the message or in case it is on different subnet then a relay agent connected on client’s subnet is used to pass on the request to DHCP server. The transport protocol used for this message is UDP and the port number used is 67. The client enters the initializing stage during this step.
Step 2: When the DHCP server receives the DHCPDISCOVER request message then it replies with a DHCPOFFER message. As already explained, this message contains all the network configuration settings required by the client. For example, the yaddr field of the message will contain the IP address to be assigned to client. Similarly the the subnet mask and gateway information is filled in the options field. Also, the server fills in the client MAC address in the chaddr field. This message is sent as a broadcast (255.255.255.255) message for the client to receive it directly or if DHCP server is in different subnet then this message is sent to the relay agent that takes care of whether the message is to be passed as unicast or broadcast. In this case also, UDP protocol is used at the transport layer with destination port as 68. The client enters selecting stage during this step
Step 3: The client forms a DHCPREQUEST message in reply to DHCPOFFER message and sends it to the server indicating it wants to accept the network configuration sent in the DHCPOFFER message. If there were multiple DHCP servers that received DHCPDISCOVER then client could receive multiple DHCPOFFER messages. But, the client replies to only one of the messages by populating the server identification field with the IP address of a particular DHCP server. All the messages from other DHCP servers are implicitly declined. The DHCPREQUEST message will still contain the source address as 0.0.0.0 as the client is still not allowed to use the IP address passed to it through DHCPOFFER message. The client enters requesting stage during this step.
Step 4: Once the server receives DHCPREQUEST from the client, it sends the DHCPACK message indicating that now the client is allowed to use the IP address assigned to it. The client enters the bound state during this step.
4. The Requirements
* Implementing DNS,DHCP and WebServer with Firewall for a StartUp company in Boston.
* DNS :
5.Steps to perform the setup / installation
1) DNS
Install BIND server:
Edit BIND service to IPv4:
Options should be set to:
Configure Options file:
The file should look like this:
Save and exit the file.
Configure the local file:
Add the forward zone to the file:
Add the reverse zone to the file:
Now, we need to create the file zones.
First, we create a directory for the files:
Start with the file "db.local" transferring it to the new directory:
Edit forward zone:
Edit the file to look like this:
Now create the reverse time zone:
Now edit the reverse time zone file:
The edited reverse time zone file should look as follows:
Check BIND configuration syntax:
Check the correctness of the zone files:
Restart BIND:
2) DHCP
DHCP server installation
Assignment of interface on what the DHCP server (dhcpd) will serve requests:
Main configuration file dhcpd.conf file:
Set the domain name and domain-name servers:
Make our DHCP authoritative inside the network:
Add of DNS zone and DNS reverse zone:
Define the subnet, range of ip addresses, domain and domain name servers:
2.1) PXE network booting
PXE stands for "Pre-boot eXecution Environment". In order to use PXE you need to setup a boot-server which will allow client systems to :
Request an IP address (via DHCP) Download a kernel (via TFTP)
TFTP Setup
Installing TFTP
Enable it by editing the file /etc/default/tftpd-hpa:
Create the root directory:
PXE Configuration
Create a file, which will contain the list of kernels which are available to boot:
Create and edit Boot.txt:
Download the official installer kernel and associated files and save them in specified directories:
2.2) RARP
Install the package with:
Create an /etc/ethers file, listing your client:
Add your client to the /etc/hosts file:
Start RARP daemon:
3) WebServer / Firewall
Installing Web server and hosting a webpage in Linux
Execute the following command on the Linux terminal to install Apache web server:
Edit the default HTML page to design web page as per our requirement:
Implenting Firewall in Linux by configuring iptables
Allow systems hosting DNS and DHCP to access web server:
Allow clients to access web server through HTTP and SSH:
Command to list out all the rules configured in the iptables:
Save the iptables to a file:
Restore the iptables if a reboot occurs:
6. Testing
1) Connect the systems hosting DNS, DHCP, Webserver and the Client together using a switch
2) Check for working of the DHCP server :
* As soon as the client is connected to the network, the DHCP starts assigning ip addresses dynamically to the hosts in the network.
* The client gets an ip address from the range of available addresses of the DHCP server for a designated lease time.
* Check if the client is getting a valid ip address from the DHCP
3) Check for working of the DNS server
* The DNS server has entries for translating/ reverse translating the webpage being hosted in the network.
* As soon as the client tries to access the webpage using the web-browser, the client sends out a DNS query to the DNS server for translation of the webpage address
* The DNS replies back with the IP address of the webserver hosting the web page.
* Check if the client gets as far as getting the DNS query response for the translation request using Wireshark.
4) Check for working of the Web Server
* After receiving the IP address of the webserver, the client tries to connect to the webserver using this information provided by the DNS server.
* Check if the client is able to access the webpage through the web browser.
5) Check for the firewall implementation
* The iptables are configured such that the client is able to access the web server using the TCP protocol at port number 80 (for HTTP) and at port number 22 (for SSH) and is blocked for any other type of access.
* Check if the client is able to view the webpage using the web browser (this confirms access using HTTP). Try SSH to the web server to check for its working.
* Hosts not in the network should not be able to access the web server
7. Future Prospects
* Adding a secondary physical DNS server machine to the network (IP: 192.168.1.6) to the network would increase its DNS resiliency.
* Adding a trusted DNS list to the DNS servers to increase the level of security. Only specified hosts can inquire the DNS servers.
* Setting up VPN on the web server side as well as the client’s side to secure the data transfer and avoid manipulation of packets in transit. Hosts outside the network could also be given access provided public IP addresses are used with DMZ/NAT configurations if necessary.
* Configure NFS server to allow clients on the network to access files over the network much like local storage is accessed.
8. Citations
* Computer Networking a Top Down Approach,6th edition, Kurose and Ross
* http://code.tutsplus.com/tutorials/the-linux-firewall--net-31748
* http://www.howtogeek.com/177621/the-beginners-guide-to-iptables-the-linux-firewall/
* https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04
* http://www.unixmen.com/setup-dhcp-server-ubuntu-14-04-lts-server/
* https://www.debian-administration.org/article/478/Setting_up_a_server_for_PXE_network_booting
* http://www.netbsd.org/docs/network/netboot/rarp.html