Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations

1-1-2005

A modular architecture for security tools (MAST)

Pascal Openshaw Iowa State University

Follow this and additional works at: https://lib.dr.iastate.edu/rtd

Recommended Citation Openshaw, Pascal, "A modular architecture for security tools (MAST)" (2005). Retrospective Theses and Dissertations. 19204. https://lib.dr.iastate.edu/rtd/19204

This Thesis is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. A Modular Architecture for Security Tools {MAST)

by

Pascal Openshaw

A thesis submitted to the graduate faculty

in partial fulfillment of the requirements for the degree of

MASTER OF SCIENCE

Co-majors: Computer Engineering; Information Assurance

Program of Study Committee: Doug Jacobson, Major Professor Yong Guan Adrian Sannier

Iowa State University

Ames, Iowa

2005

Copyright @Pascal Openshaw, 2005. All rights reserved. ii

Graduate College Iowa State University

This is to certify that the Master's thesis of

Pascal Openshaw has met the thesis requirements of Iowa State University

Signatures have been redacted for privacy lll

TABLE OF CONTENTS

CHAPTER 1. Overview ...... 1

1.1 Introduction . 1

1.2 History 2

1.2.1 Common areas 2

1.2.2 Additional security tools . 3

1.2.3 Putting them all together 3

1.3 The MAST solution 4

1.3.l A voiding vendor lock-in 6

1.3.2 Tradeoffs 6

1.3.3 Information collection 7

1.4 Sample scenarios 9

1.5 Potential modules 9

1.5.1 Application profiles . 9

1.5.2 File integrity checking 11

1.5.3 Antivirus integration . 12

1.5.4 Firewall integration 13

1.5.5 File access . 13

1.5.6 Registry access 14

1.5.7 Event logs . 14

1.6 Multiple computers . 14

1.6.1 Compiled information 15

1.6.2 Shared configurations 15 iv

CHAPTER 2. MAST configuration ...... 16 2.1 Webmin modules . 16

2.2 Central repository 17

2.2.1 Configuration 18

2.2.2 Analysis 19

2.2.3 Alerts . 19

2.3 Plugin architecture 21

2.4 Database layout . . 21

2.4.1 By program 22

2.4.2 By type . . 22

2.4.3 Program analysis 22

CHAPTER 3. File monitoring ...... 24 3.1 Programs ...... 24

3.1.1 Tripwire, Inc 24

3.1.2 I3FS .. 25

3.1.3 AFICK 26

3.1.4 Samhain . 26

3.2 Webmin module 26

3.3 MAST plugin . . 27

CHAPTER 4. Antivirus integration ...... 30

4.1 Programs 30

4.1.1 Clam antivirus 30

4.1.2 Commercial options 31

4.1.3 F-Prot . 32

4.1.4 Spyware 33

4.2 Webmin module 33

4.3 MAST plugin 34

4.3.l Analysis 34 v

4.3.2 Table layout ...... 35

CHAPTER 5. Network integration ...... 36

5.1 Programs ...... 36

5.1.l Network intrusion detection 36

5.1.2 Firewalls 37

5.2 Webmin module 39

5.3 MAST plugin . . 39

CHAPTER 6. Additional applications ...... 42

6.1 Analysis 42

6.2 Normalizing across applications 43

6.3 Related products 43

6.3.1 Nagios . 44

6.3.2 Entercept 44

6.3.3 Webmin . 44

6.4 Related research 45

6.5 Future work . 45

6.5.l Plugin development 45

6.5.2 Data analysis . . . . 46

6.5.3 Configuration management 46

6.6 Measuring success 46

6. 7 Conclusion . . . . 47

APPENDIX . MAST database 48

BIBLIOGRAPHY ...... 51 vi

LIST OF TABLES

Table 2.1 Webmin standard modules for security . 17

Table 2.2 Webmin third party modules for security 17

Table 3.1 Layout for file integrity checking . 28

Table 4.1 Layout for antivirus reports 35

Table 5.1 Layout for Snort reports ...... 40

Table 5.2 Layout for firewall configuration changes 40 1

CHAPTER 1. Overview

Desktop computer security is a growing problem with the many viruses, network attacks, trojans, and other malicious programs that can affect a system. Trying to track down what has happened on a computer, remove problems, and prevent future intrusions can be very problematic.

The solution proposed in this thesis is to have a modular architecture for security tools

(MAST). MAST consists of three components: A database containing security information, programs to interact with the database, and patches to security tools so that they can interact with the database and each other. The expert tools are responsible for analyzing data from their realms of expertise and reporting relevant information to the database. They should also be capable of sharing elements of functionality with other security applications through documented commands or interfaces. In return the programs may also be set up to utilize the functionality of other programs if installed. This kind of information and functionality sharing has the potential of increasing the quality of programs and reducing duplication of effort.

1.1 Introduction

As a computer is running, many things are happening at the same time. Network services are responding to traffic, programs are accessing files, and system changes are being made periodically. Unfortunately there are no easy ways to view or even record most of this infor­ mation. A typical security administrator might have network alerts, a few event log entries, and not much else to work with.

The key is to record all the information that the security administrator needs without being overwhelmed with too much information. A modular architecture fits this need by enabling or 2 disabling various portions based on requirements.

At the moment there are many specialized utilities for security. The plethora of security software companies are each trying to establish their niche in a particular area, and a select few are attempting to expand their areas of expertise to everything that concerns computer security.

The goal of MAST is to combine the expertise of security companies in each product area into one global package that is capable of monitoring various critical events for a computer system.

1.2 History

Intrusion detection systems (IDS) have been an important topic for many years. Ever since the first security vulnerability was found and exploited, computer administrators have been looking for ways to find out about and prevent such exploits. Various tactics have been taken in order to do this.

Of course, the best way to ensure good computer security is to not have any vulnerabilities in the software to begin with. Unfortunately software flaws are a continuing problem that is not going away anytime soon. Even if software is assumed to be perfect there are still potential problems such as accidentally installing viruses, spyware, using poor passwords, and so on. In these cases the IDS software is capable of mitigating the damage by detecting problems early on.

1.2.1 Common areas

Three of the main angles taken by IDS products have been in the areas of file integrity checking, network monitoring, and antivirus. These make intuitive sense in that certain files should never change and finding out when they have is an important step in making sure that the system is secure. The network IDS (NIDS) is important because network traffic is ever-changing and presents potential pitfalls for the computer that is trying to interpret that traffic. 3

The most well-known program for file integrity checking is Tripwire, which has been around since the early 1990's. The open-source Snort has been the standard bearer for NIDS products and has also turned into a commercial product more recently. As for antivirus systems the major vendors at the moment are Symantec, Network Associates, and Trend Micro.

1.2.2 Additional security tools

As it turns out, however, there are a multitude of security programs and checking mech­ anisms. Spyware has become a much greater problem with the increase in Internet traffic, web browsing, and e-mail. AdAware and Spybot Search & Destroy are two common pro­ grams that are capable of removing malicious software. Vulnerability assessment tools such as

Nessus, SATAN, SAINT, and nmap are capable of finding potential remote compromises on computer systems. Numerous studies have been done looking for efficient artificial intelligence algorithms which can use intelligent agents to collect information and determine intrusions with the highest accuracy. The various approaches that are possible have led to a plethora of various software applications ranging from anomaly detection, event log monitoring, root kit detection, and so on.

1.2.3 Putting them all together

Clearly a solution must be found for the typical computer administrator so that the se­ curity situation can cover all the various aspects yet still be usable. All the various products available can be confusing at times, which is where the big-name companies usually take to the forefront with the easier to use software suites. Network Associates has been moving to have more comprehensive solutions by including firewalls, spyware detection, and so on into their products. In the same way Tripwire has become an overall change monitoring solution rather than just simple file integrity checking. The problem, though, is that few companies can yet claim to have outstanding systems for each aspect of security. 4

1.3 The MAST solution

Many companies attempt to create a global tool that is capable of doing everything. The program collects information from all the log files, network traffic, file access, virus detections, integrity checking, user behaviour, network statistics, and so on. By parsing through all this information the program attempts to find the patterns and reach conclusions about what is going on.

Unfortunately, such a global approach neglects the expertise that has already been devel­ oped in niche areas. Networking experts have been working on years on certain networking programs that are open source. It would be a shame to lose all of that valuable time and expertise in order to develop something that is brand new.

The goal of MAST is to leverage the expert knowledge of each program while also combining the results of each so that they can be correlated with each other. Each security tool may only generate low-level alerts for their areas of expertise. When taken together, however, these alerts can combine to create something more meaningful.

There are three huge advantages of program integration: Event correlation, active re­ sponses, and analysis modules.

Event correlation refers to taking security alerts from several different sources, agents, or programs and combining them in ways that make sense. The more security programs are installed, the larger the number of alerts that go through and the more difficult it becomes to keep track of them all and understand relationships. Event correlation utilities attempt to recognize related events, detect multi-stage attacks, and prioritize the relevant alerts.

