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

Answered Question

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")


Correct Answer by marcabal about 7 years 7 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
rhermes Tue, 09/15/2009 - 07:56
User Badges:
  • Gold, 750 points or more

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.


Correct Answer
marcabal Tue, 09/15/2009 - 10:34
User Badges:
  • Cisco Employee,

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.

Thanks VERY much for the more detailed explanation. I guess I will need to re-engineer my access through the Firewall to accommodate these changing IP addresses for NAT transversal on our Firewall. I believe I can do this and still "keep it secure". At least this is only in test mode right now, so not a critical issue.

My frustration level just diminished by an order of magnitude! THANKS again...

Actions

This Discussion