4 Chapter Implementation Details
4.2 Rules
4.2.3 SignatureRule
SignatureRule specifies the pattern might be malicious. Usually, it takes much CPU time and lowers the network performance to perform complex analysis on the traffic in real-time. Therefore, we perform simple analysis on the traffic to guarantee the performance. Every SignatureRule defines 2 important parameters: pattern and maxOffset. Once a connection is established, NSDLL scans the SignatureRule Table for rules matching the source and destination. If the matching rules are found, two traffic monitors are added into the incoming monitor list and outgoing monitor list,
individually. Then, the connection begins to transfer data. Both the data received and the data sent will be checked for the pattern. Also, there is a offset counter initialized to zero and increase during the check. Once the counter exceeds the maxOffset of the rule, the monitors are removed from the incoming and outgoing monitor lists.
Figure 4.2.3.1 Add monitors to connections
Connec
Scan SignatureRules
Matched
No
The connection is safe Yes
Add monitors to incoming and outgoing lists.
Initialize counter to zero
Accept
Recv Send
Figure 4.2.3.2 Filter traffic according to the monitors
4.3. AlertLogs and TrafficLogs
There are two types of pre-defined logs in NSML: AlertLogs and TrafficLosg.
Both AlertLogs and TrafficLogs are generated by NSDLL of the Winsock Application.
AlertLogs are generated when there are rules violated. For example, if we have a BindingRule specifies the browser IEXPLORER.EXE cannot bind on any port. Once IEXPLORER.EXE really binds on certain port, the AlertLog is produced to record this abnormal behavior.
No
Increase Counter
The connection is malicious Yes
Counter > maxOffset?
Remove the monitors from lists Yes
Wait for next Send/Recv No
TrafficLogs are produced when the application invokes one of the following Winsock function: socket(), closesocket(), accept(), connect(), bind(), send(), recv(), sendto(), recvfrom(). TrafficLogs record the detailed actions of Winsock applications in time order. If the system is intrueded, we have clues to analysis the system’s behavior.
4.4. Client-Server Interaction in Server Mode
Figure 4.4 Client-Server Interaction
In server mode, the server is responsible for pushing and updating rule to each client. When the client computer boot up and the CoreService is running, CoreService will try to connect to NSServer. Once it succeeds, NSServer sends the RULE_ADD message and starts pushing rules to the client. The rules received by CoreService will be added to shared rule tables and applied by NSDLLs immediately. After the rules are all sent, NSServer sends a RULE_END message to tell the client it is over. If a existing rule is modified, NSServer sends RULE_UPDATE message to client. Then the updated rule is sent. After that, a
Server
RULE_END message is sent. The NSServer maintains a list of online computers with NSML installed. Network administrator can use tool to monitor the network status of the clients.
4.5. The Performance Issue
As mentioned in Section 3.1, Inject DLL is responsible for producing traffic logs and alert logs to record the behavior of a Winsock Application. Those logs are necessary because the logs might be helpful if the system is intruded. The logs give the clues to find out what’s wrong with our system. For AlertLogs, that is fine because AlertLogs are seldom produced. Only when the system finds a malicious connection the AlertLogs are produced. For TrafficLogs, However, a problem arises. Due to the high frequency of networking, NSDLL produces a large amount of TrafficLogs. To transfer all the logs to server side lowers the network performance significantly.
To solve the performance issue, we decide to shrink the size of TrafficLogs before they are really sent to the server side. As mentioned in Section 3.5, CoreService periodically queries Shared Log Tables for latest logs and sent them to the server side. After the TrafficLogs are popped from the TrafficLog table, we shrink the data size in the following steps:
1. TrafficLogs with types rather than SEND/RECV will not be shrinked.
2. Two TrafficLogs are said to be the same if they are both SEND type or both RECV type, generated by the same application, and the two logs have the
same source-destination pair.
3. for same TrafficLogs, the data transferred will be summed up.
For example, we have the following TrafficLogs:
firefox.exe localhost:4884-203.72.66.5:80 RECV 151
firefox.exe localhost:4884-203.72.66.5:80 RECV 180
firefox.exe localhost:4884-140.113.23.101:80 RECV 180
telnet.exe localhost:1477-140.113.23.101:23 CONN 0
telnet.exe localhost:1477-140.113.23.101:23 SEND 1010
telnet.exe localhost:1477-140.113.23.101:23 SEND 1030
firefox.exe localhost:4884-203.72.66.5:80 RECV 100
telnet.exe 140.113.23.101:23-localhost:1477 RECV 2010
telnet.exe localhost:1477-140.113.23.101:23 SEND 100
firefox.exe localhost:4884-203.72.66.5:80 RECV 150
telnet.exe 140.113.23.101:23-localhost:1477 RECV 510
telnet.exe localhost:1477-140.113.23.101:23 CLOSE 0
firefox.exe localhost:4884-140.113.23.101:80 RECV 100
After shrinking:
firefox.exe localhost:4884-203.72.66.5:80 RECV 581
firefox.exe localhost:3321-140.113.23.101:80 RECV 280
telnet.exe localhost:1477-140.113.23.101:23 CONN 0
telnet.exe localhost:1477-140.113.23.101:23 SEND 2140
telnet.exe 140.113.23.101:23-localhost:1477 RECV 2520
telnet.exe localhost:1477-140.113.23.101:23 CLOSE 0
After shrinking, the size of TrafficLogs significantly reduced and the network performance is therefore improved.
4.6. Implementation of Callbacks between Different Process Spaces
It is easy to implement callback functions in single process because all the functions are in the same logic memory space. However, each process owns its own addressing space, so it is hard to register callback functions between different processes. To solve this problem, we add 1 more shared table: SoftwareTable. When CoreService starts running, it creates a special named event object. Then it creates a new thread to wait the object to be signaled. When a NS Software starts running, NSLib will automatically add an entry to the SoftwareTable. Also, NSLib will record the callback functions locally and create a named event object. The event object name will be stored in the table, too. Next, NSLib creates a thread which waits for the event object to be signaled. Once a rule is violated, NSDLL will singal CoreService event object to inform CoreService to look up the SoftwareTable to find the corresponding name of event object to signal. After the thread in NSLib is signaled, the thread invokes the callbacks and then waits for another signal.
Figure 4.6 Implementation of callbacks between different processes
4.7. NSServer and Database Schema
In server mode, rule data are stored in a centralized database. In this section, we propose the database schema used in NSML. Currently, we choose MySQL [10] as our database. In the future, when the system is deployed to a large network environment, maybe some more powerful database like MSSQL would be a good choice. To access MySQL through C++, we also take the advantage of mysql++ [11], which is a powerful library to manipulate MySQL in C++.
There are 7 tables in the database schema, 4 tables for rules, 2 tables for logs, and 1 more table to record the NS Software information.
Shared Rule Tables
Table 4.7.1 BindingRule
rindex: rule index, every rule has a unique rindex number. Rindex is used when there is an update about certain rule.
hostip: apply the rule only on certain host? Zero stands for all host.
protocol: what protocol is used, currently TCP only for BindingRule.
serverport: which port the application should not bind. Zero stands for all ports.
processname: which application should apply this rule. Null string stands for all applications.
sid: which NS software does this rule belong to.
Table 4.7.2 LegalConnRule and IllegalConnRule
protocol: may be TCP or UDP srcip: the connection source ip srcport: the connection source port
destip: the destination ip of the connection destport: the detination port of the connection
action: BLOCK or ALERT. Both BLOCK and ALERT produces AlertLogs, but ALERT only generate the alert and still let the connection there.
Table 4.7.3 SignatureRule
signaturelength: length of the signature
maxoffset: the max offset where the connection should be monitored signature: the signature
Table 4.7.4 AlertLog
type: BLOCK or ALERT.
ruletype: the type of the violated rule rindex: the rule index of the violated rule message: additional message of this alert time: when this alert is generated.
Table 4.7.5 TrafficLog
` length: the data length of bytes transferred
action: SOCK_CREATE,SOCK_CLOSE,SEND,RECV,SENDTO, RECVFROM, BIND, etc.
Table 4.7.6 Software
sid: the unique id of this software name: the software name
Chapter 5
Programming Interface and Performance Evaluation
5.1 NSLib Application Programming Interface
NSLib
- NSLib(char *softwareName);
- AddSignatureRule(SianatureRule*);
- AddBindingRule(BindingRule*);
- AddLegalConnRule(LegalConnRule*);
- AddIllegalConnRule(IllegalConnRule*);
- RemoveSignatureRule(int rindex);
- RemoveBindingRule(int rindex);
- RemoveLegalConnRule(int rindex);
- RemoveIllegalConnRule(int rindex);
- UpdateSignatureRule(SianatureRule*,int rindex);
- UpdateBindingRule(BindingRule*,int rindex);
- UpdateLegalConnRule(LegalConnRule*,int rindex);
- UpdateIllegalConnRule(IllegalConnRule*,int
ER);
- SetAlertLogHandler(ALERTLOG_HANDLER);
- SetTrafficLogHandler(TRAFFICLOG_HANDLER);
typedef void (*SIGNATURE_RULE_HANDLER)(SignatureRule*);
typedef void (*BINDING_RULE_HANDLER)(BindingRule*);
typedef void (*LEGALCONN_RULE_HANDLER)(LegalConnRule*);
typedef void (*ILLEGALCONN_RULE_HANDLER)(IllegalConnRule*);
typedef void (*ALERTLOG_HANDLER)(AlertLogEntry*,int size);
typedef void (*TRAFFICLOG_HANDLER)(TrafficLogEntry*,int size);
NSLib API are designed as simple as possible. These functions can be used to develop network security software either in standalone mode or in server mode. Now let’s go through them:
NSLib(char*):
The constructor is responsible for initializing the environment. For example, it creates the event object which we mentioned in Section 4.6, and register itself to the Software Shared Table. Also, it creates another thread to wait for signals to execute the callback functions. The only one parameter is the name of the software.
SetSignatureRuleHandler(SIGNATURE_RULE_HANDLER):
SetBindingRuleHandler(BINDING_RULE_HANDLER):
SetLegalConnRuleHandler(LEGALCONN_RULE_HANDLER):
SetIllegalConnRuleHandler(ILLEGALCONN_RULE_HANDLER):
The four functions are used to set up the callback functions. Each of them accepts a callback function pointer as the parameter. When a rule violation is encountered, according to its type, the corresponding callback function is invoked, and the rule violated is passed in.
AddSignatureRule(SianatureRule*):
AddBindingRule(BindingRule*):
AddLegalConnRule(LegalConnRule*):
AddIllegalConnRule(IllegalConnRule*):
The four functions are used only in standalone mode. In standalone mode, NS software is responsible for storing the rules physically on the disk. Therefore, when NS software is initialized, it should load the rule from the disk and add them into the shared tables.
RemoveSignatureRule(int rindex):
RemoveBindingRule(int rindex):
RemoveLegalConnRule(int rindex):
RemoveIllegalConnRule(int rindex):
These functions remove rules from the shared rule tables with given rindex.
Every slot of rule tables has a flag to indicate if this slot is used or not. The remove operation simply sets the flag off. Therefore, it’s efficient to remove the rules.
UpdateSignatureRule(SianatureRule*,int rindex):
UpdateBindingRule(BindingRule*,int rindex):
UpdateLegalConnRule(LegalConnRule*,int rindex):
UpdateIllegalConnRule(IllegalConnRule*,int rindex):
These 4 functions are used to update a existing rule in rule tables. The developer needs to specify the rindex to indicate which rule is going to be overwritten.
SetAlertLogHandler(ALERTLOG_HANDLER):
SetTrafficLogHandler(TRAFFICLOG_HANDLER):
Because the memory space is limited, we cannot store all the logs in shared memory. We only keeps the latest logs in shared memory. To prevent the tables from being full, the logs need to be consumed periodically in standalone mode. Therefore, the developer should set two callbacks which will be invoked periodically. There are two parameters passed into the callback functions: an array of log entries, and the size of the array.
5.2 Performance Evaluation
Because we need to process the rule logic in real-time, NSML causes some performance overhead. We test its performance by download a big file (697 MBs) using FTP. There are 3 condition tested: 1) without NSML, 2) with NSML but without rules, and 3) with NSML and signature rules.
CPU Usage Throughput
(1) Without NSML 16.5% 7.61 MB/s
(2) With NSML, without rules 17.1% 7.22 MB/s
(3) With NSML, with signature rules 24.2% 6.58 MB/s Table 5.2 Throughput and CPU usage with/without NSML
With NSML but without rules, the throughput is lower the original. This is because NSML produces and transfers real-time traffic logs. With NSML and signature rules, the throughput becomes 6.98 Mbps due to real-time traffic analysis and traffic logs. From the result, we can see the impact to the network performance caused by NSML is small and tolerable.
The difference of CPU usage between (1) and (2) is 1.6%, which is small. The CPU usage in (3) arises to 24.2% because the CPU needs to perform algorithms to analysis the traffic. Smaller signature leads to smaller CPU usage.
Chapter 6 Conclusions and Future Works
6.1 Conclusion
It is hard to propose a comprehensive solution for network security management problem. We try to find out a possible way to find an integrated solution for it. We focus the design of NSML in 4 aspects: reliability, programmable policy, easy-to-use, high performance. In this paper, NSML introduced an open framework to provide application firewall, bandwidth control, real-time traffic analysis, and client-server architecture to solve the security and manage of network. With the help of NSML, developers can easily develop the network security software they want. This significantly reduces the hardness and time-to-market of network security software development. Also, with the help of the framework, the improper use of network by users or malicious programs in the office can be detected and managed. The quality of service of critical network applications can be guaranteed.
6.2 Future Works
Currently, we use a simple algorithm to perform traffic analysis. However, to make the analysis more powerful, we must change to a more powerful analysis method while preserving the high performance. We need help of statistic algorithms.
PAYL [8] may be one of our choices. Besides, current version of NSML does not take spy ware detection / removal into consideration although their strange behavior might be found by the rules. It is a good idea to add spy ware detection feature into the next version of NSML.
Microsoft and Cisco announced the NAP-NAC[12] Interoperability Architecture in Sep. 2006, which takes the advantage of NAP’s software framework extensibility and NAC’s hardware capability. This paper focused on developing a stable, flexible, easy-to-use, and high performance open network security management library.
However, to enhance the security further, it is necessary to port NSML into NAP framework. With the help of NAP framework, all intruded computers can be totally isolated from the network and remediate automatically. Thus, the system will be more secure.
Bibliography
[1] Spybot Search & Destroy,
http://www.safer-networking.org/ct/index.html [2] Bandwidth Controller,
http://bandwidthcontroller.com/
[3] Winsock Service Provider API,
http://msdn2.microsoft.com/en-us/library/ms741418.aspx http://msdn2.microsoft.com/en-us/library/ms741424.aspx http://msdn2.microsoft.com/en-us/library/ms741424.aspx
[4] Microsoft Cooperation, Network Access Protection Introduction, April 2007 Updated
http://download.microsoft.com/download/8/d/9/8d9b3e54-6db7-4955-9e36-58a3f0534933/NAPI ntro.doc
[5] Microsoft Cooperation, Network Access Protection Architecture, April 2007 Updated
http://download.microsoft.com/download/3/9/f/39ff0ca3-56d1-4d93-af46-98f92134d040/NAPAr ch.doc
[6] CH Chiu, SM Yuan, Managing the Network Usage of Applications,
[7] M Bailey, E Cooke, D Watson, F Jahanian, J Nazario - IEEE Security & Privacy, 2005
[8] Ke Wang, Salvatore J. Stolfo, Anomalous Payload-Based Network Intrusion Detection, Recent Advances in Intrusion Detection, 2004
[9] Symantec Sygate Enterprise Protection,
http://www.symantec.com/zh/tw/enterprise/products/overview.jsp?pcid=1001&pvid=1303_1 [10] MySQL, http://www.mysql.com/
[11] MySQL++, http://tangentsoft.net/mysql++/
[12] Microsoft Cooperation and Cisco System, Inc, Joint Architecture for NAC-NAP Interoperability http://www.microsoft.com/presspass/press/2006/sep06/09-06SecStandardNACNAPPR.mspx [13] Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server(TM) 2003, Windows
XP, and Windows 2000 (Pro-Developer) by Mark E. Russinovich and David A. Solomon (Dec 8, 2004)
[14] Winsock 2.0 by Lewis Napper (Nov, 1997)
[15] Network Programming for Microsoft Windows, Second Edition by Jim Ohlund, Anthony Jones, and James Ohlund (Feb 13, 2002)
[16] Seyed M.M., Tahaghoghi, Hugh Williams, Learning MySQL, O’Reilly, Nov 2006