导致惨重代价的运维事故

光大证券事件
2013年8月,光大证券在向客户演示时连接了正式数据库,导致股市震荡,被罚款5.2亿。

宁夏银行删库事件
2014年7月,宁夏银行在季末结算业务量较大的情况下,因备份系统异常导致备份存储磁盘读写处理严重延时,备份与主存储数据不一致。工程师在采取中断数据备份录像操作后,造成生产数据库损坏并宕机。造成38小时,700多定点医疗机构和定点零售药无法使用医保支付。

小插曲,2014年5月宁夏银行使用CDP软件进行了一场容灾演练,曾完成800公里的容灾切换。

携程删库事件
2015年5月,携程无法访问。官方反馈是由于运维工程师误操作,误删生产环境,而且重新部署后还是会被删除。经过十几小时努力,最终恢复成功。

小插曲,携程挂掉后,导流给了艺龙,结果艺龙也挂了。

Gitlab删库事件
2017年2月,Gitlab运维人员,在应对前一晚的DDOS攻击后,发现备库复制数据缓慢,并无法解决。最终决定删除备库,重新开始复制。但在十分疲倦的情况下,工程师误删了300G的生产数据,由于备份机制设置不合理,最终导致20多小时系统宕机,707位用户丢失数据,5,037项目丢失,受事故影响的用户基数不到1%。
我们可以看到的问题有:
1、审核和监控全部备份策略:虽然Gitlab号称有五重备份机制:常规备份24小时做一次、自动同步、LVM快照24小时做一次、Azure备份对数据库无效、S3备份。但没有一个可靠地运行或设置,而且备份失败也没有良好的预警机制。最终只能基于LVM的备份(最近6小时以前),还原了6 小时前的备份。
2、积极演练应对重大问题,保证备库是随时可用的,应急时也应该有序进行
3、数据中心之间数据传输要考虑好,本次数据传输也花费了较长时间
4、防止人肉运维,谨防开夜车,脚本工具化自动化。人总归会出错,而且总是在最不该发生的时候出错。
5、Gitlab本次事故发生后,公开透明的处理方式,值得大家借鉴和尊重。

AWS删服务器事件
2017年3月,AWS服务异常,经过4个多小时才恢复正常。
原因为:一名S3工程师根据预先编写的playbook执行一条命令时,输入命令时输错了一个字母,结果删除了一大批本不该删除的服务器。

verelox.com删库事件
2017年6月,荷兰云主机厂商verelox.com,一前任管理员,恶意报复公司,删除全部用户数据,并擦出了多数服务器上面的内容。

链家删库事件
2018年6月4日,链家网财务系统数据被删,这9TB数据,包括了该公司成立以来所有的财务数据。
经过紧急修复,该批数据最终得以恢复。
事件原因:由于管理制度漏洞百出,一名数据库运维人员轻易获得了不应有的高权限。该工程师与公司起了争执,修改MAC地址后,直接删库。

小插曲:
该工程师,只改了MAC地址,但并未变更主机名、IP,被系统日志记录。
修改MAC地址,也用了第三方软件,该软件日志几乎坐实了其犯罪行为。
而且删除的数据,很容易就被恢复了,只花了18万。技术方面,及其不专业。
最终,该工程师拒不配合调查,也不认罪,最终被判刑7年。

广西移动扩容事件
2017年9月,华为工程师在进行广西移动扩容时,误将HSS设备的用户数据格式化,导致广西移动损失80万用户数据。

顺丰删库事件
2018年9月,顺丰一个高级工程误删线上库,然后跑路。导致部分服务无法使用并持续近10小时。

郑大附一数据库事件
2018年12月24日,郑大附一的一名工程师,由于操作不当导致HIS库被锁表,让该医院门诊业务停止2小时。
该工程师被判刑5年6个月。

导致惨重代价的Bug

导致惨重代价的Bug

纪念“瞳”解体事件

千年虫事件
在上个世纪,软件行业初期,计算机硬件资源十分昂贵,很多软件为了节省内存会省略掉代表年份的前两位数字”19”,或默认前两位为”19”。按这个规则,1999年12月31日过后,系统日期会更新为1900年1月1日而不是2000年1月1日,这样可能意味着无数的灾难事件,导致数据丢失,系统异常或更加严重的灾难。

幸好大家发现的早,最终全球花了上亿的美元用来升级系统,没有引起毁灭性后果。

水手1号探测器
1962年7月28日,水手1号空间探测器发射升空,但由于程序编码中的轨道计算公式是错误的,导致火箭轨道偏离预定路线。最终在大西洋上空自爆。

南极臭氧层测绘事件
1978年,NASA启动臭氧层测绘的计划。但在设计时,用于该计划的数据分析软件忽略了和预测值有很大差距的数据。直到1985年,才发现南极洲上方的臭氧层空洞,但是英国科学家先发现的。直到NASA重新检测它们的数据,才发现这一错误。在修正错误后,NASA证实南极臭氧层的确有个很大的空洞。

反导系统误报事件
1980年,北美防空联合司令部曾报告称美国遭受导弹袭击。后来证实,这是反馈系统的电路故障问题,但反馈系统软件没有考虑故障问题引发的误报。

1983年,苏联卫星报告有美国导弹入侵,但主管官员的直觉告诉他这是误报。后来事实证明的确是误报。

幸亏这些误报没有激活“核按钮”。在上述两个案例中,如果对方真的发起反击,核战争将全面爆发,后果不堪设想。

辐射治疗超标事件
1985到1987年,Therac-25辐射治疗设备卷入多宗因辐射剂量严重超标引发的医疗事故,其罪魁祸首是医疗设备软件的Bug。据统计,大量患者接受高达100倍的预定剂量的放射治疗,其中至少5人直接死于辐射剂量超标。

AT&T网络终端事件
1990年1月15日,纽约60万用户9个小时无法使用电话服务。原因是,AT&T交换机从故障中恢复后,就会发送一条特殊的小时给临近的设备,但在新版本软件中,这条消息会导致电话交换机重启。于是,每6秒,所有交换机都会重启一次。最后,将程序换回了上一个版本,解决了问题。

宰赫兰导弹事件
在1991年2月的第一次海湾战争中,一枚伊拉克发射的飞毛腿导弹准确击中美国在沙地阿拉伯的宰赫兰基地,当场炸死28个美国士兵,炸伤100多人,造成美军海湾战争中唯一一次伤亡超过百人的损失。

在后来的调查中发现,由于一个简单的计算机bug,使基地的爱国者反导弹系统失效,未能在空中拦截飞毛腿导弹。当时,负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时,每工作一个小时,系统内的时钟会有一个微小的毫秒级延迟,这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位,因而时间的精度也只限于24位的精度。在长时间的工作后,这个微小的精度误差被渐渐放大。在工作了100小时后,系统时间的延迟是三分之一秒。

对一般人人来说,0.33秒是微不足道的。但是对一个需要跟踪并摧毁一枚空中飞弹的雷达系统来说,这是灾难性的——侯赛因飞毛腿导弹空速达4.2马赫(每秒1.5公里),这个“微不足道的”0.33秒相当于大约600米的误差。在宰赫兰导弹事件中,雷达在空中发现了导弹,但是由于时钟误差没有能够准确地跟踪它,因此基地的反导弹并没有发射。

Intel奔腾处理器浮点错误
1993年。Intel奔腾处理器在计算特定范围的浮点数除法时,会发生技术错误。Intel最终花费了4.75亿美元来为用户置换处理器。

飞行事故
1993年,瑞典的一架JAS 39鹰狮战斗机因飞行控制软件的Bug而坠毁。

1994年,苏格兰一架吉努克型直升飞机坠毁,29名乘客全部罹难。然而最初指责声都指向飞行员,但后来有证据表明,直升飞机的系统错误才是罪魁祸首。

死Ping
1995-1996年,由于没有进行足够的校验,在收到特殊构造的Ping包时,会导致Windows设备蓝屏并重启。

阿丽亚娜5型运载火箭事件
1996年6月4日,阿丽亚娜5型运载火箭的首次发射点火后,火箭开始偏离路线,最终被逼引爆自毁,整个过程只有短短30秒。(原计划将运送4颗太阳风观察卫星到预定轨道)

阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中,对一个水平速率的测量值使用了16位的变量及内存,因为在4型火箭系统中反复验证过,这一值不会超过16位的变量,而5型火箭的开发人员简单复制了这部分程序,而没有对新火箭进行数值的验证,结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量,引发了一系列的错误,从而影响了火箭上所有的计算机和硬件,瘫痪了整个系统,因而不得不选择自毁,4亿美元变成一个巨大的烟花。

