Snort 2.8.0 new features: IPv6 and port lists

Snort 2.8.0 comes with new features long desired for the open source intrusion detection system, including IPv6, port lists and packet performance monitoring. Learn about the new IPv6 and port lists that VARs and systems integrators can use to optimize their use of the IDS in this latest edition of the Snort Report.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

IPv6, port lists, packet performance monitoring and control of actions enabled by preprocessor or decoder events. This edition of the Snort Report provides details on IPv6 and port lists that VARs and systems integrators can use to optimize their use of the open source intrusion detection system.

Begin by downloading Snort 2.8.0. The system I use here runs FreeBSD 6.x.

Next, review the RELEASE.NOTES to find new features and see if any special instructions should be followed. On my system the release notes (once extracted) are located in /usr/local/src/snort-2.8.0/RELEASE.NOTES. It's also a good idea to look at the INSTALL document at /usr/local/src/snort-2.8.0/doc/INSTALL.

After looking at the documentation, install Snort. Notice the new switch to enable IPv6 support.

Here fe80::20c:29ff:fe00:c6c2 is the link local address of the FreeBSD system that will be pinging the listening interface of the Snort sensor. (You don't want your listening interface to be Internet-reachable; it should be completely passive. This is only a test.) The other IPv6 address is fe80::20c:29ff:fe60:232a; it's the link local IPv6 address of the Snort sensor.

One of the most exciting aspects of Snort 2.8.0 is the introduction of support for port lists. Older versions of Snort only accepted individual ports or port ranges when specifying TCP or UDP ports in rules.

For example, the README.variables document shipped with Snort 2.8.0 offers the following, which may appear in your snort.conf configuration file. I've added a line number to each for reference purposes; you should never have line numbers in a real snort.conf file.

1. portvar EXAMPLE1 80

2. var EXAMPLE2_PORT [80:90]

3. var PORT_EXAMPLE2 [1]

4. portvar EXAMPLE3 any

5. portvar EXAMPLE4 [!70:90]

6. portvar EXAMPLE5 [80,91:95,100:200]

The first item to notice is the use of "portvar" in lines 1 and 4-6 and "var" in lines 2 and 3. Snort 2.8.0 users should use portvar from now on, as the use of var will be deprecated in a future version. If you decide to use var, observe that the entire variable name ("EXAMPLE2_PORT" or "PORT_EXAMPLE2") must begin with "PORT_" or end with "_PORT". I recommend using portvar.

Line 1 sets EXAMPLE1 to be port 80. Line 2 sets the range 80-90, inclusive, to EXAMPLE2_PORT. Line 3 sets PORT_EXAMPLE2 to port 1. Line 4 sets EXAMPLE3 to any port. Line 5 sets EXAMPLE4 to any port except those in the range 70-90, inclusive. Line 6 sets EXAMPLE5 to port 80, 91-95 inclusive, and 100-200 inclusive.

README.variables offers the following sample rules, again annotated with numbers for reference only.

Rule 1 alerts on TCP traffic from any IP, port 80 to any IP, port 80-90 inclusive. Rule 2 alerts on TCP traffic from any IP, port 1 to any IP, any port. Rule 3 alerts on TCP traffic from any IP, port 90, to any IP, ports 100-1000 inclusive and ports 9999-20000, inclusive.

Trying port lists

The great aspect of port lists is the ability to specify a collection of ports which may host similar services. For example, you may run Web servers on a variety of ports. You want to test a rule that alerts when it sees traffic that isn't sent to one of those ports. Create the following port list variable and rule:

That doesn't look right. Why did the first alert fire? You don't want to see traffic to port 8000 TCP, but there was an alert. The second alert fired because the RST ACK was sent to port 50970 TCP, which is not in the port variable list.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy