sect.05--ch7--net_security-part2x - Computer Science - Western ...

doctorheavenlyNetworking and Communications

Oct 24, 2013 (3 years and 7 months ago)

90 views

CS
5
70
0


Computer

Security

and Information Assurance



Section 5:
Security in Networks


Part
2


This version of Section 5
includes

OPTIONAL slides that you may
SKIP

Dr. Leszek Lilien

Department of Computer Science

Western Michigan University


Slides based on
Security in Computing. Third Edition

by Pfleeger and Pfleeger.

Using some slides courtesy of:

Prof. Aaron Striegel


course taught at U. of Notre Dame

Prof.
Barbara Endicott
-
Popovsky

and Prof.
Deborah
Frincke

(U. Idaho)


taught at U. Washington

Prof. Jussipekka Leiwo


taught at
Vrije

Universiteit

(Free
U.
)
, Amsterdam, The Netherlands


Slides not created by the above authors are
©

2006
-
2010

by Leszek T. Lilien

Requests to use original slides for non
-
profit purposes will be gladly granted upon a written request.

2

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien

Covered earlier (in Section 2):

Security in Networks


Part 1


Outline

(1)

Outline of Part

1
of
Security in Networks

(covered in Section 2)


2
.1. Network Concepts

a)
Introduction

b)
The network

c)
Media

d)
Protocols

e)
Types of networks

f)
Topologies

g)
Distributed systems

h)
APIs

i)
Advantages of computing networks


2
.2. Threats in Networks

a)
Introduction

b)
Network vulnerabilities

c)
Who attacks networks?

d)
Threat precursors

e)
Threats in transit: eavesdropping and wiretapping

f)
Protocol flaws

3

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien

Covered earlier (in Section 2):


Security in Networks


Part 1


Outline

(2)


2
.2.

Threats in Networks
-

ctd

g)
Types of attacks

g
-
1) Impersonation

g
-
2) Spoofing

g
-
3) Message confidentiality threats

g
-
4) Message integrity threats

g
-
5) Web site attacks

g
-
6) Denial of service

g
-
7) Distributed denial of service

g
-
8) Threats to active or mobile code

g
-
9) Scripted and complex attacks

h)
Summary of network vulnerabilities



4

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien

Security in Networks


Part
2



Outline

(1)

Outline of Part

2

of
Security in Networks

(covered here)

5.
1
.

Network Security Controls

a)
Introduction

b)
Security threat analysis

c)
Impact of network architecture/design and implementation

on security

d)
Encryption

i.
Link encryption vs. end
-
to
-
end (e2e) encryption

ii.
Virtual private network (VPN)

iii.
PKI and certificates

iv.
SSH protocol

v.
SSL protocol (a.k.a. TLS protocol)

vi.
IPsec protocol suite

vii.
Signed code

viii.
Encrypted e
-
mail

e)
Message content integrity controls

i.
Error correcting codes

ii.
Cryptographic checksum

f)
Strong authentication

i.
One
-
time passwords

ii.
Challenge
-
response systems

iii.
Digital distributed authentication

iv.
Kerberos

authentication system


5

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien

Security in Networks


Part
2



Outline

(2)


5.
1
.

Network Security Controls

ctd.


g)
Access controls

i.
ACLs on routers

ii.
Firewalls

h)
Intrusion Detection Systems:
a
larms and alerts

i)
Honeypots

j)
Traffic flow security

k)
Review of network security controls


5.
2
.

Network Security Tools

5.
2
.1.

Firewalls

a)
Introduction

b)
What is a firewall

c)
Firewall

design

d)
Types of firewalls


i.
Packet filters


(i
-
1)

Simple packet filters


(i
-
2)

Stateful packet filters


ii.

Application proxies

(ii
-
1)

Guards

(“top model” subcategory)


iii.

Personal firewalls

e)
Comparison of firewall types

f)
Example firewall configurations

g)
What firewalls can

and can’t

block


6

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien

Security in Networks


Part
2



Outline

(
3
)


5.
2
.

Network Security Tools

ctd.

5.
2
.
2
.

Intrusion Detection Systems

a)
Introduction

b)
Types of IDSs

i.
Signature
-
based IDSs

ii.
Anomaly
-
based IDSs

iii.
Other

IDSs

c)
Goals for IDSs

d)
IDS strengths and limitations



5.
2
.3.
Secure E
-
Mail

a)
Introduction

b)
Security for e
-
mail

c)
Design of PEM

(Privacy
-
enhanced Electronic Mail)

d)
Example secure e
-
mail systems

i.

PGP

ii.

S/MIME


7

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





5
.

Network Security


Part 2



Part

1

of
Security in Networks

was covered in
lecture
Section 2



Part

2

of
Security in Networks

is covered
in this lecture
Section 5
, as follows:


5.
1
.

Network Security Control
s


5.
2
.

Network Security Tools



8

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





5
.
1
. Networks Security Controls


Outline

a)
Introduction

b)
Security threat analysis

c)
Impact of network architecture/design and
implementation on security

d)
Encryption

e)
Content integrity

f)
Strong authentication

g)
Access controls

h)
Alarms and alerts

i)
Honeypots

j)
Traffic flow security

k)
Controls review

9

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





a.
Introduction



There are
many security controls:


For p
rogram
s
ecurity (incl. s/w engineering issues)


For
OS
s
ecurity



Many of these strategies are useful for network security

as
well


We will now look for
security controls

designed specifically
for computer
network
s


10

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





b. Security threat analysis (1)



Threat analysis

steps :

1)

Analyze system components and their interactions

2)

Analyze possible damage to C
-
I
-
A

3)

Hypothesize possible kinds of attacks



Network elements
to be considered:


Local elements


Nodes / comm links / data storage / processes / devices / LANs


Non
-
local elements


Gateways / comm links / control resources / routers / network
resources (e.g., databases)


