Section 18.4. Accounting

18.4. Accounting

Designing and implementing moderately complex software that works reliably while satisfying its design goals can be difficult. Designing and building secure software is significantly more difficult. An error or omission in the design or implementation of software may provide avenues that can be exploited by cheaters and attackers. Unfortunately, designing, building, and testing for security will not necessarily make an application completely secure. Just as there are functional bugs in software, there are usually security flaws. Unlike most software bugs , which may be reported with great passion by your customers, cheaters and attackers are unlikely to tell you about the security flaws they discover in your software.

Accounting provides an electronic "paper trail" to detect and diagnose security flaws. An essential component of a secure application is that it automatically provides a complete accounting of every significant thing it was asked to do and every action it took in response. In particular, the application software, in conjunction with the server it is running on, should provide detailed information about:

• Attempts to compromise the security of the systemfor example, attempts to log in by guessing passwords or to deny service to legitimate users by flooding the server with data or connection attempts

• Successful intrusions by attackers

• Misuse and abuse of the system by legitimate users or cheaters

A thorough accounting of what your software is really doing and how it is being used requires logging server- and application-level events, as well as regular examination and rotation of the logs that are generated.

Recording logs doesn't help if you never check them for suspicious activity (either manually or automatically). Furthermore, logs can be modified to hide the trail of an attacker, so make sure your log files themselves are secured.

18.4.1. Server-Level Logging

Before we look at FlashCom's logging facilities, you should consider acquiring intrusion detection software such as Tripwire (http://www.tripwire.com). Tripwire and similar products monitor changes in the software installed on a server and will immediately provide an alarm when the software is changed. It doesn't matter if the change is caused by a remote attacker or by an administrator's mistake. Detecting a successful intrusion or unauthorized software change from the beginning can help administrators limit or prevent further damage and bring systems back more quickly to the state they are supposed to be in.

Once you have intrusion detection, you need to make sure you can access FlashCom's server logs. On a Windows server, FlashCom updates the operating system's Application Log with information about startup and shutdown events and, more importantly, about bad connection attempts. You can use the Windows Event Viewer to review the Application Log by going to Start Control Panel Administrative Tools Event Viewer. Select Application Log to see application events. If your system has been port scanned or attacked , you will see error messages such as this one:

 Bad network data; terminating connection : (IP: xxx.xxx.xxx.xxx, App: FlashComAdmin (TCAdminAdaptor)) : 02 00 02 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 N e s s u s - T e s t - U s e r 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 X X X X X X X X X X X X X X X X X X X X 00 00 00 00 00 00 00 00 00 00 14 0 0 0 0 0 0 a 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   18 81 B8 , 08 03 01 06 0A 09 01 01 00 00 00 00 00 00 00 00 00 s q u e l d a   1 . 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

I've shortened the listing and removed the actual IP address, but the entry was the result of a port scan by Ryerson University's security staff on a university FlashCom server. You should discuss with your system administrator how to monitor and archive FlashCom error messages. To prevent FlashCom from having to handle a very large number of invalid connection attempts, you may be forced to temporarily block access at the network level to IP addresses that persistently make a large volume of invalid connection attempts.

