Intrusion Shield vs a Firewall

For several years, firewalls have long played an integral role in cybersecurity. They’re usually deployed as the first line of defense against network-based threats, many of which used to originate from outside the corporate network. Today’s threats, however, have grown more complex. Not only are they coming from almost any direction, but they’ve also become more adept at evading firewall filters.

In the blog, we break down the differences between the Intrusion Shield device and a firewall — and why you need both in your network security architecture.

Clarifying what we mean by ‘firewall’

The term ‘firewall’ has been slapped on just about any cybersecurity solution that filters and controls network traffic. Heck, we won’t be surprised if people started lumping Shield into that category. So, before that happens, we thought it would be a good idea to distinguish between the two. When we say firewall, we’re referring to any security solution that controls network traffic based on a predefined set of rules or security policies, which are usually specified by whoever is tasked to administer the firewall.

Those rules might, for example, prohibit traffic flow of packets whose destination ports are associated with certain protocols, e.g., FTP, SSH, or Telnet. Or they could limit inbound traffic to packets coming from a certain range of IP addresses.

Basic firewall rules are simply based on source and destination IP addresses and/or ports, and network protocols. However, there are also some advanced firewalls that inspect further into each packet to find elements that violate more sophisticated rule sets. For instance, an application firewall might block certain email traffic if it finds an executable file sent along with it as an attachment. This feature is known as stateful protocol analysis or deep packet inspection.

What is Intrusion Shield?

Intrusion Shield also controls network traffic. But instead of inspecting various elements of each packet and then relying on predefined rules to determine its course of action, it mostly only looks at the packet header and footer and then looks up its database to determine if the packets in question can be allowed through or blocked. If the destination or source IP address is associated with bad actors and malicious content or belongs to an unknown network, those packets will be blocked. (Find out how we know what’s good and bad here.)

With these characteristics in mind, let’s have a look at various scenarios and compare how a firewall and Shield would respond to them.

Handling inbound packets

Firewalls were originally designed to keep threats out of the corporate network. And even today, most firewall rules are configured precisely for this purpose. So, for example, you might specify a list or range of allowable IP addresses to compare against the source IP address of each packet. Any packet that doesn’t originate from an IP that’s included in that whitelist will be blocked.

You could also do it the other way around, i.e., blacklist a set of IP addresses so that only those that don’t belong to that set will be allowed access. Those that do will be blocked. Some organizations take this blocking concept even further and block entire countries or geographical regions in what is known as geoblocking.

While these extremely paranoid security policies might succeed in blocking threats, they could also seriously impact productivity. What if you have a remote worker in one of those geoblocked countries and he/she wants to connect to one of your web servers but somehow doesn’t have VPN access? If that remote worker is connecting from a legitimately safe network, the connection should be allowed to pass through.

Configuring firewalls based on blacklists and whitelists will always be a challenge because there’s always the chance you’ll end up blocking a legitimate connection even if it’s coming from a perfectly safe network. Shield is better suited for a wider range of scenarios because you don’t have to draw up a whitelist or blacklist to block a high-risk packet. If a connection is originating from a known malicious network, it will be blocked. Otherwise, it will be allowed to pass through.

Here’s a different example, this time illustrating a firewall’s inadequacy in handling seemingly harmless inbound traffic. Some firewalls perform what is known as stateful inspection, wherein they allow or deny access based on the ‘state’ of a connection. For instance, a firewall may allow a DNS response packet to pass through even if it came from an unknown external source as long as it (the firewall) had previously observed a corresponding DNS query from one of its internal devices.

The problem is that some DNS resolvers can be compromised as in the case, for example, of a DNS cache poisoning attack. A DNS poisoning attack forces a DNS resolver to supply wrong information so that the device requesting that information will be directed to a malicious site. A firewall can’t notice this, but Intrusion Shield can. Shield will immediately recognize the threat through the data in the response packet and prevent the internal device from establishing a connection with the malicious site.

Handling outbound packets

As we already know, firewalls were traditionally designed to filter out inbound threats. But what about outbound threats? What if the threat is already inside the corporate network? How would you, for instance, block a malware that has already established a beachhead on one of your internal workstations and is now attempting to connect to its command-and-control (C2) server?

In order to address this type of threat with a firewall, you would need to know the IP addresses of all the C2 servers malware usually connect to. But what if it’s a Zero-Day? Well, you can probably resort to using overly broad security policies such as geoblocking and then block outbound connections to countries like China and Russia, where most of the state-sponsored cyber attacks are coming from, but you already know the side effects of such policies.

Besides, not all malicious servers are stationed in those countries. For all you know, the C2 server in question could be in Germany or in the US. Intrusion Shield is more effective against these threats because 1) every known malicious C2 server in the world, as well as every known association, is likely already included in its massive database, and 2) every network and server with a good reputation is likely also in that same database.

Shield will know if a process is connecting to a malicious, good, or completely unknown server, and can take appropriate action.

Handling payloads and encrypted traffic

Some firewalls can do deep packet inspection (DPI) and allow/deny access based on a packet’s payload. Some firewalls can even decrypt encrypted traffic to see what’s inside. While these advanced features can catch certain threats, they come with a tradeoff.

Because of the tremendous processing involved in DPI and decryption, firewalls equipped with these features can degrade performance and cause bottlenecks in the network. Some threat actors even abuse these resource-hungry features to carry out denial-of-service (DoS) attacks.

Since Intrusion Shield only inspects source and destination data, its performance overhead is minimal. It won’t cause any network bottlenecks. That also means it’s immune to the type of abuse threat actors play against DPI-enabled firewalls.

How Intrusion Shield enhances firewall security

Firewalls and firewall rules work best against predictable threats and in minimizing known risks. For example, since you know that unencrypted file transfer protocols like plain FTP are vulnerable to man-in-the-middle attacks, you can use a set of firewall rules to block all FTP connections and only allow encrypted protocols, such as SFTP and FTPS, to pass through.

You can then add Intrusion Shield to catch whatever threats that firewall fails to block. For example, if an internal device unwittingly attempts to connect to an FTPS service whose IP address is associated with bad actors, Shield will recognize that malicious IP and prevent that connection from getting established.

Conclusion

Gone are the days when dealing with cyberthreats was straightforward. If you wanted protection against viruses, you deployed an antivirus. If you wanted something to defend your IT infrastructure against network-based external threats, you deployed a firewall. Today’s threats are more sophisticated. A malware can be installed through an infected USB stick but retrieve commands and associated files from a remote C2 server.

Because cyberthreats are multi-faceted, the best way to counter them is also by employing a multi-layered a.k.a. defense-in-depth approach. Instead of choosing between a firewall and Intrusion Shield, you can achieve better results if you use them side by side to complement each security solution’s individual strengths and achieve stronger security.