没事在看Juniper Netscreen的警报日志,看到有一条SYN-ACK-ACK记录。
正常情况下TCP/IP协议中SYN握手大致上如此:
- A(发起者)发送一个SYN给B(接收者)
- B回复SYN-ACK给A
- A回复ACK给B
- 连接成功!
这个过程的缺陷是,如果A是有恶意的来源,始终不停的发送SYN给B,那么B就会不停的建立起空连接(未完成的连接)等待A的ACK响应,只要A不回应,B的空连接就会不断的消耗资源,直至无法响应。
It's Cool to OpenSource
没事在看Juniper Netscreen的警报日志,看到有一条SYN-ACK-ACK记录。
正常情况下TCP/IP协议中SYN握手大致上如此:
这个过程的缺陷是,如果A是有恶意的来源,始终不停的发送SYN给B,那么B就会不停的建立起空连接(未完成的连接)等待A的ACK响应,只要A不回应,B的空连接就会不断的消耗资源,直至无法响应。
一直没有空下来深入研究以下Juniper的Netscreen。正巧的是前些日子,公司有一台204-B出现了故障,这才有机会研究了一下。
公司的分支机构相对都很散,每个分支相对人数较少。Firwall+Route+VPN的组合维护起来非常方便。一般性的情况下NS5-GT这类的设备加10个用户授权就足够了。对于稍微人数多一点的机构,就需要204这类的东西了(MS是没有用户数限制的)。总部则使用了SSG550支撑。
相比其他的产品,Netscreen感觉上webUI的配置方式很是方便,特别适合像我这类懒的背命令的人——虽然看上去命令并不复杂。