文章作者：Edward Balas
信息来源：
http://www.honeynet.org/tools/dcontrol/dc.html
Summary
This document discusses a number of methods of providing per honeypot rate limiting. Specifically, we discuss how to do this with FreeBSD's Dummynet,Linux's Advanced Routing and Traffic Control, Cisco's Committed Access Rate and Juniper's Traffic Policing. For all cases discussed, it is presumed that we have 1 honeynet which is behind a routing or switching device which provides the rate limiting. Such a setup would work with GEN I or GEN II honeynets, but may require additional hardware. It should be noted that to date, the Linux, Cisco and Juniper example have not yet been tested, this document will remain incomplete until these are.
Motivation
There are numerous risks inherent in running a honeynet. Unfortunately, attempts to mitigate these risks often result in making the honeynet a less realistic model of a "normal" network. In the case of Denial of Service Attacks there is one technique that is well suited to reducing risk without affecting realism, Bandwidth rate limitation. In fact they can actually improve realism in situations where the honeynet is designed as a model of a low bandwidth network, such as a dial-up system. One of the solutions also allows for a configurable increase in latency, which can be handy to obscure the "location" of the network in relation to other components.
Your Options
There may are multiple ways of providing rate limiting to a honeynet. The most basic involve restriction using specific network settings, ie setting links to 10M half duplex for each honeypot. Others can be done in software and allow for greater control of the restriction. When possible it is best to use both to ensure that if the software soln malfunctions the hardware will provide a second line of defense. Below we list 4 software solutions: 2 are unix based (FreeBSD and Linux) and 2 are router based.
FreeBSD Dummynet
Dummynet is a FreeBSD system utility developed by Luigi Rizzo to test networking protocols. Conceptually it works by allowing the administrator to create virtual network pipes. These pipes are assigned several attributes including bandwidth, queue depth, and delay. The user then uses a firewall rule to define which packets are placed onto the pipe. When using Dummynet you can have the FreeBSD box act as a switch or a router. Having the device operate as a switch means it is not visible in the forwarding path by a hacker.
Configuration
In this example let us presume that we are operating the FreeBSD box as a bridging firewall and that the interface fxp0 is the public interface and that fxp1 is the private or honeynet interface. The configuration of Dummynet as well as other firewalling features is done through the ipfw command.
ipfw add pipe 1 ip from any to any in via fxp1
ipfw add pipe 2 ip from any to any in via fxp0
ipfw pipe 1 config mask src-ip 0xffffffff bw 128kbits/s
ipfw pipe 2 config mask dst-ip 0xffffffff bw 128kbits/s
This configuration allows us to limit each host behind fxp1 to 128kbits/s full duplex. The first 2 lines tell the FreeBSD what traffic needs to be sent to each pipe. The third and fourth lines tell Dummynet how to configure the virtual pipes.
Pipe 1 is configured to restrict traffic to 128kbits/s based on the source-ip address. The mask argument specifies that we should create a unique pipe for each unique source IP observed. If we were to use a mask of 0xffffff00 then we would create a unique pipe for every unique /24. Pipe 2 is similar to pipe 1 but we are examining based on the destination IP rather than the source. Two pipes are needed because we are modeling a full duplex link. Thus traffic in one direction goes to first pipe and traffic from the other direction goes into the second pipe.
This configuration works well with switching as you don't need to configure the IP addresses that are used by the honeypots. Dummynet has been around for a while and in my experience has been quite stable.
Linux Traffic Control
Linux's Traffic Control support can be used to provide generic traffic shaping. With this approach you need to set up a separate "class" for each host. The advantages of the Linux approach are basically the same as with FreeBSD with the following exceptions: it requires the specification of each host in the configuration, and it is not able to easily adjust latency to these hosts. This tool require a kernel patch. For GENII honeynets that utilize VMWare, it has not yet been determined if TC can be used on the same box as VMware. If it turns out that it does work, then it may work with non-bridges solutions, ie hogwash. Unfortunately due the way the VMware GSX bridges the virtual ethernet to the physical it is not possible to use Traffic Control if you are using bridge mode networking for the virtual hosts. (This needs verification).
Configuration
In this example, presume the same basic topology as in the FreeBSD config but with eth0as the public interface, and eth1as the honeynet.
!----- NOT TESTED YET
#-- step 1 -----
tc qdisc add dev eth0 root handle 0: htb default 0:3
#-- step 2 -----
tc class add dev eth0 parent 0: classid 0:1 htb rate 128kbit ceil 128kbit
tc class add dev eth0 parent 0: classid 0:2 htb rate 128kbit ceil 128kbit
tc class add dev eth0 parent 0: classid 0:3 htb rate 10Mbit ceil 10Mbit
#-- step 3 -----
tc filter add dev eth0 protocol ip parent 0:0 prio 1 u32 \
match ip dst 10.0.0.1 flowid 0:1
tc filter add dev eth0 protocol ip parent 0:0 prio 1 u32 \
match ip dst 10.0.0.2 flowid 0:2
#-- repeat for other direction -----
tc qdisc add dev eth1 root handle 1: htb default 1:3
tc class add dev eth1 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit
tc class add dev eth1 parent 1: classid 1:2 htb rate 128kbit ceil 128kbit
tc class add dev eth1 parent 1: classid 1:3 htb rate 10Mbit ceil 10Mbit
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 \
match ip src 10.0.0.1 flowid 1:1
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 \
match ip src 10.0.0.2 flowid 1:2
In this example we are setting up each direction of the traffic independently, for each direction we do the following:
Create a root queuing discipline for the interface in question.
Define classes to be used by the root, each class defines the equivalent of a pipe in FreeBSD.
Define filters that categorize which traffic should go to each class.
Cisco's CAR
Committed Access Rate is a feature provided in modern Cisco IOS versions. This feature is often used by ISP's to provide sub-rate service to customers. An example of sub-rate service is a customer connecting to an ISP with a Gig-E interface but only purchasing 500Mbytes of bandwidth initially. CAR can be used to do per host rate limiting but, as with the Linux solution, each host must be defined in the configuration.
!----- NOT TESTED YET
interface eth0/0
rate-limit input access-group 1 128000 0 0
conform-action transmit exceed-action drop
rate-limit output access-group 2 128000 0 0
conform-action transmit exceed-action drop
rate-limit input access-group 3 128000 0 0
conform-action transmit exceed-action drop
rate-limit output access-group 4 128000 0 0
conform-action transmit exceed-action drop
!
access-list 1 permit ip from 10.0.0.1 to any
access-list 2 permit ip from any to 10.0.0.1
access-list 3 permit ip from 10.0.0.2 to any
access-list 4 permit ip from any to 10.0.0.2
In example above, we edit the interface stanza of eth0/0 and add the rate-limit comands which specify the following:
Direction to apply the rate limiting
Access-group(which access-list) to use to pattern match with.
Average BPS
Burst BPS
Max BPS
Next, we see the access lists defined which are needed by the rate-limits. For each host that you want to rate limit, 4 additional config statements are needed.
Juniper's Traffic Policing
Junipers Policer, like the Linux and Cisco solution, uses a Token-bucket algorithm to enforce the rate-limiting. The Juniper config also requires explicit definition of the hosts to rate limit. One distinct advantage of the Juniper over the cisco is the ability to use Policing in conjunction with Circuit Cross-Connect to provide rate limiting with out decrementing TTL. No TTL decrementation by the Data Control components in a honeynet means they are not visible to the hacker through traceroute, which improves the realism of the network.
!------ NOT TESTED YET ------
[edit]
firewall{
family inet {
!-- step 1 -----
policer 128k-pipe {
if-exceeding{
bandwidth-limit 128k;
burst-size-limit 0k;
} then {
discard;
};
!-- step 2 -----
filter number1 {
!-- step 3 -----
term 1 {
destination-address 10.0.0.1/32
} then {
policer 128k-pipe;
accept;
}
term 2{
destination-address 10.0.0.2/32
} then {
policer 128k-pipe;
accept;
}
}
filter number2 {
term 1 {
source-address 10.0.0.1/32
} then {
policer 128k-pipe;
accept;
}
term 2{
source-address 10.0.0.2/32
} then {
policer 128k-pipe;
accept;
}
}
[edit interfaces]
eth-0/0/0 {
unit 0{
family inet{
!-- step 4 -----
filter {
input number1;
output number2;
}
}
}
Within the Juiper config, do the following:
Enter the firewall config and add a policers stanza that defines the rate limits.
Add 2 filters one for each direction of traffic
For each filter add 1 term for each host to be limited.
Enter the interface stanza and add the 2 filters.
--------------------------------------------------------------------------------
Summary
Bellow is a summary of some of the features that differentiate the various solutions. There are 3 categories that we looked at: Ease of Configuration, TTL Decrement, and Configurable Latency. The First category measure whether or not the system requires the administrator to define each host that is to be rate limited, if it does then it is not considered easy to configure. The second category is a indicator of whether or not the solution can be used in conjunction with switching( it may be the case that cisco's can do CAR on a switch, need verification). The Last category indicates if the solution is able to reliably add a specific amount of latency to the path.
Solution FreeBSD Linux Juniper Cisco
Easy Configuration YES NO NO, but nice syntax NO
No TTL Decrement YES YES YES NO
Configurable Latency YES NO NO NO
