apache httpd sever在debian下的部署和配置以及最重要的常见漏洞解析

最新推荐文章于 2024-09-26 00:45:00 发布

不想出差

最新推荐文章于 2024-09-26 00:45:00 发布

阅读量1.1k

点赞数

文章标签： apache 服务器运维

本文链接：https://blog.csdn.net/qtttgeq/article/details/130097686

版权

Apache httpd 简介

Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充，将Perl/Python等解释器编译到服务器中。同时Apache音译为阿帕奇，是北美印第安人的一个部落，叫阿帕奇族，在美国的西南部。也是一个基金会的名称、一种武装直升机等等。

Apache的特点是简单、速度快、性能稳定，并可做代理服务器来使用。它可以在大多数计算机操作系统中运行，由于其跨平台和安全性被广泛使用。

企业中常用的web服务，用来提供http：//（超文本传输协议）

apache httpd和nginx的区别？

Apache和Nginx都属于Web服务器，两者都实现了HTTP 1.1协议。无论是选择哪个，都是根据应用场景来决定的，所以仅从应用场景出发，来对比两者之间的各自特点。要让正确的工具，做出正确的事。

详细参考此文章：nginx与Apache的对比以及优缺点 - _萨瓦迪卡 - 博客园 (cnblogs.com)

我们来简述几点：

两者最核心的区别在于 apache 是同步多进程模型，一个连接对应一个进程，而 nginx 是异步的，多个连接（万级别）可以对应一个进程

一般来说，需要性能的 web 服务，用 nginx 。如果不需要性能只求稳定，更考虑 apache ，后者的各种功能模块实现得比前者，例如 ssl 的模块就比前者好，可配置项多。epoll(freebsd 上是 kqueue ) 网络 IO 模型是 nginx 处理性能高的根本理由，但并不是所有的情况下都是 epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的 select 模型或许比 epoll 更高性能。当然，这只是根据网络 IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。

更为通用的方案是，前端Nginx抗并发，后端apache集群，配合起来会更好。

总结两者优缺点比较：

　　1.Nginx 配置简洁, Apache 复杂 ;Nginx 静态处理性能比 Apache 高 2倍以上 ;

　　2.Apache 对 PHP 支持比较简单，Nginx 需要配合其他后端用；Apache 的组件比 Nginx 多 ;

　　3.apache是同步多进程模型，一个连接对应一个进程；Nginx是异步的，多个连接(万级别)可以对应一个进程；

　　4.Nginx处理静态文件好，耗费内存少；动态请求由apache去做，Nginx只适合静态和反向；

　　5.Nginx适合做前端服务器，负载性能很好；Nginx本身就是一个反向代理服务器，且支持负载均衡。

apache

不同于nginx的是，apache是模块化的，可以参考如下：

        +----------+
      +- | Module   | -----------------+
      |  +----------+                  |
      |                          +------------+
+-----------+   Apache HTTPD     | php module |
| Module    |                    +------------+
+-----------+              +----------+|
      +----------+-------- |  MPM     |+
                 |         +----+---+-+
               +-v-----------+  |   |
               |    ARP      <--+   |
               +------+------+      |
                      |             |
      +---------------v-------------v--+
      |      Operating  System         |
      +--------------------------------+

MPM（Multi -Processing Modules，多重处理模块）是Apache的核心组件之一，Apache通过MPM来使用操作系统的资源，对进程和线程池进行管理。Apache为了能够获得最好的运行性能，针对不同的平台 (Unix/Linux、Window)做了优化，为不同的平台提供了不同的MPM，用户可以根据实际情况进行选择，其中最常使用的MPM有 prefork和worker两种。至于您的服务器正以哪种方式运行，取决于安装Apache过程中指定的MPM编译参数,在X系统上默认的编译参数为 prefork。