11

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Security threat analysis (2)



Network threats:


Accessing pgms or data at remote host


Modifying pgms or data at remote host


Running a pgm at a remote host



Interception of data in transit


Modifying data in transit


Insertion of data into communication traffic


Incl. replaying previous communication


Blocking selected/all traffic



Impersonation of entities



Attack enablers:


Size / anonymity / ignorance / misunderstanding


Complexity / motivation / programming skills

12

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





c. Impact of network architecture/
design & implement. on security
(1)




Security principles

for good analysis, design,
implementation, and maintenance
(as discussed in sections on
Pgm Security and OS Security)

apply to networks




Architecture can improve security
by:

1)

Segmentation

2)

Redundancy

3)

Single points of failure

4)

Other means

13

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Impact of network architecture/ design & implement. on security (2)


1)
Segmentation



Architecture should use segmentation to

limit scope of
damage caused by network penetration by:


Reducing number of threats


Limiting amount of damage caused by single exploit


Enforces least privilege and encapsulation




Example 1:

component segmentation


Placing different components of e
-
commerce system
on different hosts


Esp. put on separate host most vulnerable system
components


E.g., separate host for web server (w/ public access)


Exploit of one host does not disable entire system

14

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Impact of network architecture/ design & implement. on security (3)




Example 2:

access separation


Separating from each other:


Production system


Testing system


Development system


E.g., no developer has access to production system


and no customer has access to development system


15

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Impact of network architecture/ design & implement. on security (4)



2)

Redundancy



Architecture should use redundancy to

prevent losing
availability due to exploit/failure of a single network
entity


Example
: having a redundant web server (
WS
) in a
company




Types

of redundancy include:


Cold spare



e.g.,

when WS fails, replace it manually
with spare WS


Warm spare


e.g.,

failover mode

= redundant WSs
periodically check each other


Hot spare



e.g., 3 WSs configured to perform

majority voting


16

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Impact of network architecture/ design & implement. on security (5)


3)

Single points of failure

(
SPF
)



Architecture should eliminate SPFs to

prevent losing availability
due to exploit/failure of a single network entity


Using redundancy is a special case of avoiding SPFs



Network designers must analyze network to eliminate all
SPFs


Example of avoiding SPF (
without

using redundancy)


Distribute 20 pieces of database on 20 different
hosts
(so called
partitioned database
)


Even if one host fails, 95% of database contents
(19/20=95%)

still available



Elimination of SPFs (whether using redundancy or not)
adds cost

17

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Impact of network architecture/ design & implement. on security (6)


4)

Other architectural means
for improving security


Will be mentioned below as we discuss more network
security controls


18

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





d. Encryption



Arguably most important/versatile tool for network security



We have seen that it can be used for:


Confidentiality/Privacy


Authentication


Integrity


Limiting data access



Kinds

of encryption in networks:

i.
Link encryption vs. end
-
to
-
end (e2e) encryption

ii.
Virtual private network (VPN)

iii.
PKI and certificates

iv.
SSH protocol

v.
SSL protocol (a.k.a. TLS protocol)

vi.
IPsec protocol suite

vii.
Signed code

viii.
Encrypted e
-
mail

19

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





(i) Link vs. end
-
to
-
end encryption
(1)


1)
Link encryption

= between 2
hosts


Data encrypted just before they are placed on physical
communication links


At OSI Layer 1 (or, perhaps, Layer 2)



Fig. 7
-
2
0
, p. 4
45
(ed.4)


Properties

of link encryption (cf. Fig. 7
-
2
0
)


Msgs/pkts
unprotected

inside S’s/R’s host


I.e., unprotected at OSI layers 2
-
7 of S’s/R’s host
(in plaintext)



Packets
protected

in transit between
all

hosts


Pkts
unprotected

inside intermediate hosts


I.e., unprotected at OSI layers 2
-
3 of interm. hosts


=> unprotected at
data link and network layers

at
intermediate hosts
(if link encryption at Layer 1)


Layers 2
-
3 provide
addressing and routing

20

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Link vs. end
-
to
-
end encryption (2)



Link encryption is transparent
(invisible)

to users, their
applications, and their OSs


Encryption service provided by physical
(or data)

layer


Can use encryption h/w
(link encryption device)



Message under link encryption


Fig. 7
-
2
1
, p. 4
46

(ed.4)


See which portions encrypted, which exposed


Only part of data link header & trailer created after
encryption is exposed



Link encryption is useful when transmission line is most
vulnerable in a network


I.e., when S’s host, intermediate hosts, R’s host are reasonably
secure
(so msgs/pkts at their Layers 2
-
7 can be exposed)


21

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Link vs. end
-
to
-
end encryption (3)



2) End
-
to
-
end encryption

= between 2
user

applications


Data encrypted as „close” to app as possible


At OSI Layer 7 (or, perhaps, Layer 6)



Fig. 7
-
2
2, p.447
(ed.4)


Properties

of e2e encryption (c
ompare

vs.
Fig. 7
-
2
0
-
ed.4
)


Msgs/pkts
protected

all the way once they „exit” S’s
app & before they enter R’s app


Msgs/pkts
protected
(in ciphertext)

inside S’s/R’s host


Packets
protected

in transit between S’s & R’s
hosts


Including
protection
inside intermediate hosts


I.e.,
protected

at OSI layers 1
-
3 of interm. hosts


Layers 1
-
3 provide
physical connectivity, addressing and
routing

for packets

22

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Link vs. end
-
to
-
end encryption (4)



E2e encryption is visible either to users or their apps


Encryption service provided by app or OS

Possibly provided only upon explicit user’s request => visible to
user


Encryption by s/w



Message under e2e encryption


Fig. 7
-
2
3, p.447
(ed.4)

(compare vs. Fig. 7
-
21
-
ed.4
)


See which portions encrypted, which exposed