An active response mechanism gives the intrusion detection system (IDS) the capability of making changes to the system based on detected threats. An appropriate response to a network attack might be to shut off certain port numbers, change firewall settings, or disable services on a host. The capability of making these changes is an important aspect of an automated security system. Requiring human interaction to make certain kinds of changes gives attackers a lengthy head start on compromising systems.

Lastly, analysis modules are what take the data collected from one or more sources and 5 either apply its algorithms to the data to reach its own conclusions or present the information to the security administrator in a manner that is understandable. The first approach is more favorable to an automated IDS system while the latter is helpful for informing the security administrator and detecting as yet unkown attacks.

An additional advantage lies in the area of sharing program functionality. Currently each security tool is designed to stand on its own and must potentially re-implement the functionality of other applications. An example is the ability to detect file accesses and run an on-demand virus scan, a file integrity check, an application profile monitor, a status monitor, and so on.

Another example would be for security tools to check for network traffic related to the log files, to an application's profile, and so on. Clearly there should be a way for such checks to occur without having to rewrite all of the program code involved or make them one monolithic program.

The MAST approach is able to solve all of these problems through the use of program patches and modules for the database. The analysis modules take the already existing data and make possible the event correlation that reduces the number of alerts. The ability to implement active responses and sharing program functionality is provided by patches to the programs.

Configuration of each security tool might still be difficult. In order to simplify the security administrator's tasks a common console for the various security tools is important. Common control centers for other kinds of tools have already been created with projects such as Webmin and the Mandrake Control Center in Linux. On the Windows side the Microsoft Management

Console, run with the "mmc" command from a prompt, is capable of using standardized sets of configuration tools available through consistent snap-ins. These snap-ins retain the same style and functionality moving from Windows 2000 to XP and on, making computer administration that much easier. While such a convenient interface would be helpful for use with MAST it is not required. The Webmin interface considered here is run through the use of a web browser for the greatest possible flexibility and configuration options. 6

1.3.1 Avoiding vendor lock-in

Another problem with the current security situation is that businesses and individuals must choose their overall security provider and attempt to work everything out with just that vendor. The alternative is attempting to install twenty completely different applications each with its own setup and configuration. This situation favors the large companies which have the funds to develop global solutions even if each particular aspect of that solution is not as strong as it could be.

Snort and Tripwire are good examples of products that started off in a niche area and grew to become bigger players. By that point they had started to commercialize and left some of the open source work behind in order to differentiate themselves. Still, there is most likely no chance that those two would be able to start including virus detection code, log parsing, and other abilities into their software portfolio without expending huge amounts of time and money.

The situation would be much better if the various products could coexist in an open overall framework without having to rely on subpar components. In that way, each company could invest the time and energy into its area of expertise and make their software more effective.

The open management utilities for coordinating the various software components would take care of the rest.

Such a solution would promote more use of independent software products that might have merit. If the architecture is readily available and applications can plug into it, then changing from one integrity checking program to another would not necessarily be a difficult task for example. Neither would changing antivirus, network monitoring, or logfile analysis vendors.

1.3.2 Tradeoffs

One of the chief arguments for integrated systems is that they are more capable of corre­ lating events together and analyzing them as a whole. They would also be simpler to use for that reason since there is just the one interface rather than having a bland generic interface to several programs or even worse have to use many different interfaces with the other programs. 7

It would seem that an open architecture that combined several separate programs could lose from the perspectives of both security and usability.

This does not have to be the case, however. By having an open selection of many different programs for each task a higher software quality can be achieved. Only the best application suited for the task would be picked rather than having to rely on one company's offerings.

Events from various sources can still be correlated when a common framework is used. This helps from the security standpoint.

From the usability standpoint, having a common framework would actually help make things easier to handle. The Webmin interface is an excellent example of how the various servers, programs, and configurations are kept up to date without having to be an expert in each area.

1.3.3 Information collection

One of the strong aspects of MAST's modular architecture is that it does not necessarily do any of the analysis itself. Foolproof intrusion detection is not an easy problem to solve. Human computer users are not much better at being able to analyze large amounts of information and determine whether or not an intrusion has occured. Instead of doing the analysis on huge databases of collected information, however, MAST simply collects the alerts and relevant information from the various areas and correlates the results together.

1.3.3.l Expert systems

How much each program reports to the MAST database is up to the designer of the plugin.

There are arguments either way about how much information to include.

Snort is potentially capable of logging all traffic going by a computer and saving it for future reference. As a MAST module it would therefore be possible to simply store this information into the MAST database so that the user can analyze it and draw conclusions. There might even be rulesets developed that would be capable of efficiently going through that information and finding relevant aspects. 8

The massive database approach is not the best one, however, in the sense that the collective knowledge of many security experts is not used. Snort does not need to keep all of the traffic in order to figure out which packets are suspicious. The rulesets and attack signatures developed over the years are extremely useful in helping sort out which packets cause alerts and which do not. The MAST system, at this point, would receive only the alerts and relevant critical events.

In the same way, the file integrity checker does not need to store all of the hash values and signatures within the MAST database. The program can use whichever storage method is quickest for itself, as long as it is capable of reporting to MAST when one of the files no longer matches.

There might be cases where each independent program would be finding more intrusions if they were correlating information with each other. That is where the beauty of a modular architecture comes in. Certain modules can be shifted towards more information rather than less if the need arises. There could be multiple modules for the Snort program depending on whether the security administrator would like to collect just the most critical alerts, most of the alerts, or all of the traffic going through. For a typical computer user only the most critical ones might be important. For a high security system, however, the additional information provided for correlation with the other sources might be important.

1.3.3.2 The MAST expert system

When more of the analysis work is offloaded to the MAST system, there starts to be a need for additional tools which are capable of sifting through that information. The ability to analyze the information is left as an analysis module for the MAST database rather than being an integral part of it.

There are two ways that MAST can analyze the information that is in its database. It may perform some additional checks on the information given, which amounts to analyzing the information more than what the expert system had already done. The other way to use the information is by relating it to other portions of the database. 9

Initially, with each module, it is not known how the information relates to others. There might be file names, IP addresses, virus names, timestamps, and so on that are collected.

Matching these up may help in certain situations. The MAST ruleset must be capable of finding similarities, using trigger conditions, and assisting the user in making correlation decisions. In addition to the regular monitoring modules, MAST therefore also needs higher-level analysis modules that are capable of putting together information from more than one source.

1.4 Sample scenarios

The kinds of questions that MAST intends to solve are very practical. Here are a few examples.

An unauthorized individual logged into the computer. During the time that they were logged in, what happened in the event log, was there any unusual network traffic, did any files change, and what commands were run?

A virus is found in a file. When was that file created, which user and/or program was responsible for modifying it, and were there any associated system or network events?

A rootkit is found to be installed on the computer. How did it get there, where was the vulnerability, and how can anyone be sure that it has been completely removed?

These kinds of problems could mean thousands or millions of dollars lost at companies if not answered properly. Identity theft, stolen credit card numbers, research databases, and national security information all depend on the correct evaluation of the situation. Without the proper security logs and analysis there could be additional problems that come up.

1.5 Potential modules

Some of the possible modules for integration are given below.

1.5.1 Application profiles

The operating system must be capable of segmenting applications into their respective realms of influence. Role-based access control (RBAC) is a useful concept that has emerged 10 but it has traditionally been applied to users. Applying RBAC to applications would allow specific programs to be given or denied rights on the computer rather than have all security privileges inherited from the user running the application.

The uses of application sandboxing can be separated into three categories: System hard­ ening, application rulesets, and a user-decided desktop firewall.

1.5.1.1 System hardening

There are two major projects that make system hardening through RBAC a reality: NSA

Linux and LIDS. NSA Linux is a set of Linux kernel patches that allows RBAC rules to be defined and enforced. LIDS is a similar project that makes certain parts of the system much more secure and write-proof. A reboot of the entire system before changing the system state to insecure mode is often required before modifications to critical system files are made.

Limiting the access of the root account, root applications, and other processes to the bare minimum helps make the system more secure. The specific rules and allowances being applied can be fine-tuned with both of the projects mentioned in order to suit individual applications and needs.

Since the Windows kernel is not open there do not seem to be any corresponding security enhancing projects for Windows.

1.5.1.2 Application rulesets

Some of the same software wrappers that were used for system hardening can be used to make complex rules for applications. Each application could have its own profile and security settings. For example, an image-editing application would be restricted to only opening and modifying recognized image files. Exceptions would be made for its own configuration files.

Music-playing programs would not be allowed to modify system files, e-mail programs would have restrictions to its own downloads folder and mailboxes, and so on. Running programs with these specific rules would most likely not reduce the intended functionality of each program.

McAfee has been working on a DARPA-funded software wrapping application (2). However 11 the software is still in beta mode and not fully functional. Some of their challenges include making the wrapper non-bypassable and how to specify security policies for it.

1.5.1.3 Desktop firewall

In the true sense a desktop firewall should apply not just to which applications can talk to the network but also to what applications are capable of doing on the computer itself.

