BIG-IP Troubleshooting 101

When you work with any technology there reaches a point where the “it’s a black box” approach is no longer valid and you have to dig in a little deeper and understand how the product works. With F5 BIG-IP this means understanding how traffic flows through the appliance and how to monitor and watch it.

TMOS – Client and Server Traffic
The F5 BIG-IP Traffic Management Operating System (TMOS) is a dual-stack full proxy which means the client terminates their TCP connection with the BIG-IP and the BIG-IP then makes a new TCP connection to the backend server. So as far as the client is concerned the F5 is the server and as far as the backend server is concerned the F5 is the client. So when you are troubleshooting it is important to understand there will always be client-side traffic and server-side traffic. The names are pretty self explaining but can be misleading in the troubleshooting process. What I mean by this is you’ll more than likely need to look at both client and server side traffic to gain a better understanding in how the application behaves/operated.

LTM Monitors
LTM monitors are used to evaluate the health of a pool member or a node. They typically run at a set interval (15 seconds by default) and will mark a pool member or node down after 3 failed intervals (this setting is configurable). If you are unsure why a monitor is failing the first place to look is the Local Traffic Manager logs. These logs are accessible via the GUI (System -> Logging) or the CLI (less /var/log/ltm) and will give you some basic information such as:
– when the resource was makes offline
– if the resource is flapping

The LTM log will not however tell you why the monitor failed. To determine this you typically need to run a synthetic request using a CLI based tool such as curl or the TMSH monitor test command. Please note: if you can not access the application using these steps the F5 is probably not at fault – no matter how much the application owner swears everything works on the server 

If this is a new application deployment I typically see monitor failures resulting from:
– Networking/firewall issues
– does the BIG-IP have a Self-IP on the sames network as the server?
– If not does the BIG-IP have a route to that network?
– Application issues
– Is the web server using name bases virtual directories? If so, what HTTP host header is it expecting?
– does the host OS have a firewall installed/configured?

If this is an existing application you need to answer the tried and true “what changed” question. In these scenarios I typically work my way down this checklist to see where the problem lies:
– can I ping the server?
– can I telnet to the port?
– can I run a synthetic request using a CLI tool like curl?
– does the web server respond with the correct website (if you’re using customized HTTP monitors – which I highly recommend)

These steps will usually lead me to the underlying issue or point me to the team who managed the device/server with the issue.

MSS----MTU

*Window size -- MSS -- MTU -- Fragmentation**

Window Size:

Lets assume there should be a data exchange that should happen between the system A and System B. Due to limitations on hardware capacity on both the system, they both may not have a same buffer memory space to receive the segments.

Due to this their window size would be exchanged among them during TCP 3 Way handshake.

Consider an example:

System 1: Window size is 1576 bytes
System 2: Window size is 1900 bytes

MSS (Maximum segment size): 1460 Bytes (MTU-Headers = MSS)

This is the transport value on which the data can be transmitted by the router/switch that is directly connected to the system/server.

MTU (Maximum Transmission unit): 1500 Bytes (With TCP+IP Header)

Payload data (MSS) + Headers = MTU

Fragmentation:

As far as i am aware, The fragmentation is being supported only on the attached router/switch. System/Server does not care for fragmentations.

Though the servers are capable of sending the larger data segments, the attached router/switch can able to transmit the segment at the size of 1460+40 byte headers.

Due to which the packet would be fragmented and sent as smaller packets.


Azar Sayyad Feel free to comment, If I missed something.

Part 10: Event Logging

we will dive into the excitement and necessity of event logging. Throughout this ASM series, we've looked at log files from a distance but we never really talked about how to configure logging. I know...event logging might not be the most fascinating part of the ASM, but it's really important stuff! Before joining F5, I worked as a cyber threat analyst for a government organization. I saw lots of cyber attacks against various systems. After an attack would take place, my team and I would come in and study the attack vector, target points, etc and it seemingly never failed that the system logs showed at least some (but many times all) of the malicious activity. If someone had just been reviewing the logs...
 

Logging Profiles

Logging profiles specify how and where the ASM stores requests for application data. In versions prior to 11.3.0, a logging profile is associated with a security policy, but beginning in 11.3.0 the logging profile is associated with a virtual server. I'm using version 11.3.0 in these examples, so this article will associate a logging profile with a virtual server.

When choosing a logging profile, you have the option of creating your own or using one of the system-supplied profiles. In addition, you can log data locally, remotely, or both using the same logging profile. Keep in mind that the system-supplied profiles are configured to only log data locally. The logging profile specifies two things: where the log data is stored (locally, remotely, both) and what data gets stored (all requests, illegal requests only, etc).

Creating a Profile

To create a new logging profile, navigate to Security >> Event Logs >> Logging Profiles and click the "Create" button. You will see the following screen:

 

I named this one "Test_Log_Profile" and enabled logging for Application Security. Notice that you can enable logging for Application Security, Protocol Security, and/or Denial of Service Protection. I enabled local storage and filtered for "Illegal Requests Only". Now that I have my logging profile created, I can associate it with the virtual server.
 

Configuring the Virtual Server

Navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the virtual server with which you want to associate the logging profile. Notice the tabs across the top part of the page...click on Security >> Policies and you will see the following screen:

Now you can move the logging profile from "Available" to "Selected" in order to enable the profile for the virtual server. Also, notice that "Application Security Policy" is enabled and the name of the security policy is listed in the drop down menu.

If you enable more than one profile, the ASM will apply the settings of the top profile first and then work down the list.
 

Viewing Log Files

Log data is stored in the /var/log/asm folder on the BIG-IP. You can view the details of the log data using the command line or the GUI.
 

Command Line

To view the log data via the command line, use a command like "cat" or "tail". You can also use other standard commands like "grep" to filter results or "more" to view one page at a time.

GUI

To view the Application Security logs in the GUI, navigate to Security >> Event Logs >> Application >> Requests and you will see the following screen:

You can click on any of the application requests, and the details will load in the bottom portion of the screen. You can view the Request Details, the actual HTTP Request, or the actual HTTP Response (if response logging is enabled in your logging profile). Many times response logging is not enabled due to the large amount of data this would consume.

Remote Storage

The ASM provides the option of storing log data on a remote server. When configuring a logging profile, you can view the Advanced Configuration to enable remote storage and select one of three types. The first is "Remote" and this option specifies that the ASM will store all traffic on a remote logging server like syslog. The second is "Reporting Server" and this option specifies that the ASM will store all log data on a server using a preconfigured storage format. The third option is "ArcSight" and this option specifies that the ASM will store all log data on a remote server using predefined ArcSight settings for the logs (the log messages are in the Common Event Format).

Speaking of remote storage...a popular remote log management tool is Splunk. In fact, Splunk offers a specific F5 app that does a fantastic job of organizing and displaying log data in a way that is easy to understand and consum

Part 9: Username and Session Awareness Tracking

Let's say you are building an awesome web application. You want to have as many visitors as possible, but you want to keep your application safe from malicious activity. The BIG-IP ASM can help secure your application by blocking harmful behavior before it ever gets to your app, but it can also help you track down and block the bad guys if they are able to somehow find a way in. This article will focus on the different ways you can track users by session or by username. Using these tracking capabilities, you can find a bad guy, and then you can track the activity or block it altogether.

Session Tracking

A session begins when a user accesses the web application and it ends when a user exits the application (or when the user exceeds an established timeout length). When a user accesses a web application, the ASM generates a session ID number for that specific session. You can track a specific session by enabling "Session Awareness" on the ASM. Navigate to Security >> Application Security >> Sessions and Logins >> Session Tracking and you will see the screen shown below. Simply check the "Enabled" box for Session Awareness (and Save and Apply Policy) and the ASM will give you the option to take certain actions on any specific session you choose. So, if you are looking through your ASM event logs and notice that a particular user is doing some bad things, you can start logging all activity for that user session or you can block the session completely.

 

