Tuesday, February 17, 2009

Packet Captures with Cisco IOS

With Cisco IOS 12.4(20)T, Cisco now supports packet captures on interfaces. This is a welcome addition to the Cisco feature set. Previous to this addition, network admins had to rely on span ports and capturing traffic on end devices to troubleshoot network problems. Now, network admins can capture packets entering and exiting router interfaces. There are a couple of disappointments with the the packet capture. The first is that the configuration is a little bit difficult to use. There are a number of commands that need to be entered to execute a capture. It would have been nice if there was just one command, similar to tcpdump. The second disappointment is that the ability to view the packets, on the router, is very limited. In order to get a good view of the packet capture, it is necessary to export the capture file and view the file using Wireshark.

I'd like to go through an example of how to use the new packet capture feature. As stated above, there are number of steps to go through to create the capture. In this example, I will show how to create a 512 Kbytes circular buffer to hold the data and collect the data on the gigabitethernet 0/1 interface.

1. The first step is to create the buffer. In the configuration below I am calling the buffer "buf1"
monitor capture buffer buf1 size 512 max-size 512 circular
2. The next step is to define which interface will listen for the traffic. This is done by creating a capture point. In the configuration below I am calling the capture point "cap1". I am setting the capture point to capture ip packets sent and received on gigabitethernet 0/1.
monitor capture point ip cef cap1 gigabitethernet0/1 both
3. The next step is to associate the buffer with the capture point.
monitor capture point associate cap1 buf1
4. The next step is to to start the capture
monitor capture point start cap1
5. After the required data is captured, the capture is stopped
monitor capture point stop cap1
6. The data can then be viewed with the command below. As you can see in the associated information shown with the command, there is not alot of detail given
show monitor cap buffer buf1 dump
23:50:18.669 EDT Feb 17 2009 : IPv4 LES CEF : Gi0/1 None

