Data Communications & Security

Lecture 11 (week 11)

Security part 2
 Chapter 8 roadmap

8.1 What is network security?

8.2 Principles of cryptography
8.3 Message integrity
8.4 Securing e-mail
8.5 Securing TCP connections: SSL
8.6 Network layer security: IPsec
8.7 Securing wireless LANs
8.8 Operational security: firewalls and IDS
Security 8-2
SSL: Secure Sockets Layer
 widely deployed security
 original goals:
protocol
• supported by almost all • Web e-commerce
browsers, web servers transactions
• https • encryption (especially
• billions $/year over SSL credit-card numbers)
 mechanisms: [Woo 1994], • Web-server authentication
implementation: Netscape • optional client
 variation -TLS: transport authentication
layer security, RFC 2246 • minimum hassle in doing
 provides business with new
• confidentiality merchant
• integrity  available to all TCP
• authentication applications
• secure socket interface
Security 8-3
SSL and TCP/IP

Application Application

SSL
TCP
TCP
IP IP

normal application application with SSL

 SSL provides application programming interface

(API) to applications
 C and Java SSL libraries/classes readily available

Security 8-4
Could do something like PGP:
-
KA
-
m .
H( )
-.
K ()
A
KA(H(m))
KS

+ KS( ) .
m + Internet

KS
+
KB( )
. +
KB(KS )
+
KB

 but want to send byte streams & interactive data

 want set of secret keys for entire connection
 want certificate exchange as part of protocol: handshake phase

Security 8-5
Toy SSL: a simple secure
channel
 handshake: Alice and Bob use their certificates,
private keys to authenticate each other and
exchange shared secret
 key derivation: Alice and Bob use shared secret to
derive set of keys
 data transfer: data to be transferred is broken up
into series of records
 connection closure: special messages to securely
close connection

Security 8-6
Toy: a simple handshake
hello

rtificate
public key ce

KB +(MS) = EMS

MS: master secret

EMS: encrypted master secret

Security 8-7
Toy: key derivation
 considered bad to use same key for more than one
cryptographic operation
• use different keys for message authentication code (MAC) and
encryption
 four keys:
• Kc = encryption key for data sent from client to server
• Mc = MAC key for data sent from client to server
• Ks = encryption key for data sent from server to client
• Ms = MAC key for data sent from server to client
 keys derived from key derivation function (KDF)
• takes master secret and (possibly) some additional random data
and creates the keys

Security 8-8
Toy: data records
 why not encrypt data in constant stream as we write it to
TCP?
• where would we put the MAC? If at end, no message integrity
until all data processed.
• e.g., with instant messaging, how can we do integrity check over
all bytes sent before displaying?
 instead, break stream in series of records
• each record carries a MAC
• receiver can act on each record as it arrives
 issue: in record, receiver needs to distinguish MAC from
data
• want to use variable-length records

length data MAC

Security 8-9
Toy: sequence numbers
 problem: attacker can capture and replay record or
re-order records
 solution: put sequence number into MAC:
 MAC = MAC(Mx, sequence||data)
 note: no sequence number field

 problem: attacker could replay all records

 solution: use nonce

Security 8-10
Toy: control information
 problem: truncation attack:
• attacker forges TCP connection close segment
• one or both sides thinks there is less data than there
actually is.
 solution: record types, with one type for closure
• type 0 for data; type 1 for closure
 MAC = MAC(Mx, sequence||type||data)

length type data MAC

Security 8-11
Toy SSL: summary
hello

certificate, nonce
KB +(MS) = EMS
type 0, seq 1, data
bob.com
type 0, seq 2, data

1, data
type 0, seq
encrypted

type 0, seq 3, data

type 1, seq 4, close

lose
type 1, seq 2, c
Security 8-12
Toy SSL isn’t complete
 how long are fields?
 which encryption protocols?
 want negotiation?
• allow client and server to support different encryption
algorithms
• allow client and server to choose together specific
algorithm before data transfer

Security 8-13
SSL cipher suite
 cipher suite
• public-key algorithm
common SSL symmetric
• symmetric encryption algorithm ciphers
• MAC algorithm  DES – Data Encryption
Standard: block
 SSL supports several cipher  3DES – Triple strength: block
