filter client_to_daemon icmp (ipv4, type: 0, code: 0)
{
# Sequence number
if (ushort(ip.blob, 6) == 0) {
$id = ushort(ip.blob, 4);
if (TFN_COMMANDS[$id]) {
alert(tfn_source, tfn_command, ip.src, ip.dst, "Network",
"client to daemon",
"--AlertDetails", "ALERT_ID", "23-9",
"ALERT_CONFIDENCE", 60,
"ALERT_SEVERITY", "high",
"ALERT_EVENT_TYPE", "unknown",
"ALERT_IMPACT", "unknown",
"ALERT_ASSESSMENT", "unknown",
"IP_ADDR_SRC", ip.src, "IP_ADDR_DST", ip.dst,
"IP_PROTO_NUM", ip.proto,
"CONTEXT", attack:context(tfn_command));
record packet.sec, ip.src, -1, ip.dst, -1, ip.proto,
cat("client to daemon command ", $id) to tfn_rec;
misc_attacks:rec(packet.sec, scope(), "tfn client to daemon",
ip.src, ip.dst);
}
}
}
func tfn2k {
if (strlen(udp.blob) == 27 && index(udp.blob, "AAAAA") > -1) {
alert(tfn_source, tfn_command, ip.src, ip.dst, "2000",
"client to daemon",
"--AlertDetails", "ALERT_ID", "23-9",
"ALERT_CONFIDENCE", 60,
"ALERT_SEVERI, TY", "high",
"ALERT_EVENT_TYPE", "unknown",
"ALERT_IMPACT", "unknown",
"ALERT_ASSESSMENT", "unknown",
"IP_ADDR_SRC", ip.src, "PORT_SRC", udp.sport,
"IP_ADDR_DST", ip.dst, "PORT_DST", udp.dport,
"IP_PROTO_NUM", ip.proto,
"CONTEXT", attack:context(tfn_command));
record packet.sec, ip.src, udp.sport, ip.dst, udp.dport, ip.proto,
"tfn2k" to tfn_rec;
misc_attacks:rec(packet.sec, scope(), "tfn2k",
ip.src, ip.dst);
}
}
总结一下:关于内网中上DDOS的傀儡主机的检测,检测其和客户端,也就是控制端的通讯是主要前提,另外还是要尽量检测他的攻击特征,因为他的攻击特征比较混合,是若干种攻击同时进行,比较难分辨,DDOS到检测攻击层面上还是和检测DOS攻击一样,近年来国内开发的分布式DOS攻击工具层出不穷,好多属于私有的,和木马功能集合的,这些分布式攻击攻击比较难收集.检测DDOS我认为要集合特征检测,加流量异常来检测
L) 有关SQL注射的问题
1) SQL INJECTOR
我这里采用
SQL_INJECTOR_REGEX1 = regcomp("/(\%27)|(\’)|(\-\-)|(\%23)|(#)/ix");
SQL_INJECTOR_REGEX2 = regcomp("/((\=)|(=))[^\n]*((\%27)|(\’)|(\-\-)|(\%3B)|(;))/i");
SQL_INJECTOR_REGEX3 = regcomp("/\w*((\%27)|(\’))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix");
SQL_INJECTOR_REGEX4 = regcomp("/exec(\s|\+)+(s|x)p\w+/ix");
SQL_INJECTOR_REGEX5 = regcomp("/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix");
SQL_INJECTOR_REGEX6 = regcomp("/((\%3C)|<)((\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47))[^\n]+((\%3E)|>)/I");
SQL_INJECTOR_REGEX7 = regcomp("/((\%3C)|<)[^\n]+((\%3E)|>)/I");
SQL_INJECTOR_REGEX8 = regcomp("/((\%27)|(\’))union/ix");
SQL_INJECTOR_REGEX9 = regcomp("/((\%27)|(\’))and/ix");
SQL_INJECTOR_REGEX10 = regcomp("/((\%27)|(\’))insert/ix");
SQL_INJECTOR_REGEX11 = regcomp("/((\%27)|(\’))select/ix");
SQL_INJECTOR_REGEX12 = regcomp("/((\%27)|(\’))delete/ix");
SQL_INJECTOR_REGEX13 = regcomp("/((\%27)|(\’))update/ix");
SQL_INJECTOR_REGEX14 = regcomp("/((\%27)|(\’))truncate/ix");
SQL_INJECTOR_REGEX15 = regcomp("/((\%27)|(\’))declare/ix");
SQL_INJECTOR_REGEX16 = regcomp("/((\%2F)|(\;))union/ix");
SQL_INJECTOR_REGEX17 = regcomp("/((\%2F)|(\;))and/ix");
SQL_INJECTOR_REGEX18 = regcomp("/((\%2F)|(\;))insert/ix");
SQL_INJECTOR_REGEX19 = regcomp("/((\%2F)|(\;))select/ix");
SQL_INJECTOR_REGEX20 = regcomp("/((\%2F)|(\;))delete/ix");
SQL_INJECTOR_REGEX21 = regcomp("/((\%2F)|(\;))update/ix");
SQL_INJECTOR_REGEX22 = regcomp("/((\%2F)|(\;))truncate/ix");
SQL_INJECTOR_REGEX23 = regcomp("/((\%2F)|(\;))declare/ix");
SQL_INJECTOR_REGEX24 = regcomp("/((\%2F)|(\;))exec/ix");
SQL_INJECTOR_REGEX25 = regcomp("/((\%20)|(\ ))union/ix");
SQL_INJECTOR_REGEX26 = regcomp("/((\%20)|(\ ))and/ix");
SQL_INJECTOR_REGEX27 = regcomp("/((\%20)|(\ ))insert/ix");
SQL_INJECTOR_REGEX28 = regcomp("/((\%20)|(\ ))select/ix");
SQL_INJECTOR_REGEX29 = regcomp("/((\%20)|(\ ))delete/ix");
SQL_INJECTOR_REGEX30 = regcomp("/((\%20)|(\ ))update/ix");
SQL_INJECTOR_REGEX31 = regcomp("/((\%20)|(\ ))truncate/ix");
SQL_INJECTOR_REGEX32 = regcomp("/((\%20)|(\ ))declare/ix");
SQL_INJECTOR_REGEX33 = regcomp("/((\%20)|(\ ))exec/ix");
SQL_INJECTOR_REGEX34 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))union/ix");
SQL_INJECTOR_REGEX35 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))and/ix");
SQL_INJECTOR_REGEX36 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))insert/ix");
SQL_INJECTOR_REGEX37 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))select/ix");
SQL_INJECTOR_REGEX38 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))delete/ix");
SQL_INJECTOR_REGEX39 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))update/ix");
SQL_INJECTOR_REGEX40 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))truncate/ix");
SQL_INJECTOR_REGEX41 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))declare/ix");
SQL_INJECTOR_REGEX42 = regcomp("/((\%2F)|(\/))**((\%2F)|(\/))exec/ix");
42个正则表达试过滤SQL INJECTOR的用法,但是我声明一点,这里不能过滤SQL INJECTOR的变形语法,也不能过滤SQL INJECTOR的POST的注射方法,因为这里不检测POST DATA部分.
目前技术圈子的局面就是防止SQL INJECTOR没有太好的办法,在主机上做防注射是主流.
这里就不一一解释这么多的regex的含义了,在SNORT里完全可以使用这些regex.
总结一下:这42个表达式不是功能较多的,最好还是针对某些特殊的注射点,再加上特定的URL作为条件过滤,这样就不容易产生误报,还有就是URL的编码格式的问题,这些42条并没有考虑到,如果你要用这些表达式,可以做针对性的测试.
M) 有关CC攻击的问题
1) WEBCC
CC攻击,本身是比较难检测的,它有两种可能:
a) 好多台主机,每台主机就是在做傀儡主机时,每次发少量的攻击包,GET某个网站的某个网页,一台这种情况就不构成CC攻击,但是大量的主机就可以造成CC攻击
b) 少量主机,每台傀儡主机短时间内发大量的CC攻击包攻击某个网站
目前我们写的防CC攻击的签名是针对第二种情况的.我们定义一个被保护对象,在每个定时器所规定的时间内,有到WEB端口的源主机GET数据报的数量超过我们定义的上限时就告警,软件里还设定如果一次认为源地址是CC攻击的源,下次来就不用判断,直接阻断,知道系统的缓冲满了,自动释放,下次再让这个源地址访问,进入下一次的CC攻击的判断.
总结一下:CC攻击是应用层的攻击,是TCP完全建立握手的情况下进行的,没办法检测协议异常,只能做HTTP层的统计,这个检测方法属于统计特征检测.
对付上面提到的a)攻击方式,没有太好的办法.
4. 规则和签名里的注意点
A) 有关签名调试
1) 做NCODE编码开发难度并不大,比SNORT规则稍微复杂一点,第一要认清函数的用法,常见函数要会用.第二NFR有好多原理性的例子不能随便贴,开发签名初期要知道写哪类签名需要哪些好的模版.第三几个NFR文件acf.cfg.values,nfr要彻底认清楚格式,不能疏漏.第四签名推上去检测不出来的原因有几个:a)签名的语法还是有问题,比如原来应该写成sample1_alert,结果写成sample1___alert,多下划线等 b)设备接法不对,根本抓不到发包机来的包 c)签名函数用错,类型之间不能转化,但是可以通过SENSOR的语法检查,这个比较难找,要靠经验 d)检测特征根本就不准确,比如软件第一次运行有某些包,运行第二次某些包软件就不发了,你把这个作为特征,就没法检测,还有就是软件的版本问题,有些版本有某些特征,有些就没有,找特征最好避开软件的版本,找比较通用的特征
2) SNORT签名,我认为如何消除误报,如何基于原理写RULES是比较重要的,在一两条规则中对某些特殊的攻击写特征还是一件不太容易的事情
B) 规则和签名误报的问题
1) 对某些签名或RULES我们可以采用端口范围作为过滤条件,PAYLOAD的长度范围也作为判断条件,比如P2P
2) 一些HTTP的访问的特征比较容易误报,因为现在的网络的出口上基本都是走的HTTP流量,异常情况比较多,这个没太好办法,就是多做测试
3) 一些溢出的检测可以把PAYLOAD的长度作为条件,某些特殊攻击的溢出地址作为判断,还有一些特殊协议,比如RPC,SMB协议的溢出,最好加上协议特征,这样才好消除误报
C) 关于IDS检测和IPS阻断的问题
1) IDS检测出来和IPS能阻断是两码事,能检测,不一定能阻断,如果是检测出主要数据报,比如应用握手的数据报,可能就阻断效果比较好,如果就检测出某些CONTROL包,可能还有一些DATA包能过的,就是没有阻断效果
2) 随着软件的版本不同,即便有些软件能检测到,但是不能阻断,这个说明软件里的这个特征已经不是主要的CONTROL或DATA包了,这样可以考虑修改更新签名
3) 在NFR的SENSOR上有动态黑名单的东西,如果阻断有困难,可以使用它来切断源,但是对UDP协议的特征包就没用
