cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1542
Views
1
Helpful
7
Replies

Test website for Global Correlation

clausonna
Level 3
Level 3

Hi folks,

I'm testing out IPS 7.0.1 and Global Correlation on one of my smaller remote offices, but want to confirm that it would actually drop malicious traffic before rolling it out to 15+ other sensors.

I've configured the sensor, and have used the "show stat global" and "show stat analysis-engine" to ensure that I'm getting the latest databases.

However, like I said this is a small office, and (thankfully) there's no malicious traffic for the IPS sensor to drop. I'm sort of in a catch-22 here.

I was going to configure a test PC to use the remote office's proxy server (thus flowing its traffic through the IPS sensor) and then try hitting some known malicious domains. That, of course, runs the risk of infection and is hit-or-miss anyways.

Are there are test sites or IP addresses in the Ironport database that I can use to prove that its working (sort of like the EICAR virus test file)

Something like testGC.ironport.com that goes to a single unused IP address somewhere.

If not, can you guys add one? It would certainly speed our deployment process, and would probably be helpful for TAC, too. This could also be used by the ASA botnet filter.

Thanks!!

1 Accepted Solution

Accepted Solutions

Now I understand more of what you are needing.

This is good customer feedback for us.

I entered an enhancement request to add a command for testing sensor connectivity to the servers for Global Correlation. So it can be considered for a future IPS version.

View solution in original post

7 Replies 7

htarra
Level 4
Level 4

The two different test environments used to test IPS are defined in terms of the parameters used to reproduce them on a Spirent Web Avalanche/Reflector pair.

Media-rich environments are characterized by content. Content seen on most popular Websites falls on the media-rich end of the spectrum, as do video content and file transfers. If your environment is driven by access to large amounts of data and converged, immersive experiences, your environment is more media-rich.

Transactional environments are characterized by connections. Many types of e-commerce environments fall on this end of the spectrum, as can instant messaging and voice. If your environment is driven by connection-intensive applications and small transaction sizes, your environment is more transactional.

https://www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/prod_white_paper0900aecd806e7283.html

marcabal
Cisco Employee
Cisco Employee

There is not currently any specific test addresses built into the reputation database for testing Global Correlation with generated test traffic.

Since the release of 7.0 there have been similar requests for help in Demoing the 7.0 features.

I will pass on your request to the team controlling the reputation database along side these other requests for Demo addresses.

Were you aware however, that you can choose to deploy 7.0 in "test" mode for Global Correlation?

conf t

service global-correlation

test-global-correlation on

What I would suggest is that you deploy 7.0 in your test lab with global correlation turned OFF.

Make to sure that you are happy with 7.0 stability with global correlation turned OFF.

Then deploy 7.0 with Global Correlation turned OFF in your deployed sensor.

Leave it long enough to be sure you are OK with the 7.0 stability when Global Correlation is OFF.

Now configure "test-global-correlation on" to set it to "test" mode, and then turn Global Correlation ON. You could do this first in your lab if you wanted to ensure stability.

Once you've tuned it to "test" mode and turned it ON, then watch your sensor for a few days.

Your sensor will download the reputation database and compare the attacker ip addresses of your alerts to those in the reputation database.

It will modify the reputation fields in the alert for those attackers with a negative score.

It will also let you know what the Risk Rating change WOULD HAVE been if it was not in "test" mode, and what WOULD HAVE been denied if it was not in "test" mode.

If you don't see alerts with negative reputation, then it is possible that your sensor won't benefit from this feature.

This can happen in situations where your sensor primarily monitors internal addresses, because the reputation database is only for external Internet IP Addresses.

If instead you DO SEE negative reputation scores being reported in the alerts, and are happy with what Risk Rating changes would have been made, and what traffic woudl have been Denied; THEN you can decide to turn OFF the "test" mode:

conf t

service global-correlation

default test-global-correlation

The "test" mode was specifically put in as an effort to try an address user's concern with deploying this feature into their sensors.

Do you think this "test" mode is sufficient, or do you feel you still need built in test addresses as part of the reputation database?

I think the test mode is great and have begun rolling out 7.0 to different ASA-SSM-10 modules to see how it does. The one thing i see the need for is a way to force an correlation update. We can specify a update for Signatures and new packages, but have not found a way to do this for GC, especially since my firewall and proxy would block the traffic.

Global Correlation updates must be automatic. The sensor must be able to consistently connect to the Sensor Base servers that serve out the auto updates.

The sensor will automatically check for an update every 5 minutes. The update interval is not user configurable.

The Global Correlation information can be updated multiple times throughout the day. It is much more dynamic in nature than signature updates which in general are updated every few days.

If you are testing connectivity after or before making changes to your firewall or sensor configuration, then you might try disabling Global Correlation, and then re-enabling it. Then wait a few minutes. This should trigger another update attempt, and you can check the output of "show statistics global-correlation" to see if the sensor was able to successfully connect.

Sensors who will not be able to consistently connect to the Sensor Base servers for Global Correlation updates because of company policies limiting internet access for the sensors, are generally not going to be good candidates for using Global Correlation. Because of the dynamic nature of the data, the sensors need constitent access to the internet from their command and control interface.

agreed and there is no problem opening access, its just the wait n see if it works that is not productive as I have 90+ IPS modules to open internet access for, so I'm just trying to carve out a good groove for the deployment.

Now I understand more of what you are needing.

This is good customer feedback for us.

I entered an enhancement request to add a command for testing sensor connectivity to the servers for Global Correlation. So it can be considered for a future IPS version.

I would like to see some configuration documentation on what is required on the ASA side of the configuration. Something along the lines of the IP networks the IPS needs to connect to and NAT configuration required.

I have 2 customers with ASAs with AIP modules. 1 has no problems with SenderBase connections, the other has failed 1500 out of 2400 attempts.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: