Private vlan’s

This blogpost is about private vlan’s. For  my CCIE study I looked into PVLAN’s. First some terminology. When working with PVLAN’s words like primary vlan, secondary vlan, promiscuous port, isolated port and community port have to sound familiar. If not check the following summary:

  • Primary VLAN: Original vlan, used to forward the actual traffic
  • Secondary VLAN: is configured with one of the following types Isolated or Community
  • Isolated port: A switch port configured as Isolated is only able to communicate with the promiscuous port. It is not able to reach any other destination!
  • Community port: A switchport configured as Community is able to communicate with a server in the same community vlan and the promiscuous port. A community port is not able to communicate with an isolated port.

Below a drawing which describes the above summary.

PVLAN

In the configuration below two laptops are configured in an isolated vlan. Therefor they won’t be able to communicate with each other, but they are able to communicate with the promiscuous port.

PVLAN_isolated

 

In the next configuration the two laptops are configured in a community vlan. because of that they are able to ping each other.

PVLAN_community

 

As you probably noticed, the only configuration change is that the private-vlan host-association changed.

Private vlan’s are very useful to large ISP, because with isolated ports it’s possible to use the same subnets. There is virtually no limit to the number of customers and only one firewall is needed for a lot of customers. The only limiting option is the throughput of the used firewall!

 

** to build this topology I used a Cisco 3560 switch and a Cisco ASA 5505 firewall

Advertisements

Port Access-Lists (PACL)

A while ago I blogged about VACL or Vlan Access-Lists. PACL and VACL are really connected to each other. In this blogpost I will show you how PACL works and how to configure it on a Cisco switch.

First of all, what is PACL. PACL makes it possible to filter incoming traffic on a layer 2 interface using layer 3 or 4 information.

First some restrictions on PACL

  • There can only be one ACL applied to a layer 2 interface per direction
  • PACL don’t filter later 2 traffic like CDP, VTP, DTP, UDLD and STP because this traffic is handled by the Route Processor before the applied ACL takes effect
  • The number of ACL’s that can be configured as part of the PACL configuration is bounded by the hardware resources of the switch
  • A MAC ACL is not applied to IP, MPLS or ARP messages
  • Only named MAC ACL can be used

I spoke earlier about the interaction between PACL and VACL. When they are both used on the switch and the traffic is bridged, PACL will always be applied before VACL’s. PACL will even override a “normal” ACL that is applied to the same interface (for this situation is only one exception, if packets are forewarded in software by the RP. If this is true an ” normal” ACL will take precedence over the PACL). Summarizing the above:

  • PACL for the ingress port
  • VACL for the egress vlan
  • VACL vfor the egress vlan

Below a schematic of this.

*PACL_bridged

It’s fairly easy to configure this, below an example of my lab and how to configure this:

topology

PACL_portconfig

PACL_acl

 

It’s a little different when the traffic is routed. The next is true for routed packets:

  • PACL for the ingress port
  • VACL for the ingress vlan
  • Input Cisco IOS ACL
  • Output Cisco IOS ACL
  • VACL for the egress vlan

Below a schematic of the above:

*PACL_routed

 

PACL can come in handy when you want to deny access of a PC/Server to another PC/Server in the same vlan and you can’t change the vlan of the machines.

 

More information on this topic can be found on the Cisco site (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/port_acls.pdf).
*=I found the used schematics on the Cisco site and borrowed them!

Differences between HP, 3COM and Cisco

Lately I have been working a lot with HP(2610, 2620), 3COM(4500, 5500) and Cisco switches. For a customer I migrated the 3COM cores switch to a Cisco Coreswitch. Before this job I never worked with HP or 3COM before. Although networking principles and protocols are the same for Cisco, HP and 3Com, there are some substantial differences between them.

First of all you have to understand that “trunking” in Cisco language means that you configure a port to transport several vlan’s. In HP/3COM it means bundeling two or more physical interfaces to one logical interface. Bundeling physical ports to become one logical port is called “port-channeling” in Cisco language.  The equivalent of Cisco’s trunking in HP/3COM language is “port tagging”.

When you configure a trunk port on a Cisco switch, you configure the port to allow trunking of several vlan’s. When configuring port-tagging you create a vlan and add ports to the vlan. An example:

Cisco:
Trunk_Cisco

HP:

HP

3COM:

3com_vlan

3com trunk

 

Since HP bought 3COM in 2010, I was clearly dealing with a lot of old stuff. So the 3COM CLI doesn’t exist anymore on modern switches. It’s all HP now. Nevertheless it is possible you encounter 3COM switches in modern networks. Below a table with some handy show command’s for Cisco and the equivalents for HP and 3COM.

commands

Then there is good old spanning-tree. On the internet you read a lot about horror story’s about spanning-tree between Cisco and HP/3COM. After reading about it, I configured “rapid spannig-tree ” (802.1w) on the Cisco core switchs. On the HP and 3COM switches the equivalent of 802.1w was already configured. After replacing the 3COM core switch with the Cisco model, I did not encounter any problems with spanning-tree!

One other thing that catched my attention, is that the HP 2610 and 2620 only host a maximum of 8 vlan’s and 16 static routes.

Off course there are a lot of other differences between Cisco and HP/3COM, but the ones described as above are the most obvious ones.

 