由于大多数的Unix都不支持真正的线程，所以采用了预派生子进程(prefork)方式，象Windows或者Solaris这些支持线程的平台，基于多进程多线程混合的worker模式是一种不错的选择。Apache中还有一个重要的组件就是APR（Apache portable Runtime Library），即Apache可移植运行库，它是一个对操作系统调用的抽象库，用来实现Apache内部组件对操作系统的使用，提高系统的可移植性。 Apache对于php的解析，就是通过众多Module中的php Module来完成的。

Apache生命周期：

  +--------------------------------------------------------------+
   |                 +---------------------+       启动阶段        |
   |                 |    系统启动, 配置     |                      |
   |                 +----------+----------+                      |
   |                            |                                 |
   |                 +----------v----------+                      |
   |                 |      模块的初始化     |                      |
   |                 +-+--------+--------+-+                      |
   |                   |        |        |                        |
   |   +-------------+ | +------v-------+| +--------------+       |
   |   | 子进程初始化  |<+ | 子进程初始化   |+>|  子进程初始化  |       |
   |   +------+------+   +-------+------+  +-------+------+       |
   +--------------------------------------------------------------+
   |          |                  |                 |     运行阶段  |
   |     +----v----+        +----v----+       +----v----+         |
   |     | 请求循环 |        |  请求循环 |       | 请求循环 |         |
   |     +----+----+        +----+----+       +----+----+         |
   |          |                  |                 |              |
   |   +------v------+    +------v------+   +------v------+       |
   |   |  子进程结束   |    |  子进程结束  |   |   子进程结束  |       |
   |   +-------------+    +-------------+   +-------------+       |
   +--------------------------------------------------------------+

这个生命周期是在perfork工作下的示意，从图中可以看出，Apache对于每一个请求都要启动一个单独的进程来处理。

Apache的运行

在启动阶段，Apache主要进行配置文件解析(例如http.conf以及Include指令设定的配置文件等)、模块加载(例如mod_php.so,mod_perl.so等)和系统资源初始化（例如日志文件、共享内存段等）工作。在这个阶段，Apache为了获得系统资源最大的使用权限，将以特权用户root（X系统）或超级管理员administrator(Windows系统)完成启动。

这个过程可以通过下图来深入了解：

      +--------+
       |  开始   |
       +----+---+
            |
 +----------v------------+   解析主配置文件http.conf中配置信息，
 |     解析配置文件        |   像LoadModule, AddType
 +----------+------------+   等指令被加载至内存
            |
 +----------v------------+   依据AddModule, LoadModule等指令
 |   加载静态/动态模块      |   加载Apache模块，像mod_php5.so被
 +----------+------------+   加载至内存，映射到Apache地址空间。
            |
 +----------v------------+   日志文件、共享内存段，数据库链接
 |     系统资源初始化      |    等初始化
 +----------+------------+
            |
        +---v----+
        |  结束   |
        +--------+

运行阶段

在运行阶段，Apache主要工作是处理用户的服务请求。在这个阶段，Apache放弃特权用户级别，使用普通权限，这主要是基于安全性的考虑，防止由于代码的缺陷引起的安全漏洞。

由于Apache的Hook机制，Apache 允许模块(包括内部模块和外部模块，例如mod_php5.so,mod_perl.so等)将自定义的函数注入到请求处理循环中。mod_php5.so/php5apache2.dll就是将所包含的自定义函数，通过Hook机制注入到Apache中，在Apache处理流程的各个阶段负责处理php请求。

Apache将请求处理循环分为11个阶段，依次是：Post-Read-Request，URI Translation，Header Parsing，Access Control，Authentication，Authorization，MIME Type Checking，FixUp，Response，Logging，CleanUp。

Nginx

概述

Nginx（发音同engine x）是一款由俄罗斯程序员Igor Sysoev所开发轻量级的网页服务器、反向代理服务器以及电子邮件（IMAP/POP3）代理服务器。起初是供俄国大型的门户网站及搜索引擎Rambler（俄语：Рамблер）使用。