火星气候探测者号事件
1999年9月,火星气候探测者号在火星坠毁。火星气候探测者号的目的为研究火星气候,花费3亿多美元。探测者号在太空中飞行几个月时间,接近火星时,探测器的控制团队使用英制单位来发送导航指令,而探测器的软件系统使用公制来读取指令。这一错误导致探测器进入过低的火星轨道(大约100公里误差),在火星大气压力和摩擦下解体。

火火星极地登陆者号件
1999年12月,火星极地登录者号在火星坠毁,原因是设计缺陷导致其在达到行星地表之间就关闭了主引擎,最终撞毁。

辐射治疗超标事件
2000年11月,巴拿马美国国家癌症研究所,从美国Multidata公司引入了放射治疗设备及软件,但其辐射剂量计算值有误(软件本身运行医生画四个方块来保护患者健康组织,但医生需要五块,于是医生自己想办法欺骗了软件,殊不知该操作方式将放射剂量进行了加倍处理)。部分患者接受了超标剂量的治疗,至少有5人死亡。后续几年中,又有21人死亡,但很难确定这21人中到底有多少人是死于本身的癌症,还是辐射治疗剂量超标引发的不良后果。

北美大停电事件
2003年8月,由于GE的一个监控软件,没有有效的通知操作人员有一个地方电站断掉了,电力缺口导致了多米诺骨牌效应,最终导致了加拿大安大略州和美国八个州断电,影响到了5千万人,总损失达60亿美元。

丰田普锐斯混合动力汽车召回事件
2005年10月,丰田宣布召回16000辆锐斯混合动力汽车。这次召回的原因是“发动机熄火意外”及“警示灯无故开启”。本次召回的根本原因不是硬件问题,而是汽车嵌入式编程代码的问题。

东京证券交易所事件
2005年12月,J-COM公司上市,开盘价格61.2万日元一股,日本瑞穗证券的一个交易员接到了客户委托“请以61万日元的价格,卖出1股J-Com的股票”。但交易员输入成了“以每股1日元的价格,卖出61万股”。由于交易系统限制,交易系统自动调整为“以57万日元,出售61万股”。

2分钟后,操作员发现操作失误,执行了3次撤单操作全部失败。J-COM股票一路狂跌,瑞穗证券拼命拉高到77.2万日元,仅此一项,瑞穗证券一共损失了约270亿日。但仍引起了很大的连锁效应。

更大的问题是,J-COM的股票一共只发行了14000多股,但卖出去的可远不止这么多。最后经过协商,瑞穗证券用每股91万日元的价格,现金清算了股民手上的9万多股,全部损失,扩大到400多亿日元。

然后瑞穗证券状告东京证券和富士通,官司打了十年。最后判定,以当日瑞穗证券电话联络东京证券的时间点为分界线,之前全部由瑞穗证券承担,之后产生的损失由东京证券承担70%瑞穗证券承担30%。富士通及程序员没有收到罚款。

恩,痛定思痛,决定开始开发了新的交易系统,开发商仍然是富士通。

Gmail故障
2009年2月份Google的Gmail故障,导致用户几个小时内无法访问邮箱。据Google反馈,故障是因数据中心之间的负载均衡软件的Bug引发的。

温州7.23动车事故
2011年7月23日,甬温线浙江省温州市境内,由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故,造成40人死亡、172人受伤,中断行车32小时35分,直接经济损失近2亿元。

上海铁路局事后反馈,“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷,遭雷击发生故障后,导致本应显示为红灯的区间信号机错误显示为绿灯。

骑士资本事件
2012年8月1日,骑士资本的技术人员,在1台设备中部署了错误版本的应用(一共8台,7台正常),该设备触发了n年前的代码,在一个小时内就执行完了原本应该在几天内完成的交易,导致错误的买入卖出,直接将公司推向了破产的边缘,投资人紧急注资4亿美元才得以幸免,最终损失高达5亿美元。

12306订票助手拖垮GitHub
2013年1月15日,GitHub受到中国大陆的DDOS攻击,网站几乎被拖垮。

最后发现,是由于春运期间,各大浏览器厂商集成了一位网友iFish(木鱼)的“订票助手”插件,帮助春运大军抢票回家。但该软件的早期版本,直接引用了GitHub的Raw File而不是静态文件,并且在访问文件失败时,每5S会重试一次。这样,抢票大军的每一个人,没5S都会向GitHub发送一次请求,造成对GitHub的DDOS攻击。

