LARG*ncm: beyond the hardening guides.
Welcome back to the NCM adventure! Not only have we achieved our original goals but we keep extending the project’s functionality. This continuous improvement could spawn its own blog series but either way we end up with a great system. The question is now and always: how can we improve more?
Recommended Software Versions
Recommended software version is now a manual check you can run from the versions page. So far our managed devices are the only supported hardware models but the foundation is there for Cisco, Ruckus/Brocade, and Juniper devices. Adding new devices to this list will be easy.
The underlying technique is similar to web scraping since I scrape a link to the firmware download page so NCM can auto select the recommended software version. Some websites make efforts to restrict scraping which makes HP/Aruba fairly challenging. This is an ongoing project as there are many models of network devices this feature doesn’t currently support.
Special shout out to Cisco for making this process extremely easy! They use a specific URL to reroute you to the selected release and there’s a label on the recommended version in the page’s source code. Awesome!
Time zone Selection
I added a time zone selector on the settings page. Our membership is entirely in the Eastern time zone so I hard-coded it at first. Now people all around the flat earth can set their own time zone appropriately. Perhaps your organisation prefers to work in GMT? It’s a minor change but an improvement none-the-less.
Beyond the Hardening Guides!
Hardening guides are vendor-specific documents that outline all the generic best practices for your devices. They can include general tips like disable unneeded services to specific configuration (no ip http server) to protocol preference (SSH instead of telnet, HTTPS instead of HTTP). Every organisation should use them when initially configuring a device or embarking on a security tune-up since following these guides is a great way to improve your security maturity. LARG*ncm makes applying hardening guides easy as it audits your existing config while cross-referencing the appropriate hardening guide for it. There’s always new information coming out and changes that don’t invalidate the hardening guide but do allow for improvement.
Take cryptography as an example. It is a moving target right now due to the emergence of quantum cryptography. I created a rule that checks for what SSH cryptography is in use and will evolve this rule as quantum resistant crypto replaces the current recommendation. This kind of natural evolution is fairly easy to keep up with.
The real weakness of hardening guides is that they are generic by default. They can tell you to secure access to your devices by only allowing authorised hosts/subnets but they can’t tell you which hosts/subnets should be authorised. Some rules require context and context is organizationally and occasionally device specific. We quickly realised we need a way to add context to the system to take the security reports to the next logical useful level.
Context Page
The context page is brand new. I created it to address the main weakness I encounter time and again working through hardening guides: they lack necessary context and include or exclude some config arbitrarily. The context page allows you to make environment-specific exceptions to the hardening guide check.
For example: we flag any instance of ‘permit ip any any’ that appears in a Cisco firewall config because it’s usually a sign that ACL has been misconfigured. However Sourcefire policies may use ACLs but they aren’t the average static packet filter you tend to find on a firewall. Very often those lists legitimately include ‘permit ip any any’ since they want to send all (or as much as possible) traffic through the IPS. With this in mind, the first context rule covers SFR ACLs and exempts them from the ‘permit ip any any’ check.
A context page example showing a rule exempting ACLs named ACL_SFR_REDIRECT from the ACL checks. Other possible exemptions can be made for certain IPs for SSH access and protocols.
SSH ACLs
The context page also covers exceptions for SSH access. This is another difficult rule to evaluate since from a security point of view you should audit what can access your devices but this will be different for every organisation and potentially also for individual devices. How can we make the system do that?
The security reports pull the ACL assigned to VTY/SSH access and evaluates it. The tricky part is against what since the system doesn’t know what should be in the list. It can look for static entries like ‘permit any any’ but it won’t know what individual devices/subnets should be there without your help. The context page allows you to input IPs/subnets in CIDR format to be used in the evaluation. The resulting security reports alert you to entries outside the list that don’t match what you’ve added to the context page.
We are moving past typical hardening guides into the realm of customized audits but these are checks worth doing, especially if you manage many devices. It’s easy to miss stale, possibly compromising, entries when you manage many devices so we decided this feature was a must have!