In this lesson, we'll discuss Angela Cearns small autonomous anti-DDoS system called A2D2 for defending against DDoS attack. It utilizes an index firewall rate-limiting and Class-Based Queuing, CBQ for short, to deal with various types of attack traffic, including ICMP, UDP, and TCP. We'll see how effective different mechanics in dealing with those attack traffic. It also implements a Snort flood preprocessor to detect subnet flooding, and it implemented a multilevel rate-limiting scheme to adapt to suspicious traffic, because sometimes we don't know for sure this is a real attack. It could be real legitimate users. We see in the next lesson how to effectively use these different filtering techniques to deal with various DDos attack traffic types. At the end of the lesson you will learn the basic IP table command for setting up class-based queuing or rate-limiting technique to deal with suspicious traffic and all DDos attacks. You will understand the effectiveness of those different schemes in dealing with DDos traffic patterns. Angela built a small scale DDos defense evaluation test-bed as you see here in the picture. She built a small tech network using Linux machines with a stock tool software from University of Washington implemented for launching a DDos attack. I believe the one calling for a tech agent here and on the right side you'll see there is the site with the DMZ firewall and enhanced Snort IDS with subnet flooding processor that she implements herself to test the effect of these various attack scheme defending against DDos attack. She set up a few RIO servers, three of them, Realplayer client to launching a real time streaming video retrieving from the RIO server a Realplayer server it hosted in the DMZ zone subnet. The metric for A2D2 system effectiveness including number packet loss, re-transmission requests generated, and how much of those re-transmission response is coming back. Here we show the rate-limiting set up using the IP table command. The IP table command with minus-N option is used to set up a different kind of chain. Here we set up three different levels of rate-limiting. So Level Two, Level One, Level Zero. For Level Two we use minus-A to specify the chain of the root and the forwarding rule. The rate-limiting is limited for traffic to that chain to be 100 packets per second. And we use that minus-N limit option to specify this kind of rate. When those rates are exceeded the packet in that chain will be dropped. For Level One, we specify the rate of 50 packet per second and any packet routed to Level Zero will be dropped. The last rule says, in the fourth chain if we see any packet with a source IP address 12.23.34.45, we will route them to the Level One chains and start to subject to the rate-limiting. And if the traffic from the source is exceeding 100 packet per second the remaining packet during those periods will be dropped. So there's a window they can only accept that 100 packet per second. We use a Snort preprocessor to count the accuracy rate from a subnet and switch the suspicious traffic to Level One if over that 30 minute period we continue to have that 100 packet per second and once it goes to Level One they only allow 50 packet per second. Now most Snort IDS consist of rule based detection engine check, or the Snort root. If they match, the packet gets dropped will generate an alert. Or the other thing, you try to extend the feature, what you can do is allow the programmer and designer to use their API to add a program into their normal packet processing and that can be done before the root check. That's pre-processing, or after the other Snort root is checked that's post-processing. The customized program can be inserted before the root engine or up to root engine to the actual working system. Here it shows a set of files to prepare when Angels implemented the subnet of network flooding detection. If you are interested you can actually visit her master thesis for more detail. Here we show the A2D2 adaptive multilevel rate limiting system. The report C program will run and listen to the Snort host to accept the Snort alert messages generated by the preprocessor. And then forward this rate information to the process running on the firewall and the process will run rate if.pl postscripts listening to a particular port and the program report C can send these messages to that particular port. Once rate if.pl is received a request you are parsing the message take out the subnet information and then looking at the firewall rule decide whether to change,update and insert the rule changing from Level Two to Level 1 to Level Zero. When the traffic exceeds a certain ratio the packet from the subnet will be put on rate limiting chain and if the traffic level persists you go to the next level and so on, until it goes back for a short period time and then perhaps for a longer period of time or even days. Here we show the implementation and processing of Class-Based Queuing, CBQ for short, on a Linux firewall. First the packet will be classified. We need to classify the packet based on their type or header content and then set the mark value in the header, set the different mark value based on the protocol type. And once that further down the road when we actually start doing the processing that can be processed based on the mark value. For example here SMTP is mark one, HMTP mark two, NNTP mark three, and ICMP mark four. We then specify these four different queue with different bandwidth quota to serve the packet marked with those mark number. So the packet with a different protocol will be treated differently with the different kind of bandwidths. Next we will show the IP table command for actually setting the CBQ up. Here we show the IP table command to mark different protocol and services traffic with a different mark value 1-4. Minus-P specifies the different protocol, minus-O, as before, specifies the outgoing interface device. Now here we use DMZ to represent whatever the DMZ interface. If it will be open to the DMZ subnet. Minus-J Mark indicates the jump options. We consider that to be like a subroutine. It will be marking the packet, changing the bit field in the IP header, with a dash-dash mark with a number and where we used those six month mark field. Here we show how to use a traffic control TC command to set up the queue display. Please check the related TC main page for detailed parameter specifications. After creating the root class and initialize with those parameters, in this script we describe a class subroutine and allow it to be shared by setting different classes. It kicked in six parameter. The first one, dollar sign one, is the parent class. Dollar sign two, which is completion for shell script, dollar sign representing a second parameter which is the particular class ID. The third one is high bandwidth and the second one is the lowest bandwidth for the class, and then handle, and then last one is style. And actually the style is the mark value IP table command we set up in the previous slot. Here we show how the four traffic class for ICMP, simple file transfer protocol, FTP, and the combined web and real time streaming services. How are they generated, those 10.1 10:1 is a low cost ID. The second parameter is 10:100, 100 is the ICM class ID. SNTP is 10:200. FTP is 10:300. World wide web, STP, and the RIO server traffic is 10:400. The bandwidth allocation for these 4 different groups are 5 percent for the ICMP, 15 percent and 10 percent and 70 percent, respectively. So we give more bandwidth for the kind of traffic, which is the Web and the real time streaming services. The actual To calculate and is 10 megabit modify by that number those percentage numbers. So the ICMP will have the high bandwidth is no more than 512 kilobit per second. And the e-mail is 1.5 megabits per second top, and email is one megabit, and the world wide web and real time streaming has 7.1 megabit per second kind of bandwidth. So the last parameter to add to the add class function is style. Always a mark value.
