How to Use Flow Data to Tighten Firewall Security Rules

This is a sponsored blog post by Francois Caron, SolarWinds® Director, Product Management.

Narrowing security rules, ok, where do I start?

Firewall administrators know that configuring their firewall rules in a very “broad way” – allowing all sources, destinations and too many/all ports – is a potential security issue. Narrowing those rules is the obvious answer to this security risk, but how do you know what is actually going through your firewall or router? How do you know what to narrow?

Most firewalls and routers generate log files that can tell you about what rules are effectively being hit; most of firewall management products are able to report on them, and let you know what you are actually letting go through your firewalls and routers. The problem is that they don’t always have the right level of granularity, or simply you may not have one of these firewall security management products (e.g., SolarWinds Firewall Security Manager [FSM]).

Proposed methodology

Here is a fairly simple flow-based methodology to approach this problem.

You will see that this approach involves a firewall security management product (step 5), but this is optional; the rest of the points are still perfectly valid:

1. Activate flows on your routers / firewalls.
2. Use the flow data to look at the traffic going through.
3. Decide what you want to restrict.
4. Create the firewall rule, e.g. Access Control List to remove that traffic.
5. Test it before it goes live (optional, need a firewall management product to do that).
6. Deploy it in the router / firewall.
7. Check that it blocks the expected traffic.

A concrete example

1. You can activate Netflow in your favorite IOS routers by tweaking the config manually. If you don’t feel comfortable doing that or you need to do it on a large number of routers, there are free tools to help you do that, such as this one from SolarWinds.
2. For this step, you need a way to report on flows in order to give you the traffic visibility that you need. Here is one of these network traffic monitor tools from Solarwinds – Netflow Traffic Analyzer – which actually goes beyond just Netflow from Cisco, by also covering sflow and Jflow. Other standards exist beyond Cisco’s Netflow, in particular sFlow. If you want to know whether your favorite device supports sFlow, here is a great list.
   

   Click to enlarge.

3. Wow, never realized that this router was actually being hammered by SNMP! So, let’s say you decide to remove SNMP.
4. The ACL rule to remove SNMP can be written like this – there are actually many different variations – and this one not being the most typical – but let’s keep things simple:

   access-list 1 deny any
snmp-server community public RO 1
snmp-server community private RW 1


5. This test is optional, but strongly recommended. It is about testing that you are not doing anything wrong with this new ACL, before you push it in production. Several product exists that can do that, including SolarWinds FSM. The virtual packet tracer function (called Packet Tracer) can confirm that:

   (a) Your new ACL will do what you want.
   (b) That it will do only what you want (e.g. won’t interact negatively with another rule already there, in this 1000’s line-big configuration).

   The summary (line 11) explains it all, by showing the result of the “virtual packet” analysis. More details on line 23:

   

   Click to enlarge.

6. Now that you are confident that this new rule will block what you want (and only what you want), it’s time to go live! Push that configuration manually or via a network configuration management tool, such as SolarWinds Network Configuration Manager.
7. Now, you want to check that SNMP traffic was effectively stopped. SolarWinds Network Performance Monitor (or any network monitor) will show their stats interrupted at the time you pushed your updated config, confirming that your device stopped responding to the SNMP requests:
   

   Click to enlarge.

Do you need to block the traffic using a finer granularity?

Again, flows can help by telling you who generates the SNMP traffic.

In the example below, the chart on the right is the list of senders who contribute to the total SNMP traffic showed on the left chart; you can now refine your ACLs by blocking specific senders only.

Click to enlarge.