
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,
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.
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”.
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 name | Description |
|---|---|
| ag_client_ip | The user's IP address as seen by the AppGate Server. |
| ag_client_name | The user's fully qualified host name. |
| ag_server_ip | The IP address of the AppGate Server's incoming interface |
| ag_server_name | The fully qualified host name of the AppGate Server's incoming interface. |
| ag_userdb | The name of the account souce that this user was found in. |
| client_prot_ver | This 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_type | What 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_version | This 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 |
| platform | A string with three parts: platform,os,id |
| username | The login name the user typed in or the distinguish name from a certificate |
| fwd_name | Normally the same as the "username" attribute, but it can be changed to facilitate Single Sign On. |
| search_name | The user name found in the account source when this user logged in, this is normally the same as the "username" attribute. |
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.
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.
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".
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.
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.
This statement (really an Attribute statement) is used to detect that the client is using IP tunneling as its traffic capturing mechanism.
This statement (really an Attribute statement) is used to detect that an AppGate Device Firewall is running on the client computer.
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.
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.
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.
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.
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.
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.
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
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.
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:
-fileexistsfile-filesizeisfilesize-filesizelargerfilesize-filesizesmallerfilesize-fileversionfile-productversionfile-md5sumfile-sha1sumfile-regexistsrootkeyvalue-regprintrootkeyvalue-getprivateprofilestringappnamekeydeffile-fsecureavversion print |max age in days-sophosmaxagertimewherertimeis of the form nn['d'|'h'|'m'] -processname-execcommand...-isadmin -issvcrunningname-querysvcname-isportbusyport-matchoutputcommandneedle1...-isnetbtenabled -canmountagshares -isunitmounteddriveletter-downloadtourl[-hashhash]filehashis of the form {md5,sha1}:XXXXX... -downloadandrunurl[hash]hashis of the form {md5,sha1}:XXXXX... -downloadandrunasargurl[-hashhash]cmdhashis of the form {md5,sha1}:XXXXX...cmdmay contain #f which will be expanded to the file name of the downloaded copy of the file to which the url points. -downloadanddourlop[hash] whereopis one of: edit, explore, find, open or print andhashis of the form {md5,sha1}:XXXXX... -afiledateisfiledate-afiledatenewerfiledate-afiledateolderfiledatewheredateis of the form yyyymmdd[hh[mm[ss]]]. -rfiledatenewerfilertime-rfiledateolderfilertimewherertimeis 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