ModSecurity Handbook：Web应用防护深入指南

5星 · 超过95%的资源需积分: 10 14 浏览量更新于2024-07-21 1 收藏 1.78MB PDF 举报

"《ModSecurity Handbook》是一本详细介绍如何使用ModSecurity来保护Web应用程序的英文手册。这本书由Ivan Ristic编写，旨在提供一个全面的指南来帮助读者理解并实施Web应用安全防护。本书适用于对Web安全感兴趣的管理员、开发者以及网络安全专业人员。书中涵盖了ModSecurity的起源、工作原理、主要功能、安装过程、配置方法等内容，并提到了一些相关的项目和资源，以供深入学习和研究。" 在《ModSecurity Handbook》中，作者首先介绍了ModSecurity的基本信息。ModSecurity是一个开源的入侵检测与防御系统，它作为一个Web应用程序防火墙，可以嵌入到Web服务器（如Apache）中，对HTTP请求进行深度检测，防止Web应用受到攻击。其关键特性包括： 1. **请求过滤**：在请求到达其他服务器模块处理之前，对输入的请求进行分析，提供了一层额外的安全保障。 2. **反规避技术**：对路径和参数进行规范化处理，以对抗规避策略。 3. **HTTP协议理解**：能够深入解析HTTP协议，对单独参数、特定Cookie值等进行细致过滤。 4. **POST数据分析**：能捕获并分析通过POST方法发送的数据。 5. **审计记录**：详尽记录每个请求，包括POST请求，便于进行日志分析和法律取证。 6. **HTTPS过滤**：在解密HTTPS请求后进行过滤，确保对加密内容的保护。 7. **压缩内容过滤**：在解压缩后，安全引擎可以访问并处理压缩内容。书中的第一部分是用户指南，包括ModSecurity的简史、工作原理、规则结构、事务生命周期、对Web服务器的影响、运行模式（嵌入式与反向代理模式）以及ModSecurity的局限性。此外，还列举了相关的资源，包括一般资源、开发者资源和相关项目，以供进一步学习和探索。第二部分涉及ModSecurity的安装过程，详细介绍了从源码编译安装、从二进制包安装以及在不同操作系统（如Fedora、CentOS、Red Hat Enterprise Linux、Debian、Ubuntu和Windows）上的安装步骤。第三部分则是配置指南，讨论了配置文件的存放位置、布局以及如何将ModSecurity添加到Apache服务器的配置中。这本书提供了全面的ModSecurity使用指南，对于想要提升Web应用程序安全性的读者来说，是一份极其宝贵的资源。

Preface

[...]

Audience

[...]

Contents of This Book

[...]

Updates

[...]

Conventions

[...]

Acknowledgements

[...]

1 Introduction

ModSecurity is a tool that will help you secure your web applications. No, scratch that.

Actually, ModSecurity is a tool that will help you sleep better at night, and I will explain

how. I usually call ModSecurity a web application ﬁrewall (WAF), because that’s the generally

accepted term to refer to the class of products that are speciﬁcally designed to secure web

applications. Other times I will call it an HTTP intrusion detection tool, because I think that

name better describes what ModSecurity does. Neither name is entirely adequate, yet we

don’t have a better one. Besides, it doesn’t really matter what we call it. The point is that

web applications—yours, mine, everyone’s—are terribly insecure on average. We struggle

to keep up with the security issues and need any help we can get to secure them.

The idea to write ModSecurity came to me during one of my sleepless nights—I couldn’t

sleep because I was responsible for the security of several web-based products. I could see the

web application security storm on the horizon. (We were then largely in the age of innocence

when it came to web application security.) I could see how most web applications were just

slapped together with little time spent on design and little time spent on understanding the

security issues. Furthermore, not only were web applications insecure, but we had no idea

how insecure they were or if they were being attacked. Our only eyes were the web server

access and error logs, and they didn’t say much.

Which brings me to my point. ModSecurity will help you sleep better at night because,

above all, it solves the visibility problem: it lets you see your web trafﬁc. That visibility is

key to security: once you are able to see HTTP trafﬁc, you are able to analyze it in real time,

record it as necessary, and react to the events. The best part of this concept is that you get

to do all of that without actually touching web applications. Even better, the concept can be

applied to any application—even the one to which you don’t have access to the source code.

There are four guiding principles on which ModSecurity is based, as follows:

Flexibility

I think that it’s fair to say that I built ModSecurity for myself: a security expert who

needs to intercept, analyze, and store HTTP trafﬁc. I didn’t see much value in hard-

Brief History 3

