Firewall Browser, our recently released free tool, has a very powerful search capability that automatically explores object hierarchies to catch all matching object groups and rules. We often see nested object groups in complex firewalls. Object and rule searches in various management consoles only look at direct matches. They are not capturing the matches that happen at child groups. When a user tries to add new object groups for new security rules, incomplete results can lead to duplicate or overlapping object groups.

Here is an interesting case from a Cisco FWSM firewall:

object-group service ldap-ports udp
 port-object eq ldap
 port-object eq ldaps

object-group service netbios-name-ports udp
 port-object eq 137
 port-object eq 138

object-group service domain-controller-udp-ports udp
 group-object ldap-ports
 group-object netbios-name-ports

object-group service std-dc-udp-port udp
 port-object range 137 138
 port-object eq ldap
 port-object eq ldaps

Object group “domain-controller-udp-ports” is exactly the same as object group “std-dc-udp-port”. With the management console, a user has to manually expand child groups with multiple searches to figure this out. Using Firewall Browser, a user can instantaneously view all object groups that match the given criteria (e.g. object name, IP address or service port) no mater how deep the values are hidden in object hierarchies.

The Firewall Browser rule search facility supports object hierarchies as well. In the above example, any access-list rule that refers to “domain-controller-udp-ports” is captured in Firewall Browser if the rule search is against any member object in “ldap-ports” or in “netbios-name-ports”.

You can download Firewall Browser from the Athena Security web site with no license restrictions for end-users.

We recently released Athena FirePAC v3.7, which adds several cool features to help you get a handle on out-of-control firewall configurations.  The new features make it much easier to identify object definitions that are not needed and to deploy consistent and systematic object definitions across an inventory of firewalls.

Object usage analysis helps you determine how objects are being used on a per-rule basis and also globally for each object.  For firewalls like Juniper Netscreen and Check Point, which allow multiple values in the source, destination, and service fields, you can now determine how much each object contributes to the overall usage of a rule.  For example, suppose you have the following rule in a Netscreen firewall:

ID	Source	Destination	Service	Action
17	client1 client2 client3	abc_dmz_proxies abc_dmz_remotes xyz_dmz_proxies xyz_dmz_remotes	HTTP HTTPS HTTP-ALT 8000

You’d like to know which of the DMZ proxy and remote destination objects specified by this rule are actually being hit.  Looking at the hit counts for the rule will only tell you that the rule is being used, but it will not tell you which of the objects in the rule are actually being used.  The new object usage analysis in Athena FirePAC will tell you exactly the percentage of total hits to the rule is contributed by each object.  This gives you valuable information about the traffic passing through your firewall and can help you identify which objects are unnecessary and can be removed from the rule.

You can also find out the aggregate usage of each network or service object in the configuration.  This makes it very easy to identify the objects that are not being used at all and can be removed.

Check it out!  You can download a free evaluation of Athena FirePAC from our web site.

We have just released a new free tool for network and firewall engineers called Firewall Browser.  It’s designed to help you search firewall configurations and find security rules and object definitions quickly and easily.  What’s really cool about this tool is that you can search for rules by source, destination, and service, entering values as IP addresses, network object names, port number, or service object names.  Similarly, you can search for network or service object definitions by name, by IP address, or by port number.  It works with Cisco, Check Point, and Netscreen firewall configurations and is available for download from the Athena Security web site with no license restrictions for end-users.  Check it out!  Let me know how you like it.

Most network engineers will agree that keeping a firewall rulebase free of unnecessary rules is good practice.  This involves finding candidates for removal based on traffic data captured in the firewall logs to identify which rules and objects were actually used.

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.

If you have a Security Information/Event Manager (SIEM) product monitoring your network, you probably see numerous events affecting your network.  When an unexpected and potentially dangerous event is detected, you will need to take action to block the incident and prevent it from happening again.  Diagnosing what really went wrong, what else is at risk, and determining the appropriate response can be difficult and time-consuming.  We have published a new whitepaper called Firewall Intervention for Threat Response that discusses how you can use the query and policy comparison facilities in Athena FirePAC to analyze the information provided by the SIEM product, identify appropriate rule changes to remediate the incident, and verify that the remedy implemented actually works without creating unintended side effects to the network.

Over at TechTarget, Joel Snyder writes about configuring access control lists on your routers to maintain security in the network control plane.

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.

The Wall Street Journal is reporting today that Shiite fighters in Iraq were able to capture video feeds from U.S. Predator drones using commercially available software.

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!

A new report released today from Verizon Business, “2009 Supplemental Data Breach Investigations Report: An Anatomy of a Data Breach,” takes a look the 15 most common types of security attacks. The report is drawn from data published in the “2009 Verizon Business Data Breach Investigations Report,” issued in April. That study reviews the cybercrime cases worked by Verizon’s Investigative Response team and analyzed more than 90 forensic investigations involving some 285 million compromised records.

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.

We recently received the following question from a customer about the security checks included in the PCI compliance analysis performed by Athena FirePAC:

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.

Firewall rule bases have an annoying tendency to grow larger over time. It’s easy to add new rules to a firewall. But nobody likes to remove rules from the firewall because they don’t know what the effect of the change will be. As a consequence, firewall rule bases will accumulate a lot of redundant and unused rules.

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.