Quarantine Bandwidth Abusers

Instructions to detect and quarantine those users who use more than their fair share of bandwidth

There are many approaches to keeping applications and users' bandwidth usage in line. Many are covered elsewhere in PacketGuide. For example, you can limit each user with a dynamic partition, cap an application's usage with a partition, or keep each session within reason with a rate policy.

Sometimes you might want to track individual users who use unreasonably large amounts of bandwidth. Once you identify these excessive users, you can enforce limitations on their bandwidth usage without impacting other users. We call this process "placing users into a penalty box." These instructions help you do just that. Three alternative solutions are presented, two using the adaptive response feature, and one using the host accounting feature.

Alternative One: Use Adaptive Response (High Bandwidth Host Agent)

The following scenario is used as an example throughout this first alternative's steps:
Move any user who is using more than 12 percent of capacity to the penalty box. Limit each user in the penalty box to a restrained amount of bandwidth. Cap the penalty box at ten percent (or another reasonable portion) of capacity. Each bandwidth abuser stays in the penalty box until the end of the day (midnight).

1. Create a traffic class under Inbound to contain your overly exuberant users. Name it PenaltyBox. Set protocol = IP, service = any, and server location = any. Create a host list called abusers and reference it in the class' matching rule as an inside host list (assuming your users are located on the inside).
   
   Once the host list and traffic class are defined, change the class' type from Standard to Exception.
   
   Repeat the same process to create a PenaltyBox class under Outbound. But this time, you can simply reference the abusers host list you already created. You needn't create a second host list.
   
   Later, you will use these PenaltyBox classes to limit the bandwidth that each quarantined user can access. And you will use the abusers host list to add and remove users from the PenaltyBox's restrictions.
   
   
2. Create a static partition for your PenaltyBox classes with size = 0 Kbps, burstable, and a limit of the maximum bandwidth you'd like to devote to all the abusers together. For example, you could limit the aggregate of all your greedy users to 10 percent of your link size.
   
   
3. Define a dynamic subpartition for your PenaltyBox classes giving each user the restricted amount of bandwidth you consider appropriate for their penalty phase. For example, you might cap each user at 64 Kbps.
   
   
4. Create a host list called exceptionHosts and add all the hosts and/or subnets you don't want placed in the penalty box. This list will contain all of your servers and other hosts for which you don't want to restrict traffic.
   
   
5. Plan an adaptive response agent to monitor host usage, quarantining and freeing bandwidth abusers appropriately. The agent should add the IP addresses of abusers to the abusers host list and restore abusers to the network's good graces by the next day.
   
   For background information on adaptive response, see Adaptive Response Overview.
   
   It would seem that when a formerly greedy bandwidth abuser's usage declines to a reasonable level, you would want to stop restricting their access. But, that is probably not a great idea. You are limiting your greedy user's access, so of course usage would drop dramatically. If you restore full access as soon as usage drops, your abuser would be liberated almost immediately, and that wouldn't make for a very effective deterrent.
   
   You really want to leave your bandwidth abusers quarantined for at least the current day. Our example liberates quarantined users at midnight. The schedule command is the appropriate vehicle to accomplish this goal. You can use it to schedule the future removal of one or all greedy hosts from the abusers host list.
   
   
6. Create an adaptive-response agent based on the High Bandwidth Host template. This agent will monitor host usage and will automatically add greedy hosts to the abusers host list (using an action file).
   
   Use the following parameters for your agent and action file:
   • RedThreshold: 12 percent
   • GreenThreshold: 5 percent
   • Red Action File: badhost.cmd
   • Red action file contents:
     #Title: Restrict a greedy host by moving it to the abusers host list (and remove it later)
     hl add abusers $host-ip
     
   • Green Action File: none
     
     
