About these ads

David Vassallo's Blog

If at first you don't succeed; call it version 1.0

Plotting the 95th percentile using Centreon

Calculating the 95th percentile of bandwidth used by a client is a common method of billing for ISP and service providers [1]. Hence, it is also of great interest to the client to plot these values as well to keep track of their service provider fees and double check bills.

Plotting the 95th percentile on Centreon is currently not very straightforward but it is possible without too much hassle once you know what to do. This article documents what you have to do to get a proper bandwidth plot both incoming traffic and outgoing traffic’s 95th percentile.

We assume that you already have a normal bandwidth graph showing traffic in / traffic out over an interface. Once you have this graph, perform the following steps:

  • Navigate to Views > Graphs > Virtuals > Metrics


  • Create a new metric. Enter a valid name, and select the host and service for which you’d like to plot the 95th percentile. Normally the host would be the internet facing router, and the interface would be the WAN interface


  • Select a DEF type of VDEF. We use VDEF because the 95th percentile is calculated over an entire range of values, not on individual data points [2]
  • As an RPN, enter the following:

Make sure there are no spaces in the above, else you will get an error. For those interested in what is going on above, RPN (reverse polish notation) works by using a “stack”. So the way to read the above is:

 – “Push the ‘traffic_in’ dataset onto the stack”

- “Push the variable ’95’ onto the stack”

- “Calculate the result of the PERCENT function on the previous two values in the stack”

More details can be found here [3]

  • Note that the “traffic_in” will probably need to change for a specific installation, depending on what you have named this variable. Use the “list of known metrics” to select the appropriate name
  • Save the above metric. This will actually return the 95th percentile

Now, unfortunately centreon does not allow you to directly plot a VDEF (notice the”hidden graph” checkbox in the screenshot above? This cannot be de-selected). So we need to employ a little trick to turn this VDEF into a CDEF, which can be plotted. This is how that is done:

  • Again create a new virtual metric, giving it an appropriate name
  • Again select the same host and service you had previously used for the VDEF above.
  • This time, select a DEF type of CDEF


  • Here’s the trick… in the RPN field, enter the following:

Again, make sure you have no spaces in the above. Also, note that “95_in_vdef” is actually the name of the vdef you previously created. It should be listed under “List of known metrics”. What we’re doing here is simple. Break down the RPN and it should be clearer:


This adds the individual data points of “traffic_in” (the traffic of the interface) to the “95_in_vdef” you previously calculated, and places the result back onto the stack. Now, we’re only really interested in the value of “95_in_vdef”, so we subtract the result of the above from traffic_in again to just leave 95_in_vdef, which is what “traffic_in,-“ is doing.

So in essence we have the following formula:

traffic_in + 95th percentile - traffic_in = 95th percentile

Now since it’s a CDEF, we can plot this. You need to do the same for traffic_out of course. First the VDEF:

VDEF for traffic out: traffic_out,95,PERCENT

VDEF for outbound traffic: traffic_out,95,PERCENT

Followed by the CDEF:

CDEF for outbound traffic: traffic_out,95_out_vdef,+,traffic_out,-

CDEF for outbound traffic: traffic_out,95_out_vdef,+,traffic_out,-

Now, one should modify the curve lines of the two CDEFs we just defined to make them pop out a little on the graphs. this is done via the “curves” option shown in the first screenshot above, for example, in the below, we set the color for 95_percent_out (our CDEF value for the outbound traffic 95th percentile) red:


The result would be something like this:


Where you can see both inbound and outbound 95th percentile lines in blue and red respectively.


[1] http://en.wikipedia.org/wiki/Burstable_billing

[2] http://oss.oetiker.ch/rrdtool/doc/rrdgraph_data.en.html#___top

[3] http://oss.oetiker.ch/rrdtool/tut/rpntutorial.en.html

About these ads

Practical Reflected File Download and JSONP