McAfee's Desktop Firewall is a security product that helps enhance security beyond McAfee's signature antivirus software. The DARPA-funded software wrapper project is a step in the right direction (2).

Such a software wrapper based on user interaction would function just like other programs do for the network. If a program requests to have access to particular files, a popup window would appear asking if the executable is allowed to read or modify certain files. Such a system would not do very well for the functioning of a standalone server but would be quite useful when it comes to desktop users attempting to keep control away from viruses.

Windows should already have a certain level of functionality in this area but it doesn't.

Since Microsoft has access to the entire kernel they are in the best position to implement security policies at the kernel and execution levels. Their disadvantage in the area is twofold however. Any additional software that they integrate as part of Windows will make it appear that they are using their monopoly to promote their own software. Additionally the software in the security realm would come under greater scrutiny than would equivalent software from other vendors and therefore likely receive poor reviews and have problems found.

1.5.2 File integrity checking

The rules specified for each program become useless if the original executable file is com­ promised. An attacker could simply replace system-level programs such as svchost.exe in order to obtain the privileges associated with that program.

Periodic file integrity checking would be a solution to this problem. When a program initially runs the value of its secure hash could be compared to the value in the database. If 12 the integrity check fails then the application is flagged and disallowed from using the security settings that were set in place for the original application.

The database must of course be rather secure so that the hash value is not tampered with.

Such tampering would allow a sophisticated malicious program to potentially compromise the hash value before running a program with enhanced privileges. If the other security checks are run properly then this should not happen.

Another danger is that the input to a trusted program is malicious. Beyond a thorough analysis of every single program and how the inputs affect it, there really isn't any way to be sure about the results. The best way to avoid problems due to improper inputs is to have anomaly intrusion mechanisms in place.

Lastly a program might be modified after it is already loaded into memory. Most modern operating systems, though, are capable of preventing programs from modifying the memory space of neighboring programs. If the operating system (OS) is incapable of protecting memory space between programs then that aspect of the OS should probably be remedied as well with either an upgrade or a patch.

1.5.3 Antivirus integration

The information from antivirus results are often not easily correlated with the initial causes of the virus. Viruses can come from a number of sources, whether they are open shares, opened e-mails, opened attachments, worms, or a computer break-in. Matching virus creation and discovery dates with network activity and file access times would allow fixing of the root causes of viruses.

There are currently a number of antivirus applications from companies like TrendMicro,

Network Associates' McAfee, and Symantec Norton. Each of these programs maintains its own results and log files without making them part of a larger overall system database. For the sake of analysis it would make sense to merge the antivirus searches and results with an overall security database that includes information about network and file activity. 13

1.5.4 Firewall integration

The computer's firewall can act as a network filter and monitor for intrusions. There are several available tools that do this. Snort is one of the most popular open-source tools while companies like McAfee have their desktop firewall products. Each of these is capable of detecting port scans and other kinds of potentially malicious activity.

The part that is missing is the ability to combine and correlate this network data with the statistics from file access and virus detections. Even with McAfee's own products there does not seem to be a mechanism to relate network events with other activity on the computer. In particular, when the antivirus component detects a virus the firewall is incapable of determining if that virus appeared due to certain kinds of network traffic.

A solution to the problem would be to take the results of the network scanner and include it in the security database.

1.5.5 File access

One area that deserves to receive more attention is a method of tracking file reads and writes. Currently the most common way of doing this is simply by trusting the operating system's security settings to prevent bad things from happening. There are not many ways to conveniently figure out when a file was last opened and what programs were responsible for the last modifications.

One of the problems with tracking file access information is simply the volume of data to be collected over time. With efficient simplification algorithms, however, it should be possible to have rotating logs about which files were opened and modified. Certain system executables could be exempt from the checking, for example, or if greater security is desired some of the accesses could be compressed by listing the file and the number of times it was accessed in a certain time period. Beyond knowing that the system accessed the registry 5000 times in one day more information may not be necessary.

As storage space becomes cheaper and more common the impact of such a database of file accesses would be minimized. When storage space is an issue the logs could be backed 14 up periodically to removable media, simply erased over time, or targeted to specific files and folders such as just the system folder in Windows or the /etc/ and /usr folders in Linux.

1.5.6 Registry access

A specific file that deserves more attention is the Windows registry. Knowing more than just read and write conditions would be helpful. Parts of the registry are responsible for application preferences while others determine the programs that are run upon computer startup, succesful logins, or to open different file types. Each of these would be useful to check.

1.5. 7 Event logs

Both Windows and Linux regularly log important system events in a configurable manner.

Within Windows, these logs are configured through the use of security settings and log options.

In Linux each invidual program and system component is configured to report events that match certain conditions.

The logs produced by the operating system have very important information such as failed login attempts, program crashes, errant system behaviour, and so on. Additional events can be monitored by changing a few settings.

For the sake of analyzing the security of the system it would make sense to include these logs into the security database. This could be done by either taking the logfile and merging it with the database once in a while or adding entries to the database in real-time. Of course, the second option may help security by catching problems immediately but might require more difficult programming.

1.6 Multiple computers

The solution being described for one computer would be very useful m scenarios with multiple computers as well. 15

1.6.1 Compiled information

The collected data that is stored m a local database could just as easily connect to a remote database and store the information there over time. Additional security checks would have to be run in order to have an encrypted connection between the two and also have good authentication so that bogus data is not inserted into the database. The outside database server should also be more protected from remote attacks since it is potentially receiving input from compromised systems.

Another way to approach network collection of information is through periodic alerts.

Instead of sending all information to the server only a portion of it may need to be collected for network analysis. These alerts could be in the form of summaries or selected portions of the security database.

1.6.2 Shared configurations

When certain application and event profiles are found to be successful on one computer system it would make sense to apply those same settings to other computers. Having a way to deploy security settings across multiple computers would make sense and would be very easy if the only configuration settings to change were just sitting in the database. The more difficult security settings to change would usually be on the Windows or Linux system OS side. On the

Windows side the security can be changed at the domain and active directory level with group policies. In the absence of such active directory options there should be a way to change them anyway with the use of scripts and registry changes.

Some of the computer differences to keep track of would be different operating systems, applications, program locations, and hash values. The security settings of one computer would most likely not be applied blindly from one computer to another without first making sure that the applications match and that the systems are similar enough. 16

CHAPTER 2. MAST configuration

There are two main aspects of the MAST setup. Given that it is a centralized manner of controlling the various security modules, there must be a way to conveniently set them up without having to parse through each tool's README file and figure out what is going on.

The other aspect is the central repository for the information collected from the modules. This portion can be a separate entity from the configuration tools.

For configuring each security tool, the Webmin system makes a lot of sense. Webmin is a browser based configuration server that has modules for various configuration tasks. The standard modules include such features as changing passwords, configuring firewalls, schedul­ ing cron jobs, and so on. The main categories are system, servers, networking, hardware, cluster, and 'others'. Having an additional tab for security would be a useful step once more security tools are available on Webmin. In the meantime they can be placed in system, servers, networking, or others as the case may be.

The central repository does not have to be a daemon that runs on the system. The only important part is that each application contributes information to its database for future analysis. When some of the other daemons, such as snort, place information in the database that is time critical then there are triggering mechanisms which cause an e-mail to be sent out with an alert and so on.

2.1 Webmin modules

Very few of the open source security tools currently have webmin modules. The standard modules are shown in table 2.1 and the third-party modules are shown in table 2.2. These are not part of the standard Webmin distribution yet. This could be because the modules have 17

Table 2.1 Webmin standard modules for security

I Description Shorewall firewall Makes changes to the Shoreline firewall Linux firewall Makes changes to iptables for Linux BSD firewall IPFW firewall for FreeBSD and Mac OS X IPFilter Firewall IPFilter for Sun Solaris systems Security sentries Portsentry, hostsentry and logcheck configuration Running processes List, kill and renice processes

Table 2.2 Webmin third party modules for security

Update I Description afick 12 Nov 2004 File integrity checker sysinfo 13 Dec 2003 Show devices and file usage wbmclamav 24 Feb 2005 Clam AntiVirus SAT 21 Jan 2001 Simple Audit Tool Snort 15 Dec 2001 Snort configuration Net Saint 21 Jan 2001 NetSaint has changed to Nagios portsentry 16 Apr 2003 portsentry IDS frontend firewalls 19 Dec 2004 Various firewall frontends not been updated in a while, they are not receiving widespread use, or are still in development.

As can be seen from table 2.2 very few of the major security tools have received continual development and support. Part of the reason is because each tool has usually developed its own frontend to configure things. Another reason is that some of the products start selling commercial front-ends in order to support development of the software.

Some of the security tools are rather difficult to set up properly without going through lengthy manuals. When the default configuration is left on everything is all right but as soon as changes need to be made programs like snort become beyond cryptic.

2.2 Central repository

The Webmin modules are a good step forward leading to easy management of the various programs. They are not, however, an end in themselves for the MAST system. Each module for the security tools is an independent entity and does not interact with the other ones. 18

