Locating a host

Something that often comes in handy is the ability to physically locate hosts on a large campus network from their IP address. This article assumes the device is correctly configured on the network.

The steps are:

1. Find the devices MAC address.
2. Locate the STP root bridge.
   
3. On the root bridge follow the path to the MAC address.

1. Find the devices MAC address.


The MAC address can be found in the ARP cache of the hosts default gateway. To find the default gateway you need to run traceroute from any host on the same network (tracert on windows) which will give you something like the following:

matt@host:~$ traceroute 10.10.10.10
traceroute to 10.10.10.10 (10.10.10.10), 30 hops max, 60 byte packets
1  10.0.0.1 (10.0.0.1)  2.598 ms  2.875 ms  3.363 ms
2  10.10.10.10 (10.10.10.10)  3.908 ms  4.684 ms  4.363 ms

If the host is running a firewall then the last line may just show stars.

Connect (telnet/ssh) to the last hop before the device itself and check the ARP cache for the device. Remember that ARP entries time out after 4 hours of inactivity, the traceroute will refresh it.

Router# show ip arp 10.10.10.10

Protocol  Address Age(min)  Hardware Addr  Type   Interface
Internet  10.10.10.10 2 001e.1234.4321 ARPA   VLAN 10

This output is from an MSFC card so the interface is the VLANs SVI. You may get a physical interface so check the CDP neighbors to ensure a switch is attached and not another router, if it is the a router then connect to it and keep tracing the address until you find a switch or VLAN interface. If you can't find it then check the NAT setup.

You now need to hop onto any switch associated with the interface shown above (VLAN 10 in this case). You may need some local knowledge or a bit more CDP investigation to find a suitable device. You may already be on it if it's a 6500 in native mode.

2. Locate the STP root bridge.
If you are working on a nicely designed network with combined routing/switching devices (e.g. 6500) then chances are good you're already logged onto the STP root bridge for that VLAN.

If not then find the VLAN you need by running

show mac-address-table address 001e.1234.4321

The commands needed here are:

show spanning-tree vlan 10
show cdp neighbors x/y

Check the spanning tree output, find the root port for that particular VLAN, check CDP neighbors for that port, connect to that device and repeat until you are sitting on the device that is the root bridge. It will either say clearly "this is the root bridge" or you'll be able to tell because the device MAC and root bridge MAC are identical.

3. On the root bridge follow the path to the MAC address.

In IOS/native mode use

show mac-address-table address 001e.1234.4321

In CatOS/hybrid mode use:

show cam dynamic 001e.1234.4321
or
show cam dynamic 00-1e-12-34-43-21

(the latter if it's really old CatOS and doesn't like new format MAC addresses)

This should give you a port, e.g. in IOS:

Router# show mac-address-table address 001e.1234.4321

vlan   mac address     type    learn qos            ports

------+----------------+--------+-----+---+--------------------------

10  001e.1234.4321   dynamic     yes  --  2/6

or in CatOS the output looks like the following (if you get no output read the note at the end of this article):

coresw1> (enable) show cam dynamic 001e.1234.4321
* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
X = Port Security Entry $ = Dot1x Security Entry

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type]
----  ------------------    -----  -------------------------------------------
10     001e.1234.4321             2/6 [ALL]

In this case the MAC is found on port 2/6. Assuming that isn't a copper port run "show cdp neighbors 2/6". Connect to that device and repeat this step until you get an answer pointing to a copper port.

You've now found the device!


Hopefully someone was thoughtful enough to either fill out the SNMP location field, the exec banner, the port description or to create a document telling you where on campus that switch is. It's now a simple matter to trace the cable and locate the device in question.


If you don't have any information beyond the switch name then it's time to start tracing cables and creating the documents yourself.



*note: CatOS will not show any output for "show cam dynamic 001e.1234.4321" if that MAC address is configured for port security on the local device as those addresses are not entered into the dynamic CAM table. In those cases you'll be able to find the port by running "show run | include 001e.1234.4321"

