网站模版上线需要什么,Reviewer WordPress,企石做网站,如何上传自己做的网站承接前面几篇文章的观点#xff0c;本文用一个安全攻击的例子说明为了解决一个伤害很低的低概率问题#xff0c;会引入多么大的麻烦#xff0c;这次是可怕的被攻击 (⊙o⊙)。
TCP 端口号只有 16bit#xff0c;序列号只有 32bit#xff0c;这意味着在强大攻击算力面前本文用一个安全攻击的例子说明为了解决一个伤害很低的低概率问题会引入多么大的麻烦这次是可怕的被攻击 (⊙o⊙)。
TCP 端口号只有 16bit序列号只有 32bit这意味着在强大攻击算力面前它很容易会被 Blind In-Window Attacks 伤害。比如如果一个针对知名服务器 80 端口的攻击者恰好猜对了 sport并且使用 in_window 的序列号伪造了 SYN 报文(or RSTData…)发给服务端服务器将重置正常的连接这种攻击随着主机内存的增加从而 window 的增加而更加容易。
为了让这种 Blind In-Window Attacks 更难以实施RFC5961 引入了 Challenge ACK 的概念如果收到莫名其妙的异常报文(比如异常 SYNRST)将重置的责任推给发送方
向发送方发一个 Challenge ACK如果果真是发送方发生了异常收到 Challenge ACK 后自然会自行 RST 连接否则就是遭受了 Blind In-Window Attack。
多么好的创意却弄巧成拙。
设计者意识到 Blind In-Window Attacks 可能会带来海量的 Challenge ACK 报文注入网络占用带宽资源从而导致另一类 DDoS Attack于是提出 ACK Throttling 方案在固定时间段(比如 1 分钟)只发送固定数量(比如 100)个 Challenge ACK。
是不是很完美是也不是说 “是” 因为想到的问题都解决了说 “不是” 因为总有想不到的。下面是一个闭环
为解决 Blind In-Win Attacks 引入 Challenge ACK 造成潜在 DDoS 引入 ACK Throttling 为 Blind In-Win Attack 提供了有效信息 Blind In-Win Attack 实施更容易不再 Blind
下面是一个攻击图示
如 Linux 常规配置的 Throttling thresh 是 1 分钟 100 次攻击者只需要与熟知端口服务器创建正常连接然后发送一个猜测的 sportseq 携带 SYN 的报文紧接着在 1 分钟内在合法连接 conn-2 中发送 100 个 In-Win 的 RST如果攻击者收到了 100 个 Challenge ACK说明猜错了继续改变 sportseq如果它收到了 99 个 Challenge ACK说明猜对了因为有一个 Challenge ACK 发给了被攻击者 A是不是很有趣
紧接着知道了 sport攻击者便可以用同样的方法猜测 seq 和 ack 来注入数据了。是不是机关算计太聪明反误了卿卿性命
针对这(又一个yet another)个问题我曾经本想着提交一个派池不再用固定的 threshold而是用随机数一会儿换一个当我查代码时发现在 4.7 版本已经更正了
/* RFC 5961 7 [ACK Throttling] */
static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
{.../* Then check host-wide RFC 5961 rate limit. */now jiffies / HZ;if (now ! challenge_timestamp) {u32 half (sysctl_tcp_challenge_ack_limit 1) 1;challenge_timestamp now;WRITE_ONCE(challenge_count, half prandom_u32_max(sysctl_tcp_challenge_ack_limit));}count READ_ONCE(challenge_count);if (count 0) {WRITE_ONCE(challenge_count, count - 1);NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);tcp_send_ack(sk);}
}而在此之前它长这样
/* RFC 5961 7 [ACK Throttling] */
static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
{.../* Then check the check host-wide RFC 5961 rate limit. */now jiffies / HZ;if (now ! challenge_timestamp) {challenge_timestamp now;challenge_count 0;}if (challenge_count sysctl_tcp_challenge_ack_limit) {NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);tcp_send_ack(sk);}
}但天知道会不会有引入另一个问题一定会。
讲这个故事的技术细节不是本意我想表达的是不要为解决一件小事而引入复杂的机制。回到 RFC5961 之前SYNRST 的 Blind In-Win Attack 发生多吗成功概率大吗不是因为它有可能发生就一定要去解决它。此外针对安全问题我一向的观点是 “不与陌生人说话”你说的每句话都在透露信息如果非要说那么 “说谎并且每次说不同的谎”真相不重要重要的是指纹不要让人猜到你的特征。
浙江温州皮鞋湿下雨进水不会胖。
