cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
894
Views
10
Helpful
15
Replies

deny inline with CLI of sensor; Is it possible?

darin.marais
Level 4
Level 4

Is it possible to manually deny (not block)an attacker-inline by using the CLI of a sensor?

If not, is it possible in MARS

15 Replies 15

darin.marais
Level 4
Level 4

In a slide presentation and interview with Lance Warner that was given at the sans institution of What Works in Security Information Management, Lance mentioned that

?MARS allows 1-button blocking as along as we set up SNMP access to switch where blocking can be done?

Could someone on the list point me to the correct place in the user and configuration guide where this configuration is described?

marcabal
Cisco Employee
Cisco Employee

I don't know about MARS.

But as for an InLine sensor, there is not currently a command to add an address to the InLine Deny list.

The sensor only supports manually adding them to the Block list for use in creating ACLS on other devices.

So is it then correct to say that the sensor is unable to block a connection or an attacker via any manual intervention method with actually out using a secondary device. i.e. a router, pix or a switch.

Could you please tell me how to add an IP address to a block list on the sensor?

We are in passive mode, but it appears that you can use the IDM on the sensor (GUI) to do this, specifically the monitoring "tab".

Sorry for the delayed response.

Correct. You can NOT tell the sensor to inline "deny" an address.

You can only tell a sensor to "block" an address on a secondary device.

There is a configuration option in the CLI to add "block-hosts":

conf t

service network-access

general

block-hosts

BUT I generally do not recommend using this method. It adds the ip address to be blocked as a permament part of the sensor configuration. And can not be managed like other blocked hosts. It can not be "deleted" from within IDM.

INSTEAD I recommend going through IDM and using the Monitoring -> Active Host Blocks section. There is an Add button to add new Blocked Hosts. The Add here will add the blocked host with a "timeout". The Block is then treated like the automatic blocks coming from sensorApp and can be automatically removed when the "timeout" is up, or manually removed by hitting the "Delete" button.

mhellman
Level 7
Level 7

Here's an old document from when Cisco first purchased Protego. I can't seem to find much updated ducumentation on how mitigation works in CSMARS. It appears to only support disabling switch ports?

The MARS box can also suggest ACLs to add to a Layer 3 device.... It cannot do any inline mitigation, though.

I know that the MARS is unable to deny inline that is not what i was asking.

The question is can the MARS tell the sensor that is install inline to deny a host or a network?

Fernando_Meza
Level 7
Level 7

Hi .. yes it can be done by modifying the actions on an individual signature : Basically from command line you need to move to signature sig0 mode and from there enter the signature submode you want to configure.

"Use the event-action command in the signature definition submode to configure the actions the sensor

takes when the signature fires.

The following options apply:

? deny-attacker-inline ?(Inline mode only) does not transmit this packet and future packets from

the attacker address for a specified period of time."

An example is below

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Enter signature definition mode:

sensor# configure terminal

sensor(config)# service signature-definition sig0

sensor(config-sig)#

Step 3 Choose the signature you want to configure:

sensor(config-sig)# signatures 1200 0

Step 4 Enter the normalizer engine:

sensor(config-sig-sig)# engine normalizer

Step 5 Configure the event action:

sensor(config-sig-sig-nor)# event-action produce-alert|request-snmp-tr

I hope it helps .. please rate it if it does !!!

It does not really help.

Originally we were looking for a solution that would allow console assess on the security monitor for our help desk. The solution would allow analysts to first detect fast scanning devices that impact performance and then be able to react with the ?push of a button? to deny devices targeting critical servers on our network with the inline sensor.

The solution that is provided above modifies the signature for all on the network. In our environment that is risky as you stand the chance of blocking something legitimate. We would like to have the opportunity to identify the device on the network before taking the action to deny it and then with the aid of a GUI, be able to take action.

There is not currently the "button" approach.

But I have passed the request on to our Marketing managers so they can consider it in the future.

In the mean time here is an alternative you might try. I have not tested this myself, but I believe it will work:

Enter the signature configuration mode in the CLI:

"service signature-definition sig0"

Now create a variable containing the list of addresses that you want denied:

"variables DENYIP ip-addr-range 1.1.1.1,10.2.2.2,30.3.3.3"

Now create a simple signature that matches any packets with a source IP address in that variable, and set the event action to deny-attacker-inline:

==============================

signatures 61000 0

alert-severity high

sig-description

sig-name My Manual Deny Attacker Signature

sig-string-info Used to manually deny an address

exit

engine atomic-ip

event-action deny-attacker-inline

specify-ip-addr-options yes

ip-addr-options ip-addr

specify-src-ip-addr yes

src-ip-addr $DENYIP

exit

exit

exit

exit

alert-frequency

summary-mode fire-once

exit

exit

exit

=========================================

When applied that new sig 61000 should deny all of the IPs in your DENYIP variable.

To deny a new IP all you have to do is add it to the variable, and apply the change.

The signature will automatically start denying the new address.

If you like the GUI approach you can use IDM to modify the "DENYIP" variable.

So what happens when I no longer want that IP Denied?

Using IDM you first remove it from the "DENYIP" variable, and apply the config change (this will prevent the signature from adding new deny requests for that IP)

Then go to the Monitoring Tab and select the "Clear List" button.

BUT BE CAREFULL. The "Clear List" will clear out the list of ALL Denied Attackers. Any Denied Attacker that was done because of a signature trigger will be removed, and will only be re-added if the attacker triggers the signature again.

HOWEVER, any IP in your DENYIP variable will be added automatically back in to the Deny List just as soon as the first packet is seen from that IP.

Now I have not tried this myself, but I am 98% sure it will function correctly.

And this may or may not work for what you are attempting to do.

Many thanks Marco,

I am overwhelmed that you have contacted your marketing with the request and that Cisco will perhaps try to make this a feature of the IPS solution. If you receive any feedback from them regarding the request, then please do let me know.

The answer that you have provided is not the easiest to implement for a help desk as it means that they will need to have access to IDSMC in VMS to add and subtract IPs which is what we don?t really want to do however the solution will satisfy our needs in the interim.

Once again a big thank you for your reply.

Darin -

We have a proprietary Event Viewer we have written (for our managed security service) to take events off of the sensor. One of the many things we can do is right-click a source IP and block it. This system utilizes SDEE. If you are interested, I can see about a demo of the product.

Thanks.

Along those same lines, just about anything you can do via the IDM can be reproduced in another environment. There are some SDEE documents that Cisco publishes that might help, but I've found it easier to just capture the HTTP between the client and the sensor [while making a particular change]. Below is what adding an "active host block" via the GUI looks like from an HTTP POST perspective.

POST https://:443/cgi-bin/transaction-server?command=addShunEntry HTTP/1.1

Accept: text/xml

Content-type: xml/txt

Accept-Charset: iso-8859-1,*,utf-8

User-Agent: CIDS Client/4.0

Host: 88-nsmc-c1

Pragma: no-cache

Cookie: userToken=doobeedoobeedoo

Cache-Control: no-cache

Connection: keep-alive

Content-length: 312

http://www.cisco.com/cids/idconf" xmlns:id="http://www.cisco.com/cids/idiom" >12.12.12.1260user

Review Cisco Networking products for a $25 gift card