254542 Networks Management and Security

1. 254542 Networks Management and Security Lecture 4

2. Authentication Protocols • A process of verifying that its communication partner is not an imposter • Authenticity does not mean authority • Alice and Bob are called principals • Authenticated based on.. • Shared secret key • trusted 3rd party = key distribution center (KDC)

3. Secret-key Authentication • Assuming A and B already share KAB • Based on challenges and responses • Ri = Challenge from the ith challenger • Ki = Key from the ith owner • KS = session key

4. A RB KAB(RB) RA KAB(RA) Authentication using a challenge-response protocol Alice Bob After all the responses, A can determine KS and send it to B in an encrypted form

5. Shortened authentication using challenge-response protocol A, RA Alice Bob RB, KAB(RA) KAB(RB) Is it secure?

6. Reflection Attack A, RT RB, KAB(RT) A, RB Trudy Bob RB2, KAB(RB) KAB(RB)

7. 3 Rules for Designing Authentication Protocol • Prove the initiator’s identity before the responder has to • Use different keys for the initiator and responder (i.e. KAB and K’AB) • The initiator and responder should use different sets of challenges (e.g. even and odd numbers)

8. Authentication Based on KDC • Previous protocol  key management problem • With KDC, each user has a single shared key • The simplest known protocol = wide mouth frog A, KA(B, KS) Alice KDC Bob KB(A, KS) What about a replay attack?

9. Solutions to the Replay Attack • Timestamp • Still vulnerable before a message is obsolete • Nonce (one-time, unique message number) • Each party has to remember nonces forever • Or a combination between nonce & timestamp

10. Needham-Schroeder Authentication Protocol RA, A, B KDC KA(RA, B, KS, KB(A, KS)) Alice Bob KB(A, KS), KS(RA2) KS(RA2 -1), RB KS(RB -1) RA = Nonce, KB(A, KS) = Ticket * Replay attack at message 3 with old KS

11. Otway-Rees Authentication Protocol A, B, R, KA(A, B, R, RA) A, KA(A, B, R, RA), B, KB(A, B, R, RB) Alice Bob KDC KB(RB, KS) KA(RA, KS)

12. Authentication using Kerberos • Developed by MIT, currently in version 5 • Widely used in real world • Assumes that all clocks are well synchronized • Involves 3 servers • Authentication Server (AS) verifies users during login • Ticket-Granting Server (TGS) issues “proof of identity tickets” • Bob the server performs work requested by Alice

13. Servers’ duties • AS • Shares a secret key with every user • Similar to KDC • TGS • Issues tickets to verify the identity of the TGS ticket bearer

14. Kerberos Operation A AS KA(KS, KTGS(A, KS)) KTGS(A, KS), B, KS(t) TGS Alice KS(B, KAB), KB(A, KAB) KB(A, KAB), KAB(t) Bob KAB(t+1) • Alice is asked for her password after message 2 arrives • Replay attack with message 3 doesn’t work

15. Kerberos in Real World • Still susceptible to password-guessing attack • Heighten security at the user end • PKI (public-key infrastructure) is being added into Kerberos • But still confined to initial requests to TGS (why?)

16. Intrusion Detection Systems (IDS) • Do not • Block or prevent attacks • Do • Notify the systems when they are being hacked • Host and Network IDS • NIDS mostly looks at the network traffic • Detecting potential attacks • Host IDS looks at host, OS, and application activities • Detecting attacks that already succeeded

17. IDS tools • Auditing • Detecting anomalous behaviors • Pattern matching and detecting • CERT (Computer Emergency Response Team) bulletin board • lists security problems that have been discovered and reported

18. Auditing • Logfile monitors • Host-based IDS scanning and analyzing logfile • Pattern searching • Integrity monitors • Watch key system structures (system files, registry keys, etc) for change • Establish a ‘known safe baseline” (pre-attack) • Should be deployed on a clean system

