Web proxy concepts

These are concepts that apply to both Transparent and Explicit Proxy.

Proxy policy

Information on Proxy policy options can be found at Proxy option components on page 50

Configuration information can be found at Web proxy configuration on page 365

Proxy authentication

Beginning in FortiOS 5.6, authentication is separated from authorization for user based policy. You can add authentication to proxy policies to control access to the policy and to identify users and apply different UTM features to different users. The described authentication methodology works with Explicit Web Proxy and Transparent Proxy.

Authentication of web proxy sessions uses HTTP basic and digest authentication as described in RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication) and prompts the user for credentials from the browser allowing individual users to be identified by their web browser instead of IP address. HTTP authentication allows the FortiGate unit to distinguish between multiple users accessing services from a shared IP address.

The methodology of adding authentication has changed from FortiOS version 5.4 and previous version. Splitpolicy has been obsoleted and instead of identity-based-policy, authentication is managed by authenticationscheme, setting and rule settings. These authentication settings are no longer configured with the individual policies. Authentication is set up in the contexts of:

config authentication scheme config authentication setting config authentication rule

The Authentication rule table defines how to identify user-ID. It uses the match factors:

l Protocol l Source Address

For one address and protocol, there is only one authentication rule. It is possible to configure multiple authentication methods for on one address. The client browser will chose one authentication method from the authentication methods list, but you can not control which authentication method will be chosen by the browser.

Matching

If a rule is matched, the authentication methods defined in the rule will be used to authenticate a user. The procedure works as the following:

Proxy authentication

1. If it is IP-based, look up active user list to see a user existed from the source IP. If found, return the user ID.
2. If no method is set, an anonymous user is created to associate to the source-IP. Return the anonymous user. It is another way to bypass user authentication for some source IPs.
3. Use authentication methods to authenticate the user.
   • If no active method is defined, a failure will result to return an anonymous user. l Otherwise, a valid or guest user has to be identified to move on.
   • Return the identified user ID.

Once a user is returned, the policy match resumes until a policy is matched or default policy will be used.

Processing policies for authentication

Authentication rules are checked once a User-ID is needed in order to resolve a match to a policy Use the following scenario as an example of the process.

There are 3 policies:

l policy1 does not have an associated user group l policy2 has an associated user group l policy3 does not have an associated user group

Step 1

If the traffic, based on protocol and source address matchespolicy 1, no user authentication is needed. The traffic is processed by policy1.

Step 2

If the traffic does not match policy 1, and any factor of policy 2 is not matched, continue to next policy.

If all the factors except the user-group of policy 2 are matched the authentication rule table is checked to get user-ID in the process in based on the procedure described earlier in Matching.

Step 3

When a user-ID is returned, whether it is a valid user or anonymous user, it is checked to see if the user is authorized by the user group associated with policy2. If yes, it is a match of policy2, and the traffic is processed by policy2. If not move on the next policy.

Step 4

For the purposes of the scenario, it will be assumed that the traffic either matches policy3 or that policy3 is the final policy that denies everything.

CLI syntax

Removals:

l “split-policy” from firewall explicit-proxy-policy.

The previous method to set up a split policy was: config firewall explicit-proxy-policy Proxy authentication

edit 1

set proxy web set identity-based enable set groups <User group> config identity-based-policy edit 1

set schedule “always” set utm-status enable set users “guest”

set profile-protocol-options “default” next

end

next

end

• “auth relative” from firewall explicit-proxy-policy

The following attributes have been removed from firewall explicit-proxy-policy:

• identity-based l ip-based l active-auth-method l sso-auth-method l require-tfa

Moves:

users and groups from firewall explicit-proxy-policy identity-based-policy to

config firewall proxy-policy edit 1 set groups <Group name> set users <User name> end Additions:

authentication scheme

config authentication scheme

edit <name> set method [ntlm|basic|digest|form|negotiate|fsso|rsso|none]

• ntlm – NTLM authentication. l basic – Basic HTTP authentication. l digest – Digest HTTP authentication. l form – Form-based HTTP authentication. l negotiate – Negotiate authentication. l fsso – FSSO authentication.
• rsso – RADIUS Single Sign-On authentication. l none – No authentication.

authentication setting

config authentication setting set active-auth-scheme <string> set sso-auth-scheme <string> set captive-portal <string>

set captive-portal-port <integer value from 1 to 65535>

l active-auth-scheme – Active authentication method. l sso-auth-scheme – SSO authentication method. l captive-portal – Captive portal host name. l captive-portal-port – Captive portal port number.

authentication rule

config authentication rule edit <name of rule> set status [enable|disable] set protocol [http|ftp|socks] set srcaddr <name of address object> set srcaddr6 <name of address object> set ip-based [enable|disable] set active-auth-method <string> set sso-auth-method <string> set web-auth-cookie [enable|disable] set transaction-based [enable|disable] set comments

