实测linux下的防火墙与系统ACL以及应用安全配置在网站故障排查中的应用

1.前言

相信许多小伙伴都遇到过这种情况，这个安全策略我明明配置了为什么就是不生效呢！咦，这个网站我前段时间还能访问，怎么现在就访问不了了。等等各种问题，理清楚这些有助于将来的快速排错与故障定位

2.从OSI角度分析三种类型的安全防护

OSI 7层模型（如下图）

防火墙：

防火墙主要分为传统的包过滤防火墙，IPS流量入侵检测防火墙。通常它对流量的拦截在第三层（网络层）就能发挥作用。linux服务器下最常见的就两种（iptables、firewall）

系统ACL：

全称为Linux 系统中的访问控制列表（Access Control List，ACL），是一种用于数据流的匹配和筛选的技术，它可以对网络流量进行控制和过滤。ACL 的配置文件可以定义哪些数据包可以接收，哪些数据包需要拒绝。这些配置是基于 OSI 模型的应用层来进行设置的，因为它们直接针对特定的应用程序或服务进行访问控制。在linux服务器下它对应的配置文件是/etc/hosts.allow和/etc/hosts.deny 。从介绍中可以看出ACL对流量的过滤主要在第七层（应用层）

针对某一个具体应用的安全配置文件：

 我这里以比较常用到web网站为例，比如nginx，经常要写一些安全防护策略，对防止DDOS攻击或者越权访问等有一定的作用。这是一个应用层的应用，所以它的安全策略配置文件一定是第七层（网络层）。它对应的配置文件一般在软件安装目录/conf/nginx.conf

3.遇到过的问题

a.某网站本地能访问，外网无法访问。此时应先看网络通不通，然后是防火墙的端口是否开放，如80、443

网络通说明到第三层没问题（也就是路由有来有回），那就看第四层（传输层）这里以firewall为例，我们查看端口放行情况

[root@wzy conf]# firewall-cmd --zone=public --list-ports 
80/tcp

此时说明防火墙的80端口是开放的。如果web服务器用的是80端口，说明到第四层也是通的。再往上就看应用层。应用层又有两块安全配置，系统ACL和nginx应用的安全策略。通常情况下直接去看nginx应用的安全策略配置文件即可。如下图

我们可以看到针对80这个端口，通用url匹配时只允许本地服务器自己访问web网站，即使同一局域网下web服务器的防火墙是完全放开，你也无法访问。会出现类似结果

这就是web服务器在应用层把你的流量拦截掉了。我们只需要把想要访问该网站的ip或者ip段加入即可。

那有朋友肯定会问系统ACL 也能做应用层的拦截，可不可以用在nginx上呢。我试了一下发现不行（我是用源码编译安装的nginx）。/etc/hosts.allow 语法  

服务名称:IP:动作
例如 
sshd:192.168.202.1:DENY

就是拒绝192.168.202.1通过sshd服务远程连接我。当我把服务名换成nginx时，并重启网络服务。发现完全没有影响。后来我去查了一些资料，终于解除了困惑

hosts.allow和hosts.deny规则的执行者为TCP wrappers，对应守护进程为tcpd；而tcpd执行依赖于程序使用了libwrap库
hosts.alllow和hosts.deny只支持libwrap库的服务
注：目前已知支持的常见服务有：sshd、vsftpd、rpcbind、rpc.mountd

那如何判断它支持哪些服务呢？

strings /usr/sbin/<services-name> | grep hosts_access

查看，若返回结果为hosts_access，则代表支持。否则不支持，即使配置也不会生效。

参考文章：针对/etc/hosts.allow的详细用法

但是如果有一天你遇到了sshd连不上服务器的时候，请记得看看/etc/hosts.deny 和allow

通过查看日志可以看到当你这样配了之后，连接就会被拒绝。

总结：不论什么疑难杂症，就是通过OSI模型加业务逻辑的双重把握，就能准确分析流量排查网络问题。

兄弟们创作不易，点个赞再走！