Summary
Product: FreeProxy
Versions: FreeProxy, 3.5 and above
Note: 2033
Date reported: 15 December 2003, 18 August 2004
Issue Detail
There have been many requests for clarifying the use of resource permissions. Rather than cover the same information that can be found in the help documentation, this technical note only provides examples.
Solution
The following examples are provided.
Simple URL filtering
Simple IP address filtering
Force the user to logon to the proxy service.
Force the user to log on to the proxy service using windows authentication.
Allow all users access to some web sites, forbid all users seeing a set of web sites, and force users to logon to see anything else.
Use of the date in the resource permission
Before starting, make sure you know how to:
Create users
Create groups
Assign users to groups
Navigate to and add or change Resources
if not, review the relevant sections of the help files.
Note: after making any change, you have to stop and restart FreeProxy before the change becomes effective.
Example 1: Simple URL Filtering.
There is no need to create any users as these rules will affect everyone. In the resources for the proxy port, add the following resources.
In the port definition for the Internet proxy port:
1. Click Permissions
Add the following resource permissions using the add key.
Code:
Resource Type Resource Id Permission Applies to Group Must auth Calendar
URI or Path *badsite* Forbidden AllUsers unchecked None
URI or Path *Essex* Granted AllUsers unchecked None
URI or Path *sex* Forbidden AllUsers unchecked None
URI or Path *notgood* Forbidden AllUsers unchecked None
Freeproxy will evaluate the URIs in the order specified in the resource list. Note that the URI containing the word "Essex" is granted to ensure that it can be viewed ahead of the the rule banning "sex". If placed the other way around ("Sex" before "Essex"), the rule would have prevented the URI containing "Essex" from being viewed. Note also that the rules are not case sensitive. Therefore "Essex" = "essex" = "EsSeX" etc
Example 2: Simple IP address filtering
Again, no users are specified for IP address filtering. In the port definition for the Internet proxy port:
Click Permissions
Code:
Resource Type IP From IP to Permission Group Must auth Calendar
Client IP Address 192.168.5.5 192.168.5.7 Granted AllUsers unchecked None
Client IP Address 192.168.6.12 Granted AllUsers unchecked None
Client IP Address 0.0.0.0 255.255.255.255 Forbidden AllUsers unchecked None
Specifying IP address ranges has been significantly improved over previous versions. In the current version you can input a range of IP addresses. The first IP address is a range of 3 IP addresses in the 192.168.5 subnet. The next is a single IP address. The last address is the full IP address range. Reading the above table as a whole, only addresses 192.168.5.5, ..6,..7 and 192.168.6.12 will have access to FreeProxy. All other IP addresses would be banned.
Example 3: Force the user to logon to the proxy service.
Create users as required who will have access to the internet.
Create a group called ProxyUsers, and add the users to the group.
In the port definition for the Internet proxy port:
Check 'Use HTTP authentication'
Select an appropriate method - Basic Digest or NTLM
Click Permissions
In the Port Defintion, select 'Use HTTP authentication', and select the Digest check box only, and fill in a Realm.
Code:
Resource Type Permission Group Must auth Calendar
HTTP Proxy Service Granted ProxyUsers Checked None
HTTP Proxy Service Forbidden AllUsers Unchecked None
The first resource allows users in the ProxyUsers group to access the service. However, they MUST logon first. Therefore, the 'Must authenticate' check box must be checked. If you don't check the check box, the browser will simply display 'Access denied'. The second resource permission traps all other users.
Example 4: Force the user to log on to the proxy service using windows authentication
It is not necessary to create users if you are using Windows authentication. A special group "WindowsUsers" consists of all users who have authenticated using their windows credentials.
In the port definition for the Internet proxy port:
Check "Use HTTP authentication"
Select NTLM as the method
Click Permissions
Code:
Resource Type Permission Group Must auth Calendar
HTTP Proxy Service Granted WindowsUsers Checked None
HTTP Proxy Service Forbidden AllUsers Unchecked None
The first resource allows users in the builtin group, "WindowsUsers" to access the service. However, they MUST logon first. Therefore, the "Must authenticate" check box must be checked. If you don't check the check box, the browser will simply display "Access denied".
As an aside, as soon as a session starts and before FreeProxy receives any user credentials, the user name of the session is "DefaultUser". With this in mind it checks the resource permissions. It scans them and lands in the "AllUsers" row. However, because the "Must Authenticate" is present, this overrides the forbidden and therefore challenges the user.
In the case of Windows authentication, the user is NOT challenged with a user/password dialog box. Internet Explorer will provide user credentials to FreeProxy from the logon information. You can see the result in the access log where the logged on user name is reported. If the credentials are not correct, FreeProxy will again challenge the client and then only will Internet Explorer present a dialog box to the user.
The second resource permission traps all other users.
Example 5: Allow all users access to some web sites, forbid all users seeing a set of web sites, and force users to logon to see anything else.
This example is more complicated. An application of this would be if you used a combination of clients which use the same port definition in FreeProxy. This can occur with using MSN and Internet Explorer and you decide to implement authentication. MSN actually ALWAYS requires the Internet proxy port even though you only select say SOCKS 4 as the MSN proxy. Unfortunately, MSN does not handle authentication challenges so you are faced with either not implementing authentication, or implementing authentication (as in the above 2 examples) and not being able to use MSN.
The solution is to defer authentication until certain URIs are requested.
In the port definition for the Internet proxy port:
Check "Use HTTP authentication"
Select an appropriate method - Basic Digest or NTLM
Click Permissions
Code:
Resource Type Resource Id Permission Group Must authenticate Calendar
URI or Path *loginnet.passport.com* Granted AllUsers Unchecked None
URI or Path games.real.com Granted AllUsers Unchecked None
URI or Path *icq* Forbidden AllUsers Unchecked None
URI or Path *notgood* Forbidden AllUsers Unchecked None
URI or Path * Granted ProxyUsers CHECKED ! None
URI or Path * Forbidden All Users Unchecked None
The first 2 URIs above specifically allow login to MSN and a games site to be visited
The next 2 forbidden URIs specifically forbid access to these sites
The fifth URI applies to everything else and the checked "Must authenticate" forces the user to authenticate before viewing the current web page.
The last URI traps any user that has not logged on.
To extend this example, list all the OK sites first, followed by the AllUsers denied list followed finally by the 2 lines which control logon
Example 5: Allow weekday workers access to certain sites and weekend workers access to other sites..
In FreeProxy create the following
A group consisting of users which have weekend only access. Call it WeekendGrp.
A group of users which are allowed access at other times. Call this group DailyGroup.
Create a group of users called SpeclGrp which will have more permissions than other users
A calendar called WeekendCal which are the available access times during the weekend.
Another calendar called DailyCal which contains the daily allowed access times for business day workers.
Code:
Resource Type Resource Id Permission Group Must auth Calendar
