cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1460
Views
15
Helpful
12
Replies

AIP-SSM

Leo_Stobbe
Level 1
Level 1

Hello,

Scenario

2 networks

outside network ANY

inside network 192.168.1.0

How can i simulate the work of AIP-SSM to be at behind of firewall?

My version.

access-list test extended permit ip any 192.168.1.0 255.255.255.0

class-map test

match access-group name test

policy-map test

class test

ips inline fail-open

Waits for any comments

Thanks

Leo

1 Accepted Solution

Accepted Solutions

My expertise is in the IPS and not the firewall. My knowledge of the firewall is fairly limited to what it takes to get packets to the SSM.

SO I am not sure what ACls are applied before decryption or after decryption.

If you want to know at what stage the ACLs are applied you would need to post a message on the firewall forum.

I was just trying to show that all firewall features (whatever they may be) would be done on the packet before sending to the SSM with the exception of encryption and final transmission.

View solution in original post

12 Replies 12

abinjola
Cisco Employee
Cisco Employee

do you mean you want to initiate a traffic from outside and access resource on inside, verifing how IPS works on that traffic ?

If yes , then you firstly need either a 1-1 static or nat 0 (inside) access-l abc for traffic to have inbound translation,

access-l abc permit ip any any

nat (inside) 0 access-l abc

then type sh service-policy which would tell you packet inspected by IPS

No. I don't. Forget about Nat acl. (It has already been done)

As we know IPS Appliance can be installed before or after firewall.In case of Cisco IPS 42xx series we can install it physically before or after firewall.

My question was how can it be done by ASA\AIP-SSM?

I want incoming traffic from outside to hit the ASA(ACL) first and then go to AIP-SSM.

these are following options to configure the IPS-SSM

ips [inline | promiscuous] [fail-close|fail-open]

can be any of the following

ips inline fail-close

ips inline fail-open

ips promiscuous fail-close

ips promiscuous fail-open

the SSM interfaces there are 2. One is the internal interface on the ASA backplane

used Only for

monitoring (both promiscuous and inline).

The second interface is the external interface of the SSM itself that is used for

management of the SSM. This external interface is what will

be assigned an IP as part of the setup command on the SSM. It should be physically

connected to one of the networks. It can plugged into the

same switch/hub where the ASA's inside, dmz, or management interface is connected. It can

then be treated as just another machine on that

network.

I have listed the steps below for the initial installation along with the

links that provide additional details.

Here is the config guide for the SSM in case you need it:

;http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids11/cliguid<

e/clissm.htm>

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids11/cliguide

/clissm.htm

for sample configuration adding IPS in promiscuous mode :-

access-list IPS permit ip aaa.bb.154.150 255.255.255.248 any

class-map ips-inspection

match access-list IPS

exit

policy-map global_policy

class ips-inspection

ips promiscuous fail-open

policy-map global_policy

class ips-inspection

let me know if you have any further Queries !

marcabal
Cisco Employee
Cisco Employee

The key piece you are missing is assigning the policy map either globally across the firewall or specifically to one of the firewall interfaces.

service-policy test global

or

service-policy test interface inside

(or replace "inside" with the name of whichever firewall interface you want)

To best "simulate" putting the SSM between your internal network and the ASA would be to change your access list to a simple "permit ip any any".

And then assign the test policy to your inside interface.

You change it to "permit ip any any" to make it simple and monitor all traffic in and out of your inside interface regardles of what IP networks are in your internal network.

By assigning the policy to your inside interface it never checks packets between your outside interface and dmz interface. Only traffic going in and out of the inside interface would be checked.

I say "simulate" because there are difference between doing the above with the SSM, and actually placing an Appliance between the internal network and the ASA.

The big difference is that the Appliance will monitor packets coming from the Internal network EVEN IF they are denied by the ASA (because of ACLs or other policies).

However the SSM will only monitor packets that are "permitted" through the ASA.

This is because all ACLs and other ASA policies (except encryption) are done prior to sending the packet to the SSM.

The ASA applies the ACL from the internal interface AS WELL AS the ACL from the outgoing interface (likely outside) and any other policies applied either on the internal interface, globally, or outgoing interface, and also NAT/PAT changes. Only after doing all this will the packet then be sent to the SSM. (If the ASA is doing encryption, then DEcryption is also done before sending to the SSM) So if an ACL denies the packet, then the packet gets dropped by the ASA and never gets sent to the SSM.

Once the packet goes to the SSM, gets analyzed, and comes back to the ASA, then the only remaining ASA features done on the packet are just encryption if needed, and transmitting out of the outgoing inteface.

So Appliances can monitor packets that do get denied by the ASA, but the SSM will not monitor these packets since the ASA will drop them and not forward to the SSM.

