Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Improper Network Segmentation Testing With Nessus

On January 3rd, 2007, Tenable's research group released a NASL script (plugin #23971, currently available to Direct Feed and Security Center customers) to test if a scanned host is on a different logical network, but also on the same physical network. If this is the case, your network may have a potential security issue, as IP based access control filtering may not be effective. This blog entry discusses what the plugin does, why this is important and comments on general firewall and access control auditing with Tenable solutions. 

What the Script Does

The NASL script attempts a layer two "ping" of target IP addresses that are not part of the local IP network (i.e., outside of the local netmask). If a response is received, then both devices share the same switching fabric and the potential security issue is reported as an informational vulnerability.

Why this is Important

If you are using some sort of routing, firewalling or proxy filtering to segment IP based networks, then an attacker may be able to create a virtual network interface and then connect directly to the target network.

For example, perhaps your organization has a DMZ with some "important" servers in them such as mail, web, .etc. and you also have a public network. There may be IP access control rules separating  the two networks. If these devices connect to a common switch though, a user in the public network may be able to configure a virtual interface with an IP address inside of the DMZ and directly access those servers. This could bypass security completely.

Consider a simpler example such as a web application that has a simple "IP based" form of access control, and requires remote users to originate from the 192.168.20.0/24 subnet. If there was one large collision domain and a remote host could perform an Ethernet "ping" of this application, they may also be able to create a virtual  interface with an IP such as 192.168.20.3 and connect to the application.

The solution is to use separate VLANs to segment layer 2 (Ethernet) traffic, or even multiple physical switches separated by routers or firewalls.

Analyzing the Results of the Plugin

Keep in mind several things when analyzing these results:

  • The test is occurring from the Nessus scanner. If you've provisioned your scanner with multiple interfaces and/or on multiple VLANs, then there might not be such an issue. However, if you've put the Nessus scanner in the HR network, and it can ARP ping hosts in the DMZ, you likely have a layer 2 security issue.
  • If you have MAC filtering in place on your switches, this is better than no filtering at all, but a user may be able to create a virtual interface with a MAC address that is either valid or not explicitly filtered.
  • Even if you have a firewall or some sort of IP filtering in place, if packets can be sent at layer two, you may be able to completely bypass the firewall.
  • The script basically says, the target is on a different IP network than I am, but I can also do an Ethernet ping to him. Keep in mind that some types of firewalls, proxies, NAC devices, security routers/switches and even honeypots may "respond" on behalf of their target.

Auditing Firewalls and ACL Polices In General

Tenable recommends a few different strategies for monitoring the security of IP based access control schemes.

  • Use distributed Nessus scanners that both scan "from the outside" as well as between political groups and organizations. If you conduct this sort of monitoring routinely, you can find changes in firewall policies when new ports become open, and you can also identify trust relationships between organizations within your network.
  • Continuous passive network monitoring, such as with the Passive Vulnerability Scanner, can identify all active hosts, hosts with open ports, hosts browsing on the Internet and internal trust relationships. By analyzing this data, a good understanding of the "real" set of access control policies can be determined.
  • Conducting log analysis of the actual firewall logs can be used to look for changes in the actual firewall configurations and lack of logs for expected and authorized traffic. Tenable's Log Correlation Engine supports this sort of analysis.      

Obtaining This Plugin

This plugin will be available to Registered Feed users January 10. It is currently available to Direct Feed and Security Center users.