Nginx的模块与工作原理

Nginx由内核和模块组成，其中，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件将客户端请求映射到一个location block（location是Nginx配置中的一个指令，用于URL匹配），而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。

Nginx的模块从结构上分为核心模块、基础模块和第三方模块：

核心模块：HTTP模块、EVENT模块和MAIL模块
基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块，
第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。

Nginx的模块从功能上分为如下三类:

Handlers（处理器模块）。此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
Filters （过滤器模块）。此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
Proxies （代理类模块）。此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。

                    +                    ^
        Http Request |                    |  Http Response
                     |                    |
    +---------+------v-----+         +----+----+
    |  Conf   | Nginx Core |         | FilterN |
    +---------+------+-----+         +----^----+
                     |                    |
                     |               +----+----+
                     |               | Filter2 |
choose a handler     |               +----^----+
based conf           |                    |
                     |               +----+----+
                     |               | Filter1 |
                     |               +----^----+
                     |                    | Generate content
               +-----v--------------------+----+
               |           Handler             |
               +-------------------------------+

Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。

Nginx架构及工作流程

上图是Nginx的架构，这个架构类似于Apache的Worker工作状态，Nginx的每一个Worker进程都管理着大量的线程，真正处理请求的是Worker之下的线程。

所有实际上的业务处理逻辑都在worker进程。worker进程中有一个函数，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个nginx服务被停止。Worker中这个函数执行内容如下：

操作系统提供的机制（例如epoll, kqueue等）产生相关的事件。
接收和处理这些事件，如是接受到数据，则产生更高层的request对象。
处理request的header和body。
产生响应，并发送回客户端。
完成request的处理。
重新初始化定时器及其他事件。

FastCGI

FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口。多数流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等。同时，FastCGI也被许多脚本语言支持，其中就有PHP。

FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能很差，因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析，然后将结果返回给HTTP服务器。这在处理高并发访问时几乎是不可用的。另外传统的CGI接口方式安全性也很差，现在已经很少使用了。

FastCGI接口方式采用C/S结构，可以将HTTP服务器和脚本解析服务器分开，同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时，可以将其直接交付给FastCGI进程来执行，然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端，这在很大程度上提高了整个应用系统的性能。

Nging和FastCGI合作

Nginx不支持对外部程序的直接调用或者解析，所有的外部程序（包括PHP）必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket（这个socket可以是文件socket，也可以是ip socket）。

接下来以Nginx下PHP的运行过程来说明。PHP-FPM是管理FastCGI的一个管理器，它作为PHP的插件存在。

FastCGI进程管理器php-fpm自身初始化，启动主进程php-fpm和启动start_servers个CGI 子进程。主进程php-fpm主要是管理fastcgi子进程，监听9000端口。fastcgi子进程等待来自Web Server的连接。
当客户端请求到达Web Server Nginx是时，Nginx通过location指令，将所有以php为后缀的文件都交给127.0.0.1:9000来处理，即Nginx通过location指令，将所有以php为后缀的文件都交给127.0.0.1:9000来处理。
FastCGI进程管理器PHP-FPM选择并连接到一个子进程CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程。
FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时，请求便告处理完成。
FastCGI子进程接着等待并处理来自FastCGI进程管理器（运行在 WebServer中）的下一个连接。

Apache和Nginx比较

功能对比

Nginx和Apache一样，都是HTTP服务器软件，在功能实现上都采用模块化结构设计，都支持通用的语言接口，如PHP、Perl、Python等，同时还支持正向和反向代理、虚拟主机、URL重写、压缩传输、SSL加密传输等。

在功能实现上，Apache的所有模块都支持动、静态编译，而Nginx模块都是静态编译的，
对FastCGI的支持，Apache对Fcgi的支持不好，而Nginx对Fcgi的支持非常好；
在处理连接方式上，Nginx支持epoll，而Apache却不支持；
在空间使用上，Nginx安装包仅仅只有几百K，和Nginx比起来Apache绝对是庞然大物。

