WEB APPLICATION FIREWALL

WEB APPLICATION FIREWALL BY MOHD IKRAM BIN RAHIMI 2003323326 THESIS PROPOSAL SUBMITTED IN FULFILLMENT OF THE REQUIREMENT FOR BACHELOR OF SCIENCE (Hons.) DATA COMMUNICATION AND NETWORKING FACULTY OF INFORMATION TECHNOLOGY AND QUANTITATIVE SCIENCE UNIVERSITI TEKNOLOGI MARA MAY 2006

WEB APPLICATION FIREWALL By MOHD IKRAM BIN RAHIMI 2003323326 A project paper submitted to FACULTY OF INFORMATION TECHNOLOGY AND QUANTITATIVE SCIENCE UNIVERSITI TEKNOLOGI MARA In partial fulfillment of requirement for the BACHELOR OF SCIENCE (Hons.) IN DATA COMMUNICATION AND NETWORKING Major Area: Security Approved by the examining Committee:.. Prof. Madya Dr Haji Mazani Manaf Project Supervisor Prof. Madya Dr Hajah Saadiah Yahya Project Examiner UNIVERSITI TEKNOLOGI MARA SHAH ALAM, SELANGOR MAY 2006

CERTIFICATION OF ORIGINALITY This is to certify that I am responsible for the work submitted in this project that the originality work is my own except as specified in the references and acknowledgment and that original work contained herein have not been taken or done by unspecified sources or persons... MOHD IKRAM BIN RAHIMI MAY 2006 2003323326 ii

ACKNOWLEDGEMENT First and foremost, all my thanks are due to Allah, the most gracious, most merciful; His grace and guidance has given me the utmost strength to be able to complete my project on time, and without much hustles. I would like to take this opportunity to extent my special thanks and deepest appreciation to my supervisor, Prof. Madya Dr Haji Mazani Abdul Manaf and my examiner, Prof. Madya Dr. Hajah Saadiah Yahya for their guidance and assistance in completing my research project. Without their persistent and untiring guidance and advices, it would certainly almost impossible for me to complete the project. I would like also to express my deepest gratitude to my beloved family; my parents, my brother and my sister-in-law. I m indeed immensely grateful and touch with the patience and support all along during the study period. Finally, I would like to express my gratitude to my friends who are very supportive and helpful and to all those whose names are not mentioned here whom in one way or another had contributed to the success of this project. Wassalam. iii

ABSTRACT The Web Application can easily be attacked by the hackers eventhough with the existence of the normal firewall in the system. This is due to the limitation that the normal firewall does not work in the application layer. The hackers will attack the Web Application using the methods like Structured Query Language (SQL) Injection, Cross Site Scripting (XSS), Command Injection, or Session Manipulation as the normal firewall only open port 80 for Internet connection. Most of the Web Application Firewall is quite costly. There are only few that can be operated under free license. The usage of ModSecurity can solve the problem as it can be downloaded under GNU license. This thesis is attempted to show the benefits of implementing ModSecurity and also the reverse proxy server, instead of just implementing the conventional web server. The penetration test is done to evaluate the performance of the server using this Web Application Firewall. The results showed that ModSecurity and the Reverse Proxy methods can improve the level of security for the web server by forbidding any intrusion to take place through the Web Application. The impacts of the attacks had caused severe damage to the server. The attacks also had congested the physical memory, CPU usage, and CPU clock with or without ModSecurity. iv

TABLE OF CONTENTS CONTENT PAGE CERTIFICATION OF ORIGINALITY ACKNOWLEDGMENT ABSTRACT TABLE OF CONTENTS LIST OF FIGURES LIST OF TABLES LIST OF ABBREVATIONS ii iii iv v viii ix x CHAPTER ONE: INTRODUCTION 1.0 Project Introduction 1 1.1 Project Background 2 1.2 Problem Statement 2 1.3 Project Objectives 3 1.4 Project Scope 3 1.5 Project Significance 3 1.6 Conclusion 4 1.7 Report Structure 4 CHAPTER TWO: LITERATURE REVIEW 2.0 Introduction 6 2.1 Firewall 6 2.2 Web Application Firewall 7 2.3 Normal Firewall Does Not Protect Web 7 Application v

