Capturing Web Application Threats Using virtual CMS Honeypot. Saharuddin Saat, Nor Adora Endut 1, Abdul Hamid Othman 2

Transcription

1 Capturing Web Application Threats Using virtual CMS Honeypot Saharuddin Saat, Nor Adora Endut 1, Abdul Hamid Othman 2 Faculty of Computer and Mathematical Sciences, Universiti Teknologi MARA, Malaysia adora 1, hamido Opensource Content Management System (CMS) is very popular and widely used by web administrators around the world nowadays because of their simplicity for the instant web application solution. Consequently, web applications have increasingly been the focus of attackers because of the unintentional web vulnerabilities that comes from the newly introduced functionality. This project aims at enhancing the level of security for CMS inside the Universiti Teknologi MARA (UiTM) network by providing the most extensive way on developing Virtual CMS Honeypots. The outcome is hoped to ease the web administrators to monitor any kind of computer threats such as hackers, worms and viruses in more comfortable and efficient way. The results also will provide the administrator some form of countermeasures for security purposes and traffic analysis. Using Customize Awstats, Snort, AcidBase and Proxy will provide a Honeypot for a rapidly expandable network and suit for the web administrator especially at UiTM to monitor webserver traffic activity and any latest computer threats.

2 Figure 2.1: HIHAT Figure 3.1: Methodology Figure 3.2: Network Design Figure 4.1: No machine client Figure 4.2: Honeypot server Figure 4.3: Starting pound Figure 4.4: Nmap screenshot Figure 4.5: Virtual Box Figure 4.6: Mono Asp Figure 4.7: Awstats report details Figure 4.8: Snort running Figure 4.9: AcidBase analysis Figure 5.1: Honeypots Attack chart LIST OF FIGURES

3 LIST OF TABLES Table 3.1: List of Software Table 2.1: List of Hardware Table 5.1: Duration of honeypots uptime Table 5.2: Number of attacks occurred per server Table 5.3: HTTP status codes Table 5.4: customize HTTP 403 error code report Table 5.5: Worms detected on topyenoh Table 5.6: Worm detected on php cms Table 5.7: directory browsing on php cms Table 5.8: Worm detected on asp cms Table 5.9: Unauthorized access on jsp cms Table 5.10: Page viewed on ruby cms Table 5.11: Honeypots Attack Listing

4 ABBREVIATIONS CMS Content Management System HTTP Hyper Text Transfer Protocol JSP Java Server Pages Technology PHP Personal Home Page ASP Active Server Pages HIHAT High Interaction Honeypot Analysis Tool SSH Secure Shell ACID Analysis Console for Intrusion Databases BASE Basic Analysis and Security Engine IIS Internet Information Services SNMP Simple Network Management Protocol TCP Transmission Control Protocol IPV6 Internet Protocol Version 6 URI Uniform Resource Identifier ICMP Internet Control Message Protocol

5 CHAPTER 1 INTRODUCTION 1.0 Introduction This chapter will describe the overview of the problems that may or may not be faced by the web administrator. Honeypot is most effective implementation for reviewing any threat that occurred inside Content Management System. Although a lot of honeypot has been developed, not all of them make the web administrator job easier since they still need to read the whole log file in each server to find any threat and vulnerability that has occurred. This chapter will provide an overview of the problem statement, objective and significance of this project. 1.1 Problem Statement Content Management System technologies such as PHP, ASP, CGI, Javascript, and Ajax have made it much easier for people to build and deploy services on the Internet. Unfortunately, this has opened a wide possibility for new attacks since it is accidentally introduce new vulnerabilities into it. Therefore, content management systems have increasingly been the focus of attackers. Although a lot of web administrator has a lot of choice to choose the more stable and secure opensource content management system as their favorite instant content management system, they still need to monitor for vulnerabilities and threats that have been occurred on the webservers. For that reason, the web administrator needs an easier way on how to analyze the long and unstructured log file for every server. The best way is to pass on the threat and monitor it on single point like having a proxy within the network to log any HTTP request. This project will propose a proper way on how to help the web administrator monitor their entire webserver HTTP request by looking at the log server only instead of having to read every each server log file. 1.2 Objectives The following are the main objectives for this research : i. To analyze any kind of attack that has been used by the hackers to compromise the server ii. To discover any successful attempt to hack the decoy cms by analyzing the log file and the cms itself iii. To generate a report using the log file based on which kind of attacks that have occurred

