Design of a Network-Access Audit Log for Security Monitoring and Forensic Investigation

Transcription

1 Design of a Network-Access Audit Log for Security Monitoring and Forensic Investigation Atif Ahmad Tobias Ruighaver University of Melbourne Department of Information Systems, University of Melbourne, Parkville, Victoria. {atif,tobias}@unimelb.edu.au. Abstract An attempt at determining the source of anomalous network traffic may result in the identification of the networked system where it originated. From a forensic point of view it is almost impossible to positively identify the application or the user behind the application that generated the traffic. Many users may have been using the networked system and there remains the possibility of network traffic generation by Trojan horses. We propose a network-access log that bridges the gap between system event logs and network monitoring by extending event logging on individual hosts with information pertaining to generation of network traffic. The key contribution of the proposed network access audit log is the establishment of the chain of evidence linking the outgoing traffic to its source thereby improving the network security of an intranet. Keywords Security Monitoring, Forensic Investigation, Network Monitoring, Event Log. INTRODUCTION Recent trends in Trojan horse deployment indicate an alarming increase in the use of deceptively modified scripts and programs to gain unauthorized access to computer systems (Gordon et al. 1998). Traditionally it has been insider threat, malicious and unintended, which offered the most potent challenge to computer security. Today the Trojan horse has emerged as a new cause for concern, and is expected to compete with insider threat as the main source of security violations. Trojan horse detection is often integrated in anti-virus software. Detecting Trojan horses on a large scale while using a template-based file-identification paradigm implicitly assumes that those Trojan horses are being employed to gain unauthorized access to more than one system at a time. More hazardous Trojan horses are those that are tailored to a single target and hence may not appear elsewhere (Gordon et al. 1998). In order to counter unique or rare Trojan horses dedicated to particular targets we cannot continue to rely only on file-identification paradigms, whether template or generic based. Instead more sophisticated methods of detection must be employed. From a forensic point of view, it is currently difficult or even impossible to ascertain whether a malicious attack originates from a Trojan horse or from some other source. Although some Trojan horse behavior can be detected by monitoring network traffic, most traffic patterns caused by Trojan horses and other malicious network applications cannot easily be differentiated from non-malicious traffic on the network. More importantly, even when the presence of a malicious program is known, it may still be impossible to identify just from the network traffic itself which traffic originates from the malicious application and which traffic has been produced by other network applications. This paper will first discuss the inadequacy of currently available auditing techniques. We will then propose a model for a network-access audit log aimed at recording network-related behavior of applications. We will show that the logging of this behavior makes it much easier to identify malicious network traffic and that by tracing network attacks back to the actual application that generated the traffic; these logs may also allow the forensic investigator to establish the exact involvement of the user in the attack.

2 COLLECTING EVIDENCE IN A CORPORATE INTRANET ENVIRONMENT Traditionally logging has been the primary source for documenting events happening in operating systems. Event logs aim to record significant events in the case where an incident takes place and the administrator wanted some idea of what had transpired (Murray 1998). Event logging has been based on the old centralized computing model that is now largely obsolete. In an Intranet-type environment where resources are distributed, events on one computer are frequently related to those on another. In these scenarios centralized logging leads to extremely localized (and short) chains of evidence that are difficult to relate to other chains on other computers within the same Intranet. Network traffic logging has assisted in connecting links of evidence that exist on operating systems that are related due to the use of network connectivity. In the case of malicious-use of remote commands if network traffic is recorded then it can be typically traced to a source address thereby connecting it to the computer from which the attack originated. In general there is not enough information in the event logs of the source address to identify which application initiated the network traffic and what initiated the network traffic in the first place. Specifically, intention is extremely difficult to establish in such an environment. If a user account can be linked to the use of privileges that led to the generation of malicious network traffic, the user may still claim that he/she didn t do it. In such a case it may become necessary to provide a source of evidence that cannot be easily repudiated that identifies the identity of the user. In such a case physical access control logs or CCTV pictures may be required. Industry standards and expert advice in the area of incident handling have traditionally limited the scope of the crime scene to the computer system itself. In a corporate intranet broadening the scope to include the immediate physical work environment around the computer system will significantly improve the context of computer-based evidence. It has been well documented that the vast majority of malicious incidents that aim at harming corporate interests originate from the work environment. Including the immediate work environment surrounding computer systems will preserve the chain of evidence that has traditionally ended at the user terminal. A significant percentage of financial loss is also due to unintentional human error. In these cases evidence collection in the work environment will provide useful intelligence that may help in explaining the why and the how of the incident. In effect, valuable intelligence may assist in reducing the cost of human error long-term. Figure 1: Chain of Evidence linking user to incident