19. Signature Matchers • A stateful NIDS that detects attacks based on a database of known attack signatures • Stateful means that it can track fragmented TCP packets (and reassemble them) • Stateless deals with individual packets • E.g. snort (http://www.Snort.org), which is a freeware and open source

20. Anomaly Detectors • NIDS, which • establishes a baseline of “normal” system • alerts when a deviation occurs • sometimes categorized into “traffic anomalies” and “protocol anomalies” • Problem: Network traffic is constantly changing, especially in large networks • Hybrid into a more host-based IDS

21. Interesting Profiles Worth Watching • Login profile • Login/location frequency, last login • Session elapsed time, session output • Password fails, location fails • Command/Program execution • Execution frequency, Program IO, program CPU • Execution denied, Program resource exhaustion • File access activities • Read/write/delete/create frequency • Number of fails on read/write/delete/create • Number of records read/written • File resource exhaustion

22. Bayesian Analysis • Applied to NIDS for diagnosis purpose • NIDS problems • Keeping signature databases up to date • Coping with massive bandwidth (especially a stateful NIDS) • Capabilities limited in switched networks • Vulnerable to attacks (e.g. DoS)

23. Sensitivity vs. Specificity Intrusion + - • TP = true positive (intrusion correctly detected) • FP = false positive (false alarm) • FN = false negative (intrusion missed) • TN = true negative (integrity correctly detected) TP FP + IDS response - TN FN

24. Internet Corporate firewall Router LAN Web server Sensitivity • Sensitivity = True positives / (true positives + false negatives) • More sensitivity = Less likeliness to miss actual intrusions • For identifying attacks … • that should never be missed • on areas that are easy to fix • Best for “screening” (FN is more critical) • Should be implemented here

25. Internet Corporate firewall Router LAN Web server Specificity • Specificity = True negatives / (true negatives + false positives) • More specificity = Less likeliness to produce false alarms • Useful tools for network administrator • For identifying attacks … • on areas in which automatic diagnosis is critical • Best when… • consequences for false-positive results are serious • Should be implemented here

26. Internet Corporate firewall Router LAN Web server Accuracy • Accuracy = Percentage of all IDS results that are correct • Encompass both sensitivity and specificity • E.g. web server under constant attacks that needs • Screening for any slight anomaly • Automatic processes to deal with any incident (due to high traffic volume) • Can be achieved by combining layers of different IDSs

27. Hacking IDSs:Fragmentation • A.k.a. packet splitting • Most common attack against NIDSs • Splitting packets into smaller pieces • Difficult for analyses • Stateful IDSs can prevent this attack but • Consume a more resources and become less accurate as throughput increases

28. Hacking IDSs:Spoofing • Spoofing TCP sequence numbers • IDS becomes desynchronized from the host • And then ignores true data stream while waiting for a forged sequence number • IDS must be aware of the real target host

29. Hacking IDSs:Protocol Mutation • For example, a typical CGI-bin request is GET /cgi-bin/script.cgi HTTP/1.0 • If IDS scans for /cgi-bin/cgi_script • The attacker can modify the request to GET /cgi-bin/subdir/../script.cgi HTTP/1.0 “directory traversal” • Solution: • Normalize traffic to look more uniform

30. Hacking IDSs:Attacking Integrity Checkers • Integrity checkers • Initialize mode: compute checksum and collect information • Check mode: look for changes • Update mode: update signature after system reconfiguration • Attacks • Send wrong information • Compromise the system between checks • Hide tracks by “correcting” the system by itself

31. Encrypted traffic (IPSec) Increased speed and complexity of attacks Increased amount of data to interpret New evasion techniques New kernel-based attack Embed IDS throughout host stack Strict anomaly detection, optimized NIDS engines, intelligent pattern matching Visual display of data New traffic normalization techniques and deeper host awareness New kernel security mechanisms Future of IDSs Problem Solution