Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Computer network wikipedia , lookup
Airborne Networking wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Network tap wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Wireless security wikipedia , lookup
Deep packet inspection wikipedia , lookup
Computer security wikipedia , lookup
Computer and Network Security John Kristoff [email protected] +1 312 362-5878 DePaul University Chicago, IL 60604 IPD - November 3, 2001 John Kristoff - DePaul University 1 What are you trying to secure? • • • Confidentiality • • Avoid snooping • Encryption? • • Integrity Deletes, changes • Backups • (D)DoS attacks No denying it Access control • Availability IPD - November 3, 2001 • Is that you? Nonrepudiation • • • Authentication Hands off! Reputation • Name = MUD John Kristoff - DePaul University 2 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 IPD - November 3, 2001 John Kristoff - DePaul University 3 Why doesn't telco security bite? Telco Internet • Central authority • No central authority • Network intelligence • End host intelligence • Billing records per call • No packet accounting • Legalese understood • Legalese fuzzy • Wiretapping laws • Privacy issues • Circuit connections • Ease of anonymity IPD - November 3, 2001 John Kristoff - DePaul University 4 So where do you put security? IPD - November 3, 2001 John Kristoff - DePaul University 5 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 IPD - November 3, 2001 John Kristoff - DePaul University 6 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 IPD - November 3, 2001 John Kristoff - DePaul University 7 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 IPD - November 3, 2001 John Kristoff - DePaul University 8 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% IPD - November 3, 2001 John Kristoff - DePaul University 9 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? IPD - November 3, 2001 John Kristoff - DePaul University 10 Perimeter security " Separate trusted net from untrusted net " Define the boundary IPD - November 3, 2001 John Kristoff - DePaul University 11 What network firewalls do • Define untrusted and trusted boundaries • Inspect traffic traversing firewall boundary • Limit communication traversing boundary • Help shield insecure hosts IPD - November 3, 2001 John Kristoff - DePaul University 12 Network firewalls illustrated IPD - November 3, 2001 John Kristoff - DePaul University 13 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 IPD - November 3, 2001 John Kristoff - DePaul University 14 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 IPD - November 3, 2001 John Kristoff - DePaul University 15 Screened subnet implementation IPD - November 3, 2001 John Kristoff - DePaul University 16 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 IPD - November 3, 2001 John Kristoff - DePaul University 17 Proxy/ALG illustrated IPD - November 3, 2001 John Kristoff - DePaul University 18 Other common firewall features • Stateful inspection • Network address translation (NAT) • Authenticaton (VPNs) • Dynamic triggers • Reporting, logging and IDS support IPD - November 3, 2001 John Kristoff - DePaul University 19 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 -A -A -A -A input input input input input -s -s -s -s -s 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 -d a.b.c.d/255.255.255.255 22:22 -p 6 -j ACCEPT -d a.b.c.d/255.255.255.255 1024:65535 -p 6 ! -y -j ACCEPT 20:20 -d 0.0.0.0/0.0.0.0 1024:65535 -p 6 -y -j ACCEPT -d 0.0.0.0/0.0.0.0 1024:65535 -p 17 -j ACCEPT -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 IPD - November 3, 2001 John Kristoff - DePaul University 20 Example: Cisco ACL Block private IP addresses access-list 100 deny access-list 100 deny access-list 100 deny ip 192.168.0.0 0.0.255.255 any ip 172.0.0.0 0.15.255.255 any ip 10.0.0.0 0.255.255.255 any Block reserved, loopback and Class E IP addresses access-list 100 deny access-list 100 deny access-list 100 deny ip 0.0.0.0 0.255.255.255 any ip 127.0.0.0 0.255.255.255 any ip 224.0.0.0 31.255.255.255 any Block source port of 111 from going anywhere access-list 100 deny access-list 100 deny tcp any eq sunrpc any 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 IPD - November 3, 2001 John Kristoff - DePaul University access-list 100 deny ip any any 21 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 IPD - November 3, 2001 John Kristoff - DePaul University 22 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 IPD - November 3, 2001 John Kristoff - DePaul University 23 Intrusion Detection Systems • Interesting, but immature technology • Provides lots of data/information • Generally doesn't interfere with communications • Anything that improves security... IPD - November 3, 2001 John Kristoff - DePaul University 24 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 IPD - November 3, 2001 John Kristoff - DePaul University 25 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? IPD - November 3, 2001 John Kristoff - DePaul University 26 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? IPD - November 3, 2001 John Kristoff - DePaul University 27 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 IPD - November 3, 2001 John Kristoff - DePaul University 28 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 • • May not understand network traffic • • Fragmentation, other host attacks (correlation) Unknown protocols/applications, encryption May miss things that don't cross its boundary IPD - November 3, 2001 John Kristoff - DePaul University 29 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, 9th USENIX Security Symposium • An area of active research IPD - November 3, 2001 John Kristoff - DePaul University 30 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 IPD - November 3, 2001 John Kristoff - DePaul University 31 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 IPD - November 3, 2001 John Kristoff - DePaul University 32 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 IPD - November 3, 2001 John Kristoff - DePaul University 33 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) IPD - November 3, 2001 John Kristoff - DePaul University 34 The poor man's host IDS • Use snort (http://www.snort.org) or... • Turn on all logging and do log reporting • Install fake service and monitor • • Use diff (or equivalent), monitor file changes • • tcp_wrappers, back officer friendly Keep copies of data/configs elsewhere Use Tripwire or equivalent IPD - November 3, 2001 John Kristoff - DePaul University 35 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 3rd parties IPD - November 3, 2001 John Kristoff - DePaul University 36 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? IPD - November 3, 2001 John Kristoff - DePaul University 37 Shared secret key illustrated IPD - November 3, 2001 John Kristoff - DePaul University 38 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 IPD - November 3, 2001 John Kristoff - DePaul University 39 Public key illustrated IPD - November 3, 2001 John Kristoff - DePaul University 40 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 IPD - November 3, 2001 John Kristoff - DePaul University 41 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 IPD - November 3, 2001 John Kristoff - DePaul University 42 VPNs illustrated IPD - November 3, 2001 John Kristoff - DePaul University 43 Potential VPN problem IPD - November 3, 2001 John Kristoff - DePaul University 44 IP Security (IPSec) • Standardized by IETF • Authentication Header (AH) • • Encapsulating Security Payload (ESP) • • Encrypts data before transmission Internet Key Exchange (IKE) • • Authenticates sender and packet contents Governs exchange of keys between end hosts IPSec is often used in VPNs IPD - November 3, 2001 John Kristoff - DePaul University 45 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 IPD - November 3, 2001 John Kristoff - DePaul University 46 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? IPD - November 3, 2001 John Kristoff - DePaul University 47 NAT illustrated IPD - November 3, 2001 John Kristoff - DePaul University 48 Enough already, how do we hack? • We'll focus on over the network attacks • Password cracking • • OS/Application attacks • • Buffer overflows, cgi-bin attacks, email exploits Protocol abuses • • Brute force, keystroke capture, sniff Spoofs, hijacks, redirects, man-in-the-middle Denial of service attacks IPD - November 3, 2001 John Kristoff - DePaul University 49 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 IPD - November 3, 2001 John Kristoff - DePaul University 50 Network scanning/mapping • PING, traceroute • DNS information • rpcinfo -p <hostname> • nmap • nbtstat, net use commands • Search engines, newsgroups, web sites • If you're on the Internet, you've been scanned IPD - November 3, 2001 John Kristoff - DePaul University 51 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 IPD - November 3, 2001 John Kristoff - DePaul University 52 Session hijacking illustrated IPD - November 3, 2001 John Kristoff - DePaul University 53 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 IPD - November 3, 2001 John Kristoff - DePaul University 54 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 IPD - November 3, 2001 John Kristoff - DePaul University 55 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 IPD - November 3, 2001 John Kristoff - DePaul University 56 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 IPD - November 3, 2001 John Kristoff - DePaul University 57 DoS attack illustrated IPD - November 3, 2001 John Kristoff - DePaul University 58 DDoS attack illustrated IPD - November 3, 2001 John Kristoff - DePaul University 59 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 IPD - November 3, 2001 John Kristoff - DePaul University 60 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 IPD - November 3, 2001 John Kristoff - DePaul University 61 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 IPD - November 3, 2001 John Kristoff - DePaul University 62 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 IPD - November 3, 2001 John Kristoff - DePaul University 63 How do I secure ...? • Web servers • FTP servers • Mail (SMTP/POP/IMAP) servers • Printers, webcams, toasters • Others...? IPD - November 3, 2001 John Kristoff - DePaul University 64 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 IPD - November 3, 2001 John Kristoff - DePaul University 65 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 IPD - November 3, 2001 John Kristoff - DePaul University 66