router syn/syn-ack/ack alarming...

Thu Sep 19 03:55:50 UTC 1996

>Larry writes: 
>>Until someone implements this as a feature, then 2600 will post the code 
>>to a program that sends SYNs followed by ACKs a minute later.  The damage
>>would be done by then, but the stats would show balanced flows.
>
>That's not a terribly useful type of attack.  That can only be done
>from a specific host and can't spoof the originating address.
>To send the second ack, you have to see the SYN/ACK come back
>from the server and know the servers sequence # etc.

The problem is the monitoring tool in the middle now needs to
keep connection state and know the difference between valid
and invalid SYN|ACK segments.  The "unsupported" bits in 
the flow export PDU imply Cisco is allready keeping track
of the sequence numbers/flow internally.  It would be 
interesting if they could send out fake RST's.  It's could
also be potentially fatal!

Adding the following code snipet to flow_print2 (or make
a flow_print3) in flowlib.c (see previous posting)
will probably catch flows that are SYN attacks.

    /* If it's not TCP */
    if (fdata->prot != PROT_TCP)
        return 0;

    /* If more than the SYN bit is set */
    if (fdata->flags != 2)
        return 0;

    /* many SYN bit only packets per flow are suspect */
    if (fdata->dPkts < 6)
        return 0;

    /* 40 byte datagrams are the output of the current tool */
    if (fdata->dOctets != (fdata->dPkts * 40))
        return 0; 

I've only had time to briefly glance at the Phrack code
so the above may not be entirely correct, but it's
the right idea.  About 8 million flows through the above filter
produced only 32 suspect flows.

Sif SrcIPaddress     DIf DstIPaddress    Pr SrcP DstP Pkts       Octets
 StartTime          EndTime             Active   B/Pk Ts Fl R1 CS MC

20  XXX.XX.XX.X      20  XXX.XX.X.X      06 973  1a0b 28         1120      
 0917.07:01:44.266  0917.07:01:44.514      0.248 40  a5 02 00 00 00

Ie 28 TCP segments with only the SYN bit sent sent in .248
seconds to port 6667.  hmm, someone flooding an IRC server imagine
that.

There's another clue left by the current tool -- the src IP
may be entirely bogus:

(from a router in front of our dialup pool)
Sep 16 18:19:02 tc2-atm0s4.net.ohio-state.edu 10708: Sep 16 22:19:00: %SEC-6-IPACCESSLOGP: list 112 denied tcp 1.1.1.1(10243) -> 199.232.245
.4(23), 1 packet
Sep 16 18:19:02 tc2-atm0s4.net.ohio-state.edu 10709: Sep 16 22:19:00: %SEC-6-IPACCESSLOGP: list 112 denied tcp 1.1.1.1(10499) -> 199.232.245
.4(23), 1 packet
Sep 16 18:19:02 tc2-atm0s4.net.ohio-state.edu 10710: Sep 16 22:19:00: %SEC-6-IPACCESSLOGP: list 112 denied tcp 1.1.1.1(10755) -> 199.232.245
.4(23), 1 packet
Sep 16 18:19:02 tc2-atm0s4.net.ohio-state.edu 10711: Sep 16 22:19:00: %SEC-6-IPACCESSLOGP: list 112 denied tcp 1.1.1.1(11011) -> 199.232.245
.4(23), 1 packet
Sep 16 18:19:02 tc2-atm0s4.net.ohio-state.edu 10712: Sep 16 22:19:00: %SEC-6-IPACCESSLOGP: list 112 denied tcp 1.1.1.1(11267) -> 199.232.245
.4(23), 1 packet

oh well..I've probably just given too many clues away to writing a really good
source address spoofing SYN flooding tool.

--
mark