由于所有的控制通讯都是单向的,这使得实时监测TFN2K额外困难。因为其随机性地使用TCP、UDP和ICMP数据包,同时进行了加密,数据包过滤和其它被动式防御策略都显得不切实际和效率低下的。伪造的数据包更会增加追踪参与拒绝服务攻击的代理端主机的难度。
幸运的是,TFN2K仍然有弱点。可能是疏忽的原因,加密后的Base 64编码在每一个TFN2K数据包的尾部留下了痕迹(与协议和加密算法无关)。可能是程序作者为了使每一个数据包的长度变化而填充了1到16个零(0x00),经过Base 64编码后就成为多个连续的0x41('A')。添加到数据包尾部的0x41的数量是可变的,但至少会有一个。这些位于数据包尾部的0x41('A')就成了捕获TFN2K命令数据包的特征了。
对TFN2K客户端程序(tfn)和守护程序文件(td)的简单搜索也可能会找到TFN2K。虽然这些文件名可以随意修改,但客户端程序和守护程序包含许多特征字符串,可以作为搜索的关键字。如下:
TFN2K客户端程序(tfn)
[1;34musage: %s
[-P protocol]
[-S host/ip]
[-f hostlist]
[-h hostname]
[-i target string]
[-p port]
<-c command ID>
change spoof level to %d
change packet size to %d bytes
bind shell(s) to port %d
commence udp flood
commence syn flood, port: %s
commence icmp echo flood
commence icmp broadcast (smurf) flood
commence mix flood
commence targa3 attack
execute remote command
TFN2K守护程序(td)
fork
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
/dev/urandom
/dev/random
%d.%d.%d.%d
sh*
ksh*
command.exe**
cmd.exe**
tfn-daemon***
tfn-child***
* Unix and Solaris systems only
** Windows NT systems only
*** This text is likely to have been changed in many TFN2K installations
TFN2K守护程序和客户端程序(tfn和td)
security_through_obscurity *
D4 40 FB 30 0B FF A0 9F **
64 64 64 64 ... ***
* 程序编译时定义的函数名,是一个非常有用的特征字符串。
** CAST-256加密表格的头8个字节(按little-endian排序)。
*** Base 64编码算法使用的静态表格中连续128字节长度的0x64值。