Hello, I am working on putting together a training for my team on recognizing a SYN flood attack. There are many ways to recognize one, for sure. The high volume of SYNs, sessions in SYN_SENT, etc. What I would like to do, however, is provide three filters for use with the I/O graphs to show, without question, that the SYN,ACK is not being honored. I have this, so far .. Filter 1: tcp.flags.syn == 1 && tcp.flags.ack == 0 Filter 2: tcp.flags.syn == 1 && tcp.flags.ack == 1 Filter 3: tcp.seq == 1 && tcp.ack == 1 && tcp.len == 0 && !(tcp.flags.push == 1) I am pretty sure I am missing something here. asked 18 Oct '13, 09:29  Qwert |
2 Answers:
I think this should get you what you want... SYN packet from Clients: tcp[13]==02 SYN_ACK packets from Server: tcp[13]==12 ACK 3-way handshake: tcp.seq==1 && tcp.ack==1 && tcp.len==0 && tcp.window_size_scalefactor ge 0 answered 18 Oct '13, 10:08  mrEEde That did the trick. Thank you for the answer. (18 Oct '13, 10:32) Qwert Improvement on the third (assuming you're looking for a filter that shows all final acks that are part of the handshake), with the additional warning that both will fail when sequence numbers are not set to relative:
Advantage is that with the filter of @mrEEde you'd miss sessions that do not use window scaling, but have a full handshake. By the way, I think I'm probably too tired by now, but why did you accept the answer if you're looking for a filter to find SYN/ACKs that are not answered by a final ACK to complete the handshake? With the filter you accepted you'll find all ACKs that are completing the handshake. I have to admit that, as far as I can tell, there is no way to find SYN - SYN/ACK sequences that have now final ACK with Wireshark. So maybe your way is to find all connections that have a full handshake, and substract the number from the count of all SYN/ACKs you see? Anyway, all real SYN floods I have seen so far are pretty obvious (to put it mildly) - I'd have to be completely blind not to see the attack in 5 seconds flat, and without any filter :-) (18 Oct '13, 11:04) Jasper ♦♦ Hi Jasper, Thanks for your response. I'm still very much a packet-analysis novice, so I appreciate the comment on window scaling. It didn't occur to me that some sessions would not use it until after you mentioned it. My thought is that by using a filter that will reliably capture the third packet in the 3-way, the absence of matches will provide categorical proof that the SYN.ACK is not being answered (given that there should be thousands(+) SYNs). And yes .. I absolutely agree that there are plenty of indicators when a real SYN flood is occurring, and really .. these are not a problem in most large scale networks with a robust IPS implementation. This is for a training doc to give the TCP-novice a clear way to determine whether a SYN flood is occurring (thus .. hopefully .. mitigating the need to reach out to an oncall at OMGam). Thanks, Kevin (18 Oct '13, 14:59) Qwert Okay, as long as you got an answer that helps I'm fine with it ;-) Just a final comment: I agree, even robust IPS implementations do not always help. I've been involved in cases where the SYN flood was so big that it took down two upstream providers that provided the data connections to the customer. 70Gbit/s is just too much... :-) (18 Oct '13, 15:17) Jasper ♦♦ |
Try this (must use relative SEQ #s): (tcp.seq == 1 && tcp.ack == 1&&tcp.len==0 && !tcp.flags.fin == 1)||tcp.flags.syn==1 answered 09 Sep '14, 11:09  akaplan |
Looks like the formatting got lost
Filter 1: tcp.flags.syn == 1 && tcp.flags.ack == 0
Filter 2: tcp.flags.syn == 1 && tcp.flags.ack == 1
Filter 3: tcp.seq == 1 && tcp.ack == 1 && tcp.len == 0 && !(tcp.flags.push == 1)