Monitoring Internet-facing Servers with SecurityCenter & Nessus

Covering All Your Bases

Internet-facing servers are a popular attack target: They are accessible to everyone on the Internet and can easily be probed for vulnerabilities. Based on exposure alone, Internet-facing servers present a higher risk of becoming compromised. This risk needs to be mitigated if organizations must provide access to services such as web, mail, and VPN connectivity. It is therefore important that these servers are regularly assessed for potential vulnerabilities (and more important that something is done to remediate the vulnerabilities). This blog entry provides guidance for some basic security issues which are important to monitor on Internet-facing servers, such as:

• Maintaining Patches - It is important to keep up-to-date with patches in general, and with systems that are exposed to the Internet, fixing both local and remote vulnerabilities are particularly important. For example, a web server may contain a vulnerability which allows an attacker to gain a shell with the privileges of the running user (e.g., www-data). If local vulnerabilities are present, the web server vulnerability can quickly lead to the attacker gaining root-level privileges. With this level of access, attackers have a much better chance to cover their tracks and hide their presence within the system. Therefore, ensuring all available security patches are installed on your systems is important.

• Easily Exploitable Web Application Vulnerabilities - If you've ever monitored the logs of an Internet-facing web server, you know attacks against applications are frequent. Application testing involves many different processes and techniques, but you don't want to give attackers any low-hanging fruit. It is important to test your applications before they are put in production, but also continue to monitor for vulnerabilities in production. Several automated tools in use by attackers exploit flaws, such as SQL injection, on a regular basis. Once the application is on your production system, it is important to regularly assess it to stay ahead of the curve and remediate the vulnerabilities before attackers get to them.

• Exposed Services - Internet-facing servers ideally offer a limited number of services, since they do not need to support a wide range of services that an internal development server would offer. This makes it easier to scan and identify vulnerabilities and detect any new services which may crop up. Firewalls are often deployed to provide an extra layer of protection for systems exposed to the Internet and ensure that only required services are permitted. Scanning these hosts on a regular basis will quickly identify any new services that are running or mistakes made in firewall configuration which may unintentionally expose an internal service or server.

Putting the Rubber to the Road

The following are examples of vulnerability scans which cover the basic security measures described above.

Local Patch Checking & "Dynamite" Plugins

Configuring local patch checking between your vulnerability scanner and Internet-facing systems allows you to find gaps in the patching process. For example, below is a graph of the patches being applied and mitigated against a set of servers providing web, mail, and SSH access to the Internet.

The graph above shows points in time (the spikes in red) where patches were missing from the hosts. The flat sections represent points in time where the systems are fully patched against known security vulnerabilities.

For even more value, you can use "Dynamite" plugins to gather more information about the systems, and detect conditions that may have security implications. For example, IPv6 presents many challenges for network administration and security alike. One challenge is discovering IPv6-enabled hosts using traditional methods of scanning. The large address space will take considerable time to identify targets on the network. Credentialed checks can be used to find IPv6-enabled hosts by enumerating the network interfaces (using a command such as ifconfig on Linux or ipconfig on Windows):

Scanning the IPv6 address of a system may bring to light vulnerabilities that are present on IPv6 and not available via IPv4.

Web Application Scanning

Many systems exposed to the Internet contain web applications. Two areas Nessus covers very well are discovering known web application vulnerabilities and fuzzing to find low-hanging-fruit application vulnerabilities (such as cross-site scripting or SQL injection). Nessus users can check for both of these conditions using a crafted scan policy and enabling two plugin families (CGI Abuses and CGI Abuses: XSS). Many administrators have been able to discover and remediate several vulnerabilities using this type of scan. Sometimes administrators will install a web application using the source code, which means it does not show up in the local security checks on Linux or UNIX systems. Scanning for known web application vulnerabilities will detect vulnerabilities which have been published for these applications.

Below is a dashboard which displays several charts used to distinctly represent web application scan results, web vulnerabilities, SSL certificate information, and web services on common and uncommon ports:

The dashboard above displays vulnerabilities detected by CGI scans performed by Nessus, and lists the severity level (upper-left corner). Certificates are useful to help ensure integrity and privacy, and there are several vulnerability checks which represent SSL issues (upper-right corner). Web servers can also run on non-standard ports, which could represent an unintentional exposure of a web service on an Internet-facing system. Many management applications also use non-standard web ports.

Full Network Scanning

Nessus and SecurityCenter provide the ability to correlate exploitable vulnerabilities, which is extremely useful in categorizing vulnerabilities. Regardless of how your organization classifies risk, a vulnerability that has an exploit published has a higher chance of being exploited than one that does not. An exposed, exploitable vulnerability on an Internet-facing system deserves immediate attention. Below is a dashboard which helps identify such a condition.

This dashboard creates three tables of exploitable vulnerabilities on the left column. One table depicts the top vulnerabilities exploitable by Core, CANVAS, and Metasploit, three of the most popular exploit frameworks. The next table lists the total number of exploitable vulnerabilities, the percentage of all vulnerabilities which are exploitable, and unique counts for each exploit platform. Finally, a twenty-five-day trend comparing three different types of exploitable vulnerability counts is plotted for each exploit platform (this dashboard requires SecurityCenter 4.4).

Conclusion

There are many tools and techniques available to protect your systems, from the most basic to very advanced. Regardless of your defensive strategy, your architecture should be built on a solid foundation which starts with basics, such as applying patches, implementing firewalls, securing applications, and hardening systems. Tenable's tools can help provide continuous monitoring to ensure these basic security measures are in place.