Sinkhole (computers): Difference between revisions
imported>Howard C. Berkowitz No edit summary |
imported>Sandy Harris No edit summary |
||
| Line 5: | Line 5: | ||
| first1 = Barry Raveendran | last1 = Greene | first2 = Danny | last2 = Macpherson}}</ref> | | first1 = Barry Raveendran | last1 = Greene | first2 = Danny | last2 = Macpherson}}</ref> | ||
Sinkholes often contain extra analysis tools that can variously confirm suspect traffic is indeed an attack, assist in or even automatically create defenses, and help trace an attack back to the source. | Sinkholes often contain extra analysis tools that can variously confirm suspect traffic is indeed an attack, assist in defense or even automatically create defenses, and help trace an attack back to the source. | ||
Large networks, as with [[Internet Service Provider]]s, often have multiple sinkholes distributed to multiple locations, so diverted traffic can be processed close to the point that it enters the network, rather than creating an undesirable load if it has to reach a distant forensic analysis point. Since the sinkholes usually are identical, the [[anycasting]] technique is very useful to advertise their presence: it can be easy to administer, and is inherently load-balancing and fault-tolerant. | Large networks, as with [[Internet Service Provider]]s, often have multiple sinkholes distributed to multiple locations, so diverted traffic can be processed close to the point that it enters the network, rather than creating an undesirable load if it has to reach a distant forensic analysis point. Since the sinkholes usually are identical, the [[anycasting]] technique is very useful to advertise their presence: it can be easy to administer, and is inherently load-balancing and fault-tolerant. | ||
Sinkhole implementation can differ when the emphasis is protecting [[router]]s rather than servers, although there are some common techniques. | Sinkhole implementation can differ when the emphasis is protecting [[router]]s rather than servers, although there are some common techniques. | ||
==Router protection== | ==Router protection== | ||
For router protection, it must be possible to divert attack traffic directed at the usual production address of the router interface, but still have either an additional, internal-only address on the interface, or another means of communicating with the router (e.g., a physically separate interface) that can be used to reconfigure the router. This is less often required on servers, which are most often protected by router configuration, but still may be appropriate if defensive code needs to be inserted into the router, yet not diverted away from it by the anycast process. <ref name=Kristoff>{{citation | For router protection, it must be possible to divert attack traffic directed at the usual production address of the router interface, but still have either an additional, internal-only address on the interface, or another means of communicating with the router (e.g., a physically separate interface) that can be used to reconfigure the router. This is less often required on servers, which are most often protected by router configuration, but still may be appropriate if defensive code needs to be inserted into the router, yet not diverted away from it by the anycast process. <ref name=Kristoff>{{citation | ||
Revision as of 01:58, 20 March 2010
In computer network and server security, a sinkhole is a network element to which suspect or dangerous traffic is diverted. Sinkhole techniques move denial of service traffic away from the network as a hole, possibly disabling a target server but protecting the overall network infrastructure.[1]
Sinkholes often contain extra analysis tools that can variously confirm suspect traffic is indeed an attack, assist in defense or even automatically create defenses, and help trace an attack back to the source.
Large networks, as with Internet Service Providers, often have multiple sinkholes distributed to multiple locations, so diverted traffic can be processed close to the point that it enters the network, rather than creating an undesirable load if it has to reach a distant forensic analysis point. Since the sinkholes usually are identical, the anycasting technique is very useful to advertise their presence: it can be easy to administer, and is inherently load-balancing and fault-tolerant.
Sinkhole implementation can differ when the emphasis is protecting routers rather than servers, although there are some common techniques.
Router protection
For router protection, it must be possible to divert attack traffic directed at the usual production address of the router interface, but still have either an additional, internal-only address on the interface, or another means of communicating with the router (e.g., a physically separate interface) that can be used to reconfigure the router. This is less often required on servers, which are most often protected by router configuration, but still may be appropriate if defensive code needs to be inserted into the router, yet not diverted away from it by the anycast process. [2] When using anycast with routers, it is best to use a routing protocol, such as the Border Gateway Protocol or Open Shortest Path First, that has an explicit router identifier that can disambiguate different announcements of the same address.
Server protection
When an attack is detected, the server under attack would be useless due to overload, so its address is effectively reassigned as the more-preferred anycast address of a set of sinkholes. The sinkhole nearest the ingress router does the analysis of a single-stream denial of service (DoS) attack, while anycast-addressed sinkholes respond well under distributed denial of service (DDoS) attack.
References
- ↑ Greene, Barry Raveendran & Danny Macpherson, Sinkholes: A Swiss Army Knife ISP Security Tool Version 1.8
- ↑ John Kristoff (January 2, 2004), Anycast Routing, Anycast Addressing on the Internet