2.4 Common Attacks through Web Application 8 2.4.1 Cross-Site Scripting 8 2.4.2 Injection Attacks 8 2.4.3 Cookie/Session Poisoning 9 2.4.4 Parameter/Form Tampering 9 2.4.5 Buffer Overflow 9 2.4.6 Log Tampering 9 2.4.7 Attack Obfuscation 10 2.5 Reverse Proxy 10 2.5.1 Advantages of Using Reverse Proxy 10 2.5.2 The Function of Reverse Proxy 11 2.6 Introduction to ModSecurity 12 2.7 ModSecurity on Apache Web Server 13 2.8 Tools for Web Server 14 2.8.1 Apache Web Server 14 2.8.2 PHP 14 2.8.3 MySQL 14 2.8.4 PHPbb 14 2.9 Acunetix Web Vulnerability Scanner 15 2.10 Conclusion 16 CHAPTER THREE: METHODOLOGY AND IMPLEMENTATION 3.0 Introduction 17 3.1 Research Approach and Methodology 18 3.1.1 The Planning Phase 20 3.1.1.1 Preliminary Information Gathering 20 3.1.1.2 Software Requirement 21 3.1.1.3 Hardware Requirement 22 3.1.2 Implementation Phase 24 3.1.2.1 Web Server Installation and Configuration 24 vi

3.1.2.2 Installation and Configuration of 25 Reverse Proxy Server 3.1.2.3 Networking Implementation 28 3.1.2.4 Installation of Penetration Test Tool 29 3.1.2.5 System Requirement 30 3.1.2.6 Installation Procedure 30 3.1.3 Analysis 31 3.1.4 Operations and Support 32 3.2 Conclusion 32 CHAPTER FOUR: RESULTS AND FINDINGS 4.0 Introduction 33 4.1 Results and Findings 33 4.1.1 Results before Installation of ModSecurity 33 4.1.2 Results after Installation of ModSecurity 37 4.2 Conclusion 43 CHAPTER FIVE: CONCLUSION AND RECOMMENDATION 5.0 Introduction 45 5.1 Conclusion 45 5.2 Recommendations 46 REFERENCES 47 APPENDICES APPENDIX A: Http.conf configuration file 50 APPENDIX B: Log File for Penetration Test 58 vii

LIST OF FIGURES PAGE Figure 2.1 Implementation of Reverse Proxy at Firewall 11 Figure 2.2 The concept of ModSecurity 13 Figure 3.1 SDLC Phases 17 Figure 3.2 Methodologies and Research Approach Diagram 19 Figure 3.3 Folder of Apache2 26 Figure 3.4 Localhost Powered by Apache 27 Figure 3.5 The Network Diagram 29 Figure 3.6 Acunetix Web Vulnerability Scanner Main Menu 31 Figure 4.1 Front Page of the Forum Website 34 Figure 4.2 PHP Information of the Web Server Attacked 35 by the Hackers Figure 4.3 CPU Information that Has Been Captured by 36 Intruder Figure 4.4 Physical Memory and CPU Usage during the Attacks 37 Figure 4.5 The Forbidden Page that Has Been Patched 38 (PHP Information) Figure 4.6 The Forbidden Page II (CPU Information) 39 Figure 4.7 Scanner Menu 40 Figure 4.8 The Result after the Scan 41 Figure 4.9 The List of Alerts after Scanning 42 Figure 4.10 The Attempted Attack through Cross Site Scripting 43 viii

LIST OF TABLES PAGE Table 3.1 Software Requirement and the Platform Used 21 Table 3.2 Web Server Requirement 22 Table 3.3 Reverse Proxy Server Requirement 22 Table 3.4 Client s Requirement 23 Table 3.5 Network Connection Requirement 23 ix

LIST OF ABBREVATIONS APT Annotation Processing Tool CGI Common Gateway Interface CPU Central Processing Unit FAQ Frequently Asked Questions GNU GNU Not Linux GPL GNU General Public License HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure IMAP Internet Message Access Control IP Internet Protocol MB Mega-Byte NNTP Network News Transfer Protocol ODBC Open Database Connectivity OSI Open System Interconnect PC Personal Computer PHP PHP Hypertext Preprocessor PHPbb PHP Bulletin Board POP3 Post Office Protocol 3 POST Power on-self Test SDLC System Development Life Cycle SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SQL Structured Query Language URL Uniform Resource Locator WAF Web Application Firewall XML Extensible Markup Language XML-RPC XML-Remote Procedure Calling XSS Cross Site Scripting x

