Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

IDS False Alarm question

Hi,

I was wondering if anyone could shed light on the following:

I am receiving an 'IP teardrop fragment' IDS event when a particular external web server is accessed from within our network.

If the same site is accessed within a few minutes of the initial alarm, a second alarm does not fire. However, the alarm will fire if a reasonable amount of time is left between attempts to access the server (say 20 minutes).

After running a debug on the firewall to capture the packets, I can see that after the client sends the initial TCP syn packet to the the web server, the server responds by sending a ping back to the source/client before it sends the TCP syn/ack response.

First question:

Is this a normal process for a web-server (validating the source address with a ping, for example...)

Next, a second ICMP Echo Reply packet immediately follows the first. However, after using a sniffer program, I can confirm that there was no ICMP Echo request corresponding to this reply. Also, the packet size looks too large for a simple ICMP packet.

The only thing I can find to explain this is a 'Tribe Flood Network DoS attack' whereby the TFN uses ICMP echo replies to send data from the server to the client...

Any ideas or comments on this would be greatly appreciated..!

1 REPLY
Bronze

Re: IDS False Alarm question

A possible explanation for the first echo request is some kind of load balancing gear in front of the web server. The virtual address pings the client to determine which actual web server is geographically closest to the client for performance reasons. I cannot think of a good explanation for the unsolicited large echo reply, but my best guess would be a misconfigured or malfunctioning piece of network gear somewhere in the path. Due to TFN's age, I highly doubt its related to the problem. Can you determine where the echo reply comes from? Inside / outside your network?

77
Views
0
Helpful
1
Replies
CreatePlease login to create content