Jump to content
Updated Privacy Statement
  • 0

Web App Firewall-Allow


Hoang Hung

Question

11 answers to this question

Recommended Posts

  • 0

|| is OR; && is and

I might have got my logic backwards last night, but don't think so... see below.

Remember: !A && !B is equivalent to !(A || B).

 

So for expression:  !(/eyz || /ecp) which we can simplify as !(A || B)

Truth table example:

user request contains:     A   | B   |   !(A || B)

/eyz                                    T    | F    |   !(T || F) == F  (policy doesn't hit - traffic allowed)       

/ecp                                    F    | T   |    !(F || T) == F (policy doesn't hit - traffic allowed)

<anything else>               F    |  F  |    !(F || F) == T (policy hits -- drops unwanted traffic)

  • Like 1
Link to comment
  • 0

Once you deploy an appfw policy pointing to a specific appfw profile (which is a set of security settings), you will need to configure the profile with the appropriate settings.

 

Decide if you are relying on simple whitelist/blacklist settings (which is going to use URL Closure:OFF) or if you want to rely on URL Closure:ON.

For simple whitelisting/blacklisting:  anything not explicitly allowed on the whitelist will be blocked. Additional URLs can then be added to the explicit blacklist as required. However, a lot of default web content is already accepted by the built in regex pattern.

 

If you use URL closure, then there are no default urls so all content is blocked initially. In this case, the types of URLs you allow on the white list then become start urls aka entry points. Once this content is allowed, links the website provides to other parts of the site will also be allowed via closure. Allowing a user to navigate to links provided by the site, but unable to browse to any url without it first being explicitly allowed or covered by closure.

 

Either configuration requires you to know a bit about your website and regular expressions.

Most page requests includ multiple objects, which would also have to be allowed such as images and stylesheets.

 

In your case, you said you want to allow access to /eyz but you don't say what you want to block.

Without closure, your start urls must account for all objects in the path/page you need access to:

The two default URLs may be permitting access to more content than you intended.

So you would need to add at a minimum, something like this to the Start URL list:

^https://webmail[.]abc[.]com/eyz$

The rest of the start URLs may allow access to the rest of the required content, but more stuff too.

 

You would then probably need to add a rule and enable to the deny url list as well:

Assuming your Ohter content is / or /xyz

^https://webmail[.]abc[.]com/$   # this may be a terrible idea; you'll have to decide if this is an allowed or denied pattern wher path ends exactly "/".

^https://webmail[.]abc[.]com/xyz   #To deny any content related to this path, don't use the "$" and leave it open ended for a broader match

 

With URL Closure, the approach to start urls and deny urls would be different; but more information would be required to construct it well.

Also consider using learning to help you figure out what you need and don't need.

 

This is just the basics as the actual AppFw config is a bit more complicated to explain.

 

For simple filtering without AppFw, you can use responder instead.

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to comment
  • 0

Here's the thing, if you don't really understand App Firewall...its probably way to complicated to try to configure with just a forum post. 

 

If you don't need the rest of the AppFw web attack protections and you just want to ensure that users can connect to the web server for paths starting with /eyz and /ecp and drop all others (because i'm assuming there are other url objects that are allowed. You might be better of with a responder policy that drops or redirects anything that is not one of the allowed paths.

 

Content Filtering uses the classic engine and will be deprecated soon. But the classic engine syntax would look like this for the path check (filter will drop traffic if not one of the allowed paths.)

!(req.http.url contains /eyz || req.http.url contains /ecp)

Use this policy in content filter as a request action and bind to your lb vserver. 

 

Preferred method:  Use A responder policy expression to drop traffic using the advanced expressions would look something like this:

add responder policy rs_pol_drop_notallowedpaths -rule '!(http.req.url.set_text_mode(ignorecase).starts_with("/eyz") || http.req.url.set_text_mode(ignorecase).starts_with("/ecp"))' DROP

 (Drop is part of previous command)

bind policy to your lb vserver...

 

NOTE: I formatted this for the CLI (by hand). The single quotes surrounding the expression are NOT needed when you use this expression in the GUI. Or you can add it via CLI and then edit it in GUI to see format.

 

We could add tests to make sure the FQDN matches webmail.abc.com, but if you are binding this policy to the vserver, this might not be necessary. If you are trying to account for http methods or other criteria than additional logic may be required.

 

 

 

Link to comment
  • 0

Hi Rhonda Rowland

when i apply policy i see that. It not hit . and I not using http, i only using https .

And now I try config policy but It not ok. My ideal: " only allowed URL as: https://webmail.abc.com/eyz , https://webmail.abc.com/ecp . All traffic other will drop.

I see that: "  Invalid rule.  "

IF i using !(REQ.HTTP.URL CONTAINS /owa || REQ.HTTP.URL CONTAINS /ecp) >>> error

""Content Filtering is deprecated - use Responder (for ERRORCODE, or DROP or RESET on the request side), Rewrite (for ADD or CORRUPT, or DROP or RESET on the response side), or Content Switching (for FORWARD) instead ""

 

plese help me.

 

Link to comment
  • 0

Hi Rhonda Rowland

Thanks you supported to me. But I have a question :

If I using REQ.HTTP.URL NOTCONTAINS /owa >>ok . But I dont  filter all host: REQ.HTTP.URL NOTCONTAINS webmail.a.com.vn  . Please help me

I cant using all domain " webmail.a.com.vn". I only used "  REQ.HTTP.URL NOTCONTAINS /owa". Because " if i using outlook i need  domain: webmail.a.com.vn . 

Please help me

 

Thanks you

Link to comment
  • 0
2 hours ago, Rhonda Rowland1709152125 said:

 

Hi Rhonda Rowland

Thanks you supported to me. But I have a question :

If I using REQ.HTTP.URL NOTCONTAINS /owa >>ok . But I dont  filter all host: REQ.HTTP.URL NOTCONTAINS webmail.a.com.vn  . Please help me

I cant using all domain " webmail.a.com.vn". I only used "  REQ.HTTP.URL NOTCONTAINS /owa". Because " if i using outlook i need  domain: webmail.a.com.vn . 

My Ideal : use filter all URL: "webmail.a.vn" , i dont use "REQ.HTTP.URL NOTCONTAINS /owa ". Because If hacker know domailn mail It can change file host at local PC" and it can access to App. so I need filter full domai " webmai.a.vn/owa"

 

Please help me

 

Thanks

Link to comment
  • 0

So your initial requirements were vary vague, so I went with the simplest answer. Now you are saying you want to allow /owa and block other stuff.  Which I guessed would be the case, but if you want an accurate policy you need to summarize your allow and deny conditions.

 

NOTE: I think the expression I used below is correct; but I ran out of time to fully validate the scenarios. But since you were asking for it again; here's what I have so far.

 

Using responder policy to filter the following:

Confirm all requests go to appropraite FQDN  and only allow paths to /eyz, /owa, and /ecp while blocking everything else. Try something like this.

 

First, I need to explain something about the policy expression.

When you look at a URL like h..ps://webmail.a.com.vn/owa/<stuff>?name1=value1&name2=value2

Changed https to h..ps to stop it from autolinking.

The following expressions match the following elements:

http.req.url matches /owa/<stuff> ?name1=value 1&name2=value2

http.req.url.path matches /owa/<stuff>

http.req.url.query matches name1=value 1&name2=value2

To get to the host name, you need this:

http.req.header("host") matches webmail.a.com.vn

or

http.req.hostname matches webmail.a.com.vn

 

So an expression that requires the FQDN to match and will drop anything that is not /eyz, /owa, ecp would look something like this. There are other ways this can be written.

!X || !(A||B||C) which is equivalent to !(X && (A || B ||C))

# expression variant 1: requires FQDN and valid path or policy is true (meaning it will drop traffic)

!http.req.header("host").set_text_mode(ignorecase).eq("webmail.a.com.vn") || !(http.req.url.path.set_text_mode(ignorecase).starts_with("/eyz") || 

http.req.url.path.set_text_mode(ignorecase).starts_with("/ecp") || http.req.url.path.set_text_mode(ignorecase).starts_with("/owa")) 

 

#expression variant 2: same thing. I find this one a little easier to "read" and its probably slightly more efficient to evaluate.

!(http.req.header("host").set_text_mode(ignorecase).eq("webmail.a.com.vn") && (http.req.url.path.set_text_mode(ignorecase).starts_with("/eyz") || 

http.req.url.path.set_text_mode(ignorecase).starts_with("/ecp") || http.req.url.path.set_text_mode(ignorecase).starts_with("/owa")) 

 

I would encourage you to test the policy logic. But it should check out.

 

#policy

add responder policy rs_pol_drop_disallowedpaths '!(http.req.header("host").set_text_mode(ignorecase).eq("webmail.a.com.vn") && (http.req.url.path.set_text_mode(ignorecase).starts_with("/eyz") || 

http.req.url.path.set_text_mode(ignorecase).starts_with("/ecp") || http.req.url.path.set_text_mode(ignorecase).starts_with("/owa"))' DROP

 

# for additional paths, we would change the expression to a pattern set to make it easier to manage. For just 3 or 4 expressions this is fine.

 

This expression may not be what you expected, but the idea is that if the FQDN doesn't match than all traffic is dropped regardless of path. if the FQDN matches, the only traffic not on the allowed paths (/eyz, /ecp, /owa) is dropped. These are allowed, but only if the fQDN is present.

If the policy is bound to the vserver, then only the webmail traffic would be on this vip.  Just be careful of the logic you use.

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...