CHAPTER 1 INTRODUCTION 1.0 Project Introduction Firewall is a system designed to prevent unauthorized access to or from a private network. Firewalls can be installed in both hardware and software, or a combination of both. Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets. All messages entering or leaving the intranet pass through the firewall, which examines each message and blocks those that do not meet the specified security criteria. Usually, the firewall will only allow port 80 for internet connection and blocks other ports. To a certain extent, it is known that web applications are insecure. As port 80 is the only port available for Internet connection, the hackers will intrude the application layer by using Buffer Overflow, Structured Query Language (SQL) injection, Cross Site Scripting (XSS), Command Injection, and Session Manipulation. Generally, companies always have secured networks with insecure applications where this will possibly jeopardize all the companies system. The usage of ModSecurity, one of the Web Application Firewall can prevent such attacks from damaging the whole system. The main advantage of the tool is that it can be downloaded from internet under GNU license where this Web Application Firewall is considered to be secured. It is the best tool for both Intrusion Detection and Intrusion Prevention. 1

1.1 Project Background The vulnerabilities from the exploits of the Web Application are on the rise. Most of the exploits targeted Web Applications such as Wordpress, PHPbb, and XML- RPC. It is understood that there are a lot of firewalls to analyse and filter the traffic at the network layer, but there is limitation of options at the application layer. Furthermore, there are only few free and open tools that can be used to protect the Web Application. This project used ModSecurity to protect the Web Application from the attacks. The project focused on the implementation of the Internet environment, installation and configuration of ModSecurity, and the use of Reverse Proxy method on the web server. Besides, the analysis will be carried out to determine the attacks on the server. The testing of the tools will be able to prove the benefits, in respect of security of Web Application. 1.2 Problem Statement Most of the firewall solutions deal with the network layer. It gives full protection to the lower layer. The hacker will take the opportunity to intrude port 80 by using certain types of attacks as the normal firewall will open the port for Internet connection. Currently, there are a lot of web application firewalls but most of them are quite costly. There are only few tools that can be operated with free license. The conventional web server can easily be attacked as it is directly connected to the internet. The vulnerabilities of the Web Application can be manipulated by the hackers in the application layer. 2

1.3 Project Objectives The main objectives of this study are as follows: 1. To study the vulnerabilities of Web Application and the methods that can be used to overcome the problems. 2. To install, configure, and implement the network environment that experiments the Web Application Firewall. 3. To test and make a comparison between the usage of the Web Application Firewall and conventional Web Application setup. 1.4 Project Scope This project focus on Web Application Firewall as presently there are complete package that been embedded in the tool known as Server Application Firewall. It uses ModSecurity as a Web Application Firewall in order to filter the possible attacks by the hackers. ModSecurity serves as an additional module in Apache HTTP Web Server. The tests are then conducted through the penetration test and the network traffic is scanned by using the tool called Acunetix Web Vulnerabilities Scanner. 1.5 Project Significance The project will able to prove the effectiveness of Web Application Firewall as this technology is still new in Malaysia. In this regard, ModSecurity has been introduced quite sometime ago and can be used either in small, medium or huge capacity server. 3

It is envisaged that the project would be able to cut down the maintenance cost as the tool used can be easily downloaded from the Internet under GNU License. It can also provide as a good documentation for those who want to use this tool. 1.6 Conclusion Web Application Firewall using ModSecurity gives huge benefits to network security as it is free, uncomplicated and considered as one of the effective tool to prevent the attacks at the application layer. As ModSecurity is still new in Malaysia, there is a need to test this tool in order to prove its reliability. 1.7 Report Structure This report consists of five major chapters as follows: Chapter 1: Introduction This chapter discussed general backgrounds of the project. It contains introduction, background, problem statement, objectives, scope, and significance of the project. Chapter 2: Literature Review This chapter briefly explained about the literature review that related to this project. It clarified the definition of Web Application Firewall, how its work and determined the current problem with regard to the vulnerabilities of the web server. It also discussed the function of ModSecurity and how it can protect the web server from malicious attacks through Application Layer. It will also briefly describe the penetration testing tool that was used in this project, Acunetix Web 4

Vulnerabilities Scanner. There are also the descriptions of Apache Web Server and the concept of reverse proxy. Chapter 3: Methodology and Implementation This chapter discussed the methodology that has been used to complete the project. The project was based on System Development Life Cycle (SDLC). It covered the aspects of planning, configuration, implementation of the project, and operation and support. It gave the detailed explanation on how the project had been setup. The methods used would ensure the project objectives can be achieved successfully. Chapter 4: Findings and Results This chapter focused on the result that has been obtained from the experiments and the observations made from the test. The comparison is made between the web server with ModSecurity application and the web server that is directly connected to the Internet. The observations also will cover other factors such as the CPU usage, CPU clock, and physical memory usage. Chapter 5: Conclusion and Recommendation In Chapter 5, all findings will be examined and clarified. Project deliverables will be determined in terms of its successfulness to meet the project objectives. The constraints of the project will also be identified. Finally, conclusion and recommendations will be made to enhance the project for the future undertaking. 5