The MAST system, however, is designed to pull together information from these disparate programs and draw useful conclusions and analysis. It pulls information from the firewall systems, host IDS, log checkers, and so on in order to keep track of everything. It is like a central control panel for monitoring all critical events on the computer. As such it needs its own database and plugins in order to interact with the various applications.

MAST can still be written in Perl as a web interface for monitoring. In fact, it could even be present as one of the Webmin security modules. However, the important portions are the plugins for each program that it monitors and the database that is kept up to date through each of these plugins.

2.2.1 Configuration

The configurations within MAST tell it how to keep track of the various programs. They do not actually modify the programs themselves but rather how information is collected from them. Modification of the security tool options happens elsewhere, either directly with the configuration files, through the Webmin interface, or with a frontend for the tool.

The information collected can come from sources that are based on either interrupts or polling. An interrupt style would involve the dynamic updating of the MAST database as events happen, as is the case for example with Snort's alerts or if a module were to report in real­ time if certain files were modified. A polling style could be the file integrity checker, collecting information from event logs, running a series of system checks, or running a vulnerability

assessment tool periodically.

The easier of the two is through polling. Most of the security programs are capable of

logging their results to a file or being run from the command line and producing their output.

The output on the command line or in the log file can then be parsed for integration into the

MAST database.

Interrupts are more problematic because they potentially require modification to the code

of each program. For example, the network monitoring software must know that it should

update the MAST database with alerts as well as logging everything else to its own database. 19

The system monitoring application would have to insert critical system events to the database as well instead of just keeping a log, e-mailing the admin, or any of its other actions. Reviewing the contents of syslog periodically would be easier but not as secure unfortunately.

2.2.2 Analysis

Instead of making the analysis portion of MAST an integral part, leaving it as a module allows greater flexibility in the kinds of artificial intelligence and intrusion detection methods that are used. Modules can have dependencies in this manner and work between each other.

The task of finding artificial intelligence algorithms which are efficient at detecting problems and intrusions is not an easy one and will receive continual development.

The continual development could happen within the MAST codebase itself but that would prevent the testing of alternative methods over time. A modular approach allows security experts to test multiple hypotheses on the best way to analyze the data and select the module that best fits the needs.

There are active and passive approaches to doing analysis within the MAST system. Active rules are triggered immediately when the database is updated. These kinds of triggers could be things like unauthorized logins, network attacks, or other critical events. Passive rules are checked less frequently and are used for the sake of post-event analysis. These rules could concern things like anomaly detection, time between logins, and matching up events between databases.

2.2.3 Alerts

The MAST alert system has several important design considerations. When plugins are developed they will need to interact properly for the best use of alerts.

2.2.3.1 E-mails

Each security tool generally has some ways of informing the security administrator of problems. One of the common ways is to e-mail an alert as soon as it happens so that the 20 administrator can react to it. However, if each tool does its own implementation in this regard it would be grossly inefficient and hard to maintain.

There are several issues with having each program do its own reporting. The main one is the difficulty of implementing the mechanism with each program. Only a few of the major security tools are set up to use e-mails and there are the configuration hurdles of whether to use sendmail, postfix, how often to send e-mails, and so on. Just reporting the results to standard output or log files is generally more convenient.

The other issue with having multiple programs is that updating e-mail setups and addresses requires going through each of the programs. Instead of changing the contact e-mail in one central location, each program must be configured independently to use that contact address.

Such a system is clearly prone to error and misconfigurations.

2.2.3.2 Triggers

If the security modules are not responsible for distributing their own alerts, the next ques­ tion becomes how MAST will be capable of determining when to send them. The answer lies in the configuration of each security tool plugin for MAST and how it interacts with the database.

When information is collected from each program's critical events that data is flagged with high, medium, and low importance. The high importance events would get sent to the security administrator immediately based on the settings, while the medium and low entries may or may not be depending on the administrator's preferences. The warning levels can be more fine-tuned for various scenarios and that depends on the use of the plugin.

There is another important advantage to having centrally managed alerts. Each individual security tool may not have found any high importance alerts. Through a correlation of many low and medium level alerts, however, a high level alert could be produced. Such a situation would be missed by any of the other tools on their own. 21

2.3 Plugin architecture

The plugins for each security tool to integrate with MAST are not necessarily a part of the

MAST code but rather patches to each security program. For example, the Snort code would be patched so that the alerts not only go to its own logfiles but also to the centralized MAST database. Each program group must be analyzed in order to determine if this approach is appropriate and which areas of the program to patch.

The patching process introduces a potential problem with future program updates. When some of the architecture is changed there might be parts of the plugin that no longer work. To avoid this problem the easiest method is to simply work with the developers of the software program. The developers of free software tools generally would like their program to be dis­ tributed and used as widely as possible. By having an additional way for their tool to be used they are increasing the overall usage of their software.

The programs that are easiest to integrate with on the fly are the ones that are run from the command-line and direct their reports to standard output. Such programs may completely change their architecture but are generally consisent in how they are called. Even if their calling criteria are changed it would simply be a matter of changing a few flags here and there.

The alternative to patching the program is to have a separate program that analyzes their output. The output of the various programs is usually stored in their database, configuration files, log files, or reported to the system event log. A plugin that relies on these outputs would not necessarily be as timely in its udates but would at least work. This kind of solution is generally the only one available with closed-source programs.

2.4 Database layout

Although it is collecting information from various programs the MAST database does not have to be large. The information it is collecting concerns just the alerts and therefore does not have to include all the additional information that the programs could potentially provide.

There are two main approaches to organizing the database. Each one has advantages and disadvantages when it comes to integrating the various security tools. 22

2.4.1 By program

The easiest way to configure the layouts is to use a table schema that is tailored to each individual program. The reports generated by the program are matched up with fields within the MAST database one to one. Such a solution makes implementation details easier by not having to change or rearrange any of the output from the programs.

2.4.2 By type

A more flexible but difficult to set up layout would be to have table schemas defined by application type. No matter which NIDS is used, for example, the alerts would all use the same fields. The file integrity checker would have to report violations in the same way for any file integrity checking program that is used.

One of the challenges with this approach is that a common fixed framework would have to be defined in order to satisfy the different programs that could be used for a certain type of program. Determining that framework would take research, would be less flexible, and would require the plugins to tailor themselves to that architecture.

The disadvantages are offset by the level of consistency within MAST. No matter which firewall program was used, for example, the analysis engines could be the same every time without having to worry about which specific firewall was being implemented. The same goes for any other program.

Before worrying about making the types of programs universal, however, it would be best to at least get some of them in a working implementation. When alert types become an IEEE standard then it might be more relevant to start making programs interchangeable.

2.4.3 Program analysis

The best way to determine the feasibility of the MAST setup is to analyze how it would function with the different security tools currently available. The following chapters will go through a few of them and show how they can be integrated both with the Webmin modular administration system and the MAST database configuration. 23

Currently Webmin is not designed for Windows. Many of the design principles would still apply though and the only difference would be configuring the programs through other means than Webmin. Webmin is simply one of the better modular configuration setups to get things done in Linux. 24

CHAPTER 3. File monitoring

Being able to verify the integrity of files on the computer is very important. The change monitoring solutions currently available attempt to establish the security of computer systems and the reliability of information. By monitoring the changes on the systems compliance can be proven for the sake of government regulations in addition to internal policies and customer privacy.

3.1 Programs

The concept of file integrity checking is rather simple. Calculate the MD5 hash value of various files on the computer and compare them with the values stored in the database to see if they match. When they do not match, the files must have been change and could possibly mean a compromise. The programs below add additional features to this simple concept in order to make themselves more useful and practical.

3.1.1 Tripwire, Inc

One of the most well-known file integrity checking applications is Tripwire. Version 2.2.1 of Tripwire was released under the GNU Public License (GPL) in October of 2000 and was developed shortly at Sourceforge.net until the last version of 2.3.1-2 in March 2001. Since then Tripwire, Inc has turned into a company that provides change auditing solutions to companies and focuses on maintaining provable compliance with government regulations such as Sarbanes-Oxley and HIPAA.

Unfortunately most of Tripwire, Inc's white papers concern the importance of change ac­ countability rather than discussing any technical features of the commercial Tripwire program 25 itself. From the online demonstration of the Enterprise edition it seems that the program chiefly concerns itself with making policies concerning file changes and monitoring those changes re­ motely on many different computer systems.

Some of the problems that are not discussed in Tripwire's marketing materials are how computer authenticate to each other for the purpose of sharing file integrity information and what a compromised computer may report about itself to the central server. These are crucial problems in the realm of file integrity checking along with concealed files and misreported file data that is different between reading and actual execution. The Tripwire program seems to be mainly a networkable and user-friendly version of its open sourced tripwire program. The program also seems to have helped companies maintain and show compliance with government regulations, an area that Tripwire, Inc has spent more time researching.

Fortunately there are other open-source projects that have stepped in to fill the void.

3.1.2 13FS

