The good news is there are resources available to anyone and are provided by Defense Information Systems Agency (DISA) which is a government agency that is part of the Department of Defense (DoD). These guides are separated into two different types: One set is called Security Technical Informational Guides (STIG) and the other is called Security Checklists.  These guides are developed to provide guidance for people who build and manage DoD networks.  They are also used in audits performed within Department of Defense networks.

None of the DoD offered materials has anything to do with HIPPA, PCI, SOX, etc. on the surface, but the thing they do have in common is they are focused on security best practices.  In my experience dealing with HIPPA, PCI, SOX, and DoD networks, using these guides as a reference to secure a network or platform will cover 90+% of anything that would come up in a HIPPA, PCI, or SOX audit.

These guides are available publicly to anyone and are considered unclassified material in their currently offered form.

Use the following link to browse the security checklists, find one that addresses your area of interest and download.  All unpacked files are in .pdf format.

http://iase.disa.mil/stigs/checklist/index.html

Cisco even provides a utility in most newer versions of the IOS to help secure the platform.  This feature is called auto secure and was introduced in version 12.3(1).  The auto secure utility goes a long way in helping the administrator configure a secure IOS device.  This article will contain many of the things the auto secure utility will implement and more, along with hopefully explaining what each command is accomplishing.

The configuration items are grouped into categories, to better separate the purpose of each.

Securing Access to the Router

!
! Do not leave any unencrypted passwords in the IOS configuration
!
service password-encryption
!
! Configure a secret password which takes the place on the enable pw
! Remove the enable pw completely after secret is configured
!
enable secret ^Pr3tty53cr3tpa55w0rd!
no enable password
!
! If no external authentication server is being used then configure
! local username/passwords in the configuration.  Don't just use
! vty or secret password for telnet access.  In this example,
! configure a user called admin with level 15 access and associated secret
! password which is stored in the configuration as a type 5, which currently
! can't be reversed (as apposed to type 7 passwords that can be un-encrypted)
!
user admin privilege 15 secret ^n0th3r53cr3tpa55w0rd!
!
! Enable AAA on the device which allows aaa commands to be configured
!
aaa new-model
!
! Create an authentication list named Admins that authenticates against
! locally configured users
!
aaa authentication login Admins local
!
! Tell the router to consider the priviledge level configured for each
! locally defined user
!
aaa authorization exec default local
!
! For console logins, use the authentication list called Admins
!
line con 0
login authentication Admins
!
! For telnet/ssh logins, use the authentication list called Admins
!
line vty 0 4
login authentication Admins

Disable unnecessary services on the device

!
! Disable the bootp server
!
no ip bootp server
!
! Disable the http server
!
no ip http server
!
! Disable the finger server
!
no ip finger
no service finger
!
! Disable Packet Assembler/Disassembler for X25
!
no service pad
!
! Disable echo discard daytime chargen
!
no service udp-small-servers
no service tcp-small-servers

Other

!
! Use the real date and time on all logging and debugging output
! as apposed to the device's uptime
!
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
!
! Set logging to the internal buffer and make it large enough to hold
! log entries without being lost due to wrapping
! because of the small default buffer size
!
logging buffered 16384
!
! Set local timezone and DST if observed
!
clock timezone CST -6
clock summer-time CDT recurring
!
! Just about all company legal departments want this used
! This will display when the device is accessed (before authenticating)
!
banner login ^C
Authorized Access only
  This system is the property of Xpresslearn.
  UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED.
  You must have explicit permission to access this
  device. All activities performed on this device
  are logged. Any violations of access policy will result
  in disciplinary action.^C
!
! Don't try to obtain a configuration via tftp at device boot
!
!
no service config

Let’s look at this another way: What kind of damage could someone do to your network if all they were armed with was a standard pc and access to the internet. The answer is obvious, however let’s get more specific. What if your network contained an unsecured switch port, a routing protocol running with no type of authentication, or what about a gateway redundancy protocol (HSRP, VRRP, etc.) that was unsecured? How about a lan without a proper spanning tree configuration? Well, the answer should still be obvious, there are a gazillion sites with utilities that run on a PC with the capability of interacting/disrupting a network with the previously stated issues. With all of that said, let’s ask ourselves a different question:

How much easier (than the previous scenarios) would it be to damage my network if someone walked into the office with a Cisco router under their arm and was able to sit down and plug it into the network? Again, without wanting to sound like a broken record, the answer should be jumping out of the screen at you – but maybe at a little more alarming rate than before. How about a little demonstration? I am about to show you in less than 10 easy steps how that Cisco router can be carried through the door and plugged into the network. Before you ask, no magic will be taught here, that will be left to the experts. Let’s get started:

1. Download Dynagen from http://dynagen.org/ and install
2. From the start button (Windows) , In the newly created Dynagen folder, click on Network Device List
3. From the generated list, Pick out the installed network adapter that connects your computer to the Local Area Network. Once found, copy the appropriate device string to the clipboard, beginning with NIO_ and select all the way out to the end of the line before copying.
4. Download this file and unzip it into the \Program Files\Dynagen\sample_labs folder. Open the sw1.net file in a text editor and do a search for the string NIO. Once found, select and replace the entire existing string in the file beginning with NIO by pasting your computers specific string from the clipboard. Save this file and exit the editor.
5. Download from Cisco’s website the IOS file named c3640-js-mz.124-18.bin . The simplest way to do this is to login to the Cisco site with your CCO ID (required), go to the download area and type in this file name in the Software Search box. Once downloaded, browse to the Dynamips installation directory and move this file into the sample_labs\XpressLearn\ios folder
6. Fire up the Dynamips Server by clicking on Start –> Dynagen –> Dynamips Server (We are getting close, feel the anticipation?).
7. Go back to the folder containing the sw1.net configuration file and right click on the file –> Open with –> dg-local
8. In mere moments, a new window should appear and you should see a greater than prompt (=>) below the words ‘Dynagen management console for Dynamips’. At the prompt, type start SW1 and when returned back to the prompt, type telnet SW1.
9. A telnet window should appear and within a few seconds wallah! A Cisco router is booting inside the telnet window.

Now, in less than 10 easy steps, you have a Cisco router that is bridged to a network that the PC your sitting in front of is connected to. Again, you have a bridged connection between the ‘virtual’ Cisco router and the network which the hosting pc is connected to. What does this mean you ask? For all practical purposes, there is a Cisco router (which is completely under your control) plugged directly into the network your PC is connected to. The virtual router is not using the hosting PC to hide behind, there is no natting, routing, etc. going on to get this router communicating to the live network. Dynamips uses a shim that sits between the network adapter in your PC and the operating system. This same shim is what is commonly used by sniffer programs to provide full viability to all traffic on the network. Why am I making such a fuss about this? There is a layer2 connection between the network switch in a wiring closet somewhere and your virtual Cisco router.

Some may ask, well what can I do with this after all the trouble of setting it up? The answer: just about anything you could if it were a real Cisco router connected to the network with direct console connection to it. Let me show you something ‘real’, but before I do, I must stress no networks were harmed in the making of this article. This was a highly trained individual performing a precise exercise to demonstrate the realities of what is described in this article. Ok, with no further jabbering:

SW1#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

BNADC-SW-01.xxx.net

                 Fas 1/0            140         T S       WS-C3548- Fas 0/45

Hmmm, this virtual Cisco router is swapping CDP information with an access switch. That’s pretty interesting…

Just by looking at the IP address of the PC running Dynamips you already know the subnet allocation for the vlan your virtual switch is connected to. This means you can try and pick out a static IP on the same subnet that is not used by anything else or, let’s try this instead of guessing:

SW1(config)#interface Vlan1
SW1(config-if)#ip address dhcp
SW1(config-if)#end
SW1#
*Mar  1 00:04:50.611: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:04:54.715: %DHCP-6-ADDRESS_ASSIGN: Interface Vlan1 assigned DHCP
address 10.32.20.238, mask 255.255.255.0, hostname SW1

