cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1138
Views
18
Helpful
17
Replies

IDS Placement

mark.o.hall
Level 1
Level 1

I am trying to determine how to configure the 4215 IDS to work in sandwich mode. 1 port connected up outside the firewall and 1 port connected up inside the firewall, and is this the best method to use and is it secure?

17 Replies 17

harshmat11
Level 1
Level 1

Yes,the method that you want is called as Inline mode and is the feature which makes an IDS different from IPS.Pls let me know the s/w version u r running(IPS functionality or Inline Mode is available s/w version 5.0 n above) Also let me know the Fast ethernet Interfaces u hv in your 4215.

Pls check the URL below for more Info:

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a008055df7d.html

Version 5.1 (4) with a 4FE card installed.

mhellman
Level 7
Level 7

That's not how you would implement the sensor inline, if that's what you mean. I believe that by default the 4215 only has 2 interfaces, one for management (fa0/0) and one for sensing (fa0/1). If you want to do inline mode, you need to purchase the 4FE card.

see: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_installation_guide_chapter09186a0080757a86.html

If you don't have the 4FE card, you can only do monitoring (no inline) and you have a couple of options for how to do that. Here's a basic overview:

http://www.snort.org/docs/iss-placement.pdf

I have a 4FE card installed and attached is a link and if you look at figure 4 this is what I am trying to do? I am trying to stay away from in-line since I heard that in-line slows traffic down. Any ideas? thanks

http://www.ciscopress.com/articles/article.asp?p=25327&seqNum=5&rl=1

The confusion appears to be about what ports get connected where.

The figure 4 you refer to has one monitoring port connected to monitor outside the firewall, and the command and control port connected to a network inside the firewall.

BUT understand that the command and control port is NOT monitoring traffic it is there just so other boxes inside the nework can communicate to the sensor. So your sensor is only monitoring the outside of your firewall between the firewall and your external router. Generally a hub or switch is used between the firewall and external router and that is technically what the sensor monitor port is connected to.

So only 2 ports are used and there is no need at all for the 4FE card because you just use the onboard monitor port and the onboard command and control port.

Now there are some users that use this figure 4 as a starting point and want to take it one step further and place a monitoring port also on the internal side of the firewall and even a monitoring on the DMZ side of the firewall.

They want to be able to see attacks on the outside, the inside, and the DMZ.

This is a great concept but will not work in 5.1(4). BUT 6.0(1) was specifically enhanced to handle this scenario.

So load 6.0(1), and now you can use 2 ports of the 4FE card to do additional monitoring. Place one of the ports to monitor off a switch on the inside network, and another one of the ports to monitor off a switch on the DMZ network.

The trick in 6.0(1) is to NOT assign these 2 additional ports to the default "vs0" virtual sensor.

Instead create 2 new virtual sensors "inside" and "dmz" (the 6.0 version allows you to create up to 3 new virtual sensors). Then you can place the inside monitoring port in the "inside" virtual sensor, and place the dmz monitoring port in the "dmz" virtual sensor.

This doesn't work very well in 5.1 because you can not create new virtual sensors. So you will need 6.0 if this is what you are attempting to accomplish.

Thanks for the update. Just so I get this staright. FE0/0 is for monitor and control only. FE0/1 could be placed outside the firewall, to monitor traffice inbound. I would have to place a switch ouside the firewall and configure spanning port for FE0/1. Then, since I am using 5.1, I can not configure another port (FE1/0-FE1/3) for use on the inside firewall. I would have to upgrade to 6.0 then configure FE1/0 for use on the inside firewall again using spanning port on the switch. How secure would this be, can a hacker get into FE0/1 then find his/her way to FE1/0 and bypass the firewall? Please correct me if I have stated anything wrong. Thanks again..

"FE0/0 is for monitor and control only"

management...not monitoring, but i think you get it. no traffic on this interface will be inspected.

"FE0/1 could be placed outside the firewall, to monitor traffice inbound"

