Howto find out how many bps a policy is using for a fortigate ( cool-trick from Socpuppets )

In this post we will look a rude,  but  simple means for counting up  how much bandwidth a policy is using.

This uses the simple diag sys session cli command and by capturing the output that we will than pipe into a script. You can set filters based on what you want to sum up or count. You can be get very creative using this approach. Here's an example of our everyday problems.

Question;

How many times have you  had a director ask you " how much bandwidth  is a person using or how much traffic to/from this host? or we have this new application and how much traffic does it uses? or how much traffic does that SIP call uses ? etc.......... "

And you end up with the deer in the headlights look? and with no response?

Okay here's a means for identifying  just how much traffic a policy-id or with other filters applied such as; port,src,dst,etc..... You can get a good base number of overall traffic consumption by applying filters and collecting the data for analysis.

In  my case,  I'm demonstrating on a FGT3140 and by using firewall policy-id#14 for DNS traffic & host 8.8.8.8 . I would like to get a total sum of how much bandwidth that's being using collectively by that policy-id #14.

1st we will set a session filter with  my existing policy-id #14 listed,  but let's look at the available filter options that you can act upon.

Now we will use the policy filter and specify the policy-id # and validate  the filter was set;

cli 

diag sys session filter policy 14
diag sys session filter dst 8.8.8.8

And here's our session filters & with the filters set.

here's the firewall policy-id#14

Now the fun begins, you will need to capture your screen output via the ssh/telnet/console terminal session.

NOTE: On unix I like to use the  script cmd before starting my  capture and ssh session.
http://unixhelp.ed.ac.uk/CGI/man-cgi?script

Now we execute the cmd with grep to extract the bps line similar to this.

The output of the capture would look something like the following in your capture buffer;

So this captured output can now be acted upon by using a little of unix scripting commands such as; cat/cut/awk .  We can take counts & sum up the totals for the lines collected.

e.g
cat <mycollectdata.filename>   | grep bps | cut -d "," -f2 | cut -d "=" -f2 | awk '{ sum += $1 } END { print sum }'

So we know the  set filter parameters  for our system session & policy-id#4 & it has a collected total of 9,034105 mbps of traffic in use. Cool !

By using the appropiāte  filters and by  being as specific as possible, we  can collect data for analysis. I find this a great means for looking at potential abusive users,  or to validate and QoS traffic-limiting functions that might be deployed, or determine how much traffic is going to a service, policy, host, protocol, etc..........

Always clear the filters via the following cli cmd before apply new filters and after data  collection. Validate that the correct expected  filters are applied;

               diag sys session filter clear 
               diag sys session filter


Lastly,

Sometimes we will need to insert a specific policy at the top the list if you wanted to  evaluate all traffic for just one particular host. I find this approach is better in a lot of case & I use this approach if not daily at least weekly when doing traffic analysis inspections.

Just  add the policy, build your session filter on that policy and then run the command and collect the data. After your satisfied, than remove the policy.

e.g ( let's say you suspect user at 1.1.1.1 is infected with a virus )


config firewall address 
     edit suspect1
         set subnet  1.1.1.1/32
end

config firewall policy 
    edit 0 
        set srcintf "port2"
        set dstintf "port1"
            set srcaddr "suspect1"            
            set dstaddr "any"            
        set action accept
        set schedule "always"
            set service "all"            
        set comments "checking how much traffic suspect 1 is using  by this policy "
    next

Than you will move this new policy-id at the top of fwpolicy list, and run your collection as discussed earlier & above.

Just remember that fwpolicies are a top to bottom matched,  and then the most specific policy is always used. So if you had policys   1,2,3,4,5,6,7,8,9, from to bottom, the #1 would be looked and matched before going to number 2,3,4 and so on.

So if you wanted to find traffic (ALL ) from  suspect1 ( 1.1.1.1 ) you can craft a similar policy and  perform your forensic collection. Adjust the services you  suspect maybe one protocol or service. And insert it before any broader policy.

remember to remove or disable  these temporary policy afterwards


This approach is also great for just determining the top talkers for  a particular services or host.

Good luck and I hope you find this approach become beneficial & helpful in your environment.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \