标签：iptables 扩展 报文 端口 我们 state 主机 连接

目录

当我们通过http的url访问某个网站的网页时，客户端向服务端的80端口发起请求，服务端再通过80端口响应我们的请求，于是，作为客户端，我们似乎应该理所应当的放行80端口，以便服务端回应我们的报文可以进入客户端主机，于是，我们在客户端放行了80端口，同理，当我们通过ssh工具远程连接到某台服务器时，客户端向服务端的22号端口发起请求，服务端再通过22号端口响应我们的请求，于是我们理所应当的放行了所有22号端口，以便远程主机的响应请求能够通过防火墙，但是，作为客户端，如果我们并没有主动向80端口发起请求，也没有主动向22号端口发起请求，那么其他主机通过80端口或者22号端口向我们发送数据时，我们可以接收到吗？应该是可以的，因为我们为了收到http与ssh的响应报文，已经放行了80端口与22号端口，所以，不管是响应我们的报文，还是主动发送给我们的报文，应该都是可以通过这两个端口的，那么仔细想想，这样是不是不太安全呢？如果某些与你敌对的人，利用这些端口主动连接到你的主机，你肯定会不爽的吧，一般都是我们主动请求80端口，80端口回应我们，但是一般不会出现80端口主动请求我们的情况吧。

你心里可能会这样想：我知道哪些主机是安全的，我只要针对这些安全的主机放行对应的端口就行了，其他IP一律拒绝，比如，我知道IP为192.168.99.100的主机是安全的，所以，我对192.168.99.100主机开放了22号端口，以便123主机能够通过22号端口响应我们的ssh请求，那么，如果你需要管理的主机越来越多呢？你是不是每次都要为新的主机配置这些规则呢？如果有30台主机呢？如果有300台主机呢？80端口就更别提了，难道你每次访问一个新的网址，都要对这个网址添加信任吗？这显然不太合理。

你心里可能又会想：针对对应的端口，我用--tcp-flags去匹配tcp报文的标志位，把外来的第一次握手的请求拒绝，是不是也可以呢？那么如果对方使用的是UDP协议或者ICMP协议呢？似乎总是有一些不完美的地方。

那么我们仔细的思考一下，造成上述问题的根源在哪里，我们为了让提供服务方能够正常的响应我们的请求，于是在主机上开放了对应的端口，开放这些端口的同时，也出现了问题，别人利用这些开放的端口，主动的攻击我们，他们发送过来的报文并不是为了响应我们，而是为了主动攻击我们，好了，我们似乎找到了问题所在？

问题就是：怎样判断这些报文是为了回应我们之前发出的报文，还是主动向我们发送的报文呢？

我们可以通过iptables的state扩展模块解决上述问题，但是我们需要先了解一些state模块的相关概念，然后再回过头来解决上述问题。

从字面上理解，state可以译为状态，但是我们也可以用一个高大上的词去解释它，state模块可以让iptables实现连接追踪机制。

那么，既然是连接追踪，则必然要有连接。

咱们就来聊聊什么是连接吧，一说到连接，你可能会下意识的想到tcp连接，但是，对于state模块而言的连接并不能与tcp的连接画等号，在TCP/IP协议簇中，UDP和ICMP是没有所谓的连接的，但是对于state模块来说，tcp报文、udp报文、icmp报文都是有连接状态的，我们可以这样认为，对于state模块而言，只要两台机器在你来我往的通信，就算建立起了连接，如下图所示：

而报文在这个所谓的链接中是什么状态的呢？这是我们后面讨论的话题。

对于state模块的连接而言，连接其中的报文可以分为5种状态，报文状态可以为NEW、ESTABLISHED、RELATED、INVALID、UNTRACKED

那么上述报文的状态都代表什么含义呢？我们先来大概的了解一下概念，然后再结合示例说明。

注意：如下报文状态都是对于state模块来说的。

• NEW：连接中的第一个包，状态就是NEW，我们可以理解为新连接的第一个包的状态为NEW；
• ESTABLISHED：我们可以把NEW状态包后面的包的状态理解为ESTABLISHED，表示连接已建立；

或许用图说话更容易被人理解：

• RELATED：从字面上理解RELATED译为关系，但是这样仍然不容易理解，我们举个例子；

比如FTP服务，FTP服务端会建立两个进程，一个命令进程，一个数据进程。

命令进程负责服务端与客户端之间的命令传输（我们可以把这个传输过程理解成state中所谓的一个连接，暂称为命令连接）。

数据进程负责服务端与客户端之间的数据传输 ( 我们把这个过程暂称为数据连接 )。

但是具体传输哪些数据，是由命令去控制的，所以，数据连接中的报文与命令连接是有关系的。

那么，数据连接中的报文可能就是RELATED状态，因为这些报文与命令连接中的报文有关系。

(注：如果想要对ftp进行连接追踪，需要单独加载对应的内核模块nf_conntrack_ftp，如果想要自动加载，可以配置/etc/sysconfig/iptables-config文件)

• INVALID：如果一个包没有办法被识别，或者这个包没有任何状态，那么这个包的状态就是INVALID，我们可以主动屏蔽状态为INVALID的报文。

• UNTRACKED：报文的状态为untracked时，表示报文未被追踪，当报文的状态为Untracked时通常表示无法找到相关的连接。

好了，我们已经大致了解了state模块中所定义的5种状态，那么现在，我们回过头想想刚才的问题。

刚才问题的根源就是：怎样判断报文是否是为了回应之前发出的报文。

刚才举例中的问题即可使用state扩展模块解决，我们只要放行状态为ESTABLISHED的报文即可，因为如果报文的状态为ESTABLISHED，那么报文肯定是之前发出的报文的回应，如果你还不放心，可以将状态为RELATED或ESTABLISHED的报文都放行，这样，就表示只有回应我们的报文能够通过防火墙，如果是别人主动发送过来的新的报文，则无法通过防火墙，示例如下。

$ iptables -F
$ iptables -t filter -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$ iptables -t filter -A INPUT -j REJECT

当前主机IP为192.168.99.100，当放行ESTABLISHED与RELATED状态的包以后，并没有影响通过本机远程ssh到IP为192.168.99.101的主机上，但是无法从192.168.99.100上使用22端口主动连接到192.168.99.101上。

对于其他端口与IP来说，也是相同的，可以从192.168.99.100主动发送报文，并且能够收到响应报文，但是其他主机并不能主动向192.168.99.100发起请求。

好了，state模块就总结到这里！

标签：iptables,扩展,报文,端口,我们,state,主机,连接
来源： https://www.cnblogs.com/lvzhenjiang/p/16033063.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。