OpenSSL Bleeding Heart漏洞
2014年4月,谷歌和芬兰安全公司Codenomicon分别报告了OpenSSL存在重大缓冲区溢出漏洞。在OpenSSL心跳扩展的源码中,没有去校验缓冲区的长度,导致攻击者可以直接获取网站的私钥信息。这次漏洞的影响面很广,几乎所有厂商都在打补丁和更新私钥及证书。

Twitter丢失400万活跃用户
2015年2月,Twitter在在季度财报中指出,苹果iOS8升级后出现的漏洞让Twitter至少损失了400万用户。首先是iOS8和 Twitter的兼容性问题流失了100万用户,Safari流览器升级后的共用链接功能无法自动升级,这一问题流失了300万用户,另外还有100万iPhone使用者在升级系统后忘记了Twitter密码,导致无法使用而离开了Twitter。

日本天文卫星“瞳”解体事件
2016年03月,日本天文卫星升空不到一个月(仅正常工作3天),就解体了,该卫星造价约19亿人民币,并搭载了多国的观测设备。
首先,由于干扰,追星仪发生了故障,启用了备用的陀螺仪。
但是,陀螺仪也有故障,导致没有旋转的卫星开始加速旋转,并达到阀值。
然后,为了阻止卫星旋转,卫星开始反向喷气,但程序员把喷气的方向搞反了,卫星越转越快,最终解体。

============================================================
注:本文主要是整理了系统Bug导致的惨痛代价,没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)
*从计算机诞生以来,众多失败的软件项目,没有加到列表中
*1982年,苏联天然气管道爆炸事件,涉及植入恶意代码,没有加到列表中

Tomcat指定native library路径

一般,指定JVM的native library路径,只需要用下面的参数就好了

-Djava.library.path=PATH_TO_NATIVE_LIBRARY

Tomcat指定native library路径时,还是不要使用这边参数的好。
建议直接修改PATH环境变量,将dll或so放到环境变量PATH的路径下就好了。
TOMCAT默认将PATH赋值给-Djava.library.path参数的。

SUN PKIX、AXIS2及C#在HTTPS认证方式的区别

最近尝试了用两级自签名证书来验证SUN PKIX、AXIS2及C#在HTTPS认证方式的区别。
两级证书为:
1、CA证书NMyCA1024
2、服务器证书serversigned

其中,AXIS2通过验证是最简单的,
1、服务端设置serversigned证书的Key Store
2、客户端设置NMyCA1024或serversigned的Trust Store
3、通过验证。

如果要SUN PKIX通过验证(Oracle的JDK/JRE自带)
1、那需要服务端设置serversigned证书的Key Store
2、客户端设置NMyCA1024或serversigned的Trust Store
3、客户端把NMyCA1024证书导入JDK或JRE的CA证书列表cacerts
4、通过验证。

如果要C#通过验证
1、那需要服务端设置serversigned证书的P12文件
2、客户端设置NMyCA1024或serversigned的Trust Store
3、客户端双击NMyCA1024证书导入IE的CA证书列表
4、通过验证。

处理windows控制字符0x17

今天同事遇到了很诡异的问题,就是从数据库中读取一个字段时,有些数据中,会多一个0x17的控制字符。

暂时没太好的处理方法,自己写了个测试例子,仅供参考吧:

for java

    public static void main(String[] args)
    {
        byte[] b= { 0x30, 0x30, 0x1f, 0x37, 0x39, 0x33, 0x39, 0x36, 0x34, 0x31 };
        byte[] bt={0x1f};
        String s1 = new String(b);
        String st= new String(bt);
        String s2 = s1.replace(st,"");
        String s3 = s1.replace((char)0x1f,' ').replace(" ","");
        System.out.println(s1);
        System.out.println(s2);
        System.out.println(s3);
    }

for charp

        static void Main(string[] args)
        {
            Byte[] b = { 0x30, 0x30, 0x1f, 0x37, 0x39, 0x33, 0x39, 0x36, 0x34, 0x31 };
            Byte[] bt = {0x1f};
            String s1 = System.Text.Encoding.Default.GetString(b);
            String st = System.Text.Encoding.Default.GetString(bt);
            String s2 = s1.Replace(st, "");
            String s3 = s1.Replace((char) (0x1F), ' ').Replace(" ", "");
            Console.WriteLine(s1);
            Console.WriteLine(s2);
            Console.WriteLine(s3);
            Console.ReadLine();
        }