Read more...

SNMPv3 in CiscoWorks

A brief article on how I've got SNMPv3 working in older versions of CiscoWorks. This follows on from the SNMPv3 intro.

Ciscoworks only allows you to associate a single SNMP user account with each device. The same SNMP user account is used to poll the device and receive traps.

The new version of Device Fault Manager apparently has full SNMPv3 support. The older ones don't seem to, but they support polling devices with AuthPriv and you can use AuthNoPriv to send SNMPv3 traps to CiscoWorks.

So to get CiscoWorks to talk with an IOS device using SNMPv3 you need:

• An AuthPriv account for SNMP polling.
• That account configured in CiscoWorks in the devices properties.
• Traps configured to use the same SNMP username, but with AuthNoPriv.

This may seem a bit unusual, defining an SNMPv3 user with a privacy key and then defining the same user without the key but it seems to work. The configuration I use is:

snmp-server group <group> v3 priv
snmp-server user <user> <group> v3 auth sha MYPASSWORD priv des PRIVPASS
snmp-server host <ip> traps version 3 auth <user>

With this configuration, you need to supply the encrypted password when polling the device, however when the device sends traps doesn't encrypt the packet contents (AuthNoPriv).


This article comes with a large dose of YMMV, it works on the version of CiscoWorks I've tested it with, it may not work on yours.
Read more...

SNMPv3

Quick article on SNMP version 3, focused on Cisco kit.

Previous versions of SNMP were configured using community strings and single-line commands in IOS.

SNMPv3 management is more like user/account management and the configuration does not appear in "show run" but is instead hidden in the private config. You access SNMPv3 configuration information via "show snmp x" commands.

SNMPv3 Communication.

There are three ways to configure SNMPv3 communication:
NoAuthNoPriv (called noauth in IOS) – username only authentication, packet sent cleartext.
AuthNoPriv (called auth in IOS) – HMAC authentication (SHA or MD5), packet sent cleartext.
AuthPriv (called priv in IOS) – HMAC authentication, encrypt entire packet.


SNMPv3 Groups.

Groups are configured as follows:

snmp-server group <groupname> v3 noauth|auth|priv [access X]

(access X is an ACL restricting hosts where accounts in the group can be accessed from).


SNMPv3 Users.

SNMP Users are configured as follows:

snmp-server user <user> <group> v3 auth <sha|md5> <pass> priv des <privpass> [access x]

Note: The password should be at least 8 letters long according to the RFC.



SNMPv3 Views.

These are used to control which MIBS the users can browse or which traps are allowed to be sent. There are three types:

Read views – Values you can look at by SNMP polling the device.
Write views – Values you can set via SNMP polling.
Notify views – Values that can be sent as SNMP traps.

I don't specifically use groups so the default settings are:

If you create a new group then it is given the read view "v1default".

If you create an SNMP trap configuration then the group associated with it has a notify view automatically generated by IOS. These views have names beginning with *tv.FFF


I've written a brief dit on getting older versions of CiscoWorks to support SNMPv3 here
Read more...

Checkpoint to Cisco VPNs #2

This is part 2 of the article started here. I'll be creating traditional mode VPN rules, because they are less abstracted than VPN communities and a bit easier to understand (in my opinion). There are some complications*.

To follow a similar methodology to that used on the Cisco router, the steps are as follows:

1. Define the ISAKMP (phase 1) policy.
2. Define the IPsec (phase 2) policy.
3. Create the firewall rule specifying traffic to pass over the VPN.
   
4. Define the encryption domains.
   

Checkpoint doesn't really have a concept of applying the crypto map to an interface as with Cisco. The Cisco concept of a crypto map is close to the encryption domains on Checkpoint.


1. Define the ISAKMP (phase 1) policy.

In Checkpoint the ISAKMP configuration is applied to an "interoperable device" object created for the Cisco VPN gateway. Edit your interoperable device and select "traditional mode configuration" on the "VPN" page to open the ISAKMP properties as shown here:

You configure encryption and integrity, specify to use a pre-shared secret (although you won't be able to enter one just yet) and in the "Advanced" options you can specify DH and lifetimes.

Be careful as the Cisco and Checkpoint default lifetimes do not match.

In practice, ISAKMP can negotiate new keys when the old ones are due to expire but best to make them match anyway to keep things tidy.



2. Define the IPsec (phase 2) policy.
3. Create the firewall rule specifying traffic to pass over the VPN.

IPSec policy is defined under the actual firewall rule which also specifies the interesting traffic. Create a rule allowing the VPN traffic through the firewall (using pre-NAT addresses) and set the action to be "Encrypt"*. Double click on "Encrypt" and you can edit the IPSec settings for the connection.

In this case we're using 3DES/MD5, DH group 2 and specifying which interoperable device the VPN is talking to.

The traffic being allowed is between 10.0.0.0/24 (local) and 172.16.0.0/24 (remote) in either direction and Any protocol.




4. Define the encryption domains.

The encryption domains on Checkpoint are defined as properties of the gateway objects. Edit the interoperable device and open the "Toplogy" page, you can either manually set the topology or use another object to represent the encryption domain.

Here I am using the Remote_172.16.0.0_24 network object to define the Cisco end of the VPN encryption domain.

If you do destination NAT then the encryption domain is the post-NAT address as opposed to the firewall rules which must contain the pre-NAT address.




So that's the remote encryption domain defined, the local encryption domain is specified in the Checkpoint gateway object in the same way. The best way to do this is with a group, so that you can easily add further subnets in future if needed.



There is just one thing missing from the above, the shared key. This is actually defined on your local Checkpoint object rather than the remote peer's object. The reason I put this last is that the peer name won't show up until you've configured the interoperable device properties.

Edit your own Checkpoint enforcement module and open the VPN "Traditional mode configuration", then use the "Edit Secrets" button and you should see an entry for each of your VPN peers that have the "Pre-Shared Secret" box ticked.

Simply select the peer and enter the secret, "cisco" in this case.








Now having said all of the above, I will also say that making these systems interact nicely is a tricky business and you may find that it doesn't work even if you've followed these instructions to the letter.

Part 3 of this series of articles will include some troubleshooting methods to try and help fix any problems.

---

* Note: Checkpoint firewall policies are either in traditional VPN mode or simplified VPN mode which uses communities rather than the rules shown above.

If you don't have the "Encrypt" option in the Action column or if you have a "VPN" column then you're using a simplified VPN policy and cannot create traditional mode VPNs. Unfortunately you cannot convert a policy from simplified mode to traditional so your options are either to create a new policy from scratch, specifying "traditional" when you create it, or to use VPN communities instead.
Read more...

Checkpoint to Cisco VPNs #1

Article #1 - Intro & Cisco Setup.

To show some of the finer points of Checkpoint VPNs I'll rig up a test lab with a site-to-site VPN linking a Cisco IOS router and a Checkpoint R65 splat box.

This article is not intended to be a general VPN introduction, rather the specifics of Checkpoint/Cisco interaction.


The network will look like this:




The local end is using 10.0.0.0/24, the Smart Center sits in this subnet.

The VPN traffic is shown by the red arrow. I'm using a transit network, VLAN 150 - 192.168.0.0/24 but this will probably be the internet in most cases.

The first VPN is going to be very simple, no NAT involved anywhere.








Cisco IOS Setup

In this case we need a static route configured on the IOS router to ensure traffic for the remote LAN goes out of the correct interface:

ip route 10.0.0.0 255.255.255.0 192.168.0.2

In reality you may not need this as for internet-based site-to-site VPNs the routers default route often does the job.

Now the five steps to create a VPN, handy bit of ISCW revision!

1. Define the ISAKMP (phase 1) policy.
2. Define the IPsec (phase 2) policy.
3. Create the crypto ACL specifying interesting traffic.
4. Make the crypto map to bind it all together.
5. Apply the crypto map to an interface.

1 - ISAKMP policy

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2
crypto isakmp key cisco address 192.168.0.1

2 - IPsec policy

crypto ipsec transform-set TESTSET esp-aes 256 esp-sha-hmac

3 - Crypto ACL
Define here what traffic should be encrypted.

ip access-list extended VPN_INTERESTING_TRAFFIC
permit ip 172.16.0.0 0.0.0.255 10.0.0.0 0.0.0.255 log

4 - Crypto Map.

 crypto map VPN_MAP 10 ipsec-isakmp
set peer 192.168.0.1
set transform-set TESTSET
set pfs group2
match address VPN_INTERESTING_TRAFFIC

5 - Apply to an interface

Cisco_Router(config)#interface fastethernet 0/0
Cisco_Router(config-if)#crypto map VPN_MAP
*Mar  1 00:25:33.187: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

If you see the "ISAKMP is ON" message then it's looking good. If you get errors then check whether your hardware and software is supported, as an example some of the 8xx series routers cannot do AES encryption and I don't think IPsec is supported on any of the standard IOS images.

Part 2 goes over configuration of the Checkpoint end.
Read more...

BDPU Guard Vs Filter

Spanning-tree BPDU Guard or BPDU Filter?

A question that has cropped up on more than one occasion is which of these options should be used? BPDU Guard or BPDU filter?

You may think it safest to use both, however that isn't the case.


BPDU Guard
The port is error disabled when a BPDU is received.

BPDU Filter
If the port receives BPDUs then portfast is disabled and it functions as a normal STP port.


You may think that BPDU filter is the more useful setting as it always results in a functioning port, however consider two switches connected together to form a bridging loop as shown here.

With BPDU guard configured on all four ports, the BPDUs are detected and ports are shut down.

With BPDU filter configured on all four ports, no BPDUs are transmitted. The switches are not aware of each other and happily forward traffic down all links, creating a bridging loop.

With both options enabled the same thing happens.

The important difference is that BPDU filter prevents transmission of BPDUs.

If you're looking at standard switchport setting then this is not desirable, so the configuration of choice is:

spanning-tree portfast
spanning-tree bpduguard enable

Read more...

Secure Switchport Template

There are several reasons why you might want to use a switch port template.

• Make life easier for administrators.
• Standardize configuration.
• Allow people without specific Cisco knowledge to configure ports.
• Increase security.
  

An example template in macro form:

macro name accessport
switchport mode access
switchport nonegotiate
switchport access vlan 99
no cdp enable
spanning-tree portfast
spanning-tree bpduguard enable
storm-control multicast level 20.00
storm-control broadcast level 20.00
@

To apply this to a port run:

configure terminal
interface fa0/xx
macro apply accessport

It is probably advisable to reset the port configuration in advance in which case the commands become:

configure terminal
default interface fa0/xx
interface fa0/xx
macro apply accessport

So what do these commands do?

switchport mode access

Specify the port is an access port.

switchport nonegotiate

Disable Dynamic Trunking Protocol (DTP).

switchport access vlan 99

Set the port into a VLAN to avoid VLAN hopping shenanigens. Replace VLAN 99 with the ID of an unused VLAN on your network (not VLAN 1!).

no cdp enable

Disable CDP to stop attackers flooding the CDP neighbor table using Yersinia or similar tools.

spanning-tree portfast

Turn on portfast for access ports, usually a good idea. If you use boot-from-LAN then you'll need this!
Note that turning on portfast does NOT disable STP on that port, it just allows the port to go directly to the forwarding state. You could still create a temporary bridging loop however so also apply:

spanning-tree bpduguard enable

Turn on BPDU Guard to shut the port down if it gets connected to another switch, but allow this switch to keep sending BPDUs on that port.

You can turn this on globally with the command:

spanning-tree portfast bpduguard default

storm-control multicast level 20.00
storm-control broadcast level 20.00

Configure storm-control.



Further reading:

The NSA guide to Cisco switch security.
Read more...