Only user’s msg (user’s data) encrypted


All headers & trailers exposed (all created after
encryption)



E2e encryption is useful when transmission lines
and

intemediate hosts are insecure



23

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Link vs. end
-
to
-
end encryption (5)



Comparison
of link vs. e2e encryption


Encryption of msgs/packets
(whether link or e2e
encryption)

is no silver bullet


No guarantees of msg/packet security


1)

Link encryption



encrypts all traffic over physical link


Typically host
H

has one link into network


=> link encryption encrypts all H’s traffic



Every H

incl. intermediate hosts


receiving traffic
via link encryption must have decryption capabilities


Either (pairs of) hosts share symmetric key

OR


Hosts use asymmetric keys



All hosts along a path from S to R must provide link
encryption to prevent
(„partial”)

packet exposure


=> usu. link encryption provided on all network links

24

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Link vs. end
-
to
-
end encryption (6)


2)

End
-
to
-
end (e2e) encryption



encrypts traffic only
between 2 apps
(„virtual crypto channel between 2 apps”)


Interm. hosts don’t need to decrypt
-
encrypt pkts


=> interm. hosts don’t need encryption facilities


All interm. hosts save time/processing


Can e
ncrypts
only some
msgs between 2 apps


If no need to encrypt all msgs => even S’s and R’s hosts
save time/processing


If needed, can encrypt all msgs


Using asymmetric keys requires fewer keys than
using symmetric keys
(n key pairs vs. n*(n
-
1)/2 keys)


25

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Link vs. end
-
to
-
end encryption (7)



Comparison

conclusions


Link

encryption:


Faster


Easier to use


Uses fewer keys
(1 K pair per host pair vs. 1 K pair per app pair)



End
-
to
-
end

(
e2e
) encryption:


More flexible


More selective
(can select only some msgs for encryption)


User
-
level, can be integrated with app



Optimize

whether link or e2e encryption better for you


If needed for higher security, use link
and

e2e encryption
together


E.g., user not trusting network link encryption can use
app with e2e encryption

26

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





(ii) Virtual private network (VPN)
(1)


Virtual private network (VPN)
= connection over public
network giving its user impression of being on private
network


It could be viewed as „logical link” encryption


Could be viewed as e2e encr. between client & server


Protecting remote user’s connection with her network


Greatest risk for remote connection via public network:


Between user’s workstation (client) and perimeter of
„home” network (with server)








Firewall

protects network against external traffic
(more later)


Physically Protected Network Perimeter



Firewall



Internal

Server

User’s

Workstation

(
Client
)

27

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Virtual private network (VPN) (2)



Example
VPN connection scenario












VPN restricts

/

filters access to „home” server/network


Only „private” accesses allowed


=> public network access feels like private network

1



C authenticates to firewall



(firewall passes user’s authentic. data to authentic. server [not



shown], which decides whether authentication is OK)

2


Firewall replies with encryption key



(after negotiating with C a session encryption key)

3



C and S communicate via encrypted
tunnel

Physically Protected Network Perimeter



Firewall



1

2

3

Internal

Server

User’s

Workstation

(
Client
)

28

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





(iii) PKI and certificates

(1)


Public key
infrastructure

(
PK
I
) = enables use of public key
cryptography
(asymmetric cryptography)


Usually in large & distributed environment




Elements
of PKI:

1)

Policies

(higher level than procedures)


Define rules of operation


E.g., how to handle keys and sensitive info


E.g., how to match control level to risk level


2)

Procedures

(lower level than policies)


Dictate how keys should be generated, managed,
used


3)

Products


Implement policies and
procedures


Generate, store, manage keys

29

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





PKI and certificates (2)


PKI
certificate
services:

1)

PKI
creates

certificates


Certificate

binds entity’s identity to entity’s public key


Entity = user or system or application

or ...

2)

PKI
gives out
certificates from its database

3)

PKI
signs

certificates


Adding its credibility to certificate’s authenticity

4)

PKI
confirms/denies validity
of a certificate


When queried about it

5)

PKI
invalidates
/
revokes

certificates


For entities that are no longer certified by PKI

OR


For entities whose private key has been exposed


30

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





PKI and certificates (3)


PKI
sets up:

1)

Certificate authorities (CAs)

2)

Registration authority


1)

Certificate authority

(
CA
)


CA can be in
-
house or external


E.g., c
ommercial
TTP

as the

trusted third party


CA is
trusted


Entities delegate to CA creation, issuance, acceptance, and
revocation of their certificates


CA
actions
:


Managing

public key certificates
(whole life cycle)


Issuing

certificates by binding entity’s identity to its
public key


Binding is done via CA’s digital signature


Determining expiration
dates for certificates


Revoking

certificates when necessary


By publishing
revocation lists

31

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





PKI and certificates (4)


Example of
CA analog
:

credit card company (
CCC
)


Certificate analog: credit card
(binds identity to account)


Revocation list analog: lists of invalid credit cards


CCC is
trusted


Customers delegate to CCC creation, issuance, acceptance,
and revocation of their credit cards


CCC
actions

(cf. “CA actions” on the previous slide):


Managing

credit cards
(whole life cycle)


Issuing

credit cards by binding customer’s identity
to customer’s account


Binding is done via CCC’s protected databases


Determining expiration
dates for credit cards


Revoking

credit cards when necessary


By checking list of invalid credit cards



(before computer
-
verification transaction era, CCC



published booklets of invalidated credit cards)

32

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





PKI and certificates (5)


2)

Registration authority

(
RA
)

=
interface
between user and CA


Duties:


Capture and authenticate user’s identity


Submit certificate requests to appropriate CA



Analog
: U.S. Citizen applying for passport and U.S.
Postal Service (USPS)



Passport (official U.S. authentication) <
-
> certificate


USPS authenticates citizen


By verifies citizen’s driver license + other proofs of identity


