一、首先，我们要搞清楚FTP协议的一些特点。
FTP协议与大多数协议最大的一个不同是：它使用双向的多个连接，而且使用的端口很难预计。
FTP连接包含一个控制连接(control connection)。这个连接用于传递客户端的命令和服务器端对命 令的响应。它使用FTP协议众所周知的21端口（当然也可使用其它端口），生存期是整个FTP会话时间。
还包含几个数据连接(data connection)。这些连接用于传输文件和其它数据，例如：目录列表等。这种连接在需要数据传输时建立，而一旦数据传输完毕就关闭，每次使用的端口也不一定相同。而且，数据连接既可能是客户端发起的，也可能是服务器端发起的。
根据建立数据连接发起方的不同，FTP可分为两种不同的模式：主动(Port Mode)模式和被动模式(Pasv Mode)。这两种不同模式数据连接建立方式分别如下：
（假设客户端为C，服务端为S）
Port模式：
当客户端C与服务端S建立控制连接后，若使用Port模式，那么客户端C会发送一条命令告诉服务端S：客户端C在本地打开了一个端口N在等着你进行数据连接。当服务端S收到这个Port命令后就会向客户端打开的那个端口N进行连接，这种数据连接就建立了。
例：客户端->服务器端：PORT 192,168,1,1,15,176
客户端<-服务器端：200 PORT command successful.
在上面的例子中192,168,1,1构成IP地址，15,176构成端口号（15*256+176）。
Pasv模式：
当客户端C与服务端S建立控制连接后，若使用Pasv模式，那么客户端C会向服务端S发送一条Pasv命令，服务端S会对该命令发送回应信息，这个信息是：服务端S在本地打开了一个端口M，你现在去连接我吧。当客户端C收到这个信息后，就可以向服务端S的M端口进行连接，连接成功后，数据连接也就建立了。
例：客户端->服务器端:PASV
客户端<-服务器端:227 Entering Passive Mode (192,168,1,2,14,26).
从上面的解释中，可以看到两种模式主要的不同是数据连接建立的不同。对于Port模式，是客户端C在本地打开一个端口等服务端S去连接而建立数据连接；而Pasv模式则是服务端S打开一个端口等待客户端C去建立一个数据连接。
二、Netfilter对FTP连线跟踪的处理
Netfilter对FTP连线跟踪的处理主要集中在ip_conntrack_ftp.c中。
在ip_conntrack_ftp.c中最重要的一个结构为ftp_search,它对FTP中各种模式的特征进行了总结。比如PORT模式，最重要的一个特征是在报文中会出现"PORT"字符串，IP地址前的字符为空格，结尾字符为"\r"，这两字符之间有一串数字(参考前面对FTP协议的分析)，这一串数字就是IP地址和端口号；PASSIVE模式，在报文中会出现"227"字符串，IP地址前的字符为"("，结尾字符为")".
static struct ftp_search {
enum ip_conntrack_dir dir;
const char *pattern;
size_t plen;
char skip;
char term;
enum ip_ct_ftp_type ftptype;
int (*getnum)(const char *, size_t, u_int32_t[], char);
} search[] = {
{
IP_CT_DIR_ORIGINAL, /*PORT模式*/
"PORT", sizeof("PORT") - 1, ' ', '\r',
IP_CT_FTP_PORT,
try_rfc959,
},
{
IP_CT_DIR_REPLY, /*PASSIVE模式*/
"227 ", sizeof("227 ") - 1, '(', ')',
IP_CT_FTP_PASV,
try_rfc959,
},
{
IP_CT_DIR_ORIGINAL,
"EPRT", sizeof("EPRT") - 1, ' ', '\r',
IP_CT_FTP_EPRT,
try_eprt,
},
{
IP_CT_DIR_REPLY,
"229 ", sizeof("229 ") - 1, '(', ')',
IP_CT_FTP_EPSV,
try_espv_response,
},
};
对FTP连线跟踪的处理是从函数help()开始的。在该函数中定义了一个数组u_int32_t array[6] = { 0 };该数组就是用来保存IP地址和端口号的，其中array[0]~array[3]保存IP地址，array[4]和array[5]和起来组成端口号，计算方法为array[4]*256+array[5]。
下面使用前面定义的搜索模式来搜索报文，把获得的IP地址和端口号保存在array中。
for (i = 0; i < sizeof(search) / sizeof(search[0]); i++) {
if (search[i].dir != dir)
continue;
found = find_pattern(data, datalen, search[i].pattern,
search[i].plen, search[i].skip, search[i].term,
&matchoff, &matchlen, array, search[i].getnum);
if (found)
break;
}
在find_pattern函数中有*numlen = getnum(data + i, dlen - i, array, term);这条语句，这儿的getnum分别对应ftp_search中的try_rfc959(),try_eprt(),try_espv_response(),这些函数就是主要对报文进行分析的函数。
在获取了IP地址和端口号后就可以建立元组，然后再建立期望连接，并把期望连接加入期望连接表中。下面这段代码就是建立元组和期望连接。
t = ((struct ip_conntrack_tuple)
{ { ct->tuplehash[!dir].tuple.src.ip,
{ 0 } },
{ htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3]),
{ htons(array[4] << 8 | array[5]) },
IPPROTO_TCP }});
mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
{ 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
/* Ignore failure; should only happen with NAT */
ip_conntrack_expect_related(ct, &t, &mask, NULL);
之所以称为期望连接，是因为现在还处于控制连接阶段，数据连接此时还未建立，但将来是会建立的。如此处理之后，我们就可以预先获取建立数据连接的信息，当真正的数据连接需要建立时，我们只需在期望连接表中进行查找，保证了多连接协议的正确处理，同时还提高了效率。
三、代码流程
- 1、Initialization
- nf_conntrack_ftp_init(net/netfilter/nf_conntrack_ftp.c)
- nf_conntrack_ftp_init(net/netfilter/nf_conntrack_ftp.c)
{
int i, j = -1, ret = 0;
char *tmpname;
ftp_buffer = kmalloc(65536, GFP_KERNEL);
if (!ftp_buffer)
return -ENOMEM;
if ( ports_c == 0) // static unsigned int ports_c;
ports[ports_c++] = FTP_PORT; //static u_int16_t ports[MAX_PORTS];
/* FIXME should be configurable whether IPv4 and IPv6 FTP connections
are tracked or not - YK */
for (i = 0; i < ports_c; i++) {
ftp[i][0].tuple. src.l3num = PF_INET; // Will be used when hash tuple
ftp[i][1].tuple.src.l3num = PF_INET6;
for (j = 0; j < 2; j++) {
ftp[i][j].tuple. src.u.tcp.port = htons(ports[i]); // Will be used when hash tuple
ftp[i][j].tuple. dst.protonum = IPPROTO_TCP; // Will be used when hash tuple
ftp[i][j].expect_policy = & ftp_exp_policy;
ftp[i][j].me = THIS_MODULE;
ftp[i][j].help = help;
tmpname = &ftp_names[i][j][0];
if (ports[i] == FTP_PORT)
sprintf(tmpname, "ftp");
else
sprintf(tmpname, "ftp-%d", ports[i]);
ftp[i][j].name = tmpname;
pr_debug("nf_ct_ftp: registering helper for pf: %d "
"port: %d\n",
ftp[i][j].tuple.src.l3num, ports[i]);
ret = nf_conntrack_helper_register(&ftp[i][j]);
if (ret) {
printk("nf_ct_ftp: failed to register helper "
" for pf: %d port: %d\n",
ftp[i][j].tuple.src.l3num, ports[i]);
nf_conntrack_ftp_fini();
return ret;
}
}
}
return 0;
}
- nf_conntrack_helper_register(net/netfilter/nf_conntrack_helper.c)
{
unsigned int h = helper_hash(&me->tuple);
BUG_ON(me->expect_policy == NULL);
BUG_ON(me->expect_class_max >= NF_CT_MAX_EXPECT_CLASSES);
BUG_ON(strlen(me->name) > NF_CT_HELPER_NAME_LEN - 1);
mutex_lock(&nf_ct_helper_mutex);
hlist_add_head_rcu(&me->hnode, & nf_ct_helper_hash[h]); // Global helper list
nf_ct_helper_count++;
mutex_unlock(&nf_ct_helper_mutex);
return 0;
}
- helper_hash(net/netfilter/nf_conntrack_helper.c)
* helpers currently in the kernel. */
static unsigned int helper_hash(const struct nf_conntrack_tuple *tuple)
{
return (((tuple-> src.l3num << 8) | tuple-> dst.protonum) ^
(__force __u16)tuple-> src.u.all) % nf_ct_helper_hsize;
}
- How ftp helper registered
- How ftp helper works
- Big picture
- Main helper function(net/netfilter/nf_conntrack_ftp.c)
unsigned int protoff,
struct nf_conn *ct,
enum ip_conntrack_info ctinfo)
{
unsigned int dataoff, datalen;
const struct tcphdr *th;
struct tcphdr _tcph;
const char *fb_ptr;
int ret;
u32 seq;
int dir = CTINFO2DIR(ctinfo);
unsigned int uninitialized_var(matchlen), uninitialized_var(matchoff);
struct nf_ct_ftp_master *ct_ftp_info = &nfct_help(ct)->help.ct_ftp_info;
struct nf_conntrack_expect *exp;
union nf_inet_addr *daddr;
struct nf_conntrack_man cmd = {};
unsigned int i;
int found = 0, ends_in_nl;
typeof(nf_nat_ftp_hook) nf_nat_ftp;
/* Until there's been traffic both ways, don't look in packets. */
if (ctinfo != IP_CT_ESTABLISHED
&& ctinfo != IP_CT_ESTABLISHED+IP_CT_IS_REPLY) {
pr_debug("ftp: Conntrackinfo = %u\n", ctinfo);
return NF_ACCEPT;
}
th = skb_header_pointer(skb, protoff, sizeof(_tcph), &_tcph);
if (th == NULL)
return NF_ACCEPT;
dataoff = protoff + th->doff * 4;
/* No data? */
if (dataoff >= skb->len) {
pr_debug("ftp: dataoff(%u) >= skblen(%u)\n", dataoff,
skb->len);
return NF_ACCEPT;
}
datalen = skb->len - dataoff;
spin_lock_bh(&nf_ftp_lock);
fb_ptr = skb_header_pointer(skb, dataoff, datalen, ftp_buffer);
BUG_ON(fb_ptr == NULL);
ends_in_nl = (fb_ptr[datalen - 1] == '\n');
seq = ntohl(th->seq) + datalen;
/* Look up to see if we're just after a \n. */
if (!find_nl_seq(ntohl(th->seq), ct_ftp_info, dir)) {
/* Now if this ends in \n, update ftp info. */
pr_debug("nf_conntrack_ftp: wrong seq pos %s(%u) or %s(%u)\n",
ct_ftp_info->seq_aft_nl_num[dir] > 0 ? "" : "(UNSET)",
ct_ftp_info->seq_aft_nl[dir][0],
ct_ftp_info->seq_aft_nl_num[dir] > 1 ? "" : "(UNSET)",
ct_ftp_info->seq_aft_nl[dir][1]);
ret = NF_ACCEPT;
goto out_update_nl;
}
/* Initialize IP/IPv6 addr to expected address (it's not mentioned
in EPSV responses) */
cmd.l3num = nf_ct_l3num(ct);
memcpy(cmd.u3.all, &ct->tuplehash[dir].tuple.src.u3.all,
sizeof(cmd.u3.all));
for (i = 0; i < ARRAY_SIZE( search[dir]); i++) {
found = find_pattern(fb_ptr, datalen, // Try to find packet which trigger a ftp connection tracking
search[dir][i].pattern,
search[dir][i].plen,
search[dir][i].skip,
search[dir][i].term,
&matchoff, &matchlen,
&cmd,
search[dir][i].getnum);
if (found) break;
}
if (found == -1) {
/* We don't usually drop packets. After all, this is
connection tracking, not packet filtering.
However, it is necessary for accurate tracking in
this case. */
pr_debug("conntrack_ftp: partial %s %u+%u\n",
search[dir][i].pattern, ntohl(th->seq), datalen);
ret = NF_DROP;
goto out;
} else if (found == 0) { /* No match */
ret = NF_ACCEPT;
goto out_update_nl;
}
pr_debug("conntrack_ftp: match `%.*s' (%u bytes at %u)\n",
matchlen, fb_ptr + matchoff,
matchlen, ntohl(th->seq) + matchoff);
exp = nf_ct_expect_alloc(ct);
if (exp == NULL) {
ret = NF_DROP;
goto out;
}
/* We refer to the reverse direction ("!dir") tuples here,
* because we're expecting something in the other direction.
* Doesn't matter unless NAT is happening. */
daddr = &ct->tuplehash[!dir].tuple.dst.u3;
/* Update the ftp info */
if ((cmd.l3num == nf_ct_l3num(ct)) &&
memcmp(&cmd.u3.all, &ct->tuplehash[dir].tuple.src.u3.all,
sizeof(cmd.u3.all))) {
/* Enrico Scholz's passive FTP to partially RNAT'd ftp
server: it really wants us to connect to a
different IP address. Simply don't record it for
NAT. */
if (cmd.l3num == PF_INET) {
pr_debug("conntrack_ftp: NOT RECORDING: %pI4 != %pI4\n",
&cmd.u3.ip,
&ct->tuplehash[dir].tuple.src.u3.ip);
} else {
pr_debug("conntrack_ftp: NOT RECORDING: %pI6 != %pI6\n",
cmd.u3.ip6,
ct->tuplehash[dir].tuple.src.u3.ip6);
}
/* Thanks to Cristiano Lincoln Mattos
for reporting this potential
problem (DMZ machines opening holes to internal
networks, or the packet filter itself). */
if (!loose) {
ret = NF_ACCEPT;
goto out_put_expect;
}
daddr = &cmd.u3;
}
nf_ct_expect_init(exp, NF_CT_EXPECT_CLASS_DEFAULT, cmd.l3num, // Setup expectation for this ftp connection
&ct->tuplehash[!dir].tuple.src.u3, daddr,
IPPROTO_TCP, NULL, &cmd.u.tcp.port);
/* Now, NAT might want to mangle the packet, and register the
* (possibly changed) expectation itself. */
nf_nat_ftp = rcu_dereference(nf_nat_ftp_hook);
if (nf_nat_ftp && ct->status & IPS_NAT_MASK)
ret = nf_nat_ftp(skb, ctinfo, search[dir][i].ftptype,
matchoff, matchlen, exp);
else {
/* Can't expect this? Best to drop packet now. */
if ( nf_ct_expect_related(exp) != 0)
ret = NF_DROP;
else
ret = NF_ACCEPT;
}
out_put_expect:
nf_ct_expect_put(exp);
out_update_nl:
/* Now if this ends in \n, update ftp info. Seq may have been
* adjusted by NAT code. */
if (ends_in_nl)
update_nl_seq(ct, seq, ct_ftp_info, dir, skb);
out:
spin_unlock_bh(&nf_ftp_lock);
return ret;
}
- Pattern search(net/netfilter/nf_conntrack_ftp.c)
- Structure
- Structure
const char *pattern;
size_t plen;
char skip;
char term;
enum nf_ct_ftp_type ftptype;
int (*getnum)(const char *, size_t, struct nf_conntrack_man *, char);
} search[IP_CT_DIR_MAX][2] = { // 2 directions and 2 modes
[ IP_CT_DIR_ORIGINAL] = {
{
.pattern = " PORT",
.plen = sizeof("PORT") - 1,
.skip = ' ',
.term = '\r',
.ftptype = NF_CT_FTP_PORT,
.getnum = try_rfc959,
},
{
.pattern = " EPRT",
.plen = sizeof("EPRT") - 1,
.skip = ' ',
.term = '\r',
.ftptype = NF_CT_FTP_EPRT,
.getnum = try_eprt,
},
},
[ IP_CT_DIR_REPLY] = {
{
.pattern = " 227 ",
.plen = sizeof("227 ") - 1,
.skip = '(',
.term = ')',
.ftptype = NF_CT_FTP_PASV,
.getnum = try_rfc959,
},
{
.pattern = " 229 ",
.plen = sizeof("229 ") - 1,
.skip = '(',
.term = ')',
.ftptype = NF_CT_FTP_EPSV,
.getnum = try_epsv_response,
},
},
};
- try_rfc959(net/netfilter/nf_conntrack_ftp.c)
static int try_rfc959(const char *data, size_t dlen,
struct nf_conntrack_man *cmd, char term)
{
int length;
u_int32_t array[6];
length = try_number(data, dlen, array, 6, ',', term);
if (length == 0)
return 0;
cmd->u3. ip = htonl((array[0] << 24) | (array[1] << 16) |
(array[2] << 8) | array[3]);
cmd->u.tcp. port = htons((array[4] << 8) | array[5]);
return length;
}
- try_eprt(net/netfilter/nf_conntrack_ftp.c)
static int try_eprt(const char *data, size_t dlen, struct nf_conntrack_man *cmd,
char term)
{
char delim;
int length;
/* First character is delimiter, then "1" for IPv4 or "2" for IPv6,
then delimiter again. */
if (dlen <= 3) {
pr_debug("EPRT: too short\n");
return 0;
}
delim = data[0];
if (isdigit(delim) || delim < 33 || delim > 126 || data[2] != delim) {
pr_debug("try_eprt: invalid delimitter.\n");
return 0;
}
if ((cmd->l3num == PF_INET && data[1] != '1') ||
(cmd->l3num == PF_INET6 && data[1] != '2')) {
pr_debug("EPRT: invalid protocol number.\n");
return 0;
}
pr_debug("EPRT: Got %c%c%c\n", delim, data[1], delim);
if (data[1] == '1') {
u_int32_t array[4];
/* Now we have IP address. */
length = try_number(data + 3, dlen - 3, array, 4, '.', delim);
if (length != 0)
cmd->u3. ip = htonl((array[0] << 24) | (array[1] << 16)
| (array[2] << 8) | array[3]);
} else {
/* Now we have IPv6 address. */
length = get_ipv6_addr(data + 3, dlen - 3,
(struct in6_addr *)cmd->u3. ip6, delim);
}
if (length == 0)
return 0;
pr_debug("EPRT: Got IP address!\n");
/* Start offset includes initial "|1|", and trailing delimiter */
return get_port(data, 3 + length + 1, dlen, delim, &cmd->u. tcp.port);
}
- try_epsv_response(net/netfilter/nf_conntrack_ftp.c)
static int try_epsv_response(const char *data, size_t dlen,
struct nf_conntrack_man *cmd, char term)
{
char delim;
/* Three delimiters. */
if (dlen <= 3) return 0;
delim = data[0];
if (isdigit(delim) || delim < 33 || delim > 126
|| data[1] != delim || data[2] != delim)
return 0;
return get_port(data, 3, dlen, delim, &cmd->u .tcp.port);
}
- nf_ct_expect_init(net/netfilter/nf_conntrack_expect.c)
u_int8_t family,
const union nf_inet_addr *saddr,
const union nf_inet_addr *daddr,
u_int8_t proto, const __be16 *src, const __be16 *dst)
{
int len;
if (family == AF_INET)
len = 4;
else
len = 16;
exp->flags = 0;
exp->class = class;
exp->expectfn = NULL;
exp->helper = NULL;
exp->tuple.src.l3num = family;
exp->tuple.dst.protonum = proto;
if (saddr) {
memcpy(&exp->tuple.src.u3, saddr, len);
if (sizeof(exp->tuple.src.u3) > len)
/* address needs to be cleared for nf_ct_tuple_equal */
memset((void *)&exp->tuple.src.u3 + len, 0x00,
sizeof(exp->tuple.src.u3) - len);
memset(&exp->mask.src.u3, 0xFF, len);
if (sizeof(exp->mask.src.u3) > len)
memset((void *)&exp->mask.src.u3 + len, 0x00,
sizeof(exp->mask.src.u3) - len);
} else {
memset(&exp->tuple.src.u3, 0x00, sizeof(exp->tuple.src.u3));
memset(&exp->mask.src.u3, 0x00, sizeof(exp->mask.src.u3));
}
if (src) {
exp->tuple.src.u.all = *src;
exp->mask.src.u.all = htons(0xFFFF);
} else {
exp->tuple.src.u.all = 0;
exp->mask.src.u.all = 0;
}
memcpy(&exp->tuple.dst.u3, daddr, len);
if (sizeof(exp->tuple.dst.u3) > len)
/* address needs to be cleared for nf_ct_tuple_equal */
memset((void *)&exp->tuple.dst.u3 + len, 0x00,
sizeof(exp->tuple.dst.u3) - len);
exp->tuple.dst.u.all = *dst;
}
EXPORT_SYMBOL_GPL(nf_ct_expect_init);
1>.port（ftp sever发起建立连接）
:~# cat /proc/net/nf_conntrack
ipv4 2 tcp 6 3589 ESTABLISHED src=10.0.1.2 dst=172.26.0.107 sport=53708 dport=21 packets=6 bytes=273 src=172.26.0.107 dst=100.99.1.4 sport=21 dport=53708 packets=5 bytes=394 [ASSURED] mark=0 zone=0 policy=3 pri=0 src_user=0 dst_user=0 src_session=0 dst_session=0 flags=0x0 fwmark=(0x40010009 0x0) in_if=5 out_if=2 dst_domainID=abcdabcd src_domainID=abcdabcd src_dev_index=0 dst_dev_index=0 src_group_id=0 dst_group_id=0 device_type=0 compliance=0 bw_enable=0x00000000 bw_status=0x00000001 catid=0 appid=0 behid=0 ips_rule_id=0 use=2
ipv4 2 tcp 6 34 TIME_WAIT src=10.0.1.2 dst=172.26.0.107 sport=53707 dport=21 packets=14 bytes=616 src=172.26.0.107 dst=100.99.1.4 sport=21 dport=53707 packets=10 bytes=652 [ASSURED] mark=0 zone=0 policy=3 pri=0 src_user=0 dst_user=0 src_session=0 dst_session=0 flags=0x0 fwmark=(0x40010009 0x0) in_if=5 out_if=2 dst_domainID=abcdabcd src_domainID=abcdabcd src_dev_index=0 dst_dev_index=0 src_group_id=0 dst_group_id=0 device_type=0 compliance=0 bw_enable=0x00000000 bw_status=0x00000001 catid=0 appid=0 behid=0 ips_rule_id=0 use=2
2> passive(client 发起建立数据连接)
wgsupport@Firebox:~# cat /proc/net/nf_conntrack
ipv4 2 tcp 6 26 ESTABLISHED src=10.0.1.2 dst=172.26.0.107 sport=43167 dport=54581 packets=1398 bytes=55940 src=172.26.0.107 dst=10.139.100.217 sport=54581 dport=43167 packets=3046 bytes=13511104 [ASSURED] mark=0 zone=0 policy=3 pri=0 src_user=0 dst_user=0 src_session=0 dst_session=0 flags=0x0 fwmark=(0x40010002 0x0) in_if=6 out_if=5 dst_domainID=00000000 src_domainID=00000000 src_dev_index=0 dst_dev_index=0 src_group_id=0 dst_group_id=0 device_type=0 compliance=0 bw_enable=0x00000000 bw_status=0x00000001 catid=0 appid=0 behid=0 ips_rule_id=0 use=2
ipv4 2 tcp 6 3566 ESTABLISHED src=10.0.1.2 dst=172.26.0.107 sport=53720 dport=21 packets=20 bytes=898 src=172.26.0.107 dst=10.139.100.217 sport=21 dport=53720 packets=13 bytes=942 [ASSURED] mark=0 zone=0 policy=3 pri=0 src_user=0 dst_user=0 src_session=0 dst_session=0 flags=0x20 fwmark=(0x40010002 0x0) in_if=5 out_if=6 dst_domainID=abcdabcd src_domainID=abcdabcd src_dev_index=0 dst_dev_index=0 src_group_id=0 dst_group_id=0 device_type=0 compliance=0 bw_enable=0x00000000 bw_status=0x00000001 catid=0 appid=0 behid=0 ips_rule_id=0 use=3
四、分析
FTP协议使用两个连接。一个叫控制连接，另一个叫数据连接。FTP的命令和应答通过控制连接来交换，这个连接会存在于整个FTP会话过程中。另一方面，一个文件（或一个文件列表）通过数据连接来传送，这个连接是当每次文件传输时才新建立的。
通常出于网络安全的考虑，大多数防火墙不允许除FTP控制连接之外的任何连接连到FTP的服务端口（默认是TCP的21端口）。虽然如此，当一个文件传输时，防火墙临时地认可数据连接。为了做到这点，防火墙跟踪控制连接的状态，并检测跟文件传输相关的命令。这就是所谓的状态检测。
PORT命令的格式如下：
PORT<space>h1,h2,h3,h4,p1,p2<CRLF>
这里字符串“h1,h2,h3,h4”表示点分十进制的客户端的IP地址
“h1.h2.h3.h4”。字符串“p1,p2”表示一个数据端口号（= p1 * 256 + p2）。地址和端口号都是十进制数。数据端口由客户端动态指定。另外，命令和应答以<CRLF>字符序列结尾。
Netfilter跟踪一个FTP控制连接，并获取TCP序列号和包含一个FTP命令行（以<LF>结尾）的数据包的数据长度。然后基于这些信息，它计算出下一个命令数据包的序列号。当一个这样序列号的数据包到达时，Netfilter分析数据包中的数据是否包含一个FTP命令。如果数据的头部是“PORT”，并且数据以<CRLF>结尾，于是Netfilter认为它是一个有效的PORT命令（实际的代码会更复杂），并从中取出IP地址和端口号。然后，Netfilter“期待”服务器主动建立一个到客户端指定的端口号的数据连接。当数据连接请求确实到达时，它会认可连接，同时连接建立。一个没完成的命令，即所谓的“不完全的”命令，会因为无法真实的跟踪而丢弃。
从大的方面来说，netfilter就是一张大的流转发表，这个转发表的查找是基于流的五元组（sip/dip/sport/dport/type），流是有方向的，我们分别定义为正向和反向。用一个图更为形象的说明流表的组织形式。
通过上图，我相信一定能够客观真实的反映流表的组织形式了吧，正向流和反向流分别对应两个方向，他们在hash表里面映射不同的表项，但是他们所关联到的是同一个连接跟踪表项。
系统的连接跟踪会在四个地方进行处理，分别是路由前，路由后，本地收以及发。本地收发也不在讨论范围内，需要的自己察看看，关键在于触类旁通。首先说说最简单的，没有动态协议的情况。在路由前接收到一个报文，接着跟踪报文信息调用二层以及三层的回调函数，
构造出报文的5元组信息(tuple，后文简称为元组)。接着通过这个5元组即我们上文所说的正向流或者反向流来查找对应的连接跟踪信息（nf_conn）.情况简单的说就是两种，存在或者不存在，存在就返回这个结构。如果不存在就创建连接信息即nf_conn,但是这个时候并没有加入hash表里面去，所以还挂在unconform链上。
因为上文说了我们暂时不讨论动态协议，所以在创建连接信息的时候，查找expectation和helper肯定都没有，所以也就直接返回了。这儿可以看到两者的不同在于创建新的连接与否。有了这个nf_conn连接跟踪表，我们就需要对这个连接的的状态进行调整。具体的状态机可以参考代码，TCP的比较复杂一些，ICMP和UDP的差不多。到此为止，路由前就处理完了，我们可以看到要么查找到简单处理，要么构建一个新连接，但是挂到
全局的未决链上。
接下来的处理就是路由后了，在发出报文之前，这个时候主要就是做一些错误检查，然后把前面处理的未决的连接跟踪加入到前面看到的hash表项里，让系统能够检索到。 现在我们加入动态协议再重新看一下这个流程，以tftp或者ftp为例都可以，简单起见，tftp吧。下面这个大的流程很重要，切记切记，不懂也首先记住，然后再分析。在创建新的连接跟踪信息时候，首先判断一下这个连接是不是期望连接，如果是就关联到之前的主链接上面。然后不管是主链接还是期望连接都查找相应的helper函数，当然主连接通过全局表查找，而子连接是在主连接的help创建时候赋的值。对于简单的动态协议，其子连接是没有helper函数的，例如tftp或者ftp。
上面的话记牢了吧，首先查找期望连接，然后查找helper函数。这是因为一些动态协议，其控制协议创建好了expectation后，挂到全局表，接下来就是数据通道，而这个数据通道就是期望连接，所以虽然是新建连接，但是也是我们所预知的，所以和其master关联。
另外就是helper函数，例如tftp在模块加载时候就注册了这个helper，当我们新建一个连接，会查找这个表看是否是其中的一种协议，很幸运，我们就是tftp那么首先把这个helper关联到这个连接。路由器的处理就完了，对于helper的调用要在路由后我们才能看到了。 最近终于到了路由后，在路由后的处理流程里面，首先做的工作就是对前面的helper进行调用，当然help主要完成的工作就是expectation的创建，然后挂到全局链表，等待数据通道报文。解析来的工作和前面就是一样了，把新建的连接加入hash表。
扫一扫
1373
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
