New Member

Question

manage application control and web filter

Forum|Forum|9 years ago
April 11, 2017
10 replies
35434 views

Hi

I have a problem of designe between application control and web filter

i have a machine that i want to

- make update through apt-get

- acces to specific url

i have application control with apt update and it works

but as soon as i apply my welb filterting to the only specific adress i want to allow the apt update doesn't work anymore.

what are the relation vetween web filter and application control?

hmtay_FTNT

Staff

Hello edoutreleau,

There are 2 modes that you can run in the profile-based firewall policy. Proxy-mode and Flow-mode. In flow-mode, packets are scan by all the security modules at the same time.

All of the applicable flow-based security modules are applied simultaneously in one single pass, and pattern matching is offloaded and accelerated by CP8 or CP9 processors. IPS, Application Control and CASI, flow-based Web Filtering and flow-based DLP filtering happen together.

In proxy-mode, the packets are first scanned by App Control before they are scanned by the Web Filter proxy.

Decrypted SSL traffic is sent to the IPS engine (where IPS, Application Control, and CASI can be applied) before re-entering the proxy where actual proxy-based inspection is applied to the decrypted SSL traffic.

The links below should help you understand the flow chart for both modes in a better way hopefully.

http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-life-of-packet-54/lop-packet-flow-flow.htm

http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-life-of-packet-54/lop-packet-flow-proxy.htm

A couple of questions about your configuration:

1. My guess is you want to block everything else and allow only Apt-Get and certain URLs. Is that correct?

2. If 1 is yes, are you blocking everything but Apt-Get on App Control?

3. If 2 is yes, and you use Web Filter to whitelist certain URLs, that would not work because while the new policy has Web Filter whitelisting the URLs, App Control does not whitelist the URLs. Packets have to be able to get through all the security modules to be allowed through. If any one module drops the traffic, then it will be dropped.

>>but as soon as i apply my welb filterting to the only specific adress i want to allow the apt update doesn't work anymore.

This sounds weird.

Can you send me your configuration file, a packet capture, App Control logs and Forward Traffic logs in a PM? I will check them and let you know what could have been wrong. Thanks.

HoMing

ted_barker

New Member

Dear HoMing

Interesting topic (currently finished NSE4, tomorrow NSE7 training) and I still do not understand exactly the difference and how to apply which feature to the current problem. Maybe you can shed some light.

From what I understand is that the goal is

-- to allow apt-get update only to a single host, i.e. http://ch.archive.ubuntu.com/ubuntu/

So the application control signature apt-get sound like a good thing to do. I.e. allow apt-get.

Now in order to limit to the above HOST or URL a static URL webfilter with a match on it could be used to further limit apt-get to only those URL.

1) application control with signature apt-get update

2) webfilter static URL with a match on ch.archive.ubuntu.com (no idea how you filter on the host part only, without some regex, no support from FortiOS to match protocol, domain, host, path?)

Now if proxy inspection or flow inspection should not make a difference for that, right? It looks like the order of applying is not different, Application Control before Web Filter?

Question A) in your reference to flow based it lists "L7 decoder" web filtering before application control, but maybe Static URL webfilter is considered a "Local URL Filtering"

Question B) Is there a way to tie 1 and 2 together in a policy, i.e. only allow if application is apt-get and Static WebFilter matches? (Not sure if you put application control and webfilter into a single policy if it is AND or OR)

Question C) Is there a better way to achieve the goal?

Question Flow/Proxy: We have all our default VDOM in proxy mode, but some inspections such as IPS are always flow based. When should a customer use only flow based VDOM/inspection?

hmtay_FTNT

Staff

Hi Ted,

I will answer your questions in order.

A) The Static URL webfilter is considered "Local URL Filtering" in the flow diagram, not the L7 decoder. The L7 decoder only tries to identify and decode the packets coming in with known decoders. The rule matching is done at "Single-Pass Rule Matching".

B) Yes. In this case, where you want to block everything else and allow only certain sites/applications, you would need both Application Control and Web Filtering. That said, you can look at Web Filtering like a subset of Application Control that covers HTTP and HTTPS sessions.

Case 1: Let's say we want to block Facebook. We can do it with either the "Facebook" signature under Application Control, or we could add Facebook's domains manually in a Static URL Filter.

Case 2: Let's say we want to block Skype. In this case, we have to use the "Skype" signature under Application Control. Web Filtering will not work because a large portion of Skype's sessions uses a proprietary protocol - non HTTP/HTTPS.

In short, whatever the Web Filter can do, Application Control can do the same. What the Application Control can do, Web Filter might not be able to do the same.

Back to the original question. Yes, you can tie them both in the same policy. What you can do is set the HTTP.BROWSER_*, SSL_*, HTTPS.BROWSER signatures in Application Control to Allow - and also Apt-Get specifically for this case. This way, you let Web Filter do the controls for HTTP and HTTPS sessions. When the Application Control module scans a HTTP/HTTPS packet, it lets the packet pass to the Web Filter module to scan it. Then, you apply the filters accordingly in your Web Filter profile - allow "xxx.com" and block "*" if that's what you want.

C) In 5.6.0, we introduced the "Policy-based" NGFW mode which works differently than the regular "Profile-based" mode of the past versions. Configuring the policy in this mode is slightly different than the regular "Profile-based" mode. I would think many people would find it easier to do the configuration under "Policy-based". Note that since this is a new OS release, there might still be issues to work on on some new features as we get more feedbacks. If you have a production environment that cannot tolerate downtime well, please be cautious.

https://forum.fortinet.com/tm.aspx?tree=true&m=147758&mpage=1

Flow/Proxy) It's up to your environment and the tradeoffs you are willing to accept. Proxy-mode provides more features for Web Filter and AV and also more security modules. Flow mode, while providing less, provides better performance.

hmtay_FTNT

Staff

I will start with the last question since it is a quick and short one.

>>Also can FGT match against SNI if no SSL decryption done? A) in WebFilter B) in Application Control

Yes. Use certificate-inspection instead of deep-inspection.

>>WebFilter matching. http://2abc.abc.com:888/a..om/abc?ed.harris=5#tag2 scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] What are the recommendations from Fortinet on how to define the regex that it does not is to heavy.

The URL has distinct characters to separate each parts like "://", ".", ":", "/", "?", "#". These are straight forward delimiters to use to separate scheme, user, password, host, port, path, query and fragment.

For the actual names, you do not need to use '.'. You can do something like [a-zA-Z0-9]{x,y} if you want to set a min limit or max limit. That way instead of checking for all hex characters, you limit the check to printable chars that are used in a string. If more special characters could appear like "ed.harris=5", you can add '.' and '=' into the character class for that section.

Sign up

Login with SSO

Login to the community

Login with SSO