防火墙NOTRACK标记详解

我以前一直使用的iptble策略

http://blog.chinaunix.net/uid-23504396-id-234592.html

发现光有
-A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK 

-A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK 
还不够，修改为

-A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK 
-A PREROUTING -p tcp -m tcp --sport 80 -j NOTRACK 

-A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK 
-A OUTPUT -p tcp -m tcp --dport 80 -j NOTRACK 

修改跟踪链接没了，发现curl 没返回! LVS负载及无法被ldirectord添加，抓包发现只有SYN包!
再翻资料才明白，之前一直以为跟踪链接只和nat有关是错误的
跟踪链接与stat也有关系，由于规则是-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
（无论是回调、lvs还是mysql，你的服务器总会做对外访问，不使用state基本是不可能的，用ip来做白名单会非常不好批量部署，禁用state来逃避跟踪链接是不可取的）
当访问百度80端口的时候，百度回来的状态是ESTABLISHED ，但是由于我前面NOTRACK，所以出去的包回不来了...
解决思路
1、从80端口回来的包允许
-A INPUT -p tcp -m multiport --sports 80 -j ACCEPT
这样做显然是不安全的，外部只要有那个80段偶给你发包就接受了，防火墙白干了

2、output链中dport 80规则删除，PREROUTING里只对dport 80且目标ip是本机的做NOTRACK 
也就是改为
-A PREROUTING -d youip -p tcp -m tcp --dport 80 -j NOTRACK 
这样做缺点在于
一个是每台机器ip不同，防火墙脚本需要批量部署
二就是，如果你的服务器需要对外访问，比如链接银联，淘宝、其他post等，那么跟踪链接问题依然存在

3、给予UNTRACKED状态通过权限，也就是
-A INPUT -m state --state RELATED,ESTABLISHED,UNTRACKED -j ACCEPT
这样做我们需要确认UNTRACKED 是否是安全状态

State	Explanation
NEW	The NEW state tells us that the packet is the first packet that we see. This means that the first packet that the conntrack module sees, within a specific connection, will be matched. For example, if we see a SYN packet and it is the first packet in a connection that we see, it will match. However, the packet may as well not be a SYN packet and still be considered NEW. This may lead to certain problems in some instances, but it may also be extremely helpful when we need to pick up lost connections from other firewalls, or when a connection has already timed out, but in reality is not closed.

ESTABLISHED	The ESTABLISHED state has seen traffic in both directions and will then continuously match those packets. ESTABLISHED connections are fairly easy to understand. The only requirement to get into an ESTABLISHED state is that one host sends a packet, and that it later on gets a reply from the other host. The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state. ICMP reply messages can also be considered as ESTABLISHED, if we created a packet that in turn generated the reply ICMP message.

RELATED	The RELATED state is one of the more tricky states. A connection is considered RELATED when it is related to another already ESTABLISHED connection. What this means, is that for a connection to be considered as RELATED, we must first have a connection that is considered ESTABLISHED. The ESTABLISHED connection will then spawn a connection outside of the main connection. The newly spawned connection will then be considered RELATED, if the conntrack module is able to understand that it is RELATED. Some good examples of connections that can be considered as RELATED are the FTP-data connections that are considered RELATED to the FTP control port, and the DCC connections issued through IRC. This could be used to allow ICMP error messages, FTP transfers and DCC's to work properly through the firewall. Do note that most TCP protocols and some UDP protocols that rely on this mechanism are quite complex and send connection information within the payload of the TCP or UDP data segments, and hence require special helper modules to be correctly understood.

INVALID	The INVALID state means that the packet can't be identified or that it does not have any state. This may be due to several reasons, such as the system running out of memory or ICMP error messages that do not respond to any known connections. Generally, it is a good idea to DROP everything in this state.

UNTRACKED	This is the UNTRACKED state. In brief, if a packet is marked within the raw table with the NOTRACK target, then that packet will show up as UNTRACKED in the state machine. This also means that all RELATED connections will not be seen, so some caution must be taken when dealing with the UNTRACKED connections since the state machine will not be able to see related ICMP messages et cetera.

也就是说经过raw表标记的才会是UNTRACKED状态，否则是其他状态，那么这么做是安全的，所以这个是最优做法

回头来看我的文章
http://blog.chinaunix.net/uid-23504396-id-3035008.html

今天终于知道，NOTRACK没有导致limit失效，而是状态不是NEW了所以规则没匹配