Forum Discussion

Zdenda's avatar
Zdenda
Icon for Cirrus rankCirrus
Jul 26, 2019

ASM - Rest API - sig-set ID

Hi,

signature-set IDs used in iControl Rest use those IDs:

(either ID in a link of sig-set like: "/asm/signature-sets/XFklAdYbdN8MUWbi74WC3g", or ID of sig-set already used in policy like "/asm/policies/abcdc123/signature-sets/4IXuDlyTtr3C4d322L27nQ")

 

My question is, are those IDs static, for example defined from signature-set name? Or can those IDs be changed after LB upgrade, reboot or so?

I have one specific signature set (created by myself) and would like to hardocde ID of it to my code in order to quickly add it or remove from any policy.

 

Thanks,

Zdenek

 

ASM Advanced WAF
devops
iControlREST
security
  • Sebastien6's avatar
    Sebastien6
    Icon for Altostratus rankAltostratus
    Jul 28, 2019

    All the ASM hash in URLs are MD5 hash from name of object. Only If you change the name, the hash change. Remain the same outside of that even between various version of TMOS.

  • Satoshi_Toyosa1's avatar
    Satoshi_Toyosa1
    Ret. Employee
    Aug 01, 2019

    Here's the steps to create the hash from the name of the ASM object.

    1. Create the MD5 digest from the name (yields 128 bits of binary data)
    2. Encode it using base64 (yields 24 characters)
    3. Trim the last two "==".

    For example,

    # echo -n /Common/sat | openssl dgst -md5 -binary | base64 | cut -c-22
9afAWDUoawpiNnfSfSGtMQ

    Obviously, because MD5 is not reversible (one-way), the hashed ID cannot be decoded back to the object name.

    See also

    • Sebastien6's avatar
      Sebastien6
      Icon for Altostratus rankAltostratus
      Aug 02, 2019

      Cool thank you. Works fine. Per chance, do you know the way to do it for whitelist=ips?

      I know the name is based on a combination of ipAddress/ipMask, as hash change if you change the ipMask.

       

      I tried all those without success for 192.168.0.30/255.255.255.255 that should be 2S_b6WCJRsVKz9zgrtxYPA:

       

      b'192.168.0.30/255.255.255.255'

      b'/192.168.0.30/255.255.255.255'

      b'/Common/whitelist-ips/192.168.0.30/255.255.255.255'

      b'/Common/whitelist-ips/192.168.0.30/255.255.255.255'

      b'/Common/seb-dev-policy1/whitelist-ips/192.168.0.30/255.255.255.255'

      b'/Common/seb-dev-policy1'

      b'/whitelist-ips/192.168.0.30/255.255.255.255'

       

      tried also all of them using 192.168.0.30_255.255.255.255 with no success.

       

       

       

       

       

       

  • Satoshi_Toyosa1's avatar
    Satoshi_Toyosa1
    Ret. Employee
    Aug 06, 2019

    For an entity with multiple values, you need to concatenate them with "###UNLIKELY_DELIMITER###" as the delimiter: i.e., "192.168.0.30###UNLIKELY_DELIMITER###255.255.255.255".

    Also, I forgot to mention one more step. Because Base64 generates characters that are not URI safe, "+" and "/" must be translated to "-" and "_" respectively: i.e., sed 'y/+\//-_/'.

    Here's the revised version of the steps:

    1. Create a source input string by concatenating the elements using the ###UNLIKELY_DELIMITER### delimiter.
    2. Create the MD5 digest from the source input (yields 128 bits of binary data)
    3. Encode it using base64 (yields 24 characters)
    4. Trim the last two "==" (22 characters)
    5. Transliterate "+" and "/" to "-" and "_" respectively.

    For example,

    echo -n "192.168.0.30###UNLIKELY_DELIMITER###255.255.255.255"  | openssl dgst -md5 -binary | base64 | cut -c-22 | sed 'y/+\//-_/' 
2S_b6WCJRsVKz9xgrtxYPA

    Note that the order of elements matters (e.g., 192.168.0.30...255.255.255.255 vs. 255.255.255.255...192.168.0.30) and depends on what entity you are dealing with. You need to try out (although the complexity of a brute-force try-and-error is O(2^N), thankfully, there is not so many combinations).

    Cheers.