>最近网站被扫描出几个漏洞，大部分都是apache配置引起的，在此记录一下怎么修复。 ### 1.检测到目标URL存在http host头攻击漏洞  头攻击漏洞，比较常见的漏洞，修复的方法也提供了 漏洞的详细描述： 为了方便的获得网站域名，开发人员一般依赖于HTTP Host header。例如，在php里用_SERVER["HTTP_HOST"]。但是这个header是不可信赖的，如果应用程序没有对host header值进行处理，就有可能造成恶意代码的传入。 解决办法： web应用程序应该使用SERVER_NAME而不是host header。 在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法host header。在Nginx里还可以通过指定一个SERVER_NAME名单，**Apache也可以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项**。 我们使用的正好是apache，所以加上相关配置应该就可以了。 ``` ServerName www.xxxxxx.com UseCanonicalName On ``` ### 2. HTTP Security Header Not Detected  这里主要是头部缺少了一些参数，修复的办法漏洞文档也提供了，加上缺失的参数。可以在nginx上加，也可以在apache上加。 >这里可以看下：https://www.linux.org/threads/fixing-http-security-header-not-detected.12462/ Apache修复方法： ``` Header always append X-Frame-Options SAMEORIGIN Header set X-XSS-Protection "1; mode=block" Header set X-Content-Type-Options nosniff Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" ``` Nginx修复方法： ``` add_header x-frame-options "SAMEORIGIN" always; add_header X-XSS-Protection "1; mode=block"; add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload'; add_header X-Content-Type-Options nosniff; ``` 修改后curl进行测试，参数都带上了  ### 3. Directory Listing 这个漏洞主要是说网站现在有一些目录可以直接访问，比如一些js、css的文件夹，这个问题还是比较严重的。 表现如下：  本来发现这个问题我第一个反应是不是Nginx打开了autoindex，然后去看了 Nginx的配置文件，发现并不是。 然后猜测是apache的配置引起的，上网查了下，还真是。 看了下配置文件，配置的是：Options Indexes FollowSymLinks 查到的资料是改为：**Options FollowSymLinks ，把 Indexes 去掉** ``` DocumentRoot "/var/www/html" <Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride AuthConfig FileInfo Indexes Limit Options=All,MultiViews Require all granted </Directory> ``` 在测试环境改了之后发现可以，再访问的时候就是 **403 Forbidden**  然后开始申请上生产，这里问题就来了，生产机器改了之后发现还是可以继续访问目录。囧 继续看配置文件，发现还有别的地方配置了可以目录访问，  关于apache的配置我也没有深入了解过，看着感觉有问题，在我本地试了之后发现确实是由于这个引起的，所以也需要修改， 改为 **Options FollowSymLinks** 这里我猜测上面的Directory 里面是apache的默认配置，VirtualHost 里是我们设置的某个端口的配置，所以请求进来读取的配置应该是 VirtualHost 里面的，所以里面的配置也需要进行修改。 ``` <VirtualHost *:80> DocumentRoot F:\workspace_sz\new_svn\dev\var\www\html <Directory "F:\workspace_sz\new_svn\dev\var\www\html"> #Options -Indexes #Options All Options FollowSymLinks AllowOverride All #Order allow,deny #allow from all </Directory> </VirtualHost> ``` 因为我对这个配置也不是太熟，在此记录一下，有问题希望大家指正，谢谢 ### 4. Apache重启方法 ``` httpd -k graceful httpd -k restart ``` 推荐使用 **httpd -k graceful** USR1或graceful信号使得父进程建议子进程在完成它们现在的请求后退出(如果他们没有进行服务，将会立刻退出)。父进程重新读入配置文件并重新打开日志文件。每当一个子进程死掉，父进程立刻用新的配置文件产生一个新的子进程并立刻开始处理新的请求。 >httpd -k graceful 也叫优雅重启 >这里可以看下：https://www.cnblogs.com/zjzhuwenbo/archive/2013/12/12/3471231.html ``` 1.停止 apachectl -k stop 　　 发送TERM或stop信号到父进程可以使它立刻杀死所有子进程。这将花费一些时间来杀死所有子进程。然后父进程自己也退出。所有进行中的请求将被强行中止，而且不再接受其它请求。 2.重启 apachectl -k restart 　　 向父进程发送HUP或restart信号会使它象收到TERM信号一样杀掉所有的子进程，不同之处在于父进程本身并不退出。它重新读入配置文件、重新打开日志文件。然后产生一系列新的子进程来继续服务。 3.优雅重启 apachectl -k graceful 　　 USR1或graceful信号使得父进程建议子进程在完成它们现在的请求后退出(如果他们没有进行服务，将会立刻退出)。父进程重新读入配置文件并重新打开日志文件。每当一个子进程死掉，父进程立刻用新的配置文件产生一个新的子进程并立刻开始伺服新的请求。 4.优雅停止 apachectl -k graceful-stop 　　 WINCH或graceful-stop信号使得父进程建议子进程在完成它们现在的请求后退出(如果他们没有进行服务，将会立刻退出)。然后父进程删除PidFile并停止在所有端口上的监听。父进程仍然继续运行并监视正在处理请求的子进程，一旦所有子进程完成任务并退出或者超过由GracefulShutdownTimeout指令规定的时间， 父进程将会退出。在超时的情况下，所有子进程都将接收到TERM信号并被强制退出。 ```