6 1.3 Scope The research will be focused on the following, which are the boundaries for the research: i. This project will be focusing on only four kinds of languages (cms) which are JSP, PHP, Ruby and ASP ii. This project will be deployed at UiTM s Data Center iii. This project will be using Debian 4 (Awstats, MySQL, Apache, PHP, Pound, Tcpdump, Tcpreplay, Snort, AcidBase, VirtualBoxOSE, NOMachine, Mambo, Mojoportal, Opencms, Radiant), IBM server. iv. The honeypot server requires customization on awstats to produce comprehensive report of HTTP request 1.4 Significance of the study This research will be significant to provide information to deploy virtual honeypots and security action has been taken while developing the virtual honeypots. At the end of this project, hopefully it will help the web administrator in order to monitor the access activity and the threats that arise at the virtual honeypots. Some of the significances are: i. The information beneath the honeypot is the most important aspect, which would guide web administrators in terms of handling any security threats ii. The provision of a user friendly log reader on honeypot server which is the proxy for the virtual honeypot iii. With a user-friendly environment, it will diminish the problem of reading long and unstructured log files and efficiently captures what has happened inside the virtual honeypots 1.5 Conclusion Chapter 1 has covered an overview of the project objectives, scope and the significance of the project involved that must be met with the project requirement. The next chapter will be focusing on literature review about the aspect of the project development.

7 CHAPTER 2 LITERATURE REVIEW 2.0 Introduction Some reviews have been made in order to understand what and how the concept of the project will be done. This chapter will discuss more about all of the information related to the project. These literature reviews are based on articles available on the internet websites about previous researches that are related to this project. Also, Honeypots that are used for this project will be elaborated on. 2.1 HONEYPOT Introduction There are a lot of honeypot tools has been around such as Project honeynet, High Interaction Honeypot Analysis Tool (HIHAT), Honeyd, back officer and many more. The only reason the existence of honeypot is because the information beneath it that can help web administrator to understand any kind of attack and how to countermeasure it. According to Lance Spitzner (2002) A honeypot as "a security resource who's value lies in being probed, attacked or compromised ". This means that whatever we designate as a honeypot, it is our expectation and goal to have the system probed, attacked, and potentially exploited. Keep in mind, honeypots are not a solution. They do not 'fix' anything. Instead, honeypots are a tool. How you use that tool is up to you and depends on what you are attempting to achieve. A honeypot may be a system that merely emulates other systems or applications, creates a jailed environment, or may be a standard built system. Regardless of how you build and use the honeypot, it's value lies in the fact that it isattacked. This project will be focusing at the Pusat Sistem Maklumat Bersepadu (PSMB) Data Center UiTM which is where the research honeypot will be deployed. It is the best place to deploy since the data center has the high potential to garner as much data as possible and it is wheremost of the heavy traffic from the internet comes in. Attack might be occurred within the local area network or from the internet. According to (Lance Spitzner, 2002) Research honeypots are honeypots designed to gain information on the blackhat community. These honeypots do not add direct value to a specific organization. Instead they are used to research the threats organizations face, and how to better protect against those threats. Think of them as 'counterintelligence', their job is to gain information on the bad guys. This information is

