Maximise the benefits of your Pen Test
In this second part of our occasional series ‘Make the most of your Pen Testing‘ by our cyber security specialist Tom Sherwood, we help you take care of some security basics ahead of your pen test. This way, your consultant will have more time to focus on the trickier elements of your information security.
In this post we look at 5 ways you can carry out simple hardening of your firewalls. You can catch part one here: Top 5 tips for Hardening your Servers
1. Keep Your Firewalls’ Operating Systems Updated
Assuming your firewall is deployed and filtering traffic as intended, keeping your firewalls’ operating systems patched and up-to-date is probably the most valuable security precaution you can take.
This ensures that your devices are patched and protected against any published vulnerabilities that could allow an attacker to:
- Gain management access to the devices
- Bypass filtering and pass unauthorised traffic through the firewall
- Knock over the firewall and create a denial-of-service condition (where no traffic is permitted through the devices)
In a recent incident, it was found that some Juniper Firewall devices had built in back door access to certain firewall operating system versions. Consequently, all devices running the affected operating system versions could be accessed and administered by anyone using the built in credentials.
To avoid these risks, subscribe to the security advisories published by your vendor and update your devices to the latest relevant stable release on a regular basis. Use only supported products and platforms, and cease use of unsupported or end-of-life versions.
2. Configure Strong & Non-Default Passwords
Nowadays it’s safe to assume that access to key systems like firewalls will be protected by password authentication to prevent unauthorised access.
Our pentesters frequently encounter firewall and network administrators who have neglected to change default or blank passwords, or set strong passwords. This can leave firewalls open to password guessing attacks which can enable an attacker to gain remote management access to the device in short order.
Ensure that all default and blank passwords are changed to suitably strong values. As a minimum we recommend 10 characters in length, containing a mix of lower and uppercase letters, numbers and special characters.
See that passwords are not re-used between devices and where passwords appear within configuration files, they are listed in encrypted and non-reversible form.
For Cisco devices, wherever possible avoid the use of Cisco Type 7 encoded passwords and use md5 encrypted secrets instead.
3. Configure Suitable Remote Management Access
The likelihood is that only authorised personnel in your IT department require to log in and remotely manage devices. For this reason, many firewalls allow configuration to restrict management access to specific interfaces, network ranges and even IP addresses.
By confining management access to internal/trusted network segments, and preventing access from the wider internal network estate or internet, you can vastly reduce the potential threat from password guessing type attacks and other attacks against management services.
Once the the availability of management services is secured, take care that the management services themselves are fit for purpose. Here our testers generally look for protocols that utilise suitable authentication and encryption. As such, un-encrypted management protocols such as Telnet, TFTP, FTP, SNMP prior to version 3, and HTTP should definitely not be used.
Using HTTPS or SSH for management is highly recommended, preferably configured to use strong ciphers.
4. Harden Your Rule-base
So, now you have a working rule-base, everyone is happy and can do what they to need to unhindered. However, you have a nagging feeling that some of the problems discussed here might have played a part in the past. What can you do? The answer is to bite the bullet with a deep audit of the rule-base. Here are key points to consider:
- Understand and document why each rule exists within the rule-base. If a rule has no purpose or is no longer relevant, remove it.
- Be miserly with your source and destination stipulations. Where possible aim for a granular level of control and limit the groups of hosts or networks you’re dealing with to no larger than a /28 network, which is the equivalent of 14 hosts. Ask yourself does that whole network need access to this resource, or does this host require access to all my servers, or just specific hosts. The more you can limit access the better, as this makes it harder for malicious employees, or attackers who have socially engineered their way inside your premises, to set up rogue hosts to attack your network.
- Apply the same miserly approach to services. Restrict firewall rules to allow traffic to specific destination ports/services. For example, if a group of users need access to an internally hosted web application on a linux server but don’t need to login and manage the server, they should only be permitted to route traffic to the server’s HTTPS port (443/TCP). All traffic from that group of users to the SSH service (22/TCP) should be dropped.
- Wherever possible, do not use clear text protocols within your internal environment; use firewalling to enforce this. Consider where clear text traffic allowed through the firewall could be swapped for an encrypted alternative.
- Securely log all relevant or dropped traffic to a designated logging server. In the event of a security breach, some of it could yield crucial forensic information.
5. Undertake Regular Rule-base Housekeeping
Large rule-bases in complex environments can be confusing, and their administration onerous. Regular housekeeping of the rule-bases can go a long way to reducing mistakes such as unauthorised permission of traffic through the firewall. During your housekeeping, ensure that:
- The purpose of all rules is understood and documented. Review the provisioned access and remove unnecessary rules.
- There are no overlapping or duplicate rules. This means that should access need to be removed, action is only required in one place, rather than amending multiple rules.
- Review temporary rules and either remove them or make them permanent if the requirement will be ongoing.
If you would like Advania to manage your Penetration Testing, or if you need support with any aspect of your information security, you’re welcome to contact us.
