Republished with permission from WatchGuard Technologies, Inc.

WatchGuard


Logs offer clues to what users do

By David M. Piscitello, President, Core Competence

I rarely miss an opportunity to emphasize how useful logging and log event analysis can be to security administrators. The most obvious use of log records is to reveal malicious activities, but administrators can also use logging for lots of other management tasks. Log messages can help you isolate configuration errors. When combined with firewall testing (auditing), logs also help confirm that the security policy configured at the firewall matches the security policy you intended to enforce.

But perhaps the most powerful use of logging is user activity monitoring. In fact, if your organization now must comply with external policy from new regulations or from government agencies, you might discover that monitoring user activity is no longer optional -- it's mandatory. This article outlines how you implement user-level monitoring using your Firebox.

The devil in the details

Monitoring user activity adds a level of detail beyond monitoring network activity, by associating events to authenticated users. To implement user level monitoring, you must first decide whether all authenticated users will be subject to the same acceptable use policy (AUP) or whether different policies will apply to different users, based on the user's role in the organization. To illustrate the difference between network-level monitoring and user-level monitoring, imagine that fictitious company Kunstler & Sons Musical Instruments decides that employees should not use the company network to access sexually explicit material. Dustin, the network administrator, implements this policy by defining an HTTP proxy policy, and configuring a WebBlocker policy to block content categories (e.g., gross depictions, full nudity, sexual acts) from every host attached to the Trusted network.

In this scenario, any attempt to access material that WebBlocker recognizes as sexually explicit would be blocked. The log record would look something like this:

12-05 10:33:01 Deny 192.168.1.3 216.163.137.3 http/tcp 63675 80 1-Trusted 0-External/PPPoE ProxyDeny: HTTP Request categories (HTTP-proxy-06) src_ip_nat="206.74.215.144" src_port_nat="26499" proxy_act="HTTP-at-K&S" cats="nudity-full,sex-graphic,gross" op="GET" dstname="www.playboy.com" arg="/"

While this configuration effectively blocks objectionable material everywhere on the Trusted network, these log records do not irrefutably identify the individual attempting to visit objectionable sites. But if Kunstler & Sons implements user authentication, such attempts could be traced to a specific account.

Whodunnit?

Users and user groups are created via the Authentication Servers dialog box of the WSM 8.x Firebox System Manager. Administrators can choose to use a Firebox Internal Database for group and account management, or an external authentication server (e.g., RADIUS or Active Directory).

Once user authentication is in place, you can implement access controls (firewall policies) to permit and prohibit activities by specifying users and groups rather than IP addresses, IP address ranges, or IP networks in the From: and To: fields of any policy property dialog box.

The implementation of a user-based access control is thus accomplished by:

  1. Implementing user authentication
  2. Defining an HTTP proxy policy, and
  3. Configuring a WebBlocker policy to block content categories (e.g., gross depictions, full nudity, sexual acts).

In this scenario, any attempt to access material that WebBlocker recognizes as sexually explicit would still be blocked. But the log record would look something like this:

12-05 13:11:58 Deny 192.168.1.3 216.163.137.3 http/tcp 63857 80 1-Trusted 0-External/PPPoE ProxyDeny: HTTP Request categories (HTTP-proxy-06) src_ip_nat="206.74.215.144" src_port_nat="26631" proxy_act="HTTP-at-K&S" cats="nudity-full,sex-graphic,gross" op="GET" dstname="www.playboy.com" arg="/" src_user="taylor@Firebox-DB"

The organization can now hold Taylor accountable for her actions, since only Taylor should be able to authenticate to the firewall using her credentials.

Different strokes for different folks

Suppose, however, that Kunstler & Sons somehow becomes an antispyware software developer. Some employees have the necessary albeit distasteful task of exploring lurid and offensive corners of the Web to ferret out sites that host spyware, and thus obtain sample installer packages they can analyze. In this situation, one Acceptable Use Policy is clearly insufficient. Two policies are required: one that prevents users at large from accessing sexually explicit material; and one that authorizes members of the spyware research team to access such material.

To provide the role-based access needed in this scenario, Kunstler & Sons could configure two user groups (e.g., spyware-researchers and users-at-large ). In the following example, Kunstler & Sons has created the two user groups, and now configures two HTTP proxy policies: one that allows members of the spyware-researchers group unfettered access, and one that prevents members of the users-at-large group from accessing sexually explicit material. With such policies in place, a member "dave" of the group spyware-researchers can access Playboy.com while any member of the group users-at-large will still be prohibited from doing so. The log record in this case would probably resemble this:

12-05 12:51:28 Allow 192.168.1.3 64.154.80.132 http/tcp 63824 80 1-Trusted 0-External/PPPoE allowed, mss not exceeding 1440, idle timeout=43205 sec 48 127 (HTTP-10) src_ip_nat="206.74.215.144" src_port_nat="24315" src_user="dave@Firebox-DB"

Notice that, in my example, Dave has succeeded in accessing Playboy.com (IP 64.154.80.132) from the same computer that Taylor had used. Notice also that I know this because I am logging both allowed and denied events. While this admittedly consumes more resources, I benefit from having a complete view of activities.

More fun with user-level logging

The examples above demonstrate how you can use log records to monitor compliance and abuse of an AUP, but they illustrate only how you might monitor external Web access. If you're concerned about information leakage via e-mail attachments, you might investigate how role-based access controls can be implemented in conjunction with the SMTP proxy to prevent unauthorized or unintentional disclosure of sensitive or modifiable material. For example, an organization might elect to prohibit certain groups from distributing documents in Microsoft Word by blocking attachments of this MIME type at the SMTP proxy and permitting only Acrobat (pdf) attachments. User-level monitoring has lots of different practical uses.

Role-based access controls can also be applied to visitors to an organization's Web or FTP site. For example, an organization might create user accounts for business partners or contract workers and grant such parties access to certain directories or file types. Generally, you can define as many user groups as needed to support the set of role-based access controls that meet organizational security objectives, and satisfy any regulatory constraints as well.

By logging Allowed as well as Denied traffic, you'll have a more complete and accurate picture of network activity and who's initiating it. Your organization will have enough information to analyze rather than guess when configuration problems and claims of abuse occur. Finally, if you take appropriate measures to protect log records from tampering, you will be better prepared if questions of regulatory compliance arise. ##


      Copyrightę 2005, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.