ADMIN

Recommendations

Info

nutS And boltS modSecurity © KrishnaKumar Sivaraman, 123RF.com Protecting web servers with ModSecurity Apache Protector even securely configured and patched web servers can be compromised because of vulnerabilities in a web application. modSecurity is an Apache extension that acts as a web application firewall to protect the web server against attacks. by Sebastian wolfgarten Security issues on the web are no longer typically a result of poor configuration or the lack of up-to-date server software. Tomcat, Apache, and even IIS have become extremely mature over the past few years – so much so that they don’t have any noticeable vulnerabilities, although exceptions can always turn up to prove the rule. Thus, hackers have turned their attention to the web applications and scripts running on the servers. Increasingly complex user requirements are making web applications more complex, too: Ajax, interaction with external databases, back-end interfaces, and directory services are just part of the package for a modern application. And, attack vectors grow to match this development (see the “Attacks on Web Servers” box). Firewalls for the Web In contrast to legacy packet filters, Web Application Firewalls (WAFs) don’t inspect data in the network or transport layer, but rather at the HTTP protocol level (i.e., in OSI Layer 7) [1]. They actually speak HTTP. For this to happen, these firewalls analyze incoming and outgoing client requests and server responses to distinguish between benevolent and malevolent requests on the basis of rules. If necessary, they can even launch countermeasures; if configured to do so, the software will also inspect encrypted HTTPS connections. Accessories en Masse Where classical network-based firewalls – I’m exaggerating slightly here – either permit any or no HTTP connections, WAFs target individual HTTP connections based on their content. ModSecurity is a highperformance WAF for Apache and a complex module for the Apache web server. Originally developed by Ivan Ristic, Breach Security handles its distribution and development [2]. Two variants of the software are available: the open source variant released under the GPLv2, and a commercial version with professional support, pre-configured appliances, and management consoles. ModSecurity runs on Linux, Solaris, FreeBSD, OpenBSD, NetBSD, AIX, and Windows, with the later versions only available for Apache 2.x. This article discusses version 2.5.10; the successor 2.5.11 is merely a bugfix. The software’s functional scope is enormous but comprehensively documented [3]. It logs HTTP requests and gives administrators unrestricted access to the individual elements of a request, such as the content of a POST request. It also identifies attacks in real time based on positive or negative security models and detects anomalies based on supplied patterns for known vulnerabilities. The powerful rules discover whether credit cards are in the data stream or use GeoIP to prevent access from certain regions. ModSecurity checks not only incoming requests but also the server’s outgoing responses. The software can implement chroot environments. As a reverse proxy, it protects web applications on other web servers, such as Tomcat or IIS. Breach also provides a collection of core rules that guarantees the basic security of the web server. Comprehensive documentation, many examples, and a mailing list provide support for the user. This makes Mod- Security a good choice for protecting web servers and their applications against vulnerabilities. But before you can even consider tackling the highly 86 Admin 01 www.Admin-mAgAzine.com
modSecurity nutS And boltS complex configuration, you first need to install the third-party module. Packages for any Distribution If you prefer not to build the package for Apache 2 yourself, you can pick up pre-built packages for Debian, RHEL, CentOS, Fedora, FreeBSD, Gentoo, and Windows. The manual install requires the Apache mod_unique_id module, which is not automatically provided by some distributions. You can use the LoadModule security2_module U modules/mod_security2.so directive to integrate the module into the Apache configuration file, httpd. conf, if your distribution doesn’t do this for you. After restarting, the web server lists the module in its error_log. Filter Rules ModSecurity has a mass of configuration options, but to understand how it works, all you need is the basic configuration. The SecRuleEngine option activates the module’s filter mechanism and allows it to process filter rules. The settings here are On, Off, and DetectionOnly, which tells the module to monitor, but not become actively involved with, the clientserver connection, even if individual rules are configured to let it do so. This setting is useful for testing the module and your own rules. To help you get started, or for debugging, you also want to enable the SecDebugLog option to define a troubleshooting log (e.g., SecDebugLog /var/log/httpd/modsec_debug.log). Additionally, you can set the SecDebugLogLevel parameter to specify verbosity, on a scale of 0 to 9, which issues comments on its own activities and the way it processes user-defined rules. Levels 4 or 5 are useful for fine tuning or troubleshooting. In production, set this parameter to 0. The SecDefaultAction parameter defines ModSecurity’s default behavior for requests that match a filter rule Attacks on web Servers Compared with local applications, web applications are more vulnerable because they involve so many different components – from the browser and the Internet infrastructure to the web server and the back ends beyond. Vulnerabilities can occur anywhere, but the server is always at the center of this environment. If the web application doesn’t sufficiently validate user input and instead passes it to a database running in the background, attackers could use SQL injection to inject their own commands into the command chain. Thus, the attacker would be able to read, modify, or delete data and thereby exert a major influence on the application. If an application also allows attackers to store files on the web server and execute them over the web, the intruder could set up a web shell. Because the server will execute the attacker’s files, the attacker can run operating system commands on the web server and finally escalate their privileges to interactive shell access. Although the architecture of a carefully configured Apache will not give the attacker root access, this is often unnecessary to access sensitive data. And the more services that are installed on the server, the more likely it is that the attacker will find one that is vulnerable. without a corresponding action. The option also expects you to specify a processing phase for the standard action, as listed in Table 1. ModSecurity applies filter rules in five different phases of processing and responding to a client request [4]. In real life, only phase 2, in which the client requests that content (i.e., incoming data) is filtered, and phase 4, which handles the server response (i.e., outgoing data), are relevant. Additionally, you can use the option to define one or multiple actions that the software will perform when a match occurs [5]. To log incoming client requests in the auditlog in phase 2 and respond to the access attempt with a HTTP 403 (Forbidden) error message, you would do this: SecDefaultAction phase:2,log,U auditlog,deny,status:403 A massively negative default function like the default deny is highly restrictive, but it does offer maximum protection if you additionally define Table 1: modSecurity Processing Phases filters and actions (see also the “Insider Attacks” box). The software offers a number of prebuilt alternatives here, including converting request parameters, running external scripts (e.g., to perform an antivirus scan), or forwarding malevolent requests. The latter is useful if you are trying to investigate attacks or want to forward them to a honeypot. The basic configuration (Listing 1) also logs the contents of incoming requests and the responses given in return. It enters the information in the auditlog as mentioned previously. The first directive, Sec AuditEngine, enables this. The option for the second directive defines whether the software stores the auditlog entries in a single file (Serial) or writes a file for each transaction (Concurrent). Concurrency is necessary if you intend to deploy the ModSecurity Console addon product. Breach Security offers the software for managing multiple instances, provided you don’t need to monitor more than three servers. E Number Phase Designator Activities 1 Preview phase REQUEST_HEADERS Earliest possible filtering of incoming requests before access control, authentication, authorization, and MIME detection have taken place Apache‐side 2 Client request REQUEST_BODY Full access to the content of a client request (normal case) 3 POST request RESPONSE_HEADERS Initial option for filtering server responses 4 Server response RESPONSE_BODY Full access to the content of the server response to an incoming client request 5 Logging LOGGING Access to all relevant information before it is written to the Apache logfiles www.Admin-mAgAzine.com Admin 01 87
Page 1 and 2:
ADMIN Network & Security Rescue CD
Page 3 and 4:
Welcome to Admin WELCOME ALL FOR AD
Page 5 and 6:
Table of Contents SERVICE 8 Spacewa
Page 7 and 8:
POWERHOUSE PERL 11 cool projects! F
Page 9 and 10:
Spacewalk Features configuration fi
Page 11 and 12:
Spacewalk Features Figure 2: Assign
Page 13 and 14:
Spacewalk Features kickstart profil
Page 15 and 16:
Icinga Features Table 1: States Opt
Page 17 and 18:
Icinga Features ministrators only n
Page 19 and 20:
Icinga Features Figure 6: Network o
Page 21 and 22:
MySQL Forks and Patches Features th
Page 23 and 24:
MySQL Forks and Patches Features In
Page 25 and 26:
Exchange 2010 Features © peapop, F
Page 27 and 28:
they can now synchronize text messa
Page 29 and 30:
Backup Software Features data. One
Page 31 and 32:
Backup Software Features tended), l
Page 33 and 34:
Backup Software Features Two “wiz
Page 35 and 36: Backup & Disaster Recovery Georgeto
Page 37 and 38: OCFS2 Tools ing. OCFS2 is fairly si
Page 39 and 40: OCFS2 Tools F Figure 2: Unspectacul
Page 41 and 42: To do this, you need to change the
Page 43 and 44: Synergy Tools Figure 1: Synergy as
Page 45 and 46: SystemTap Tools The SystemTap [3] t
Page 47 and 48: SystemTap Tools Instead of searchin
Page 49 and 50: Package Your Scripts Virtualization
Page 51 and 52: Linux Magazine ACADEMY curl U http:
Page 53 and 54: openVz VirtuAlizAtion live migratio
Page 55 and 56: OpenVZ Virtualization a number of c
Page 57 and 58: OpenVZ Virtualization OpenVZ kernel
Page 59 and 60: AND SAVE 30%! ADMIN Network & Secur
Page 61 and 62: Virtual Machine Manager Virtualizat
Page 63 and 64: Virtual Machine Manager Virtualizat
Page 65 and 66: Teamviewer Management and be contro
Page 67 and 68: NOV. 7-12 2010 24th Large Installat
Page 69 and 70: Chef Management Server Provides rec
Page 71 and 72: Chef Management ‐r http://s3.amaz
Page 73 and 74: Chef Management Figure 5: The clien
Page 75 and 76: Sysinternals Management AdInsight a
Page 77 and 78: Sysinternals Management Name Table
Page 79 and 80: PAM and Hardware Nuts and Bolts Fig
Page 81 and 82: November 13-19, 2010 • Ernest N.
Page 83 and 84: PAM and Hardware Nuts and Bolts to
Page 85: ON NEWSSTANDS NOW ! UBUNTU USER MAG
Page 89 and 90: ModSecurity Nuts and bolts Insider
Page 91 and 92: REAL SOLUTIONS FOR REAL NETWORKS Ea
Page 93 and 94: Daemon Monitoring Nuts and Bolts Fi
Page 95 and 96: VPns with SSTP nuTS And BoLTS Hands
Page 97 and 98: VPNs with SSTP Nuts and Bolts Figur
Page 100: DEDICATED SERVERS £59 FROM PER MON
show all

ADMIN

Create successful ePaper yourself

Delete template?

Save as template?