RSA Authentication Manager provides an authentication mechanism consisting of a “token” – either hardware (e.g. a Keyfob) or software (application that provides same functionally as a keyfob).  A hardware or software token is assigned to an individual, which generates an authentication code at fixed intervals (usually 60 seconds) using a built-in clock and the tokens factory-encoded random key (known as the “seed”). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased.

In this example, I are using RSA Authentication Manager 6.1, which is running on a purpose built appliance that uses Windows 2003 Server with the RSA server software installed.  This particular solution includes Funk Software’s Steel Belted Radius, which provides a radius authentication mechanism into RSA.  At the time of this writing, this particular appliance and software version is approaching end of life and has since been replaced with Authentication Manager 7.1.  In the appliance version of 7.1 (known as Authentication Manger 3.0), the operating system has moved to Linux with Authentication Manager 7.1 loaded on top of it.  Version 7.1/3.0 also includes a radius server that can be used for radius clients needing to utilize two-factor authentication.

Now, onto the client portion of software used to interface with the RSA server.  As previously mentioned, there are two options, with the first being to use the RSA provided authentication agent for Unix/Linux.  The agent is actually a module that hooks into PAM, which is the central authentication standard used in most modern Unix/Linux systems today.  This option provides the maximimum functionality and interfaces directly with the RSA protocol (which means the RADIUS server is not required).

The second option is to load a RADIUS module into PAM (pam_radius_auth), which would then communicate to the RSA server via it’s built in RADIUS server.  Why would you want to use this option over the first option presented?  The RSA provided client is only supported on  a couple of Linux platforms, namely Red Hat and SuSE, which are both RPM based.  So if you are using any other Linux distribution (Debian based, etc.), there is not an RSA provided option with this client software.

Most Linux software repositories will contain a PAM radius module, which prevents having to download source code and compiling programs.  I’m specifically working on a Debian based system, which includes the module libpam_radius_auth in it’s repository.  The following contains instructions for configuring the system:

First, install the module from the distributions repository:

root@localhost:~# apt-get install libpam-radius-auth
Running /usr/bin/apt-get install libpam-radius-auth
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  radius-server
The following NEW packages will be installed:
  libpam-radius-auth
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.7kB of archives.
After this operation, 127kB of additional disk space will be used.
Get:1 http://ftp.us.debian.org lenny/main libpam-radius-auth 1.3.16-4.4 [24.7kB]
Fetched 24.7kB in 0s (58.4kB/s)
Selecting previously deselected package libpam-radius-auth.
(Reading database ... 36010 files and directories currently installed.)
Unpacking libpam-radius-auth (from .../libpam-radius-auth_1.3.16-4.4_amd64.deb) ...
Setting up libpam-radius-auth (1.3.16-4.4) ...

Now that the module is installed, it’s time to edit configuration files:

root@localhost:~# vi /etc/pam_radius_auth.conf

My default configuration file had two invalid entries defined to show the format. One of two entries in my configuration file was for 127.0.0.1 with a comment below it that read “having localhost in your radius configuration is a Good Thing”. I don’t know what that is supposed to mean, but don’t leave it in the configuration as we have no Radius server running on the local machine.

After removing the existing (sample) entries and replacing with valid server entries, which contained server[:port], shared_secret, and timeout (separated by tab) – save and close the file. A particular detail to note is that initially I set the timeout value to the displayed default of 3 (seconds). However, I experienced authentication failures until I changed that value to 5 (seconds) – after noticing timeout messages in /var/log/auth.log.

Next, we need to modify a PAM configuration file in order to specify the use of the RADIUS module when authentication occurs. Note: There are several services that make use of the PAM system for authentication. Therefore, by doing what I am about to explain could cause negative impact on an application that uses PAM to authenticate users. Further research should be performed to determine which configuration file the following commands should be placed in, based on what you want to secure.

In this example, there are no applications running that need auth services provided by PAM (such as an FTP server, HTTP server, SAMBA, etc). The goal is to define the use of a global policy that uses the RADIUS module for central authentication. If you wanted to only secure a particular service (like ssh logins for administrator shell access via sshd), a different file other than the following can be modified so to not disrupt any other PAM using applications installed on the machine.

Edit the /etc/pam.d/common-auth configuration file:

root@localhost:/etc/pam.d# vi common-auth

First, find the following line in the configuration:

auth	required	pam_unix.so nullok_secure

Insert a new line BEFORE/ABOVE the previous line and paste the following line into the file.

auth	sufficient	pam_radius_auth.so

Save and exit the file. The previous addition to the common-auth file tells PAM to use the RADIUS module for authentication first (since it is listed first in the configuration). By specifying ‘sufficient’ in our entry, PAM determines that a successful auth using this module is satisfactory, therefore no other modules defined in the configuration file need to be processed. However, if there is a failure from this module (user didn’t exist on RADIUS server), then continue processing entries in this configuration file. Note: By configuring this way, any locally defined users on the system will still authenticate successfully. Therefore, it is advised to only have local ‘emergency accounts’ defined, in case the machine completely looses communications with all configured RADIUS servers – you would still be able to log in with a local user. If you adopt this policy, obviously the people who know the credentials to the locally defined account(s) should be minimal – in order to force the use of individual (RADIUS defined) accounts.

