This is a known issue.
The Engine is tracking packets destined to those ports with the assumption being that they are the server ports. The Engines therefore analyze all of the traffic going to those ports looking for the associated patterns for the signatures.
What you've found is that in your case these ports are being used as client ports. And the data being sent to them is the response from your web server. (or another service) In the responses from your web server the sensor is detecting the patterns and firing alarms for the signatures.
This happens because the engines look at packets without regard to whether or not the destination port is the server port or the client port. This is a bug in our Engines and is currently being worked on for correction in a future release.
Until then what you will need to do is Exclude your Web Server (or other service) as the SOURCE of these alarms. The response traffic from your web server will then no longer trigger the alarm. This will eliminate the majority of the false positives you are seeing.
NOTE: This only prevents the alarm from firing if the sensor thinks the web server is the atacking box, the alarm will still fire for attacks directed at your web server and other boxes from other machines.
Future alarms would have to be evaluated. If the destination port is the server port then the alarm is likely true, but if then destination port in the alarm is actually the client port then more than likely it is another false positive.
The NSDB will be updated to document these false positives as we work on getting them fixed in a future release.