I used my trusty Hack-it-yourself auction site to do some testing with this feature. I enabled Session Awareness and then accessed the auction site. Then, I reviewed the ASM event logs (Security >> Event Logs >> Application >> Requests) to see the details of the activity for my user session. Notice in the screenshot below that the Request Details show the Session ID as well as a link to Session Tracking Details (it also gives you a link to the APM session details...pretty cool). When you click on the Session Tracking Details link, you are given the option to Log All Requests, Delay Blocking, and/or Block All.

I selected Log All Requests and Block All, and then I tried to log back into the auction site. Guess what? Totally got blocked...and it all got logged in the ASM event logs. So, using this blocking feature, I can easily stop a user from accessing the web application simply by blocking the user session.

Now, here's a little more of my story...I accessed the auction site from my Firefox browser and, like I said before, I got blocked. I switched over to Internet Explorer and accessed the site without any problem. Makes sense, though, because I started a totally new session with the other browser. I just wanted to make sure you kept that in mind as you determine the best way to track and stop the bad guys who access your application.

Username Tracking

Let's talk about your awesome web app for a second. When you created said web app, you no doubt built a login page and established URLs and parameters so that users could authenticate and gain access. By adding these URLs and parameters into your security policy, the ASM can track users by username via the login URL you establish. In order to configure the appropriate login and access parameters, navigate to Security >> Application Security >> Sessions and Logins >> Login Pages List and create a new Login Pages List.

In the Login URL, select either Explicit or Wildcard then select either HTTP or HTTPS based on the type of traffic the application accepts, then type in the path of the login page. Next, you can select the Authentication Type (I chose HTML Form based on the structure of the Hack-it-yourself auction site). Next, type in the parameter names for the application's Username and Password parameters (these are case sensitive). When the ASM detects these parameters used together, it knows that a login attempt is taking place.

Finally, you need to configure Access Validation criteria that must be satisfied in order for the ASM to allow the user to access the authenticated URL. It's important to note that at least one of these criteria must be selected. If multiple criteria are selected, they must all be satisfied in order for the ASM to allow access to the authenticated URL. The screenshot below shows the settings for my Hack-it-yourself auction site:

After the Login Page Properties are set, you can go back to the Session Tracking settings and add the Login Page to the Application Username settings (see the screenshot below). This tells the ASM to start tracking the username from the login URL you listed

The Test

I accessed the auction site and logged in with my username (jwagnon) and password. See the screenshot below

Based on all the ASM settings I configured earlier, the ASM should have recognized this login and it should give me the option of tracking this specific user. Sure enough, the ASM Event Logs show the login action (notice the log entry for the Requested URL of /login.php in the screenshot below). I clicked on this specific log entry, and the request details show that the username "jwagnon" logged in to the site.

Much like the session tracking options, the ASM gives the option to Log All Requests, Delay Blocking, and/or Block All activity from this specific user. I chose to Log All Requests and Block All activity from this username. Then, I attempted to log back into the auction site using the "jwagnon" username and password, and the ASM blocked the request. Remember how I switched from Firefox to Internet Explorer on the session awareness tracking and I was able to access the site because of the new session I started? Well, I tried that same thing with the username tracking but the ASM blocked it. That's because I used the same username to access the application from both browsers.

I also wanted to show the actual HTTP request from this login action. I clicked on the HTTP Request tab for the /login.php event. The screenshot below shows that the request includes the parameters "username" and "password". These are the values for the username and password parameters that were identified in the Login Page Properties that we saw earlier (this is why the values for the parameters are case sensitive). The ASM recognized these two parameter values in the HTTP Request for the /login.php URL, so it gave the option for tracking the username.

Session Tracking Status

The last thing I'll mention about all this tracking goodness is that the ASM gives you the option of viewing all the session and/or username tracking details from one screen. Navigate to Security >> Reporting >> Applications >> Session Tracking Status to see all the details regarding the sessions and/or usernames you have taken action on. Notice in the screenshot below that the details for Block All and Log All Requests for both session and username are listed (it even shows the value of the session and username). You can click on the hyperlink "View Requests" on the right side of the page and the ASM will display all the requests that satisfy that specific criteria. Pretty cool and handy stuff!

Part 8: Data Guard

Data Guard