Yeah, that will do it… Now my virtual router/switch has a valid IP assigned on the network. Gee wiz, is there much more I can figure out on my own? Dynamips can sniff the traffic flowing through interfaces inside of Dynamips instances. Let’s turn on capturing for a couple of minutes and see what happens:

After giving a few minutes to capture, you can stop the capture so that the file can be opened and viewed in a sniffer program. To stop the capture simply type: no capture SW1 F1/0. Open up the sw1.dmp inside of your sniffer program, the first thing I see is some EIGRP hello packets – Let’s take a look:

Here is the EIGRP packet which came from our default gateway (which of course is the router) and if we look closely, the Autonomous system number is contained inside the hello packet. So, we have discovered EIGRP running in autonomous system 20. What do you want to be there is no authentication being used in the routing protocol process? Let’s give this a shot:

SW1(config)#router eigrp 20
SW1(config-router)#network 10.32.20.0 255.255.255.0
SW1(config-router)#no auto-summary
SW1(config-router)#end
SW1#
*Mar  1 00:16:39.179: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.32.20.1 (Ethernet1/0)
is up: new adjacency
*Mar  1 00:16:39.871: %SYS-5-CONFIG_I: Configured from console by console
SW1#
SW1#sh ip eigrp nei
IP-EIGRP neighbors for process 20
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.32.20.1            Vl1               11 00:00:47  441  3969  0  26626
SW1#
SW1#sh ip route summary
IP routing table name is Default-IP-Routing-Table(0)
IP routing table maximum-paths is 16
Route Source    Networks    Subnets     Overhead    Memory (bytes)
connected       1           0           72          136
static          0           1           72          136
eigrp 20        77          831         65376       123488
internal        106                                 122536
Total           184         832         65520       246296
SW1#

Wow, all of a sudden I have a route table with 831 more routes in it. At this point it would be very easy to inject a host route into the EIGRP routing process. The purpose of this would be so that a host could be impersonated by another computer. By injecting this specific route, you can direct all traffic to an unintended destination, which allows you to capture all sorts of sensitive data.  Even by taking just a passive approach by not manipulating EIGRP at all, it has provided us a map of the entire network with the route table.

The possiblities are endless – maybe the virtual switch get’s configured for HSRP after you figure out what group number is being used. Then set a priority that allows all the traffic to flow through your router before it goes back out to it’s destination. Granted, the Dynamips instance probably wouldn’t hold up because of the low forwarding rate, but there could be some damage done before it dynamips crashed.

Enough about layer3 stuff, what about spanning tree? We do have a switch module installed, thus we are running spanning-tree. Assuming Per-Vlan spanning tree running on the network, we could at least become the root bridge for the access vlan we are a member of.

SW1#sh spanning-tree root
VLAN1
  Root ID    Priority    8273
             Address     00d0.636e.cc00
             Cost        23
             Port        41 (FastEthernet1/0)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Wow, all we have to do it set our spanning tree priority for the vlan1 that is configured on the virtual switch to a priority less than 8273. Once that change is made, now all the traffic on that vlan is flowing through a port on the virtual switch to get to it’s destination. Oh, and hopefully there is no way to get connected to a port on the network that allows trunking and especially one that allows trunking with no restrictions on vlans passing through that trunk port. My My, once a trunk port was established to our virtual switch, we could really get crazy by setting up a VTP server and manipulate the version to a really high number, then wipe out all the vlans on the entire network (assuming vtp is running on the network).

When this article began, the point was to sell making your network more secure. The entention of this entire exercise was to enlighten on how much easier it becomes to be disruptive when you have (and control) a router/switch that can be plugged into a network. Please, don’t take this article as a how-to for disrupting networks – that is certainly not the intention.

In another article, I will specifically describe how to configure a network to combat against every one of the examples mentioned in this article.

This isolation can be accomplished through the use of private vlans. For this example, let’s assume no one host needs to communicated with another in the DMZ network. The only common communication needed between hosts is access to the network gateway, which in this case, would be a firewall interface.

The solution would be to implement private vlans. There are two vlans required, one to be used for a primary vlan and the other to be used as the isolated vlan. They would be defined in the following matter:

switch#config t
switch(config)#vlan 100
switch(config)#name Isolated_SysBackup
switch(config)#private-vlan isolated
switch(config)#vlan 101
switch(config)#name Primary_for_isolated_SysBackup
switch(config)#private-vlan primary
switch(config)#private-vlan association 100

The two previous vlans are needed for this basic private vlan implementation. One vlan is considered the primary vlan(101), its purpose is to carry traffic from promiscuous ports to isolated, community, and other promiscuous ports. The other vlan(100) is used to carry traffic from isolated ports to promiscuous ports. To simplify, vlan 101 carries traffic from the firewall interface to the DMZ host it is communicating with. Vlan 100 will carry traffic from the DMZ host to the firewall interface. Think of vlan 101 carrying traffic in one direction and vlan 100 carrying traffic in the other direction.

The firewall interface serving as the default gateway for all hosts in the dmz would be configured on the connected switchport with the following:

Switch#config t
Switch(config)#interface gig1/0/48
Switch(config-if)#description bna-fw-01 DMZ
Switch(config-if)#switchport mode private-vlan promiscuous
Switch(config-if)#private-vlan mapping 101 100

All the hosts that reside in the DMZ would have their switchports configured with the following:

switch#config t
switch(config)#interface GigabitEthernet1/0/1
switch(config-if)#description bna-dns-01 Primary
switch(config-if)#switchport private-vlan host-association 101 100
switch(config-if)#switchport mode private-vlan host

This will effectively prevent any host from talking to another host in the DMZ, however all hosts in the DMZ will communicate with a common firewall interface.

Alternative solution:

Many of the older switches do not support a full private vlan implementation. However, there is still a way to implement the same functionality using the limited private vlan implementation. The solution is to use protected ports, which is also referred to as private vlan edge ports.

Protected ports do not forward any traffic to protected ports on the same switch. This means that all traffic passing between protected ports—unicast, broadcast, and multicast—must be forwarded through a Layer 3 device. Protected ports can forward any type of traffic to nonprotected ports, and they forward as usual to all ports on other switches.

Only one vlan is required for this implementation, which would already exist (the DMZ hosts would already be a member of this vlan). Assume vlan 100 as the vlan defined on the switch, the ports connected to each DMZ host will be configured as:

switch#config t
switch(config)#interface GigabitEthernet1/0/1
switch(config-if)#switchport access vlan 100
switch(config-if)#switchport protected

The firewall interface is configured in the standard manner:

switch#config t
switch(config)#interface GigabitEthernet1/0/48
switch(config-if)#switchport access vlan 100

The drawback to using protected ports is that if you have multiple switches used your dmz network, hosts on one switch can communicate to hosts on another switch, even if they both have switchport protected configured. This scenario happens because the uplink port connecting the two switches is not a protected port. With this limitation in mind, there are some creative ways to work protecting hosts on multiple switches, but it will almost always involve combining technolgies , such as combining with vlan access lists at the distribution layer.

If you only have a few switches that make up your dmz environment and your stuck with having protected port usage only, consider using an aggregate switch.  Each of your dmz switches would be uplinked to the aggregate switch and the port protected command would be configured on the aggregate switch side of the uplinks.  The firewall interface would then plug into the aggregate switch (with no port protection configured).  In this scenerio, the aggregate/distribution switch is preventing a host on one switch from talking to the other.

hostname CentralLanRouter
!
interface FastEthernet0/0
description Infrastructure Subnet
ip address 10.0.1.1 255.255.255.0
!
interface FastEthernet0/1
description Employee Subnet
ip address 10.0.2.1 255.255.255.0
!
interface FastEthernet1/0
description HR Subnet
ip address 10.0.3.1 255.255.255.0
!
interface FastEthernet1/1
description Server Subnet
ip address 10.0.4.1 255.255.255.0
ip access-class 100 in
!
access-list 100 remark ACL to protect HR Server
access-list 100 permit tcp 10.0.3.0 0.0.0.255 host 10.0.4.100 eq 443
access-list 100 deny ip any host 10.0.4.100
access-list 100 permit ip any any

The access list 100 defined above accomplishes the following:

Allows IP addresses of 10.0.3.x to access the host 10.0.4.100 via SSL
Denies all other IP addresses from accessing the host 10.0.4.100 via any port
Allows any IP address to access any host

<!–adsense#inlinepostad–>

The access list 101 below keeps the server from initiating connections out to other workstations. This would be used as an additional security measure, in case the Payroll server was compromised. In the event an intruder got console access to server, you wouldn’t want it to have the ability to ftp files off the server to another location.

interface FastEthernet1/1
description Server Subnet
ip address 10.0.4.1 255.255.255.0
ip access-class 100 in
ip access-class 101 out
!
access-list 101 remark ACL to restrict outbound access from the HR server
access-list 101 permit tcp host 10.0.4.100 10.0.3.0 0.0.0.255 gt 1023
access-list 101 deny ip host 10.0.4.100
access-list 101 permit ip any any

The order of the statements in the access list is the magic, since they get processed line by line from top to bottom.

You want to enable ssh access to manage a cisco device, but don’t want to use AAA.

Solution:

First, make sure a local username/password is defined on the device

Router(config)# username admin password cisco

Second, Generate a general use key for the ssh encryption:

Router(config)# crypto key generate rsa general-keys exportable

This message will appear next, enter one of the three common values at the prompt: 512, 1024, 2048

Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.

How many bits in the modulus [512]:
% Generating 512 bit RSA keys ...[OK]

Next, change ssh to use version 2:

Router(config)# ip ssh version 2

Configure the vty lines, which is used when accessing the device:

Router(config)# line vty 0 4

Important next step: Tell the router to authenticate using local authentication – otherwise login will fail

Router(config)# login local

Configure lines to only accept ssh logins, which effictively disables accessing the device via Telnet :

Router(config)# transport input ssh

Enable port security:

Switch(config)#errdisable recovery cause psecure-violation
Switch(config)#int fa0/1
Switch(config-if)#switchport mode access
Switch(config-if)#switchport port-security
Switch(config-if)#switchport port-security maximum 1
Switch(config-if)#switchport port-security violation shutdown
Switch(config-if)#end

The configuration above will enable port security on fastethernet0/1, which would go out to an end user workstation. If someone placed a small switch/hub at the end of the connection in order to connect a second device (such as a network printer, another workstation, etc.), a second mac-address would be detected. This triggers the access switch to shutdown the port (and sending an snmp trap), effectively cutting off all connectivity to the network.

The global configuration command shown above: errdisable recovery cause psecure-violation causes the port to be brought out of shutdown state automatically after the default timer expires. The errdisable recovery timer can be changed from the default of 300 seconds using the errdisable recovery interval command.

enable secret secretpw
line vty 0 4
password telnetpw

Another password needed to be assigned to secure logins via the console port:

line con0
password consolepw

If there was a modem attached for remote out-of-band access, yet another password was assigned to the auxiliary port:

line aux 0
password modempw

With ‘tripple A’ or AAA, access can be defined in a more centralized manner – regardless of the database being used (local, TACACS, Radius, etc…). Consider the following configuration:

enable secret secretpw
username Admin privilege 15 secret adminpw (engineer login)
username Monitor privilege 1 secret monitorpw (helpdesk login for basic troubleshooting only)
aaa authentication login default local enable (the default authentication list will cover logins via all sources – Console, AUX, and Telnet)
aaa authorization console (consider privilege levels at console logins)
aaa authorization exec default local (consider privilege levels at telnet logins)

This configuration will produce:

An enable prompt for the admin login:

User Access Verification

Username: admin
Password:

R1#

A non-privileged router prompt for the monitor login:

User Access Verification

Username: monitor
Password:

R1>

Router> enable
Router# config terminal
Router(config)# access-list 1 permit 192.168.200.0 0.0.0.255
Router(config)# line vty 0 15
Router(config-line)# access-class 1 in
Router(config-line)# exit
Router(config-line)# end

By applying an input statement on the inbound vty, you can control the protocols used to access the router.

Router> enable
Router# config terminal
Router(config)# line vty 0 15
Router(config-line)# transput input { telnet | ssh } (you can specify either or both)