4 ms·

I guess this explains why netcraft keeps showing their website as mostly down worldwide for the last day or so when it's actually performing extremely well. Qu

by trotsky 16y ago

I guess this explains why netcraft keeps showing their website as mostly down worldwide for the last day or so when it's actually performing extremely well. Question: why does the RST packet identify non-existent nodes? Doesn't TCP sequence prevent a blind continuation of a http request? Is this just one type of syn flood protection?

jjoe 16y ago
Most likely, the initial Netcraft attempt to connect is met with a RST. Subsequent attempts are also met with the same RST. This is because the attempts are spaced out in time enough for the original ACL, permitting access, to be flushed. According to the RFC, the RST does not get an ACK if the initiating node is "legitimate." So the "silence" or non-ACK is a good sign, which results in the initiating node being added to the ACL. You don't want plain TCP handling this because of half-open TCP handshakes which can exhaust kernel data structures (memory) and CPU (from having the kernel sift through a large data set). Regards
- trotsky 16y ago
  Thank you for your insight. A bogus IP - one that no one is listening on - would also not ACK a RST, right? Doing a little googling this process seems to detect an attack (from a valid ip) that has been programmed to ignore RST - presumably because some intermediate ISPs (like tier1 borders) will detect a DDOS and forge a RST to attempt to mitigate them. Much like the firewall configs that circulated to defeat sandvine RST throttling of bittorrent.
  - jjoe 16y ago
    A bogus host will obviously not respond to the RST but the last router-hop that receives the RST will (per RFC/protocol specs). The response is destination unreachable via ICMP. The ICMP unreachable packet is cheap (non-persistent) and requires no up-keep from the last hop to the bogus host. Most importantly, the ICMP unreachable packet requires no upkeep from the filtering node in EC2. Regards
    - trotsky 16y ago
      thanks much!

by trotsky 16y ago

jjoe 16y ago

Most likely, the initial Netcraft attempt to connect is met with a RST. Subsequent attempts are also met with the same RST. This is because the attempts are spaced out in time enough for the original ACL, permitting access, to be flushed. According to the RFC, the RST does not get an ACK if the initiating node is "legitimate." So the "silence" or non-ACK is a good sign, which results in the initiating node being added to the ACL. You don't want plain TCP handling this because of half-open TCP handshakes which can exhaust kernel data structures (memory) and CPU (from having the kernel sift through a large data set). Regards

trotsky 16y ago
Thank you for your insight. A bogus IP - one that no one is listening on - would also not ACK a RST, right? Doing a little googling this process seems to detect an attack (from a valid ip) that has been programmed to ignore RST - presumably because some intermediate ISPs (like tier1 borders) will detect a DDOS and forge a RST to attempt to mitigate them. Much like the firewall configs that circulated to defeat sandvine RST throttling of bittorrent.
- jjoe 16y ago
  A bogus host will obviously not respond to the RST but the last router-hop that receives the RST will (per RFC/protocol specs). The response is destination unreachable via ICMP. The ICMP unreachable packet is cheap (non-persistent) and requires no up-keep from the last hop to the bogus host. Most importantly, the ICMP unreachable packet requires no upkeep from the filtering node in EC2. Regards
  - trotsky 16y ago
    thanks much!