suites  RC2 – Rivest Cipher 2: block
 negotiation: client, server  RC4 – Rivest Cipher 4: stream
 AES – Advanced Encryption
agree on cipher suite
• client offers choice SSL Public key encryption
• server picks one  RSA
 DH
 ECC
 EDH
Security 8-14
Real SSL: handshake (1)
Purpose
1. server authentication
2. negotiation: agree on crypto algorithms
3. establish keys
4. client authentication (optional)

Security 8-15
Real SSL: handshake (2)
1. client sends list of algorithms it supports, along with
client nonce
2. server chooses algorithms from list; sends back:
choice + certificate + server nonce
3. client verifies certificate, extracts server’s public key,
generates pre_master_secret, encrypts with server’s
public key, sends to server
4. client and server independently compute encryption
and MAC keys from pre_master_secret and nonces
5. client sends a MAC of all the handshake messages
6. server sends a MAC of all the handshake messages

Security 8-16
Real SSL: handshaking (3)
last 2 steps protect handshake from tampering
 client typically offers range of algorithms, some
strong, some weak
 man-in-the middle could delete stronger algorithms
from list
 last 2 steps prevent this
• last two messages are encrypted

Security 8-17
Real SSL: handshaking (4)
 why two random nonces?
 suppose Trudy sniffs all messages between Alice
& Bob
 next day, Trudy sets up TCP connection with Bob,
sends exact same sequence of records
• Bob (Amazon) thinks Alice made two separate orders
for the same thing
• solution: Bob sends different random nonce for each
connection. This causes encryption keys to be different
on the two days
• Trudy’s messages will fail Bob’s integrity check

Security 8-18
SSL record protocol
data

data data
MAC MAC
fragment fragment

record encrypted record encrypted

header data and MAC header data and MAC

record header: content type; version; length

MAC: includes sequence number, MAC key Mx
fragment: each SSL fragment 214 bytes (~16 Kbytes)
Security 8-19
SSL record format
1 byte 2 bytes 3 bytes
content
type SSL version length

data

MAC

data and MAC encrypted (symmetric algorithm)

Security 8-20
 Client handshake: ClientHel
Real SSL
Server
lo

ServerHello
handshake:
connection hands hak e : C ertificate

: S e rv e rHe lloDone
handshak e

handshake: ClientK
eyExchange
ChangeCipherS
pec

everything handshake: Finish

e d
henceforth
is encrypted ChangeCipherS
pec

ds ha k e: Finished
han

application_data

ata
application_d

Alert: warning, close

_notify
TCP FIN follows
Security 8-21
Key derivation
 client nonce, server nonce, and pre-master secret input into
pseudo-random-number generator.
• produces master secret
 master secret and new nonces input into another random-
number generator: “key block”
 key block sliced and diced:
• client MAC key
• server MAC key
• client encryption key
• server encryption key
• client initialization vector (IV)
• server initialization vector (IV)

Security 8-22
SSL in practice.
1. TCP connection established
2. Client requests connection to server
3. Server sends certificate (X509) and public key
4. Client compares key with those in its cache, CA.
User asked to accept/cache key
5. Client creates session key and sends it to server
encrypted with server’s public key
• Server may request client public key (optional)
• Server may check client’s public key (cache/CA)
6. All subsequent traffic encrypted by session key

COS30015 COS80013
SSL attacks Not on
exam
 BEAST (2011)
• Browser Exploit Against SSL / TLS
• Attacked injects javascript into victim’s browser
• JS sends headers and encrypted headers (block cipher)
to attacker.
• Attacker collects multiple headers + ciphertext and can
re-build the session ID from leaked info. (known text
attack)
 Fix:
• Move stream ciphers
(TLS_RSA_WITH_RC4_128_SHA and
TLS_RSA_WITH_RC4_128_MD5) to higher priority
than block ciphers AES and DES.
COS30015 COS80013
 SSL attacks Not on
 CRIME (2012) exam
• Compression Ratio Info-Leak Mass Exploitation
• Inject JS into victim’s browser
• JS sends encrypted(compressed(session cookie)) back to
attacker, each slightly different (different number of repeating
characters)
• Attacker reconstructs session cookie 1 char at a time.
 Fix:
