2.1 Related Works
The early network firewalls mostly emphasized on providing robust security and preserving high performance [6][7]. After that, the research started to integrate more secure functions into the network firewall [8]. Recently, as needs in security diversification, more security systems were integrated into one.
For improving proxy performance, little research has been done on topic development in improvement of TCP splicing for application proxy performance with kernel support [9][10].
There is also study in reducing overheads to minimize system costs [11].
Typical network security devices include firewalls, VPN devices, IDSs, anti-virus systems, anti-spam systems, and content filtering systems. Firewalls and VPN devices usually exist in a single box [12][13][14][15]. Content security devices, such as IDSs, anti-virus systems, anti-spam systems, and content filtering systems, usually exist in a separate box each [16][17][18]. These devices either operate standalone or receive redirected traffic from firewalls.
As the computer processing power increases, there is a tendency to integrate more functions into one box. Commercial products, such as Symantec Gateway [19], FortiNet [20], Astaro Security Linux [21], integrate all of the above functions in a box. How to integrate many functions efficiently becomes a practical issue in both research field and market place [22][23].
2.2 Selected Packages
As opposed to commercial products, we select open-source packages for easier observation because the source code is available. The selected software packages are introduced herein. Only Snort can work alone. The others need to cooperate with a cache proxy server or a mail server. The packet flow of our integration is explained in detail in the
next section.
TABLE 1 Open-source packages.
Package name Type Language Interface Version
Snort Single process C BPF 2.0
AMaViS Multi process Perl Socket 20030616-p9
ClamAV Single process C Socket 0.7
SpamAssassin Plug-in Perl Function call 2.6.3
DansGuardian Multi process C++ Socket 2.0
Table 1 lists five open-source packages we selected for integration. Here Snort is an intrusion detection system. ClamAV and SpamAssassin, working with AMaViS and a mail server, serve as anti-virus and anti-spam systems, respetively. In this work, we chose Postfix for the mail server because of its complete support with AMaViS. The system of content filter consists of DansGuardian and a cooperated cache proxy server, Squid.
Figure 1 shows the components and packet flows of the selected packages. First, Snort sniffs packets with libcap, and then does a series of preprocessing, de-fragmentation, re-assembly, normalization, etc. Next, the packets are sent to the detection engine for signature matching. Finally, if any intrusion is found, Snort will generate alerts and may log the packets for further analysis.
AMaViS receives mail from the MTA. Upon receiving the mail, AMaViS proceeds with the MIME Handler to check whether there are any attached files. If there are any, AMaViS would recognize the file types and decompress them if they are compressed files. Last, AMaViS sends decoded text to SpamAssassin for anti-spam check and decompressed files to ClamAV for anti-virus scan. It decides to block this mail or not according to the results from SpamAssassin and ClamAV.
After receiving the message from AMaViS, SpamAssassin starts to read the message and match against a list of signatures to determine whether it is a spam or not. Finally, it returns
the result to AMaViS to decide whether if this mail is a spam. ClamAV is invoked by AMaViS when anti-virus is needed. It reports whether there is any virus in the files.
DansGuardian receives a request from the client, and then proceeds with a series of IP address and URL checking. If the request is permitted, DansGuardian passes the request to Squid, or block it directly.
2.3 Complete Packet Flows
FIGURE 1 Components and packet flows of a loosely-coupled architecture.
Now let us examine the detailed HTTP and SMTP packet processing flows of the integrated security gateway. In the HTTP part, if both IDS and Web filtering functions are turned on, the Web traffic flow is as follows:
(1) The packets are sniffed by Snort and copied from kernel to user space.
(2) The request is also received by DansGuardian through the TCP/IP protocol stack.
(3) DansGuardian checks whether the URL of the request is permitted to access.
(4) If permitted, the request is received by Squid.
AMaViS
IP/URL check Squid file
Snort
MTA
Kernel Space User Space
(5) Squid makes a connection to the Web server if necessary.
In this Web processing flow, there are three user/kernel interactions in steps (1), (2), and (4), and one inter-process communication in step (4).
In the SMTP part, the mail traffic flow is as follows:
(1) The packets are sniffed by Snort and copied from kernel to user space.
(2) The kernel passes the mail to localhost:25.
(3) The mail is received by the MTA through the TCP/IP protocol stack.
(4) The MTA forwards mail to AMaViS.
(5) AMaViS calls SpamAssassin to check mail.
(6) AMaViS sends message to ClamAV to scan files attached in the mail.
(7) AMaViS forwards mail back to the MTA.
(8) The MTA relays mail to mail server.
In this mail processing flow, there are four user/kernel interactions in steps (1), (3), (4), and (7), two inter-process communications in steps (4) and (7), one process invoking in step (6), and one file system access in step (4).
Obviously, there are many redundant user/kernel interactions and inter-process communications. This consumes more system resources and time. Furthermore, some servers fork processes to serve many clients concurrently. Context switch between these processes take more system resources. These overheads reduce system performance.