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
Change Control
Logging and Time synchronization
Name user accounts (often using a back-end directory for authentication)
Encrypted administration protocols (no more telnet ! )
Verify boot Images before installing, and periodically after
Periodically update to remediate security exposures
Harden the device using a public or custom Benchmark (yes, even Firewalls are not hardened out of the box)
Audit the final configs against the Benchmark
 

Hardening Steps
We've had numerous diaries on this, on this, including (please let me know if i've missed any, I've only included the ones I could remember)

• Logging  ( https://isc.sans.edu/diary.html?storyid=6100 )
• Implementing ARP inspection to prevent Man in the Middle Attacks (use with caution) ( http://isc.sans.edu/diary.html?storyid=11650 , http://isc.sans.edu/diary.html?storyid=7567 )
• Implementing DHCP Snooping to prevent Rogue DHCP Servers (usually these home routers gone bad, but they can be real attackers too) ( http://isc.sans.edu/diary.html?storyid=7567 , http://isc.sans.edu/diary.html?storyid=8233 )
• Implementing encrypted management protocols - ie stamping out telnet and http, and migrating to sshv2 and https ( http://isc.sans.edu/diary.html?storyid=11434 )

There have also been some recent papers in the reading room on scripting capabilities on routers, which can also be exploited:

• Using routers for port scanning and reconnaissance (IOSMAP) ( http://www.sans.org/reading_room/whitepapers/tools/iosmap-tcp-udp-port-scanning-cisco-ios-platforms_32964 )
• Bypassing or hijacking firewall functionson routers (IOSCAT) ( http://www.sans.org/reading_room/whitepapers/tools/iosmap-tcp-udp-port-scanning-cisco-ios-platforms_32964 )
• Using routers to host malware (yes, really !! ) ( http://www.sans.org/reading_room/whitepapers/malicious/iostrojan-owns-router_33324 )

(note that forcing signature of scripts is the remediation for all of these)

Looking for specific documents that you can use as Benchmarks to Audit or as Guides in hardening your infrastructure?  The most common ones referred to are:

• CIS Router Benchmark ( http://benchmarks.cisecurity.org/en-us/?route=default )
• CIS Switch Benchmark ( http://benchmarks.cisecurity.org/en-us/?route=default )
• CIS Firewall Benchmarks ( http://benchmarks.cisecurity.org/en-us/?route=default )
• RFC 3871 - Operational Security Requirements for Large Internet (http://www.faqs.org/rfcs/rfc3871.html )

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.

Don't neglect vendor documentation in your efforts (Cisco, Brocade, Extreme, Juniper and all the rest).  Vendor docs will include their own security and hardening guides and documentation - in many cases the same recommendations are covered, but the specific commands will of course vary from vendor to vendor.  In other cases, they'll have security guidance that is specific to that vendor's features, platform or technology (fiber channel for instance will have quite different security guidance compared to ethernet)

Examples
Some example config lines for common recommendations (cisco syntax is covered, most other vendor's syntax is pretty similar, check your documentation and assess for impacts in your environment before implementing any of these blindly).  Note that these examples do not constitute a complete hardening guide (use the links above for that), they fall into that low hanging fruit category, things that are easy to change that will make a significant difference.

NTP (Network Time Protocol)
On most gear, setting up NTP for time sync is dead easy.  In most environments, you'll have a redundant pair of routers or switches that you can set up as the main NTP servers for the infrastructure (other sites might use Linux or Unix hosts, or dedicated timeserver appliances).  Normally these get 2 "reliable" NTP time sources (often we'll pick 2 unrelated, reliable NTP servers on the 'net - dedicated NTP servers will often have an atomic clock on board).  Everything else in the environment will point back to these hosts for their time.

ntp source GigabitEthernet0/0.1           ! setting the source is optional but recommended
ntp server 203.0.113.1
clock timezone EST -5
clock summer-time EDT recurring

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   
logging buffered 8192 debugging
logging 203.0.113.10
logging source-interface GigabitEthernet0/0.1      ! also optional but recommended

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:

radius-server host 203.0.113.209 auth-port 1645 acct-port 1646 key <some key>
radius-server key <some key>
ip radius source-interface GigabitEthernet0/0.1           ! optional

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
aaa authentication login default group radius local

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
  permit 203.0.113.0 0.0.0.255
  permit 198.51.100.7

hostname routername
ip domain-name domainname.com     ! need an FQDN to define RSA keys
crypto key generate rsa general-keys modulus 2048      ! be sure to set a decent length
ip ssh version 2                      ! be sure to force SSH v 2

line vty 0 15
transport in ssh                    ! force SSH only
access-class ACL-VTY-IN             ! enforce mgt station ACL

Backups:
Let's say you want to backup your routers or switches daily (or Fiber Channel Switches, or Firewalls, really anything that has a decent CLI).  While we're at it, let's back up the version info, and also the md5 hash of the OS image to verify it's integrity (yea, I know all about md5 collisions, but md5 hashes are what we have to work with on this platform).  We'll use plink (the text based putty client) to collect the data via SSH:

plink –l %1 –pw %2 %3 “sho ver”  >inventory\%3_inventory.txt
plink –l %1 –pw %2 %3 “sho config” >> inventory\%3_inventory.txt
plink –l %1 –pw %2 %3 “verify /md5 flash:/c2800nm-advipservicesk9-mz.124-8.bin” >> inventory\%3_inventory.txt

where:
%1 is the userid
%2 is the password
%3 is the ip address or resolvable name of the device
%3 is also used for the filename.  You could get fancy and include a date / time stamp in the filename as well.

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:

Now that you have your configurations backed up, you can run DIFF reports to see any changes from yesterday.

• Where the changes made approved in your change management procedure (oops, that's a good thing to have too!)
• Did the changes happen in the approved time? Did the change run long, or was it just plain applied outside the change window?
• Did the approved changer make the change (the person who made the change should show up as a named user in the log, both when they logged in and when they made the changes)
• If it's NOT an approved change, who made it (ditto, you'll see their name in the log)
• And finally, now that the change is complete, does RAT indicate that you may have weakened your overall security posture?  Note that RAT audits you against the CIS Benchmark(s) - if you use a different hardening standard, you'll need either a different tool or script, or some manual translation to make the final call on this.  Note also that RAT is for audit, it's not a full security assessment tool - you'll need different tools for a full security assessment.

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
Metafore