coded functionality, because real life is so complex that everyone needs to do things

just slightly differently. ModSecurity achieves ﬂexibility by giving you a powerful rule

language, which allows you to do exactly what you need to, in combination with the

ability to apply rules only where you need to.

Passiveness

ModSecurity will take great care to never interact with a transaction unless you tell it

to. That is simply because I didn’t trust a tool, even the one I built, to make decisions

for me. That’s why ModSecurity will give you plenty of information, but ultimately

leave the decisions to you.

Predictability

There’s no such thing as a perfect tool, but a predictable one is the next best thing.

Armed with all the facts, which you will ﬁnd in the reference manual, the posts on

the ModSecurity Blog, or here, you can understand ModSecurity’s weak points and

work around them.

Feature quality over quantity

Over the course of six years spent working on ModSecurity, we came up with many

ideas for what ModSecurity could do. We didn’t act on most of them. We kept them

for later. Why? Because we understood that we have limited resources available at our

disposal and that our minds (ideas) are far faster than our implementation abilities.

We chose to limit the available functionality, but do really well at what we decided

to keep in.

There are bits in ModSecurity that fall outside the scope of these four principles. For exam-

ple, ModSecurity can change the way Apache identiﬁes itself to the outside world, conﬁne

the Apache process within a jail, and even implement an elaborate scheme to deal with an

once-infamous universal XSS vulnerability in Adobe Reader. Although it was I who added

those features, I now think that they detract from the main purpose of ModSecurity, which

is a reliable and predictable tool that allows for HTTP trafﬁc inspection.

Brief History

Like many other open source projects, ModSecurity started out as a hobby. Software devel-

opment had been my primary concern back in 2002, when I realized that producing secure

web applications is virtually impossible. As a result, I started to fantasize about a tool that

would sit in front of web applications and control the ﬂow of data in and out. The ﬁrst ver-

sion was released in November 2002, but a few more months were needed before the tool

became useful. Other people started to learn about it, and the popularity of ModSecurity

started to rise.

4 Chapter 1: Introduction

Initially, most of my work was spent wrestling with Apache to gain access to request bodies,

which was a crucial ability. Apache 1.3.x did not have any interception or ﬁltering APIs,

but I was able to trick it into submission. Apache 2.x improved things by providing APIs

that do allow content interception, but there was no documentation to speak of. Nick Kew’s

excellent The Apache Modules Book (Prentice Hall) came out in 2007, by which time it was

too late.

By 2004, I was a changed man. Once primarily a software developer, I became obsessed

with web application security and wanted to spend more time working on it. I quit my

job and started treating ModSecurity as a business. My big reward came in the summer

of 2006, when ModSecurity went head to head with other web application ﬁrewalls, in an

evaluation conducted byForrester Research, and came out very favorably. Later that year,

my company was acquired by Breach Security. A team of one eventually become a team of

many: Brian Rectanus came to work on ModSecurity, Ofer Shezaf took on the rules, and

Ryan C. Barnett the community management and education. ModSecurity 2.0, a complete

rewrite, was released in late 2006. At the same time we released ModSecurity Community

Console, which combined the functionality of a remote logging sensor and a monitoring

and reporting GUI.

The last major update of ModSecurity was 2.5, released in February 2008. There have been

11 maintenance releases since. ModSecurity 2.5.11 (released in November 2009) is the most

recent version at the time of writing.

Since leaving Breach Security in January 2009, I am no longer in charge of ModSecurity, but

it remains in the capable hands of Brian Rectanus and Ryan C. Barnett. I remain involved

and contribute from time to time.

Understanding ModSecurity

ModSecurity is a hybrid web application ﬁrewall that relies on the host web server for some

of the work. The only supported web server at the moment is Apache 2.x, but it is possible,

in principle, to integrate ModSecurity with any other web server that provides sufﬁcient

integration APIs.

Apache does for ModSecurity what it does for all other modules—it handles the infrastruc-

ture tasks:

1. Decrypts SSL

2. Breaks up the inbound connection stream into HTTP requests

3. Partially parses HTTP requests

剩余306页未读，继续阅读

tekin

粉丝: 3124
资源: 39

ModSecurity Handbook：Web应用防护深入指南

ModSecurity Handbook: 2018版入门指南

ModSecurity Handbook：全方位指南

ModSecurity Handbook - 完整的Web应用安全指南

ModSecurity Handbook(使用手册)

modsecurity handbook

modsecurity handbook英文版

ModSecurity中文使用手册

ModSecurity手册

ModSecurity中文手册.doc

ModSecurity中文安装帮助手册

最新资源