• Disable compression of HTTPS requests or
• Change cipher to CipherBlockChaining (padded to fixed
length)
http://resources.infosecinstitute.com/beast-vs-crime-attack/

COS30015 COS80013
 SSL attacks Not on
exam
 BREACH (2013)
• Browser Reconnaissance and Exfiltration via Adaptive
Compression of Hypertext)
• Based on CRIME attacks
• Relies of gzip (DEFLATE) compression algorithm built into
browsers and web servers and CSRF attacks.
• Attacker brute-forces some bits and then reconstructs plain
text 1 char at a time.
 Fix:
• Disable compression of HTTPS requests or
• Add CSRF protection (later).
http://resources.infosecinstitute.com/beast-vs-crime-attack/

COS30015 COS80013
SSL Vulnerability Not on
exam
 Heartbleed (2014)
• Affects some OpenSSL libraries
• Problem with the "Heartbeat" keep-alive packet
• Allows user to scrape 64kB or RAM before
authentication.
• Get other people's logins
 Fix:
• Patch OpenSSL or use a different SSL library.

COS30015 COS80013
 SSL attacks Not on
exam
 HEIST (2016)
• HTTP Encrypted Information can be Stolen through TCP-
windows
• Does not require packet sniffing.
• Uses TCP packet fragmentation to determine length of plain
text.
• Makes BREACH attack easier (can be launched by malicious
web server against another connection).
 Fix:
• Disable compression of HTTPS requests or
• Disable 3rd party cookies.
https://tom.vg/papers/heist_blackhat2016.pdf

COS30015 COS80013
 Not on
SSL attacks exam
 DROWN (2016)
• Decrypting RSA with Obsolete and Weakened eNcryption
• SSL v2 (including e-mail, TLS services which use SSL)
• Requires MITM.
• Send session key encrypted with server public key. Collect
responses. Responses leak key info.
• Takes 40,000 probes or 17,000 depending on bugs.
• Brute-force RSA key in 8h or 1min.
 Fix:
• Disable SSL v2 https://drownattack.com

COS30015 COS80013
SSL takeaway
 All SSL versions are vulnerable to attacks
 Replaced by TLS 1.0 (==SSL3)
 Replaced by TLS1.1
 TLS1.2
 Security requires constant vigilance – need to
monitor the media, CERTs, AV industry and
patch/update/end-of-life vulnerable and obsolete
technologies.

Network Security
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity
8.4 Securing e-mail
8.5 Securing TCP connections: SSL
8.6 Network layer security: IPsec
8.7 Securing wireless LANs
8.8 Operational security: firewalls and IDS

Security 8-31
What is network-layer confidentiality ?
between two network entities:
 sending entity encrypts datagram payload, payload
could be:
• TCP or UDP segment, ICMP message, OSPF message ….
 all data sent from one entity to other would be
hidden:
• web pages, e-mail, P2P file transfers, TCP SYN packets
…
 “blanket coverage”

Security 8-32
Virtual Private Networks (VPNs)
motivation:
 institutions often want private networks for security.
• costly: separate routers, links, DNS infrastructure.
 VPN: institution’s inter-office traffic is sent over
public Internet instead
• encrypted before entering public Internet
• logically separate from other traffic

Security 8-33
Virtual Private Networks (VPNs)
public IP
IPsec
laptop
header Secure
Internet
header
payloa w/ IPsec
d
e
ad

he
Secur

IP r
paylo

ad
e
salesperson

IPs der
he
in hotel

a
ec
r
IPsec
heade

Se load
pa
cur
r

y
router w/
heade

router w/
IP

e
IPv4 and IPsec IPv4 and IPsec
ad

he
IP er
ylo

ad
pa

pa
er

ylo
he IP
ad

ad
branch office
headquarters
Security 8-34
IPsec services
 data integrity
 origin authentication
 replay attack prevention
 confidentiality

 two protocols providing different service models:

• AH
• ESP

Security 8-35
IPsec transport mode

IPsec IPsec

 IPsec datagram emitted and received by end-system

 protects upper level protocols

Security 8-36
IPsec – tunneling mode

IPsec IPsec
IPsec IPsec

 edge routers IPsec-  hosts IPsec-aware

