Security Policy HTTPS redirect
Hi all, We are using a security policy on our LTM Virtual server to block access (and redirect to a "you are blocked page") from a list sanctioned countries. We are using an irule to do the redirect, on Action = "Accept Decisively". The redirect for HTTP works great, but I have not been able to get the HTTPS to redirect. I have tired several different irule configurations but none of them have worked. irule: when CLIENT_ACCEPTED { SSL::profile /www-qa/xxx.site.443.profile.clientssl log local0. "XXXHTTP client accepted" } when HTTP_RESPONSE { log local0. "XXXHTTP responding data" HTTP::redirect https://you.are.blocked.com\r\n\r\n } Any ideas on what I am missing, or a better way to add a redirect on a HTTPS securTty policy? thanks
Debate: How do you configure an optimal and scalable ASM policy structure?
The reason behind this question is to raise a debate regarding how BIG-IP administrators usually go about configuring ASM policies. I have heard numerous of different methods but no real "best practices" regarding structuring the policies. In order to get started with a policy, I tend to only go with a Negative Security Policy, focusing on Attack Signatures based on the Generic bundle or adding technology specific bundles. The reason for this is that the application developer does not have a clue how the application works and they do not have dedicated teams that operate the policies when I leave the project (working as a consultant). I have also seen demos for AWAF and Cloud Edition, where you simply "add a policy" and you're protected, using a more generic policy for all applications. For the applications requiring more specific policies, you create individual for those applications. With Layered Security Policies, this should be quite easy to manage and I'm guessing that is the main reason for it. What I had in mind was to create the following policy structure: 1. Generic Policy - This will form as a baseline, created using the Rapid Deployment Method and will only contain the Generic Attack signatures along with other mandatory settings. This policy should be mandatory for all applications. 2. Technology Based Policies - This will be a child policy to the Generic Policy also focusing on the Negative Security Model. Here we add attack signatures based on technologies in order to form "security packages". Creating perhaps the following policies: Windows Linux IIS (Windows + IIS) Apache (Linux + Apache) These will be gradually created as the teams send in their orders with technologies that does not already have a policy. The reason for this is to make it easier for App Teams to select a security package based on what technologies their application is running. 3. Application Specific Policies - This will also be based on the Generic Policy but with more specific settings. Here we can exclude certain attack signatures that are not compatible with the application but also create a policy based upon the positive security model. The core concept of having a model like this to make it easier for app teams to get a baseline and/or a slightly advanced policy. With the application specific policy, you won't be locked down and having exclusions affect all applications. Also having the ability to create specific and more secure policies for the applications that require it. This is just an idea I've had when thinking about structuring the ASM policies but I have no idea if this is feasible in real life. Is there anyone operating their ASM policies in this manner or do you have a different approach?
Unable to view ASM policies.
I don't know if this is a bug but maybe somebody has come upon this issue - When browsing to "security>> application security policies:policies list" I am unable to view my policies. I am using version 13.1.0.7. I have this issue in three different browsers, and in both nodes of my F5 cluster. As a result I cannot perform any actions regarding any of the policies. This is what it looks like. Note the entry number on the side - you can see that policies do exist. They are just not visible.
Duplicate ASM policies in GUI after 12.1.1 HF1 upgrade
Went from 12.1.0 to 12.1.1 HF1 and discovered under my App Security -> Security Policies -> Active Policies that I show 2 of each policy in the GUI. Oddly enough, it only reported it twice via GUI, not when I checked via CLI. When I booted back to 12.1.0, the GUI duplicates went away. This has occurred on two separate pairs of F5s I have a case open for this, but am wondering if anyone has seen similar behavior with 12.1.1 HF1?