CHAPTER 2 LITERATURE REVIEW 2.0 Introduction The literature review was organized into several subject areas that are related to this project. It will review the concepts of the undertaken projects as to assist its overall implementation. The references made would be able to clarify and understand various aspects of the project such as the concept of firewall and Web Application Firewall, ModSecurity as a effective Web Application Firewall, the problems with regard to the vulnerabilities of the web server, the concept of proxy server and reverse proxy, and also the penetration testing tools, that is Acunetix Web Vulnerability Scanner. 2.1 Firewall Techtarget (2003) defined firewall as a set of related programs, located at a network gateway server that protects the resources of a private network from users of other networks. The term also implies the security policy that is used with the programs. An enterprise with an intranet that allows its workers access to the wider Internet installs a firewall to prevent outsiders from accessing its own private data resources and for controlling the outside resources that its own users have access to. Basically, a firewall, working closely with a router program, examines each network packet to determine whether to forward it toward its destination. A firewall also includes or works with a proxy server that makes network requests on behalf of workstation users. A firewall is often installed in a specially 6

designated computer separate from the rest of the network so that no incoming request can get directly at private network resources. 2.2 Web Application Firewall According to Web Application Security Consortium (2005), Web Application Firewall is an intermediary device, sitting between a web-client and a web server, analyzing OSI Layer-7 messages for violations in the programmed security policy. A web application firewall is used as a security device protecting web server from attack. Web Application Firewalls are often called 'Deep Packet Inspection Firewalls' because they look at every request and response within the HTTP/HTTPS/SOAP/XML-RPC/Web Service layers. Some Web Application Firewalls look for certain 'attack signatures' to try to identify a specific attack that an intruder may be sending, while others look for abnormal behavior that does not fit the websites normal traffic patterns. Web Application Firewalls can be either software, or hardware appliances based and are installed in front of a web server in an effort to try and shield it from incoming attacks. 2.3 Normal Firewall Does Not Protect Web Application There are differences between normal firewall and web application firewall. The normal firewall deals with network layer (Layer-3 OSI) while web application firewall deals with application layer (Layer-7 OSI). Netcontinuum (2003) described that there is seven reasons the normal firewall do not protect web application. First, the network firewall is entirely blind to encrypted web traffic. Second, common application encoding schemes easily bypass the network firewall as well. Third, network firewall was designed before the web was invented. Fourth, the network firewall cannot protect the user from 7

entire categories of threats. Fifth, the application protection features offered by leading network firewalls are impractical for all but the simplest environment. Sixth, the network firewall with deep inspection would not scale. Lastly, even at their best, network firewalls will never able to improve the performance of application infrastructure. 2.4 Common Attacks through Web Application There are various techniques that the hackers use to attack the web application. The attacks will have significant impacts on the web server. 2.4.1 Cross-Site Scripting Cross-site scripting vulnerabilities occur when an attacker uses a web application to send malicious code, generally in the form of a script, to a different end user. Cross-Site Scripting takes advantage of a vulnerable web site to attack clients who visit that web site. The most frequent goal is to steal the credentials of users who visit the site. 2.4.2 Injection Attacks Many web applications uses operating system features, databases and other external programs to perform their functions. Injection flaws allow attackers to relay malicious code through a web application to another system. These attacks include calls to the operating system via system calls, shell commands, and calls to backend databases via SQL (i.e., SQL injection). Whole scripts written in perl, python, and other languages can also be injected into poorly designed applications and executed. Any time a web 8

application uses an interpreter of any type, it introduces the possibility of an injection attack. 2.4.3 Cookie/Session Poisoning Cookies are often used to transmit sensitive credentials, and are often easily modified to escalate access or assume another user's identity. 2.4.4 Parameter/Form Tampering Parameters used in URLs, HTTP headers, and forms are often used to control and validate access to sensitive information. 2.4.5 Buffer Overflow Most web applications have fixed-size buffers that hold data in memory. A buffer overflow occurs when an attacker sends more data to the buffer than it was intended to hold. This extra data then overflows to adjacent buffers and can be executed as if it were a program. Buffer overflows provide the hacker with a means to launch malicious code on the targeted web server. That code may include commands to steal passwords or confidential information, alter system configurations, install backdoors, or launch other attacks. Almost all known web servers, application servers and web application environments are susceptible to buffer overflows. 2.4.6 Log Tampering Erasing and tampering with transaction logs allows an attacker to cover their tracks or alter web transaction records. 9