As we all know, we need to protect the personal and sensitive information of our users. So back in the day, some super-smart people developed an iRule that scrubs out credit card numbers from HTTP traffic that passes through the BIG-IP (the link to the iRule is here). This is a great iRule, but the good news is that the BIG-IP ASM gives you all the power of this iRule (and more) by simply checking a box in the Data Guard settings. In fact, the ASM gives you the option to scrub more than just credit card numbers. It also allows you to protect social security numbers and other sensitive information based on custom patterns that you can define!

In the BIG-IP ASM, you can navigate to Security >> Application Security >> Data Guard and you will see the following screen:

Notice that you can simply check the box for Credit Card Numbers and US Social Security Numbers. For credit card numbers, the ASM uses the Luhn Algorithm to verify that a specific sequence of numbers is, in fact, a valid credit card number (just because you have a sequence of 16 numbers doesn't mean you have a credit card number).

If you need to protect another specialized number, you can simply build the pattern in the "Custom Patterns" (using regular expression syntax) and enable that as well...you can add as many custom patterns as you want. In addition, you can set Exception Patterns...these are patterns that the ASM will recognize as not being sensitive.

The "Mask Data" checkbox is simple but important. When you check this box, the ASM replaces all sensitive data (as defined by any/all of the options you choose) with a string of asterisks (*). Keep in mind that if you don't check this box, the ASM will not insert the asterisks in place of your data...so make sure you check this one!

File Content Detection is a really cool feature as well. This gives you the option of selecting one or more of the available file types as sensitive data. For example, if your organization uses a specific file type for sensitive data, then you can move that document type from "Available" to "Members" and the ASM will protect the server from delivering that file type to users.

Finally, the Enforcement Mode allows you to either "Ignore URLs in the list" or "Enforce URLs in the list". The default setting is to Ignore URLs. This option allows you specify URLs that will be ignored or protected (respectively) by the Data Guard feature. If you want to protect all URLs in your application, just leave the "Ignore URLs in the list" selected and make sure there are no URLs listed...that way, the ASM doesn't ignore anything.

Blocking Settings

I feel like I talk about Blocking Settings all the time in these articles, but these settings are important! Navigate to Security >> Application Security >> Blocking >> Settings to list the options for all the blocking settings in your policy. Scroll way down to the bottom of the page to find the "Data Guard: Information leakage detected" and this will give you the option to Learn, Alarm, and/or Block when the ASM triggers on a Data Guard violation.

You will probably want to just Learn and Alarm on this setting. If you Block on this setting, then every time a Data Guard violation occurs (as defined by all the stuff you selected in the section above), the ASM will generate a Blocking Page. Instead, if you Learn and Alarm on this setting, the ASM will allow the user to see the page, but it will mask the sensitive data (as long as you select the "Mask Data" option on the Data Guard page). The screenshot below shows all the details:

The Test...

Now that all the Data Guard settings are in place, I want to see how the ASM performs on a web application. In this example, I went back to my trusty Hack-it-yourself auction site (configuration settings are here if you need them). As you can see from the screenshot below, I went to the "Sell an Item" page and entered a credit card number (looks fake, but it actually passes the Luhn test for valid credit card numbers) and a US Social Security Number.

After I entered all the data, I hit "submit" to sell my test item...this is where the ASM should catch the request and notice it contains sensitive data...
 

The Results...

As you can see from the screenshot below, the ASM recognized the sensitive data and masked it correctly. I also tested this by changing the blocking settings to "Block" and sure enough, I got the ASM block page when I tried to sell the exact same item.

Last thing...I wanted to show a screenshot of the ASM logs. Notice that the ASM simply Alarmed on this violation (no blocking page), but it caught the Credit Card Number as well as the Social Security Number. Pretty cool stuff!!

ASM Part 7: Geolocation

he ASM can do lots of great things to protect your application, not the least of which is the Geolocation features it offers. Geolocation enforcement allows you to configure which countries can access your web application. The ASM matches the client's IP address to its physical location and if your security policy is configured to allow that location, it allows the client to access your application. If you need to block certain geographical locations (i.e. you are getting several attacks from a specific country), then you can simply disallow that Geolocation in your security policy.

The ASM uses the layer 3 IP header to identify the client's IP address, but it can also be configured to use the X-Forwarded-For (XFF) address as the source address (we'll see this in a minute). If the XFF address is trusted, then the header's inner-most value will be used as the query input.