8 then used to protect against those threats. Traditionally, commercial organizations do NOT use research honeypots. Instead, organizations such as Universities, government, military, or security research organizations use them. Meanwhile, Christian (2008) in his article defines that honeypots are decoy computer resources set up for the purpose of monitoring and logging the activities of entities that probe, attack or compromise them. Activities on honeypots can be considiered suspicious by definition, as there is no point for benign users to interact with these systems. Honeypots come in many shapes and sizes; examples include dummy items in a database, low-interaction network components like preconfigured traffic sinks, or fullinteraction hosts with real operating systems and services. M uter (2008) suggests, the simplest form of a honeypot is a real vulnerable system that has been modified to include surveillance methods. Such a system is called a high-interaction honeypots because the attacker is able to fully interact with the honeypot just like a real system. This offers the best potential for analyzing all aspects of an attack, but also introduces risk that the attacker will use the capabilities of the system to attack others. A high interaction honeypot must disguise itself as a real machine, hiding its surveillance methods to all users even if they have root privileges. A physical honeypot is a real machine with its own IP address. This can be a disaster if the machine can be compromise and there is high opportunity that it is going to be broken. Niels Provos (2003) in his article sugguesting that a virtual honeypot is need to be simulated by another machine that responds to network traffic sent to the virtual honeypot is the safer way to deploy a honeypot. Virtual honeypots are attractive because they requirer fewer computer systems, which reduces maintenance costs. Using virtual honeypots, it is possible to populate a network with hosts running numerous operating systems. To convince adversaries that a virtual honeypot is running a given operating system, we need to simulate the TCP/IP stack of the target operating system carefully, in order to fool TCP/IP stack fingerprinting tools like Xprobe or Nmap. Among the famous honeypots that is largely used nowadays are Honeynets. They are one of the most advanced and complex honeypots, their primary purpose is to capture extensive information on threats, both internal and external. Honeynets are complex in that they are entire networks of computers to be attacked. Nothing is emulated. The systems and applications within a Honeynet can be the same systems found in a real organization. Within these systems additional information, such as files, records in databases, log entries, or any information that is desirable for the attacker to interact with can be placed. Honeynets have this flexibility because they are not a standardized solution, instead a Honeynet is a specialized architecture that creates a fishbowl, and any target systems can be placed within this fishbowl. Just like a fishbowl, a virtual world can be created; however instead of adding coral and sand, a Solaris database server or Cisco routers are added. Just like a fishbowl, everything that is going on can be observed, however with a Honeynet, the attacker never realizes that they are being overserved.

9 2.2 RELATED CMS HONEYPOT High Interaction Honeypot Analysis Tool (HIHAT) Figure 2.1: HIHAT HIHAT is one of the related project developed using generic toolkit. The difference is HIHAT captures any threats then it will push the data from the honeypot to the log server. HIHAT is a framework that constructs honeypots for web application based on the scripting language PHP only. Moreover, it is a physical honeypot which is using a real machine with its own IP address.

10 CHAPTER 3 METHODOLOGY 3.0 Introduction This chapter will be focusing on and explaining about the methodology that will be used in this project in order to achieve the main objectives for the project. This chapter also will describe all the possible flow on how the project will be done, what kind of information will be gathered and the steps that are involved. Having an appropriate methodology is an important step in a project because it can be a guidance and as a point of consistency when the project is in progress. It also will be used to provide step by step information on the problem and the solutions that come across for these problesm. Honeypot server will be deployed in order to serve the four kinds of cms with different languages. The honeypot server will dump any HTTP request to the virtual cms through pound. Awstats will be the tool to generate report for HTTP request that has been occurred. The main objective to use the awstats is to make thing easier for us to analyze any kind of attack that has been use by the hackers and to discover any successful attempt to hack the decoy cms by analyzing the log file and the cms itself. The honeypot server also uses snort as the threat database signature since snort is the most well known industrial standard tool and reliable to detect any web application threat. AcidBase will be use to create the report base on what kind of attack have occurred. If any of those virtual honeypots being compromised, it will be isolated from the network and an analysis will be conducted to learn how the threats take place. 3.1 Methodology Used This project will be using five main phase that will require researcher to pass and remain error free for every phase before proceed to the next phase and until completion. All phases will be explained through the flow chart in detail.

11

12

13

14 3.1.1 Information Gathering The first phase of the project will be determining the problem statement and background of the problem that will come out with the objective what and will be achieve from the problem and information that will be gathered. Information and problem statement will be gathered from the existing implementation of the virtual honeypots that available on the internet. It is best to implement a new approach that can enhance the honeypot server that will be deployed inside UiTM s data center. The reason is to make sure that the honeypot server which will be deployed is not going to be compromised by hackers. The security of the honeypot server is very important because all the virtual honeypots are depending on the honeypot server to be functional. The virtual honeypots must be exactly the same as any real server inside the data center and this make the hackers think that the virtual honeypots are exactly like a real server Project Requirement Next phase is project requirement. This phase will identify the requirement that will be involved to develop the virtual honeypots. From the previous phase, we have gathered all the information towards the objective. From the objective and scope of the project, researcher will identify the tools, hardware, software and system architecture to develop the virtual honeypots. All of the requirement that involved will have their own strength and responsibility towards the project development. Every aspect determining the project requirement must meets the objective and are able to provide a solutions along the project development. The following are the requirement for the project that will be used and implemented

15 Software

16

