1. IPD - November 3, 2001John Kristoff - DePaul University1 Computer and Network Security John Kristoff jtk@depaul.edu +1 312 362-5878 DePaul University Chicago, IL 60604

2. IPD - November 3, 2001John Kristoff - DePaul University2 What are you trying to secure? • Confidentiality • Avoid snooping • Encryption? • Integrity • Deletes, changes • Backups • Availability • (D)DoS attacks • Authentication • Is that you? • Nonrepudiation • No denying it • Access control • Hands off! • Reputation • Name = MUD

3. IPD - November 3, 2001John Kristoff - DePaul University3 Internet security really bites • LOTS of hosts are hard to secure • Bad default configurations • Poor software implementations • Fixes/patches rarely applied • Average user/admin is security clueless • It is difficult to coordinate among sites • Any weak link can break the security chain

4. IPD - November 3, 2001John Kristoff - DePaul University4 Why doesn't telco security bite? Telco • Central authority • Network intelligence • Billing records per call • Legalese understood • Wiretapping laws • Circuit connections Internet • No central authority • End host intelligence • No packet accounting • Legalese fuzzy • Privacy issues • Ease of anonymity

5. IPD - November 3, 2001John Kristoff - DePaul University5 So where do you put security?

6. IPD - November 3, 2001John Kristoff - DePaul University6 Physical security • Trash bins • Social engineering • It's easier to trust a face/voice than a packet • Protect from the whoops! • Don't trip over the power cord • Don't spill your coffee • Hit the right switch • Software really can kill hardware

7. IPD - November 3, 2001John Kristoff - DePaul University7 End host security • The end-to-end argument • This is usually where the problem is • But, ultimately you want to protect data • End hosts are in control of data • Users are in control of hosts • Users often don't secure hosts sufficiently • There are LOT of hosts and LOTS of users

8. IPD - November 3, 2001John Kristoff - DePaul University8 Network security • Inspect and act on packets as they go • Boy, this is really hard! • Evasive tactics like tunneling get through • Uh-oh... encryption • What am I breaking? • Can I relay, inspect and act fast enough? • This might help, but its not a panacea

9. IPD - November 3, 2001John Kristoff - DePaul University9 Probably need layered defenses • The belt and suspenders approach • Attackers might hit a layer they can't break • Multiple layers tend to slow attacks down • Use the laws of statistics • If defense A stops 90% of all attacks, • And if defense B stops 90% of all attacks, • Then combined they may stop 99% of all attacks • (1-.9)*(1-.9) =.01, 1 -.01 =.99 or 99%

10. IPD - November 3, 2001John Kristoff - DePaul University10 The network is just a highway • How do you secure the highway • Police patrol • Toll booths • Licensed drivers • Vehicle inspections and standards • Rules of the road • Are the highways completely safe now?

11. IPD - November 3, 2001John Kristoff - DePaul University11 Perimeter security " Separate trusted net from untrusted net " Define the boundary

12. IPD - November 3, 2001John Kristoff - DePaul University12 What network firewalls do • Define untrusted and trusted boundaries • Inspect traffic traversing firewall boundary • Limit communication traversing boundary • Help shield insecure hosts

13. IPD - November 3, 2001John Kristoff - DePaul University13 Network firewalls illustrated

14. IPD - November 3, 2001John Kristoff - DePaul University14 Key ideas • Firewalls should be unnecessary • They're a network solution to a host problem • They don't solve the real problem and... •..make it hard/impossible to do certain things • Ultimate control of hosts is out of our hands • Securing a LOT of hosts is hard! • But.. network solutions are *sigh* necessary

15. IPD - November 3, 2001John Kristoff - DePaul University15 Packet filtering firewalls • Filter everything - not very useful • Filter by IP address • Filter by application type (TCP, UDP) • Filter on field/flag settings (source route) • Filter invalid packets (SYN/FIN packets) • Other pattern match

16. IPD - November 3, 2001John Kristoff - DePaul University16 Screened subnet implementation

17. IPD - November 3, 2001John Kristoff - DePaul University17 Application Layer Gateway (ALG) • Also commonly called a proxy firewall • These permit no direct communication • Firewall intercepts all traffic in each direction • Very intelligent device... •...must understand what a user is doing • Difficult to install if it doesn't currently exist

18. IPD - November 3, 2001John Kristoff - DePaul University18 Proxy/ALG illustrated

19. IPD - November 3, 2001John Kristoff - DePaul University19 Other common firewall features • Stateful inspection • Network address translation (NAT) • Authenticaton (VPNs) • Dynamic triggers • Reporting, logging and IDS support