In-Kernel Integrity Checker and Intrustion Detection File System (or I3FS for short) is an on-access intrusion detection file system that checks the integrity of the file system in real time

(4). The project is intended to be an overall intrusion detection system by having alerts for changed files. The speed drop for including the checks was found to be only about 4%.

Making the integrity checking a part of the kernel filesystem makes it less vulnerable to attacks that could be carried out against user-level utilities. The prototype software that they developed works as an extension for the Linux kernel. Instead of using an outside SQL database though the checksums and policies are stored in four different in-kernel Berkely databases.

In order to function with an overall security system that also tracks viruses and network intrustions the code would most likely need to be changed so that the information is stored in the same overall database.

Since the software is mostly beta quality it may not be the best one to use at this point. 26

3.1.3 AFICK

Another File Integrity ChecKer (AFICK) is a more practical application at the moment because it is capable of running on several different operating systems and has received more testing (5). It runs on any computer that can handle Perl and some standard modules.

AFICK currently uses the sdbm database for storage though this could be changed to SQL to match the rest of the applications. The only downside would be having a mixture of Perl and C code in the implementation of the project.

3.1.4 Samhain

The Samhain file integrity checker seems to have the best features out of the open-source products that are available (6). It supports many different file aspects, is written in C, and is already capable of logging to relational database systems such as SQL. As a standalone application there is also a frontend to the program and a way to have centralized monitoring and management of computers running Samhain. Its only downside is that on Windows it has to run through a Cygwin PO SIX environment.

A 2004 article from Linux Magazine also concludes that Samhain is one of the file integrity checkers with the greatest number of features and reliability (7).

3.2 Webmin module

Samhain by Rainer Wichmann is currently the most practical choice for file integrity check­ ing using a relational database management system. Since it does not have an easy to use

Webmin module one would have to be developed.

Samhain can be used either as a standalone client or as a client/server module. The client/server setup must be used if the results are to be logged to a database. An alternative to using the server for a single host is to parse the output of running samhain but that would make using some of the features more difficult.

The client executable is 'samhain' and the server is 'yule'. They must be compiled sep­ arately and with different paths/names so that they do not conflict with each other. The 27 configuration file for samhain is in /etc/samhainrc, the log file at /var/log/samhain__log, and state data at /var/lib/samhain.

One of the biggest problems with samhain at the moment is that most of the features cannot be dynamically changed. A recompile is needed in order to enable additional features or disable others. Most of these should really have been in the /etc/samhainrc file rather than having to recompile each time. Some of the compile time options are listed below.

• enable-network: Compile with client/server support.

• enable-udp: Enable the server to listen on port 514/udp (syslog).

• enable-srp: Use SRP protocol to authenticate to log server.

• with-gpg=PATH: Use GnuPG to verify database/config.

• enable-login-watch: Watch for login/logout events.

• enable-stealth=XOR_VAL: Enable stealth mode, and set XOR_VAL.

• enable-micro-stealth=XOR_VAL: As with-stealth, but without steganographic hidden

configuration file.

• enable-nocl=PW: Enable command line parsing ONLY if PW is the first argument on

the command line.

The other available options include things such as changing folder prefixes, including the logserver address, enabling xml mode for the log file, and so on. The only reason to have these be compile time options is if that helps security by preventing changes to the configuration text file. Otherwise the main feature that would have to be compiled in is the cloaking of the application name and associated files.

If a Webmin module were to support changing the features that are done at compile time it would have to be able to re-compile and install the application on the fly. Such a task might not be so bad for such a small program that has very few dependencies.

3.3 MAST plugin

Samhain is generally run by executing a check, initialize, or update command. 28

Table 3.1 Layout for file integrity checking

I Field File path Original signature Detected signature Date found Scan type User owner Group owner Created Modified Permissions Action taken

• Initialize database: samhain -t init

• Check files: samhain -t check

• Run as daemon: samhain -t check -D

• Report to log server: samhain -t check -D -e warn

• Start the log server: yule -S

The client-server connection is secured with the Secure Remote Password (SRP) protocol.

A plugin for Samhain could take several different forms. As with many software projects there is more than one way to run an algorithm.

The easiest way is to use the provided Yule server and change the database connection options to point to the right database and tables. The existing samhain codebase would not change in the least and all the features would still be available. The only issue is that an additional daemon, yule, is required to run in that case.

To avoid having to run yule there would have to be changes to the samhain code itself so that it is capable of logging to the database on its own. Such work would probably not be as beneficial because re-implementing the database insertion code would cause difficult software updates to samhain every time a new version comes out. Using the existing client/server setup would probably be better. 29

A compromise approach is to handle the timing of samhain runs outside of samhain itself by running samhain in 'foreground' mode. Such a method requires additional plugin code to be written in order to schedule samhain runs, parse the output, and insert the data. This method could be useful to maintain easy compatibility with future versions of samhain without having to rely on a potentially buggy or discontinued yule server.

The database values for the integrity checking alerts are given in table 3.1. 30

CHAPTER 4. Antivirus integration

Some programs and files are known to have malicious content. These kinds of files can be proactively scanned for and eliminated from the computer. Software that removes malicious software can look for viruses, worms, trojans, and spyware. There are many companies involved with this field since viruses are a very common problem for desktop users.

4.1 Programs

Out of the anti virus and antispyware field there are several commercial solutions and a few free ones. The open source solutions have a greater likelihood of being inexpensive, standards­ based, and easier to integrate with an overall database. Another big advantage is that they cost nothing and can be distributed without licensing problems.

4.1.1 Clam antivirus

ClamWin Antivirus received the Slashdot February 2005 Project of the Month award and is one of the leading open-source antivirus solutions. The Clam Antivirus project has a database of 31,000 viruses, worms, and trojans according to their site. ClamWin is simply a front-end to the virus scanning engine from Clam AV.

The windows version comes as a pre-compiled binary for ease of use considerations. The source code for all components is available however which makes modifications easier.

Currently the Windows version is not capable of doing on-access virus scanning m the same way that McAfee and other companies do. The Linux and BSD versions support on­ access scans though. Through the integration with the file monitoring utility that could change though. 31

There are two main problematic aspects of integrating this antivirus program with an overall monitoring solution. The first one involves getting the results away from reports that are saved to disk and migrated to a system where they are saved to a database directly. Within

Linux they can be saved to the event log but this is still not as proactive as actually placing them in a database.

The second main integration problem is in compatibility with updates. If the developers themselves do not have database compatibility then future updates to the engine or definitions might break a modified version of the virus scanner. Therefore the scanning engine and the virus definition updates should be kept clearly separate, which they usually are with virus scanners. The updates to the overall security solution would then go through the Clam AV site for updated definitions on a daily or some other regular basis.

One way to solve the problems is to use the command-line version of the scanner and read its output as described in the documentation. This would ensure the greatest levels of compatibility over time without having to rewrite portions of Clam AV.

Clam Antivirus has a list of about 100 companies that use their product in a production environment. Among the universities, companies, and other institutions are DynDNS and

Sourceforge.net. The widespread use of the product helps ensure that the releases are of a good enough quality to support these organizations and that new virus definitions are added frequently based on user experiences.

4.1.2 Commercial options

Network Associates, Symantec, and Trend Micro are the leaders in commercial antivirus products. In a 2002 Gartner evaluation of the market leaders in auditing and integrity man­ agement these vendors were found to be on top of the rest. Computer Associates, F-Secure, and Sophos were found to be somewhat lacking in the ability to execute solutions.

Each of these three top companies is also a partner with the U.S. Army for the sake of providing security solutions of military member owned computers. Accounts at the Army

Knowledge Online website provide the capability of downloading antivirus applications and 32 firewalls from these vendors.

The challenge is being able to integrate the ready-made solutions with third party databases and applications. The programs are often highly customized to work with ePolicy Orchestrator or other mechanisms of computer management. Getting the virus scanners to integrate with an outside managing application might be difficult and would probably involve either parsing the log files periodically or somehow running the antivirus portion effectively from the command­ line. Unfortunately, none of the most recent tools is designed to work as effectively from a command-line as they do from the embedded GUI. Compatibility between each other in terms of formats and management would not improve their lock-in from companies for an overall suite of applications.

4.1.3 F-Prot

F-Prot antivirus is a commercial product that supports several different platforms. There are versions for Windows, Linux, BSD, Microsoft Exchange, Solaris SPARC/x86, IBM AIX, and DOS.

In the same way as ClamAV, F-Prot is usually run from the command line and prints information to STDOUT. Therefore the same kinds of migration issues would occur with F­

Prot as it does with ClamAV. Some kind of parser would need to be created for the sake of integrating F-Prot with an overall security solution. The potential advantage with such a commercial product is that Frisk Software International might provide better support, software

updates, and customized packages than would a free software solution.

A big disadvantage with F-Prot however is that the commercial licenses can cost up to $300

per computer. Workstations are generally $30 per computer but this would still end up being

a lot considering that it is just one part of an integrated security solution. Other companies

such as McAfee and Symantec have established a greater reputation for themselves.

