Resource Security

Overview

There are two components to resource security viz. Resource Permissions and Authentication.

Resources

From version 3.5, FreeProxy/FreeWeb has the ability to apply resource security to many of the resources utilised by the user. Among those items considered a 'resource' are, a service, an IP address, a port, a path or a URL. For example, the 'FreeProxy HTTP Proxy Service' is considered a resource as is the user's client IP address. You can control who can or cannot use the resource. The ability to limit access to specific URLs still exists in this version however this is now done with resource security and the range of features has been considerably extended. 

Authentication

Most resources can be secured by requiring the user log on before access will be granted. Some permissions, such as IP address filtering does not apply to specific users. Authentication means 'making sure that the user is who they say they are and are registered in the company register as  a known user'. Typically this is done using a userid and password.

FreeProxy allows you to authenticate either to the Windows domain (requiring a domain controller) or independently by only authenticating to FreeProxy's own database. Authentication methods are:

• Basic authentication

• Digest authentication

• NTLM authentication

Note: authentication is separate from encryption. HTTP does not specify any encryption methods. 

Once a user has been authenticated, FreeProxy will check whether the user has been granted permission to access the resource being requested. If Windows Authentication is used, the FreeProxy password will not be checked. Built-in groups make the task a lot easier.

Default User Group

Before authentication takes place, each new connection is assigned to the Default user group. Unless you specify Resource permissions, the default user, which is a member of the default group (the 'AllUsers' built-in group) can access all resources. Once the user has been authenticated, the connection then assumes the new user id.

Windows User Group

Any user which authenticates against a Windows domain, is automatically placed into the 'WindowsUsers' built-in group. You can assign this group to any resource so that when a user authenticates with the Windows domain, they have access to the resource.

Using Windows Domain Authentication

Prerequisites for Windows domain authentication to work correctly are:

• The server running FreeProxy MUST be logged into the domain that the users can authenticate against. 
• Under Windows 98, you need to enable NTLM security services: Control Panel è Network è Access Control è select User-level access control, specifying the Windows domain name. When you change this setting, Windows will want to re-boot.

HTTP Authentication Methods

You can select the authentication methods you want to use. If you are not sure, then select them all and FreeProxy will negotiate the 'best'. The 'best' may not be the most secure and is up to the client to select one from the list. The select method may be the only one available to the client. Also read the the following details on the method before making a selection.

Basic Authentication

Basic authentication as defined in RFC2617 is observed by almost all browsers and internet aware clients. It is a simple method and easy to implement. The major drawback is that the user id and password are passed in the HTTP messages using 'clear text' after being encoded (not encrypted)(§). Although you cannot read the password by simply looking at the message, it can easily be decoded using the right tool by anyone intent on breaking into the message. Basic is ideal for households or intranet access where the possibility of anyone being able to monitor the traffic between the browser and the proxy is remote or unlikely, or, the userid and password are generally known within the community. Messages are processed quickly with this method. FreeProxy can authenticate to either the Window Domain, or to FreeProxy's own User database. 

(§) Encoding the userid and password means that they are translated into a different character set. They can be translated back just as easily. Encoding ensures that messages use a character set that is consistent with the HTTP specification. Encryption is translating the userid and password into a character string that can only be converted back to its original form if you have the appropriate encryption key. This would be done to prevent anyone from viewing the data being encoded. 

Digest Authentication

Basic authentication as defined in RFC2617 is observed by some browsers (for example Internet Explorer) and some internet aware clients. It is more secure than Basic as it does not send the password in the message but rather a 'digest' or mathematical hash of the password using standard hashing algorithms. In addition, other information is encoded into the message to prevent other well-known security risks such as 'replay' attacks, 'man-in-the-middle' attacks etc. It would be extremely difficult for anyone to masquerade or derive the password from the message. A determined user with a super-computer and lots of time would have difficulty. Digest Authentication has only been implemented on the FreeProxy user database. If you wish to implement a digest-like authentication method using Windows authentication, use NTLM.

NTLM Authentication

NTLM is a Microsoft proprietary authentication method and therefore requires a Windows NT/2000/2003 domain controller to service requests as the authentication 'authority'. 

Summary

Users, Groups, Domains and Realms

SOCKS 5 Authentication Methods

SOCKS 5 has numerous ways of authenticating. FreeProxy offers Username/password, no authentication or authentication to the Windows domain.

UserName/Password

This is a simple clear text userid and password message sent to FreeProxy by the client. They are authenticated against the FreeProxy user database.

No Authentication

You can make authentication optional by leaving the 'Must Authenticate' check box unchecked when setting up a SOCKS 5 port. If an authentication message is received, the userid and password will be authenticated. With the check box unchecked, the client can optionally not send the user id and password to FreeProxy and still gain access. With the check box checked, FreeProxy will expect a userid and password.

Windows Authentication

If windows authentication has been selected (in the Options dialog box of the FreeProxy Control Centre) then the username and password will be authenticated against the Domain controller. 

Resource Permissions

Protection Spaces

Resources fall into 2 main protection spaces, ie Port definitions and IP Service definitions. When you define a particular instance of a Port or Service, you create a protection space instance, in which you can define protection for individual resources in that space. For example, if you create a Port definition with the name 'Internet' and 'HTTP Proxy', you can specify resource security for 'The HTTP Proxy Service', 'Client IP Addresses, URL, and Server IP address. 

Access Permissions

Access can be 'Forbidden' or 'Granted'. If you do not specify access to a resource, FreeProxy will assume that access to the resource is permitted for all users. Using this, you need only specify those resources which are specifically forbidden. Access is granted/forbidden in the order presented.

For example:

        Grant            *.GOODURL.*

        Forbid           *.GOODURL.*

Access to www.GOODURL.com will always be granted as this permission was encountered first.

