1 / 31

Addressing Issues

Addressing Issues. Frank Flanagan. Mac Addresses. Each NIC has a factory assigned MAC address e.g. 90.74.BF.8F.80.CF This a 48 bit address It is uniquely assigned, each vendor is assigned a block On most NICs it may be overridden by software MAC authentication is not therefore very strong

julio
Download Presentation

Addressing Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Addressing Issues Frank Flanagan

  2. Mac Addresses • Each NIC has a factory assigned MAC address e.g. 90.74.BF.8F.80.CF • This a 48 bit address • It is uniquely assigned, each vendor is assigned a block • On most NICs it may be overridden by software • MAC authentication is not therefore very strong • MAC addresses are not very useful to network administrators • No control over what addresses you purchase • Makes routing very difficult

  3. IP Addresses • IP addressing and Ethernet addressing were originally developed separately and somewhat incompatibly • Originally an organization obtained a block of addresses assigned by a NIC • Now most organizations obtain only a few addresses and use NAT/PAT • Routing within and between organizations can be performed based on IP addresses • All Ethernet frames are transmitted using MAC source and dest addresses • So a mapping between MAC and Ethernet addresses is required • Initially was done using using hand configured tables

  4. ARP • Address Resolution Protocol was created to solve the MAC to IP address mapping • ARP is intended to be used by machines on the same sub-net as one another • Say A (131.1.1.3) wants to make a connection to B(131.1.1.5) but does not know the MAC address • A forms an ARP request packet and sends it to the Ethernet broadcast address FF.FF.FF.FF.FF.FF • The machine owning the IP address sends an ARP response giving its MAC address • If the destination is not on the same subnet the address of a router is returned

  5. ARP Details • ARP is not part of IP and does not have IP headers • ARP packets having a broadcast destination address are not forwarded by routers • ARP records are aged and deleted from local caches eventually • Records typically have a life of up to thirty minutes

  6. Old Style Ethernet • When Ethernet was originally conceived it was a cable bus • All traffic in a network had to pass every node and nodes, by good grace rather than by anything enforceable, were intended to process only traffic intended for them • Various physical topologies were adopted while still leaving the Ethernet as a logical bus • Bandwidth limitations as opposed to security concerns led to the adoption of switched Ethernet

  7. Switched Ethernet • The old style hub or cable is replaced with a switch • The switch forwards all broadcasts to all segments • It dynamically senses the MAC address(es) on each segment • Normal packets are only forwarded to the correct segment • With modern UTP networks there is usually only one device on each port of the switch • Therefore each segment should only see the traffic to or from the machine on the segment • But everything depends on ARP working properly

  8. The Problems with ARP • Machines may send UNARPs i.e. delete me from your arp table • Machines may send gratuitous ARP responses this may happen legitimately for instance with two boxes working as a hot standby pair • Proxy ARP used when using NAT or routed networks may be manipulated • See for instance • http://www.phenolit.de.arpoc • http://www.monkey.org/~dugsong/dsniff • http://www.packetstorm.securiyy.com/sniffers/smit.tar.tgz • NB: Neither DCU nor I accept any liability for anything you chose to download from the internet

  9. Normal Communications

  10. Attacker ARPs its Address

  11. Attacker Forwards Traffic

  12. Defenses • Static ARP entries for key systems • arp –s <ip-addr> <mac-addr> • This undoes much of the ease of use of arp but is likely to be worth the effort for key systems • ARP watching • ftp://ftp.ee.lbl.gov/arpwatch-2.1a6.tat.gz • Rely on static IP to MAC database • Lose most of the benefits of ARP • Cannot use DHCP

  13. RARP • RARP reverse of ARP • Maps MAC addresses to IP addresses • Used by BOOTP and DHCP to dole out addresses • RARP is broadcast based • Significant attacks are against higher layer protocols • DHCP provide client systems with dubious configuration • DHCP tends to alllow unauthorized systems to gain a presence on the network

  14. Bootp/DHCP Defenses • Static IP addresses – loses all benefits of DHCP • DHCP/BOOTP MAC configuration • Data base of MACs • ARP monitoring • Port Security

  15. Domain Name System • ARP/RARP provide translation between MAC and IP addresses • The IP addresses known to ARP are numbers • DNS provides translation between numeric and symbolic IP addresses • Unless you are willing to revert to using numeric addresses there is little choice other than using DNS • Unfortunately as everyone relies on DNS for address translations, on a world wide rather than just on a local network basis as with ARP, hacking DNS is one of the most dangerous attacks available.

  16. DNS Name Lookup

  17. DNS Protocol • Client executes gethostbyname() • Local resolver library sends request to local name server • If local name server does not have address it queries authoritative name server • Local server will cache address on the way back • DNS uses both UDP and TCP • UDP for requests < 512 bytes • TCP for larger requests • Just about every firewall is configured to alllow outgoing port 53 TCP/UDP to resolve names • This means that it is often a target

  18. Terminology • Zone Transfer – intended to transfer data between primary and secondary DNS servers for redundancy • recursive requests or non-authorities requests – Request for information on an address for which this server is not authorities i.e. a request which will either be fulfilled from the cache in the server or will cause the server to make a request from an upstream name server

  19. Vulnerabilities • Poor access controls • Caching servers do not manage their own cache • Databases tend to be ASCII • Dynamic DNS update • Microsoft especially uses DDNS to allow client systems to update their own resources on DNS servers. • Zone Transfer • Recursion – Most default DNS systems allow remote systems to query them for systems for which the server is not authoritative • DNS is very trusting • DNSSEC is one possibility

  20. The Promise of Improvement • The IETF has designed a number of security extensions for DNS but deployment keeps getting delayed to avoid interoperability problems. • Like IPV6 I suspect that these may actually get deployed some time during my lifetime

  21. DNS Harvesting • Hackers often harvest data from DNS • The DNS database may contain many records: • IP Address records • Reverse records • Name server records • Host Information records • Do not use • Service Records • Associates service with a server or a set of servers (Active Directory makes extensive use of these records) • Text Records – Do not use • Well known service records – similar to SRV records

  22. DNS Harvesting Tools • http://www.samspade.org • http://www.solarwinds.org • dig • nslookup

  23. Denial of Service Attacks • DNS Request Flooding – Flood a server with requests for systems for which it authoritative • DNS Response Flooding – As request flooding except with a live spoofed source address, this floods the supposed source network with responses from faked requests • Recursive Request Flooding – flood a target name server with requests for addresses for which it is not authoritative thus flooding both the target and the authoritative server for the domain • Do NOT accept non-authoritative requests from unknown source addresses • DNS flooding relies on the difference in size between small DNS requests and large DNS responses

  24. DNS Cache Poisoning Explained • DNS servers are constantly sending out questions ("What's the IP address of www.xxx-xxxx.com?") and receiving answers ("www.xxx-xxxx.com is at 209.237.229.14"). • They don't actually authenticate the source of the answers -- there's no way for your DNS server to be sure that the answer actually came from the REAL xxx-xxxx.com. Some DNS servers don't even check that they asked a question that corresponds to an answer they received, and just believe any answer someone sends them. • The simplest form of cache poisoning is simply sending fake answers to someone's DNS server; for each safeguard a DNS server might apply to prevent cache poisoning there's usually a workaround that goes one step further. This is why SSH has all that stuff with strict checking of host keys.

  25. Now I Digress • It's just like fraud schemes in the real world -- some guy walks up and says he's from the gas company. You let him in, he steals your beer. Next time you ask him for gas company ID. He shows you a fake one. Beer stolen. • Next time you call the gas company phone number printed on his ID. It's his buddy's phone number; the buddy tells you the guy's legit. Beer stolen. • Next time you call the gas company's number as shown on your latest gas bill. It's his buddy's other line; they sent you a forged gas bill. Beer stolen again. • Indeed, perhaps they simply bribe a real gas company employee to steal your beer. It's a never-ending arms race. • Daniel F. Boyd / boyd@csgeeks.orgLast modified: Tue Jul 30 16:02:41 2002

  26. Registration Fraud • Hi I am Frank from Microsoft can you register the following domain for me? • Sounds implausible • It happened • Domain registrars are supposed to confirm lots of things and typically only accept changes only from a single email address

  27. Buffer Overflows • There have been a number of successful buffer overflow attacks on DNS • The most notorious was the BIND8 Transaction Signature Attack • This managed to get random code to execute • It was an early stage attack so it worked on both recursive and non-recursive DNS servers • It was used by the li0n worm among others

  28. DNS Spoofing • Intercept a DNS request to redirect client to a fraudulent address • DNS spoofing tools exist such as the imaginatively named dnsspoof • DNS spoofing requires faking a DNS request ID • This is now supposed to be difficult due to the introduction of random DNS IDs • There are a number of interesting proposals to used the birthday paradox to overcome this

  29. DNS Hijacking • Either compromise an upstream name server or • Replace a name server in the domain of interest • Can be achieved by attacking a poorly protected upstream DNS server

  30. Securing DNS • Run the DNS servers with the least privilege possible • Run as little as possible on the servers • Use multi tier DNS • One in the DMZ for the outside world • One in the core for internal users • All patches • Firewall • Do not support external recursive queries

  31. Verisign’s Sitefinder “Service” • Verisign now manage the top level .com domain among others • They introduced a modification to the top level DNS in that no domain could be non-existent instead if you mistyped a name you were redirected to a Verisign site with some helpful suggestions e.g that when you typed googl you might have intended to type google and a lot of advertising • This caused outcry among the internet community and broke lots of useful things like testing for valid domains before accepting email • This was suspended but is now rumored to be on the verge of being resurrected

More Related