20. IPD - November 3, 2001John Kristoff - DePaul University20 Example: Linux ipchains Don't want to see packets with private IP addresses -A input -s 192.168.0.0/255.255.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -A input -s 172.0.0.0/255.240.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -A input -s 10.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY Let SSH, established TCP connections, FTP data, UDP and BOOTP/DHCP in -A input -s 0.0.0.0/0.0.0.0 -d a.b.c.d/255.255.255.255 22:22 -p 6 -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d a.b.c.d/255.255.255.255 1024:65535 -p 6 ! -y -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 20:20 -d 0.0.0.0/0.0.0.0 1024:65535 -p 6 -y -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 1024:65535 -p 17 -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 67:67 -p 17 -j ACCEPT Drop any packets that don't have our source IP and log those attempts -A output -s 140.192.0.1/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l

21. IPD - November 3, 2001John Kristoff - DePaul University21 Example: Cisco ACL Block private IP addresses access-list 100 deny ip 192.168.0.0 0.0.255.255 any access-list 100 deny ip 172.0.0.0 0.15.255.255 any access-list 100 deny ip 10.0.0.0 0.255.255.255 any Block reserved, loopback and Class E IP addresses access-list 100 deny ip 0.0.0.0 0.255.255.255 any access-list 100 deny ip 127.0.0.0 0.255.255.255 any access-list 100 deny ip 224.0.0.0 31.255.255.255 any Block source port of 111 from going anywhere access-list 100 deny tcp any eq sunrpc any access-list 100 deny udp any eq sunrpc any Allow DNS and TELNET (log it) to 1.2.3.4, deny everything else access-list 100 permit tcp any host 1.2.3.4 eq domain access-list 100 permit tcp any host 1.2.3.5 eq telnet log access-list 100 deny ip any any

22. IPD - November 3, 2001John Kristoff - DePaul University22 What can't a network firewall stop? • Bad packets that look good • Denial of service (DoS) attacks • Well, they can stop them at the firewall • But then the firewall has just been DoS'd • Stupid user tricks • Things that go around the firewall • Things that don't cross the firewall boundary

23. IPD - November 3, 2001John Kristoff - DePaul University23 So you're saying...? • It would be nice if all hosts could be secured • Network solutions can help • Malicious insiders can get by anything you got • A holistic approach is needed. Including: • Audits, detection and response • Education • Standards and best practices

24. IPD - November 3, 2001John Kristoff - DePaul University24 Intrusion Detection Systems • Interesting, but immature technology • Provides lots of data/information • Generally doesn't interfere with communications • Anything that improves security...

25. IPD - November 3, 2001John Kristoff - DePaul University25 What is IDS? • Ideally, immediately identifies successful attacks • Should have a immediate notification system • Out-of-band from the attack if possible • Probably can also monitor attack attempts too • Might have attack diagnosis, recommendation and/or automated attack mitigation response • Lofty goals: • 0% false positive rate • 0% false negative rate

26. IPD - November 3, 2001John Kristoff - DePaul University26 Privacy issues • Does an IDS violate privacy? • Are packet headers (protocols) private? • Is identification (an address) private? • Are packet contents private (payload)? • Are communications (flows/sessions) private? • Where is the IDS? • Who manages the IDS? • How is the IDS data handled and managed?

27. IPD - November 3, 2001John Kristoff - DePaul University27 Storage, mining and presentation • IDSs can collect LOTS of information • What is useful data? • What are you looking for? • Data correlation within/outside of the IDS? • What does the admin see? • Where and for how long do you keep data? • How do you secure access to IDS data?

28. IPD - November 3, 2001John Kristoff - DePaul University28 Host IDS • An integral part of an end-system • System log monitor • Kernel level packet monitor • Application specific • A very good place to put security • Distributed management issues • Not all end systems will support an IDS • Will be as useful as the end user is cluefull

29. IPD - November 3, 2001John Kristoff - DePaul University29 Network IDS • An add-on to the communications system • Generally passive and invisible to the ends • May see things a host IDS cannot easily see • Fragmentation, other host attacks (correlation) • May not understand network traffic • Unknown protocols/applications, encryption • May miss things that don't cross its boundary

30. IPD - November 3, 2001John Kristoff - DePaul University30 Anomaly detection • A form of artificial intelligence • Learn what is normal for a network/system • If an event is not normal, generate alert • May catch new attacks not seen before • For a simple, but effective example see: • Detecting Backdoors, Y. Zhang and V. Paxson, 9 th USENIX Security Symposium • An area of active research

31. IPD - November 3, 2001John Kristoff - DePaul University31 Signature matching • Know what an attack looks like and look for it • Very easy to implement • Low false positive rate • Most current IDSs are of this type • Easy to fool • Signatures must be added/updated regularly