Nginx相对apache的优点

轻量级，同样起web 服务，比apache 占用更少的内存及资源
静态处理，Nginx 静态处理性能比 Apache 高 3倍以上
抗并发，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能。在- - Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。
高度模块化的设计，编写模块相对简单
社区活跃，各种高性能模块出品迅速啊

apache相对nginx的优点

rewrite，比nginx 的rewrite 强大
模块超多，基本想到的都可以找到
少bug，nginx的bug相对较多
超稳定
Apache对PHP支持比较简单，Nginx需要配合其他后端用

选择Nginx的优势所在

作为Web服务器: Nginx处理静态文件、索引文件，自动索引的效率非常高。
作为代理服务器，Nginx可以实现无缓存的反向代理加速，提高网站运行速度。
作为负载均衡服务器，Nginx既可以在内部直接支持Rails和PHP，也可以支持HTTP代理服务器对外进行服务，同时还支持简单的容错和利用算法进行负载均衡。
在性能方面，Nginx是专门为性能优化而开发的，在实现上非常注重效率。它采用内核Poll模型(epoll and kqueue )，可以支持更多的并发连接，最大可以支持对50 000个并发连接数的响应，而且只占用很低的内存资源。
在稳定性方面，Nginx采取了分阶段资源分配技术，使得CPU与内存的占用率非常低。Nginx官方表示，Nginx保持10 000个没有活动的连接，而这些连接只占用2.5MB内存，因此，类似DOS这样的攻击对Nginx来说基本上是没有任何作用的。
在高可用性方面，Nginx支持热部署，启动速度特别迅速，因此可以在不间断服务的情况下，对软件版本或者配置进行升级，即使运行数月也无需重新启动，几乎可以做到7×24小时不间断地运行。

同时使用Nginx和Apache

由于Nginx和Apache各自的优势，现在很多人选择了让两者在服务器中共存。在服务器端让Nginx在前，Apache在后。由Nginx做负载均衡和反向代理，并且处理静态文件，将动态请求（如PHP应用）交给Apache去处理。

以上内容转载至：Nginx 和 Apache 各有什么优缺点？ - 知乎

apache在centos7下的部署：

yum install httpd -y		##apache软件
yum install httpd-manual	##apache的手册
systemctl start httpd 
systemctl enable httpd 
sudo systemctl restart httpd
sudo systemctl reload httpd2 更改配置后重启该服务
sudo systemctl disable httpd httpd服务是默认开机启动的，这个命令可以关掉开机启动
firewall-cmd --list-all				##列出火墙信息
firewall-cmd --permanent --add-service=http		##永久允许http
firewall-cmd --reload				##火墙从新加载策略
/var/www/html				##apache的/目录，默认发布目录
/var/www/html/index.html		##apache的默认发布文件
vim /var/www/html/index.html		##写默认发布文件内容
<h1> hello world </h1>

ok初步部署一键完成。

配置属于自己的个人站点：

1、Apache服务常见配置文件介绍

漏洞解析：

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

Apache HTTPD 换行解析漏洞（CVE-2017-15715）

影响版本：2.4.0~2.4.29 比较新了

漏洞环境：

docker-compose build
docker-compose up -d

1.漏洞原因：

2.漏洞复现：

使用win的宿主机访问docker映射到kali本机的8080口可以看到是一个简单的文件上传页面：

查看源码，使用post方法的一个文件上传表单页面。

我们上传一个.php后缀的文件尝试一下：

返回bad.firle。

显然是在后台做了过滤，回到kali下查看一下：