3 THE RATIONALE FOR NETWORK ACCESS LOGGING Event logging in a generalized sense is simply a process by which details regarding a significant event are recorded onto a persistent medium for future reference. Traditionally event logging has focused on events happening in the operating system on individual computers. Event logging facilities aim to record significant events in case the system went down and the administrator wanted some idea of what transpired (Murray 1998). Today the centralized computing model is largely irrelevant; the average workplace employs a distributed architecture where users no longer generate traffic on a centralized system. Instead dedicated workstations generate network traffic and access network resources (like file servers etc.) on demand. This new distributed computing model has replaced the centralized model as the preferred computing architecture and has gained wide acceptance in workplaces today. Unfortunately, general event logging technology has not kept up with this development. As is obvious, event logging too should become distributed. However, just collecting the event logs of every system in a centralized event database is not an adequate solution. Without adapting the system s event logging mechanism to its new role, each system will only record events as if it were in a stand-alone state. Figure 2: Windows NT Event Log Entry To address the obvious deficiencies of current event logs, some system administrators are trying to gather data from the network itself (Mukherjee et al. 1994). However, there is a lack of guidelines on what data should be collected while the collection itself has become difficult through the widespread use of LAN switches. Hence, system administrators often have to rely on commercial network monitoring tools designed to ensure the efficient running of the network. Better, but still relatively expensive, are commercial network intrusion detection tools. In both cases, the data collection will be limited by the original objectives of the data collection tools. Even when a systematic network monitoring approach is combined with the traditional logging of system events, a forensic investigator faces difficulties. The low level of abstraction of the information contained in network logs will make it difficult to get a detailed understanding on what is happening on the network (Sommer 1998). And when suspicious network patterns have finally been identified, it may only be possible to trace them back to the systems involved. If the attacker has not manipulated the internal timing of the identified systems, it may also be possible to find out which user account was involved. In general, there will not be enough information in the event logs to determine whether the traffic was directly initiated by the user, was generated by a specific application that has been running without the user being aware, or perhaps resulted from some other event (Sommer 1998).

4 The following is a sample tcpdump output showing network events illustrating the limited data available when recording network traffic (Loza, 2000) : #tcpdump tcpdump: listening on hme0 11:17: > : udp 82 11:17: pine.tree.com > birch.tree.com.telnet: =>S : (0) win 8760 <mss 1460> (DF) 11:17: pine.tree.com > oak.tree.com: icmp: echo request (DF) 11:17: oak.tree.com > pine.tree.com: icmp: echo reply (DF) 11:17: arp who-has tell Field Data Timestamp: 11:17: Source.Port > Dest.Port: > : Protocol : Udp Bytes of data: 82 Table 1: tcpdump entries We are primarily concerned with the first line of this example where host sends data to host through port Tcpdump tells us the protocol used is UDP and that 82 bytes were passed in this direction. Note the limited information we are able to obtain from such network logging. To bridge the gap between systems event logs and network monitoring, we need to extend event logging on each system with information on the source of network traffic. We can assume at this point, that all host-based traffic will be initiated by a network application or service and will have to pass the network subsystem (or network stack) of the host before being placed on the network itself. Hence, in the next section we will further develop the concept of a network-access log that records details regarding significant events that have occurred during the generation of network requests and during the processing of these requests by the network stack. By creating a log of events regarding the nature of all network requests, which links the user to the program generating the requests and that program to the traffic it produces, we believe we are able to improve accountability for both user behavior and program behavior in a distributed computing environment. OBJECTIVES OF NETWORK ACCESS LOGGING As computing moved from standalone computers to a networked environment, it became obvious that the available audit logs were no longer sufficient as the only source of evidence. To improve the situation, system administrators currently have no choice but to fall back on whatever network monitoring or network intrusion detection tools they have available (Sommer 1998). They will be limited by the options these tools have for generating network logs and other output. The proposed network access log will offer a third source of evidence regarding behavior of any network applications responsible for initiating network traffic. The types of events of interest to this event log include the starting up of these applications by the user as well as any action carried out by these applications that eventually results in the generation of network traffic. Behavior of network applications can be both passive and active. Passive behavior includes network application behavior like listening for incoming data and active behavior includes sending data to an external entity. Whereas both require the invocation of system calls, at the network driver level only the sending of data (active behavior) is detectable. Therefore, logging events elsewhere in the network stack may also detect the passive behavior of a network application.