• status – Enable/disable auth rule status. l protocol – set protocols to be matched l srcaddr /srcaddr6 – Source address name. [srcaddr or srcaddr6(web proxy only) must be set]. l ip-based – Enable/disable IP-based authentication. l active-auth-method – Active authentication method.
• sso-auth-method – SSO authentication method (require ip-based enabled) l web-auth-cookie – Enable/disable Web authentication cookie.
• transaction-based – Enable/disable transaction based authentication. l comments – Comment.

Configuring authentication in transparent proxy

You can enable transparent web-proxy feature to support authentication. Follow these steps

1. Configure a firewall policy
2. Enable a UTM profile in the firewall policy. Whenever there is a UTM item enabled, the feature enables the profile-protocol-options.
3. Go to the Proxy Options

l In the GUI this is Security Profiles > Proxy Options. l In the CLI it is config firewall profile-protocol-options.

Edit the profile used by the policy.

4. Enable HTTP in the profile.

Proxy addresses

In the GUI toggle on HTTP under Protocol Port Mapping In the CLI, the command sequence is:

config firewall profile-protocol-options edit <profile id> config http set status enable end

Fill out any other appropriate values.

5. Configure the proxy-policy, and set the value transparent-web for proxy option, others configuration are same as the explicit-web proxy

In the GUI, go to Policy & Objects > Proxy Policy. In the Proxy Type field choose Transparent Web .

In the CLI, the command sequence is:

config firewall proxy-policy edit <profile id> set proxy transparent-web end

Fill out any other appropriate values.

6. Setup the authentication rule and scheme

With this configuration, if a HTTP request passes through FortiGate without explicit web proxy being applied, the traffic will be redirected to WAD daemon after it matches the proxy with HTTP-policy enabled, then WAD will do the proxy-policy matching, and all of the proxy authentication method can be used for the request.

Proxy addresses

Information on Proxy addresses can be found at Proxy addresses on page 229

Proxy address group

In the same way that IPv4 and IPv6 addresses can only be grouped together, Proxy addresses can only be grouped with other Proxy addresses. Unlike the other address groups, the Proxy address groups are further divided into source address groups and destination address groups. To see the configuration steps go to Proxy address groups on page 231

Web proxy firewall services and service groups

Configure web proxy services by selecting Explicit Proxy when configuring a service. Web proxy services can be selected in a explicit web proxy policy when adding one from the CLI. If you add a policy from the web-based manager the service is set to the webproxy service. The webproxy service should be used in most cases, it matches with any traffic with any port number. However, if you have special requirements, such as using a custom protocol type or a reduced port range or need to add an IP/FQDN to an proxy service you can create custom explicit web proxy services.

Web proxy services are similar to standard firewall services. You can configure web proxy services to define one or more protocols and port numbers that are associated with each web proxy service. Web proxy services can also be grouped into web proxy service groups.

One way in which web proxy services differ from firewall services is the protocol type you can select. The following protocol types are available:

l ALL l CONNECT l FTP l HTTP l SOCKS-TCP l SOCKS-UDP

To add a web proxy service go to Policy & Objects > Servicesand select Create New. Set Service Type to Explicit Proxy and configure the service as required.

To add a web proxy service from the CLI enter:

config firewall service custom edit my-socks-service set explicit-proxy enable set category Web Proxy set protocol SOCKS-TCP set tcp-portrange 3450-3490

end

To add a web proxy service group go to Policy & Objects > Servicesand select Create New > Service Group. Set Type to Explicit Proxy and add web proxy services to the group as required.

To add a web proxy service group from the CLI enter:

config firewall service group edit web-group set explicit-proxy enable set member webproxy my-socks-service

end

Learn client IP

If there is another NATing device between the FortiGate and the Client (browser), this feature can be used to identify the real client in spite of the address translation. Knowing the actual client is imperative in cases where authorization is taking place.

The settings for the feature are in the CLI in the context of config web-proxy global

Once here, enable the feature with the command:

set learn-client-ip enable

Once the feature is enabled, the other settings become available.

learn-client-ip-from-header

This command has the following options:

learn-client-ip-srcaddr/learn-client-ip-srcaddr6

The options for this setting are selected from the list of IPv4 address or IPv6 address objects.

Example

Below is a config example where the real client ip address will be used to match policy or fsso authentication after the learn-client-ip feature enabled.

The value of learn-client-ip-from-header option can be set to true-client-ip, x-real-ip or x-forwarded-for, but in this case it has been set to x-forward-for.

config web-proxy global set proxy-fqdn “default.fqdn” set webproxy-profile “default” set learn-client-ip enable

set learn-client-ip-from-header x-forwarded-for set learn-client-ip-srcaddr “all” end

config firewall proxy-policy edit 1 set proxy explicit-web set dstintf “mgmt1” set srcaddr “all” set dstaddr “all” set service “w” set action accept set schedule “always” set groups “fsso1” set utm-status enable set av-profile “default” set dlp-sensor “default” set profile-protocol-options “default” set ssl-ssh-profile “deep-inspection” end

config authentication rule edit “rule1” set srcaddr “all” set sso-auth-method “scheme1” end

config authentication scheme edit “scheme1” set method fsso

end