With this data, it is possible to clean up rules and objects within the rules that are never hit, as well as remove object members that are not hit in any rule.  The benefits of rule cleanup are not only for improving the maintainability, but also the performance of the firewall.  In high-transaction systems, such as financial trading systems or e-commerce platforms, squeezing the most performance out of the firewall can become a crucial exercise.  Once cleanup is completed, additional improvements in performance can be achieved by using the same traffic log data to determine the most used rules and objects. This forms the basis for re-ordering rules, where the objective is to move the most frequently used rules to the beginning of the rulebase as long as there is no impact on policy.

Re-ordering rules to improve performance requires rule dependencies to be taken into account so that the firewall’s behavior is not adversely impacted. Moving a rule will change the behavior if any of the rules passed over by the moved rule have a rule order dependency with it, i.e. they overlap with it and perform a different action.  For example, moving an allow rule over an overlapping deny rule would cause some previously denied packets to now be allowed.  You even need to take into account rule options such as logging or user authentication.

Often, only specific objects within the rule are frequently used and these specific portions might not have any rule order dependencies.  In these cases it might be easier to simply carve out separate rules using these most-used objects and add them at the beginning of the rulebase.

To illustrate some of these points, consider the following example ruleset for a perimeter firewall connected to the Internet, a DMZ network hosting publicly accessible web servers, and an internal network hosting some application servers.

In this rulebase, rules 100 and 60 were the two most used rules, in that order.  Determining whether or not these rules overlap requires identifying the specific IP addresses and subnets used in each of the network groups and the services included in the service groups.  If the service groups DangerousSvcs and InventorySvcs contain any of the same services, then rule 60 cannot be moved up in the rulebase any further than rule 5 because both rules refer to the network group InventorySvrs and they have differing actions.  Similarly, rule 100 cannot be moved in front of the rule 60 if they overlap since rule 60 has a user authentication option even though they have the same rule action.  It might be better to redefine rule 100 to exclude the addresses and services referred to by rule 60 so that rule 100 can be moved higher up in the rulebase.

It is possible to determine the most used rules or most used addresses and services in the firewalls with the help of scripts. The log data can be parsed and stored in a database and SQL queries used to count the number of rows for each rule ID to get the rule usage.  However, determining rule order dependencies does require examining the relationships between each rule and every other rule in the rulebase.  You need to determine the effective portion of each rule, taking into account the content of each object used in the rule before you even try to determine the overlaps between the rules.  Correlating these addresses or services to the object groups requires an understanding of object and rule structures within the firewall configuration.  Performing this analysis manually requires a lot of time and is error prone because of the large number of rule and object combinations that have to be looked at.  If the rulebase is non-trivial, even a scripting solution is untenable.

Fortunately, Athena FirePAC automates this process and generates a report that identifies all structural redundancies in rules and objects that can be cleaned up, all unused objects and rules that can be cleaned up using the firewall log data, and provides an optimized rule order where the rules are reordered based on most used rules and rule order dependencies.

Do you have SNMP enabled on edge devices? Fine… so long as you also have an access list saying that those SNMP packets can only come from your management station. Is the management interface, whether HTTP, HTTPS, SSH or (heaven forbid) Telnet running?

Fine … so long as no one outside our network can ever get there.

We call this the “control plane” or “management plane.” Think of it as a different network that runs in parallel to your data network, and is used to control, monitor and manage the data network. In huge networks, there is a true network control plane that is completely separate from the data that the device sees. But in many smaller networks, control plane, management plane, and data plane run on the same wire.

You can, and should, secure your network control plane in many ways, but they mostly come down to two techniques: access control lists and self-protection.

ACCESS CONTROL LISTS MANAGE TRAFFIC TO EDGE DEVICES
Access control list protections usually occur when you put a block of some sort in non-firewall devices at the edge and core of your network. A good example is SNMP. Let’s say you have an SNMP management station at 10.20.30.161. That represents the one valid flow to and from that management station to network and security devices. Now, any other SNMP traffic floating around on your network, or coming in from the edge, should be blocked. If you have intermediate routers in your network, and certainly if you have firewalls, you should use them to block SNMP traffic — and any other management traffic — to your security and network devices, except from authorized sources.

Good advice, and an excellent example of best practices for securing your network infrastructure.  To ensure that your network infrastructure remains secure, you will want to configure and enforce access control restrictions like these on all of your non-firewall devices.  Furthermore, you will want to routinely audit the network devices to ensure that they continue to follow these best practices.  When changes are made to a device’s access control lists, you will want to be notified when changes cause the device to fail to meet these practices.

Of course, auditing all of the devices in your network infrastructure can be a huge job.  The attention to detail required to make sure you get it right and don’t miss something takes a lot of time.  It’s difficult to perform the audits frequently enough to be effective without tools and automation to facilitate the process.  Fortunately, the security checks in Athena FirePAC provide a perfect vehicle for implementing these kinds of network best practices.

