Tip

How to determine network interface cards for IDS sensors

After deciding on an operating system (OS) to use for your Snort IDS sensors, you will need to configure networking. Ideally, you should have a minimum of two network

    Requires Free Membership to View

    Login

interface cards (NICs). One of these is used for sniffing and should be un-numbered -- that is, not have an IP address assigned to it. The other should have an IP address as usual and be used only for management. Also, you may have as many additional network interfaces as you like -- numbered or un-numbered -- provided the hardware and operating system can support them.

The management interface should be on a trusted network, usually your LAN, or a dedicated management VLAN or segment. You can configure it as you normally would for your OS and environment.

More Information
Learn more about intrusion detection and prevention with this learning guide.
For un-numbered interfaces, having no IP address on the un-trusted or monitored segments adds a layer of security. Since there is no IP address to target, those segments are much harder to attack, but not foolproof. By definition, Snort sees the traffic. Therefore a vulnerability in Snort or the network packet capture library may still be exploited, and this has happened in the past. Remember, your sensor is a security device and should be configured, hardened and maintained with that in mind.

Windows, Unix and Linux all support un-numbered interfaces. For example, to bring up eth1 as an un-numbered interface on a Red Hat or derivative Linux distribution, use your favorite text editor to create or edit /etc/sysconfig/network-scripts/ifcfg-eth1 so it looks like this:

DEVICE=eth1
ONBOOT=yes

Running an un-numbered interface under Windows is also easy, but counter intuitive. For example, under Windows 2000 simply right click on "My Network Places" and choose Properties. Right click the appropriate connection, e.g. "Local Area Connection 2" and choose Properties again. Verify that you are working with the correct physical interface by checking the name and/or properties (i.e. MAC address) of the network interface card, then uncheck all components, especially "Client for Microsoft Networks" and "Internet Protocol {TCP/IP}." You would think this action disables the card, but it doesn't. It will not show up under ipconfig /all, but it will if you use the snort –W command. Run snort –W and note the number of the interface you will use for sniffing (e.g. 2), then test that Snort is working by a command like snort –vi 2. If Snort suddenly stops working in the future, check snort –W again as Windows sometimes changes the interface numbers when you make changes to networking.

In any case, make sure you cable appropriately after configuring your un-numbered network interface. You don't want to plug the management interface into the un-trusted segment or vice versa.


SNORT INTRUSION DETECTION AND PREVENTION TECHNICAL GUIDE

  Introduction
  Why Snort makes IDS worth the time and effort
  How to identify and monitor network ports after intrusion detection
  How to handle network design with switches and segments
  Where to place IDS network sensors
  Finding an OS for Snort IDS sensors.
  How to determine network interface cards for IDS sensors
  Modifying and writing custom Snort IDS rules
  How to configure Snort variables
  Where to find Snort IDS rules
  How to automatically update Snort rules
  How to decipher the Oinkcode for Snort's VRT rules
  Using IDS rules to test Snort

ABOUT THE AUTHOR:
JP Vossen, CISSP, is a Senior Security Engineer for Counterpane Internet Security. He is involved with various open source projects including Snort, and has previously worked as an information security consultant and systems engineer.

This was first published in May 2005

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top