USPS submits passport request forms to appropriate
passport office of the U.S. Gov’t


Passport office <
-
> CA


USPS brings passport to customer’s home



Note: Trustworthiness of USPS authentication
determines level of trust that can be placed in
passports

33

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





PKI and certificates (6)


PKI efforts
stateside and overseas


Building PKI for various purposes


E.g.,
Federal PKI Initiative



to provide secure
communication to U.S. gov’t agencies


It also specifies how commercial s/w using PKI
should operate
(so gov’t can use off
-
the
-
shelf products)


Major PKI product
vendors

in the U.S.:


Baltimore Technologies


Northern Telecom/Entrust


Identrus



Certificates can bind:


Identity to public key



classic, most common


Other

bindings under research


E.g., binding financial status to key (credit card companies)


Draft standards:

ANSI X9.45, Simple Public Key
Infrastructure (SPKI)


34

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





PKI and certificates (7)



PKI is not yet mature


Many outstanding issues


Cf. Table 7
-
6, p. 4
53

(ed.4)


Still, many points are clear
:


CA should be approved/verfied by independent body


CA’s private keys must be stored in tamper
-
resistant
security module
(maybe with h/w support)


Access to CAs and RAs should be tightly controlled


Using strong authentication (e.g., 2FA or 3FA with smart cards)

35

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





(iv) SSH protocol
(SSH = Secure SHell)


SSH protocol

(newer: v.2)


provides authenticated and
encrypted
communication with

shell/OS
command
interpreter


Originally defined for Unix


Replaced insecure utilities for remote access


Such as Telnet / rlogin / rsh



Protects against spoofing attacks
(falsifying one end of
communication, incl. masquerading, sesssion hijacking, MITM)

&
message modification / falsification



Involves
negotiation

between local and remote sites


Negotiate which
encryption

algorithm to use


E.g., DES? IDEA? AES?


Negotiate which
authentication

technique to use


E.g., public key? Kerberos?

36

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





(v) SSL protocol (a.k.a. TLS prot.)

(1)


SSL protocol

(v3)

=
(approx.)

TLS protocol

-

interfaces
betwen app
on
client

C
and TCP/IP
protocols


P
rovide
s: (1)

server

S authentication,
(2)
optional

C
authentication
,
and
(3)
encrypted
communication
channel between C and S for
session

between C and S


SSL

= Secure Sockets Layer /
TLS

= Transport Layer Security



Originally defined by Netscape to protect browser
-
to
-
server
communication


Simple but effective


most widely used secure commu
-
nication protocol on Internet
(incl. WWW browsers/servers)



Involves
negotiation

between C and S


Negotiate which
encryption

suite to use for session


E.g., DES? RC4 w/ 128
-
bit/40
-
bit key? RC2? Fortezza? [Bishop]


Negotiate which
hashing

technique to use for session


E.g., SHA1 or MD5?

37

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





SSL protocol (a.k.a. TLS protocol) (2)


SSL use
scenario
(handshake protocol)


C requests an SSL
session

by sending:
Hello
-
C, Rand
-
C
(random nr)
,
list

of cipher
(encryption)

algorithms & hash
algorithms known to C


Hash used to checksum messages


S responds with msgs including:
Hello
-
S, Rand
-
S,
cipher & hash algorithm selected by S
(from C’s list)

, S’s
certificate, K
PUB
-
S
,
[SKIP:

request for cert. fr. C
]


C can use S’s certificate
(X.509v3 cert.)

to verify S’s authenticity


[SKIP: C replies with:
C’s certificate
]


C returns „
pre
-
master secret

encrypted

under K
PUB
-
S


Pre
-
master secret
-

e.g., 48 random
bytes

if selected cipher is RSA
[Bishop
-
CompSec
-
A&S, p.296]






...continued...

38

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





SSL protocol (a.k.a. TLS protocol) (3)





...continued...



C and S calculate „
master secret
” using:


„Pre
-
master secret”


Constant strings ‘A’, ‘BB’ and ‘CCC’


Rand
-
C and Rand
-
S,


SHA hashing algorithm
[ibid, p. 294]


C and S switch to encrypted communication using
„master secret” as session key


C and S exchange application data for
the duration of
the
session
(i.e., for as long as they stay connected)



TLS is potentially vulnerable to MITM attacks

[Conklin et al., p.163]

39

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





(vi) IPsec protocol suite

(1)




IPsec

(
IP Security Protocol Suite
) =
standard for
securing
IP communications

by encrypting and/or authenticating all
IP packets



IPsec is
public

(published / scrutinized)



By design,
protects against

threats including:



spoofing
(incl. session hijacking)

/ eavesdropping



Choice of ciphers/hash protocols


Communicating parties
negotiate

which ones to use


IPsec defines
some ciphers/hash

as
required

in every
IPsec implementaion


40

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





IPsec protocol suite (2)



IPsec
provides security

at
IP

layer

in

IPv6
or
IPv4

[Stall.p.499]


IP versions:


IPv4

= v.4


older IP protocol version
(still in use)


IPv6

= v.6


newer IP protocol version


IPv6


larger address space


Developed
(1992
-
1998)

since IPv4 runs out of
address space




IPv4 has 32
-
bit source/destination addresses




IPv6 has 128
-
bit source/destination addresses


IPv6


also
other functional enhancements


To accommodate
faster networks


To accommodate mix of
multimedia data streams



IPsec

protects all layers above IP
layer
(where it „resides”)


In particular, protects TCP or UDP protocols


Protects „
automatically



Protects
transparently

(no modifications to TCP, UDP


needed)

41

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





IPsec protocol suite (3)



Basis of IPsec:
security association

(
SA
) = set of security
parameters for a secured
1
-
way

communication channel


2 SAs
needed
for 2
-
way
communication
[St,487]



Components

of SA:

1)
Encryption
algorithm

and „
mode




