The Internet Security Les Cottrell SLAC Lecture 3

The Internet & Security Les Cottrell – SLAC Lecture # 3 presented at the 26 th International Nathiagali Summer College on Physics and Contemporary Needs, 25 th June – 14 th July, Nathiagali, Pakistan Partially funded by DOE/MICS Field Work Proposal on Internet End-to-end Performance Monitoring (IEPM), also supported by IUPAP 1

Outline • • • What’s the problem? How prevalent are security attacks? Denial of Service attacks Spoofing Network applications exposures Prevention Detection Follow up Top 12 recommendations 2

Problems • Complexity of systems – Patchwork of untrustworthy parts – Even mature subsystems (Unix, Windows, Word) poorly understood – All systems have errors (buffer overflows, unchecked input, inadequate testing …) – Humans are part of the system – Rapid change & introduction of new parts changes environment (active content, streaming content) • Security is in tension with ease of use and friendliness, so unpopular 3

Prevalence • “Inferring Internet Denial-of-Service Activity” by D. Moore et. al. in 3 weeks found > 12, 000 attacks against > 5000 targets belonging to > 2000 organizations. • a denial-of-service attack left whitehouse. gov unreachable from, according to a Web monitor, around 2: 30 p. m. EDT to 8: 20 p. m. May 22, 01 from www. wired. com/news/politics/0, 1283, 43993, 00. html • We started receiving ~13 Mbits/sec at 10: 30 pm EDT on May 22 and it continues as of this writing (6: 58 am, May 23, 01). From Computer Emergency Response Team (CERT) • An out of the box Linux Red. Hat 6. 2 system will be “rooted” on average within 72 hours. Bob Cowles, SLAC Computer Security Officer 4

Prevalence - cont. • In a two-day rampage (May 24 -25, 2001) against U. S. government Web sites, a group of cybervandals dubbed Poizon. B 0 x, attacked two sites maintained by the Defense. Information Systems Agency, the organization tasked with defending military networks. Poizon. B 0 x defaced nine other government Web sites, including: – The chief information officer of the General Services Administration. – NASAs Advanced General Aviation Transport Experiments. – The Arcata [Calif. ] Fish and Wildlife Office. – The U. S. Bankruptcy Court, Eastern District of California. – The U. S. District Court, Northern District of Texas. Info. Sec News <isn@c 4 i. org> 5

Network Vulnerabilities • • ARP cache flooding DHCP spoofing DNS cannot be trusted Little IP address authentication Integrity checks are minimal Denial of service attacks are easy to stage Security not part of original network design Changing things (to improve security) breaks compatability 6

Do. S flood attacks • Flooding to provide Denial of Service (Do. S): – Do. S attacks deny resources of a remote host or networks that would otherwise be used by legitimate users – Flooding attacks overwhelm victim’s CPU, memory or network resources by sending large numbers of spurious requests. • Difficult to tell “good” requests from “bad” so hard to defend against • To load network attacker sends small packets as fast as possible since most devices are limited by packet processing rate and not bandwidth 7

SYN floods • Attacker loads victim’s cpu by sending stream of TCP SYN packets to a listening TCP port – For each SYN packet victim must search through existing connections & if no match allocate a new data structure for connection – Number of connections may be limited in victim’s host, so host can be overwhelmed – Victim also re-sends SYN/ACK until time limit 8

Distributed Attacks • More powerful attacks leverage multiple hosts to send the SYNs – i. e. attacker compromises many hosts, installs a small attack daemon (bots) on each • Compromises via buffer overflows, 1 year old patchable web server Unicode bug, poorly written CGI scripts, etc. – Attack can then be coordinated from multiple hosts focusing on a single victim host 9

Impact from a Do. S attack • Do. S attack Feb 7 & 8, 2000 • Impact on losses for DNS, web, and network services 10

IP spoofing • To conceal identity, thus forestalling an effective response, attackers forge (“spoof”) the IP source address of each packet they send – Often select the IP address at random – Attack appears to be coming from a third party – Also can reflect attacks through innocent third parties • Protection: – Dynamic size for connection table – Decrease timeout for partial connections – Prevent spoofing across routers 11

ICMP • RFC 792, & clarified in RFCs 1122, 1256, 1349, 1812 • Smurf: – Spoof source address – Uses broadcast address to get amplification • i. e. every host on subnet responds to same source – e. g. can provoke host unreachable, ttl exceeded • Don’t allow ICMP to go to broadcast address • Rate limit or block most ICMPs – BUT lose ping & traceroute, watch out for MTU discover 12

UDP Security • Services can often be spoofed as the source of a request • The connectionless nature makes it hard for firewalls to protect – direction of connection not easily determined – must examine packet contents in application dependent fashion 13

ARP • First host to respond to ARP broadcast wins – Thus a “bad guy” can respond quickly and poison the recipient’s cache • E. g. “bad guy” can pretend to be router • No fix. 14