I know what you're probably thinking...in this crazy TCP/IP world, it's fairly easy to hide the true physical location of an IP address by using anonymity networks (like Tor), proxy servers, etc. And, you would be right. So, I'll simply say that it's important to keep this in mind as you allow or disallow certain locations in your security policy (i.e. don't think that just because you disallow a certain country that you have completely blocked every person from that country). Fortunately, the BIG-IP ASM has specific geolocations identified for Anonymous Proxies. In addition, if you are concerned about clients from anonymous networks accessing your application, be sure to read all about IP Address Intelligence to find even more options for blocking these anonymous users!

BIG-IP Configuration

Let's see how the BIG-IP is set up to configure all this goodness. Navigate to Security >> Application Security >> Geolocation Enforcement and you will see the screen shown below.

Notice that I selected a few unique geolocations for your viewing pleasure. I wanted to call these out since they are not typical country locations. N/A represents all the internal IP addresses that are not mapped to a country. Other represents external IP addresses that are not mapped to a specific country. Finally, as I mentioned earlier, Anonymous Proxy represents known servers that are acting as proxies (allow clients to mask their true source IP address).

As you can see, this interface keeps it really simple...you just scroll through the list of geolocations and add the ones you want blocked to the list of disallowed locations. Then, hit save...and don't forget to "Apply Policy" when you are finished!

Blocking : Settings

If you have been reading the other articles in this ASM series, you already know about this next setting. In order to block, the ASM requires you to do more than just move a geolocation to the "disallowed" list...you have to configure the blocking settings as well. After you finish listing all the geolocations that you want to block, you will need to navigate to Security >> Application Security >> Blocking >> Settings and make sure the "Access from disallowed Geolocation" is set to "Block" (you can set it to Learn and Alarm as well if you want). The screenshot below gives you all the details:

X-Forwarded-For

Let's check out how the ASM can be configured to trust the XFF header, and then we'll get into the test to make sure all this works correctly. To trust the XFF header, you will need to configure the properties of the security policy itself. Navigate to Security >> Application Security >> Security Policies and then click on the policy you want to change. This will take you to the properties page of the policy. Be sure to view the "Advanced" configuration on this page (Basic is the default view). When you are in the Advanced Configuration view, you will see the "Trust XFF Header" at the bottom of the page. Enable this setting and then add the name of the custom XFF header and click "Add". I named mine "XFF_Geo" since we're doing this crazy geolocation stuff. As a reminder, don't forget to "Apply Policy" after making these changes...or any other changes for that matter.

Now that the custom XFF header is configured and trusted, I can use this to build a GET request from any IP address I choose.

The Test...

I used Fiddler2 (awesome tool) to craft a GET request for the online auction site I've been using for this article series (https://auction.f5demo.com). You'll notice in the screenshot below that I used the XFF_Geo to allow for a different IP address than the one I normally use. In this case, I picked an address from Antarctica and sent the request...who knew they had IP addresses in Antarctica?

The Results...

Prior to adding the Antarctica geolocation to the list of Disallowed locations, I took a screenshot of the GET request from the ASM logs (Security >> Event Logs >> Application >> Requests). As you can see in the screenshot below, the request came through just fine. You can even see at the bottom of the page that the ASM knows this address is from Antarctica. In fact, if you want, you can click the "Disallow this Geolocation" right from this screen, and the ASM will move this location to the Disallowed locations for you (you still have to "Apply Policy" though). I will remind you, though...if you click on the Disallow this Geolocation button, it will disallow every IP address from that country. I'm not saying don't do it, but just be aware. In fact, this could actually be a really helpful button if you are in the middle of an attack and you need to quickly cut off access from a given location!

After I sent the first request from Fiddler2, I updated my security policy to disallow the Antarctica location. Then, I sent the request again. Here's what the ASM caught. Notice that the violation is the exact setting from the Blocking Settings we looked at earlier

Part 6: IP Address Intelligence and Whitelisting

This article will discuss some really cool ASM features: IP address intelligence and whitelisting. It's hard to defend against all the crazy cyber threats out there today, so wouldn't it be nice to know if the IP address requesting access to your application is trusted or not? And, wouldn't it be convenient to tell certain IP addresses that you explicitly trust them? Well the ASM allows you to do all that! So turn on that ASM and get ready to configure some awesomeness...

IP Address Intelligence

In·tel·li·gence noun \in-ˈte-lə-jən(t)s\: information concerning an enemy or possible enemy or an area

Imagine this...you just launched a fantastic web application, and you want as many visitors as you can possibly get. But, you also want to make sure those visitors are not harmful. These days it's hard to know if the user accessing your application is fraudulent or not. There are so many botnets, proxies, scanners, infected sources, etc running rampant today that it becomes a very daunting task to figure out which ones are good and which ones are bad.

The IP Address Intelligence feature on the BIG-IP ASM identifies IP addresses that are associated with high risk activity. When a client connection is initialized, the ASM monitors information from Layer 3 and determines if a client is already known to have a high risk profile. It's the application-equivalent of the FBI's most wanted list!

The system uses an automated algorithm to gather evidence of threats based on observation, context, and statistical modeling. The bad IP addresses are catalogued and tracked indefinitely. If one of these bad IP addresses attempts to access your application...guess what? Sorry, no dice for the bad IP.

The ASM also enables the use of the HTTP X-Forwarded-For (XFF) header as the source of the client IP identification instead of the Layer 3 address header. If you allow the XFF to be trusted, then this header's inner-most value is used, but if the XFF is not trusted, the source address from the IP header is used.

The Database

I'm sure by now you are curious about the size and function of that IP Address Intelligence database. The IP Address Intelligence feature uses the online IP address reputation service that is maintained by Webroot security services. As you can imagine, the list of bad IP addresses grows every day. Currently, the database contains well over 230 million IP addresses...and counting! The IP Address Intelligence feature uses a BIG-IP shared daemon called "iprepd" and a matching database file. The iprepd daemon updates the database file every 5 minutes...that's almost real-time updates! It does this automatically (there's no manual update option), so you can have the peace of mind that comes with knowing your application is protected from the most up-to-date list of known bad IP addresses. When the database is updated, it only downloads the changes from your current database, so the downloads go pretty quick (except the very first one).

Because the IP Address Intelligence feature uses an external service for database maintenance and functionality, it requires a separate add-on license. The database file is not included with the ASM bundled software, but once you activate the license, the BIG-IP will contact the provider site and download the database. Here's another really cool thing about this feature...once it's enabled, you can use it with all your BIG-IP modules...not just the ASM! Also, if your license ever expires (we all know you would never let this happen, but just play along for a second), the local database will still be queried and used...it just won't get the every-5-minute updates any more.

If you ever want to check on the status of the database (how many IPs were added/deleted/changed during updates), you can use the following command (the last row will show you the total number of IP addresses in the database):

tail /var/log/iprepd/iprepd.log

One last thing you should know before we dive into the BIG-IP configuration details...IP Address Intelligence is available with BIG-IP version 11.2 and newer. So, get off that 10.x (or 9.x) box and upgrade to these features that are not only really cool but are also extremely important for the protection of your valuable business assets.

BIG-IP Configuration

You can find all the IP Address Intelligence goodness by navigating to Security >> Application Security >> IP Addresses >> IP Address Intelligence. The following screenshot provides the details of the configuration options for this feature. You may have noticed that in my lab version of the BIG-IP ASM I don't have IP Address Intelligence licensed, but also notice that if it were licensed, the blue text on the right side of the screen toward the top of the page would show the last time/day the database was updated. This is an easy way to check on the database updates from the GUI rather than the command line if you lean that way (don't worry, we don't judge).

As you can see, there are several IP Address Intelligence Categories, and each bad IP address will fall into one (or more) of these categories. You have the option of Alarming or Blocking (or both) each category. Here's a quick list of what each category includes:

• Windows Exploits - includes active IP address offering or distributing malware, shell code, rootkits, worms, and viruses
• Web Attacks - includes cross site scripting, iFrame injection, SQL injection, cross domain injection, and domain password brute force
• BotNets - includes Botnet Command and Control channels and an infected zombie machine controlled by a Bot master
• Scanners - includes all reconnaissance, such as probes, host scan, domain scan, and password brute force
• Denial of Service - includes DoS, DDoS, anomalous syn flood, and anomalous traffic detection
• Infected Sources - includes IP addresses currently known to be infected with malware and IP addresses with an average "low" Reputation Index score.
• Phishing Proxies - includes IP addresses hosting phishing sites and other kind of fraud activities such as Ad Click Fraud and Gaming fraud
• Anonymous Proxy - includes IP addresses that provide proxy and anonymizing services and IP addresses registered with the Tor anonymity network

The last thing I'll mention on the IP Address Intelligence Categories is that you can look up a specific IP address and see what category(ies) it falls into. Type this little beauty into the command line and you'll see the categories (if any) for the given IP address:

iprep_lookup x.x.x.x (where x.x.x.x is the IP address)

Don't Forget The Other Block...

After you select the blocking settings for the categories listed above, you need to make one more stop before the ASM will block these bad boys. Head over to Security >> Application Security >> Blocking >> Settings and make sure you check the "Block" setting for the "Access from malicious IP address" setting. The screenshot below gives you all the details...

Is My Name On That List?

Now that we have figured out all the ways to block these bad IP addresses, let's turn our focus on how to let the good guys in. The BIG-IP ASM includes a feature called "IP Address Exceptions" that gives you the ability to explicitly allow certain IP addresses. You can navigate to Security >> Application Security >> IP Addresses >> IP Address Exceptions and you will see the following screen:

As you can see, this one is pretty simple and straightforward. You simply add an IP Address and optional Netmask (255.255.255.255 will be the Netmask if you don't add one), and then you select one or more of the options listed.

• When the Policy Builder trusted IP option is enabled, the Policy Builder will consider traffic from this specified IP address as being safe. The Policy Builder will automatically add to the security policy any data logged from traffic sent from this IP address. Selecting this option also automatically adds this IP address to the Trusted IP Addresses setting on the Policy Building Configuration screen. If you don't enable this option, the Policy Builder will not consider traffic from this IP address as being any different than traffic from any other IP address.

• When the Ignore in Anomaly Detection option is enabled, the ASM will consider this IP address as legitimate and will not consider it when performing brute force prevention and web scraping detection. Once you enable this option, the system automatically adds this IP address to the IP Address Whitelist setting for Anomaly Detection. If you don't enable this option, the ASM will not consider traffic from this IP address as being any safer than traffic from any other IP address.

• When the Ignore in Learning Suggestions option is enabled, the ASM will not generate learning suggestions from traffic sent from this IP address. If you don't enable this option, the ASM will generate learning suggestions from the IP's traffic.

• When the Never block this IP Address option is enabled, guess what? The ASM will not block requests sent from this IP address...even if your security policy is configured to block all traffic. If you don't enable this option, the ASM will treat this IP address the same as all others.

• When the Never log traffic from this IP Address option is enabled, the system will not log requests or responses sent from this IP address...even if the traffic is illegal and even if your security policy is configured to log all traffic. If you don't enable this option, the ASM will simply continue to log traffic as specified in the settings of your security policy’s Logging Profile. On a related note, this option can be quite helpful when you have approved scanners testing your application on a regular basis. You may want to keep the scanner traffic out of your logs so that you can more easily focus on the user traffic.

• When the Ignore IP Address Intelligence option is enabled, the ASM will consider this IP address as legitimate even if it is found in the IP Address Intelligence database (you know...the one we just talked about). Once you enable this option, the system automatically adds this IP address to the IP Address Whitelist setting for IP Addresses Intelligence (you can check out the screenshot in the section above and see where these IP addresses would be listed). If you don't enable this option, the ASM will not consider traffic from this IP address as being any safer than traffic from any other IP address.

ASM Part 5: XML Security

XML Concepts

The Extensible Markup Language (XML) provides a common syntax for data transfer between similar systems. XML doesn't specify how to display data (HTML is used for that), but rather it is concerned with describing data that can be manipulated and presented using other languages. XML documents are built on a core set of basic nested structures, and developers can decide how tags are named and organized. XML is used extensively in web applications today, so it's important to have a basic understanding as well as a strong defense for this critical technology.

The XML specification (described in this W3C publication) defines an XML document to be well-formed when it satisfies a list of syntax rules provided in the specification. If an XML processor encounters a violation of these rules, it is required to stop processing the file and report the error. A valid XML document is defined as a well-formed document that also conforms to the rules of a schema like the Document Type Definition (DTD) or the newer and more powerful XML Schema Definition (XSD). It's important to have valid XML documents when implementing and using web services.

Web Service

A web service is any service that is available over a network and that uses standardized XML syntaxes. You've heard of the "... as a Service" right? Well, this is the stuff we're talking about, and XML plays a big role. On a somewhat tangential note, it seems like there are too many "as a Service" acronyms flying around right now...I really need to make up a hilarious one just for the heck of it. I'll let you know how that goes...

Anyway, back to reality...a web service architecture consists of a service provider, a service requestor, and a service registry.

The service provider implements the service and publishes the service to the service registry using Universal Description, Discovery, and Integration (UDDI) which is an XML-based registry that allows users to register and locate web service applications.

The service registry centralizes the services published by the service provider.

The service requestor finds the service using UDDI and retrieves the Web Services Definition Language (WSDL) file, which consists of an XML-based interface used for describing the functionality offered by the web service. The service requestor is able to consume the service based on all the goodness found in the WSDL using the UDDI. Then, the service requestor can send messages to the service provider using a service transport like the Simple Object Access Protocol (SOAP). SOAP is a protocol specification for exchanging structured information when implementing web services...it relies on XML for its message format. Now you can see why XML is so closely tied to Web Services.

All this craziness is shown in the diagram below. I know what you're thinking...it's difficult to find anything more exciting than this topic!

 

Because XML is used for data transfer in the web services architecture, it's important to inspect, validate, and protect XML transactions. Fortunately, the BIG-IP ASM can protect several applications including:

• Web services that use HTTP as a transport layer for XML data
• Web services that use encryption and decryption in HTTP requests
• Web services that require verification and signing using digital signatures
• Web applications that use XML for client-server data communications (i.e. Microsoft Outlook Web Access)

ASM Configuration

Before you can begin protecting your XML content, you have to create a security policy using the "XML and Web Services" option. After you create the security policy, you create an XML profile and associate it with the XML security policy. You can read more about creating policies in the Policy Building article in this series. To create an XML profile, you navigate to Application Security >> Content Profiles >> XML Profiles. When all this is done, the XML profile will protect XML applications in the following ways:

• Validate XML formatting
• Mask sensitive data
• Enforce compliance with XML schema files or WSDL documents
• Provide information leakage protection
• Offer XML encryption and XML signatures
• Offer XML content based routing and XML switching
• Offer XML parser protection against DoS attacks
• Encrypt and decrypt parts of SOAP web services

Validation resources provide the ASM with critical information about the XML data or web services application that the XML profile is protecting. As discussed earlier, many XML applications have a schema file for validation (i.e. DTD or XSD) or WSDL file that describes the language used to communicate with remote users. The XML profile is used to validate whether the incoming traffic complies with the predefined schemas or WSDL files.

The following screenshot shows the configuration of the XML profile in the ASM. Notice all the different features it provides. You can download the all-important configuration files (WSDL), you can associate attack signatures to the profile (protects against things like XML parser attacks -- XML Bombs or External Entity Attacks), you can allow/disallow meta characters, and you can configure sensitive data protection for a specific namespace and a specific element or attribute. Another really cool thing is that most of these features are turned on/off using simple checkboxes. This is really cool and powerful stuff!

I won't bore you with all the details of each setting, but suffice it to say, this thing let's you do tons of great things in order to protect your XML data.

 I hope this sheds some light on how to protect your XML data. And, if you're one of the users who implements anything "as a Service" make sure you protect all that data by turning on the BIG-IP ASM.