7. Create a command file that deletes the PenaltyBox traffic classes and clears out all entries in the abusers host list. (In the next step, you'll schedule this command file to run every night.) The command file should contain the following commands:
   
   class delete /Inbound/PenaltyBox
class delete /Outbound/PenaltyBox
hl rm abusers
hl new abusers
class new /Inbound PenaltyBox nodefault inside list:abusers outside host:any
class new /Outbound PenaltyBox nodefault inside list:abusers outside host:any
class set /Inbound/PenaltyBox exception
class set /Outbound/PenaltyBox exception
   
   This command file will delete the PenaltyBox traffic classes, remove the abusers host list, and then recreate the classes and host list.
   
   
8. Create the following schedule using the command scheduling setup page:
• Choose file and enter the name of the command file you created in step 6.
  
• Make sure delete file when done is not selected
• Choose local time and specify the time you want the command to run. In our example, it would be 23:59:59
• Choose daily
• Make sure "once only" is not selected
• Enter your email address in Mail results to
  
  
9. Make sure shaping is enabled.
   

Alternative Two : Use Adaptive Response (Quota Bandwidth Host Agent)

This alternative uses a different scenario: Move any user who exceeds his/her bandwidth quota (10 MB of download) to the penalty box. Prevent each user in the penalty box from using any more bandwidth until the end of the day (midnight).

1. Create a traffic class under Inbound to contain your over-quota users. Name it PenaltyBox. Set protocol = IP, service = any, and server location = any. Create a host list called abusers and reference it in the class' matching rule as an inside host list (assuming your users are located on the inside).
   
   Once you have defined the host list and traffic class, change the class' type from Standard to Exception.
   
   
2. Assign a discard policy to your PenaltyBox class.
   
   
3. Create a host list called exceptionHosts and add the IP addresses and/or subnets of all the hosts you don't want placed in the penalty box. This list will contain all of your servers and other hosts for which you don't want to restrict traffic.
   
   Note: This step is very important because the discard policy drops traffic for all hosts that exceed bandwidth quota.
   
   
4. Create an adaptive-response agent based on the Quota Bandwidth Host template. This agent will monitor host usage and will automatically add over-quota hosts to the abusers host list.
   
   Use the following parameters for your agent:
   
   • HostUsageThreshold: 10000000 bytes
   • HostUsageMonitorInterval: 1 day
   • Side: Inside
   • ViolatingHosts: abusers
   • ExceptionHosts: exceptionHosts
   • RedThreshold: 1
   • GreenThreshold: 0
     
     
5. Enable the agent at the time you want the interval to begin/end (such as midnight).
   
   Note: Since agents are automatically enabled when you create them, you should disable the agent immediately after creating it. Then, at midnight (or whatever time you want a day to officially begin), re-enable the agent so that the monitoring interval starts at the beginning of the day. Rather than staying up until midnight to issue the command yourself, you can schedule the command agent on Quota Bandwidth Host agent to run once only, at midnight.
   
   
6. Make sure shaping is enabled.

Alternative Three : Use Host Accounting

Note: Host accounting is not available on the PacketShaper 900 Lite, 1200, or 1400 Lite models.

The following scenario is used as an example throughout this second procedure's steps:
Catch each user moving over one gigabyte of data in a single day. Restrict the user to a maximum rate of 64 Kbps for two days. Then remove the restrictions.

(Note: the CLI commands for steps 1 through 5 are listed at the end of step 5)

1. Create a traffic class under Inbound to contain your overly exuberant users. Name it PenaltyBox. Set protocol = IP, service = any, and server location = any. Create a host list called abusers and reference it in the class' matching rule as an inside host list (assuming your users are located on the inside).
   
   Once the host list and traffic class are defined, change the class' type from Standard to Exception.
   
   Repeat the same process to create a PenaltyBox class under Outbound. But this time, you can simply reference the abusers host list you already created. You needn't create a second host list.
   
   Later, you will use these PenaltyBox classes to limit the bandwidth that each quarantined user can access. And you will use the abusers host list to add and remove users from the PenaltyBox's restrictions.
   
   For more information, see Traffic Tree Overview, Traffic Classification Overview and/or Matching Rules Overview.
   
   
2. Create a static partition for your PenaltyBox classes with size = 0 Kbps, burstable, and a limit of the maximum bandwidth you'd like to devote to all the abusers together, perhaps 5 to 15 percent of your link size.
   
   
3. Define a dynamic subpartition for your PenaltyBox classes giving each user the restricted amount of bandwidth you consider appropriate for their penalty phase. For example, you might cap each user at 64 Kbps.
   
   For more information, see Partition Overview.
   
   
4. Enable host accounting using the command-line interface:
   host accounting enable inside 10 3000000
   
   PacketWise's host accounting feature, only available with the command-line interface, offers a way to track byte counts of throughput for each IP address, group of users in a host list, or subnet.
   
   For more information, see host accounting.
   
   
The CLI commands used to this point are as follows:

hl new abusers
class new inbound PenaltyBox inside list:abusers
class set inbound/PenaltyBox exception
partition apply inbound/PenaltyBox 0 15%
partition dynamic apply inbound/PenaltyBox per-address inside 0k 64k
class new outbound PenaltyBox inside list:abusers
class set outbound/PenaltyBox exception
partition apply outbound/PenaltyBox 0k none
partition dynamic apply outbound/PenaltyBox per-address inside 0k 64k
host accounting enable inside 10 3000000


5. Choose an interval of time over which you'd like to measure bandwidth usage. Perhaps a day or perhaps a week. Each time your interval elapses, you'll need to quarantine new abusers and free previous abusers. For our example, we'll use a day.
   
   Choose an amount of data for that interval that you consider unreasonable and above normal usage expectations. For our example, we'll consider it unreasonable for any user to fetch or send more than one gigabyte in one day.
   
   
6. Let your time interval pass, giving your organization's users enough time to create a usage track record.
   
   
7. Retrieve your per-user usage data. Both CLI commands measure dump and host accounting retrieve work to access these measurements. You might want to restrict the report data to a specific subnet(s) or host list to monitor only those IP addresses you really want to examine. For example, universities typically examine only those subnets that go to the students' residential facilities.
   
   Example command lines:
   me dump host all by element 1d sort bytes
   host accounting retrieve dns all 6/9 08:00 to 6/10 08:00 into usage.txt
   
   Measure dump has a handy "sort" option so that you can find all your top users quickly and automatically. Host accounting lacks a "sort" option so you must take extra steps to massage the output file to group the top users.
   
   
8. If you use the "host accounting retrieve" command, put the results into a text file just as the above example does using the file usage.txt. Download the results file to to a PC, open it with Excel or another spreadsheet utility, and sort the rows based on the contents of the "bytes" column. Alternatively, you could use the file with any utility or script that would pull out all rows containing a bytes column bigger than your limit.
   
   
   
   
9. Examine the top users in your list. Note those whose associated bytes count exceeds your limit.
   
   
10. For each user or IP address that you want to quarantine, add the address to your abusers host list referenced by your PenaltyBox traffic classes. Because you are probably already using the CLI, you might find the CLI command more convenient:
    hl add abusers <the_abuser_host>
    
    
11. To be polite, consider sending the user email to tell them their bandwidth will be restricted for a couple of days due to excessive use.
    
    
12. You don't want to leave your quarantined user in the penalty box for too long. Maybe just a brief stay of perhaps two days will prompt the user to reform their habits. It would be convenient if you didn't have to remember to remove the user after two days. The schedule new command allows you to schedule the user's freedom without having to remember later.
    
    schedule new once:<mm/dd> <hh:mm> hl delete abusers <the_abuser_host>
    
    For example, if today is June 10th, to remove the user hoggy.yourcompany.com from the penalty box at 8:00 AM in two days, the CLI command would be:
    
    schedule new once:6/12 08:00 hl delete abusers hoggy.yourcompany.com
    

Note: You can embellish this procedure in a variety of ways. You can explore using categories in the host accounting feature to restrict the type of usage you examine. If you want to use this procedure in a frequent and ongoing basis, you can automate it by writing a script and executing PacketWise commands through APIs (application programming interfaces). (The Packeteer XML API Guide is available through the documentation web page (support.packeteer.com/documentation)). You can use the Top Talkers and Top Listeners feature to see who is using the most bandwidth within a given application or class instead of using host accounting (however, you would not get byte counts or be able to save the information for later comparison).