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...) |
imported>Howard C. Berkowitz (Use of router internal event logging) |
||
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 debugging 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}} |
Revision as of 09:12, 15 September 2008
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 sinkhole
When 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 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.
If the router has an internal event debugging 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
- ↑ Greene, Barry Raveendran & Danny Macpherson, Sinkholes: A Swiss Army Knife ISP Security Tool Version 1.8