Sinkhole (Computer network): Difference between revisions
imported>Howard C. Berkowitz (New page: {{subpages}} In the context of Internet operator routing, a '''sinkhole''' is both a target to which hostile traffic can be directed away from its target, and which also provides a...) |
mNo edit summary |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{subpages}} | {{PropDel}}<br><br>{{subpages}} | ||
In the context of [[Internet]] operator [[routing]], a '''sinkhole''' is both a target to which hostile traffic can be directed away from its target, and which also provides an appropriate place to apply specialized security analysis tools to that traffic. Greene and Macpherson describe sinkholes as "...the network equivalent of a [[honeypot]]."<ref>{{citation | | In the context of [[Internet]] operator [[routing]], a '''sinkhole''' is both a target to which hostile traffic can be directed away from its target, and which also provides an appropriate place to apply specialized security analysis tools to that traffic. Greene and Macpherson describe sinkholes as "...the network equivalent of a [[honeypot]]."<ref>{{citation | | ||
|url = http://www.arbornetworks.com/downloads/Sinkhole_Tutorial_June03.pdf | |url = http://www.arbornetworks.com/downloads/Sinkhole_Tutorial_June03.pdf | ||
| title = Sinkholes: A Swiss Army Knife ISP Security Tool Version 1.8 | | title = Sinkholes: A Swiss Army Knife ISP Security Tool Version 1.8 | ||
| first1 = Barry Raveendran | last1 = Greene | first2 = Danny | last2 = Macpherson}}</ref> They emulate traffic aimed at a production router or server, to a network and host(s) engineered to withstand the attack; a path separate from the main production network is often used from an ingress | | first1 = Barry Raveendran | last1 = Greene | first2 = Danny | last2 = Macpherson}}</ref> They emulate traffic aimed at a production router or server, to a network and host(s) engineered to withstand the attack; a path separate from the main production network is often used from an ingress Border Gateway Protocol customer or interprovider router, to the nearest sinkhole. | ||
"Nearest" is relevant here because it is perfectly feasible to have multiple sinkholes, typically with an [[anycast]] address, to divert distributed denial of service (DDoS) attacks. | "Nearest" is relevant here because it is perfectly feasible to have multiple sinkholes, typically with an [[anycasting|anycast]] address, to divert distributed denial of service (DDoS) attacks. | ||
==Diverting to a sinkhole== | ==Diverting to a sinkhole== | ||
Line 11: | Line 11: | ||
==Sinkhole instrumentation== | ==Sinkhole instrumentation== | ||
There is no single configuration for a sinkhole. Two common approaches are to have the target reached through general-purpose router, or possibly a BGP-speaking "switch" with port mirroring, and using a LINUX PC as the actual target. Alternatively, the target and egress router can be combined into a PC running an open-source routing package such as Quagga. The anycast device can be on its own VLAN to which additional analyzers can be connected. | There is no single configuration for a sinkhole. Two common approaches are to have the target reached through general-purpose router, or possibly a BGP-speaking "switch" with port mirroring, and using a LINUX PC as the actual target. Alternatively, the target and egress router can be combined into a PC running an open-source routing package such as Quagga. The anycast device can be on its own VLAN to which additional analyzers can be connected. | ||
If the router has an internal event monitoring capability, such as Cisco's '''debug''' feature, that can be cautiously enabled, since it can generate a great deal of traffic and heavily burden the router processor. Nevertheless, the data generated by such a function can be especially informative if the attack is directed against routers rather than servers. | |||
All devices must be time-synchronized if there is to be any hope of correlating events. | All devices must be time-synchronized if there is to be any hope of correlating events. | ||
Line 17: | Line 19: | ||
Depending on the network capability and requirements, there may be additional intrusion detectors, which, perhaps, can generate a blackhole route once the attack is understood. Blackhole host routes, to the same destination, are also injected as NO-EXPORT into iBGP, but tell the ingress routers to silently discard the traffic. | Depending on the network capability and requirements, there may be additional intrusion detectors, which, perhaps, can generate a blackhole route once the attack is understood. Blackhole host routes, to the same destination, are also injected as NO-EXPORT into iBGP, but tell the ingress routers to silently discard the traffic. | ||
==References== | ==References== | ||
{{reflist}} | {{reflist}}[[Category:Suggestion Bot Tag]] |
Latest revision as of 17:01, 18 October 2024
This article may be deleted soon. | ||
---|---|---|
In the context of Internet operator routing, a sinkhole is both a target to which hostile traffic can be directed away from its target, and which also provides an appropriate place to apply specialized security analysis tools to that traffic. Greene and Macpherson describe sinkholes as "...the network equivalent of a honeypot."[1] They emulate traffic aimed at a production router or server, to a network and host(s) engineered to withstand the attack; a path separate from the main production network is often used from an ingress Border Gateway Protocol customer or interprovider router, to the nearest sinkhole. "Nearest" is relevant here because it is perfectly feasible to have multiple sinkholes, typically with an anycast address, to divert distributed denial of service (DDoS) attacks. Diverting to a sinkholeWhen an attack on a network resource is detected, on a BGP-speaking router, the human or operator creates a host route to the anycast address, and injects it into internal BGP, marked with the NO-EXPORT BGP community. This will cause the attack traffic to move from the production path to the sinkhole path, without warning the miscreant with something as blatant as an Internet Message Control Protocol filtering or no-such-destination message. Sinkhole instrumentationThere is no single configuration for a sinkhole. Two common approaches are to have the target reached through general-purpose router, or possibly a BGP-speaking "switch" with port mirroring, and using a LINUX PC as the actual target. Alternatively, the target and egress router can be combined into a PC running an open-source routing package such as Quagga. The anycast device can be on its own VLAN to which additional analyzers can be connected. If the router has an internal event monitoring capability, such as Cisco's debug feature, that can be cautiously enabled, since it can generate a great deal of traffic and heavily burden the router processor. Nevertheless, the data generated by such a function can be especially informative if the attack is directed against routers rather than servers. All devices must be time-synchronized if there is to be any hope of correlating events. As a start, the sinkhole should have Simple Network Management Protocol, and, if supported, NetFlow analyzers for traffic statistics. It is often useful to have a local log that diverts attack events away from the main network log server. A hardware-based protocol capture/analysis device, or an open source protocol analyzer, such as Wireshark, often are included. Depending on the network capability and requirements, there may be additional intrusion detectors, which, perhaps, can generate a blackhole route once the attack is understood. Blackhole host routes, to the same destination, are also injected as NO-EXPORT into iBGP, but tell the ingress routers to silently discard the traffic. References
|