For example, FirePAC provides a standard security checks for SNMP that can be customized to ensure that the device policy allows SNMP messages from only the management station and to flag the check if any the policy allows any other source.  FirePAC provides other standard checks for various management protocols that can be similarly customized to check for restrictions to allow only access from the management station.  These kinds of customizations to the standard security checks in FirePAC will help you tailor the Security Audit report to your organization’s network policy and simplify the task of ensuring the security of your network.

Senior defense and intelligence officials said Iranian-backed insurgents intercepted the video feeds by taking advantage of an unprotected communications link in some of the remotely flown planes’ systems. Shiite fighters in Iraq used software programs such as SkyGrabber — available for as little as $25.95 on the Internet — to regularly capture drone video feeds, according to a person familiar with reports on the matter.

[...]

The stolen video feeds also indicate that U.S. adversaries continue to find simple ways of counteracting sophisticated American military technologies.

[...]

Some of the most detailed evidence of intercepted feeds has been discovered in Iraq, but adversaries have also intercepted drone video feeds in Afghanistan, according to people briefed on the matter. These intercept techniques could be employed in other locations where the U.S. is using pilotless planes, such as Pakistan, Yemen and Somalia, they said.

[...]

The potential drone vulnerability lies in an unencrypted downlink between the unmanned craft and ground control. The U.S. government has known about the flaw since the U.S. campaign in Bosnia in the 1990s, current and former officials said. But the Pentagon assumed local adversaries wouldn’t know how to exploit it, the officials said.

Most interesting was this comment about the difficulty in upgrading the drones to encrypt the video downlink.

Officials stepped up efforts to prevent insurgents from intercepting video feeds after the July incident. The difficulty, officials said, is that adding encryption to a network that is more than a decade old involves more than placing a new piece of equipment on individual drones. Instead, many components of the network linking the drones to their operators in the U.S., Afghanistan or Pakistan have to be upgraded to handle the changes.

Security has to be built in from the start, not added in as an afterthought.  Of course, you should never underestimate your adversaries either!

The report identifies and profiles the most common attacks. For each type of attack, the report provides case examples, frequency of occurrence, threat sources, warning signs, controls that can deter or prevent threats, and commonly affected industries.

The report identifies and ranks by frequency the following top 15 types of attacks:

1. Keyloggers and spyware.
2. Backdoor or Command/Control.
3. SQL injection.
4. Abuse of system access/privileges.
5. Unauthorized access via default credentials.
6. Violation of Acceptable Use and other policies.
7. Unauthorized access via weak or misconfigured ACLs.
8. Packet sniffer.
9. Unauthorized access via stolen credentials.
10. Pretexting (social engineering).
11. Authentication bypass.
12. Physical theft of asset.
13. Brute-force attack.
14. RAM scraper.
15. Phishing (and variants).

It’s interesting to observe that 6 of the 15 list proper egress filtering as one method of mitigating the attack. That’s more than a third of the most common attacks that can be stopped by proper firewall configurations. Read the whole thing.

I just ran Athena FirePAC on an ASA firewall that is failing PCI requirement 1.3.6 due to SYN flood protection not enabled. I understand what SYN flood protection does, but I believe ASA firewalls still processes in a stateful manner, even without SYN flood protection turned on. This failure would indicate that the firewall will process a non stateful packet, and I don’t believe that’s the case. Can someone advise on why FirePAC failed us on this requirement?

The PCI DSS control item 1.3.6 says, “Implement stateful inspection, also known as dynamic packet filtering. (That is, only ‘established’ connections are allowed into the network.)” It is true that Cisco ASA firewalls implement stateful inspection, as do most modern firewalls including Check Point, and Juniper Netscreen. So checking for it is a moot point.

Rather than simply making this a “checkbox” item in the PCI DSS compliance analysis provided by Athena FirePAC, we decided to take this as an opportunity to check for additional protection against some common attacks that exploit the stateful nature of TCP connections. The SYN flood attack is one example.

In Cisco ASA firewalls, the NAT and Static commands have a parameter that specifies the maximum number of embryonic connections allowed per host. An embryonic connection is a connection request that has not finished the three-way handshake between source and destination. The default is 0, which means unlimited embryonic connections are allowed. Setting the embryonic connection limit to a non-zero value lets you prevent SYN flood attacks by dropping connections after the limit is reached. FirePAC checks if this limit is not set, i.e. 0, which means unlimited embyronic connections are allowed. If it is 0, the host is susceptible to the SYN flood attack and the security check is flagged. FirePAC performs similar checks for Juniper Netscreen and Check Point firewalls as well.

As I’ve noted elsewhere, simply passing a PCI compliance audit is not a substitute for security. You really have to know what’s going on in your firewall to ensure that it’s configured securely. Given some of the changes announced earlier this year by the PCI council, these kinds of robust and detailed analyses will be required to show that that the PCI in-scope network is truly secure and controlled. FirePAC includes these kinds of additional checks to help you get it right.