IPv6地址规则

一、IPv6顾名思义,其地址长128bit(2的64次方)。
为了便于记忆,通常采用16进制表示,每4个16进制为一段,共8段(8*4*4=128):
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
其中,XXXX范围为0000-FFFF

二、IPv6地址表示,主要有下面几种:
1、首选法,即每一位都写全,比如:
0234:0000:0000:0000:1234:0000:0000:2234
0000:0000:0000:0000:0234:0000:0000:2234
但这样不便于书写,于是人们想办法来进行缩写

2、将相连的0000,表示为::,但只允许出现一次,上面的地址可以缩写为
0234::1234:0000:0000:2234
::0234:0000:0000:2234

3、将每一段的前导0去掉,这样上面的地址变为
234::1234:0:0:2234
::234:0:0:2234
这样就便于人们记忆了

4、另外,IPv6可以兼容IPv4:
IPV4兼容的IPV6地址,用于在IPV4网络上建立自动隧道,以传输IPV6数据包:
0000:0000:0000:0000:0000:0000:YYY.YYY.YYY.YYY
其中,YYY范围为000-255
映射IPV4的IPV6地址,仅用于拥有IPV4和IPV6双协议栈节点的本地范围:
0000:0000:0000:0000:0000:FFFF:YYY.YYY.YYY.YYY
其中,YYY范围为000-255

三、IPv6的地址分为单播(Unicast)、多播(Multicast)和任意播(Anycast)。
其中单播分为本地链路,本站点地址,ULA,可聚合全球单播地址,回环。
1、本地链路地址(Link-Local Addresses):同一链路相邻节点之间通讯,不能被路由
地址前10个bit是1111 1110 10,规则为FE80::/64,即FE80::/10+54bit0+EUI-64
FE80:0000:0000:0000:EUI-64

2、本地站点地址(Site-Local Addresses):只能在一个站点内使用,私有地址
地址前10个bit是1111 1110 11,规则为FEC0::/48,即FEC0::/10+38bit0+16bit子网表示+EUI-64
FEC0:XXXX:XXXX:XXXX:EUI-64

3、唯一的本地IPv6单播地址(ULA,Unique Local IPv6 Unicast Address):用于替代Site-Local Addresses
地址规则为FD00::/8,后面跟一个被称为全局ID的40bit随机标识符。

4、可聚合全球单播地址(Aggregatable Global Unicast Addresses):公网地址,全球路由
前三bit为001,第一个地址为:
2000:0000:0000:0000:0000:0000:0000:0000
最后一个地址为:
3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

5、回环地址:
0000:0000:0000:0000:0000:0000:0000:0001
0:0:0:0:0:0:0:1
::1

6、未指定地址(Unspecified address)
0000:0000:0000:0000:0000:0000:0000:0000
0:0:0:0:0:0:0:0
::

四、多播地址:一对多
前8个bit为1111 1111,地址规则为FE00::/8
FF01::到FF0F::的多播地址是保留专用地址
FF01::1 节点本地范围所有节点多播地址
FF02::1 链路本地范围所有节点多播地址
FF01::2 节点本地范围所有路由器多播地址
FF02::2 链路本地范围所有路由器多播地址
FF05::2 站点本地范围所有路由器多播地址

五、任意播:任意播是多个设备共享一个地址,应用在一到附近模式(one-to-nearest)
发送方发送一个以任意播为目标地址的包,当路由器接受到这个包以后,就转发给具有这个地址的离它最近的设备。
任意播地址是从单播地址中划分出来的,对于那些没有配备任意播的的地址就是单播地址;但是当一个单播地址分配给不止一个接口的时候,单播地址就成了任意播地址。
所以单播地址与任意播地址的规则是一样的。

六、EUI-64计算方法:
假设电脑的MAC是00:0C:85:AB:50:01;
首先在MAC地址正中间插入FFFE,得到00:0C:85:FF:FE:AB:50:01
然后由左到右第七bit置反,得到02:0C:85:FF:FE:AB:50:01
将其改写为EUI-64规则,得到020C:85FF:FEAB:5001
需要对第七位取反的原因:
在MAC地址中,第7比特为1表示本地管理,为0表示全球管理
在EUI-64格式中,第7位为1表示全球惟一,为0表示本地惟一

