Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

IPS-4240 Connections

I've been given a handful of 4240s and ssm-10's to install and configure but know nothing about them. I connected up a 4240 and managed to do basic things like upgrade it with the latest pkg and get it to do signature auto-updates. I also associated it with a blocking device, an ASA 5520, but I can't tell if it can talk to it or if it has tried to, although I have configured a login profile for it. Is there a way to tell if it works or do you have to wait until it tries to configure something on the ASA?

I decided to go with promiscuous mode as inline is too risky for my scenario. I set up a switch span port and sent the ASA's outside interface traffic to a sensing interface on the 4240, and it seems to see it and analyze it ok as far as I can tell by looking at the events. Is that a good way to set it up? I haven't seen any documents that discuss it in detail. Someone had mentioned that I might want to have it monitor the inside but I wasn't sure about that. Wouldn't I want to monitor attempted nasty activity on the outside so the IPS device can respond to it? Or is it better to just analyze traffic that makes it through the ASA?  As it stands now I can see things like MSSQL stack overflow packets on the outside interface on occasion, which is interesting, but maybe it's a waste of time monitoring it if it isn't getting through. Please advise.

Also, If I want to implement TCP resets do I need to designate another interface to do it or can it be done by the existing sensing interface?

Thanks in advance.

Cisco Employee

Re: IPS-4240 Connections

You can check the communication status with configured blocking devices from the CLI by issuing:

show statistics network-access

As for your deployment scenario, there are two schools of thought on this:

- monitor the inside interface as you should only be concerned with exploit traffic that has traversed your perimeter defenses (ASA, etc), why spend time processing events that were already defended by the ASA?

- monitor both the inside and outside interface so you can validate the full functionality of your perimeter defenses as well as detect/protect against any traffic that does enter your network.

You should be able to successful utilize the sensing interface as the TCP reset interface; but this will be limited by the span configuration on the connected switch.


CreatePlease to create content