phillips321.co.uk

So it grinds my gears that every time I do a pentest I end up reporting the same sh!t every time. You’d think before I turn up you’d at least patch your kit, but nope!

Here’s a little Top 5 for sysadmins, project managers and security controllers to consider doing before I break their kit. And this relates specifically to infrastructure kit, if it’s a web application that I’m testing I strongly suggest you read this post as well; Things to do before a pentest – web application.

1. Updates! And we’re not just talking about OS updates, we’re also talking about software updates and anti virus definitions. It’s no good having fully patched Windows device if you’ve then got firefox version 10 installed along with an AV virus definitions database dating back to 2010. Look to install a WSUS in your environment to keep the Microsoft devices up to date and ensure a process is in place to update installed software components such as Apache Tomcat, Mozilla Firefox, Adobe Reader and Oracle Java.
2. Encrypted Services. So this covers services like HTTPS, RDP and more. Ensure that you’re SSL services do not support SSL version 2, do not support weak ciphers (generally anything <128bits is considered weak) and use a reliable and trusted valid certificate (signed using a hashing algorithm such as SHA256 and a trusted Certificate Authority). And this also means not using insecure services such as Telnet, FTP and rlogin!
3. Account lockdown. There’s no point having up to date systems if an attacker doesn’t need to exploit anything other than weak accounts. Use a password policy! All passwords should be using a complex mixture of UPPERCASE, lowercase, numeric and special characters (this includes SNMP community strings) and that passwords are changed frequently. Ensure users do not share accounts, and that each account is appropriately locked down to limit access to nothing more than the account needs (i.e. does a basic user need the ability to write to the root of the C: drive?).
4. Network protection. Great, you’ve gone and installed an all signing, all dancing and cutting edge firewall, but; what’s the point if you’re not using it correctly? That IPS you paid out for is being used as an IDS? Pointless! That firewall is simply acting as a routing device? Pointless! That managed switch is simply acting as a dumb switch? Pointless! Ensure that where protection functionality is available that it is being used. This means creating firewall rules on a per service basis and destination basis, don’t group too many rules into one rule, break them down; and never use an ANY:ANY rule! That IPS needs to be configured to correctly understand your valid network traffic and what to do when it sees bad traffic, and make sure it’s INLINE! And that managed switch that you installed, make sure it’s being used properly, disabled unused ports, enable port security (sticky MACs ect) and segregate your traffic into different VLANs!
5. Auditing. Lets just say you have been hacked, how are you going to identify what happened and what’s been lost? Networking devices offer logging functionality via syslog and/or SNMP so this should be enabled but auditing and event logging should also be performed and remotely mirrored on server devices such as the event log in Windows and the /var/log folder on unix devices.