aware

Security 8-37
Two IPsec protocols
 Authentication Header (AH) protocol
• provides source authentication & data integrity but not
confidentiality
 Encapsulation Security Protocol (ESP)
• provides source authentication, data integrity, and
confidentiality
• more widely used than AH

Security 8-38
Four combinations are possible!

Host mode Host mode

with AH with ESP

Tunnel mode Tunnel mode

with AH with ESP

most common and

most important

Security 8-39
Security associations (SAs)
 before sending data, “security association (SA)”
established from sending to receiving entity
• SAs are simplex: for only one direction
 ending, receiving entitles maintain state information
about SA
• recall: TCP endpoints also maintain state info
• IP is connectionless; IPsec is connection-oriented!
 how many SAs in VPN w/ headquarters, branch
office, and n traveling salespeople?

Security 8-40
Example SA from R1 to R2
headquarters Internet
branch office

200.168.1.100 193.68.2.23

R1 security association
172.16.1/24
R2
172.16.2/24

R1 stores for SA:

 32-bit SA identifier: Security Parameter Index (SPI)
 origin SA interface (200.168.1.100)
 destination SA interface (193.68.2.23)
 type of encryption used (e.g., 3DES with CBC)
 encryption key
 type of integrity check used (e.g., HMAC with MD5)
 authentication key
Security 8-41
Security Association Database (SAD)

 endpoint holds SA state in security association

database (SAD), where it can locate them during
processing.
 with n salespersons, 2 + 2n SAs in R1’s SAD
 when sending IPsec datagram, R1 accesses SAD
to determine how to process datagram.
 when IPsec datagram arrives to R2, R2 examines
SPI in IPsec datagram, indexes SAD with SPI, and
processes datagram accordingly.

Security 8-42
IPsec datagram
focus for now on tunnel mode with ESP

“enchilada” authenticated
encrypted
new IP ESP original Original IP ESP ESP
header hdr IP hdr datagram payload trl auth

Seq pad next

SPI padding
# length header

Security 8-43
What happens?
headquarters Internet
branch office

200.168.1.100 193.68.2.23

R1 security association
172.16.1/24
R2
172.16.2/24

“enchilada” authenticated
encrypted
new IP ESP original Original IP ESP ESP
header hdr IP hdr datagram payload trl auth

Seq pad next

SPI padding
# length header
Security 8-44
R1: convert original datagram to IPsec datagram

 appends to back of original datagram (which includes original

header fields!) an “ESP trailer” field.
 encrypts result using algorithm & key specified by SA.
 appends to front of this encrypted quantity the “ESP header,
creating “enchilada”.
 creates authentication MAC over the whole enchilada, using
algorithm and key specified in SA;
 appends MAC to back of enchilada, forming payload;
 creates brand new IP header, with all the classic IPv4 header
fields, which it appends before payload

Security 8-45
 Inside the enchilada:
“enchilada” authenticated
encrypted
new IP ESP original Original IP ESP ESP
header hdr IP hdr datagram payload trl auth

Seq pad next

SPI padding
# length header

 ESP trailer: Padding for block ciphers

 ESP header:
• SPI, so receiving entity knows what to do
• Sequence number, to thwart replay attacks
 MAC in ESP auth field is created with shared secret key

Security 8-46
IPsec sequence numbers
 for new SA, sender initializes seq. # to 0
 each time datagram is sent on SA:
• sender increments seq # counter
• places value in seq # field
 goal:
• prevent attacker from sniffing and replaying a packet
• receipt of duplicate, authenticated IP packets may
disrupt service
 method:
• destination checks for duplicates
• doesn’t keep track of all received packets; instead uses
a window

Security 8-47
Security Policy Database (SPD)
 policy: For a given datagram, sending entity needs
to know if it should use IPsec
 needs also to know which SA to use
• may use: source and destination IP address; protocol
number
 info in SPD indicates “what” to do with arriving
datagram
 info in SAD indicates “how” to do it

Security 8-48
Summary: IPsec services

 suppose Trudy sits somewhere between R1 and

R2. she doesn’t know the keys.
• will Trudy be able to see original contents of datagram?
How about source, dest IP address, transport protocol,
application port?
• flip bits without detection?
• masquerade as R1 using R1’s IP address?
• replay a datagram?