5 In many cases it is the passive behavior of a network application that is indicative of the true nature of the application. For example a web browser and a web server both send and receive data through the network subsystem on port 80. Differentiating the two at the network driver level based upon whether they send or receive data is difficult. However monitoring the network application s invocation of services from the network subsystem (eg. Listen()) will allow the distinction to stand out clearly. The primary objective of the network access log is to record any data a forensic investigator may need to prove the historical chain between the source of the traffic (user, application, etc.) and each component that takes part in affecting the resultant network packet that is sent onto the physical link, so as to maintain accountability for all network traffic outgoing from the system. The main tradeoff in any event logging mechanism is to keep system overheads and use of disk space within acceptable limits, while at the same time maximizing the amount of useful information in the event logs Schaen et al. (1991). Hence, it is important to prevent excess redundancy in the event logs and to provide flexible options to allow the system administrator or security specialist to tailor the audit policy. THE BRIDGE MODEL It is important to establish that if collecting events at the network card level is not adequate, we no longer have a single point of collection for network related events. In most operating systems, the network stack can be invoked at different levels depending on the intended functionality of the network application involved. Further examination also shows that there is no obvious location at which monitoring would be able to achieve all of the above objectives of the audit log. Sufficient abstraction is required to be able to minimize redundant data and a strategic location(s) that allows the capture of the most useful data about the network traffic while ensuring that no traffic circumvents these monitored locations. If we accept that we can no longer monitor on the network card level, we may also have to accept that we can no longer guarantee that a malicious user or program can never bypass our event logging mechanism. We can only make circumvention of our monitoring points as difficult as possible. Although in general network calls may use any installed transport protocol and any available path through the network stack, there are only a few fixed number of entry points to the stack that are commonly used. Rather than monitoring the behavior of outgoing traffic through the entire stack, we propose that simply monitoring the entry points, while ensuring that the path from each entry point to the lowest layer is protected from tampering, will be sufficient. If we can assume that system administrator privileges have not been compromised, such protection can be easily instituted through the use of change-detection software. Logging every access point in the entire network stack may be possible but such an approach allows for significant redundancy to any subsequent logging. Hence, instead of monitoring all access points, we propose this bridge model where we endeavor to monitor a minimum number of points, while ensuring that all traffic flows through these points by protecting the stack from illegal entry or other attempts to circumvent those points. To confirm the viability of this bridge model we examined the flow of network requests through the network stack of NT. PRELIMINARY EXAMINATION OF NETWORK REQUESTS THROUGH THE NT NETWORK STACK Network Applications generate network traffic by sending outgoing data through one or more dlls. These dlls make up various layers of the network stack and eventually pass this data to the network card, which deposits it onto the network. To demonstrate the difference between passive and active behavior of a network aware application we display the startup sequence of a web browser at the top (Win32 API) and bottom (network card) of the network stack. The startup sequence consists of the invocation of the web browser and ends with the completed loading of its default homepage.