Other messages include failures to log in to the administrative server (I've removed the actual IP address):

 Failed login attempt from xxx.xxx.xxx.xxx at 10/08/2004 5:20:25 PM. 

Also, if a client attempts to connect to an application that does not exist, the log will show the message:

 Connection rejected by server. Reason : [ Server.Reject ] :   (_defaultRoot_, _defaultVHost_) : Application (noApp) is not defined.. 

18.4.1.1 Access logs

Once you are sure you can monitor server-level events and bad connection attempts, you have to decide if you want to turn on access logging for each virtual host. If you decide to enable access logging, follow the directions in Chapter 10 or available from Macromedia in the section on the Vhost .xml file in Managing Flash Communication Server at:

http://www.macromedia.com/support/flashcom/documentation.html

Over time, the access log file can grow in size so it should be regularly rotated (files older than a determined age must be moved to an archive). Otherwise, the filesystem will eventually fill up with log data and the server will stop working. You can ask the system administrator running the server to use a log rotation script or a utility available from Macromedia:

http://www.macromedia.com/support/flashcom/ts/documents/flashcom_logging.htm

The access log file (or simply access log) contains a series of onLog( ) method calls and the information object that was passed into each call. To read the file, which is stored as a stream named access.flv , it must be played by a Stream or NetStream object with a predefined onLog( ) method. See Chapter 10 and Example 10-13 for more details.

Here is a sample entry from an access log on my local development server:

 id: 72121824 referrer: file:///F/Flash/OreillyBook/chapter13/PeopleGrid/peopleGrid.swf uri: rtmp:/peopleGrid/_definst_ pid: 1784 time: Mon Apr 19 10:59:15 GMT-0400 2004 description: Connect code: NetStream.Admin.Access level: information tunnel: false 

The description field indicates whether the client connected or disconnected. The time , the name of the application instance ( uri ), and the address of the referring .swf ( referrer ) are also available. Unfortunately, the security value of the information is limited because the IP addresses of the client and agent are not provided. However, the log is useful for monitoring the total number of connections across a virtual host to every application instance, as well as the address of each .swf that connected. The id field is a unique identifier for each client. To determine how long each client was connected, match the client id for a "Disconnect" description against the record with the same id and a "Connect" description .

18.4.1.2 Bandwidth logs

Macromedia provides a sample bandwidth-logging application, named Flogger :

http://www.macromedia.com/support/flashcom/ts/documents/flashcom_logging.htm

The application is installed like any other application by creating an applications subdirectory named Flogger and installing a Server-Side ActionScript file ( Flogger.asc ) in it. An updated but unsupported version of Flogger (version 1.1) was announced here:

http://www.markme.com/mesh/archives/000774.cfm

The Flogger application was designed primarily as a sample application, but it is useful as a starting point for developing your own application for monitoring bandwidth consumption of virtual hosts and by applications. However, you should expect to spend some time modifying it to meet your own needs before relying on it in a production environment.

Flogger generates a new bandwidth log file every day and updates it every minute. Each log file is an .flv file with a filename in the following format:

 BandwidthInfo_   yyyy   _   mm   _   dd   .flv. 

For example:

 BandwidthInfo_2003_07_26.flv. 

A Flash client is provided that can read bandwidth log files by connecting to the Flogger application and playing each recorded stream. The stream contains stored remote method calls and an information object passed into each call. An onServerStats( ) method information object contains the following properties:

 bytes_in bytes_out total_connects total_disconnects connected memory_Usage cpu_Usage time 

See the Server Management API, discussed in Chapter 10, for information on how to interpret each field. The time property is the time the log entry was added. The stream also contains onAppStats( ) method calls with information objects that contain the following properties:

 bytes_in bytes_out accepted rejected connected time appName vhostName 

18.4.1.3 Collecting FlashCom Server logs

Both the access and bandwidth-logging applications come with Flash movies that can read the stream files they create. However, in many cases, a better approach is to read, analyze, and archive log files at regular intervals using a separate administrative or logging server. If any of the primary FlashCom Servers are compromised and their logs erased, the administrative server will have protected copies of the logs. An administrative server should also issue alerts when significant events occur so that a system administrator can take action as necessary.

Many medium- and large-scale organizations already have secured logging or administrative servers. A FlashCom Server installation can be added to the system to run custom-written logging applications. The custom applications connect to and read the log files of the primary FlashCom Servers at regular intervals. Figure 18-3 shows an administrative FlashCom Server protected behind a firewall.

Figure 18-3. An administrative FlashCom Server for logging purposes behind a firewall

The administrative server can connect to the primary FlashCom Servers but cannot be reached from the Internet due to the firewall.

Later releases of FlashCom (after 1.5.2) may generate text or other types of log files that can be handled in more traditional ways. In that case, a separate logging server to securely store and analyze logs is still a good idea. Also, the code in Flogger.asc and admin.asc files is an excellent starting point for designing and building custom logging and monitoring applications.

18.4.2. Application-Level Logging

Server-level logging may not tell you when someone is using an automated program to try to guess user passwords or catch someone trying to cheat in an online game. To deal with those and other problems, you need to analyze your application to determine what events are significant enough to log and learn how to analyze logs to find problems. When an event occurs, both the event and the server's response should be captured. For example, every application should log each login attempt, how the attempt was handled, and why.

Built-in application logging is available in FlashCom and is described in Chapter 10. When it is enabled, a separate .flv file that contains the output of every trace( ) statement is created for every application instance. No log rotation system is available, so one has to be developed to rotate and archive each .flv . The code in Chapter 12 for finding and reporting all the .flv files in a directory using ColdFusion is a good starting point for a log rotation and archiving function if necessary.

Another and more flexible approach is to use the PFCSLogger component described in Chapter 12. Although it requires access to an application server via Flash Remoting, it is an excellent way to create useful logs in a central location.

Finally, in some cases, there may be legal or other requirements to record everything, including all the audio/video sent to the server by every user. In that case, the recording framework introduced in Chapter 15 can be used in conjunction with a regular logging and archiving system to record and archive everything.

One important security feature offered by FlashCom is worth noting. Audio and video streams served by FlashCom are never recorded in the user's cache. This affords an extra measure of security for copyrighted materials. Flash video played without FlashCom (either embedded or progressive video) is cached on the end user's hard drive and is therefore more susceptible to copyright infringement.