Hopefully this is what you were looking for.

Hi,

Thanks for your reply.

From your post i understood.

Let's imagine ASA has 2 interfaces.

Inside and Outside

class-map test

match any

policy-map test

class test

ips inline fail-open

service-policy interface xxxxx

Packets would be analyzed in both direction(in and out) whatever interface i used by service-policy command. Because of there is no in or out argument.

Scenario1

Service policy applied to outside interface.

The incoming packets would go first:

1.SSM

2.Decryption (If required)

3.Inbound ACL

4.NAT

The leaving packet would go:

(NAT and Encryption already done)

1.Outbound ACL

2.SSM

Scenario2

Service policy applied to inside interface.

The incoming packet would go:

1.Inbound ACL

2.NAT

3.SSM

4.Encryption

The leaving packets

(Decryption and Nat already done)

1.Outbound ACL

2.SSM

Correct me,please, if something is wrong

thanks

Leo

SSM class map is applied to service-policy that needs to be tied globally

As a policy applied on outside would never check packet from inside to DMZ or vice versa, therefore SSM would not be inspecting that packet

The SSM analysis feature is always done last with the exception of encryption.

Encryption and final transmit out of the firewall are the only firewall features done After SSM Analysis.

So InBound ACLs and Outbound ACLs as well as NAT and Decryption will all be done Before sending the packet to the SSM regardless of which interface has the policy applied.

Where the policy is applied does not determine the order in which the firewall features are executed, instead only determines which traffic those features will be done on.

For example,

Lets say you have a connection from an inside machine to a web server on the internet (no encryption being done).

If you apply the policy to the inside, the SSM analysis will be done as the last thing before the packets are transmitted. The to web server packets will be checked against ACLs and NAT'd before being sent to the SSM. Similarly the to inside client packets will be checked against ACLs and NAT's back to internal addresses before being sent to the SSM.

SO in both directions the SSM analysis is the last feature being done.

NOTE: Because NAT changes are done before SSM analysis the SSM sees some packets with NAT addresses and other packets with Local addresses. To help the SSM properly track the packets the ASA adds an additional header to the packet that lets the SSM know the Local addresses for the packets.

So the SSM always looks in the additional header of the packet to know the Local addresses and uses those Local addresses when doing analysis and alarming.

If you were to instead put the policy on the outside interface, there would be no change in the order of the features. The SSM analysis would still be the last thing done on the packets.

As another scenario lets say you have a VPN tunnel setup on the firewall.

An inside client is talking to a server through the VPN tunnel that goes through the outside interface.

If you apply the policy to the inside interface.

Then packets to the server will be checked against ACLs (NAT'd if necessary), then sent to the SSM for analysis. When it comes back from the SSM then it is encrypted and sent through the tunnel.

The encryption happens after analysis.

The packets from the server will be checked against ACLS, AND decrypted Before being sent to the SSM.

SO you see that Encryption is the only thing happening After SSM analysis.

If you applied the policy to the Outside interface there is NOT any change to the order of the features.

Packets to the server (ino the VPN tunnel) still get analyzed Before encryption, and packets from the server (from the VPN tunnel) still get decrypted Before analysis by the SSM.

So applying the policy to different interface does NOT change the order in which the features get applied to the packet.

A packet goes through the same steps regardless of whether the policy is on the inside or outside interface.

The difference is just in which packets get analyzed.

If you place it on the inside. The packets between inside and outside will be monitored AS WELL AS packets between inside and DMZ, BUT the packets between outside and DMZ will not be monitored.

If you place it on the outside. The packets between the inside and outside will still be monitored. But now packets between outside and DMZ get monitored, and packets between inside and DMZ do NOT get monitored.

Hi Marcabal,

Thanks for your detailed answer.

Your post is very helpful for understanding some key concepts.

The one thing from your post confused me a little bit is:

VPN scenario:

"The packets from the server will be checked against ACLS, AND decrypted Before being sent to the SSM"

So it means that in classic VPN scenario encrypted packet are checked

against Inbound ACL and then decrypted?

My expertise is in the IPS and not the firewall. My knowledge of the firewall is fairly limited to what it takes to get packets to the SSM.

SO I am not sure what ACls are applied before decryption or after decryption.

If you want to know at what stage the ACLs are applied you would need to post a message on the firewall forum.

I was just trying to show that all firewall features (whatever they may be) would be done on the packet before sending to the SSM with the exception of encryption and final transmission.

mlenco
Level 1
Level 1

Can you match an access group? I thought you could use match any, match IP or match access-list.

I could be wrong.

Matt

You are correct.

There were some typos and they should have been "match access-list test" instead of "match access-group name test".

Review Cisco Networking for a $25 gift card