Dynamic Host Configuration Protocol • DHCP built on UDP, ports 67/68 (see RFC 2131) – Client is dynamically assigned (leased) an IP configuration (IP address, gateway, DNS server, domain name etc. ) – Server controls allocation of addresses – Client must renew periodically – Can greatly increase of configuration flexibility & decrease maintenance • BUT – single client (using spoofed addresses) may use up all available IP addresses – Does not prevent someone using unassigned address – Rogue machine can respond & claim to be router, DNS & 15 hence intercept all traffic

Domain Name Service DNS • Built on UDP, port 53 (see RFC 1591): – Maps host names to IP addresses & back – Hierarchical structure - no server for all hosts – All domains have authoritative name server – Root name servers maintain server list for all subdomains – Once translated, mapping is cached • ICANN administers top level domains • Example, get IP address of www. sun. com: • • Check local cache Query “. com” nameserver, get referral to “ns. sun. com” Query ns. sun. com Cache result & return IP address 16

DNS insecurity • 21 Jan 2001: Yahoo. com & Microsoft. com traffic redirected. A faulty DNS table appears to be to blame for redirecting traffic to My. Domains. com • Systems may change and the cache is wrong • Cache may be poisoned by an “attacker” • No authorization for change requests • Attacker can administratively change “authoritative nameserver” and there are few checks to prevent it 17

SNMPv 1 • Built on UDP • Community name is passed as clear text 18

Telnet RFC 854 • Built on TCP – sends passwords in clear text – often target of sniffers collecting passowrds – session unencrypted - session may be hijacked • Use ssh instead – not all hosts (e. g. some network devices) support ssh 19

Prevention • Need defense in depth. • Firewalls, filtering router ACLs • Vulnerability scans – Look for hosts with OS at a level that can be compromised – Look for ports/applications that should not be open – ISS, freeware from www. nessus. org • Don’t overprotect – Waste of resources (direct cost) – Reduced functionality (indirect cost) • Don’t leave backdoor open – Think like an attacker or find someone who can 20

Filters • Simple filtering done by Access Control Lists (ACLs) in routers – Filter to deny access to dangerous stuff – Or Deny all and allow access to approved stuff – Filters based on header information • Source/destination address/port • Protocol – Rules apply interface & direction 21

Firewalls • • Specialized for filtering without routing duties Usually easier to configure, have auditing, logging, auditing Can use for privacy to hide internal network addresses Many firewalls can maintain state, i. e. maintain virtual sessions for UDP and close port when connection closes • Some firewalls can look inside data in packets to discover application (e. g. to disallow Active. X controls) • With all the extra function there can be performance issues for high speed networks. 22

Detection • Host based intrusion detection: instrument OS, applications, e. g. tripwire (look at what has changed), web page defacement detection • Network based intrusion detection – Passively sniff on packets and look at flows. – Look for list suspicious ports/protocols being accessed, when, by whom, for how long/much. Keep logs going back months • Possible inappropriate use: IRC, Gnutella, Napster … • Remote control: Back. Orifice, subseven, netbus … • d. Do. S: tfn, trinoo … – Look for attack signatures, may look in packet contents & compare bits with known patterns – Look for scan signatures like seq of ports, or seq of hosts – Can provide pre-knowledge of signatures of known attacks • Needs constant updates – Can look for abnormal behavior – Netflow, ISS, freeware from www. snort. org 23

Notification & follow up • After discovering, have to alert someone by pager, email – Have to worry about false positives • • • Need a clear procedure in place for dealing with intrusions Have to notify management May have to take down & re-install OS etc. May have to cut off from Internet while clean up May have to field questions from funding agency, press, law enforcement agencies • Have to do a post-mortem & improve processes • All of the above are painful, want to avoid if possible. 24

Security Awareness Top 12 1. Encourage users to log off when absent and require password-protected screensavers on PCs. 2. Encourage use of strong passwords made of mixed letters, numbers and special characters. 3. Encourage a clear, well-defined, written security policy, with all users having a copy. 4. Discourage installing modems on networked workstations. 5. Encourage use of encryption techniques when handling or sending confidential email. 6. Discourage users having a careless or indifferent attitude toward security. 25

Security Awareness Top 12 7. Discourage, under any circumstances, users giving their passwords to someone via email. 8. Encourage users to maintain physical control of laptop cases while in public places. 9. Encourage users to change passwords frequently, particularly if it may be compromised. 10. Encourage awareness of social engineering attempts to breach security. 11. Encourage active use and regular, automated updating of anti-virus software. 12. Discourage use of the Internet for any illegal activities. 26

Requirements • Make sure the firewall/ACLs are installed, working & maintained • Security patches – current & installed in timely manner • Remove use of clear text passwords (telnet => ssh, email, FTP…) • Change default vendor passwords • Regularly test security systems & processes 27

More Information • Lectures on security: – www. speakeasy. org/~rcowles/ • ICMP in security scans: – www. sys-security. com/html/papers. html • Prevalence of attacks: – www. caida. org/outreach/papers/backscatter/index. xml • Solaris Network Settings for Security – www. sun. com/software/solutions/blueprints/1299/network. pdf • FAQ from SANS – www. sans. org/infosec. FAQ/ 28