Security 8-49
IKE: Internet Key Exchange
 previous examples: manual establishment of IPsec SAs in
IPsec endpoints:
Example SA
SPI: 12345
Source IP: 200.168.1.100 Not on the
Dest IP: 193.68.2.23 exam from
Protocol: ESP here onwards
Encryption algorithm: 3DES-cbc
HMAC algorithm: MD5
Encryption key: 0x7aeaca…
HMAC key:0xc0291f…
 manual keying is impractical for VPN with 100s of
endpoints
 instead use IPsec IKE (Internet Key Exchange)

Security 8-50
IKE: PSK and PKI
 authentication (prove who you are) with either
• pre-shared secret (PSK) or
• with PKI (pubic/private keys and certificates).
 PSK: both sides start with secret
• run IKE to authenticate each other and to generate IPsec
SAs (one in each direction), including encryption,
authentication keys
 PKI: both sides start with public/private key pair,
certificate
• run IKE to authenticate each other, obtain IPsec SAs (one
in each direction).
• similar with handshake in SSL.

Security 8-51
IKE phases
 IKE has two phases
• phase 1: establish bi-directional IKE SA
• note: IKE SA different from IPsec SA
• aka ISAKMP security association
• phase 2: ISAKMP is used to securely negotiate IPsec
pair of SAs
 phase 1 has two modes: aggressive mode and main
mode
• aggressive mode uses fewer messages
• main mode provides identity protection and is more
flexible

Security 8-52
IPsec summary
 IKE message exchange for algorithms, secret
keys, SPI numbers
 either AH or ESP protocol (or both)
• AH provides integrity, source authentication
• ESP protocol (with AH) additionally provides
encryption
 IPsec peers can be two end systems, two
routers/firewalls, or a router/firewall and an end
system

Security 8-53
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity
8.4 Securing e-mail
8.5 Securing TCP connections: SSL
8.6 Network layer security: IPsec
8.7 Securing wireless LANs
8.8 Operational security: firewalls and IDS

Security 8-54
WEP design goals
 symmetric key crypto
• confidentiality
• end host authorization
• data integrity
 self-synchronizing: each packet separately encrypted
• given encrypted packet and key, can decrypt; can continue
to decrypt packets when preceding packet was lost (unlike
Cipher Block Chaining (CBC) in block ciphers)
 Efficient
• implementable in hardware or software

Security 8-55
Review: symmetric stream ciphers
keystream
key keystream
generator

 combine each byte of keystream with byte of plaintext to

get ciphertext:
• m(i) = ith unit of message
• ks(i) = ith unit of keystream
• c(i) = ith unit of ciphertext
• c(i) = ks(i)  m(i) ( = exclusive or)
• m(i) = ks(i)  c(i)
 WEP uses RC4

Security 8-56
Stream cipher and packet independence
 recall design goal: each packet separately encrypted
 if for frame n+1, use keystream from where we left off for
frame n, then each frame is not separately encrypted
• need to know where we left off for packet n
 WEP approach: initialize keystream with key + new IV for
each packet:

keystream
Key+IVpacket keystreampacket
generator