E.g., for DES, mode = CDC


cipher bloc chaining

2)
Encryption

key

3)
Encryption
params

(e.g., initialization vector for encryption)

4)
Authentication

protocol and key

5)
SA
lifespan


Allows long
-
running sessions to select new crypto key

6)
Address of opposite end

of SA
(source
<
---
> destination)

7)
Sensitivity level
of protected data


(e.g., unclassified / restricted /





confidential / secret / top secret)

42

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





IPsec protocol suite (4)



Security parameter index

(
SPI
)
-

data structure


Resides
on each host
H
running IPsec


Used to
select 1 of
n
H


SAs

that exist on H


Different SAs for concurrent communications with different
remote Hs




Fundamental IPsec

data structures
/

protocols

1)

AH

=
authentication header

/
AH protocol


For
authentication
-
only

IPsec service:


Authenticates S (sender )


2)
ESP

=
encapsulated security payload
/
ESP protocol


For
encryption
-
only

IPsec service

OR



For
combined

encryption/authentication


IPsec service

43

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





IPsec protocol suite (5)



IPsec can be used
for various crypto sessions
:


VPN


e2e
(incl. app 2 app)


For network mgmt
(e.g., for routing)



IPsec scenario


TCP layer
passes
conventional

TCP Header
&
Data

down
to IP layer


IP layer
calls
upon
IPsec

to
encapsulate

conventional

TCP
Header & Data into
ESP
(encapsulated security payload)


Fig. 7
-
2
7
, p. 4
55
(ed.4)


IP layer
:
-

a
dds IP Header


-

passes packet down to physical layer


Physical layer
adds Physical Header & Physical Trailer


44

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

IPsec protocol suite (6)


ESP structure


includes more than just TCP Header & Data



Fig. 7
-
2
8
, p. 4
56

(ed.4)


„authenticated”


portion
authenticated by IPsec
with
Authentication Data
(Auth. Data = kind of signature)


„encrypted”


portion

encrypted by IPsec


Fields

within ESP:

1)
SPI

(
unencrypted
)


index for security association
to be used for this pkt

2)
Sequence Number

(
unencrypted
)


sequential
number, prevents pkt replay attacks

3)
Payload Data



(part of)

data passed fr. TCP Layer

4)
Padding

/
Padding Length



padding necessary to
inflate pkt to required fixed size
(e.g., size required by
block cipher used for encryption)

5)
Next Header



type of data in Payload Data field

6)
SKIP:

Authentication Data

(
unencrypted
)




authenticates all above fields

45

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





IPsec protocol suite (7)


ISAKMP

(
Internet Security Association Key Management
Protocol
) =
key mgmt protocol
for IPsec


Key mgmt is always a critical element in crypto apps


ISAKMP is simple, flexible, scalable


Distinct key for

each I
P
sec
’s

SA
(
security association)



In IPsec, ISAKMP
implemented via IKE
(
ISAKMP Key
Exchange
)



IKE properties


Provides ways to
agree on

protocols, cipher and
authentication algorithms,
and
keys


E.g., agree as follows: protocol = EPS, cipher = triple DES;
authentication alg. = SHA
-
1; key used for session


Provides ways to
manage

protocols, cipher and
authentication algorithms, keys


Uses
key exchange protocol

(
based on Diffie
-
Hellman
scheme
)

46

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

IPsec protocol suite (8)



IKE key exchange scenario
(using Diffie
-
Hellman scheme)


X and Y know number g


X and Y choose large primes x and y, respectively


X send g
x

to Y / Y send g
y

to X


X calculates (g
y
)
x

/ Y calculates (g
x
)
y


Since (g
y
)
x

= (g
x
)
y

=>
X and Y share secret



Actual calculation is mod(n)


a bit more complex


X and Y exchange identities & certificates


Certificates authenticate identities


X and Y derive shared crypto key


X and Y enter security association

=> they establish session



IKE key exchange is
very efficient


Can be done in 2 messages if w/o authentication


Can be done in 4 messages if w/ authentication

47

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





vii. Signed code



Problem:
malicious active code


E.g., malicious code on a web site for downloads



Partial solution:
code signed by TTP
(trusted third party)



TTP
appends

digital
signature to
piece of
code


PKI

can be used by prospective code users
to validate

signature




Still
code

security

not guaranteed


E.g., March 2001 mistake of Verisign (CA)


Erronously issued two code
-
signing certificates to
impostors masquerading as Microsoft employees


Verisign detected mistake after almost 2 months


Customers who didn’t validate certificate
(by checking
Verisign’s certificate revocation list)

could still
trust

bad
certificates

48

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

viii. Encrypted e
-
mail



E
-
mail msgs


like a postard that everybody who handles it
between S and R can read


People use envelopes for confidentiality
(C in C
-
I
-
A)


We can „envelope” e
-
mail msgs by encrypting them



Encryption protects C and can protect I



Encryption is easy, establishing good key mgmt is difficult



2 basic key mgmt approaches:

1) Hierarchical certificate
-
based PKI solution


E.g., S/MIME

2) Use of flat, individual
-
to
-
individual key exchange


E.g., PGP



E
-
mail security
(incl. PGP and S/MIME)

will be discussed


soon

49

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

e) Msg content integrity
controls (1)


Content integrity verification

provided „for free” with
encryption


Since can’t perform
meaningful

data modification w/o decrypting it


But attacker can modify encrypted data to make it useless


E.g., changing a bit of data in packet


Threats

to msg content integrity

1)
Malicious modification that changes content


in a
meaningful

way

2)

Nonmalicious modification that changes content


in a way that is
not necessarily meaningful


3)


Malicious modification that changes content


in a way that is
not meaningful




NOTE: Different cases than in text!


Encryption can solve the toughest case: Case
(1)

above

EASIER

TO
PREVENT

OR
DETECT

50

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

Msg content integrity controls (2)



