SYN-ACK-ACK攻击和SYN COOKIE

没事在看Juniper Netscreen的警报日志,看到有一条SYN-ACK-ACK记录。

正常情况下TCP/IP协议中SYN握手大致上如此:

  1. A(发起者)发送一个SYN给B(接收者)
  2. B回复SYN-ACK给A
  3. A回复ACK给B
  4. 连接成功!

这个过程的缺陷是,如果A是有恶意的来源,始终不停的发送SYN给B,那么B就会不停的建立起空连接(未完成的连接)等待A的ACK响应,只要A不回应,B的空连接就会不断的消耗资源,直至无法响应。

继续阅读“SYN-ACK-ACK攻击和SYN COOKIE”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍

netscreen的使用感受

一直没有空下来深入研究以下Juniper的Netscreen。正巧的是前些日子,公司有一台204-B出现了故障,这才有机会研究了一下。

公司的分支机构相对都很散,每个分支相对人数较少。Firwall+Route+VPN的组合维护起来非常方便。一般性的情况下NS5-GT这类的设备加10个用户授权就足够了。对于稍微人数多一点的机构,就需要204这类的东西了(MS是没有用户数限制的)。总部则使用了SSG550支撑。

相比其他的产品,Netscreen感觉上webUI的配置方式很是方便,特别适合像我这类懒的背命令的人——虽然看上去命令并不复杂。

继续阅读“netscreen的使用感受”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