Solved: SSM-AIP 7.0(1) Global Correlation config nightmare!

rsmith · ‎09-15-2009

Thanks, Cisco, for creating a Management nightmare with your "Global Correlation" option in version 7.0...

Lets start with the SSM-AIP-20 Management interface...

We have an OOB Management network, with a single POI into this through a separate PIX515E appliance. Both the ASA5540 AND the SSM-AIP-20 reside on this network.

The first issue was in Routing, since the ASA sees the Management network as "directly attached", and we ROUTE the traffic through the PIX for updates on the SSM module, we had to add translation entries in the PIX515E for the SSM module (10.x.x.x Management, 172.x.x.x translated).

This was not a big issue, but here is where the nightmare begins...

First a note: We have the Management network locked down TIGHT, only a couple of Network Management stations allowed into that network to access these devices.

I enabled Global Correlation in test mode, but it was "failed" every time it tried to update.. Reading other posts, I created ACL and Static NAT in the PIX515E for these IP's:

204.15.82.17 (IP listed in the IME Global Correlation update server)

97.65.135.170 and .137 (from another post in these forums)

207.15.82.17 (IP found in a trace)

Still no updates. Looking in the PIX logs, I found "no translation" entries for the following addresses:

198.133.219.25

209.107.213.40

208.90.57.73

I put these in, and it started updating! FIXED? NOT!

This morning, it was again failing... Looked in the PIX logs again, and found these:

77.67.85.33

77.67.85.9

Entered them, and the SSM is happy again. How long? Who knows?

So, now I have NINE holes in my "secure" network, and who knows when Cisco will change or add new IP addresses to this list.

Cisco, if you are listening - ALL access to/from the Global correlation through a single IP? PLEASE?

(use the one listed in the IME - 204.15.82.17, for the URL "update-manifests.ironport.com")

marcabal · ‎09-15-2009

A few of the addresses belong to Cisco (originally ironport.com addresses from the ironport aquisition) and are used as manifest servers to provide the sensor a list of files to download.

The sensor then downloads those files from Akamai servers. Akamai has a large number of servers across the world. Cisco sends the update to Akamai and they replicate it across their servers. When sensors try to connect to the Akamai server it does a DNS query and by controlling the DNS response it can direct sensors to an Akamai server located nearer to the sensor. This allows for better load balancing, response times, and download speeds.

However, Akamai has a large number of servers (in the thousands I think) world wide, and you can't predict which server your specific sensor will be directed to.

Sensor connections to the cisco servers for the manifest (file list) is on port 443, and usually to update-manifests.ironport.com URLs.

Sensor connections to the Akamai servers for the actual file downloads are on port 80 and usually to updates.ironport.com URLs.

The above is all based on my limited understanding of how the updates work. I may have gotten a few details wrong, but should at least give you a general idea.

I will be working with development to get this better documented in Release Notes and Readme with the next IPS software release.

View solution in original post

rhermes · ‎09-15-2009

Not that this will make your secure network any more secure, but Cisco said that the global correlation infomation could be passed thru a proxy http/https server on the inside of a secure network.

rsmith · ‎09-15-2009

THANKS CISCO!!! Add another IP Pair!

208.50.79.73

208.50.76.65

(Who "owns" these IP addresses...are they really ALL Cisco?)

marcabal · ‎09-15-2009