Terry is a seasoned penetration tester with a diverse background across IT, cybersecurity, and military service. Before joining Black Hills Information Security in 2022, he performed various roles including pentesting, incident response, and forensic analysis.
While social engineering attacks such as phishing are a great way to gain a foothold in a target environment, direct attacks against externally exploitable services are continuing to make headlines. In this blog, we’ll cover things you can do to better protect externally exposed network resources. If you haven’t reviewed your external footprint in some time, this is a good read to help you examine your current configurations and give you some ideas on better securing external infrastructure.
Some of the largest breaches in recent memory were due to exposed applications that suffered from remotely exploitable vulnerabilities. Many of us are probably familiar with vulnerabilities like Log4Shell1, ProxyShell2, and the MOVEit3 breaches. While these vulnerabilities were initially 0-days, continued exploitation took place well after patches were available from the vendors. What can we do to protect ourselves? Let’s look at some questions we can ask to help ensure our external infrastructure is as secure as possible.
Knowing what you have is the first step in being able to protect it. For a network, this means asking what services are accessible from the internet and why they are accessible. Keep an updated inventory of open ports and software in use, making sure you regularly review this data to keep it accurate and current. In a past life as an incident responder, it was not uncommon to learn that a breach was the result of a legacy firewall rule that was forgotten. Some of these situations allowed an adversary to obtain remote access to internal resources when there was no longer a legitimate business need for the port to be open on the firewall. Some ports were opened for testing purposes, containing an overly broad scope and never closed; others were opened for legitimate reasons, but facilitated access to applications with known vulnerabilities that were exploitable remotely.
Taking a thorough inventory of externally accessible services and software packages in use will go a long way in helping you understand ways to better secure your environment. Regular external vulnerability scans and port scanning checking all ports are useful ways to accomplish this. Tools such as commercial vulnerability scanners4, Nmap5, and masscan6 are useful. Other resources, such as Shodan.io,7 can also give you an idea of what ports and protocols are open on your networks. These tools can help with verifying network changes after deploying new systems or decommissioning older systems. Check vendor websites for security advisories and general product updates for any software packages in use. Ensuring your software is up-to-date and properly patched will go a long way in helping prevent successful breaches. Once patches have been applied, it is always a good idea to use a vulnerability scanner or manual testing to verify the patch was applied and the vulnerability had been mitigated.
Now that we know what we are opening to the world and why, let’s ask ourselves, “What would happen if these services were exploited?” If a public-facing service is breached, where can the attacker move to next? Will they be able to access your entire network from a single compromised host, or will they be in a network that restricts or delays immediate lateral movement? Answering these questions requires some knowledge of your network architecture. For example, do you have a DMZ configured to separate internal resources from public-facing web servers? I have encountered many networks with NAT rules in place, allowing direct access to servers on an internal network. This configuration risks making further exploitation easier versus having an attacker boxed into a DMZ with fewer or more difficult options for lateral movement. This is particularly important if the software being exploited is through a 0-day. A vendor patch may not yet be available, but having the proper separation in place between externally accessible services and your internal network may be the only way to mitigate broader impact until a patch is available.
Employee remote access is also a relevant topic to review in this process, particularly with the rise of remote workers. It is a good idea to examine how your users are accessing network resources externally. Where possible, keep the resources accessible only through a VPN that is protected with a strong password and multi-factor authentication. If a user requires external access to internal network services, it is a better choice to facilitate this access through a VPN instead of opening ports through a firewall.
Now that you know what you have and why it is accessible, and you possess an understanding of the impact if those services were to be exploited, you will also want to know what is happening while others are interacting with those services. The best way to address this is to ensure audit policies are in place and log files are captured for analysis and general log retention. This is a critical step, and key to understanding the full impact of a breach. Ensuring your logging mechanisms are in place and correctly configured is critical. Sadly, I have been on IR engagements where firewall logs were only written to memory, with no more than a few hours of logs available, well past the timeframe of the suspected breach. If you don’t have a SIEM, at a minimum, offload firewall logs to a syslog server. Other instances where a client’s Microsoft 365 tenant did not have audit logging enabled were also common. A lack of log data can make it very difficult, in some cases impossible, to fully answer critical questions about events during a breach. Audit logging should always be enabled, and the resulting logs should be captured and stored for subsequent analysis and retention.
In this blog, we’ve talked about knowing what is accessible on your external network and why, how network architecture is important, and addressed the need for good auditing and logging practices. While this is not a catch-all process and there are many other related topics to consider, these are good starting points to better understand your environment and how to defend it.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。