ASA/IPS interfaces
liven
Member Posts: 918
Ok here is another off the wall question...
The ASA's I am working with have 4 built in interfaces.
outside
inside
dmz
failover
is how I have them setup in the ASA.
When I look at the interfaces in the IPS I only see one of the four interfaces: inside
I would like to add the DMZ interface to be watched by the IPS, but I can not add it from the command line or from the GUI...
I know this is a vague question. But if anyone has any suggestions I would appriciate them.
THanks
The ASA's I am working with have 4 built in interfaces.
outside
inside
dmz
failover
is how I have them setup in the ASA.
When I look at the interfaces in the IPS I only see one of the four interfaces: inside
I would like to add the DMZ interface to be watched by the IPS, but I can not add it from the command line or from the GUI...
I know this is a vague question. But if anyone has any suggestions I would appriciate them.
THanks
encrypt the encryption, never mind my brain hurts.
Comments
-
liven Member Posts: 918hmmm
my boss any myself are starting to think that the IP's can only watch one gig interface at a time.
This would make sense...
Just can't seem to find that in writing anywhere...encrypt the encryption, never mind my brain hurts. -
dtlokee Member Posts: 2,378 ■■■■□□□□□□You need to modify the inspection policy (or create your own) and tell it to send the traffic to the IPS module for inspection.
something like:
policy-map outside-policy
class internet-traffic
IPS inline fail-open
or you could add it to the default inspection policyThe only easy day was yesterday! -
liven Member Posts: 918Thanks.
Still have a lot to learn on these things...
I wouldn't call my self an expert on Snort, but I am pretty familiar with it (deployed dozens of sensors)...
I think I am just having a hard time finding documentation. I am sure I am looking in the wrong place, but some times ciscos website is difficult to find things...
Anyway thanks again.encrypt the encryption, never mind my brain hurts. -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□Add to that you need to apply the policy as a service-policy either globally or per interface. Interfaces for the AIP-SSM (bar the management int.) are logical so you only see the Backplane which can be logically connected to/placed inline with any (or all) of the ASA's physical interfaces.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
liven Member Posts: 918Ahriakin wrote:Add to that you need to apply the policy as a service-policy either globally or per interface. Interfaces for the AIP-SSM (bar the management int.) are logical so you only see the Backplane which can be logically connected to/placed inline with any (or all) of the ASA's physical interfaces.
Ok this is starting to make sense.
Like you said I have not created any service policy and all I can see is the "BackPlane interface".
I guess I was just confused as to why I could see Gig 0/1 (back plane) from the IPS and none of the other interfaces. Further I was confused as to why I couldn't configure any of the other interfaces from the IPS (not as far as network settings but promisc, monitoring etc...).
THanks again. I will keep on hammering.encrypt the encryption, never mind my brain hurts. -
pr3d4t0r Member Posts: 173I wouldn't use asa as IPS, if you want an IPS/IDS try to use a dedicated system for that job e.g 3d system by sourcfire, not a all in one device.
-
Ahriakin Member Posts: 1,799 ■■■■■■■■□□I'm curious why not? The AIP-SSM is a full, well I guess we can't keep calling them 42xx sensors, but it runs the same software as standalone Cisco IPS devices (With high end processing). I particularly like the fact that you can use class maps with access-lists to very precisely allocate logical traffic to whatever virtual sensor and inline/promiscuous mode you want. A full implementation of Sourcefire 3D is pretty expensive too, plus it goes way beyond standalone IPS, you'd really want to be comparing it to Cisco hardware sensors married to a MARS.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
pr3d4t0r Member Posts: 173From my experience Sourcefire 3D System is the most complete IPS/IDS solution. The RNA is by far the most valuable tool. Combine that with the best IDS engine in the world -Snort- and you have a system that monitors EVERYTHING.
Cisco has lost the game in IDS/IPS far ago. Few signatures, lots false positives, no tunning capabilities, no custom rules writing etc.
Hey I am a Cisco guy too but when it comes to ids/ips Sourcefire is my choise -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□pr3d4t0r wrote:Cisco has lost the game in IDS/IPS far ago. Few signatures, lots false positives, no tunning capabilities, no custom rules writing etc.
Hey I am a Cisco guy too but when it comes to ids/ips Sourcefire is my choise
No offense when's the last time you used a Cisco IPS? I won't comment on the false positives etc. (I haven't seen many at all, certainly less than the Snort sensor I also run on the server segment) but No tuning or Custom rule writing? It has both in spades, at least in 5.x and now 6.x (sorry I haven't used pre 5.x). Cloning/Editing/tuning existing signatures is extremely intuitive and easy, the custom rule writing is more complex but then so is the same for Snort when you first start out.
I like Snort, I think Sourcefire 3d sounds like an excellent solution and if it was within our budget I would have implemented it this year (primarily for it's integration with Nessus and more accurate target assessment/filtering, though Cisco 6.x does include at least a basic OS filter) but the assertions you've made about the Cisco product are incorrect.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
pr3d4t0r Member Posts: 173Ahriakin wrote:pr3d4t0r wrote:Cisco has lost the game in IDS/IPS far ago. Few signatures, lots false positives, no tunning capabilities, no custom rules writing etc.
Hey I am a Cisco guy too but when it comes to ids/ips Sourcefire is my choise
No offense when's the last time you used a Cisco IPS? I won't comment on the false positives etc. (I haven't seen many at all, certainly less than the Snort sensor I also run on the server segment) but No tuning or Custom rule writing? It has both in spades, at least in 5.x and now 6.x (sorry I haven't used pre 5.x). Cloning/Editing/tuning existing signatures is extremely intuitive and easy, the custom rule writing is more complex but then so is the same for Snort when you first start out.
I like Snort, I think Sourcefire 3d sounds like an excellent solution and if it was within our budget I would have implemented it this year (primarily for it's integration with Nessus and more accurate target assessment/filtering, though Cisco 6.x does include at least a basic OS filter) but the assertions you've made about the Cisco product are incorrect.
I don't remeber in version 4.x to have the ability to write your own rules etc. And when i say "writing custom rules" that includes, not only IDS rules aka Snort rules but RNA rules also.
Version 4 was the first and last time i used cisco ips,when u say Cloning/Editing/tuning that includes writing your own individual IDS rules ? e.g writing a rule for a specifi exploit that is not covered in the cisco signatures. Or lets try something else reverse shell over 80 or 443 can i write such rules in cisco ?
regards. -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□Yup you can clone an existing for a foundation (you can edit them in place but that's not a great idea, better to clone and disable the original) or simply start from scratch to create your own. It's pretty versatile imho. While it works a little differently to Snort there's nothing I've needed to do on one I couldn't do on the other, with a little digging.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
liven Member Posts: 918I guess I just prefer snort right because I am really familiar with it.
But having to deploy cisco with a new project is causing me to learn it as well. I just thought it would be a little more intuative since it is an appliance. Perhaps I am way off the mark with that statement.
I guess snort was not crystal clear in the beginning (for me) so it will just a bit of time.encrypt the encryption, never mind my brain hurts.