Sinkhole (Computer network): Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
m (Internal monitoring is not redundant with the example of "debug")
imported>Howard C. Berkowitz
m (Sinkhole moved to Sinkhole (Computer network): disambiguation)
(No difference)

Revision as of 12:50, 15 September 2008

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

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 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

  1. Greene, Barry Raveendran & Danny Macpherson, Sinkholes: A Swiss Army Knife ISP Security Tool Version 1.8