Repeated Signature ID 3030 matches on our IPS 4240

Kevin Melton · ‎04-06-2010

I am working at a client site today that has a Cisco IPS 4240 employed near the edge of their network.

Using IME, I have taken a look at some of hte recurring events that the device is reporting. Over and over again, there is a 3030 signature match occuring from various hosts on the Inside networks that are allegedly targeting outside public addresses.

The signature name of 3030 is TCP SYN Host Sweep. When I drill down into the event, it lists its Severity level as "Informational".

What can I do to determine if this activity is problematic and potentially eliminate it? Teh IPS does not report that it is taking any "Action" against these packets.

Thanks

Kevin Melton

Jennifer Halim · ‎04-07-2010

The default action for signature 3030 is alert. So it will only provide you with the event alert that a TCP SYN host sweep has occurred.

TCP SYN host sweep is normally done if you have someone is performing TCP scan to see if there is any open TCP port:

http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=3030&signatureSubId=0&softwareVersion=6.0&releaseVersion=S2

It could mean that someone is probably performing a security audit, OR/ it could be an attacker scanning your network. The event will tell you what is the source ip address, and you could investigate the source host to see if it is legitimate or not.

Kevin Melton · ‎04-07-2010

Thanks for the resonse.

We were able to determine yesterday after a little bit of detective work with Wireshark that the origin of at least some of the SYN sweep signature matches was coming from one of our servers. This specific server is sending alot of SYN packets trying to connect to a port 5022 on IP addresses 1.1.1.2, 1.1.1.3, and 1.1.1.4.

We were not able to find any evidence of any scan running, in that there was not repetative traffic which was searching over a wide range of IP addresses or ports.

Performing a google search seemed to indicate that this behaviour was indicative of SQL server using Database Mirroring. My associate and I went into the SQL Studio Manager yesterday in an attempt to see if we could somehow stop the service or process from running, but were unsuccessful.

Since our IPS unit it outside of our Firewall but behind our Border Router, I thought that the best option in light of the fact that we could not figure out how to stop the originating host from sending out these packets was to filter for these on the Firewall and deny them. I configured this deny statement on our inside interface inbound. Interestingly enough, i noticed on the sniffer a change in traffic being captured with respect to the problem once the Firewall was configured to block these packets. Originally and prior to configuring the Firewall to deny these packets, I had placed the Wireshark into the appropriate VLAN, and then set a capture filter to search for addresses 1.1.1.2, 1.1.1.3, and 1.1.1.4, With this filter set, I was seeing only SYN packets originating from the server. Once I set the firewall to block anything to port 5022 from the source host, I noticed I started getting RST, ACK packets BACK from the 1.1.1.2, 1.1.13, and 1.1.1.4 addresses.

I do not understand this behavior. My best guess at this point is that there is some configuration check box somewhere on the Server that causes this traffic to originate. Since we cannot figure out how to turn it off, at least by blocking the traffic on the firewall, we are stopping what were otherwise alot of unnecessary syslog messages being generated from the IPS to our Log Server.

Kevin

Jennifer Halim · ‎04-08-2010

RSK ACK means that the TCP session closes down for whatever reason. Depending on whether the firewall is stateful or not, if you configure access-list to block tcp/5022, if it's not a stateful firewall, it will also break existing connections, then it will send the RSK ACK to let the peer knows that the connection is no longer there and to RST it.