Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq Archives: Re: explanation and code for stream.c issues

Re: explanation and code for stream.c issues

Subject: Re: explanation and code for stream.c issues
From: Vladimir Dubrovin (vladSANDY.RU)
Date: Sat Jan 22 2000 - 04:41:35 CST

Hello Tim Yardley,

21.01.00 22:15, you wrote: explanation and code for stream.c issues;

>>T> -- start rule set --
>>T> block in quick proto tcp from any to any head 100
>>T> pass in quick proto tcp from any to any flags S keep state group 100
>>T> pass in all
>>T> -- end rule set --
>>Attack can be easily changed to send pair SYN and invalid SYN/ACK

My mistake here - SYN/ACK packet isn't required. Sorry, i wrote this
message after 11 hours of work.

Intruder sends SYN packet and then sends, lets say 1000 ACK packets to
the same port from same port and source address. SYN packet will open
ipfilter to pass all others packets. This attack doesn't need
randomization for each packet.

By the way - published stream.c doesn't use ACK bit at all.
    packet.tcp.th_flags = 0;
It looks like usual flooder and can be easily filtered with ipfw by
blocking packets without any flags set (this packets are invalid for
allow tcp from any to any tcpflags ack
allow tcp from any to any tcpflags syn
allow tcp from any to any tcpflags syn,ack
deny tcp from any to any

Attached is patched stream.c which sends (SYN packet + 1023 ACK
packets) from random port and source. This ipfw rule and published
ipfilter rule will be unusable against this attack. In my current
location i can't test it.

T> As was mentioned in the "advisory/explanation" on the issue, ipfw cannot
T> deal with the problem due to the fact that it is stateless.

T> The attack comes from random ip addresses, therefore throttling like that
T> only hurts your connection or solves nothing at all. In other words, the
T> random sourcing and method of the attack, makes a non-stateless firewall
T> useless.

It would be better if you reed the rule before answering. Of cause,
ipfw can't find invalid ACK packets. But if OS supports DUMMYNET
option ipfw can be used to limit the number of packets in a fixed
amount of time. In this case:

ipfw pipe 10 config delay 50 queue 500 packets
ipfw add pipe 10 tcp from any to $MYHOST in via $EXTERNAL

we limit router ro only allow 500 TCP packets in every 50ms. Average
size of tcp packet is approx. 500 bytes (you can test it). So, you
allow bandwidth of 40M pbs for standard TCP traffic. But this rule
will effectively block any spoofing attack which uses small packets.
If 50-bytes packets are used this rule will allow only bandwith 4M bps
for such attack. Not only "ACK" attack, but any flood. We didn't check
source, so we closed against any spoofing.

Of cause in this case you will loose TCP packets during an attack and
connections can be dropped, but at least your host will be safe. As it
was pointed, _any_ packet filter, including ipfilter, can't solve this
problem completely.

  |Vladimir Dubrovin|
  | Sandy Info, ISP |

  • application/octet-stream attachment: stream.c

This archive was generated by hypermail 2b27 : Sun Jan 23 2000 - 17:19:38 CST