well, it will plug into something that sees all the traffic going to the firewall. this can basically be implemented in one of 3 different ways; taps, hubs, and spans.

"Then, since I am using 5.1, I can not configure another port (FE1/0-FE1/3) for use on the inside firewall"

technically I think you can, but what marcabel was saying is that 5.1 wasn't specifically designed for this [and therfore acts wierdly when you do this] whereas 6.x was. Use 6.x if you can.

"How secure would this be, can a hacker get into FE0/1 then find his/her way to FE1/0 and bypass the firewall".

technically, it's possible an attacker could mount some attack that takes advantage of the fact that untrusted data is slurped up on the monitoring interface and then processed. Snorts had bugs like that and I'm sure Cisco IPS does too. For this reason, some people put the sensor management interfaces in a bubble network.

Pretty much correct.

Some users actually have placed another port (Fe1/0-Fe1/3) on the inside as well while using 5.1 but it doesn't do what they would expect and can have a negative impact on the sensor's ability to monitor. The virtual sensor can get confused when seeing the same packet twice especially if the firewall has modified the packet in between.

So yes I would upgrade to 6.0 if you are wanting to monitor both in front and behind the firewall.

As for how secure. It would be almost impossible for an external hacker to access Fe0/1 to gain entry into the sensor and get in through Fe1/0. The monitoring ports do not have IP Addresses and their MAC addresses are unused so a hacker could not direct packets to the interface, the switch has to copy packets to the monitoring port. And the packets that do come in the interface do not get analyzed by the IP stack and instead are passed straight to our analysis software.

However, I did say "almost" impossible. Because there is always the extremely small possibility of a bug that a hacker might be able to exploit to get this to happen. We have never found such a bug, and have never heard of it happening in the field.

But a switch with a vlan for the external and a vlan for the internal has similar exposure. A few years ago there were some actual attacks that attempted to get the switch to bridge between the 2 vlans and bypass the firewall. Those switch bugs have been fixed for a few years now.

Since they tried it with switches it is possible that it could be tried with an IPS sensor.