17 Hardware Design and Development At the third phase, will be the critical phase where the design and development of the project involved. This phase will determine the project requirement that was gathered and collected during the project requirement phase can be implemented and provide solutions to achieve the objectives as well as the boundaries or project limitation. The content management system (cms) that has been identified will be implemented on the virtual honeypots. At the third phase everything will be done correctly to make the virtual honeypots run error-free Network Design The project will follow the network design below to deploy and implement the proposed virtual honeypots. This will require all the hardware that has been listed on the project requirement phase.

18 3.1.4 Implementation After the system design and development finished, the next level is where the virtual honeypots are implemented. This phase will test the virtual honeypots availability and reliability to provide a connection within UiTM network. This phase also will be the point to test the virtual honeypots is fully functional and identify if there is any of the virtual honeypots that are not functioning well Error Rectification The next phase is rectifying the errors. Any problems regarding the errors of the virtual honeypots will be resolve as soon as it is being discovered. If any of the virtual honeypots is not functioning well, then it will be difficult to get an accurate analysis result of any threat that might be occurred. 3.2 Conclusion Choosing the most strategic methodology is the most critical and important part in every project design and development. Methodology also determines in detail what are the processes involved in developing the virtual honeypots. All the phase will ensure the project time line are

19 in order and have to complete in time. The entire requirement must be helpful along the virtual honeypots design and development. Next chapter will be discussing in chapter 4: the virtual honeypots overview.

20 CHAPTER 4 HONEYPOTS OVERVIEW 4.0 Introduction This chapter will explain the main overview of the virtual honeypots and architecture that had been used to develop the system. This chapter also will explain how the virtual honeypots are being monitored and the interface for the administrator. 4.1 Honeypots Overview Remote Desktop using No Machine To monitor the honeypot server, No Machine client is used to access the server. No Machine manipulates port 22 of ssh to create remote desktop environment. This will make thing easier for the web administrator to monitor the honeypot server without having to login physically to that server. The honeypot server has been installed with the no machine server in order to make it accessible through the ssh port. Figure 4.1: NoMachine client. Firstly, we need to provide username and password before connecting to the honeypot server as shown on figure 4.1 above. No Machine is a very light remote desktop that use NX to compresses the X11 data to minimize the amount of data transmitted. NX also makes extensive use of caching, to make the session as responsive as possible.

21 Figure 4.2 shows the remote desktop interface which is exactly the same as logging in physically to the honeypot server Pound The Pound program is a reverse proxy, load balancer and HTTPS front-end for Web server(s). In this project, pound is use to do port forwarding from the honeypot server to the virtual honeypots. In order to capture the entire HTTP request to the virtual honeypots and write to a file, we need to issue command tail f /var/log/syslog > vcms.log. This will capture HTTP request to the virtual honeypots and save it to a file name vmcs.log.

22 Figure 4.3 shows how to start pound by starting the service using command line. Please refer to Appendix A for the details configuration for port forwarding. Port forwarding is implemented to make the virtual honeypots accesseible from the proxy server.

23 Figure 4.4 shows the nmap scanning result detect the open ports, services that are currently running and the version on the honeypot server. It shows that port 8080 is open and service that available is Apache Tomcat serve for our java cms. Port 8082 is open and service that available WEBrick which is our ruby cms. Port 8888 is open and service that available is our Apache with Mono which is our asp cms. Port is open and service that available is Apache for our mambo cms. Other than that port are default ports of the honeypot server for management purpose Virtualbox VirtualBox is used in this project to create and run virtual honeypots on the virtual machine. The virtual honeypots installed with debian operating system for java cms, php cms and asp cms. While the asp cms use Opensuse operating system since Mono is more stable running on it.

24 The virtual honeypots are running smoothly without having a problem as shown on Figure 4.5. Each virtual honeypots have been installed with the specific software based on their specific requirement.

25 Figure 4.6 shows that one of our virtual honeypots is running smoothly in virtualbox. The asp cms running with Mono on the virtualbox and opensuse has been installed as the operating system Log analysis Awstats The awstats can be access from the honeypot server by opening the browser and go to url By default awstats only shows details error pages for 404 kind of error only. In this project, customization needs to be made so we can show every single error for each virtual honeypots.

26 Figure 4.7 show awstats report details on each virtual honeypots. The report were generated by running script that has been created by issuing./myscript on the command line. Refer to appendix B for the details bash script to compile all pound HTTP log file. The reports were generated in html format Snort Snort is an open source network intrusion prevention and detection system utilizing a ruledriven language, which combines the benefits of signature, protocol and anomaly based inspection methods. In this project, snort were use to detect any kind of attack that goes to the virtual honeypots and honeypot server itself.

