http://www.sans.org/critical-security-controls/control.php?id=4 Hardening network infrastructure is an often overlooked step. For some reason, switches and routers often fall into the category of "it works, we must be done". Or, if it was hardened when installed, it'll be checked off as "done" (as in "done forever"). If you think about it, your routers, switches and firewalls touch *everything*. We really should put a sustained effort into securing these devices as vital parts of the infrastructure. Don't limit yourself to routers, switches and firewalls in this - be sure to include Fiber Channel switches, Load Balancers, IPS servers and appliances (yes, i see these get missed all the time! ) in this category also This sustained effort should have all the usual suspects: Backups Hardening Steps
There have also been some recent papers in the reading room on scripting capabilities on routers, which can also be exploited:
(note that forcing signature of scripts is the remediation for all of these)
The CIS Benchmarks have an advantage here, in that they also have an assessment tool to compare, audit and score a captured configuration against a benchmark. ntp source GigabitEthernet0/0.1 ! setting the source is optional but recommended
Similarly, logging everything back to a common syslog host is usually a one-liner (or close to it) service timestamps log datetime localtime show-timezone Setting the source interface for NTP, syslog and the rest is important, if you don't and a backup link is activated, the source ip address for these will change and potentially mess up any log management you may have in place. Note that the souce interface should either be a loopback, or some interface that will always be live (in this case it's a WAN router, I used the inside interface) Also, the decision about what timezone to use in logging can also differ from company to company. If the entire network resides in a single company, normally local time is used (as is seen above). However, in larger organizations the span multiple timezones, a single timezone for all equipment can make troubleshooting a lot simpler. In cases like this, it is common to see all the network gear log in GMT (Greenwich Mean Time), with the SYSLOG server perhaps adding a local timestamp to make it easier for the admins to find things in the Gigs of logs. Using GMT is the recommendation in most hardening guides. In other organizations, all gear will be sync'd to the timezone that "head office" is in. This accomplishes the same thing, but troubleshooting individual gear can get complex, especially if you are also factoring in information from end users who are in that timezone. Because of these varying perceptions of "what time is it?", it's generally best to operate in GMT, and have the gear report its timezone in the log entry (Thanks Don for highlighting this omission in the original story) Tieing back to an external authentication source is a bit more complex, but it's usually only a few lines on the infrastructure gear - If your back-end is AD, your authentication server is probably Microsoft IAS or NPS, and your config lines will look like: First, set up a RADIUS host that you have already configured for this: Note again the source-interface thing. If you miss this in RADIUS and another interface gets used (backup route activated or whatever), RADIUS will break unless you have all possible IPs defined on the RADIUS host - it's just way easier to use source interface commands. Next, set up AAA (Authentication, Authorization, Accounting): aaa new-model once the login part is done, let's secure the remote admin access access-list standard ACL-VTY-IN ! define authorized mgt stations and subnets hostname routername where: I tend to use plink to collect input for RAT, as opposed to the SNARF method in RAT (which uses telnet). This example is on Windows (putty / plink), but you can certainly write a similar script on Linux or OSX. Note also that there are tools out there that do exactly this (CATOOLS, RANCID). Let's combine all of this (NTP, SYSLOG, AAA Back-end Authentication, config backups) to illustrate why this is all important, and how it all inter-relates:
Again, this diary is all about catching the easy stuff that we see gets missed all the time - for complete set of things to consider, including procedures, use the Hardening Benchmarks, or define your own benchmark for a more complete picture that encompasses your organization's business requirements, policies and procedures. If I've made any errors or especially typos, please use our comment form to set me straight ! More importantly, please use our comment form to let us know what you do in your environment - any tips or war stories are very welcome ! As always, our comment form is open 7x24.
PS - As an FYI, all IP addresses in this story are formatted as per RFC 5737 ( http://tools.ietf.org/rfc/rfc5737.txt ), which reserves specific IPv4 address spaces for documentation
|
Rob VandenBrink 578 Posts ISC Handler Oct 6th 2011 |
Thread locked Subscribe |
Oct 6th 2011 1 decade ago |
It should be noted that CIS-RAT is out of date for the current CIS benchmarks. You will get invalid results using this tool.
A replacement is in beta testing. |
Anonymous |
Quote |
Oct 6th 2011 1 decade ago |
I think other devices such as modem/ISDN, Wifi router/switches/repeater, printers, should be included here too.
|
Anonymous |
Quote |
Oct 7th 2011 1 decade ago |
I think other devices such as modem/ISDN, Wifi router/switches/repeater, printers, should be included here too.
|
Anonymous |
Quote |
Oct 7th 2011 1 decade ago |
The nice thing about an unmanaged switch is there's nothing to take over.
|
Anonymous |
Quote |
Oct 7th 2011 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!