2.4.7 Attack Obfuscation Hackers frequently disguise attacks by encoding their requests with methods like URL encoding or Unicode. 2.5 Reverse Proxy According to Art Stricek (2002), Reverse Proxy proxies on behalf of the backend HTTP server not on behalf the outside client s request, hence the term reverses. It is an application proxy for servers using the HTTP protocol. It acts as a gateway to an HTTP server or HTTP server farm by acting as the final IP address for requests from the outside. The firewall works tightly with the Reverse Proxy to help ensure that only the Reverse Proxy can access the HTTP servers hidden behind it. From the outside client s point of view, the Reverse Proxy is the actual HTTP server. 2.5.1 Advantages of Using Reverse Proxy According to Prentice Hall PTR (2004), one of the biggest benefits of having a reverse proxy configuration is that the clients have a single point of access to the web servers. This obviously adds a second layer of security that allows the system administrator to track and contain an attack against the servers. A system administrator can control over who can access the servers and what content the users can be allowed to access. Another great benefit is that outsiders are not aware of the names of the servers that are proxying. This administrator will easily replace servers or make host name changes since the rules or "mappings" are handled by the reverse proxy. This does not affect outside clients. 10

The idea of setting up an architecture with a single point of access helps in the load balancing and failover. For companies concerned with hardware costs, leveraging a reverse proxy can significantly lower hardware cost because it eliminates the need to have separate hardware and software for internal and external users. Internal and external users can access the same servers using the same HTTP requests. This method also eliminates the need to have different hardware to store data for internal and external users. The reverse proxy is capable of securing the back-end data that is required to service an HTTP application without exposing any information to outside world. 2.5.2 The Function of Reverse Proxy Noordergraaf (2000) stated that when a client makes a request to the web site, the request goes to the proxy server. The proxy server then sends the client's request through a specific path in the firewall back to the content web server. The content web server passes the result through the path back to the proxy. The proxy sends the retrieved information to the client, as if the proxy were the actual content server. Figure 2.1: Implementation of Reverse Proxy at Firewall (Sun Microsystem) 11

If the content web server returns an error message, the proxy server can intercept the message and change any URLs listed in the headers before sending the message to the client. This prevents external clients from getting redirection URLs to the internal content server. Since a reverse proxy server potentially allows access to internal hosts, disabling generic (forward) proxying on the proxy server, or applying appropriate access controls if they are enabled, is important. The firewall should be configured so that it allows connections from the reverse proxy to the content web servers exclusively, and not to any other internal resources. The proxy server's configuration should not allow generic proxy requests. It should only allow reverse proxy requests and remap them appropriately to the content web servers. 2.6 Introduction to ModSecurity Thinking Stone (2003) indicates that ModSecurity is an open source intrusion detection and prevention engine for web applications. It can also be called an web application firewall. It operates embedded into the web server, acting as a powerful umbrella, shielding applications from attacks. ModSecurity integrates with the web server, increasing the ability of the server to deal with the web attacks. Some of its features are listed as follows : Request filtering; incoming requests are analysed as they come in, and before they get handled by the web server or other modules. (Strictly speaking, some processing is done on the request before it reaches ModSecurity but that is unavoidable in the embedded mode of operation.) Anti-evasion techniques; paths and parameters are normalised before analysis takes place in order to fight evasion techniques. Understanding of the HTTP protocol; since the engine understands HTTP, it performs very specific and fine granulated filtering. For example, it is possible to look at individual parameters, or named cookie values. 12

POST payload analysis; the engine will intercept the contents transmitted using the POST method. Audit logging; full details of every request (including POST) can be logged for forensic analysis later. HTTPS filtering; since the engine is embedded in the web server, it gets access to request data after decryption takes place. Compressed content filtering; same as above, the security engine has access to request data after decompression takes place. ModSecurity can be used to detect attacks, or to detect and prevent attacks. It is available under two licences. Users can choose to use the software under GNU General Public License, or other variety of commercial licences. Figure 2.2: The concept of ModSecurity (Thinking Stone) 2.7 ModSecurity on Apache Web Server Apache Lounge Group has developed a project of ModSecurity on Apache Web Server. They created ModSecurity as a module in Apache Web Server. Apache Lounge also developed the project, so that the user can use ModSecurity, either in Linux or Windows platform. 13