4.4. Access rules

4.4.1. Access rules
4.4.2. Client checks

4.4.1. Access rules

An access rule defines a restriction, or under what circumstances a service or role should be granted.

An access rule may be thoroughly customized using boolean operators. The 'Access rule' interface provides a series of buttons for use when writing a rule (and, or, not, (, ), true and false). Using these buttons, one can for instance define a service which is only available to two specific clients connecting to one specific server, only during office hours or on holidays, and only to users authenticated with smart cards.

When access rules are saved, a sanity check is done on the expression. If the expression is not valid, the access rule will not be saved to the database, and a detailed error report will be shown to the administrator.

Access rules consist of the following types of statements:

Boolean operators and primitives

Boolean operators (and, or, not, ( and )) are used to group other checks together. The boolean primitives (true and false) can be used to create short access rules which are always true or false.

Attribute

Attributes are key/value pairs which are set from either the client machines or from an LDAP server, such as Microsoft Active Directory. An Attribute statement looks at the attribute value and matches it against another value. The match can be made as a regular expression match (=) or as normal relational operators (<, >, <=, >= or !=). The match is done numerically if both values are numbers (decimal numbers are accepted) otherwise string comparison is used.

This allows the AppGate server to restrict access based on information from outside the server. More information about regular expressions can be found at Section 11.11, “Regular Expressions Reference”.

Predefined attributes

A number of predefined attributes are set automatically when the user logs on. This includes information about the session, the client and other environment variables.

Table 4.1. Predefined attributes

Attribute nameDescription
ag_client_ipThe user's IP address as seen by the AppGate Server.
ag_client_nameThe user's fully qualified host name.
ag_server_ipThe IP address of the AppGate Server's incoming interface
ag_server_nameThe fully qualified host name of the AppGate Server's incoming interface.
ag_userdbThe name of the account souce that this user was found in.
client_prot_verThis version number is used in the protocol between the AppGate Client and Server. This attribute can be used to select different services depending on the version of the AppGate Client.
ag_client_typeWhat kind of client the user used when connecting to the AppGate Server. Possible values are "full", "connect", "applet", "ssl", "console", "generic ssh".
ag_client_is_webstart"true" if the client was started as an Java Web Start application, "false" otherwise.
ag_client_versionThis version is the "offical" version number of the connecting client. Values are "8.1", "7.1.5" etc
ag_client_lmhosts"true" if the client can write to the LMHOST file, "false" otherwise. On platforms other than Windows, this attribute is always "false".
ag_client_share_capable"true" if the client can use the share component, "false" otherwise. On platforms other than Windows, this attribute is not set.
identd"true" if the client is using an identd daemon, "false" otherwise
persfw"true" if the client is using AppGate's DFW, "false" otherwise
iptunneling"true" if the client is using AppGate's IP tunneling driver, "false" otherwise
platformA string with three parts: platform,os,id
usernameThe login name the user typed in or the distinguish name from a certificate
fwd_nameNormally the same as the "username" attribute, but it can be changed to facilitate Single Sign On.
search_nameThe user name found in the account source when this user logged in, this is normally the same as the "username" attribute.

Attributes from clients

The value of the attribute is set by the client by executing a 'client check' command at the start of the session. This may for instance be used to run a small program that checks whether an anti virus software is running on the client computer and restrict access based on this information. Another way to set attributes from the client is to use the gui_extraprompts configuration option. See the section called “User-provided credentials” for an example of this.

Attributes from LDAP/AD servers

When an LDAP user database is used, it is possible to map attributes in the LDAP database to attributes that the AppGate server can use (see Section 4.3.3, “LDAP/AD” for details). This can be used to , for instance, enable access to a Microsoft Exchange server only if the user has an e-mail address defined in Active Directory.

Time