This week introduced us to a new web attack vector, which the researcher dubbed “Reflected File Download” [RFD] . It’s a very interesting attack which has potential to do some severe damage, especially in social engineering contexts. Full details of the reflected file download attack can be found here:


While reading through the white paper linked above, the author notes that, when talking about code injection points, JSONP callbacks make a good, albeit limited, entry point for attacker code:

” JSONP Callbacks – by definition a JSONP callback is reflected back into the response. While this is often a more limited injection point that forbids special characters, it remains usable for some RFD payloads. ” [1]

The author also notes the use of the “download” HTML attribute [2] to force a download rather than view a generated file in-browser. In most of my tests, sites either validated the JSON callback, or did not allow manipulation of a downloaded filename by using the ;/filename.bat;/filename.bat trick which Hafif uses. However, the attack does increase the importance of validating JSONP callbacks.

Validation of JSONP callbacks has been on the radar from quite some time. An interesting blog post by Tav [3] back in 2009 illustrates that even back then, JSONP callback validation was an important issue. So, how easy would it be to pull off an attack based on the JSONP callbacks and the techniques presented in the RFD paper?

Maybe a bit too simple. Taking the same friendfeed.com API which Tav mentions  (aside: why hasn’t this been patched yet?!) , visiting the url:


We get the output of:


Confirming that the unvalidated JSONP callback still exists. But now with RFD, this is what we can do:

  • We note that the API doesn’t directly allow a user to download a file, so the HTML download attribute will have to be used


  • We test if the API allows an attacker to modify the filename as per the RFD paper like so:
<a href="http://friendfeed.com/api/feed/public;/test.sh;/test.sh?callback=alert%28document.cookie%29%3Bfoo{}" download> Test </a>

It doesn’t… the server returns


 indicating the server is looking for test.py on it’s filesystem rather than allowing “loose urls” which make the browser use test.py as the download filename. We can still get around this however…

  • Create a link on an attacker controlled page (or via XSS injection or other badness…) like so:
<a href="http://friendfeed.com/api/feed/public?callback=echo${IFS}cHJpbnQgJ0hlbGxvIFdvcmxkJwpwcmludCAncGF3bmQgOignCg==|${IFS}base64${IFS}--decode${IFS}|${IFS}python||" download="test.sh"> FriendFeed Test </a>

Note  I have now modified the JSONP callback value to something we can run… The command is geared towards a bash shell, and deserves some explanation:

- The ${IFS} serves as a replacement for whitespace. Some JSONP APIs filter out whitespace in callback functions, so it depends on what you find out there

- The actual commands to be run are base64 encoded, again, to avoid some filtering in the JSONP callbacks APIs

- The base64 string is decode, and passed into python.

- The final || are the bash Boolean “or”. This means if the first command does not run, then run whatever command comes after this symbol. Since we know the first part of the command is going to work, bash will disregard the second part, effectively commenting out the rest of the feed…

  • A clever social engineer would style the link and put it into context, claiming something like “Free FriendFeed Reader”… you get the point. The user would maybe check the link out, but seeing the “friendfeed.com” domain, would probably not give it a second thought, congratulating himself for remembering to even check the link domain :)


  • The file will be downloaded, coming from friendfeed.com – probably throwing off web firewalls, url filters, etc…
JSONP and RFD download

JSONP and RFD download

  • If the user were to run the file (I’ve been using bash for convenience, as Hafif notes in his paper, an attacker would use .com, or .bat and try get around the system execution policies), we get:


So, in conclusion, JSONP in conjunction with RFD can be quite damaging. Mitigation strategies include, at a minimum, properly sanitizing the user input for your JSONP callbacks. Hafif outlines a couple more.


[1] “Reflected File Download a New Web Attack Vector” – Oren Hafif

[2] http://www.w3schools.com/tags/att_a_download.asp

[3] http://tav.espians.com/sanitising-jsonp-callback-identifiers-for-security.html


Get every new post delivered to your Inbox.

Join 170 other followers