When it comes to network security, one debate that still occurs now and then is the age-old question of whether to use a whitelist or blacklist to block unwelcome traffic from entering the network, such as known malware or phishing attacks delivered through email or other means.
To break this decision down, consider that at the edge of the network are a set of rules. These can be known under a number of names; from firewall rules to Access Control List entries (ACL), to spam rules, these may all address different types of data or do so at different points in the network, but they are all attempting to do the same thing: apply a set of rules to approve or deny traffic entry to the network.
The same rule can be applied by either whitelisting or blacklisting approaches. Let’s consider the following situation – say for example you wanted to allow HTTPS traffic (TCP port 443) from the IP address 220.127.116.11 being sent to 18.104.22.168. How does this look for both approaches?
With the whitelist approach, the basic principle is this: block everything except those things which are explicitly allowed. To apply our HTTPS rule, the firewall or other device would add a rule explicitly allowing that type of traffic for those source and destination addresses.
When a network packet is inspected, if it doesn’t match the exact combination of characteristics specified in the rule, it will be rejected and disallowed access to the network. Otherwise, if it does match the rule, it will be allowed in, and pass through the network as normal.
If we were to use blacklisting, then there is no need to explicitly create a rule for this type of traffic. By default, it will be let through unless we add a rule which purposefully blocks it from entering the network. All traffic will be let through, and only those which are explicitly denied by rules will fail to enter the network.
By comparing the two approaches, we can see that a blacklist may appear to be preferable; intuitively, it makes sense to specify what you don’t want to enter the network rather than what you do. However, especially in today’s network environment, with an ever-changing and increasing number of threats, it is often the poorer choice.
By limiting your rules to blocking only known threats, you expose yourself to those which you don’t already know about. Although this was applied on a widespread basis in the past, and may still be acceptable for smaller networks with static applications and devices with no access to the internet or other networks, whitelisting must be considered the more secure option today.
Consider the following situation: the attacker you have created a rule to block HTTPS traffic from moves from the IP address of 22.214.171.124 to 126.96.36.199. Now, your carefully-created rule which blocked traffic from 188.8.131.52 exactly has been bypassed; a network using blacklisting will let the traffic from the new IP address through, defeating the network edge security measures.
In the case of a whitelist approach, the network remains secure however; thanks to its behaviour of ‘block everything except that which is explicitly allowed’, the network is still protected even when the attacker changes their IP address, or the protocol in use (such as switching to HTTP, TCP port 80).
Many network operators are put off of the whitelisting approach due to the additional amount of administration it requires. In the past, network operations teams have been more hard-pressed to make sure no legitimate traffic is dropped, rather than making sure no illegitimate traffic enters the network. Although there have been exceptions, by and large this has been the case.
Look at the vast number of devices and applications using a modern network today, especially for an enterprise or service provider, and determining whitelist rules for all of them can indeed be a daunting task, and the risk of denying legitimate traffic is real. However, there are a few things that can help resolve this situation for the network operator, regardless of their scale.
Long a favourite in the routing world, summarisation allows one rule to do the work of many by working out a common characteristic shared by multiple rules and combining them into a single entry. An example is rather than blocking specifically 184.108.40.206, the network operator could block the IP address range 20.20.20.x, assuming that every IP address in that range is not welcome to communicate with the network.
2. Learning firewalls.
Some firewalls today come with learning functionality, where the firewall can be left in a transparent ‘learning’ mode for a day or other period of time during which traffic isn’t blocked, and the firewall creates rules itself for all (hopefully legitimate) traffic which passes through it. These can be very helpful in determining and implementing a set of whitelist rules in a realistic timeframe, although they should still be reviewed where possible to look for obvious malicious traffic that may have snuck through.
At the end of the day, like so many things in security the debate between whitelist and blacklist is a case of weighing security against convenience. The whitelist approach is more secure but requires typically more manual intervention, and is more prone to generating support calls to the network operations team when legitimate traffic fails.
However, if a security measure is not implemented in the network with the best intent of making it useful to prevent malicious activity and unwelcome traffic, it’s not really worth doing at all. At best, it gives a false sense of confidence, and many networks today using the blacklist approach fall into this category. Taking the jump to whitelisting may be painful and is likely to provoke short-term increases in support calls, but the resultant increase in network security should be measurable.
Ultimately, the choice between these approaches is still that: a choice. Going forward a whitelist approach looks to be far more effective at preventing unwelcome traffic from entering the network, especially as the capability of learning firewalls increases, even tied together with crowd-sourced security rules. But, a blacklist may still suit those very simple internal networks with fixed traffic.