One question that often raises its head is “what else should we be doing to further secure our networks against an avoidable attack ?”
There isn’t one single answer for this – much in the same sense as no “silver bullet” exists either. Too often, we neglect that should arguably be the basics. Aside from the best practice approaches which any network administrator worth their salt should already have implemented, there are numerous other ways to secure a network and harden it against attack. This article will explain some of the lesser known and implemented methods
Yes, I know. I can see you rolling your eyes right now. Whilst this certainly isn’t a new concept and has been around for a number of years, you’d be surprised how several organisation seem to place everything in the default VLAN. I’ve inherited networks where the even the basic principles are not being used properly – if at all. For example, a Cisco switch has the default admin VLAN of 1. Common practice is every sense is to shut this down and use a different number. Again, this in itself is not a new or groundbreaking stance, but is often overlooked. A cyber criminal will attempt to interrogate all VLANs on a switch if they gain access to it. If the default VLAN doesn’t exist (or is shutdown), then at least one attack type is mitigated.
By not disabling VLAN1, you are essentially permitting wide open access to the control plane of your switching infrastructure. A cyber criminal or malicious actor would have the capability to perform a variety of damage such as spoofing superior BPDU configurations to invoke a root bridge change, leverage “VLAN hopping” to attack hosts on disparate VLAN, and spoof VTP advertisements to delete VLAN databases across the entire domain.
In addition, bridging control protocols have very weak security mechanisms if not addressed. The best advice for Cisco networks is to create a unique VLAN and apply it on every access port where a more specific VLAN isn’t needed. VLAN1 should always be removed from all dot1q trunks (including the “trunk allowed VLAN” commands). This works because Cisco switches will continue to send control protocols across trunks even when the native VLAN has been administratively removed. This has the effect of blocking user data from transiting the trunk while allowing BPDU configurations and other defined protocols to reach the connected bridge.
A classic example of fallout here is when interconnecting heterogeneous networks. For example, connecting two switches of differing manufacturers together can create a hidden vulnerability you never even knew existed. For this reason, it is always recommended to stick to one type of networking brand, and not a mixture. More information on hardening the IOS on Cisco switches can be found here.
The process of network segregation is surprisingly simple. It sounds complex, but really isn’t. What is more important here is it’s effectiveness. Segregation of a network is also commonly referred to as “zoning”. The concept is to split larger networks into smaller ones, placing various services and infrastructure into individual VLANS. The network itself can be homogeneous or heterogeneous, but by separating traffic this way, it is possible to permit and deny traffic entering and leaving each VLAN on a case by case basis. The general consensus behind this implementation is this example:
Let’s say you have 100 PC’s on one floor, with (for example), 10 machines in each “department”. In virtually all cases, machines from Accounting would not need direct access to Operations (and so on), so to reduce the impact of a potential malware or command and control attack, you should be placing each department in it’s own isolated VLAN. This effectively would limit the attack to those machines that were in the same VLAN – preventing it from spreading to other areas of your network. The one caveat here is application and file access. In the event of a ransomware attack, it’s highly likely that connected network shares would be included in the encryption process. In this case, whilst you are protecting other machines on your network by using segmentation, you still have the exposure of network shares. For obvious reasons, standard NTFS permissions and correctly structured shares can prevent an attack of this type from spreading beyond what the affected department actually has access to.
Segmenting a network goes one step further than segregation in the sense that the actual segmentation is handled by a physical interface (rather than virtual), such as a firewall. Again, the network can be homogeneous or heterogeneous, with traffic being policed by the firewall responsible for that zone. If two networks are separated by a firewall, restricting traffic over this link becomes much more effective, and in most cases, simpler to manage than ACLs on a switch.
Application Layer Gateways
An Application Layer Gateway (ALG) is a combined group of ports and protocols that serves to match traffic against an implicit rule base in order to handle the connection stream automatically. The idea of this is to provide a mechanism where traffic matching a specific type is automatically assigned the correct ports, services, and network discovery features to allow a seamless transmission. The ALG in principle is a great way of ensuring traffic reaches it’s destination using minimal configuration and effort, and in most cases, this works very well. However, there are pitfalls when adopting this route, as RTSP and SKINNY traffic for voice are known to fail if the ALG is responsible for the traffic but does not handle it properly. In addition, the ALG may open other undesired ports as part of the “suite” making for an arguably less secure environment than you had originally intended to create. In fact, an ALG can also be leveraged in an attack to gain access to another system by impersonating the traffic type. If you can get along without an ALG, disable it. If not, take the necessary steps to harden it with policies or rules. In most cases, further research is required in order to establish secure connectivity between devices without the ALG in place, but this investment in time is well worth it in the long run from the security posture and standpoint alone.
Several firewalls, switches, mail servers, and various other types of equipment make use of headers, or banners that in virtually all cases by default will expose the underlying device. In the case of Checkpoint
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ HTTP/1.0 404 Not found Date: Thu, 21 Oct 2017 17:17:50 GMT Server: Check Point SVN Foundation Conten-Type: text/html X-UA-Compatible: IE-EmulateIE7 Conenction: Close X-Frame-Options: SAMEORIGIN Last-Modified: Sat, 17 Jan 2015 19:00:00 GMT Content-Length: 204 <HTML> <HEAD> <TITLE>404 File Not Found >/TITLE> </HEAD> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
And in the case of Microsoft Exchange
220 <ServerName> Microsoft ESMTP MAIL service ready at <RegionalDay-Date-24HourTimeFormat><RegionalTimeZoneOffset>
Essentially, these banners provide far too much detail, and in the worst cases, would actually provide a wealth of information to any attacker looking to gain unauthorised access to the device. This tells the attacker exactly what the underlying device is meaning he or she would not have to waste time with a discovery via finger or similar methods of obtaining a device footprint. They already know what the underlying device is that they need to traverse, or find a vulnerability in, and can use that time in terms of investment to determine direct weaknesses or other exploits that will provide a means of access. The advice here is obvious – disable banners where possible, or at best, reconfigure them so that if they do have to be there, they provide inaccurate information to make an attacker’s life much harder.
I’ve seen some organisations use an A class subnet (16 million hosts) for a network that has 8 locations with 200 staff in each. Bearing in mind that an individual C class subnet has 254 host addresses, is this really necessary ? No – it isn’t. It’s also heavy in terms of overhead, and if you have broadcasts enabled between segments, then you could easily find your core switches overloaded with unnecessary traffic.
Some organisations use a large subnet to place devices into without considering the overhead. All networks make use of broadcasts, which are very chatty by nature. Broadcast messages contain a wealth of information that can easily be used to formulate an attack on your network based on the information obtained. As an example, WireShark can be used in promiscuous mode to listen in on traffic, and intercept packets sent between two hosts in separate subsets. Consider disabling broadcasts between your subnets to keep this threat to a minimum (as a side note, WireShark is often used to facilitate “Man In The Middle”). Potentially worse, excessive broadcast traffic can lead to a “broadcast storm”. This event takes place when messages are broadcast on a network and each message prompts a receiving host to respond by broadcasting its own messages on the network, thus causing more messages to be generated. Eventually, the switch fabric hosting this traffic can be “flooded” or overwhelmed to the point where the device can “hard lock” (lit up like a Christmas tree) and freeze completely requiring a power cycle in order to release. Broadcast storms are often the undesired result arising from faulty network adapters or infrastructure cabling, where the card or cable floods the network with packets.
However, broadcast and data storms also have their origins in intentional attacks with the desired purpose being the collapse of a network. Most vendors will detect this and provide preventative measures – only if it is enabled with the relevant firmware – I’ve seen this enabled on switches in previous roles, but the design left a lot to be desired, and it was the poor layout and ignorance to common standards that lead to these units being vulnerable to attack in the first place.
Consider the use of supernet scopes when designing a network. If you don’t need millions of addresses, then limit the subnet sizes to what you actually need.
Upgrade Firmware & Disable Insecure Protocols
Assess the firmware revision of all network devices on a frequent basis. Don’t leave switches running the same firmware as they were when they were first installed. The attack landscape continues to change dramatically (almost daily), and what was considered impossible literally “last week” is now very real in terms of being breached. Perform an audit of all other devices on the network to see if they should be considered vulnerable.
If you do have legacy systems that cannot be upgraded, and there is still a business need for this data or application, then take steps to physically secure it. Place it on a fortified VLAN, and only power it on if a user formally requests access to it. Switch off after use – if it’s not available, it can’t be compromised – logic. If your users argue that they need constant access to the “legacy” system in the long term, then is this really legacy ? During these types of discussion, I typically engage with business leaders to make the decision in terms of accessibility, but never security.
Part of any device audit in terms of security is the detection and removal of weak protocols – particularly those that provide some level of access. Protocols such as TELNET and SNMP (at versions 1 and 2) are considered vulnerable because everything they transmit is in clear text. Get rid of these and replace them with SSH and SNMP v3 (which offers security). In some instances, you could argue that your SNMP devices are not public facing so the risk of attack is mitigated. Wrong. If you are going to use older implementations of SNMP, then at least take the necessary steps to secure it with an ACL, use a read only community, and don’t even think about using “public” or “private” as the community names. Will an attacker go for these ? I would. You’d be surprised at what possibilities exist with RW (Read / Write) access via SNMP on a router, switch, or firewall.
Monitoring / SIEM Logging
If you haven’t already, implement a monitoring solution. There are plenty of open source applications that perform this function very well. One that immediately springs to mind is Observium. The free version is impressive, and the paid version (for a small fee per year) is even better. This product can provide a significant insight into your networks (at the operational layer), and can also provide a decent level of visibility in terms of odd activity during off peak hours. The trick here is to not generate alerts on literally everything. This in itself presents a danger of overload, and you’ll quickly find yourself in a situation where staff do not read the emails because there are far too many to digest. In this instance, an alert informing you that your email server is suddenly sending thousands of messages per minute out of business hours gets missed when it could in fact be an actual breach.
The Security Information and Event Management (SIEM) platform gives enterprise security professionals invaluable insight into and forensic track record of the activities within their infrastructure and environment. This technology has been in place for more than a decade, naturally evolving from log management basic principles. It essentially combines security event management (which records and inspects log and event data in real time to provide threat monitoring, event correlation and incident response) – with security information management (SIM) which collects, analyses and reports on log data.
The primary purpose of a SIEM is to provide readily available information on security-related incidents and events (classic examples of this are successful and failed logins, malware activity and other possible malicious activities) and to send alerts if the inspected information denotes that an activity run against a predefined set of rules indicates a potential security issue.
Each one of these categories can greatly enhance your security posture, but aren’t much use if they are poorly configured, or even worse, not in place at all. Whilst some of these may look complex, they are actually much easier to implement than they look. The list is also non-exhaustive, and several other mechanisms such as regular patching, software updates, and generally accepted “security hygiene” (in fact, 80% of security is best practice). In any case, I’d expect to find the vast majority (if not all) of the above on a adequately secured network.