F-Prot seems to be more geared toward servers and e-mail scanning than McAfee and some

of the others. They do not claim any protection from spyware at this point unfortunately. 33

4.1.4 Spyware

With the increase in problems with viruses and spyware there are many companies which have started advertising their products and solutions. Some of these are in fact spyware themselves under the guise of legitimate software. Without doing background research into some of them it is very difficult to determine which ones are legitimate or not. Many of them are more geared toward the problem of spyware than of viruses in general.

Spyware Doctor received a 5-star rating from CNet. The average user rating is only 3.5/5 though and one of the main reasons is that the program is more of a trial version than free with lots of advertisements integrated. Advertising a program as free followed by having many advertisements and enticements to purchase more is a common tactic in the computer software field.

There are also common freeware programs such as AdAware and Spybot Search and De­ stroy. Each of these is capable of rooting out many of the common viruses based on their database of known spyware programs. Running multiple spyware removers is often necessary before getting rid of all of them. There are sometimes cases when work has to be done manu­ ally in order to remove all of the offending material since automated tools can only go so far in finding the cause of the problems.

4.2 Webmin module

In companies that are locked in with a certain security solution provider there might be a use for parsing logs from the antivirus suite. However, since they are less flexible and more expensive than the free alternative provided with ClamAV, as part of an overall computer integrity solution they do not make as much sense. Being able to receive continual updates from the security community while also potentially making source code changes is a huge advantage that places ClamAV above the others for the sake of security projects such as this one.

ClamAV has very few important pre-compile options. Almost everything is controlled from the configuration file at /etc/clamd.conf. The main important configuration option involves 34 compiling clamav for multiple architectures, which could be useful for binary distributions rather than using the source code each time.

The clamav-milter addition allows the antivirus application to be run against e-mails for security. The configuration options are not for clamav-milter itself but rather in the

/etc/mail/sendmail.mc file where additional lines need to be added to support the filter.

4.3 MAST plugin

The command-line programs clamscan and clamdscan are able to scan entire directory structures. The clamd daemone itself just runs in the background and follows the options listed in the configuration file. The freshclam updater gets the latest virus definitions from online and can run either interactively or as a periodically checking daemon.

4.3.1 Analysis

The clamav application is very simple. It is only designed to check for viruses and nothing else. The virus database is the important part of the program that receives a lot of attention

and development. The rest is suitable for integration with other programs or as a regular

command-line scanner.

As such there is not even any database integration by default. There is, however, a libcla­

mav library that allows for including antivirus features into another program. Frequently this

is used for e-mail scanning programs used to eliminate viruses.

As a plugin to MAST, the goal of clamav would be to verify that none of the files on the

computer are infected with viruses. As such only the simplest functionality would be needed.

Running clamdscan periodically on the necessary files, parsing the output, and logging to the

event log would be all that is needed to make clamav a part of the MAST system.

The output from clamscan where it outputs everything to -stdout could be as follows from

the documentation.

/tmp/test/removal-tool.exe: Worm.Sober FOUND

/tmp/test/md5.o: DK 35

Table 4.1 Layout for antivirus reports

Field File path Virus name Date found Scan type User owner Group owner Created Modified Permissions Action taken

/tmp/test/blob.c: OK

/tmp/test/message.c: OK

/tmp/test/error.hta: VBS.Inor.D FOUND

The virus name is printed between the filename: and FOUND strings, which makes it very easy to parse through. For the sake of analysis with the rest of the database, other information about the virus which would be good to have include knowing when the file was created, who owns it, when it was last modified, and what the permissions on it were. As such the plugin would insert into the database the relevant information concerning each of these when a virus is found.

4.3.2 Table layout

When viruses are found it is useful to determine more than just the filename. Looking

at the last accessed times and so on would help correlate with events from the rest of the

database. Table 4.1 shows what the database should contain. 36

CHAPTER 5. Network integration

Almost all computers must connect to an outside network in order to be effective. This ranges from web, print, and file servers to workstations that people use on a daily basis. The ability to track down malicious network traffic from the computer's perspective is an important asset that supplements what would be possible with network intrusion detection.

5 .1 Programs

There are two important aspects of firewall integration. A firewall is a filter for network traffic that only allows some of it through based on certain rulesets. It can be located on the network at a gateway or other critical point in order to safeguard the computers within the network. In this case, however, the firewall will be considered mainly from the host's perspective where it is the last line of defense before the applications on the computer receive input from the network.

The other important aspect is being able to monitor the network for unusual or malicious activity. Again, this can be done from the outside with monitoring devices on the network looking for inappropriate network traffic. For this system the host-based network monitoring applications will be looked at.

5.1.1 Network intrusion detection

In the network intrusion detection systems (NIDS) realm one product stands above the rest: Snort. This program has become the de facto standard for NIDS thanks to its open source nature, constant development, and the amount of documentation and books that have been written on it. 37

5.1.1.1 Snort

The Snort Intrusion Detection System (IDS) is already capable of recording its results to a MySQL database. This places it in a good position for integration into a larger system.

Sourcefire is the company founded by the creator of Snort, Marty Roesch, in 2001. Frost

& Sullivan awarded Sourcefire the 2005 Network Security Infrastructure Protection Company of the Year Award. This was "in recognition of its unique product strategy, significant devel­ opments in related network scanning technology, and its achievement in gaining a significant market share against well entrenched competitors through its innovative business model."

Sourcefire's core technology is still actively maintained and updated by open source de­ velopers. The additional services provided by Sourcefire only serve to enhance the general useability of Snort and provide support for the products in the commercial and enterprise realm.

The basic version of Snort would therefore be a very good candidate for use on a host computer. Many researchers continue to use it for testing NIDS capabilities (23).

5.1.1.2 Frontends

There are several additional tools that make reading the output from Snort somewhat easier. A popular open-source frontend is Basic Analysis and Security Engine (BASE) (14).

The code from this project is based on one of the initial analysis engines from Analysis Console for Intrusion Detection (ACID) which has not been updated since January 2003 (15). BASE is written in PHP for use on a webserver that can display and update information about the network monitoring. The entire system can be installed easily on Windows as well as described by Steele (16).

5.1.2 Firewalls

The translation of network intrusion detections to firewall rules is an important step that is not so easy to handle. Most Network Intrusion Detection Systems (NIDS) are passive and simply monitor the kind of traffic that is going through for later review and alerts. Being 38 able to actively monitor and block certain traffic on the fly is more complicated and requires a certain level of assurance that the blocks will be appropriate. If the system is not set up properly then false alarms could inadvertently bring the entire network down.

5.1.2.1 Linux

On the Linux side there is the time-tested IPTables for Linux kernels 2.4.x and 2.6.x. It is based on netfilter, is an upgrade/rewrite of ipchains, and allows packet filtering, Network

Address Translation (NAT), and packet mangling (17). The fwsnort project (18) is capable of taking Snort IDS rules and turning them into IPTables rulesets. Articles from linuxsecurity.com

(19) and SysAdmin magazine (20) have covered how to use fwsnort effectively on a Linux computer.

5.1.2.2 Windows

Unfortunately there is not an equivalent, solid firewall solution for Windows. The built-in

Windows firewall that comes with Windows XP has only rudimentary support for rulesets and

cannot handle network address translation, conditional rules, and other complicated tasks.

Neither has it been very well integrated with intrusion detection applications in the same way

that IPTables has.

While there may not be outstanding solutions for servers and gateways, there are a few

decent products where personal firewalls are concerned. These could integrate with the host­

based computer monitoring application mainly through the use of their log files. The top

players in the firewall field do not have any open source products.

Some of the common firewalls are BlackICE, Sygate Personal Firewall, ZoneAlarm, Syman­

tec Norton Personal Firewall, Tiny Personal Firewall, and McAfee Personal Firewall. However,

hardly any of these would be suitable for a server application as noted by Mark Burnett of Se­

curityFocus (21). One of the main complaints is that under large amounts of server traffic the

firewall could cause the computer to blue screen. Besides, many of the firewalls have pop-up

windows that would be unacceptable for a largely unattended computer. 39

5.2 Webmin module

There are some very good NIDS and firewall applications for Linux that are already ready for deployment. Unfortunately the Windows situation is all right for network monitoring but still needs a lot of progress before having a good server firewall solution. The current firewall offerings would have to be tailored by hand to match the rules found from the network monitoring portion of the project.

Snort has a configuration utility but it has not been updated in the last four years since

2001. As such it is probably no longer reliable and would have to be updated. The tools such as Analysis Console for Intrusion Detection (ACID) and Basic Analysis and Security Engine

(BASE) are frontends more for the analysis of the results than for any kind of configuration.

Generally speaking, the default configuration could probably be all right. However, some of the options would most likely need to be tweaked for an expert administrator to get the kinds of alerts needed with all the necessary information.

The snort configuration files reside in the /etc/snort/ directory with snort.conf being the chief among them. The Webmin module would have to provide an interface with explana­ tions for the snort options and a convenient way to change them. Other locations for snort configuration options are in /etc/sysconfig/snort and /etc/rc.d/init.d/snortd . These other two determine how snort is started as a service and what the command-line options for snort should be. Since the command line overrides the snort.conf file they could be important to change as well. Various Linux distributions may change where they store these files though so it might be more complicated for the Webmin module to locate and modify them.

Most of the Linux firewalls already have Webmin modules so that is not a problem.

5.3 MAST plugin

Snort alerts can already be stored into a database and it supports MySQL among others.

There are a number of tables for configuration but only a few of them are relevant for the sake

of integration with the rest of the system. Table 5.1 shows the fields that would be important

for the sake of matching up with the other reports. The Reference ID is for the sake of matching 40

Table 5.1 Layout for Snort reports

Field Timestamp Attack type Source IP Destination IP Source port Destination port Protocol Reference ID

Table 5.2 Layout for firewall configuration changes

Field Timestamp Block type Protocol Source IP Destination IP Source port Destination port Explanation

up with the original Snort database if more information about the packet is needed, such as

TCP /IP flags and payload.

On the firewall side it would be less of a monitoring issue and more of a way to apply

configurations based on intrusion detection monitoring. As network intrusions are detected

certain IP addressses could be blocked for example or ports closed if they appear to have a lot

of unauthorized traffic.

Storing the entire configuration within the MAST database would not be very efficient,

however. There are a variety of rule types and forwarding mechanisms. The IPTables configu-

ration files are notoriously difficult to get right for example. The plugin for the firewall would

be better off as a mechanism to send updates to the firewall in terms of blocked IPs and that 41 sort of thing. The interface would have to be standardized so that no matter which firewall is used, the language and update mechanism would remain the same.

Generally speaking the changes to the configuration involve blocks. A good table layout for the blocking situation with firewalls is given in table 5.2. 42

CHAPTER 6. Additional applications

The beauty of a modular architecture is that any other programs can easily be added to the security system and still retain the ease of use and functionality. There are security scripts, vulnerability assessment scanners, file access checks, and many other potential security tools that could be integrated with the overall security console.

6.1 Analysis

The previous chapters covered examples from the realms of file, virus, and network moni­ toring. One of the other important modules could be parsing through the event log.

The operating system itself keeps track of many events in event logs. A computer user can change the configuration somewhat in order to select the types of events that are logged.

Within windows the system logging capabilities are defined through the local security policies and several options. In Linux almost any program with the right privileges can enter things into the system log at /var/log/syslog.

Simple Event Correlator (SEC) is a replacement for swatch and logsurfer that is also capable of correlating events from HP OpenView, CiscoWorks, and others. Several studies have been written about using SEC to analyze log files (24; 25; 26). SEC would be a prime candidate for an event log module.

The first step in selecting a new module is making sure that it adds something valuable to the security system. Clearly in the case of a log analyzer there are some benefits from having an expert system that looks through the log files. Only anomalies and potential problems are reported.

The next steps are making sure that the program can integrate well with a database of other 43 security alerts and has a decent configuration tool. Using a Webmin module for configuration would help ensure consistency with all the other security modules.

6.2 Normalizing across applications

Often there are many different programs that provide the same kind of functionality. Fire­ walls, antivirus products, and file integrity checkers are just a few examples of areas that have many tools developed already. In an ideal situation, rulesets written for one tool would be just as useful when applied to a different tool without having to rewrite the code and configu­ ration options. Unfortunately such a situation is rarely the case as each program implements customized features and different ways of defining rules.

Having a common configuration and management language for each category of programs would allow switching out between vendors with ease or running MAST in an environment where more than one firewall or integrity checker is being used. Mixed environments with both

Linux and Windows would be one area where such flexible rulesets would be useful. When an attack is found on one system applying changes to all of the potentially affected systems becomes trivial.

Such a normalized setup is a potential feature of using MAST but is not a requirement.

In the meantime the patches could provide some level of normalization and translation from one rule style to another. Once some of the rulesets become de facto standards then it is more likely to become an IEEE standard later on for some of the application categories.

6.3 Related products

So far security tools have remained in their own areas of expertise. There are the network intrusion detection systems, file integrity checkers, log monitors, and so OIL A few programs have gone the extra step and embraced various security concepts, such as the offerings by companies like Tripwire, Inc, McAfee, Symantec, and others. However, they are unable to

leverage the expertise from many other security tools at the same time and instead have to

develop many of their products in-house. Sometimes these products are of high quality but 44 they rarely cover every possible security angle.

6.3.1 Nagios

Nagios (27) is a host and service monitor that is capable of monitoring many different aspects of the computer through plugins. These plugins are for the sake of monitoring things like temperature, program status, disk load, CPU load, and so on. However, this information is more for the sake of verifying uptime than to detect and react to security breaches. The plugins could be configured to work with security tools but the overall architecture is not designed to work that way.

6.3.2 Entercept

McAfee's Entercept (11) is an enterprise host and network based Intrusion Detection and

Prevention System (IDS/IPS) that has various agents for desktops and servers. There are

behavioral rules, signatures, and process blockers as part of the system in order to prevent ma­

licious activity. The downside is the high cost of deploying such a system and the fact that very

few of the specs and methods are published for the sake of protecting their intellectual prop­

erty. From the advertisements that they call white papers it looks like the security monitoring

possibilities are more limited but that overall the system is rather stable and scaleable.

6.3.3 Webmin

Webmin itself could be considered the solution to the modular architecture. In this research

it has been considered a part of the solution but not the entire resolution. The biggest reason

that it doesn't fit all the criteria is because modules are considered to be mostly separate and

usually do not interact with each other. An additional application, even if it is within webmin,

would be required in order to pull together the various pieces of information from each security

tool. 45

6 .4 Related research

A few other research papers have looked at the problem of coordinating various other intrusion detection mechanisms. They have looked mainly at the effectiveness of integrating two or more IDS systems for the sake of having better alerts and more accurate intrusion models.

One of the ways to simplify the security administrator's job and have more accurate alerts is to combine alerts from various sources. In the paper by Valeur, Vigna, Kruegel, and Kemmerer

(28) a method of combining these alerts effectively is looked at. In particular, the alerts from each IDS source must be normalized, pre-processed, verified, and analyzed for its impact before becoming part of the intrusion reports that go to the security administrator.

The goal of the project, however, was mainly to reduce the number of alerts going to the security administrator by combining related events into overall summary alerts. The quality gain of the overall application was not looked at as much, or the ability to add and remove data and analysis modules easily, or have automatic responses based on configuration. The biggest drawback was that functionality was not shared across application boundaries.

6.5 Future work

This research has identified the need for, layout, and implementation feasibility for a global security framework. Implementing such an ambitious security architecture will require much work over time in order to integrate the most possible number of good security tools. The development of the MAST setup can be divided into three steps.

6.5.1 Plugin development

The analysis of security information cannot occur until there is at least some information stored in the MAST database to begin with. Developing plugins for some of the major security tools would help create the foundation for further work in the area of results analysis.

The tools already discussed were in the areas of integrity checking, antivirus, and net­ working. These security applications would make good starting points for development and 46 implementation.

6.5.2 Data analysis

Once the information is collected in the MAST database then it can start being summarized and analyzed. When the security alerts are good enough on their own the analysis will not even be necessary some of the time. When the security alerts are at lower levels and not really critical, however, relationships between them can reveal critical problems overall.

6.5.3 Configuration management

One of the difficulties with having many security tools is that they become hard to manage

and configure. By having the appropriate Webmin modules in place it would be possible to

take care of all the applications from one location.

6.6 Measuring success

The goal of MAST is to make a security administrator's job easier and make possible

the development of more advanced security tools. If even a few programs have plugins for

MAST then that part of the goal can be considered achieved. Individuals and companies can

determine whether or not the program is helping them achieve their security goals from a

practical standpoint.

A common way to test new alert correlation techniques is to use attack data sets and

compare the correlation results to the various other programs that have already been used.

However, MAST is the architecture that allows different analysis methods to be used, not the

analysis method itself. Therefore such test results would reflect on the strength or weaknesses

of various algorithms used rather than on MAST itself.

The true determining factor of MAST's success is how much progress it helps make in the

realm of open-source security tools. In the short term it simply has a Sourceforge project

established and some initial plugin development. Once it reaches a critical mass of users, 47 security tool developers will start designing their programs with MAST integration in mind and use some of the more advanced features that it can provide.

Fortunately the use and development of MAST by others is not a requirement for it to work well. Even if only one individual or company uses and develops it, there will be benefit for that particular company and possibly some bug fixing for some of the security tools being used. Determining the future popularity of a program can be rather difficult and unpredictable.

\Vhen products must be popular to be useful they lose some of their guaranteed appeal. The

MAST project is useful in its own right and simply needs the development time of at least a

few individuals.

6. 7 Conclusion

The MAST project holds great potential for the integration of many different security tools.

Writing the modules for each of these tools may take some time but will help security become

that much easier to handle for all security administrators. The ease of creating additional

modules may even encourage the development of different and better tools that can fit into

