Topic
You should consider using this procedure under the following conditions:
- You want to display the attack signature sets for a BIG-IP ASM system.
- You want to compare attack signature sets between BIG-IP ASM systems.
Description
A list of attack signature sets on a BIG-IP ASM system can be displayed from the command line. This allows the administrator to compare attack signature sets between different BIG-IP ASM systems. Comparing signature sets between different BIG-IP ASM systems, such as production and QA systems, is useful when testing custom signature sets within a QA environment before applying the custom signature sets to a production environment. By comparing the difference in signature sets, an administrator may prevent duplicates in signature names or applying signatures that already exist on both systems.
Prerequisites
You must meet the following prerequisite to use this procedure:
- You have administrative access to the Configuration utility.
- You have root access to the BIG-IP ASM command line.
Procedures
- Displaying attack signature sets on BIG-IP ASM systems
- Viewing attack signatures using the iControl REST API
- Limiting the displayed attack signature details
Displaying attack signature sets on BIG-IP ASM systems
To display attack signature sets on a BIG-IP ASM system, query the database for attack signature sets and save the output to a file by performing the following procedure:
Impact of procedure: Performing the following procedure should not have a negative impact on your system.
- Log in to the Advanced Shell (bash).
- Run a query for the attack signature sets and redirect the output to a file.For example, the following commands query the database for attack signature sets, create the /var/tmp/unit1_sig_sets.out file, and redirect the query’s output to the file:
BIG-IP ASM 11.6.0 and later
mysql -uasm -p`perl -I/ts/packages -MF5::Cfg -e ‘print F5::Cfg::get_mysql_password()’` PLC -e “select PLC.NEGSIG_SETS.set_name,PLC.NEGSIG_SETS.set_id,PLC.NEGSIG_SIGNATURES.sig_id,PLC.NEGSIG_SIGNATURES.sig_name from PLC.NEGSIG_SETS,PLC.NEGSIG_SIGNATURES order by set_name,sig_id;” > /var/tmp/unit1_sig_sets.out
You can add signature description details to the query by adding the PLC.NEGSIG_SIGNATURES.sig_desc field to the query.
For example:
mysql -uasm -p`perl -I/ts/packages -MF5::Cfg -e ‘print F5::Cfg::get_mysql_password()’` PLC -e “select PLC.NEGSIG_SETS.set_name,PLC.NEGSIG_SETS.set_id,PLC.NEGSIG_SIGNATURES.sig_desc,PLC.NEGSIG_SIGNATURES.sig_id,PLC.NEGSIG_SIGNATURES.sig_name from PLC.NEGSIG_SETS,PLC.NEGSIG_SIGNATURES order by set_name,sig_id;” > /var/tmp/unit1_sig_sets.out
Note: Adding the PLC.NEGSIG_SIGNATURES.sig_desc field to the query considerably increases (x10) the query time and the size of the unit1_sig_sets.out file. F5 recommends that you do not run this query on BIG-IP ASM devices during high load.
- You can use common Linux utilities to view (cat, more, view, and less) the attack signatures. Additionally, you can use Linux command line utilities such as awk and grep/egrep to search for specific attack signatures.
For example, the following command parses the file asm_signatures.txt for attack signatures centric to predictable resource location and then limit the displayed signatures to URI specific signatures:
awk ‘($1 == “Predictable” && $3 == “Location” ) && ( $0 ~ “(URI)” ) { print $0 }’ /var/tmp/unit1_sig_sets.out
Important
: This command may need to be manually typed because using cut and paste may inadvertently include hidden characters that may cause the command to fail.Example command output:
Predictable Resource Location Signatures 299999982 200000029 DOS/Windows short name access (URI)
Predictable Resource Location Signatures 299999982 200000041 ASP.NET configuration file access (web.config) (URI)
Predictable Resource Location Signatures 299999982 200000093 XSS script tag end (URI)
Predictable Resource Location Signatures 299999982 200000096 XSS script target (URI)
Predictable Resource Location Signatures 299999982 200000099 XSS script tag (URI)
Predictable Resource Location Signatures 299999982 200000108 Javascript Entity (URI)
… - Repeat this procedure for all BIG-IP ASM systems of interest.
- After you have copied all of the files to the same physical system, you can compare attack signature sets by using the diff command, or tool of your choice, to check for any differences between the file contents.
Viewing attack signatures using the iControl REST API
You can use the iControl REST API to query the BIG-IP ASM system for attack signatures and save the data to a text file. The text file can then be parse using common Linux commands.
Additionally you can retrieve the attack signature sets from multiple BIG-IP ASM devices and then compare the files using Linux commands such as diff.
Impact of procedure: Performing the following procedure should not have a negative impact on your system.
- Log in to the command line of the BIG-IP ASM system.
- Retrieve the attack signature sets using the following iControl REST API command syntax:
curl -k -u
: -X GET https://localhost/mgmt/tm/asm/signature-sets | jq -M . | tee Note: Replace
: with a BIG-IP ASM Configuration utility administrative username and password. Note: The command example can also be used to retrieve the attack signature list from a remote BIG-IP ASM device by replacing localhost with the hostname or IP address of the BIG-IP ASM device.
- Use the following Linux command syntax to extract the attack signature IDs from the file to an alternate file:
awk ‘$1 == “\”signatureId\”:” { print $2}’
| sort | tee Note: Replace <ids file name> with a unique logical file name for each BIG-IP ASM device, such as the system hostname.
- Repeat steps 1 through 3, retrieving the attack signature sets from the BIG-IP ASM system to compare signature sets against.
- Place all the signature ID list files in a local directory on a Linux or BIG-IP device.
- To compare the total attack signature IDs in each of the two lists of attack signature IDs run the following command:
wc -l <file name> <file name>
For example:
wc -l asm101.example.com asm102.example.com
35212 asm101.example.com
33735 asm102.example.com
68947 totalNote: This command gives you the total number of lines (signatures) in each file.
- Using the following Linux diff command, you can compare the attack signature ID list files to view attack signature IDs that are unique to each file.
diff -y –suppress-common-lines asm101.example.com asm102.example.com
Note: This syntax displays all the attack signature IDs listed in the both files side by side. Signature IDs that are unique to the first file have a corresponding < (left arrow) in the second column for the second file, and signature IDs unique to the second file have a corresponding >(right arrow) in the left column for the first file.
Example output:
> 200021137
> 200021140
> 200021140
> 200021140
> 200021140
> 200021140
> 200021140
> 200021140
> 200021140
200022008 <
200022009 <
200022010 <
200022011 <
200022012 <
200022013 <
200022014 <
200022015 <
200022017 <
200022018 <
200022019 <
…
Limiting the displayed attack signature details
Using the iControl REST API you can retrieve detailed information regarding attack signatures. This information can be verbose. Using common Linux commands you can limit the displayed data of retrieved attack signature sets.
- To retrieve all the attack signature sets from the BIG-IP ASM using an iControl REST API command use the following syntax:
curl -sk -u <username>:<password> -H “Content-Type: application/json” -X GET https://localhost/mgmt/tm/asm/signature-sets | jq -M . | tee <file name>
Note: Replace <username>:<password> with a Configuration utility administrative username and password. Replace <file name> with a unique Unix style file name that is specific to the device.
Example attack signature detail retrieved from the BIG-IP ASM 14.1.0:
{
“matchesWithinPlainText”: false,
“matchesWithinGwt”: false,
“isUserDefined”: false,
“matchesWithinCookie”: false,
“kind”: “tm:asm:signatures:signaturestate”,
“selfLink”: “https://localhost/mgmt/tm/asm/signatures/3LXQbQhIINowlPjnE1zISQ?ver=14.1.0”,
“matchesWithinParameter”: false,
“systems”: [
{
“systemReference”: {
“link”: “https://localhost/mgmt/tm/asm/signature-systems/9ySigIBMpBbYU4r8FNAt4g?ver=14.1.0”
}
},
{
“systemReference”: {
“link”: “https://localhost/mgmt/tm/asm/signature-systems/rmJS-0tJyICXEV_B5PrXCQ?ver=14.1.0”
}
}
],
“references”: [
{
“value”: “CVE-2010-2227”,
“type”: “cve”
}
],
“matchesWithinXml”: false,
“id”: “3LXQbQhIINowlPjnE1zISQ”,
“matchesWithinHeader”: true,
“signatureId”: 200200002,
“matchesWithinJson”: false,
“name”: “Non-standard Transfer-Encoding header value”,
“lastUpdateMicros”: 1510506047000000,
“description”: “\nSummary:\nThis event is generated when a non-standard value is seen for the \”Transfer-Encoding\” HTTP header. The only commonly used value for this header is \”chunked\”.\n\n–\nImpact:\nNot known.\n\n–\nDetailed Information:\nThis event is generated when a suspicious \”Transfer-Encoding\” HTTP header value is detected. \n\n–\nAffected Systems:\nAll systems.\n\n–\nAttack Scenarios:\nThere are many possible.\n\n–\nEase of Attack:\nSimple to medium.\n\n–\nFalse Positives:\nNone known.\n\n–\nFalse Negatives:\nNone known.\n\n–\nCorrective Action:\nEnsure the system is using an up to date version of the software and has had all vendor supplied patches applied. \n\n–\nAdditional References:\n\n–\n”,
“revision”: “1”,
“matchesWithinRequest”: false,
“attackTypeReference”: {
“link”: “https://localhost/mgmt/tm/asm/attack-types/HgiC5vtNTMgDoIldHkf6Ag?ver=14.1.0”,
“name”: “Other Application Attacks”
},
“matchesWithinResponse”: false,
“matchesWithinUri”: false,
“accuracy”: “high”,
“risk”: “high”,
“signatureType”: “request”
}, - You can use the following command syntax to retrieve all attack signatures and then limit the viewed output to only attack signatures with a specific attribute:
curl -sk -u <username>:<password> -H “Content-Type: application/json” -X GET https://localhost/mgmt/tm/asm/signature-sets | jq -M . | grep -A1 <attribute>
Note
: If you have created an all attack signature sets file as described in the first procedure step, you can parse the file directly without retrieving the attack signature sets using the REST command. You can use just the Linux grep command syntax on the file. From the following example: grep -A1 <attribute> <file name>.For example
curl -sk -u <username>:<password> -H “Content-Type: application/json” -X GET https://localhost/mgmt/tm/asm/signature-sets | jq -M . | grep -iA1 <attribute>
Note: Replace <username> with the Configuration utility administrative user name, replace<password> with the user name password. Replace <attribute> with the signature attribute that you want to limit the command output on (examples: URI, PHP, SQL, XPath, and so on).
For example the following command syntax retrieves attack signatures limiting the displayed signatures to signatures that contain the attribute “(URI)”.
Note: If you have created an all attack signature sets file as described in the first procedure step you can parse the file directly, using the Linux command syntax: grep -iA1 “(URI)” <file name>.
curl -sk -u <username>:<password> -H “Content-Type: application/json” -X GET https://localhost/mgmt/tm/asm/signature-sets | jq -M . | grep -iA1 “(URI)”< p>
Example command output:
“name”: “\”/..namedfork/data\” execution attempt (URI)”,
“signatureId”: 200003068
—
“name”: “\”/proc/self/environ\” execution attempt (URI)”,
“signatureId”: 200003132
—
“name”: “\”chdir\” execution attempt (URI)”,
“signatureId”: 200003184
—
“name”: “\”chfn\” execution attempt (URI)”,
“signatureId”: 200003186
… - You can use the following command syntax to retrieve attack signatures displaying only their ID, name and description:
curl -sk -u
: https://localhost/mgmt/tm/asm/signatures | jq ‘.items[]|.signatureId,.name,.description’ Example command output:
200000003
“Web-Server sample dir access”
“Summary:\nThis event is generated when an attempt is made to access hidden web site content or functionality. This is a general detection signature (i.e. it is not specific to any web application).\n\n–\nImpact:\nInformation disclosure. This may aid the attacker to mount a more dangerous attack.\n\n–\nDetailed Information:\nBy making educated guesses, the attacker could discover hidden web site content and functionality, such as configuration, temporary, backup or sample files.\nThis can lead to the disclosure of sensitive system information which may\nbe used by an attacker to further compromise the system.\n\n–\nAffected Systems:\nAll systems.\n\n–\nAttack Scenarios:\nAn attacker can search the web site for known sample files or files with .tmp, .bak and other extensions or attempt to access administrative pages or directories.\n\n–\nEase of Attack:\nSimple.\n\n–\nFalse Positives:\nNone known.\n\n–\nFalse Negatives:\nNone known.\n\n–\nCorrective Action:\nEnsure the system is using an up to date version of the software and has had all vendor supplied patches applied. Restrict access to sensitive files and nonpublic web server functionality.\nUtilize \”Positive Security Model\” by accepting only known types of input in web application.\n\n–\nAdditional References:\n\nPredictable Resource Location\nhttp://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml\n\n–\n” 200000002
“Unix home dir access (/~)”
“Summary:\nThis event is generated when an attempt is made to access hidden web site content or functionality. This is a general detection signature (i.e. it is not specific to any web application).\n\n–\nImpact:\nInformation disclosure. This may aid the attacker to mount a more dangerous attack.\n\n–\nDetailed Information:\nBy making educated guesses, the attacker could discover hidden web site content and functionality, such as configuration, temporary, backup or sample files.\nThis can lead to the disclosure of sensitive system information which may\nbe used by an attacker to further compromise the system.\n\n–\nAffected Systems:\nAll systems.\n\n–\nAttack Scenarios:\nAn attacker can search the web site for known sample files or files with .tmp, .bak and other extensions or attempt to access administrative pages or directories.\n\n–\nEase of Attack:\nSimple.\n\n–\nFalse Positives:\nNone known.\n\n–\nFalse Negatives:\nNone known.\n\n–\nCorrective Action:\nEnsure the system is using an up to date version of the software and has had all vendor supplied patches applied. Restrict access to sensitive files and nonpublic web server functionality.\nUtilize \”Positive Security Model\” by accepting only known types of input in web application.\n\n–\nAdditional References:\n\nPredictable Resource
Location\nhttp://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml\n\n–\n”
… - Alternatively, you can use the iControl REST API to query for attack signatures with a specific object. In the following example command syntax only attack signatures with the “matchesWithinUri” object are returned.curl -sk -u <username>:<password> -H “Content-Type: application/json” -X GET https://localhost/mgmt/tm/asm/signatures -d ‘{“matchesWithinUri”:”true” }’ | jq -M .Other possible attack signature objects are listed in the following table.
Signature object Object value accuracy high
medium
lowisUserDefined true
falsematchesWithinCookie true
falsematchesWithinGwt true
falsematchesWithinHeader true
falsematchesWithinJson true
falsematchesWithinParameter true
falsematchesWithinPlainText true
falsematchesWithinRequest true
falsematchesWithinResponse true
falsematchesWithinUri true
falsematchesWithinXml true
falserevision numeric value risk high
medium
lowsignatureId attack signature numeric value signatureType request
response - Using a combination of objects you can retrieve a more specific list of attach signatures.For example, to retrieve a list of attack signatures that are URI-based, high accuracy, and high risk, you can combine the objects matchesWithinUri, risk, and accuracy into the iControl REST command.
curl -sk -u <username>:<password>t -H “Content-Type: application/json” -X GET https://localhost/mgmt/tm/asm/signatures -d ‘{“matchesWithinUri”:”true”,”risk”:”high”,”accuracy”:”high” }’ | jq -M.
Note: You can use the Linux commands demonstrated previously in this article to refine the attack signature information retrieved from the iControl REST API command.