Redundant rules exist in firewall rule bases because of structural relationships between the rules; one or more rules duplicate the functionality of other rules. As firewalls evaluate the rules in the sequence they are defined in the rule base, rules whose functionality is covered by other preceding rules in the rule base will never be triggered and hence can be removed safely. There can also be redundant rules that exist as special cases preceding more general rules that succeed them. Removing these special cases will not change the firewall functionality; the later general rules allow or deny the same traffic. Identifying the redundant rules requires an understanding what traffic is allowed or denied by each rule. From this, you can identify rules that are redundant. If object groups are used heavily in the rule base, identifying the redundant rules manually will be painful and time consuming because of the large number of expanded combinations that need to be investigated. Tools are good at automating this type of analysis and easily identify these rules. Once identified, cleaning up these rules is very safe. Here at Athena Security, we have found as much as 30%-40% of the rules in large rule bases are structurally redundant and contribute nothing to the functionality of the firewall. Removing these rules will simplify the firewall configuration, making it easier manage and less error-prone to make changes.

On the other hand, identifying unused rules requires a lot more time and effort invested up front. These are the rules that have become stale over a period of time. They were not removed because the business owner could not be identified or the business owner is not sure. Some times you have to prove to the business owner that they are not really using the services allowed in the rule base. So identifying these unused rules requires capturing firewall logs for reasonable time duration. These logs then need to be analyzed to see which rules were never triggered during the period of log capture. Trending might also be required to accurately identify rules that might only be used at certain points in the year. On most firewalls, capturing logs for rules requires enabling of the log option on the rules that are being monitored. This could have an impact on the firewall performance, depending on the traffic being logged. Even though this process is time-consuming, often this is the only way to make the overly permissive rules less specific or to remove unused services from existing rules.

Cleaning up firewall rule bases is an important part of auditing your firewalls. This process can be very complex and time-consuming to attempt by hand. By using tools such as Athena FirePAC that automatically identify redundancies and unused rules, you can complete the process in only a day or two rather than weeks.

First, as was announced here, Athena Security is now a technology partner with SolarWinds and we have integrated FirePAC with Orion Network Configuration Manager. You can connect to Orion NCM from FirePAC, select the firewall you’re interested in from the device repository, and import their configurations directly into FirePAC. The import is fast, easy, and painless. No worries about logging into the firewall or which commands you need to issue to get the right data. And you can import multiple firewalls in one operation.

Related to the Orion NCM integration is the configuration update feature. Now, after you’ve imported a firewall into FirePAC, you can update the configuration automatically from the same location it was originally imported from. If you imported from the filesystem, the update will be taken from the same files. If you imported from Orion, the update will be taken from there. No need to specify the same source for the configuration files over and over again. Just select the firewall in the FirePAC Firewall Inventory and click the Update operation.

Another big new feature is our enhanced Query capability. There are now three types of queries that allow you to explore the firewall behavior and configurations. With the Data Flow query, you can ask questions like “which critical hosts are exposed to these risky services?” or “what sources are allowed to connect to this server?” or “why is this service not being allowed through the firewall”? It allows you to use Athena’s powerful data flow analysis of firewall behavior to identify specific risks to your network or to understand exactly what the firewall is doing.

With the Rule Search query, you can search for rules that match specific patterns of source, destination, and service parameters across your entire inventory of firewalls. You can even select rules based on matching network or service groups. With the Object Search query, you can find where specific network or service objects are defined and where those objects are used in other object groups. Taken together, Rule Search and Object Search give you a powerful capability to understand the structure of your rulesets and object definitions and their inter-relationships.

Wrapping up the Query facility is the new Saved Queries feature. Now you need only enter the parameters for a given query once. Then you can save it and issue the saved query again later. This can be useful when you have a long list of critical hosts that you need to check exposures to on a regular basis.

All these new features really extend FirePAC as an operational tool for managing firewalls.  You can download an evaluation free for 30 days from our web site.  Check it out!

To cast your vote for Athena, go to the finalist page and select Athena Security in the Software category. The winners will be announced at TiEcon, May 14-15, 2009 being held at the Santa Clara Convention Center.

The tools exploit similar inherent security weaknesses in the two networking technologies — namely in how they forward traffic.

[...]

To execute an MPLS or Ethernet carrier network hack, the attacker first must get into the network, either by hacking a router or a management tool. Then Rey and Mende’s MPLS hacking tool could be used: It modifies the labels that are added to packets in an MPLS network and determine how those packets get forwarded. This lets an attacker silently redirect traffic to other sites, such as a malicious DNS server or a phony authentication server, Rey says. “The victim doesn’t notice anything and the attacker has both directions of traffic” in his control, he says. “The whole VPN model of trust is violated,” he says.

The attack doesn’t target a specific vulnerabilty — just the way MPLS operates. The story is much the same for Ethernet. VLAN-tagging, for instance, helps carriers separate different customers’ traffic across their backbones. “But there’s no encryption and no additional security” with Ethernet, Rey says. “It’s just traffic separated by adding some more bits to the traffic, which brings us back to being able to modify those bits” with our hacking tool, he says.

The researchers plan to release the tools at Black Hat Europe next week.