CS 5950/6030 Network Security Class 33 (W, 11/16/05)

Leszek Lilien Department of Computer Science Western Michigan University Based on Security in Computing. Third Edition by Pfleeger and Pfleeger.

Using some slides (as indicated) courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands Slides not created by the above authors are © by Leszek T. Lilien, 2005 Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

2 Class 32 7. Security in Networks 7.2. Threats in Networks 7.3. Networks Security Controls d) i.

ii.

Encryption iii.

iv.

v.

vi.

Link encryption vs. end-to-end (e2e) encryption Virtual private network (VPN) PKI and certificates SSH protocol SSL protocol (a.k.a. TLS protocol) IPsec protocol suite—PART 1 © by Leszek T. Lilien, 2005 e) f) vi.

vii.

IPsec protocol suite— PART 2 Signed code viii.

Encrypted e-mail Message content integrity controls i.

ii.

Error correcting codes Cryptographic checksum i.

Strong authentication ii.

iii.

iv.

One-time passwords Challenge-response systems Digital distributed authentication Kerberos

3 IPsec protocol suite (7)  © by Leszek T. Lilien, 2005   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 IPsec security association (SA)  In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange)   IKE properties Provides ways to agree on protocols, cipher and authentication algorithms, 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

4    © by Leszek T. Lilien, 2005

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

5     

[---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) soon will be discussed © by Leszek T. Lilien, 2005

6   

[---SKIP---] e) Msg content integrity controls (1)

© by Leszek T. Lilien, 2005  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

2) Nonmalicious modification that changes content in a way that is 3) Malicious modification that changes content in a way that is way

not necessarily meaningful not meaningful

EASIER TO PREVENT OR DETECT NOTE: Different cases than in text!

Encryption can solve the toughest case: Case (1) above



f) Strong authentication

Networked environments as well as both ends of communication need authentication  i.

ii.

Strong authentication controls include: One-time passwords Challenge-response systems iii.

iv.

Digital distributed authentication Kerberos authentication system 7 © by Leszek T. Lilien, 2005

8 © by Leszek T. Lilien, 2005

End of Class 32

9 Class 32 Class 33 7. Security in Networks 7.3. Networks Security Controls d) ...

e) f) © by Leszek T. Lilien, 2005 vi.

vii.

i.

ii.

iii.

iv.

IPsec protocol suite— Signed code / viii.

One-time passwords PART 2 Encrypted e-mail Message content integrity controls i.

Error correcting codes / ii.

Strong authentication Challenge-response systems Kerberos Cryptographic checksum Digital distributed authentication g) h) i) j) k) i.

ii.

Access controls ACLs on routers Firewalls Intrusion Detection Systems: alarms and alerts Honeypots Traffic flow security Review of network security controls

[UPDATED]  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 initiates a session sent from user’s workstation when it 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

service

( T-GS )

ticket-granting

T-GS knows user’s identity based on authentication performed initially by the server 10 © by Leszek T. Lilien, 2005

[UPDATED]  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 11 © by Leszek T. Lilien, 2005

[UPDATED]  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 12 © by Leszek T. Lilien, 2005

13 [REPEATED] Kerberos authentication system (8)  1) 2) Requires continuous availability of trusted ticket granting server (T-GS) Server S’ authenticity requires trust between T-GS & S 3) Requires timely transactions (too quick ticket expiration will result in rejecting legitimate requests) 4) Subverted workstation can replay user pwds 5) 6) 7) Weaknesses of Kerberos system Pwd guessing works (attacker can send initial —Step 1— authentication request to Kerberos server, receive response, try to decrypt response by guessing at pwd) Kerberos does not scale well (due to system size might need > 1 KS and/or T-GS server; coordination and security problems if more than one KS and/or more than one T-GS is needed; cf. Fig. 7-32, p.450

) Use of Kerberos requires compatibility of all apps in a given computing environment compatible is not feasible) (to date few apps are compatible with Kerberos; modifying apps to make them © by Leszek T. Lilien, 2005



g) Access controls (1)

  Before user is allowed access to network resources, must know: Who What needs access => authentication and how will be accessed =>

access controls

 Access controls include: 1) ACLs (Access Control Lists) 2) Firewalls on router 14 © by Leszek T. Lilien, 2005

15 Access controls (2) 1) ACLs on routers  (ACL = Access Control List) Router directs traffic:  OR To subnetworks it controls  To other routers (for delivery to other subnetworks)  Routers convert

external internal

(subnetwork-wide)  (network-wide) IP address to MAC address Recall that MAC address is unique physical address of device’s NIC—network interface card    Can put ACL on a router 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 limiteded way Use sparingly: only for BUT...

specific

&

known

threats © by Leszek T. Lilien, 2005

Access controls (3)  ... Problems with (i) putting too many ACLs on routers: 

Packet-checking overhead



each

for router Router must check packet against a lot of work => degraded performance More ACLs on router => more work

each

ACL –  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 16 © by Leszek T. Lilien, 2005

Access controls (4)  ... Problems with putting too many ACLs on routers-CONT.

(iii) Inability  of router to detect all spams Because source addresses in packets)

datagrams

(UDP 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 even detect being flooded

not

=> can

not

block flooding datagrams 17 © by Leszek T. Lilien, 2005

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) 18 © by Leszek T. Lilien, 2005

19  

h) Intrusion Detection Systems: alarms & alerts

  Example of 2-layer network protection Provided by router (Layer 1) AND firewall (Layer 2) Fig. 7-33, p. 452  We can add one more layer

intrusion detection systems

( of protection:

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 & raise alert sysadmin or secadmin, alarm , thus preventing „real” attack OR  Can detect that attack has already occurred & raise starting system recovery actions alarm ,  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 © by Leszek T. Lilien, 2005

 

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 card database remains obscure to them real credit User lessons learned (thanks to honeypots) countermeasures to build better 20 © by Leszek T. Lilien, 2005



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) 21 © by Leszek T. Lilien, 2005

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 Onion-like packet sent by W to X Send packet to Y Send packet to Z  Full route: W  X  Y  Z     W sends green packet to X X unwraps it, gets red packet X sends red Y unwraps it, gets Y sends blue packet to Y packet to z Z unwraps it, gets blue blue packet packet 22 © by Leszek T. Lilien, 2005

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 23 © by Leszek T. Lilien, 2005

  

k) Review of network security controls

Table 7-4, p. 426 provided classification of network vulnerabilities (during our earlier discussion of threats)    Table 7-7, p. 454 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 24 © by Leszek T. Lilien, 2005

25 © by Leszek T. Lilien, 2005

End of Class 32