On Wed, 18 Sep 1996, Vern Paxson wrote:

...

...

have something in their logs like SYN/ACK RATIO 33:1 POSSIBLE HACKER ATTACK which will make them sit up and take notice.

I don't see how in reality to make the syn/syn-ack/ack ratio work soundly. It seems too easy for the cracker to synthesize bogus syn-ack's or ack's to manipulate the ratio however they please.

Wouldn't the ratio be calculated from outgoing SYN's and incoming ACK's? I can see that a sophisticated attacker could have a machine on another network sending incoming ACK's to balance the outgoing SYN's but I suspect this would be an extremely small percentage of attacks.

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. Larry Plato

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