The E-Class SRA appliance records system and user events in a series of log files. You can view the log files in AMC, or by sending the messages to an external syslog server—this process is described in System Logging and Monitoring on page 276. This section explains how to manually review log files from the command-line interface on the appliance itself and interpret the data.
: •: File Locations on page 729
: •: System Message Log on page 730
: •: Network Tunnel Audit Log on page 736
: •: Web Proxy Audit Log on page 740
: •: Management Console Audit Log on page 742
: •: WorkPlace Logs on page 742
The following table lists the names of the log files on the appliance, which are initially stored locally (/var/log/aventail/).
|
To minimize storage requirements for log files, the appliance rotates the files. The log rotation procedures vary, depending on the frequency you specify:
|
Log files of more than one day old are stored in uncompressed format. The log file names contain a suffix that is numbered sequentially from 1 through 7, so that if the log rotation occurs daily, a log file with the suffix 7 is one week old. For example:
: •: extraweb_access.log is the current log file for Web proxy service.
: •: extraweb_access.log1 through extraweb_access.log.7 are the logs from the previous rotations.
The system message log (/var/log/aventail/access_servers.log) is generated in syslog format (see RFC 3164) and contains message logs for the Web proxy service, the network tunnel service, and the policy server (an internal service that controls policy for the other services). It also provides detailed messages about all access control decisions: each time a user request matches a policy rule, a log file entry is recorded explaining the action taken.
This sample message log entry is followed by descriptions of its elements:
[08/Nov/2009:07:16:24.312477 +0000] E-Class SRASSLVPN 002764 up 00000001 Info System CFG Pool Init STATIC/NAT id=1 name='HQ-pool2' gid='AV1160554493976A' ndns=2 nwins=2 nsuffix=0
| ||||||||||||||||||||||||||||||||||
: •: Auditing Access Policy Decisions on page 732
: •: Viewing Client Certificate Errors in the Log on page 733
: •: End Point Control Interrogation on page 734
: •: Unregistered Device Log Messages on page 735
Auditing Access Policy Decisions
One of the main uses for the system message log is to audit access policy decisions. Each time a user request matches a policy rule, the appliance writes an entry to the message text field (the last field in the message log) explaining the action taken.
A sample message for an access policy decision looks like this:
[09/Nov/2009:02:45:32.282637 +0000] E-Class SRASSLVPN 002421 ps 100004b3 Info EWACL User '(192.168.136.70 (Dominique Daba)@(Students)' connecting from '192.168.136.70:37975' matched rule 'accessRule(AV1091719670706:preauth access rule)', access to '127.0.0.1:455' is permitted.
For each connection request that matches a rule, a log message is generated at the Info level. Requests that don’t match a rule are logged at the Verbose level, and when no rule match is found the request is logged at the Warning level.
For policy decisions, the logging message text field (everything after Info in the previous example) includes the following information:
| ||||||||||||||||||||||||
If no rule matched, an Info level message is generated indicating that no matching rule was found.
This section includes examples of log messages auditing access control.
Example 1—Success at Info Level
[09/Nov/2009:02:45:32.712860 +0000] E-Class SRASSLVPN 002421 ps 10000531 Info Session Authentication for user '(192.168.136.70 (Guest))@(Students)' SUCCESS for realm 'Visitors'
Example 2—Failure at Info Level
[09/Nov/2009:04:27:40.965127 +0000] E-Class SRASSLVPN 002873 ps 00000003 Info WPACL User '(kevin figment)@(Students)' connecting from '192.168.136.70:0' found no matching access rule, access to 'www.seattletimes.com:80' is denied.
Viewing Client Certificate Errors in the Log
If the appliance is unable to verify a certificate chain, a message such as this one appears in the system message log file:
[09/Nov/2009:21:28:14.610949 +0000] E-Class SRASSLVPN 001539 ps 10000042 Info System Auth: CRL-CERT: Cert verification status = 0, err = 20 'unable to get local issuer certificate'
This message includes an error code (in this case “20”) reporting why the certificate check failed. These error codes are described in the following table:
|
End Point Control Interrogation
The system message log captures information during client EPC interrogation when the log level is set to verbose. The appliance checks for the presence of certain device profile attributes on the client, and the log file records the query and the results.
In the following example, EPC is checking for a certain antivirus application (Symantec Client Security, version 9.x or later). When the application is not found, this particular device is relegated to the Default zone:
[04/Oct/2009:22:29:23.867093 +0000] E-Class SRASSLVPN 027186 uk 00000001 Verbose System ::API::QAABA145dFYNZimCKNWHB7p2q2Y=::(timwillis)@(Students)::CLIENT:: Interrogation: Evaluation of OPSWATAV AV1128462569762A [NortonAV.dll,Symantec Corp.,Symantec Client Security,>=,9.x,,,,,FALSE] results: FALSE
04/Oct/2009:22:29:23.875781 +0000] E-Class SRASSLVPN 027186 uk 00000001 Verbose System ::API::QAABA145dFYNZimCKNWHB7p2q2Y=::(timwillis)@(Students):: Classified into zone: Default zone
Unregistered Device Log Messages
Unregistered device log messages provide device IDs from login attempts by users on devices that are not registered. The AMC provides a way to export the unregistered device log messages in XML format. On the Logging page, select Unregistered device log from the Log file drop-down list and then click Export. You can reduce the size of the exported file by first applying filter or search criteria.
You can also access and export the list of unregistered devices to an XML format on another system. The list can be accessed directly in a Web browser using the following URL:
https://(internal IP address)/UnregisteredDevices.xml
This URL requires BASIC HTTP authentication, and the credentials must be an AMC user with at least "View" access to the Monitoring category.
A curl or wget command can be used to obtain the list programmatically from the external machine. The syntax for the curl command is as follows:
curl -k3u (user):(password) https://(internal IP):8443/UnregisteredDevices.xml
The syntax for the wget command is as follows:
wget --no-check-certificate --http-user=(user) --http-password=(password) https://(internal IP address):8443/UnregisteredDevices.xml
Both of the above commands turn off SSL certificate checking, which is useful when using a self-signed certificate.
A full definition of the URL used to fetch the XML version of the unregistered device report is provided below:
<!--
HTTP GET command line usage
URL:
https://<internal address>:8443/UnregisteredDevices.xml?parameter=value¶meter=value
Authentication:
BASIC HTTP authentication, credentials must be AMC user with at least view access to the : Monitoring category.
Parameters (all optional):
username - string, case insensitive, default * (all users)
Search for login attempts from users that contain this value as part of their username.
: Example: username=li will return entries for Linda and Melinda
realm - string, case insensitive, default * (all realms)
Search for login attempts to Realms that contain this value as part of the Realm name.
: Example: realm=Corp will return entries for Corporate and Non-Corporate
platform - string, enumerated values below
Search for login attempt from devices running only the specified platform:
all - all platforms (default)
windows - only Windows devices (XP, Vista, etc)
mac - only Mac devices
linux - only Linux devices
activeSyncMobile - only Exchange ActiveSync devices
mobilePhone - only Mobile Phone devices
pda - only PDA devices
unknown - only devices on which the platform could not be determined
exported - string, enumerated values below
Search for entries that have or have not already been exported either in
AMC or via an HTTP get command.
all - all entries, whether or not they have been exported (default)
exported - only entries that have already been exported
unexported - only entries that have not already been exported
limit - number, default 1000
Limit the search to this many entries.
deviceCount - number, 0-3, default all entries
Search for users with only the specified number of devices already registered in the external : AD/LDAP store.
0 - user has no devices registered
1 - user has one device registered
2 - user has two devices registered
3 - user has three or more devices registered
lastLoginTime - string, enumerated values below, default all
Search for user login attempts that happened only in the time period specified, relative to the : current time.
all - all login attempts
hour - attempts in the last hour
day - attempts in the last day (24 hour period)
week - attempts in the last week (7 days)
-->
The network tunnel audit log provides detailed information about connection activity, including the status of completed tunnel connections and the status of completed flows within tunnels.
Note: The two record types can be distinguished by the word "flow" or "tunnel" appearing in the sixth field of the message.
Messages are stored on disk in the file /var/log/aventail/extranet_access.log and contain the following parameters:
[source-ip:port] [authentication] "[username@realm]" "[date/time]" [version] [command] [destination-ip:port] [status code] [bytes-received] [bytes-sent] [connection duration] [imei]
The following example illustrates a network tunnel service audit log file entry:
12.230.158.210:1110 ssl:LDAP "fred figment" "13/Sep/2009:19:18:28 -0700" v1.1 flow:tcp 192.168.136.254:22 0 21722 60631 263 490236207159217
The log entries contain the following fields (separated by spaces):
|
\Auditing Connection Status Messages
The network proxy/tunnel audit log includes a connection status code that is often useful in debugging client/server connection problems. The status code is the field immediately following the destination-ip:port field in the log file (see Network Tunnel Audit Log on page 736 for a description of an entire log file entry).
The following table describes each code.
|
:
Examples
If a user enters an invalid username/password, error number 65535 appears in the log:
192.168.2.69:3127 ssl "testing" "26/Feb/2009:21:31:51.947 +0000" none -:- 65535 385 0 14 352711-01-521146-5
If a timeout occurred, the message contains error number 65426:
192.168.2.69:3127 ssl "testing" "26/Feb/2009:21:31:51.947 +0000" none -:- 65426 385 0 1 352711-01-521146-5
All tunnel traffic originating from the client and destined for the Internet (running in “redirect all” mode) is routed through an IP address you specify on the Configure Network Tunnel Service page in AMC (Enable route to Internet). If this route to the Internet is not available, you’ll see a connection status code of 65504:
151.219.76.85:4827 - "(l248411)@(Radius)" "26/Jun/2009:17:54:14.916 +0000" 1.1 Flow:TCP 165.170.0.1:1503 65504 0 0 60 352711-01-521146-5
The Web proxy audit log provides detailed information about connection activity, including a list of users accessing your network and the amount of data transferred.
The /var/log/aventail/extraweb_access.log file messages are stored in the World Wide Web Consortium (W3C) Common Log Format (CLF). See http://httpd.apache.org/docs/logs.html for more information on CLF logs. The log message has the following parameters:
[source-ip] [identity] [shortname@realm] [longname] [date/time] "[request]" [HTTP return code] [bytes-sent] [imei]
The following is a sample network proxy/tunnel service audit log file entry:
192.168.200.162 - (extranetuser)@(Translation) (uid=extranetuser,ou=Users,dc=indigo,dc=com) [31/Mar/2009:09:08:09 -0700] "GET http:/ /127.0.0.1:455/postauth/interrogator/AventailComponents.exe HTTP/1.1" 200 536016 "-"
The log entries contain the following fields (separated by spaces):
|
Examples
: •: If an authentication attempt fails—for example, because the user enters an invalid username or password—a single message appears in the log with a return code of 200 (“OK”), indicating the client request was understood). Notice that the source IP address in the message is the only way for you to identify who made the request:
192.168.2.69 - - [26/Feb/2009:21:43:30 +0000] "POST /__extraweb__authen HTTP/1.1" 200 3610 352711-01-521146-5
For a successful authentication, a similar message appears, but with a return code of 302 (“Found”). It is immediately followed by another message that contains the user's authentication credentials and a return code of 200:
192.168.2.69 - - [26/Feb/2009:21:44:25 +0000] "POST /__extraweb__authen HTTP/1.1" 302 206 352711-01-521146-5
192.168.2.69 - (jsmith)@(AD) [26/Feb/2009:21:44:25 +0000] "GET /workplace/access/home HTTP/1.1" 200 15424
: •: If a user successfully authenticates, but is denied access to a Web resource by an access rule, a message containing a return code of 403 (“Forbidden”) is logged:
192.168.2.69 - (jsmith)@(AD) [26/Feb/2009:21:52:25 +0000] "GET /dukes HTTP/1.1" 403 3358 352711-01-521146-5
: •: If a user successfully authenticates and is permitted to access a URL, a message appears that is identical to the one for a failed authentication (a return code of 200), except that this one includes the user’s credentials:
192.168.2.69 - (jdoe)@(AD) [26/Feb/2009:21:51:03 +0000] "GET /dukes HTTP/1.1" 200 262 352711-01-521146-5
An individual with administrative privileges can view a history of configuration changes that were made to the appliance by reviewing the AMC audit log. This log provides an audit history of configuration changes made in AMC by administrators. Follow the steps in Management Audit Log on page 283 to view the log (/var/log/aventail/policy_audit.log) in AMC.
An additional AMC-related log file in syslog format (/var/log/aventail/management.log) is also available.
The Aventail WorkPlace log (/var/log/aventail/workplace.log) is useful for troubleshooting access to file shares using Network Explorer, and also answering questions about what Web and network shortcuts are shown on the WorkPlace portal page. Accessing file resources is also logged to the Web proxy service log (extraweb_access.log).
: •: WorkPlace Shortcut Examples on page 742
When a user logs in to Workplace and successfully sees shortcuts, the log file entries looks like this:
1. The username credentials are logged with a session ID (when troubleshooting, just look for the username):
Feb 26 22:03:03 127.0.0.1/127.0.0.1 local7.debug DEBUG [22:03:03,612] GOT: CredentialsManager[teamSessionId=+kMs+1fJYyVOxJ8f/YO0gg==,teamcredentials={username=jdoe} ,credentials={}]
2. Later you see a message indicating a successful load of the shortcut (in this case a Web shortcut):
Feb 26 22:03:03 127.0.0.1/127.0.0.1 local7.debug DEBUG [22:03:03,615] pcsession: <authorize:exit> uri=http://wemmet.internal.net status=SUCCESS
3. The successful load of a network shortcut looks like this:
Feb 26 22:03:03 127.0.0.1/127.0.0.1 local7.debug DEBUG [22:03:03,617] pcsession: <authorize:exit> uri=smb://marshare01/marketing status=SUCCESS
If a user does not see shortcuts (because of an access rule you have set up, for example), the denial of access looks like this:
1. Look for the username at login:
Feb 26 22:12:15 127.0.0.1/127.0.0.1 local7.debug DEBUG [22:12:15,027] GOT: CredentialsManager[teamSessionId=hZ98BEZxdyARJCtjkGl3lA==,teamcredentials={username=dsmith} ,credentials={}]
2. Look for the shortcut information that is failing to load on the user's WorkPlace portal page. This is an example of a Web shortcut failure:
Feb 26 22:12:15 127.0.0.1/127.0.0.1 local7.debug DEBUG [22:12:15,043] pcsession: <authorize:exit> uri=http://wemmet.internal.net status=FAILURE
Notes
: •: Access (permit/deny) to a resource share is also logged in extaweb_access.log:
192.168.2.69 - (jdoe)@(AD) [26/Feb/2009:22:19:21 +0000] "GET /workplace/access/exec/file/view?path=smb://marshare01/marketing/reports.doc/ HTTP/1.1" 200 4608
: •: An additional WorkPlace-related log file in syslog format (/var/log/aventail/wp_init.log) is also available.