For this post and the previous one you posted:
- if alert is outbound, you should confirm that;
- Sensor port configuration (inside/outside) is correct
-If is is really outbound, it means that one of your internal IPs is generating the traffic
This would indicate some sort of reconnaissance activity taking place.
I would investigate the internal IP address and try to find out if there is a legitimate reason for this IP to be scanning port 80 on the 'outside' IPs.
Thanks for replying.
-Sensor port configured correctly
-I know the internal IP generating the packet
With that said, is there a way I could inspect the related packets?
When in the alert details, if I click Actions -> Analyze Packets, the only option is "All packets in this flow and all related flows". When I select that, and click "Analyze Packets" I get nothing.
I'm just trying to figure out what I can do on my side before trying to investigate an end-user's workstation. I have quite a few hosts that generate these every day.
This is a reconnaissance attack and unfortunately you cannot enble forensic logging for it.
In any case you would see severail ACK packets from your internal IP to the external hosts. This is to discover if port 80 is up or not.
I don't think it is normal to see several hosts generating these alerts, I would be investigating the hosts for any suspicious activity/processes/programs.
How about with the "TCP: Full-Connect Host Sweep"?
The same applies. In this case the internal hosts is doing a full 3 way handshake to find out if port 80 is open on the external hosts.
We've seen this in our enviroments that comes from Steelhead Riverbeds devices..
We mark this as false positive and tune it in our policy.
because the way packet shaper may works by modification TCP for performance may resulting lots of ACK which not confirm normal TCP traffic tracking by IPS. in other word the traffic have been modified by these devices for better performance..
I'm not sure what trigger in your enviroments but it's would be good to understand the source and destination for this attack
It's could give you some clue
Whenever you see "TCP: ACK Host Sweep", going out-bound, it will usually turn out to be a false positive in most cases.
A majority of the time it's due to the web surfing habits of employees in your environment, especially if you use multi-tab browsers - which most, if not all, browsers are today.
You can duplicate this alert by one of two ways:
1. Open a browser, conduct an arbitrary search using Google, open all links on page 1, page 2 and page 3 of the search (use the CTRL - Click Link method)
2. Or, you can open twenty different web pages and save them all as your "home" page. Close the browser and re-open so that all twenty tabs/pages attempt to open at the same time.
In both cases, the browser is establishing connectivity to the website and it's sub-domains (such a web page where the content is hosted elsewhere but still displayed on the main page). Each time it establishes a connection, there is a TCP ACK (from the three way handshake, SYN, SYN-ACK, ACK).
The reason that the attack triggers is because the number of ACKs observed from a single host within a given time-frame.
To address the amount of attacks you see:
1. Edit the attack (under Reconnaissance policy), and modify the threshold to either include a higher count of ACKs observed, or
2. Edit the attack and modify the threshold to decrease the time the hold timer will look for contiguos ACKs, or
3. You can simply choose to tune it out and mark it as a false positive when you see the attack heading out-bound.
Message was edited by: robrod - Clarification and spelling. on 6/13/12 2:01:59 PM CDT
That is what I suspected, and it sounds like I'm not the only one experiencing it. I will go ahead and tune accordingly.