Next, edit the /etc/pam.d/common-account file

root@localhost:/etc/pam.d# vi common-account

Find the line:

account	required	pam_unix.so

Insert the following BEFORE/ABOVE the previous line:

account	required	pam_radius_auth.so

Save and exit the file. The previous addition to the common-account file is to tell PAM to use the RADIUS module for any authorization requirement (like permitting access to a service based on time of day, etc.), prior to checking the local database. By specifying ‘required’ in our entry, PAM determines that the success of the module is required for the module-type facility (in this case authorization is the module-type) to succeed.

Next edit the /etc/pam.d/common-session configuration file:

root@localhost:/etc/pam.d# vi common-session

Find the line:

session	required	pam_unix.so

Insert the following lines BEFORE/ABOVE the previous line:

session	required	pam_radius_auth.so
session	required	pam_mkhomedir.so	skel=/etc/skel/	umask=0022

Save and exit the file. The previous addition to the common-session file is to define tasks to be performed at the start and end of a user control of a service. By specifying ‘required’ in our entry, PAM determines that the success of the module is required for the module-type facility (in this case services is the module-type) to succeed.

As you can see, we added a second module (pam_mkhomedir.so) to the common-session configuration file. This is required in order to have a home directory available for a RADIUS authenticated user. The module will run after a successful authentication and create the user home directory in /etc/skel with the appropriate permissions.

That will complete the configuration setup. There is one final step left that has to be performed for every user that will login to the system via RADIUS. Because RADIUS doesn’t provide a directory service, we have to have UID and GID information pre-populated on our system. This is accomplished by creating the username and groupname on the local system, which will assign the necessary unique user ID and group ID values (numbers).

For example, a user that needs to authenticate via radius using a login id of johnh (that belongs to an associated group called johnh) needs to have the following performed on the local system:

useradd johnh

That will do it, the user will now have an entry that is created in /etc/passwd and /etc/group with an automatically created (unique) ID number.

Before I go any further, it must be stated that commercial packages exist that can do this type of analysis for you.  These software programs usually import CheckPoint logs into a larger data-source and then run various reports against it.  While those packages are extremely valuable to the firewall administrator, often times it is cost prohibitive to the company they work for.  It will be my attempt to share a Do It Yourself, bare bones, just get it done, alternative approach to buying these costly software packages.

As far as prerequisites, not much is needed: I’ll be using a Linux workstation for the utilities, such as cat,grep, and others.  The log data will be imported into a SQLite database for analysis.  Everything I have mentioned thus far is available on a Windows workstation, but will require a little bit of work to find/install it.  My point here is: If you have not taken the plunge to set up a Linux ‘utility’ workstation yet – now would be a great time to knock that out.  Anyway, I will show all my examples and reference the procedure as if it is being performed from a Linux machine.  However, I think it will easily be adaptable to the Windows only administrator.  If not, I will do my best to clarify points as questions are asked.

First, we must get the logs in the format we can work with.  This will require exporting the current CheckPoint log file type to a delimited, plain text type.  The utility required for this will be located in the Firewall1 program directory on the SmartCenter management station.

From a command line on the SmartCenter machine, we want to change to the firewall log directory:

cd \fw1_install_dir\RXX\fw1\log

where fw1_install_dir = SmartCenter installation directory and XX = the version of SmartCenter installed (i.e. R75).

running the ‘dir’ command in this directory will give you the name of the available logfiles for export.  The file names will follow the format of YYYY-MM-DD_HHMMSS_XX.log, select the file for export and run the following:

fwm logexport -n -p -m raw -i [YYYY-MM-DD_HHMMSS_XX.log] -o [YYYY-MM-DD_HHMMSS_XX.txt]

The switches are explained below:

Usage:
fwm logexport [-d delimiter |-s] [-i filename] [-o filename] [-f|-t] [-x start_p
os] [-y end_pos] [-z] [-n] [-p] [-a] [-u unification_scheme_file] [-m (initial|s
emi|raw)]
Where:
-d  - Set the output delimiter. Default is ';'.
-s  - Set the delimiter to be ASCII character #255.
-i  - Input log file name. Default is the active log file, fw.log.
-o  - Output file name. Default is printing to the screen.
-f  - Only in case of active log file - Upon reaching end of file, wait for new
records and export them as well.
-t  - Same as -f flag, only start at end of file.
-x  - Start exporting at the specified position.
-y  - End exporting at the specified position.
-z  - Continue exporting the next records, in case of an error. Default is to stop exporting.
-n  - No IP resolving. Default is to resolve all IPs.
-p  - No port resolving. Default is to resolve all ports.
-a  - Export account records only. Default is export all records.
-u  - Unification scheme file name. Default is log_unification_scheme.C.
-m  - Unification mode: initial-order, semi-unified, or raw. Default is 'initial'.