┌──(root㉿killer)-[~/vulhub/httpd/CVE-2017-15715]
└─# cat index.php                        
<?php
if(isset($_FILES['file'])) {
    $name = basename($_POST['name']);
    $ext = pathinfo($name,PATHINFO_EXTENSION);
    if(in_array($ext, ['php', 'php3', 'php4', 'php5', 'phtml', 'pht'])) {
        exit('bad file');
    }
    move_uploaded_file($_FILES['file']['tmp_name'], './' . $name);
} else {

?>

<!DOCTYPE html>
<html>
<head>
        <title>Upload</title>
</head>
<body>
<form method="POST" enctype="multipart/form-data">
        <p>
                <label>file:<input type="file" name="file"></label>
        </p>
        <p>
                <label>filename:<input type="text" name="name" value="evil.php"></label>
        </p>
        <input type="submit">
</form>
</body>
</html>

<?php
}
?>

ok，上述后缀的文件一概不让传。

如何解决？

简单！我们使用burp抓包在.php的后边加一个\x0A做一个尝试：

ok抓到，尝试修改：

在1.php后面插入一个\x0A（注意，不能是\x0D\x0A，只能是一个\x0A），不再拦截：

ok搞定，我们成功访问到了，存在换行符解析漏洞！

简答来说，正常的网站百分之99是禁用.php后缀的文件的，这是肯定的，如果我们拿到对方中间件的信息发现是拥有换行符解析漏洞的版本2.4.0--2.4.29的apache，那么需要在。php后缀的后边加上一个\x0A，它的后缀会以%0a的方式存在，所以黑名单不会有限制，上传到apache后会对这个后缀做一个截断，以.php的形式解析，在也就可以触发此漏洞拿到webshell！

解决方案：

更新最新版本就好了，解析漏洞也没啥特别好的防御策略，只能是更新

Apache HTTPD 多后缀解析漏洞

Apache HTTPD 支持一个文件拥有多个后缀，并为不同后缀执行不同的指令。比如，如下配置文件： AddType text/html .html

AddLanguage zh-CN .cn

其给.html后缀增加了media-type，值为text/html；给.cn后缀增加了语言，值为zh-CN。此时，如果用户请求文件index.cn.html，他将返回一个中文的html页面。

以上就是Apache多后缀的特性。如果运维人员给.php后缀增加了处理器：

AddHandler application/x-httpd-php .php

那么，在有多个后缀的情况下，只要一个文件含有.php后缀的文件即将被识别成PHP文件，没必要是最后一个后缀。利用这个特性，将会造成一个可以绕过上传白名单的解析漏洞。

通俗来说，解析漏洞一般都是绕过开发或者运维人员设定好的限制，有的为白名单还有聊过的nginx解析漏洞的黑名单等，总的来说就是绕！

本漏洞的具体原理是：因为在apache的配置文件中添加修改了多后缀的功能模块，这导致检测到有.php的文件不管是不是在最后方写着都会被当作php文件来解析

例如：aaa.php.jpg

漏洞环境:

docker-compose up -d

漏洞复现：

使用宿主机访问映射到kali的ip：

这个index.php页面是做了一个白名单机制，但是运维人员给到的限制非常单一，这给了我们绕过的机会，

使用vscode构造了一个PHP info的图片格式，上传：

ok利用多后缀解析漏洞成功拿到了webshell：

解决方案：

这还是由于运维人员的配置不当造成的，他在index.php文件中做了白名单功能，在代码层面看这确实是足够安全的，可忽略了中间件安全同样是非常重要的一个点。

1.直接关闭多后缀解析功能，这是无解的一个点，可以完全避免次漏洞，但是会损失掉足够功能，有利有弊。

2.添加文件内容的检测功能模块，这对一句话木马这种是非常有效的。但这并非最优解，因为我们是可以做图片马的，把一句话木马添加到构造在图片里同样是可以绕过此项限制。那么如何绕过？

简单，在解析图片之前打乱重新排列就好，但是这也有应对的办法，图片文件打乱重新排列会将大多数编码重新构造，但是有一部分核心的编码是不会改变的，木马插入这个地方即可。这块是文件上传技术的内容，这里不做过多叙述，太多了手动狗头~

