Internet Security
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
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
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 compatibility
DoS flood attacks • Flooding to provide Denial of Service (DoS): • DoS 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
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
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
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
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
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
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.
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 ease 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 & 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
DNS insecurity • 21 Jan 2001: Yahoo.com & Microsoft.com traffic redirected. A faulty DNS table appears to be to blame for redirecting traffic to MyDomains.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
SNMPv1 • Built on UDP • Community name is passed as clear text
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
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
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
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 ActiveX controls) • With all the extra function there can be performance issues for high speed networks.
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: BackOrifice, subseven, netbus … • dDoS: 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
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.
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