The switches used in the previous example should be self-explanatory after looking them up using the syntax help above.

Here is the command I ran in my environment

C:\Program Files\CheckPoint\R71\fw1\log>fwm logexport -n -p -m raw -i "2011-09-28_235900_98.log"
 -o "d:\2011-09-28_235900_98.txt"
Starting... There are 20492936 log records in the file
File logexport.ini was opened successfully
Processed 20492936 out of 20492936 records (99%)

Once I did this in my environment for one log file, which contained access information for a 24 hour period, the result was a 5.2G text file.  This would obviously be impossible to open with any editor, which is where our Unix utilities come into play.

At this point, I only want to load the necessary data into the db.  This keeps the database small and makes queries much more responsive.  In order to extract a subset of data from the log output, we will use awk and grep to put the desired results into a separate file.  In this example, I want traffic that was either sourced or destined to 10.16.2.20.

# awk '{q=split($0,a,";");if (NR==1){for (v=1;v<=q;v++) c[a[v]]=v} printf("%s;%s;%s;%s;%s;
%s;%s;%s;%s;%s\n",a[c["date"]],a[c["time"]],a[c["action"]],a[c["rule_uid"]],a[c["rule_name"]],
a[c["src"]],a[c["s_port"]],a[c["dst"]],a[c["service"]],a[c["xlatesrc"]])}' 2011-09-28_235900
_98.txt | grep '\<10.16.2.20\>' > windowsdc01.txt

The previous command uses ‘awk’ to process the file ’2011-09-28_235900_98.txt’ and only print the log fields we are interested in. Awk is being used because for some reason, Checkpoint does not export log files the same way twice.  For example a fwm export one day may contain 51 columns, the next day it might contain only 40.  Obviously this would play havoc on importing the same fields each time into our database.  By extracting just the columns we need, this ensures the same format each time.  This command looks very complex, the only thing you really want to consider is if additional fields are wanted in the output.  If this is the case, just make sure the additional fields are specified in order within the script.  For example, let say you want to add an additional field (i/f_name) to the output.  If you look at the first line of the original exported file, which are the column headers, you will see the “i/f_name” column is between “action” and “rule_uid”.  So hear is what you would add to the existing script (in bold)

a[c["action"]],a[c["i/f_name"]],a[c["rule_uid"]],

You will also need to add an additional %s; after the printf statement for each additional field you add

Moving on, note after the grep command the \< and the \> characters with the ip address in between.  What this does it tell grep to only match this character string if it’s the beginning or end of the word.  If the \< characters were missing from above, then we would also match other hosts like 110.16.2.20 or 210.16.2.20.  Likewise, if the \> were missing off the end, then we would match on 10.16.2.201, 10.16.2.202, and so on.  Finally, the greater than sign followed by a file name, will output the results to a file instead of to the default location of the screen.

Now, I have a separate file that contains only the data I care about at the moment and it is 28Mb vs. the 5Gb source file we started with.  The next thing to do is load it into a sqlite database.  Before we can do that, we have to create the database with a table containing the proper columns to accept the text file import.  We start by invoking sqlite and passing it a variable that will be the name of a new database, which in this example is called data.db.  Once sqlite is invoked, run the SQL script shown below, which is used to create the table. Obviously this sql statement would need to be modified if you added additional fields over what is shown in the previous example.

# sqlite3 data.db
SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>CREATE TABLE tbl_fwlogs(
f_date varchar(10),
f_time varchar(10),
f_action varchar(10),
f_rule_uid varchar(100),
f_rule_name varchar(15),
f_src varchar(10),
f_srcport varchar(10),
f_dst varchar(15),
f_service varchar(10),
f_xlatesrc varchar(10));
sqlite>

Define the separator used in the import file

sqlite> .separator ";"

Finally, import the text file into the database

sqlite> .import file.txt tbl_fwlogs

Now that you have data to query, here is a sample that displays what rules are being used in the rulebase for this particular host.

sqlite> select DISTINCT(f_rule_uid),f_rule_name from tbl_fwlogs;

{3C9A2260-8E75-4488-82C3-A3F279BB72B6};Srv to Srv access
{13385ECB-2S6F-4657-CC20-4DA76F217141};Windows Domain Resources
{3A5A0D9E-1D32-41BD-9795-829ED5CFE366};Time Requests
{5D2726D6-738A-43BA-8B5B-63FA0A7EBF78};Monitoring Servers
{A696790B-2605-46B2-BDA3-8A64A5B98C1A};DNS
{DDDCF882-8121-4E27-8A28-EA17EC5BC47E};Internal ICMP
sqlite>

In this example we see there are 6 rules in use for this host.  From here additional queries would determine src/dest addresses and protocols used so that we could take that info and build a stricter rule set for this host.

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>