Patching routing and switching infrastructure in any organisation is often delayed, sometimes due to the potential impact on production systems and sometimes because the IT resources are simply too busy fighting fires. Recent media focus on end point defence and the variability of end point operating systems has overwhelmed many of us. But we should not forget the basics, and gateway infrastructure should be reviewed at least quarterly.
Infrastructure reviews need to go beyond patching.
Rules which were added for a specific function long retired often hang around providing potential attack vectors for the bad guys. Access Control Lists, VLANs, authentication methods, redirection rules and interfaces should all be confirmed in a review as active and performing the function intended. Old rules and unnecessary configuration should be backed up to the configuration change control system (in some cases this might be just a directory on a network share, but a backup of the config before and after each change is critical) then removed.
While critical Security Advisories may drive gateway infrastructure upgrades, the infrastructure inside the network should not be forgotten.
If an attacker manages to enter the network and find an unpatched server or switch the impact of the compromise may be significantly increased! In a statement made to the US House Energy and Commerce Committee hearing in May, Gene Spafford professor at Purdue University and executive director of the school's Center for Education and Research in Information Assurance and Security said the recent breach of Sony's PlayStation Network was centred around servers "running on very old versions of Apache software that were unpatched and had no firewall installed".
Some devices continue to be shipped with default passwords and as part of an infrastructure audit all appliances, switches, routers and other networking equipment need to be checked for unchanged default passwords. Your vendor can provide default password advice and your systems integrator should be able to prove that passwords were changed during the installation process.
Vendors such as Cisco even provide guides to hardening Cisco IOS and NX devices.
These guides go into large amounts of detail and while the format is perhaps a little unwieldy, the information provided is very relevant to an infrastructure review. By way of example, the following extract is from the NX-OS hardening guide.
This section deals with IP Fragments, often used by hackers to perform DDoS attacks, confuse IDS systems and defeat packet filter security policies.
Filtering IP Fragments
The filtering of fragmented IP packets can pose a challenge to infrastructure and security devices alike. This challenge exists because the Layer 4 information that is used to filter TCP and UDP packets is present only in the initial fragment. Cisco NX-OS uses a specific method to check non-initial fragments against configured ACLs. Cisco NX-OS evaluates these non-initial fragments against the ACL and ignores any Layer 4 filtering information.
This approach causes non-initial fragments to be evaluated solely on the Layer 3 portion of any configured access control entry.
In this example configuration, if a TCP packet destined for 192.168.1.1 on port 22 is fragmented in transit, the initial fragment is dropped as expected by the second access control entry based on the Layer 4 information within the packet. However, all remaining (non-initial) fragments are allowed by the first access control entry, based completely on the Layer 3 information in the packet and the access control entry rules. This scenario is shown in the following configuration:
ip access−list extended ACL−FRAGMENT−EXAMPLE
permit tcp any host 192.168.1.1 eq 80
deny tcp any host 192.168.1.1 eq 22
Due to this non-intuitive nature of fragment handling, IP fragments are often inadvertently permitted by ACLs. Moreover, fragmentation is often used in attempts to evade detection by intrusion-detection systems. For these reasons, IP fragments are often used in attacks, and so they must be explicitly filtered at the top of any configured iACLs. This example ACL includes comprehensive filtering of IP fragments. The functions in this example should be used in conjunction with the functions in the previous examples.
ip access−list extended ACL−INFRASTRUCTURE−IN
! !−−− Deny IP fragments using protocol−specific ACEs to aid in
! !−−− the classification of attack traffic !
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
! !−−− Deny all other IP traffic to any network device !
deny ip any <infrastructure−address−space> <mask>
! !−−− Permit transit traffic !
permit ip any any
Cisco's Russ Smoak, Director of Security Intelligence Operations also provides the following tip.
"The Cisco Security Centre is our primary vehicle for delivering time-sensitive security collateral. It hosts pages dedicated specifically to Best Practices and Service Provider Security Best Practices that contain categorised lists of documents that describe security techniques and practices."
Smoak believes a regular review and update schedule has many component parts and advises it may be wise to coincide a review with the official Cisco IO Software Security Advisories, which are released twice-yearly. There are a number of systems integrators and security consulting organisations who can provide infrastructure audit services.