Re: explanation and code for stream.c issues

[vlad () SANDY RU (Vladimir Dubrovin)]

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
TCP).
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 |
  +=-=-=-=-=-=-=-=-=+

<HR NOSHADE>
<UL>
<LI>application/octet-stream attachment: stream.c
</UL>