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 :
1) Get a Domain name for the Start Up
2) Configure name servers to handle queries for the domain
3) Use BIND/Posadis/PowerDNS server
4) Create 5 DNS records in the DNS Server
5) Create reverse domains in in-addr.arpa for the addresses
- DHCP :
1) Assign a set of IP addresses for leasing to clients
2) Exclude addresses which are generally used for hardware devices or static ip addresses
3) Setting a lease time for which a client may use an ip address before it must re-lease the ip address or request for a new one
4) Dynamic allocation of ip addresses
5) Implementing PXE Boot and RARP
- Webserver and Firewall :
1) Use Command line tools and packages to install webserver and implement Firewall
2) Host a web page on the webserver and make the page accessible to clients in the network using a web browser
3) Make the server the most secured one in all possible ways
5.Steps to perform the setup / installation
1) DNS
Install BIND server:
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
Edit BIND service to IPv4:
gksudo gedit /etc/default/bind9
Options should be set to:
OPTIONS="-4 -u bind"
Configure Options file:
gksudo gedit /etc/bind/named.conf.options
The file should look like this:
options {
directory "/var/cache/bind";
recursion yes; # enables resursive queries
allow-recursion { trusted; }; # allows recursive queries from "trusted" clients
listen-on { 192.168.1.5; }; # ns1 private IP address - listen on private network only
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
...
};
Save and exit the file.
Configure the local file:
gksudo gedit /etc/bind/named.conf.local
Add the forward zone to the file:
zone "dearnetworks.com" {
type master;
file "/etc/bind/zones/db.dearnetworks.com"; # zone file path
allow-transfer { 192.168.1.6; }; # ns2 private IP address - secondary
};
Add the reverse zone to the file:
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.1.168.192"; # 192.168.1.0/24
allow-transfer { 192.168.1.6; }; # ns2 private IP address - secondary
};
Now, we need to create the file zones.
First, we create a directory for the files:
sudo mkdir /etc/bind/zones
Start with the file "db.local" transferring it to the new directory:
cd /etc/bind/zones sudo cp ../db.local ./db.dearnetworks.com}
Edit forward zone:
gksudo gedit /etc/bind/zones/db.dearnetworks.com
Edit the file to look like this:
$TTL 604800
@ IN SOA ns1.dearnetworks.com. admin.dearnetworks.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.dearnetworks.com.
IN NS ns2.dearnetworks.com.
; name servers - A records
ns1.dearnetworks.com. IN A 192.168.1.5
ns2.dearnetworsk.com. IN A 192.168.1.6
; 192.168.1.0/24 - A records
host1.dearnetworks.com. IN A 192.168.1.100
host2.dearnetworks.com. IN A 192.168.1.101
dearnetworks.com. IN A 192.168.1.23
Now create the reverse time zone:
cd /etc/bind/zones sudo cp ../db.127 ./db.1.168.192
Now edit the reverse time zone file:
sudo vi /etc/bind/zones/db.1.168.192
The edited reverse time zone file should look as follows:
$TTL 604800
@ IN SOA ns1.dearnetworks.com. admin.dearnetworks.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.dearnetworks.com.
IN NS ns2.dearnetworks.com.
; PTR Records
5 IN PTR ns1.dearnetworks.com. ; 192.168.1.5
6 IN PTR ns2.dearnetworks.com. ; 192.168.1.6
100 IN PTR host1.dearnetworks.com. ; 192.168.1.100
101 IN PTR host2.dearnetworks.com. ; 192.168.1.101
23 IN PTR dearnetworks.com. ; 192.168.1.23
Check BIND configuration syntax:
sudo named-checkconf
Check the correctness of the zone files:
sudo named-checkzone dearnetworks.com db.dearnetworks.com
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/zones/db.1.168.192
Restart BIND:
sudo service bind9 restart
2) DHCP
DHCP server installation
sudo apt-get install isc-dhcp-server -y
Assignment of interface on what the DHCP server (dhcpd) will serve requests:
sudo nano /etc/default/isc-dhcp-server
INTERFACES="eth0"
Main configuration file dhcpd.conf file:
sudo nano /etc/dhcp/dhcpd.conf
Set the domain name and domain-name servers:
# option definitions common to all supported networks...
option domain-name "dearnetworks.com";
option domain-name-servers ns1.dearnetworks.com;
Make our DHCP authoritative inside the network:
authoritative;
Add of DNS zone and DNS reverse zone:
# dearnetworks.com DNS zones
zone dearnetworks.com. {
primary 192.168.1.5; #This server is the primary DNS server for this zone
}
zone 1.168.192.in-addr-arpa. {
primary 192.168.1.5;
}
Define the subnet, range of ip addresses, domain and domain name servers:
# A slightly different configuration for an internal subnet.
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.25 192.168.1.100;
option domain-name-servers 192.168.1.5;
option domain-name "dearnetworks.com";
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
default-lease-time 600;
max-lease-time 7200;
}
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
apt-get install tftpd-hpa
Enable it by editing the file /etc/default/tftpd-hpa:
#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"
Create the root directory:
mkdir -p /var/lib/tftpboot /etc/init.d/tftpd-hpa start Starting HPA's tftpd: in.tftpd.
PXE Configuration
Create a file, which will contain the list of kernels which are available to boot:
mkdir /var/lib/tftpboot/pxelinux.cfg
/var/lib/tftpboot/pxelinux.cfg/default:
DISPLAY boot.txt
DEFAULT etch_i386_install
LABEL etch_i386_install
kernel debian/etch/i386/linux
append vga=normal initrd=debian/etch/i386/initrd.gz --
LABEL etch_i386_linux
kernel debian/etch/i386/linux
append vga=normal initrd=debian/etch/i386/initrd.gz --
LABEL etch_i386_expert
kernel debian/etch/i386/linux
append priority=low vga=normal initrd=debian/etch/i386/initrd.gz --
LABEL etch_i386_rescue
kernel debian/etch/i386/linux
append vga=normal initrd=debian/etch/i386/initrd.gz rescue/enable=true --
PROMPT 1
TIMEOUT 0
Create and edit Boot.txt:
- Boot Menu -
=============
etch_i386_install
etch_i386_linux
etch_i386_expert
etch_i386_rescue
Download the official installer kernel and associated files and save them in specified directories:
cd /var/lib/tftpboot/
wget http://ftp.uk.debian.org/debian/dists/oldstable/main/installer-i386/current/images/netboot/debian-installer/i386/pxelinux.0
mkdir -p /var/lib/tftpboot/debian/etch/i386
cd /var/lib/tftpboot/debian/etch/i386
wget http://ftp.uk.debian.org/debian/dists/oldstable/main/installer-i386/current/images/netboot/debian-installer/i386/linux
wget http://ftp.uk.debian.org/debian/dists/oldstable/main/installer-i386/current/images/netboot/debian-installer/i386/initrd.gz
2.2) RARP
Install the package with:
sudo apt-get install rarpd
Create an /etc/ethers file, listing your client:
#/etc/ethers CC:CC:CC:CC:CC:CC client
Add your client to the /etc/hosts file:
192.168.1.75 client
Start RARP daemon:
rarpd -A
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:
sudo apt-get install apache2
Edit the default HTML page to design web page as per our requirement:
sudo gedit /var/www/html/index.html
Implenting Firewall in Linux by configuring iptables
Allow systems hosting DNS and DHCP to access web server:
sudo iptables -A INPUT -m iprange --src-range 192.168.1.1-192.168.1.6 -j ACCEPT
Allow clients to access web server through HTTP and SSH:
sudo iptables -A INPUT -p tcp --dport 80 -m iprange --src-range 192.168.1.25-192.168.1.100 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -m iprange --src-range 192.168.1.25-192.168.1.100 -j ACCEPT
Command to list out all the rules configured in the iptables:
sudo iptables -L
Save the iptables to a file:
sudo iptables-save > /home/anku/rules.v4
Restore the iptables if a reboot occurs:
sudo iptables-restore < /home/anku/rules.v4
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