七、隧道协议地址转换
6over4地址
[64bit-prefix]:0:0:WWXX:YYZZ,其中的WWXX:YYZZ是w.x.y.z IPv4公共地址的十进制点号表示法,用于一个使用6to4协议的隧道机制的节点。
6to4地址
2002:WWXX:YYZZ:[SLA ID]:[Interface ID],用于表示一个使用6to4协议的隧道机制节点。

Wireshark过滤规则

Wireshark是一个很好用的sniffer工具,插件十分强大。有时,为了判断问题,在日常工作中也会用到一些,现在记录一部分常用的过滤规则:

1、运算符

lt < 小于
le <= 小于等于
eq == 等于
gt > 大于
ge >= 大于等于
ne != 不等
and && 与操作
or || 或操作
not ! 非操作

2、ip、mac和port过滤

#过滤ip地址为192.168.1.102的全部数据包
ip.addr eq 192.168.1.102
#过滤从192.168.1.102发来的数据包 或 发往192.168.1.102的数据包
ip.src eq 192.168.1.102 or ip.dst eq 192.168.1.102

#过滤MAC地址为00:00:00:01:02:03的所有包
eth.add eq 00:00:00:01:02:03
#过滤MAC地址为00:00:00:01:02:03发送的包 或 发往00:00:00:01:02:03的包
eth.src eq 00:00:00:01:02:03 or eth.dst eq 00:00:00:01:02:03

#过滤8080端口全部tcp数据包(接收和发送)
tcp.port eq 8080
#过滤8080端口发送的全部tcp数据包 或 发送到8080端口全部tcp数据包
tcp.srcport eq 8080 or tcp.dstport eq 8080

#过滤21端口全部udp数据包(接收和发送)
upd.port eq 21
#过滤21端口发送的全部udp数据包 或 发送到21端口全部udp数据包
udp.srcport eq 21 or udp.dstport eq 21

#过滤1024以内端口数据包
tcp.port <= 1024

#去掉tcp数据包
!tcp
#或
not tcp

3、包长度过滤

#udp报文长度等于100
udp.length eq 100

#udp数据长度等于92
udp.len eq 92

#经常可以用到eth(farme),ip,arp,tcp,udp等协议的包长度
#注意区分包长度和payload长度

4、HTTP协议

#过滤GET方法的HTTP数据包
http.request.method == "GET"

#按URI过滤HTTP数据包
http.request.uri == "/image/logo.gif"

#按内容过滤HTTP数据包
http contains "Content-Type: application/dicom"

5、匹配规则

\d 0-9的数字
\D \d的补集
\w 单词字符,即大小写字母、0-9的数字、下划线
\W \w的补集
\s 空白字符,包括换行符\n、回车符\r、制表符\t、垂直制表符\v、换页符\f
\S \s的补集
. 除换行符\n外的任意字符
.* 匹配任意文本
[…] 匹配[]内所列出的所有字符
[^…] 匹配非[]内所列出的字符
^ 表示其后的字符必须位于字符串的开始处
$ 表示其前面的字符必须位于字符串的结束处
\b 匹配一个单词的边界
\B 匹配一个非单词的边界
{n} 匹配前面的字符n次
{n,} 匹配前面的字符n次或多于n次
{n,m} 匹配前面的字符n到m次
? 匹配前面的字符0或1次
+ 匹配前面的字符1次或多于1次
* 匹配前面的字符0次或式于0次

6、包匹配

#字节匹配,比如匹配payload第一个字节0x14的UDP数据包
udp[8]==14

#范围匹配,经常使用到tcp[offset,n],比如匹配payload的前4个字节0x0004002a
udp[8:4]==00:04:00:2a

#正则匹配,要用match,比如匹配HTTP1.1协议的数据包
tcp[20:] matches "^GET [ -~]*HTTP/1.1\\x0d\\x0a"

7、示例

#DICOMClient 上抓取 DICOMServer
ip.dst eq 服务端ip &&  tcp.port eq 104

#DICOMServer 上抓取 DICOMClient
tcp.port eq 104

#HL7v2Client 上抓取 HL7v2Server
ip.dst eq 服务端ip &&  tcp.port eq 3306

#HL7v2Server上抓取 HL7v2Client 
tcp.port eq 3306