Msg content integrity controls #1:
DETECT


Error
detection and error
correction codes


As discussed before

(„Intro to Cryptology” section)


Simplest error detection code:
even
/
odd parity check


More complex error detection codes:


Hash codes
or
Huffman codes


Some detect multiple bit errors


Some also pinpoint which bits are incorrect


For

detecting/correcting

nonmalicious
changes


Does not matter whether accidentally „meaningful” or not


Can also stop some
malicious

attacks


Again does not matter whether msg changes „meaningful” or not


E.g., attackers not knowing which code used => can’t fool it


E.g., attacker manipulating 2 bits & thinking that we have 2

bit correction code fails if we have 3
-
bit correction code


More complex
error detection codes can stop tougher
attackers

51

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

Msg content integrity controls (3)



[SKIP]

Msg content integrity controls #2:
PREVENT or
DETECT


Cryptographic checksum

/
msg digest

/
hash


To prevent or
malicious
attacks on data



As discussed
before

(„Intro to Cryptology” section)


Can also detect
malicious
errors


Can also detect
nonmalicious
errors



Note that attacker can modify
:


Modify only data bits


Modify error prevention/detection mechanism

52

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





f) Strong authentication



Networked environments as well as both ends of
communication need authentication



Strong authentication controls include:

i.
One
-
time password
s

ii.
Challenge
-
response systems

iii.
Digital distributed authentication

iv.
Kerberos

authentication system



53

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

i.
One
-
time password
s (1)


One
-
time password (OTP) method


Controls wiretapping and spoofing


Prevents reuse of pwd captured by wiretapper


Strong authentication prevents spoofing (incl. masquerading,
session hijacking, MITM)


Each password used only once


„Thrown away” after use



OTP uses secretly maintained pwd list

OR


User has
password token
(
PT
)


= device to randomly generate new pwd
(e.g.)

every
minute


E.g., SecureID device from Security Dynamics


random # every
minute

54

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

One
-
time password
s (2)



Pwd generation for user U is based on time
synchronization with PT of this particular user U


Pwd changed in sync by both U’s PT and system
authenticating U


PTs of different users produce different pwd
sequences



Problems with OTP

1)

Attacker can steal/find PT
(device)

2)

One
-
minute
window of vulnerability



Wiretapper can reuse password for one minute


If PT generates new pwd once per minute

55

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

ii.
Challenge
-
response
systems



Challenge
-
response systems

solve OTP problems

1)

Solve problem of stolen/lost password tokens (
PTs
)



Solution: PT requires a PIN


Even if stolen by attacker, PIN protects „responses”

2)

Solve problem of window of vulnerability



Solution: New challenge for each use


Does not matter whether new use within
one minute

window or not



Challenge
-
response systems

can be viewed as more
sophisticated version of OTP



Problem:



Neither OTP or C
-
RS protect
user

from rogue system

56

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

iii.
Digital distributed
authentication

(1)



„Digital” from „
Digital

Equipment Corporation” (
DEC
)


Once a powerful computer company


Acquired
(1998)
by Compaq, which subsequently merged with Hewlett
-
Packard

(2002)


As of 2004 their product lines were still produced under H
P
name




In 1980s DEC recognized need for
authentication of
nonhuman entities
in distributed environment


E.g., mutual authentication of user query processor and
DB manager
(process)




Goals

of Digital distributed authentication:


Prevent server impersonation
(e.g., DB mgr impersonation)


Prevent interception/modific. of msgs between entities


Prevent replay of previous authentication

[Wikipedia]

57

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





[
---
SKIP
---
]

Digital distributed authentication

(2)



Architecture

of Digital distributed authentication (1989):


Each server S has K
PRIV
-
S


Corresponding K
PUB
-
S

available to any process that might
need authenticated channel to S


A to B communication uses K
PUB
-
B


B to A communication uses K
PUB
-
A


A and B use sequence #s to msg replay




B can establish secret
(symmetric)

session key K for
communication with A by:


Selecting key K


Sending E(K, K
PUB
-
A
) to A


From now on, A and B can exchange data encrypted
with K

58

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





iv.
Kerberos

authentication system (1)



Kerberos



system for authentication between intelligent
processes in distributed systems
(incl. C
-
S authentication)

[K. = guard dog
in Hades
(Greek mythology)]


Developed at MIT (1988+)



Design
goal
:


Enable systems to withstand attacks in distributed
systems



Basic idea
of Kerberos: Central server provides
tickets

to
requesting app


Ticket

is authenticated, non
-
forgeable, non
-
replayable
token


=>
Implemented as e
ncrypted data structure
naming
user U

and
service for which U has access permission
(also contains time value, control info)

59

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (
2a
)



Nodes involved:


User
U

(client)


Server
S
(with File
F

that U wants to read)


Kerberos Server
KS



distributes “
pre
-
tickets”


Having
pre
-
ticket

is needed before asking for ticket


Ticket
-
Granting Server
TGS



distributes
tickets



Real
-
life
analogy
:


U = a
fan

that wants to watch World Championship


Many more Us than available tickets


S =
game

that U wants to watch


Pre
-
ticket

= right to buy a ticket


KS =
lottery

that gives a “pre
-
ticket” to each winner


Pre
-
ticket

= right to buy a ticket


TGS =
box
-
office

that sells tickets only to Us that have
pre
-
tickets

60

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (2
b
)


User’s
Step 1
:
Establishing session w/ Kerberos



Fig. 7
-
29
, p.
4
62

(ed.4)

-

TGS

= Ticket
-
Granting Server /
KS

=
Kerberos server


U’s workstat’n sends
U’s identity to KS


KS
verifies

that U is authorized


KS sends 2 msgs:

1)

Msg to U
, which contains:
E(S
TGS
+ T
TGS
, pwd)


S
TGS



U’s session key
for session
with TGS


T
TGS