There is also another possibility, however. If an internal user could gain access to the sensor through the command and control port.(through a connection direct to the sensor's IP where the user would need to know a username and password to get into the sensor)

Then theoretically that internal user could create a covert channel through the sensor to bypass the firewall. So be carefull who you give username and password access to for your sensor.

So the possibility of being able to bypass the firewall is extremely small but does exist.

But if it really does concern you then there is an alternative that will give you 100% guarantee that it won't happen.

Instead of a span on a switch for the monitoring you could use a TAP.

The TAP will send the packets to the sensor using 2 ports, but will not accept any packets from the sensor. The TAP is built ONLY for transmit of the copied packets to the sensor, and can not receive back any packets from the sensor. The hardware of the TAP itself was built not to allow it.

So you would place a TAP on your outside connection, and a TAP on your inside connection. Then use Fe1/0 and Fe1/1 to monitor the outside, and use Fe1/2 and Fe1/3 to monitor the inside.

Fe1/0 and Fe1/1 would be placed in the same virtual sensor, and Fe1/2 and Fe1/3 would be placed in a second virtual sensor.

So then packets can go into the sensor, but they can't come back out of the sensor on any monitoring port.

Thanks, for the info. I now have other questions since I have upgraded to 6.0. When I log into the IDS from a web browser my cable is connected up to FE0/1 and I enter the IP Address of the IDS and the IDM comes up. I thought only FE0/0 was used for this? In the IDM it shows FE0/1 and FE1/0-3 for the interfaces. In the mode we have been discussing do I connect a cable to both FE0/0 and FE0/1 on the inside of the firewall? How do I know which port to span? And is there anything I have to do to the ports? I have updated the signatures, what now?

Thanks,

Port numbering on the IDS-4215 specifically has caused some issues.

The older sensors that originally shipped with IDS 4.1 have port numbers that are opposite than those used in IPS 5.0.

With IPS 5.0 and 6.0 the command and control is FastEthernet0/0.

Physically it is the Ethernet port on the Right next to the Console port.

See the disgram in step 5:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids13/hwguide/hw4215.htm#wp528468

Unfortunately back in 4.1 that port was physically labeled Ethernet 1, and the 4.1 software referred to it as "int1".

If you have one of these older sensors then use a piece of tape and write over the Ethernet1 label and name 0/0.

Write over the Ethernet0 label and name it 0/1.

The numbering convention changed going from 4.1 to 5.0. In 4.1 that port next to the console wasthe command and control port and called int1 and labeled Ethernet1. Going to 5.0 it is STIll the command and control port, but now it is called FastEthernet0/0, but is still physically labeled Ethernet1.

This was supposed to have changed on newer IDS-4215s shipped since 5.0 was released, but I have heard rumors that there are still some with the wrong labels.

Another way you can check is to Only plug in that one wire and bring up IDM.

Then execute "show int brief" on a 6.0 sensor.

Only FastEthernet0/0 should show as being Link UP, and will also have a "*" under the CC column for Command and Control.

(NOTE: If using 5.x you will have to use "show int" and look for the Link status for ech port.)

Once you have physically confirmed which port is command and control then you can plug into your network like any other PC. Or if you do have a separate secure network for command and control of your security devices then you can plug it into that other network. You will want to give an IP, netmask, and default gateway appropriate to what ever network you connect it to.

The other onboard interface is, therefore, the FastEthernet0/1 monitoring interface.

Plu that into your switch and set that switchport up as the span destination port.

On your sensor run setup and assign FastEthernet0/1 to virtual vs0 for promiscuous monitoring (or use IDM and assign FastEthernet0/1 to vs0, if using IDM you will also need to Enable FastEthernet0/1 - if you use CLU setup comand, thenthe CLI setup will enable it automatically).

OK, this makes sense, wasn't sure if I was going crazy or not with the port labeling. In a previous response you mentioned TAP, what exactly is a TAP? currently we do not have a switch outside our F/W and I really don't want to place one there, that is why I am interested in this TAP.

Thanks

Here is a TAP from NetOptics:

http://www.netoptics.com/products/product_family_details.asp?cid=1&pid=4&Section=products&menuitem=1&tag=NetOptics+Network+Taps

You can read all about TAPs on the NetOptics site.

There are some draw backs you should be aware of when using TAPs. It will take 2 monitoring interfaces of the sensor to monitor the one TAP connection. SO this can reduce the number of networks you could have monitored. (NOTE Both monitoring interfaces need to be put in the same virtual sensor for the sensor to work correctly.)

Another downside is that because the sensor can not send packets back into the network you can not use the Reset TCP Connection event actions on those interfaces.

There is a workaround where you can use an "Alternat TCP Reset" interface, but that requires a 3rd monitoring interface plugged into a switch between the 2 devices. Because you don't have a switch between the firewall and router even the "Alternate TCP Reset" interface is not an option for you.

Other than that many users have been very happy with TAPs. Typically customers choose to use Taps when they have no other way of getting copies of packets to a Promiscuous Sensor, or they don't want the sensor plugged directly in to their live network. (Generally it is a highly sensitive network with strict up time requirements and the fewer things that can cause a network issue the better.)

Finisar also sells taps:

http://www.finisar.com/index.php?file=view_product&var=product&sub_sub_cat=14&lev=D&div_id=smenu4&product_id=294&sub_sub_name=TAPs&last_level=last_level&last_link=Single-port%20TAP&l=last

And there are probably a few other TAP vendors out there as well.

Thanks, I'll stick with a switch. My only question is and I think I have tried this and it didn't work is this:

Can a port on a Cisco switch be spanned to multiple ports? I am currently spanning the inside firewall port to our webfiltering software server, I would also need that same port spanned to the IDS. Can this be done? Can it be done across multiple switches?

It completely depends on the switch.

Some switches allow multiple destinations for the same span session. While other switches do not.

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:

Review Cisco Networking products for a $25 gift card