LAB5 : TCP – UDP - DNS -

NAT IP network

Table des matières

1. Goals ........................................................................................................... 2
2. Initialization ................................................................................................ 2
 3. Local and remote DNS resolution .................................................................................................... 3
4. TCP Connection with a server ......................................................................................................... 3
5. NAT : addresses masquerading like your Internet « Box ».............................................................. 5

By Rexy

Your names :
-

IP Network – By Rexy 2 LAB5 : TCP-UDP-DNS-NAT

1. Goals
This practical LAB allows you to study the “TCP” and “UDP” Level 4 protocols. You will also study the behavior of the DNS
(Domain Name Service).
• Documents : « network-reminders.pdf », « TCP-UDP-support.pdf », « TCP-UDP-presentation.pdf » ;
• Concepts involved : TCP, UDP, local and remote name resolution, Network Address Translation, The integrated Linux
firewall (Netfilter), The command in "user land" to modify the firewall behavior (iptables) ;
• Commands and useful files : /etc/hosts, nslookup, dig, iptables, ss (previously : netstat)
• Reminder of the simulation context : you will use a « virtualbox » virtual machine (VM) containing a Mageia Linux
system which has been voluntarily reduced. This system integrates the « Marionnet » network simulator. The VM is
available on the Internet (http://ftp.alcasar.net) in folder “divers”.
◦ On this Linux host, you're automatically connected with the « student » user (password = « student »). The password
is « toor » for the root account.
◦ On the Marionnet guest, the user account is « marionnet » (password = « marionnet »). The password is « root » for
the account « root ».
• Work to deliver : you have to answer several questions directly within this document. You will upload it on Moodle
following the format : « LAB5_your_names.odt ».

2. Initialization
• Stop the Linux VM. Set the Network Interface Card (NIC) of this
VM to « NAT » type.
• Run the Linux VM and log you in as “student”. In a terminal, as
root, run the command “bridge-or-nat.sh”. Choose “Mode NAT
(avec Marionnet)”.
• Test Internet connectivity of the Linux VM.

3. Local and remote DNS resolution

Goal: locally resolve the hostname. Analyze a sequence with an Internet DNS server.
• Reboot your VM, run Marionnet and create a new project.
• Create the following architecture (H1 is a Hub !). Configure M1 in DHCP
mode. On M1, retrieve the network parameters in order to configure M2
manually and statically (set IP@, router@ and DNS@ manually). Verify that
M1 can connect to M2 and that M1 & M2 can connect to an Internet server.
• On M1 & M2, the hostname has been set by the Marionnet simulator. The
« hostname » command allows you to get and set the hostname. Set the
hostname of each machine with your family names (ie : “rexy1” & “rexy2”).
The « /etc/hosts » file allows for a local resolution of the association between
an IP address and a « hostname ». Correctly set the « /etc/hosts » files of each machine so that they can connect (ping) to the
other machine with its name. Take a screenshot.
• Run « wireshark » on M2 in order to analyze LAN frames. On M1, request your DNS server in order to resolve the Internet
hostname of your choice (“nslookup” or “dig” command). Which protocol of OSI L4 is used (UDP or TCP) ? Which source
port and destination port are used ? Analyze the DNS protocol. Copy the DNS request and the DNS answer below.
Screenshot « ping between M1 & M2 » (with your family name as hostname) :

IP Network – By Rexy 3 LAB5 : TCP-UDP-DNS-NAT

DNS Resolution
• L4 protocol : UDP
• Port source : dls-monitor 2048 Port destination : domaine 53
• DNS request :

• DNS answer :

4. TCP Connection with a server

• The Marionnet host systems (M1, M2, etc.) embed an SSH server (Secure SHELL) in order to securely take remote control
when needed. On a Linux system, to display the open ports and the network services linked to them, use the « ss -ntaup »
command (or “netstat -ntaup”). Verify that an SSH server is running on M1. What is the SSH listen port ?
• On M1, create a new user account with its password. Run « Wireshark ».
• From M2, use SSH to connect to M1 using the new user account (« slogin new_user_name@ip_address »). Take a screenshot
with Wireshark displaying the TCP « handshaking » of the SSH connection.
• Just after the TCP « handshaking », you can see a « Diffie Hellman » exchange. What is the goal of this exchange?
• Once connected, send some Linux commands (hostname, whoami, ls, df, etc.). Is Wireshark able to see the commands and
the results ? Disconnect from the SSH session (« exit »).
• From M2, use « lynx » to connect to an HTTP WEB server (ie : “neverssl.com”). Use Wireshark to capture and analyze the
flows : What is the DNS name of the server ? What is its IP address ? What are the source and destination ports ? What is the
agent identifier of your WEB client? What are the name and the version of the WEB server? In Wireshark, click on the frame
which corresponds to the beginning of the handshaking with the WEB server (SYN packet). Perform a “session following”
(right click + “follow tcp stream”). You can now see the entire HTTP session in a human readable way.
SSH listen port: 22
Handshaking screenshot:

IP Network – By Rexy 4 LAB5 : TCP-UDP-DNS-NAT

Goal of a « Diffie Hellman » exchange:
Établir une clé de chiffrement partagée donc de sécurité contre les interceptions (man in the middle)
HTTP analysis:
• Server DNS name:www.googl.fr
• Server IP@: 99.83.138.213
• source + destination ports: src: 10.0.2.16 dst: 99.83.138.213
• Client agent identifier:

• Screenshot of the HTTP stream (Wireshark : click on the first HTTP segment (syn), then right click on “follow tcp stream”)
:

• Are you able to see the version and type of web server in the header? If not, find another web server where this information
is sent.
• Screenshot of a WEB server header with type and version:

IP Network – By Rexy 5 LAB5 : TCP-UDP-DNS-NAT

• What do you think about this information regarding security? Which option in APACHE web server configuration files should
be set in order to not send this information in the header (named « banner ») ?

• On your system, run “netstat” with the right options in order to see your TCP/UDP open ports and the services (processes)
that opened these ports (take a screenshot).

5. NAT : addresses masquerading like your Internet « Box »

Goals : enabling the masquerading function (it’s the name of the NAT) in the Linux kernel firewall.
• Review the principles of the « NAT - Network Address Translation » (see Wikipedia with a special mention for the
« masquerading » notion)
• Reboot (don’t snapshot) your VM, run Marionnet and create a new project.
• Create the following network architecture :
- LAN1 = M1 + B1 + 1st NIC of R (R_NIC1). M1 is in DHCP mode. Look at the M1 IP parameters
to configure R in static mode. Test that both M1 and R can connect to the Internet.
- LAN2 = M2 + 2nd NIC of R (R_NIC2). These two NICs are configured in static mode, and their
network IP plan is different from that of LAN1. Don’t forget to configure R in router mode. Don’t forget
to configure M2 default gateway.
At that point, M2 can only ping both NICs of R and M1. M2 can’t connect to the Internet because B1
doesn’t know the LAN2 IP plan. B1 isn’t configurable. So you can’t add R as the router to be used to go
to LAN2... Therefore, we have to configure R as a NAT router like your Internet BOX.
• You now have to modify the firewall rules of R in order to translate all the connections with a source IP in LAN2 to the IP
address of R_NIC1 (which is in LAN1). The command used to display the firewall rules is “iptables -nvL”. To only display
the rules of the translation table (NAT table), enter the command “iptables -tnat -nvL”. At this point, they should be empty.
You can find the “rules-iptables.sh” script on Moodle. It’s a template that empties all rules and allows you to add your own
rules. Here is a rule that allows you to masquerade (to “nat”) all the outgoing packets from eth0 : « iptables -t nat -A
POSTROUTING -o eth0 -j MASQUERADE ». Retrieve and copy the script on R (see. reminder below). Add the masquerade
rule and test. M2 should connect to both M1 and to the Internet IP@. Run « Wireshark » on R and display eth0 frames in
order to verify that the source IP address is the router’s during the exchange from M2 to M1 (or to the Internet).
• Take a screenshot displaying : « wireshark » on R, the state of the NAT table on R (“watch iptables -tnat -nvL”) and M2
pinging M1 (or an Internet IP@).
REMINDER: an exchange of files between the host system and « marionnet » systems is allowed via the following directory :
- on the host : « /tmp/marionnet-xxxx.dir/n_project/hostfs/N°_guest »

IP Network – By Rexy 6 LAB5 : TCP-UDP-DNS-NAT

- on Marionnet systems : « /mnt/hostfs »

• LAN1 IP plan :
• LAN2 IP plan :
• Screenshot displaying « wireshark » on R, the state of the NAT table on R (“watch iptables -tnat -nvL”) and M2 pinging M1
(or an Internet @IP) :

IP Network – By Rexy 7 LAB5 : TCP-UDP-DNS-NAT