6 The following table illustrates the function calls made at the API layer (first 30 calls are shown). Address resolution and network address conversion functions (inet_addr,ntohs, htonl, inet_ntoa, etc.) and socket address resolution (getsockname) have been omitted. Call API Call Function 1 WSAStartup Initiates use of the Windows Sockets DLL by a process. 2 Gethostbyname Gets host information corresponding to a hostname. 4 Socket creates a socket which is bound to a specific service provider 7 Bind associates a local address with a socket. 8 Gethostbyname 14 Connect establishes a connection to a peer 15 Socket 17 Ioctlsocket controls the mode of a socket 18 Bind 23 Connect 24 Select determines the status of one or more sockets, waiting if necessary 25 Send sends data on a connected socket 26 WSAFDIsSet 27 Recv receives data from a socket 28 Select Table 2: Possible function calls used in the startup sequence of a web browser The majority of the above Winsock API calls are passive. The only active calls visible from the network card are send() and recv(). Web browsers follow a sequence of calls when establishing a socket connection (see Fig 3), these calls form a recognized pattern which can be used to identify anomalous Winsock activity by processes masquerading as web browsers. An interesting piece of information to a Forensic investigator would be the existence of an unsuccessful socket() call made by the network application. Unsuccessful socket() calls can occur for a variety of reasons including the failure of the network subsystem or the absence of a preceding WSAStartup() call. Any of these events provides a clear signal to investigators that unauthorized network calls were placed. The main features of a network access log would be the recording of the time a network application was invoked, the absolute path of the executable, the process id, and the active and passive behavior of the executing process. The network access log represents a continuing chain of evidence relating outgoing network traffic to its system based origins. Figure 3: Sequence of calls followed by Web browsers when establishing a socket connection

7 CONCLUSION The key contribution of the proposed network access audit log is the establishment of the chain of evidence linking the outgoing traffic to its source. Previously, detection of anomalous traffic would result in, at best, an indication of which system it came from. Currently, with many users using the system and with the possibility of network traffic generation by Trojan horses it is almost impossible to determine the application or the user behind the application that generated the traffic. The network-access log, on the other hand, provides the facility by which any piece of network traffic can be traced to its source. The main advantage of the network access log is detection of masquerade attacks (web servers acting like browsers or sending mail files, TCP/IP applications using other protocols and ports to send or receive messages, or anomalous behavior by legitimate applications), however the log can also build an indirect profile of the network traffic generated by the host. Change detection applied on the log allows it to become part of a distributed intrusion detection mechanism that detects insider threats. The primary weakness of this log is its inability to detect the use of unauthorized transport protocols. In order to generate network traffic, local system components must use all or part of the network subsystem to generate packets that will eventually be placed on the network. These packets are formed by transport protocols that consist of software installed by the system s administrator. It is assumed that the path(s) traversed by outgoing data destined for the network is inviolable, i.e. all outgoing data must enter the network subsystem using one or more of the approved paths before being placed on the network. Installation of non-standard or unauthorized packages that allow local components to circumvent any or all of these paths will violate the integrity of the audit log. Hence it is assumed that administrator privileges on the system are secure and the system administrator takes care when installing new network stacks to ensure that these are monitored as well. Finally, while the network access log attempts to record the behavior of local components of the system that generate network traffic, outgoing data itself is not filtered or inspected for anomalous content. Therefore, detecting normal network applications that do not behave in a suspicious manner but send confidential data will not be possible via this log. References Loza, Boris (2000). Sniff Your own Networks with TCPDUMP, Gordon, S. and D. M. Chess (1998). Where There's Smoke, There's Mirrors: The Truth about Trojan Horses on the Internet. Virus Bulletin Conference. Murray, J. D. (1998). Windows NT Event Logging, O'Reilly & Associates. Mukherjee, B., L. T. Heberlein, et al. (1994). Network Intrusion Detection. IEEE Network(May/June 1994): Sommer, P. (1998). Intrusion Detection Systems as Evidence. RAID 98, Louvain-la-Neuve, Belgum. Schaen, S. I. and B. W. McKenney (1991). Network Auditing: Issues and Recommendations. IEEE: Bishop, M. (1995). A Standard Audit Trail Format. Proceedings of the 1995 National Information Systems Security Conference, Baltimore, MD. Ranum, Marcus J. et al., Implementing A Generalized Tool For Network Monitoring, USENIX 11 th Administration Conference, San Diego, Oct Systems

8 COPYRIGHT [Atif Ahmad, Tobias Ruighaver] The author/s assign the We-B Centre & Edith Cowan University a nonexclusive license to use this document for personal use provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive license to the We-B Centre & ECU to publish this document in full in the Conference Proceedings. Such documents may be published on the World Wide Web, CD- ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the authors.