U’s ticket
for TGS


Enables U to

request service from
TGS

where
pwd

=

user’s pwd
(Note: used as encr
.

key by KS)

2)

Msg to TGS
, which contains:


E(
S
TGS

+
U’s identity
,
shared KS
/
TGS

key)


(
i.e.,
encrypted under key shared by KS

&
TGS
)


S
TGS



TGS’s session key
for session
with U

(same

as U’s session key for session with TGS)


If U’s workstation can decrypt E(S
TGS +
T
TGS
, pwd) using
its pwd, then U’s authentication succeeds

U

U

U

U

U

U

U

U

61

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (3)



Note: KS stores users’ pwds =>
no need to pass pwds
over network

between U’s workstation and KS


Security advantage!



User’s
Step 2
:
U a
ccess
es

services of distributed system


e.g., access file
F



Fig. 7
-
3
0
, p. 4
63
(ed.4)


Using
U’s ticket for TGS

(received fr. KS in Step 1)
, U sends
to TGS:



E(„request
R

for
U’s
ticket for accessing F
” , S
TGS
)


Note: S
TGS

(
U’s session key for session with TGS

obtained fr. KS



in Step 1)

is used to encrypt R


TGS verifies U’s access permission


...continued...

U

U

62

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (4)

...continued...


If verified OK, TGS returns to U message encrypted
under S
TGS
, which contains:

1)
U’s session key for

session with
F

(really: with F’s file
server)
= S
F

2)
U’s ticket for
accessing
F



Ticket is encrypted under
secret key
(„TGS
/
F key”)

known only to TGS and F’s file server


Ticket contains:


U’s authenticated identity
(TGS knows that S
TGS

is
U’s key

and nobody else’s


because KS sent to TGS
S
TGS

and U’s identity tied together in Step 1)


Identification of file F


Access rights (e.g., read permission)


F’s session key for F’s session with U

= S
F

(same
as U’s session key for session with F)


Ticket expiration date

U

U

U

U

U

63

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (5)


Strengths
of Kerberos:

1)
No pwds communicated over network


Pwd sent by user to Kerberos server only once & sent
outside the network
(e.g., in a letter)


User’s pwd is
not

sent from user’s workstation when it
initiates a session


User’s pwd stored only at Kerberos server



2)
Provides crypto protection against spoofing
(e.g.,
masquearding, session hijacking, MITM)


Each access request mediated by a
ticket
-
granting
service

(
TGS
)


TGS knows user’s identity based on authentication
performed initially by the server

64

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (6)


Strengths of Kerberos


cont.1


3)

Limits period of ticket validity
(this disables some long
-
term
attacks

e.g., brute force cryptanalysis)


Tickets contain timestamps used by servers to
determine ticket’s validity


Ticket validity period limits duration of „window of
opportunity” for attacker



4)

Prevents replay attacks


Each user’s request stamped with time of request


Servers compare timestamps of requests w/ current
time, accept requests only if they are close enough to
current time


Time
-
checking prevents most replay attacks


Since presentation of tickets by attackers will be delayed
more than presentation of tickets by legitimate users

65

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (7)


Strengths of Kerberos


cont.2


5)

Provides mutual authentication


Service user can be assured of any server’s authenti
-
city by requesting an authenticating response from S



6)

Uses public key technology for key exchange



66

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Kerberos

authentication system (8)



Weaknesses

of Kerberos system

1)

Requires continuous availability of trusted ticket
-
granting server (TGS)

2)

Server S’ authenticity requires trust between TGS & S

3)

Requires timely transactions
(too quick ticket expiration will
result in rejecting legitimate requests)

4)

Subverted workstation can replay user pwds

5)

Pwd guessing works
(attacker can send initial

Step 1


authentication request to Kerberos server, receive response, try to
decrypt response by guessing at pwd)

6)

Kerberos does not scale well
(due to system size might need
> 1 KS and/or TGS server; coordination and security problems if
more than one KS and/or more than one TGS is needed; cf.
Fig. 7
-
3
1
, p.450
-
ed.4
)

7)

Use of Kerberos requires compatibility of all apps in a
given computing environment
(to date few apps are
compatible with Kerberos; modifying apps to make them
compatible is not feasible)

67

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





g) Access controls (1)



Before user is allowed access to network resources, must
know:


Who

needs access =>
authentication


What

and
how

will be accessed =>
a
ccess control
s



Access controls include
:

1)
ACLs
(Access Control Lists)

on
r
outer

2)
Firewalls



68

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Access controls (2)


1)

ACLs on
r
outers

(ACL = Access Control List)


Router directs traffic:


To subnetworks it controls

OR


To other routers (for delivery to other subnetworks)



Routers convert
external

(network
-
wide)
IP address to
internal

(
sub
network
-
wide)

MAC address


Recall that MAC address is unique physical address of device’s
NIC

network interface card



Can put ACL on a r
outer to deny access to particular
host

D

from particular host

S


E.g., to prevent
spam

(flooding)

of D with packets from
S, router can delete all packets from S to D


It’s OK if router uses ACLs in a l
imited
ed way


Use sparingly: only
for
specific

&
known

threats


BUT
...

69

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Access controls (3)


...

Problems

with

putting
too many
ACLs

on routers:

(i)

Packet
-
checking overhead

for router


Router must check
each

packet against
each

ACL


a lot of work


=> degraded performance


More ACLs on router => more work


Routers are already busy just routing all packets
ingoing/outgoing to/from their subnets


(ii)

Logging

overhead

for router


To be able to detect spam, router must log source
addresses of packets


Then can analyze to see which source addresses produce
floods


Routers are designed to do only essential work


anything else is inefficient => logging on router is
inefficient => adds workload

70

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Access controls (4)



...

Problems with putting
too many
ACLs on routers
-
CONT.

(iii)

Inability

of router
to detect all spams


Because source addresses in
datagrams