32. IPD - November 3, 2001John Kristoff - DePaul University32 Honeypots • A system that welcomes attacks • Unbeknownst to the attacker generally • The system is very closely monitored • Can be used to test new technology/systems • Generally educational in nature • Helpful as trend monitor for that system type • Be careful honeypot doesn't become liability

33. IPD - November 3, 2001John Kristoff - DePaul University33 Possible IDS failure modes • Fragmentation, state and high-speeds • Requires lots of CPU, memory and bandwidth • Inability to decode message/transaction  t^Hrr^Hm56^H^H //^H -u^Hrf • Background noise • Tunnelling/encryption • IDS path evasion • Stupid user tricks

34. IPD - November 3, 2001John Kristoff - DePaul University34 The poor man's Network IDS • Setup a router subnet and unix host • Block all outgoing/incoming packets  access-list 100 deny ip any any log • Log packets (filter matches) with syslog • Use perl/grep/uniq/... to build simple reports  Total violations: 468  Top source host:badguy.org  Top dest. TCP port:21 (ftp)

35. IPD - November 3, 2001John Kristoff - DePaul University35 The poor man's host IDS • Use snort (http://www.snort.org) or...http://www.snort.org • Turn on all logging and do log reporting • Install fake service and monitor • tcp_wrappers, back officer friendly • Use diff (or equivalent), monitor file changes • Keep copies of data/configs elsewhere • Use Tripwire or equivalent

36. IPD - November 3, 2001John Kristoff - DePaul University36 Encryption or Fodszqujpo • Try to make something readable, unreadable • Usually math intensive • Plain text to cipher text to plain text • Need strong algorithms and secure keys • Public versus private keys • How do you exchange keys securely? • Key escrow, recovery and trusted 3 rd parties

37. IPD - November 3, 2001John Kristoff - DePaul University37 Shared secret key • Each party knows the secret key • The secret key decrypts the cipher text • Book = Ulysses • Key = 7, 23, 4 •...or page 7, line 23, word 4 • Ulysses is the secret key, don't tell anyone! • How do the trusted parties learn the key?

38. IPD - November 3, 2001John Kristoff - DePaul University38 Shared secret key illustrated

39. IPD - November 3, 2001John Kristoff - DePaul University39 Public key cryptography • Advertise your well known public key • Everyone uses it to encrypt messages to you • Once encrypted, no one can decrypt it • Private key • Only you have the private key • Private key decrypts the public key encryption • Keyrings and secure public key distribution

40. IPD - November 3, 2001John Kristoff - DePaul University40 Public key illustrated

41. IPD - November 3, 2001John Kristoff - DePaul University41 Pretty Good Privacy (PGP) • Crypto software for mail, files and disks • Uses public (and private) key technology • Supports digital signatures • Public key servers maintain public keys • Free for non-commercial use • http://web.mit.edu/network/pgp.html http://web.mit.edu/network/pgp.html

42. IPD - November 3, 2001John Kristoff - DePaul University42 Virtual Private Networks (VPNs) • Make an insecure public network secure • Use Internet instead of building your own net • Secure/encrypted tunnels between endpoints • Endpoints must be secure • Sound like a host security problem? Yep. • Many challenges and trade-offs

43. IPD - November 3, 2001John Kristoff - DePaul University43 VPNs illustrated

44. IPD - November 3, 2001John Kristoff - DePaul University44 Potential VPN problem

45. IPD - November 3, 2001John Kristoff - DePaul University45 IP Security (IPSec) • Standardized by IETF • Authentication Header (AH) • Authenticates sender and packet contents • Encapsulating Security Payload (ESP) • Encrypts data before transmission • Internet Key Exchange (IKE) • Governs exchange of keys between end hosts • IPSec is often used in VPNs

46. IPD - November 3, 2001John Kristoff - DePaul University46 Kerberos • Popular for network based authentication • Also for authorization • Also used to encrypt network traffic • Uses the concept of issuing tickets to users • Uses centralized server for management • Must be secure of course! • Been around for awhile, becoming popular

47. IPD - November 3, 2001John Kristoff - DePaul University47 Network Address Translation • Meant to be a IPv4 address depletion solution • NAT is wrongly applied as a security solution • Deployment of NAT has hurt the Internet • Using NAT is expensive • NAT breaks many things • If you have addresses, don't use NAT • I don't like NAT - can you tell?

48. IPD - November 3, 2001John Kristoff - DePaul University48 NAT illustrated

49. IPD - November 3, 2001John Kristoff - DePaul University49 Enough already, how do we hack? • We'll focus on over the network attacks • Password cracking • Brute force, keystroke capture, sniff • OS/Application attacks • Buffer overflows, cgi-bin attacks, email exploits • Protocol abuses • Spoofs, hijacks, redirects, man-in-the-middle • Denial of service attacks