Protect your network against CDP attacks!

As a network consultant/engineer you should be aware of network security risks. Today it is fairly simple to take down a network with the use of Kali Linux. There, it has been said: Kali Linux. This Linux distro is a hackers dream. It has all the necessary tools on board to damage a network very very hard! A hacker only needs a free outlet that is patched to a switch. Within minutes a company can be down on it’s knees!

First of all I’m writing this series of postings to point out the need for security on the network layer, not to make a hackers life easy! In this post I will describe how to use Kali Linux, but more important are the security solutions I give to prevent attacks on your network. This post will be about protecting your network against CDP attacks.

How do I test Kali, you probably guest it already when you read my earlier posts, I use GNS3 for it. Below the topology I use for testing.
topology

R1 and R2 are configured as two multilayer switches, with several (routed) vlan’s. For reference below the config of R1.

R1
!
interface FastEthernet0/0
description Trunk to R2
switchport mode trunk
!
!
interface FastEthernet0/4
switchport access vlan 11

!
!
interface Vlan10
ip address 10.0.0.252 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.252 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.252 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.252 255.255.255.0
standby 13 ip 192.168.80.254
!

CDP Flooding
CDP (Cisco Discovery Protocol) is a great tool when you have to make documentation of a network and most cases CDP is globally enabled on every switch en every switchport on the network. Great, but then a any given moment you check the cdp status on your switch and see this:

cdp_flood

and this:
proc_cpu

As you can see the cdp table is flooded with bogus entry’s and because of the ongoing stream of bogus cdp packets, the cpu spikes to 100%. It’s just a matter of time before the switch will reboot. Problem is, when the switch is rebooted it will be just the same because the stream of cdp packets just keeps going on.

How is this possible you think, well it’s really easy. Install Kali Linux, start the Yersinia program and click attack. Is it that easy I hear you think? Yes it’s that easy! Check it out:

Start Kali Linux:
kali

Start Yersinia
start yersinia

Click the cdp tab, click Launch Attack, choose “flooding CDP table” and click “OK”.
start attack

 

That’s it, your cdp table will be flood with bogus cdp packets. Now check your switch with the “show cdp table”, “show cdp traffic” and “show proc cpu sorted” command:
cdp_flood

proc_cpu

cdp traffic

Within two minutes my switch crashed and rebooted, so this is a real threat to the stability of your network.
To prevent this kind of attacks a couple of things can be done:

First of all, place switchports that are not in use in a dummy vlan and give them an admin down
Second, disable cdp on switchports that don’t need it. For example access ports that only contain a computer or a IP phone which don’t need the CDP protocol to function!
Third, ports that can’t be disabled, configure Port Security on them!

 

 

Vlan Hopping

At the office we had a discussion about vlan hopping. What is possible and what’s not?
Basically there are two possibilities, a “DTP attack” and “double tagging”.

The first option is based on the “Dynamic Trunking Protocol”. With this attack it is possible to create a trunk from a hackers pc. By sending malicious DTP packets to the switch, the attacker is able to create a trunk. From this point the attacker can reach all vlan’s on the trunk.

This attack can be avoided by disabling the DTP protocol. Use “vlan allowed” lists on trunks and make sure that unused ports are configured as access ports and placed in a dummy vlan. And make sure the ports are administratively down!

The second option is called double tagging. With this kind of attack a hacker double tags a packet.
Let’s say the following network situation is in place:

Switch 1 and switch 2 are connected by a trunk. This trunk has vlan 1 configured as the native vlan.
One PC connected to switch 1 in vlan 1 and one PC connected to switch 2 in vlan 100.
The attacker uses PC 1. He or she sends a malicious packet that is double tagged with vlan 1 and 100. The packet arrives at switch 1, the first tag is taken off. The switch can’t see the second tag and because the traffic is on the native vlan it is send to switch 2. When the packet arrives at switch 2, the switch see’s the tag and puts the traffic in vlan 100. As you can see, the traffic hopped from vlan 1 to vlan 100.
See the image below for a graphical view.

Double tagging

This attack can be avoided by using a dummy vlan as native vlan!

VLAN Access Control Lists

A customer asked me if it is possible to block ping (or icmp) from host 1 to host 2 in the same vlan.
Yes this is possible, if you use a so called VLAN Access Control List or VACL.

It’s fairly easy to configure. First of all, create a vlan:
!
conf t
!
vlan 100
name Test
!

Then create a SVI (this is not mandatory):
!
conf t
!
int vlan 100
ip address 10.0.0.254 255.255.255.0
no shut
!

Create an extended access list in which you permit the traffic you want to drop:
!
conf t
!
ip access-list extended VACL_test
permit icmp host 10.0.0.1 host 10.0.0.2
!

Create the access-map:
!
conf t
!
vlan access-map VACL_no_icmp
action drop
match ip address VACL_test // this points to the access list created earlier
vlan access-map VACL_no_icmp
action forward // this permits all other traffic
!

Now connect the access-map to the vlan:
!
conf t
!
vlan filter VACL_no_icmp vlan-list 100
!

Try pinging from host A to host B and you will see it isn’t possible. Try pinging your default gateway and you will see this is possible.
With other words, the VACL is functioning as intended.