(UDP
packets)

can be easily forged
(by attacker using UDP
protocol)


If attacker sends many datagrams with the
same

(repeated)

forged address, router with ACL
can

detect & block them


Otherwise
(i.e., if attacker sends datagrams with few
repeated forged addresses)
, router with ACL will
not

even detect being flooded


=> can
not

block flooding datagrams


71

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Access controls (5)


2)

Firewalls


Designed to do screening that routers can’t do efficiently


Because routers designed for routing
(of course!
)


Firewalls designed for access filtering


AND

auditing


AND

examining whole packets
(not only source/destination
IP/ MAC addresses

which is what routers do)




Firewalls will be discussed in detail later
(but very soon)

72

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





h) Intrusion Detection Systems:
A
larms &
A
lerts


Example of
2
-
layer network protection


Provided by router (Layer 1)
AND

firewall (Layer 2)


Fig. 7
-
3
2
, p. 4
69

(ed.4)



We can add
one more layer

of protection:


intrusion detection systems

(
IDS
) = device placed within
protected network for monitoring for illegitimate actions in
order to detect attacks in progress
(beginning, advanced)

or
after they have occurred


E.g.: Can detect reconaissance &
alert

sysadmin or secadmin,
raise
alarm
, thus preventing „real” attack

OR


Can detect that attack has already occurred & raise
alarm
,
starting system recovery actions


IDS is a.k.a.
IPS

=
intrusion

protection

system


A marketing gimmick?


IDS can be Layer 3 of layered network protection


To be discussed in detail soon

73

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





i) Honeypots



Honeypot



system built as a bait attracting attackers


Once attackers take the bait:


They are
observed

to learn how they behave/operate


New attacks / Prefered targets / ...


They are
traced

to catch them or scare them off


Or at least trace enough to be able to threaten them with
identifying them if they don’t stop


They are
diverted

from really valuable attack targets


E.g., diverted to
phony

credit card database while
real

credit
card database remains obscure to them



User lessons learned
(thanks to honeypots)

to build better
countermeasures

74

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





j) Traffic flow security (1)




Threat
: attacker infering occurrence/location of some event
/ structure from intensity of encrypted network traffic


(If not encrypted, no need to infer


attacker can simply read all)


Example 1: Inference that traffic between Thinges Corp. and
bankruptcy lawyer precedes declaration of bankruptcy by Thinges


Example 2 (old): Battlefield network: Busiest network node is at
enemy’s HQs




Solution 1:
Masking by steady traffic volume


X and Y always send the same volume of
encrypted

traffic between them


If X has nothing to communicate to Y, X sends
meaningless padding packets to Y
(Y behaves analogously)


75

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Traffic flow security (2)



Solution 2:
Masking by
onion routing


Example: W wants to send packet to Z in a hidden way


W wraps „real” packet to Z into packet addressed
to
Y
, which asks Y
to send it toZ


W wraps packet to Y into packet addressed
to X
,
which asks X
to send it to Y

Send packet to Z

Send packet to Y

Onion
-
like

packet sent by W to X



Full route: W


X


Y


Z





W sends
green

packet to X



X unwraps it, gets
red

packet


X sends
red

packet to Y



Y unwraps it, gets
blue

packet


Y sends
blue

packet to z



Z unwraps it, gets
blue

packet

76

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





Traffic flow security (3)


Why „
onion
” routing? Layers of wraps around „real”
packet to Y


like layers of an onion



Note:
(Recall the full route: W


X


Y


Z

)


X knows that packet came from W & should be
forwarded to Y


But X does
not

know if W is source or intermediate host,
does
not

know if Y is destination or intermediate host


Y knows that packet came from X & should be
forwarded to Z


But Y does
not

know if X is source or intermediate host,
does
not

know if Z is destination or intermediate host


Z knows that packet came directly from Y & knows
that W is its source


Z knows that Y is just an intermediate host


=> Intermediate nodes do
not

know source/destination


They only know host that forwarded packet to them &


know host to which they should forward packet

77

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





k) Review of network security controls


Table 7
-
4, p. 4
39

(ed.4)
provided classification of network
vulnerabilities
(during our earlier discussion of threats)


Table 7
-
7, p. 4
71

(ed.4)

lists
controls

for

each of these
classes of network vulnerabilities


it shows that:


There are many great network security controls


Most are used also in environments other than networks
(including applications and OSs)


Three

of these controls are
specific to networks
:


Firewalls
/

IDSs
/

encrypted e
-
mail


We shall discuss them in some detail next



Table 7
-
7 is a great reference for network security controls!


Use it often


If you can get copyright permission from publisher, I’d advise
you to copy it and post above your desk


Otherwise, make your own notes based on it

78

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





5.2
. Network Security Tools
















Network security tools


5.2
.1.

Firewalls


5.2
.2.

Intrusion Detection Systems


5.2
.3.

Secure E
-
Mail

[Fig: B.
Endicott
-
Popovsky
]

79

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





5
.
2
.1. Firewalls



Outline

a)
Introduction

b)
What is a firewall

c)
Firewall

design

d)
Types of firewalls

i.
Packet filters


(i
-
1)

Simple packet filters


(i
-
2)

Stateful packet filters

ii.
Application proxies

(ii
-
1)

Guards

(“top model” subcategory)

iii.

Personal firewalls

e)
Comparison of firewall types

f)
Example firewall configurations

g)
What firewalls can

and can’t

block

80

Section
5



Computer

Security

and Information Assurance

©

2006
-
2010
by Leszek T. Lilien





a. I
ntroduction



Firewalls


Invented in the early 1990’s


But

idea related to
reference monitors

from 1970’s



What is reference monitor?


OS includes
kernel
/
core
/
nucleous



responsible for lowest
-
level functions


Incl. synchronization, inter
-
process communication,


msg passing, interrupt handling


Security kernel