27 Figure 4.8 show how to start the snort service by issuing the command Snort c /etc/snort/snort.conf i br0 Snort is running and listening to interface br0 which is our interface where traffic comes in to the virtual honeypots and the honeypot server AcidBase BASE is the Basic Analysis and Security Engine. It is based on the code from the Analysis Console for Intrusion Databases (ACID) project. This application provides a web front-end to query and analyze the alerts coming from a SNORT IDS system.

28 Figure 4.9 shows the AcidBASE web interface to perform analysis of intrusions that snort has detected in our network.

29 CHAPTER 5 RESULT AND FINDINGS 5.0 Introduction This chapter will describe the result of the data gathered from the honeypot server and virtual honeypots. Current implementation, the objective has been achieved and the result has been collected and analyzed. 5.1 Duration of honeypots uptime The virtual honeypots were successfully deploy and running 31 days uninterrupted in order to get the most data. As shown on table 1, they were running from March 9, 2009 until April 9, None of them were being compromised and being used as a stepping stone to do any harm to other servers inside the UiTM s data center. 5.2 Awstats log report Based on the awstats report, % percentage of attacks occurred at the honeypot server which is topyenoh. Among all of the virtual honeypots, php cms is the most targeted cms with % percentage of attacks. The asp cms is the second highest number of attacks among virtual honeypots with % percentage of attacks. Third highest cms is ruby cms

30 with 0.13 % percentage of attacks. Lastly, the less attack occurred at jsp cms with 0.12 % percentage of attacks Honeypots server By default, awstats error report details only available for error 404 only. In this situation, we can only do analysis if all HTTP request defined as a threat even though the HTTP request is 200 which means the request has succeeded. This class of status code indicates that the client's request was successfully received, understood, and accepted [11]. It is because a statement for sql injection will return status code valid. The HTTP status codes on the table 3 shows that most of the request pages return the status code document not available. Based on the HTTP patterns, we can see about hits within 15 minutes came from same ip address. Some of the request can be seen as below: [26/Apr/2009:13:05: ] "GET /useraction.php3 HTTP/1.0" "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" [26/Apr/2009:13:05: ] "GET /userreg.cgi?cmd=insert&lang=eng&tnum=3&fld1=test999 %0acat</var/spool/mail/login>>/etc/passwd HTTP/1.0" "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" [26/Apr/2009:13:05: ] "GET /zentrack/index.php HTTP/1.0" "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

31 As shown on table 5.4, HTTP error code for 403 forbidden pages was successfully generated by custom HTTP errors report. The result shows that, there are request for forbidden pages and the access to the pages being denied. Refer to appendix C for the details awstats customize configuration multiple errors report. Awstats has the capability to detect any worm activity to connect to the server. The worm signature used awstats library to detect the pattern of the worm. The HTTP request below shows that code has been injected to the server to run anonymous command prompt listing the directory that available on that server remotely through web browser [26/Apr/2009:13:04: ] GET /_vti_bin/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system 32/cmd.exe?/c+ dir HTTP/ Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Awstats detect the malicious code as part of the Nimda family worm that trying to exploit the IIS vulnerability of windows server executing command remotely through web browser [12]. This kind of attack is called Unicode attack. The server returns error 404 which is file not found because the code trying to inject windows command that only available on windows server only Php cms The HTTP request below shows that code has been injected to the server to run anonymous command prompt listing the directory that available on that server remotely through web browser [26/Apr/2009:20:31: ] GET /scripts/trsensepostchangemeli.dll?template=nonexistfile?templat e=..\\..\\..\\..\\.. \\winnt\\system32\\cmd.exe?/c+dir HTTP/

32 The malicious code was detected as part of the Nimda family worm that trying to exploit the IIS vulnerability of windows server executing command remotely through web browser. This kind of attack is trying to exploits the vulnerable script of trsensepostchangemeli.dll on the server. The server returns error 404 which is file not found because the code trying to inject windows command that only available on windows server only. On table 5.7, the valid 200 page which been highlighted red in color shows that there are 18 times the page of phpmyadmin being viewed. The hacker was only browsing the database through the phpmyadmin without doing any harm to the database. This kind of attack occurred because anybody can access the phpmyadmin without any authentication required Asp cms The HTTP request below shows that code has been injected to the server to run anonymous command prompt listing the directory that available on that server remotely through web browser [06/Apr/2009:14:12: ] "GET/c/winnt/system32/cmd.exe?/c+dir+/OG HTTP/1.0" The malicious code was detected as part of the Nimda family worm that trying to exploit the IIS vulnerability of windows server by executing command remotely through web browser [12]. It launches the directory traversal kind of attack to run the command prompt listing the directory available on that server. The server returns error 404 which is file not found because the code trying to inject windows command that only available on windows server only.

