Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology

Allow vuln scanner or pen tester access dynamically? One time code, OTP, comparison?

We would like to allow vulnerability scanners or pen testers to send requests without being blocked on an ad hoc basis without our intervention. Currently we have to add a temporary IP address exception which requires a policy change to add and then remove it. Not ideal.

Has anyone else done this?

Our testing team suggested adding a header to their requests, something like X-SCAN-TESTING-{OneTimeTokenCode}:{TestersMonthlyTokenCode} (not sure why you'd need both). This is an interesting idea, but how would you generate the code in an iRule to compare it to? Or, rather than generate the code in the iRule, could you make an external call to a location where the OTP was generated and stored?

Rate this Question

Answers to this Question


It is certainly possible to do with an iRule and a datagroup containing a list of codes (or allowed IP addresses which is much easier to implement). Lists of codes/IP Addresses are easier to manage in a datagroup rather than constantly adding/removing IP address exceptions in ASM policies.

you would simply use ASM:disable command if the request contains your X-SCAN-TESTING header


having an iRule to connect and retrieve OTP from an external source is a bit over-engineering for such a simple problem, but it is certainly possible

You can also have the solution with no iRule at all and just put all the rules of header checking into the local traffic policy

Comments on this Answer
Comment made 16-Oct-2017 by cdjac0bsen 60

True, it is easier, but when you resort to using a static tag, a hacker could eventually uncover it and bypass the ASM policy.


Chris, I understand the challenge here. What you can do is have a dynamic tag which changes daily (or weekly or monthly - whatever suits you). Not quite OTP, but easy to manage and set up.

The way to achieve it is to write an iRule which takes the current date and mixes it with some "secret" "salt" value and then hashes the result using a hashing function (e.g. MD5 or SHA1 or whatever your security requirement to a hashing function is).

For example (let's assume the secret is "cdjac0bsen")

we take today's date 20171018 and add the secret (e.g. concatenate with a dash):


then the above value is hashed using md5. It produces "d39cb5a222be728dddd1ff3adc480cb5" - you can simply give this token to your pentesters - this token will be valid for the whole day.

Tomorrow the token will change to: 81e20431312f37d6572651d242f2521a (md5 of "20171019-cdjac0bsen").

The iRule will compare the token value received in header X-SCAN-TESTING with this calculated value. If they match - it is a valid pentester, if they mismatched - it is a hacker or someone using an old/stolen token.

Hope this helps,