499A6280: 00192F06 0C09001B D5FF3C05 08004500 ../.....U.<...E. 499A6290: 008000BA 0000F611 881DAD4F 20284465 ...:..v...-O (De 499A62A0: 29B91194 1194006C 00003668 E2340000 )9.....l..6hb4.. 499A62B0: 51D5B8B1 90BFB446 3F7011AF 78C98F42 QU81.?4F?p./xI.B 499A62C0: 696F3833 023841E8 5EF6988B C741F5E9 io83.8Ah^v..GAui 499A62D0: 4ACD925F 074DC56C 10B731B2 797F9C03 JM._.MEl.712y... 499A62E0: 28BF4C53 2ADF0EEF AE0F3526 98442EE2 (?LS*_.o..5&.D.b 499A62F0: 5A8C348A 246ABF28 3EFA15CB 11ABF76C Z.4.$j?(>z.K.+wl
499A6300: EC586E86 E802FF30 343BE135 9A0300 lXn.h..04;a5...
7. A better way to view the data is to export it. The data can be exported to another computer. The capture file can then be viewed with Wireshark. The export supports FTP, HTTP, HTTPS, PRAM, RCP, SCP, and TFTP. The example below shows TFTP.
monitor capture buffer buf1 export tftp://192.168.1.10/buf1.pcap

Here are some references to use for further information

Sunday, February 15, 2009

Cisco IOS SSL VPN Example

Cisco has made a big push into the SSL VPN market. Currently, their main focus appears to be on beefing up their SSL VPN support of the ASA FW. SSL VPN does exist within IOS as well, though. Version 12.4(20)T added a lot of new features. The IOS SSL VPN features are definitely lagging behind the ASA SSL VPN, but the basic functionality is available within IOS SSL VPN. The IOS SSL VPN supports clientless, thin client, and full client modes. The clientless mode uses a web portal. Thin client augments the web portal with port forwarding capability. The full client uses the AnyConnect SSL client. The IOS SSL VPN does not have RDP, telnet, ssh, etc plugin capability that exists in the ASA SSL VPN. It also does not support the dynamic access policy(DAP) also available in the ASA SSL VPN.

I wanted to show an example of using clientless and thin client features in this blog entry. Before going into the example, I wanted to point out the general methodology for implementing the IOS SSL VPN. The "webvpn context" command is the container that houses the individual parameters for the VPN. The "webvpn gateway" and "policy group" provide the parameters that are added to the "webvpn context".

The example is based on the diagram below



For this example, the router needs to provide a user on the 192.168.137.x network secure access to R1 through an SSL web portal. HTTP acccess, to R1, is provided through a URL link. HTTPS and SSH access, to R1, is provided by port forwarding. In a real world example, this type of access could allow emergency access for a network administrator from any computer.

The first step is to set up the authentication method for the user. The IOS SSL VPN uses the default AAA method by default. For this example, we will use local authentication with the commands below
aaa new-model
aaa authentication login default local
username cisco password cisco
The next step is to setup the IP and port information for connectivity to the SSL VPN. The IOS SSL VPN allows the IP to be based on the interface IP of the router or a virtual IP address. Additionally, the port can be the standard 443/tcp or it can be another manually assigned port. For this example, we will use the fa1/0 interface of the router and port 8000/tcp. This is shown below.
webvpn gateway SSL1
hostname SSL1
ip address 192.168.137.100 port 8000
ssl trustpoint TP-self-signed-4294967295
inservice
Notice the "ssl trustpoint" in the configuration. This is automatically created when the "inservice" command is added to active the configuration.

The next step is to create the "webvpn context". As stated earlier, this is the container for the VPN parameters. Within the "webvpn context" container, there are number of parameters that are defined and applied. For example:
  1. A URL can be defined
  2. The URL can be applied to a policy group
  3. The policy group can then be applied to the context
This is all within the "webvpn context" container. An example is shown below
webvpn context SSL
url-list "R1"
heading "R1"
url-text "R1-http" url-value "http://192.168.1.2"
policy group default
url-list "R1"
default-group-policy default
This shows the URL list, R1, being defined and then applied to the policy group, default. The policy group, default, is then applied to the context with the "default-group-policy" command.

In a similar manner, the IOS SSL VPN can support port forwarding. This is shown below.
webvpn context SSL
port-forward "R1"
local-port 5000 remote-server "192.168.1.2" remote-port 443 description "R1 HTTPS"
local-port 5001 remote-server "192.168.1.2" remote-port 22 description "R1 SSH"
policy group default
port-forward "R1" auto-download
default-group-policy default
This portion shows how to forward ports. When a user uses a web browser to access https://127.0.0.1:5000, they are redirected to https://192.168.1.2 through the SSL connection. Similarly, when a users uses an SSH client to access 127.0.0.1 on port 5001, they are redirected to 192.168.1.2 on port 22. In the "port-forward" command, notice the "auto-download" parameter. This causes the port forward connectivity to launch automatically, instead of requiring the user to click on the "thin client" start button shown below



The screenshots below show the GUI experience based on the configuration above.

1. The user accesses the web portal at https://192.168.137.100:8000



2. The user logs in and is presented with the web portal



3. At the same time as step 2, the port forwarding window appears with the setting for port forwarding



Below is the full relevant config for the example above
aaa new-model
!
!
aaa authentication login default local
username cisco password 0 cisco
no ip http server
no ip http secure-server
webvpn gateway SSL1
hostname SSL1
ip address 192.168.137.100 port 8000
ssl trustpoint TP-self-signed-4294967295
inservice
!
webvpn context SSL
ssl authenticate verify all
!
url-list "R1"
heading "R1"
url-text "R1-http" url-value "http://192.168.1.2"
!
!
port-forward "R1"
local-port 5000 remote-server "192.168.1.2" remote-port 443 description "R1 HTTPS"
local-port 5001 remote-server "192.168.1.2" remote-port 22 description "R1 SSH"
!
policy group default
url-list "R1"
port-forward "R1" auto-download
banner "Welcome to the IOS SSL Lab"
default-group-policy default
gateway SSL1
inservice

Wednesday, February 11, 2009

Auto reconnect with Cisco AnyConnect VPN

One of the great features about the Cisco AnyConnect VPN client is auto reconnect. This feature automatically reconnects a VPN session if the users internet connectivity drops. This means that if a user is connected to the VPN and the user's computer is accidentally unplugged, the VPN connection will be automatically reestablished when the computer is plugged back in. Another example would be a similar situation when a 3G wireless connection drops. If using the IPSec VPN client, a temporary loss of signal would cause the VPN connection to drop. With the AnyConnect VPN client, the VPN connection would be automatically reestablished.

This feature is turned on by default. As long as the user's computer does not go into a suspend state the AnyConnect VPN client will attempt to reconnect. This setting is defined in an XML file that is described in the Cisco AnyConnect VPN Administrator Guide, Release 2.3. The XML file is located in the \Documents and Settings\All Users\Application Data\Cisco\Cisco AnyConnect VPN Client\Profile\AnyConnectProfile.tmpl file. By modifying this file, the auto reconnect functionality can be disabled, if desired.

The portion of the file pertinent to auto reconnect appears as follows

Monday, February 9, 2009

Moving Cisco CSA Management Center to a New Server with New Name and New IP

The Cisco Security Agent Management Center (CSA MC) provides the central management for CSA. The Agents check in with the CSA MC to make sure they have the latest policy and version of software. For this reason, it is important that the CSA MC be a stable server that is always operational with the same IP address and name. Unfortunately, there may be unavoidable instances where the CSA MC must be moved to a new server with a different IP and name. This guide will go through how to move the CSA MC application and database to a new server and migrate the Agents, running on the end computers, to use the new CSA MC.

The following assumptions are being made
  1. The database is MS SQL Server 2005 Express Ediation and is housed on the same server as the CSA MC
  2. CSA version 6.0
  3. Screenshots show the old CSA MC with name "CSA" and the new CSA MC with name "CSA2"
Creating the New CSA MC
The first step is to install the exact same version of CSA MC application on the new server. The license does not need to be installed on the new CSA MC because the license will be moved over from the old CSA MC as part of the database move.

The next step is to move the database from the old CSA MC to the new CSA MC. This will allow all the registered agents, groups, rule modules, rules, etc to be moved to the new CSA MC. The detailed steps are listed below.
Note: It is important to note that doing this fully replaces the existing database. This means that any SSL certificate, Agent, policy, group,etc information on the existing database will be removed. We will see how this affects the Agent registration for the new CSA MC later.
First, on the new and old CSA MCs, stop the CSA MC service and the Agent, running on the CSA MC, using the following commands

Open Start->Run... and type "services.msc". Stop the Management Console, MSSQL, and Agent services. The services should look similar to the names below.





On the new CSA MC, rename the c:\Program Files\Cisco\CSAMC\CSAMC60\db directory to a new name, such as db-backup. Next, copy the c:\Program Files\Cisco\CSAMC\CSAMC60\db directory from the old CSA MC to the new CSA MC. At this point you have fork lifted the database from the old CSA MC into the new CSA MC. Reboot the new CSA MC.

Updating Agent Kits
As mentioned earlier, the old CSA MC database has been fork lifted into the new CSA MC and fully replaced the existing database on the new CSA MC. This means that any existing agent kits and any new agent kits generated on the new CSA MC still reference the old CSA MC. To correct this, we need to dig into the database and modify some entries.
Note: The database changes are based on my own research. Use at your own risk
The CSA MC installation did not include the Management console to view the SQL Server 2005 database. Microsoft offers the Microsoft SQL Server Management Studio Express to manage the database. Download this application to the CSA MC and install it. After it has been installed, launch it. Take the default login settings as shown below


Navigate down the database tree to the following section



Within this tree scroll down and look for "dbo.mc_config". Right click on the name and click "Open Table" as shown below




The table shows the entries that get sent as part of the Agent Kit. We will modify the parameters to reflect the new CSA MC instead of the old CSA MC.

This screenshot shows the database before any changes were made. The name CSA references the old CSA MC as does the IP 192.168.137.100




This screenshot shows the database after the changes were made. The name CSA2 references the new CSA MC as does the IP 192.168.137.15.



In addition to the changes listed above, you should probably modify the sslca.crt, sslca.ns, sslca.key, sslhost.crt, sslhost.csr, and sslhost.key files in the database. In my testing, everything seemed to work fine without modifying the values, but for completeness sake, I would recommend modifying both the names and the data to reflect the information on the new CSA MC server. The data can be retrieved from the c:\Program Files\cisco\CSAMC\CSAMC60\cfg directory. Right click on each file and open with notepad. Then copy the entire contents and paste it into the value portion of the database.

After the database has been changed, the agent kits need to be refreshed to incorporate the new values. This can be done by running the following command
C:\Program Files\Cisco\CSAMC\CSAMC60\bin>webmgr makekits_refresh
Generating rule programs...
Regenerating agent kits...
Done.
Once this is complete, the agent kits will have the correct information referencing the new CSA MC.

Fixing the Agent on the New CSA MC
Now, access the web GUI and navigate to Systems > Hosts. You'll notice that the new CSA MC server is not listed. This is because we are using the database from the old server. This is shown below.



The old CSA MC does not need to be listed here, so you can move the server named "CSA.lab.com" to the recycling bin.

The Agent running on the new CSA MC, CSA2.lab.com, is not showing up because we are using the database from the old CSA MC. The new CSA MC was registered in the original database on the new CSA MC. This was the database that we renamed "db-backup". Confirmation of the problem is shown in the agent logs on the new CSA MC
1504: CSA2: Feb 06 2009 21:58:10.773 -0600: %CSA-4-REGISTRATION_FAILED_INVALID_REGID: %[Component=Csamanager][PID=1076]: No deployment host exists on server with registration ID={90A55B27-4F2B-490A-A27E-081D8747E3F5}.
We need to get a new registration that is recognized by the current database on the new CSA MC. In order to do this, the following steps should be followed:
  1. Remove the Agent on the new CSA MC
  2. Reboot
  3. Download and install the "Servers CSA Management Center V6.0.0.201" Agent Kit from the new CSA MC.
  4. Reboot
  5. Verify that the new CSA MC shows up in the CSA MC web GUI in "Systems > Hosts".
Following these steps will allow the Agent, running on the new CSA MC, to be properly registered and displayed.

Handling Existing Agents
The registration IDs for the existing Agents have been ported to the new CSA MC with the database move. There are just two steps that need to occur, on the computers with the Agent installed, to complete the migration of the already deployed Agents from the old CSA MC to the new CSA MC
  1. Modify the c:\Program Files\Cisco\CSAgent\cfg\agent.bundle file to reference the new CSA MC
  2. Replace the c:\Program Files\Cisco\CSAgent\cfg\sslca.crt file to reference the new CSA MC
To complete step 1, you will first need to stop the Agent with the "net stop csagent" command. After that, open the agent.bundle file and make the modifications as shown in the screenshots below. In the screenshots, CSA and 192.168.137.100 reference the old CSA MC and CSA2 and 192.168.137.15 reference the new CSA MC. The original file is shown on the left and the new file is shown on the right














The second step was to replace the sslca.crt file. The CSA MC creates its own root certificate and distributes it in the CSA Agent Kit. The Agents then trust the SSL certificate provided by the CSA MC because it is signed with the root certificate. When the CSA MC is changed, the root certificate also needs to be changed to reference the new CSA MC. The new sslca.crt can be obtained from the new CSA MC in the c:\Program Files\Cisco\CSAMC\CSAMC60\cfg directory. It needs to replace the c:\Program Files\Cisco\CSAgent\cfg\sslca.crt file on each computer with the Agent.

The two steps above can normally be accomplished with a central application used to push out applications. Some examples of these applications would be Microsoft SMS or Altiris.

Once the two step above are completed, you should see the following screen on the Agent status page



References

Sunday, February 8, 2009

Easy way to find the SNMP OIDs on an ASA FW

One excellent command for viewing ASA SNMP OIDs is "show snmp-server oidlist". It appears that this is a hidden command, based on the ASA 8.0 Reference Guide. This command provides information on the OID and name associated with it. I've included an example below
show snmp-server oidlist

-------------------------------------------------
[0] 1.3.6.1.2.1.1.1. sysDescr
[1] 1.3.6.1.2.1.1.2. sysObjectID
[2] 1.3.6.1.2.1.1.3. sysUpTime
[3] 1.3.6.1.2.1.1.4. sysContact
[4] 1.3.6.1.2.1.1.5. sysName
[5] 1.3.6.1.2.1.1.6. sysLocation

I found this command at the link below. All credit should go to Joe Harris.
http://6200networks.com/2008/10/23/asa-snmp-oids/

Monday, February 2, 2009

Cisco NAC Version 4.1.8 released

Cisco NAC version 4.1.8 has been released. The release notes spell out the changes.

The general NAC Manager/Server enhancements are
  • CAS Fallback Behavior Enhancement
  • CAS HA Pair Link-Detect Configuration Enhancement
  • DHCP Failover Behavior Enhancement
Additionally, there are number of agent fixes.

Sunday, February 1, 2009

Creating a self-signed SSL certificate for Microsoft IIS

I wrote a previous blog entry that gave information creating a self-signed SSL certificate with Apache. I recently also had to create a self-signed SSL certificate for Microsoft IIS. It turns out that this is really easy.

Microsoft provides an IIS resource kit that provides an application to create a self-signed SSL certificate. The application is called selfssl.exe. The steps for creating the SSL certificate are listed below.
  1. Download and install the IIS resource kit.
  2. Open a cmd prompt and type: cd "c:\Program Files\IIS Resources\SelfSSL"
  3. Create the self-signed SSL certificate by just typing: selfssl.exe
There are a number of command line parameters you can enter to modify the default settings. They are listed below

C:\Program Files\IIS Resources\SelfSSL>selfssl /?
Microsoft (R) SelfSSL Version 1.0
Copyright (C) 2003 Microsoft Corporation. All rights reserved.

Installs self-signed SSL certificate into IIS.
SELFSSL [/T] [/N:cn] [/K:key size] [/S:site id] [/P:port]

/T Adds the self-signed certificate to "Trusted Certificates"
list. The local browser will trust the self-signed certificate
if this flag is specified.
/N:cn Specifies the common name of the certificate. The computer
name is used if not specified.
/K:key size Specifies the key length. Default is 1024.
/V:validity days Specifies the validity of the certificate. Default is 7 days.
/S:site id Specifies the id of the site. Default is 1 (Default Site).
/P:port Specifies the SSL port. Default is 443.
/Q Quiet mode. You will not be prompted when SSL settings are
overwritten.

The default behaviour is equivalent with:

selfssl.exe /N:CN=SERVER /K:1024 /V:7 /S:1 /P:443

Below is an example of creating the self-signed SSL certificate

C:\Program Files\IIS Resources\SelfSSL>selfssl
Microsoft (R) SelfSSL Version 1.0
Copyright (C) 2003 Microsoft Corporation. All rights reserved.

Do you want to replace the SSL settings for site 1 (Y/N)?y
The self signed certificate was successfully assigned to site 1.

C:\Program Files\IIS Resources\SelfSSL>cd "c:\Program Files"