Methodolgy to ID source of DOS attack

Do the embryonic connections show up in netstat -a output? Or do they have forged source IP addresses? I'm curious to see what options there are for tracing SYN floods.

 

 

Aaron

After the lack of response to this, I am questioning whether people think I'm just dumb and shouldn't be asking something so obvious, or if this is something most people don't see or bother to look into.

 

 

I'm fairly certain that the source of these packets was internal, related to application testing, and that spoofing is unlikely. I didn't think to run netstat -a at the time, though that is an excellent suggestion. It is interesting to think about whether these connections will show up or not.

 

 

At the time I was doing a tcpdump looking for RST packets, but upon reflection that was a stupid idea since the LTM is dropping the SYN packets instead of sending RSTs, so I wouldn't have captured the RSTs. What I should have done (duh)is filter on SYN packets - maybe capture say, 1000 packets. If the LTM is dropping 16000 per second, I would expect most of those 1000 captured packets to be from the suspect device.

 

 

I suspect tcpdump is probably the right command to be using. I just assumed there'd be some bigpipe command that could easily ID the source, but I must be wrong about that.

It's not something I've ever been asked about or seen in customer implementations.

 

 

I'm pretty sure netstat -a would show the connections in a state of SYN RECEIVED or something similar. If the source IP was forged, I'm not sure how you'd identify the true source. I'm guessing this wouldn't be simple.

 

 

Anyone else have thoughts on this?

 

 

Aaron

Sol 9259 (Click here) seems to indicate that this message results from the sourced packets not being SYN packets or part of the current connection table.

 

 

In this case, there would be no connection chain to track.

Posted By smp on 01/28/2009 7:19 AM

 

 

At the time I was doing a tcpdump looking for RST packets, but upon reflection that was a stupid idea since the LTM is dropping the SYN packets instead of sending RSTs, so I wouldn't have captured the RSTs.

 

 

 

Also don't forget the syncookie mechanism...if you reach a certain threshold of SYN's coming in, LTM will respond with a syncookie to the client and immediately close the connection. If it's a legitimate client, it will respond back and LTM is smart enough to reopen the connection based on the syncookie. But SYN floods are avoided because the LTM has already closed the connection and moved on. So you may see "dropped" SYN's without seeing the "Limiting open port RST response" message as well.

 

 

Denny

 

 

I just started seeing some RST messages one about every 1-2 hours. From this thread it seems that Sol 9259 (as discussed above) seems to indicate that this message results from the sourced packets not being SYN packets or part of the current connection table. Thus it seems that the RST messages are not part of normal traffic.

My questions are a) is it normal to see RST packets when using the LTM product b) can these RST messages be "safely" ignored c) at what frequency, level, or reduction should RST messages like the below be a concern -or- d) is there some rule to add to my virtual server to block a specific type of connection or traffic.

 
    [f5user@www:Active] log  grep RST ltm
    [f5user@www:Active] log  gunzip -c ltm.* | grep RST
    Apr 28 13:56:52 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    Apr 28 17:23:02 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    Apr 28 17:47:22 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    Apr 28 18:24:02 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    Apr 28 19:19:15 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    Apr 28 20:41:25 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    Apr 28 22:52:57 local/tmm warning tmm[1350]: 011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
    [f5user@www:Active] log  grep RST ltm

Obviously dropping from 251 to 250 packet/sec seems like nothing to worry about, but my traffic pattern will go up by a factor of 25 in the next few weeks (since only a part of our client base has been routed to the F5 right now).

Jon

Mmm..... What the BigIP is doing is sending a RST packet because it's recieved a tcp packet for a connection that doesn't exist, and the recieved packet DOES NOT have the SYN flag set... In this respect the F5 is behaving exactly like any other IP host... If an IP stack recieves a packet without the SYN flag set for a connection that doesn't eist in the connection table, the host sends back a RST to tell the sending host that the connection doesn't exist and they need to reset their state.

 

 

The best way to diagnose this would IMO be a two parter... First perform a tcpdump looking for RST packets... Sonce the F5 is rate limiting to 250/sec, there should be plenty to see... Have a look at the destination IP... Then perform a tcpdump filtering just on that IP address... You'll then have all the info on what the host is sending (Valid and invalid packets) and what's being sent back.

 

 

It's always possible that this is simply due to a genuine fault... One reason I can think of is possibly you just had a failover, and these packets are destined for a VS that doesn't have mirroring enabled.

 

 

H