Defines a time period. The choices are 'All days', 'Work days', and 'Weekends' (may specify times of day for any of these. For instance, "Work days 8.00-17.00" or "All days at any time".

From

This statement can be used to detect from where the client is connecting. It is expressed as an IP address, or as a whole range of addresses, or as a subnet or supernet. For instance, from{*.appgate.com} matches any user connecting from a client whose fully qualified host name ends with appgate.com. Another example; from{10.42.23.0/24} matches users whose clients are located on the 10.42.23.* subnet.

Platform

This statement is used to detect what platform the user is running. This statement should not be used for strong security, since it is possible to fake the platform reported by the client. However, it may well be used for presenting the relevant services on different platforms.

IP tunneling

This statement (really an Attribute statement) is used to detect that the client is using IP tunneling as its traffic capturing mechanism.

Firewall

This statement (really an Attribute statement) is used to detect that an AppGate Device Firewall is running on the client computer.

identd

This statement (really an Attribute statement) is used to verify that an identd daemon is answering on the connecting client computer. This is normally only interesting if the client is a Unix computer.

Authentication

Defines valid authentication methods for the services. Using this as part of an access rule, it is possible to restrict access to a service based on the authentication method used for the connection. The drop down box displays all the authentication methods that has been defined for the AppGate server.

It is possible to differ between different instances of radius authentication, if multiple radius authentication methods has been defined.

Crypto

Defines valid cryptography methods for the services. Using this as part of an access rule, it is possible to restrict access to a service based on the cryptography method used for the connection.

Access rule

This is a drop-down box containing all access rules that have already been defined. Using this option, access rules may be "nested" inside of other access rules to produce an easily customized rule.

For instance, nested rules are used when you want an access rule to encompass everything one rule does, plus additional restrictions.

There is no need to define a negating role, as there are "negate" buttons everywhere where access rules are used.

Server

Defines an AppGate server where this rule should evaluate to 'true'. This is only relevant in multi-machine AppGate clusters.

NOTE: If an access rule is defined using an expression which allows access only to a certain AppGate Server and load balancing is used, the access rule applies to the server one is actually connected to, but this is not always the same server the user tried to connect to. Therefore, it is not recommended to define this type of access rule while using load balancing.

Can clients be trusted?

The AppGate server cannot verify that the attributes set from the clients are accurate. It is, for instance, possible for a cunning hacker to tell the AppGate server that the client machine is using anti-virus software. Attributes from the clients should be used to select different services depending on the configuration of the machine, not to grant access to sensitive information.

Examples

An access rule called secure_from_internet which gives 'true' if the connection comes from a host outside of the company network and uses a certificate for authentication.

          (not from(*.appgate.com)) and auth(certificate)
        

An access rule called secure_from_intranet which is true if the connection comes from a host on the company network and the user uses a certificate or password for authentication.

          from(*.appgate.com) and (auth(certificate) or auth(password))
        

These two rules can be used as building blocks to create another access rule called secure_connection.

          secure_from_intranet or secure_from_internet
        

4.4.2. Client checks

The 'Client Check Setup' section of the console allows the administrator to upload and define Client Check Commands.

Client Check Commands are commands which are run on the client machine when the client connects to an AppGate server. The output from these commands is used to set attributes which can be used in Access rules. The commands are stored on the AppGate server and downloaded to the client machine (if they have not already been downloaded when connecting at an earlier time).

The command may be any form of file that may be executed on the designated client platform (e.g a native Win32 binary for Windows, a .bat file for Windows or a Bourne-shell script for Unix). It must return exit code zero if the attribute should be set. The attribute is then set to the last line of output on stdout.

To upload a new command executable, click on the 'Upload...' button and select the file that should be uploaded. By default, the AppGate server has the executable called check.exe already uploaded and ready for use.

To add a new Client Check Command, click on the 'Add...' button and specify which attribute that should be set, which platform the Client Check Command applies to, which executable will be run, and which arguments will be given to the executable.

To edit an existing Client Check Command, either double-click on the Client Check Command or select one from the list and click on the 'Edit...' button.

To remove an existing Client Check Command, select one from the list and click on the 'Delete' button.

Binary commands that have not been assigned an attribute are listed without an attribute and can not be edited, but they can be deleted by selecting them and clicking on the 'Delete' button.

check.exe

A program called check.exe is pre-installed on every AppGate server. It can perform a great number of checks on a Windows client machine, such as reading a registry entry, see if a certain program is running or calculate a checksum of a file.

Because check.exe is such a versatile program, it has a lot of options:

 -fileexists file
 -filesizeis file size
 -filesizelarger file size
 -filesizesmaller file size
 -fileversion file
 -productversion file
 -md5sum file
 -sha1sum file
 -regexists root key value
 -regprint root key value
 -getprivateprofilestring appname key def file 
 -fsecureavversion print | max age in days 
 -sophosmaxage rtime
  where rtime is of the form nn['d'|'h'|'m']
 -process name
 -exec command...
 -isadmin
 -issvcrunning name
 -querysvc name
 -isportbusy port
 -matchoutput command needle1...
 -isnetbtenabled
 -canmountagshares
 -isunitmounted driveletter
 -downloadto url [-hash hash] file
  hash is of the form {md5,sha1}:XXXXX...
 -downloadandrun url [hash]
  hash is of the form {md5,sha1}:XXXXX...
 -downloadandrunasarg url [-hash hash] cmd
  hash is of the form {md5,sha1}:XXXXX...
  cmd may contain #f which will be expanded to the file name
  of the downloaded copy of the file to which the url points.
 -downloadanddo url op [hash]
  where op is one of: edit, explore, find, open or print
  and hash is of the form {md5,sha1}:XXXXX...
 -afiledateis file date
 -afiledatenewer file date
 -afiledateolder file date
  where date is of the form yyyymmdd[hh[mm[ss]]].
 -rfiledatenewer file rtime
 -rfiledateolder file rtime
  where rtime is of the form nn['d'|'h'|'m']
          

Here are some examples of check.exe commands:

 -fileexists %windir%/notepad.exe
 -regexists HKEY_LOCAL_MACHINE "Software/Microsoft/Internet Explorer" Build
 -regprint HKLM "Software/Microsoft/Internet Explorer" Build
 -process mstask.exe
 -afiledateis c:/windows/notepad.exe 20040401
 -afiledatenewer c:/windows/notepad.exe 200404012359
 -afiledateolder %windir%/notepad.exe 20040401235959
 -rfiledatenewer c:/windows/notepad.exe 10d
 -rfiledateolder #REG[HKLM,Software/ACME Software,SomeValue] 10h