the larger framework. 48

APPENDIX. MAST database

The following SQL commands create the tables for file monitoring, antivirus, network monitoring, and firewall.

SET AUTOCOMMIT=O;

START TRANSACTION;

Table structure for table 'antivirus'

CREATE TABLE 'antivirus' (

'File path' varchar(255) NOT NULL default '',

'Virus name' varchar(255) NOT NULL default '', 'Date found' datetime NOT NULL default '0000-00-00 00:00:00', 'Scan type' varchar(64) NOT NULL default'', 'User owner' varchar(64) NOT NULL default'',

'Group owner' varchar(64) NOT NULL default '', 'Created' datetime NOT NULL default '0000-00-00 00:00:00',

'Modified' datetime NOT NULL default '0000-00-00 00:00:00', 'Permissions' smallint(6) NOT NULL default '0', 'Action taken' varchar(255) NOT NULL default'', PRIMARY KEY ('Date found' ,'File path'(128),'Virus name'(128))

) TYPE=MyISAM; 49

Table structure for table 'firewall'

CREATE TABLE 'firewall' (

'Timestamp' datetime NOT NULL default '0000-00-00 00:00:00',

'Block type' varchar(255) NOT NULL default ''

'Source IP' int(11) NOT NULL default '0', 'Dest IP' int(11) NOT NULL default '0',

'Source port' smallint(6) NOT NULL default '0',

'Dest port' smallint(6) NOT NULL default '0',

'Protocol' varchar(8) NOT NULL default'',

'Explanation' varchar(255) NOT NULL default''

PRIMARY KEY ('Timestamp' ,'Source IP' ,'Dest IP')

TYPE=MyISAM;

Table structure for table 'nids'

CREATE TABLE 'nids' (

'Timestamp' datetime NOT NULL default '0000-00-00 00:00:00',

'Attack type' varchar(255) NOT NULL default''

'Source IP' int(11) NOT NULL default '0',

'Dest IP' int(11) NOT NULL default '0',

'Source port' smallint(6) NOT NULL default '0',

'Dest port' smallint(6) NOT NULL default '0',

'Protocol' varchar(8) NOT NULL default '',

'Reference ID' varchar(32) NOT NULL default '' 50

PRIMARY KEY ('Timestamp' ,'Attack type'(128),'Source IP' ,'Dest IP')

) TYPE=MyISAM;

Table structure for table 'samhain'

CREATE TABLE 'samhain' (

'File path' varchar(255) NOT NULL default'',

'Original signature' varchar(128) NOT NULL default ''

'Detected signature' varchar(128) NOT NULL default ''

'Date found' datetime NOT NULL default '0000-00-00 00:00:00',

'Scan type' varchar(64) NOT NULL default '',

'User owner' varchar(64) NOT NULL default '',

'Group owner' varchar(64) NOT NULL default'',

'Created' datetime NOT NULL default '0000-00-00 00:00:00',

'Modified' datetime NOT NULL default '0000-00-00 00:00:00',

'Permissions' smallint(6) NOT NULL default '0',

'Action taken' varchar(255) NOT NULL default ''

PRIMARY KEY ('File path' ,'Date found')

TYPE=MyISAM;

COMMIT; 51

BIBLIOGRAPHY

[1] Webmin: A web-based interface for system administration for Unix. Available http:

//www.webmin.com/ (retrieved 20 March 2005).

[2] Network Associates, Inc. Software Wrappers. Available http: //opensource .nailabs.

com/wrappers/ (retrieved 23 Mar 2005).

[3] Kolodgy, Charles. Infrastructure Integrity. White paper, available http://www.

tripwire.com/files/literature/white_papers/Infrastructure_Integrity_IDC.

pdf (retrieved 25 Mar 2005).

[4] Swapnil Patil, Anand Kashyap, Gopalan Sivathanu, and Erez Zadok (2004). I3FS: An In­

Kernel Integrity Checker and Intrusion Detection File System. 18th USENIX LISA Con­

ference 2004, 67-78. Available http://www. fsl. cs. sunysb. edu/project-i3fs .html

(retrieved 25 Mar 2005).

[5] Eric, Ger bier. Another File Integrity ChecKer. Available http: I /af ick. sourceforge.

net/ (retrieved 25 Mar 2005).

[6] Wichmann, Rainer. Samhain Labs home page. Available http://la-samhna.de/

samhain/ (retrieved 25 Mar 2005).

[7] Loschwitz, Martin. Projects on the Move. Linux Magazine, April 2004 pages 87-

89. Available http://www. linux-magazine. com/issue/41/Free_Software_Projects.

pdf (retrieved 26 Mar 2005). 52

[8] Kojm, Tomasz. Clam Antivirus. Available http: I /www.clamav.net/ (retrieved 26 Mar

2005).

[9] Cherney, Alex. ClamWin Antivirus. Available http: I /www.clamwin.com/ (retrieved 26

Mar 2005).

[10] Frisk Software Intl. F-Prot Antivirus. Available http://www.f-prot.com/ (retrieved 26

Mar 2005).

[11] McAfee. Host and Network Intrusion Prevention. Available http: I /www.

mcafeesecuri ty. com/us/locaLcontent/whi te_papers/wp-1l.ost_nip. pdf (retrieved 26

Mar 2005).

[12] Hallawell, A. Enterprise Antivirus 2Q02 MQ: Room for Improvement. Gartner, Inc. Avail­

able http://www.mcafeesecurity.com/us/local_content/white_papers/wp_gartner_

magi c_quadrant . pdf (retrieved 25 Mar 2005).

[13] Frost and Sullivan (Feb 2005). Company of the Year Award. Available http://www.

sourcefire. com/news/docs/SF_ICTOTL05. pdf (retrieved 25 Mar 2005).

[14] Basic Analysis and Security Engine. Available http: I I secure ideas. sourceforge. net/

(retrieved 25 Mar 2005).

[15] Analysis Console for Intrusion Detection. Available http: I I acidlab. sourceforge. net/

(retrieved 25 Mar 2005).

[16] Steele, Michael E (Jan 2005). WinSnort.com Master/Single Intrusion Detection Sys­

tem (Win-IDS). Available http://sourceforge.net/project/showfiles .php?group_

id=103348 (retrieved 25 Mar 2005).

[17] Netfilter and IPTables. Available http://www. iptables. org/ (retrieved 25 Mar 2005).

[18] Fwsnort. Available http://www. cipherdyne. org/fwsnort/ (retrieved 25 Mar 2005). 53

[19] Nakjang, Nawapong (Aug 2003). Basic Intrusion Prevention using Content-based Fil­

tering. Linuxsecurity.com. Available http: I /www. linuxsecuri ty. com/ content/viewI

117370/49/ (retrieved 25 Mar 2005).

[20] Rash, Michael (Apr 2004). Content Filtering and Inspection with fwsnort and psad.

SysAdmin Magazine, April 2004 vol 13 no 4.

[21] Burnett, Mark. Where, oh where, is my Windows firewall? The Register, 1 8

March 2005. Available http://www. theregister. co. uk/2005/03/18/windows_server_

firewall/ (retrieved 25 Mar 2005).

[22] Lawton, George (Mar 2002). Open Source Security: Opportunity or Oxymoron?

Computer Volume 35, Issue 3, March 2002 pages 18 - 21.

[23] Shai Rubin, Somesh Jha, and Barton P. Miller. Automatic Generation and Analysis of

NIDS Attacks. Computer Security Applications Conference, 2004. 20th Annual 06-10 Dec

2004 pages 28 - 38. Available http: I /www. cs. wise. edu/~shai/59f inal. pdf (retrieved

25 Mar 2005).

[24] Vaarandi, Risto (2003). A data clustering algorithm for mining patterns from event logs.

IP Operations and Management, 2003. (IPOM 2003). 3rd IEEE Workshop on. Pages

119 - 126. Available http: //kodu. neti. ee/~risto/publications/slct-ipom03-web.

pdf (retrieved 25 Mar 2005).

[25] Vaarandi, Risto (2002). SEC a Lightweight Event Correlation Tool. IP Operations and

Management, 2002 IEEE Workshop on. Pages 111 - 115. Available http: I /kodu. neti.

ee/~risto/publications/sec-ipom02-web.pdf (retrieved 25 Mar 2005).

[26] Rouillard, John P. Real-time Logfile Analysis Using the Simple Event Correlator (SEC).

18th USENIX System Administration Conference (LISA '04) Proceedings, November

2004, pp 133-149. Available http://www.cs.umb.edu/~rouilj/sec/sec_paper.pdf (re­

trieved 25 Mar 2005). 54

[27] Nagios: An open source host, service and network monitoring program. Available http:

I /www.nagios.org/ (retrieved 30 Mar 2005).

[28] Valeur, F.; Vigna, G.; Kruegel, C.; Kemmerer, R. A Comprehensive approach to intrusion

detection alert correlation. Dependable and Secure Computing, IEEE Transactions on.

Volume 1, Issue 3, July-Sept. 2004 Page(s):146 - 169.