50. IPD - November 3, 2001John Kristoff - DePaul University50 Anatomy of a typical compromise • Do some reconnaissance work, scan, probe • Launch the exploit • Maintain compromised access with backdoors • Fix system so no one else gets in • Use/abuse system • Make it look like you were never there • Sometimes a few of these steps are skipped

51. IPD - November 3, 2001John Kristoff - DePaul University51 Network scanning/mapping • PING, traceroute • DNS information  rpcinfo -p • nmap  nbtstat, net use commands • Search engines, newsgroups, web sites • If you're on the Internet, you've been scanned

52. IPD - November 3, 2001John Kristoff - DePaul University52 Session hijacking • Pretend to be someone you're not • Take over or insert commands into a session • You may need to • Know IP addresses • Predict TCP sequence numbers • Keep one end of the real session busy • Run blind for awhile

53. IPD - November 3, 2001John Kristoff - DePaul University53 Session hijacking illustrated

54. IPD - November 3, 2001John Kristoff - DePaul University54 Password cracking •Encrypted passwords can be broken • If nothing else, by brute force • Don't let passwords be the only line of defense • Sending logins in plain text over net is bad! • Many apps do this (e.g. FTP, TELNET) • Even HTTP! • Things like kerberos, SSL and SSH help a lot

55. IPD - November 3, 2001John Kristoff - DePaul University55 Viruses and worms •Programs whose goal is to spread •...and possibly cause you a great deal of grief • Worms are common (e.g. ILOVEYOU) • Viruses infect other programs • Somehow code has to be executed • Proves users are too trusting • Some feature-full apps are becoming problems • e.g. Microsoft getting burned regularly here

56. IPD - November 3, 2001John Kristoff - DePaul University56 Weak input validation • Buffer overflows and format string attacks  strcpy(destvar, srcvar) type of stuff • Try to get your overflowed data to execute • If program was running as root/Admin... •...and you can successfully overflow a buffer... • It's probably game over for said system. • Remote overflows are very possible/popular

57. IPD - November 3, 2001John Kristoff - DePaul University57 Denial of service (DoS) attacks • Prevents or impairs standard service • SYN flooding • SMURF attacks • Distributed DoS attacks • Source address spoofing helps attacker • How to discern valid data from DoS packets? • No perfect solution exists today

58. IPD - November 3, 2001John Kristoff - DePaul University58 DoS attack illustrated

59. IPD - November 3, 2001John Kristoff - DePaul University59 DDoS attack illustrated

60. IPD - November 3, 2001John Kristoff - DePaul University60 Partial (D)DoS solutions • Gotta find the sources - not trivial if spoofed! • Ingress/egress filtering • ICMP traceback (itrace) • Packet marking (pushback) • Rate limiting • Shunning and black hole routing • Work with upstream provider

61. IPD - November 3, 2001John Kristoff - DePaul University61 How do I secure Windows?  echo Y | del c:\*.* Just kidding... • Keep up to date on patches • Run Windows Update • Remove unnecessary protocols like NETBIOS • Be very wary of running unknown programs • Do not use file/print sharing • Install and use virus protection, security tools

62. IPD - November 3, 2001John Kristoff - DePaul University62 How do I secure UNIX/Linux? • Remove unnecessary services • Empty out inetd.conf if possible • Start removing rc.d scripts and programs • Keep up to date on patches • Avoid RPC, wu-ftpd, BIND, sendmail • And others that continue to have probs • Use security tools

63. IPD - November 3, 2001John Kristoff - DePaul University63 How do I secure network devices? • Remove unnecessary services • Disable directed broadcasts • Install spoofing filters • Put device IP on secured management net • Secure routing protocols • Secure logs, time sync, snmp, etc. • Keep up to date on system software

64. IPD - November 3, 2001John Kristoff - DePaul University64 How do I secure...? • Web servers • FTP servers • Mail (SMTP/POP/IMAP) servers • Printers, webcams, toasters • Others...?

65. IPD - November 3, 2001John Kristoff - DePaul University65 Any last bit of advice? • Use the Network Time Protocol (NTP) • syslog like you've never syslog'd before • SSH is your friend • Learn and make use of perl • Find a good mailing lists/digests/URLs  Know your netstat -an |more output • Please do not attack DePaul's network

66. IPD - November 3, 2001John Kristoff - DePaul University66 References http://networks.depaul.edu/security/ http://condor.depaul.edu/~jkristof/ news://news.depaul.edu/dpu.security http://www.cert.org http://www.sans.org http://www.cerias.purdue.edu http://www.neohapsis.com http://www.securityfocus.com