To only allow access to specific URLs, they would have to be listed.

        Forbid       *.OurCompany3.com*

        Grant        *.OurCompany?.com*

        Forbid       *

This sequence forbids access to 'www.OurCompany3.com', allows access to any other URL containing OurCompany?.com ( www.Ourcompany.com, int.de3.OurCompany4.com, etc) and forbids access to ALL other URLs. The "Forbid *' is really important to ensure that all other URLs are not accessed. Without the Forbid *, access would be granted to all URLs except "OurCompany3.com".

Conditioning Permission with a time constraint

As from V3.8 you can attach a calendar to a resource permission. Doing so you can specify when the resource permission is effective.

For example:

Grant    *.GOODURL.*    Calendar: Daily, Users: DailyUsers

Grant    *.GOODURL.*    Calendar: Weekend, Users: WeekendUsers

Forbid    *

In the above example, assuming that the Daily calendar specifies Monday to Friday access and the Weekend calendar specifies weekend access, then Daily Users will only have access to one URL during the week and weekend users to the same URL but only on weekends.

Resource permissions must be specifically granted

Has been removed from this version although the field is still displayed. In future versions it will be removed.

User must authenticate to gain access to this resource

The presence of an authentication method or a resource permission does not result in a request to the client to authenticate the user. If you do not check this check button, all authentication will occur using the currently defined user; and it is not necessary or desirable to check this for all resource permissions. For example a user accessing a proxy. You will check this to force the user to authenticate when accessing the 'HTTP Proxy Service'. This will request authentication from the client. Once the client has been authenticated, then all other permissions for the 'HTTP Proxy Service' will be based on the User id obtained during this authentication. So if you additionally have placed permissions on specific URLs, FreeProxy will check whether access is permitted using the User id it already has. If access is denied, FreeProxy will reply with a 'Forbidden' reply. If you check the 'User must authenticate to gain access to this resource' check box, FreeProxy will continue challenging the client for a User Id and Password until a valid one has been entered.

On some occasions, delaying a logon until a protected resource is accessed, is preferable. For example, if you trust all local intranet users you can use local binding to ensure that only internal users access the proxy. For those more sensitive URLs, you can specify resource permissions and check the 'User must authenticate to gain access to this resource' check box. In most cases no authentication will take place unless the user accesses the sensitive URL. When this happens, the user is asked to log on.

Obtaining the User id and password

User id or User Name and password are obtained from the client. It is typical for browsers like Internet Explorer or Netscape Navigator to present a dialog box to the user. The browser (or other client) will format an HTTP message and send it to FreeProxy in the appropriate form. It is possible that the Browser and FreeProxy will negotiate the appropriate authentication method if you have specified more than one method.

Depending on the browser and the authentication method selected, it may attempt to send FreeProxy the logon user and password before presenting the user with a dialog box. If this is the case the user will not be aware that authentication is taking place. For example, using Internet Explorer and NTLM authentication with a HTTP proxy, the user will not be presented with a dialog box unless the logon user and password are not correct, or the user id is not specified in the FreeProxy User Database. Evidence of authentication having taken place can be found in the access reports.  See here for more about access reports.

Resources Types

The following resource types can be specified for each instance of a Port or Service definition, depending on the Protocol or Service you have selected.

Client/Server IP Filter

The address range used by the client or the IP address the proxy connects to. The IP address is entered as 4 'octets' or numbers in the range 0 to 255. An IP Address is considered as a number where 192.168.100.5 is greater than 191.168.100.5. The range 192.168.25.2 to 192.168.25.3 are 2 IP addresses. 192.168.25.2 to 192.168.27.2 is the range of all IP addresses (192.168.25.2 to 192.168.25.255) and (192.168.26.0 to 192.168.26.255) and 192.168.27.0 and 192.168.27.1 and  192.168.27.2

URL Filter

Search arguments

Search arguments can contain wild cards.

#: Any single digit

&: Any single alpha character (a-z or A-Z)

?: Any single character

*: Any number of characters (any character)

^: Compare using the next character. eg ^# will look for a '#' in the URL and not a single alpha character. ^^ will look for a single ^

Path and Filename Filter

This works on the path and filename part of the URL only. In the URL below

https://web01.portal.au.mmi.com/forms/login.fcc?TYPE=33554433&REALMOID=06-0005104d-298d-1ea9-ad84-80c32ddf0000&GUID=&

In the above URL, the highlighted section is the path and filename.

The search parameters and method are the same as for the URL filter above.

For example a filter like

*.exe, Forbid

would forbid any file with a .exe file name extension.

Port Number

The ability to limit port numbers applies only to those functions where control over the port number is with external systems. For example, the connection to an HTTPS server is normally assigned to port 443 by the browser whereas the selection of port numbers to connect to your SMTP server is defined in FreeProxy; and therefore you can control this. If you did want to forbid access to HTTPS, for example, you can forbid port 443 as the HTTP Tunnel port. A port number is in the range 1 to 65535. The first 1023 port numbers are reserved for well-known services.

User Id/IP Address Affinity

In circumstances where you only want a user to use only one IP address, then this permission can be attached to a port. It works like this.

1. It only applies to users who have authenticated. Does not work with the Default user.

2. Once the user has authenticated, his/her IP address is recorded.

3. The next time the user uses FreeProxy, a check is made that the same IP address is being used. If not, the connection is closed.

4. If the validity period has expired, then the user is allowed access.

For example, you select 'User Id/Address Affinity' for HTTP Proxy. When the user 'George' uses the proxy, 'George' is entered into the table with the IP address and the time this person first accessed the system. If the validity period is 10 hours, and the time of logging on is 10am, then the 'George' user will only be able to access the proxy from a different IP address after 8pm.