33 5.2.4 Jsp cms On the Jsp cms server, there is no such worm activity detected. The HTTP request detected is a request trying to access java servlet manager. The request already included Authorization credentials, and then the 401 response indicates that authorization has been refused for those credentials as shown below: [10/Apr/2009:05:25: ] "GET /manager/html HTTP/1.1" " "Mozilla/5.0 (X11; U; Linux i686; en-us; rv: eol) Gecko/ (Debian ~pre080614i-0etch1) Epiphany/2.14" Table 5.9 below shows the awstats report of one unauthorized access of page java servlet manager Ruby cms Ruby cms server has the smallest number of visitor. Furthermore, there is no such worm and hacking activity was detected since the ruby cms being running. Table 5.10 shows that there are about 6 times the ruby cms pages being viewed.

34 5.3 AcidBase report This honeypots recorded 448 alerts under 10 types of alert comprising 2 categories. The highest attack is Webroot Directory Traversal with 62.5 % attempt to access files not intended to be accessed. The second highest is Double Decoding attack with 26% attempt to reveal directory.

35

36 6.0 Introduction CHAPTER 6 CONCLUSION AND RECOMMENDATION This chapter will be the last chapter that describe the conclusion and overall of the project development. This chapter also will describe the recommendation for the project development which may be improved for the next research. 6.1 Conclusion From information gathering, project requirement, honeypots design and development and implementation, overall for this project it has achieve the objective: To analyze any kind of attack that has been used by the hackers to compromise the server To discover any successful attempt to hack the decoy cms by analyzing the log file and the cms itself To generate a report using the log file based on which kind of attacks that have occurred Virtual honeypots save the cost to deploy honeypots since it does not require a physical server. All HTTP requests capturing and reporting has been fully functional to enable the administrator monitor the occurrence of attacks on the honeypots and analyze the threat. Using awstats help administrator save their time and efficiently monitor the honeypots. This virtual honeypots will give the web administrator the easiness to monitor their cms honeypots and react as soon as the incident arises. 6.2 Recommendation At this current time, this honeypots project only focusing on HTTP request that has been captured and analyzed. It does not monitor the database operation for each server. It is best to implement database monitoring since the database is where the data of cms to be fully functional. Having database monitoring is a value added for the honeypots to captured and analyzed by not depending on HTTP request monitoring only.

37 References 1. Niels Provos (2003) A Virtual Honeypot Framework Retrieved October 21, 2008 from 2. Christian Kreibich, Jon Crowcroft (2008) Honeycomb Creating Intrusion Detection Signatures Using Honeypots, Retrieved October 21, 2008 from 3. Michael Muter (2008) A Generic Toolkit for Converting Web Applications Into High- Interaction Honeypots, Retrieved October 21, 2008 from 4. Lance Spitzner (2002) Honeypots Definitions and Value of Honeypots, Retrieved October 21, 2008 from 5. Lance Spitzner (2002) Honeypots: Catching the Insider Threat Retrieved October 21, 2008 from 6. Acidbase (2009) Basic Analysis and Security Engine (BASE) project, Retrieved October 21, 2008 from base.secureideas.net/index.php 7. Snort (2009) Snort - the de facto standard for intrusion detection/prevention (2009), Retrieved January 2, 2009 from 8. Awstats (2009) Awstats - Free log file analyzer for advanced statistics (2009), Retrieved January 2, 2009 from 9. Virtualbox (2009) An x86 virtualization software package developed by Sun Microsystems (2009), Retrieved January 2, 2009 from Nomachine (2009) Desktop Virtualization and Remote Access Management, Retrieved January 2, 2009 from RFC 2616 (2009) Status code definitions (2009), Retrieved January 2, 2009 from Security Space (2009) Nimda worm. Retrieved January 3, 2009 from Mono (2009) Provides the necessary software to develop and run.net client and server applications on different platforms (2009), Retrieved January 2, 2009 from

38 APPENDICES

39

40

41

42

43

44

45