3更换中间件，这也是无解的一个办法，但是遇到的问题相信也是非常棘手，而且更换中间件意味着可能会遇到其他的漏洞。。。。

总结来说，这事运维人员配置不当造成的，最好还是给这玩意关了。

Apache HTTP Server 2.4.49 路径穿越漏洞（CVE-2021-41773）

Apache HTTP Server是Apache基金会开源的一款流行的HTTP服务器。在其2.4.49版本中，引入了一个路径穿越漏洞，满足下面两个条件的Apache服务器将会受到影响：

版本等于2.4.49
穿越的目录允许被访问，比如配置了<Directory />Require all granted</Directory>。（默认情况下是不允许的）

攻击者利用这个漏洞，可以读取位于Apache服务器Web目录以外的其他文件，或者读取Web目录中的脚本文件源码，或者在开启了cgi或cgid的服务器上执行任意命令。

cgi在百分之99的情况下是未开启的，这玩意是基于c语言写网页的一个东西，基本被淘汰

漏洞环境

执行如下命令编译及运行一个存在漏洞的Apache HTTPd 2.4.49版本服务器：

docker-compose build
docker-compose up -d

环境启动后，访问http://your-ip:8080即可看到Apache默认的It works!页面。

漏洞利用和原理：

使用如下CURL命令来发送Payload（注意其中的/icons/必须是一个存在且可访问的目录）：

curl -v --path-as-is http://your-ip:8080/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

这是个什么东西？url编码的.的意思，转换成常见的utf-8编码为：../

看到这里相信已经基本明了，就是用../不停的穿越目录上下级来获取到apache文件之外的文件，造成任意下载的一个情况

在服务端开启了cgi或cgid这两个mod的情况下，这个路径穿越漏洞将可以执行任意命令：

curl -v --data "echo;id" 'http://your-ip:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

总结：apache路径穿越漏洞是非常新的一个漏洞，由于本身的配置失误和源码失误造成此漏洞，还是建议更新到最新版本来防范，想要利用需要对utf-8的.做url编码来穿越，前提是有足够的权限来访问etc目录，但大多数情况下默认是有访问权限的。

最大的前提是你在穿越目录之前使用url编码的下一级目录是必须要存在的

如果服务器开启了cgi或者cgid这两个mod的情况下，足够路径穿越漏洞可以开启任意命令执行，纯看运气

curl -v --data "echo;id" 'http://your-ip:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

Apache HTTP Server 2.4.50 路径穿越漏洞（CVE-2021-42013）

Apache HTTP Server是Apache基金会开源的一款流行的HTTP服务器。Apache官方在2.4.50版本中对2.4.49版本中出现的目录穿越漏洞CVE-2021-41773进行了修复，但这个修复是不完整的，CVE-2021-42013是对补丁的绕过。

这个漏洞可以影响Apache HTTP Server 2.4.49以及2.4.50两个版本。

执行如下命令编译及运行一个存在漏洞的Apache HTTP Server 2.4.50版本服务器：

docker-compose build
docker-compose up -d

环境启动后，访问http://your-ip:8080即可看到Apache默认的It works!页面。

漏洞利用

我们使用CVE-2021-41773中的Payload已经无法成功利用漏洞了，说明2.4.50进行了修复。

但我们可以使用.%%32%65进行绕过（注意其中的/icons/必须是一个存在且可访问的目录）：

curl -v --path-as-is http://your-ip:8080/icons/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/etc/passwd

%32%65 组地方是谁？再加一个%不又就是%2e了？两个漏洞的区别就这么简单除此之外没有任何区别，就是做了一个双重编码，而双重编码是可以被解析的

可见，成功读取到/etc/passwd：

在服务端开启了cgi或cgid这两个mod的情况下，这个路径穿越漏洞将可以执行任意命令,同上。