Strange sig 3030 from our Netscreen untrusted interface

gpoer · ‎11-09-2001

Our Cisco Secure IDS (that lives outside the firewall) is picking up some strange traffic off one of our Netscreen Firewalls. The Src addresses are the un-trusted interface addresses assigned to the Netscreen. Has any one seen something like this before? Is it a bug or am I seeing something interesting?

Date Sensor Signature Sub Sig Description Severity Src Address Src Port Dst Address Dst Port

2001-10-26 08:51:24 3 3030 0 TCP SYN Host Sweep 2 my.net.com 2028 0.0.0.0 0

2001-10-26 08:55:24 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1610 0.0.0.0 0

2001-10-26 09:17:24 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1100 0.0.0.0 0

2001-10-26 09:21:20 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1058 0.0.0.0 0

2001-10-26 09:23:21 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1707 0.0.0.0 0

2001-10-26 09:25:23 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1133 0.0.0.0 0

2001-10-26 09:27:21 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1959 0.0.0.0 0

2001-10-26 10:33:21 3 3030 0 TCP SYN Host Sweep 2 my.net.com 1448 0.0.0.0 0

--------Cut--------

(other address assigned to interface)

2001-11-02 09:24:24 3 3030 0 TCP SYN Host Sweep 2 my2.net.com 1886 0.0.0.0 0

2001-11-02 09:54:20 3 3030 0 TCP SYN Host Sweep 2 my2.net.com 1197 0.0.0.0 0

2001-11-02 10:48:23 3 3030 0 TCP SYN Host Sweep 2 my2.net.com 1779 0.0.0.0 0

2001-11-02 11:29:24 3 3030 0 TCP SYN Host Sweep 2 my2.net.com 1152 0.0.0.0 0

2001-11-02 11:49:20 3 3030 0 TCP SYN Host Sweep 2 my2.net.com 1286 0.0.0.0 0

What ever it is it is not terribly fast. The dates are inconsistent in this email but they are actually occurring everyday with similar frequency.

marcabal · ‎11-09-2001

Is your FireWall running NAT?

If so then multiple clients are connecting to different web servers (or ftp servers).

This simulates a single ip address sending SYN packets to multiple detination addresses which is considered a TCP SYN Host Sweep.

I would reccomend Excluding your NAT addresses as the source of this alarm.

If you have done that, and the alarm is still firing then you are seeing a known bug in IDS.

The alarm has gone into Summary Mode, and that is likely why the destination addresses are 0.0.0.0 in your alarms. Look in the alarm detail field to see if it says Summary.

The exclude code has a problem when the alarm goes into summary mode because it is unable to match properly on the 0.0.0.0 address we use in Summary mode.

You can either use SigWizMenu and change this signature to use FireOnce mode rather than FireAll or Summary, or you can add an extra Exclude line with the NAT addresses as the Src and the word OUT as the destination.

Refer to DDTS Issue:CSCdv61032