In part 2 of our series on crafting more secure firewall rules, we will focus on inbound traffic and how rules can be crafted to strengthen the security posture in your organization. We will highlight a few pitfalls and provide recommendations to tighten down these rules to improve your organization’s security posture. Note: This is not an exhaustive list of all best practices relating to firewalls, but just touches on one of the most common issues with lax firewall rules.
Example 1: “Public Facing Exposure”
Let’s take an example of a public facing web server that needs to be accessible from the internet. In this example, the web server is on the same subnet as multiple servers that only need to be accessible via internal resources.
This is something that we have found more often than we’d like to see among production networks. In these networks, we see servers that need to be accessed publicly and servers that need to be accessed privately, sharing the same subnet. This scenario is problematic because there are no barriers to control traffic between the publicly accessible servers and the private servers. This poses a substantial security risk, if one of the public servers becomes compromised. Attackers will then easily be able to move laterally from the initially compromised server to all the others.
The other less obvious issue with this scenario is that you have no visibility into the traffic that between the public and internal servers. Often times, the speed at which an organization is able to respond to a cyber incident can be correlated to the log data that they possess. Even if an organization has an endpoint protection solution that can provide some of this data, it’s best to be able to also be able to see the traffic as it passes between hosts on the network. Having this log data, will also allow you to forward logs to a SIEM (Security Information and Event Management) tool that can be monitored by a SOC.
Addressing “Public Facing Exposure”
So, how do we fix the problem in the example above? For servers that need to be accessible from the internet, it’s typically best to place said servers inside a DMZ. Network segmentation is a basic security principal that can be implemented, that helps you granularly control the type of traffic that is allowed between subnets. A DMZ is a type of network segmentation, because it allows for your public servers to be separate from your internal servers and forces any communication between your public servers and other resources to traverse the firewall first.
Some additional safeguards that can be put in place to protect internet your public facing servers, are an IDS (Intrusion Detection Systems) or IPS (Intrusion Prevent Systems) appliance and a WAF (Web Application Firewall). The IDS or IPS will look specifically for attacks being carried out against your servers, while the WAF can help protect your web applications again common web exploits. We will address these technologies in more detail in a future blog post.
Example 2: “Convenient Access”
The next example is an organization that allows RDP to internal resources. These resources can be workstations or servers. Allowing RDP through a firewall from the outside world should never be a solution to provide users or vendors access to internal resources. RDP open through a firewall has been exploited by attackers in ransomware attacks for years, yet organizations still do it because it’s convenient.
Addressing “Convenient Access”
Fixing the problem of convenient access is probably one of the easiest to implement security safeguards that we’ll discuss about in the Venyu Cyber Corner blog. The answer is to force users and vendors to SSL VPN, preferably with MFA (Multi-factor Authentication) to be able to access internal resources from the outside world.
Since proper cybersecurity focuses on a layered approach to protect organizations, a remote access solution that forces users or vendors to SSL VPN with MFA provides closes a significant security hole, without costing the organizations a large sum of money to implement and operate.
As always if you have additional questions, would like someone to review your firewall settings with you, or need assistance with a change, please open a support case using the customer portal (https://portal.myvenyu.com/)