Security 8-57
WEP encryption (1)
 sender calculates Integrity Check Value (ICV, four-byte
hash/CRC over data
 each side has 104-bit shared key
 sender creates 24-bit initialization vector (IV), appends to key:
gives 128-bit key
 sender also appends keyID (in 8-bit field)
 128-bit key inputted into pseudo random number generator to
get keystream
 data in frame + ICV is encrypted with RC4:
• bytes of keystream are XORed with bytes of data & ICV
• IV & keyID are appended to encrypted data to create payload
• payload inserted into 802.11 frame
encrypted

Key
IV data ICV
ID

MAC payload Security 8-58

 WEP encryption (2)
IV
(per frame)
KS: 104-bit key sequence generator
secret ( for given KS, IV)
symmetric
k1IV k2IV k3IV … kNIV kN+1IV… kN+1IV 802.11 WEP-encrypted data
key IV
header plus ICV
plaintext &
frame data d1 d2 d3 … dN CRC1 … CRC4
plus CRC
c1 c2 c3 … cN cN+1 … cN+4

new IV for each frame

Figure 7.8-new1: 802.11 WEP protocol

Security 8-59
WEP decryption overview
encrypted

Key
IV data ICV
ID

MAC payload
 receiver extracts IV
 inputs IV, shared secret key into pseudo random generator,
gets keystream
 XORs keystream with encrypted data to decrypt data +
ICV
 verifies integrity of data with ICV
• note: message integrity approach used here is different
from MAC (message authentication code) and
signatures (using PKI).

Security 8-60
End-point authentication w/ nonce
Nonce: number (R) used only once –in-a-lifetime
How to prove Alice “live”: Bob sends Alice nonce, R. Alice
must return R, encrypted with shared secret key

“I am Alice”

R
KA-B(R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it must be
Alice!
Security 8-61
WEP authentication
authentication request

nonce (128 bytes)

nonce encrypted shared key

success if decrypted value equals nonce

Notes:
 not all APs do it, even if WEP is being used
 AP indicates if authentication is necessary in beacon frame
 done before association
Security 8-62
Breaking 802.11 WEP encryption
security hole:
 24-bit IV, one IV per frame, -> IV’s eventually reused
 IV transmitted in plaintext -> IV reuse detected
attack:
• Trudy causes Alice to encrypt known plaintext d1 d2 d3 d4 …
• Trudy sees: ci = di XOR kiIV
• Trudy knows ci di, so can compute kiIV
• Trudy knows encrypting key sequence k1IV k2IV k3IV …
• Next time IV is used, Trudy can decrypt!

Security 8-63
WPA: 802.11i: improved security
 Wifi Protected Access
 Developed/certified by Wifi Alliance
(manufacturers)
 numerous (stronger) forms of encryption possible
than WEP.
 provides key distribution
 uses authentication server separate from access
point
 Each client has a different key
 But has serious vulnerabilities
(https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access)

Security 8-64
802.11i: four phases of operation
AP: access point
STA: AS:
wired
client station Authentication
network
server

1 Discovery of
security capabilities

2 STA and AS mutually authenticate, together

generate Master Key (MK). AP serves as “pass through”

3 STA derives
Pairwise Master 3 AS derives
same PMK,
Key (PMK)
sends to AP

4 STA, AP use PMK to derive

Temporal Key (TK) used for message
encryption, integrity
Security 8-65
EAP: extensible authentication protocol
 EAP: end-end client (mobile) to authentication server
protocol
 EAP sent over separate “links”
• mobile-to-AP (EAP over LAN)
• AP to authentication server (RADIUS over UDP)

wired
network

EAP TLS
EAP
EAP over LAN (EAPoL) RADIUS
IEEE 802.11 UDP/IP
Security 8-66
WPA2
 Introduced 2004 to fix the bugs in WPA
 Adds AES encryption,
 Standard since 2006

 Numerous brute forcing attacks now available.

 To be replaced (WPA3 2018)

Network Security
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity
8.4 Securing e-mail
8.5 Securing TCP connections: SSL
8.6 Network layer security: IPsec
8.7 Securing wireless LANs
8.8 Operational security: firewalls and IDS

Security 8-68
Firewalls
firewall
isolates organization’s internal net from larger Internet,
allowing some packets to pass, blocking others

administered public
network Internet
trusted “good guys” untrusted “bad guys”
firewall
Security 8-69
Firewalls: why
prevent denial of service attacks:
 SYN flooding: attacker establishes many bogus TCP
connections, no resources left for “real” connections
prevent illegal modification/access of internal data
 e.g., attacker replaces CIA’s homepage with something else
allow only authorized access to inside network
 set of authenticated users/hosts
three types of firewalls:
 stateless packet filters
 stateful packet filters
 application gateways

Security 8-70
Stateless packet filtering
Should arriving
packet be allowed in?
Departing packet let
out?

 internal network connected to Internet via router firewall

 router filters packet-by-packet, decision to forward/drop
packet based on:
• source IP address, destination IP address
• TCP/UDP source and destination port numbers
• ICMP message type
• TCP SYN and ACK bits
Security 8-71
Stateless packet filtering: example
 example 1: block incoming and outgoing datagrams with
IP protocol field = 17 and with either source or dest port
= 23
• result: all incoming, outgoing UDP flows and telnet
connections are blocked
 example 2: block inbound TCP segments with ACK=0.
• result: prevents external clients from making TCP
connections with internal clients, but allows internal
clients to connect to outside.

Security 8-72
Stateless packet filtering: more examples
Policy Firewall Setting
No outside Web access. Drop all outgoing packets to any IP
address, port 80
No incoming TCP connections, Drop all incoming TCP SYN packets
except those for institution’s to any IP except 130.207.244.203,
public Web server only. port 80

Prevent Web-radios from eating Drop all incoming UDP packets -

up the available bandwidth. except DNS and router broadcasts.

Prevent your network from being Drop all ICMP packets going to a
used for a smurf DoS attack. “broadcast” address (e.g.
130.207.255.255).
Prevent your network from being Drop all outgoing ICMP TTL expired
tracerouted traffic

Security 8-73
Access Control Lists
ACL: table of rules, applied top to bottom to incoming packets:
(action, condition) pairs: looks like OpenFlow forwarding (Ch.
4)!
source dest source dest flag
action protocol
address address port port bit
outside of any
allow 222.22/16 TCP > 1023 80
222.22/16
allow outside of 222.22/16
TCP 80 > 1023 ACK
222.22/16
outside of
allow 222.22/16 UDP > 1023 53 ---
222.22/16
allow outside of 222.22/16
UDP 53 > 1023 ----
222.22/16
deny all all all all all all

Security 8-74
Stateful packet filtering
 stateless packet filter: heavy handed tool
• admits packets that “make no sense,” e.g., dest port = 80,
ACK bit set, even though no TCP connection established:

source dest source dest flag

action protocol
address address port port bit
allow outside of 222.22/16
TCP 80 > 1023 ACK
222.22/16

 stateful packet filter: track status of every TCP connection

• track connection setup (SYN), teardown (FIN): determine
whether incoming, outgoing packets “makes sense”
• timeout inactive connections at firewall: no longer admit
packets
Security 8-75
Stateful packet filtering
ACL augmented to indicate need to check connection state table
before admitting packet

source dest source dest flag check

action proto
address address port port bit conxion
outside of any
allow 222.22/16 TCP > 1023 80
222.22/16

allow outside of 222.22/16

TCP 80 > 1023 ACK x
222.22/16

outside of
allow 222.22/16 UDP > 1023 53 ---
222.22/16

allow outside of 222.22/16 x

UDP 53 > 1023 ----
222.22/16

deny all all all all all all

Security 8-76
 Application gateways
 filter packets on host-to-gateway
application data as well as telnet session application
gateway
on IP/TCP/UDP fields. router and filter

 example: allow select

internal users to telnet
outside gateway-to-remote
host telnet session

1. require all telnet users to telnet through gateway.

2. for authorized users, gateway sets up telnet connection to
dest host. Gateway relays data between 2 connections
3. router filter blocks all telnet connections not originating
from gateway.
Security 8-77
Limitations of firewalls, gateways
 IP spoofing: router can’t
know if data “really”
comes from claimed
source
 if multiple app’s. need
special treatment, each has
own app. gateway
 client software must know
how to contact gateway.
• e.g., must set IP address
of proxy in Web
browser
 filters often use all or
nothing policy for UDP
 tradeoff: degree of
communication with
outside world, level of
security
 many highly protected
sites still suffer from
attacks
Security 8-78
Intrusion detection systems
 packet filtering:
• operates on TCP/IP headers only
• no correlation check among sessions
 IDS: intrusion detection system
• deep packet inspection: look at packet contents (e.g.,
check character strings in packet against database of
known virus, attack strings)
• examine correlation among multiple packets
• port scanning
• network mapping
• DoS attack

Security 8-79
Intrusion detection systems
multiple IDSs: different types of checking at
different locations

firewall

internal
network
Internet

IDS Web DNS

server FTP server
sensors server demilitarized
zone

Security 8-80
Network Security (summary)
basic techniques…...
• cryptography (symmetric and public)
• message integrity
• end-point authentication
…. used in many different security scenarios
• secure email
• secure transport (SSL)
• IP sec
• 802.11
operational security: firewalls and IDS

Security 8-81