From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Fri Sep 30 2005 - 21:41:57 GMT-3
The following website has the entire article as well as configuration files
for the two 2950s and the 3550.
http://www.antionline.com/showthread.php?s=&threadid=269785
Read below....
-Dennis Hartmann
Defending Against Rogue DHCP Servers posted 08-08-2005 03:05 PM
(post #1)
Hey Hey,
This was originally submitted for the newsletter but again I'm resubmitting
so that it's searchable and reaches a larger base. It's also a follow up to
my previous tutorial DHCP and Resulting Theoretical Attacks
For some time now, large corporations that provide public internet/intranet
access have been plagued with the problem of Rogue DHCP servers. This issue
can be easily solved with some basic switch security techniques. Due to a
lack of hardware this will be demonstrated with the following network setup,
layered in a collapsed core design.
Figure 1 - Network Layout - http://www.seeminglyrandom.info/dhcp/dhcp-1.jpg
The network will consist of 4 VLANs and require 5 address ranges. The
details of this setup can be found in the table below.
Figure 2 - VLAN/Hardware Layout w/ Address Scheme -
http://www.seeminglyrandom.info/dhcp/dhcp-2.jpg
The web server used in this example is a Catalyst 2950 switch, so the config
for that switch has also been included.
There are two forms of security used to restrict access and limit the
attacks caused by Rogue DHCP servers. The first thought is to go immediately
to 802.1x, since the devices support it, however being a public institution
this would limit availability and also require users to have usernames and
passwords, while not fully protecting from an accident rogue DHCP server
(for example from a VMWare client). The first item that is required is the
Cisco command switchport protected; this should be placed on all ports that
will be used for client access. To better explain the switchport protected
command we can reference a CiscoPress website
quote:
Source: http://www.ciscopress.com/articles/...29&seqNum=3
A protected port feature is used in those environments where no traffic can
be forwarded between two ports on the same switch. This way, one neighbor
connected to one port does not see the traffic that is generated by another
neighbor connected to the second port. The blocking of traffic (unicast,
broadcast, or multicast) only works when both ports are protected. When a
protected port is communicating with an unprotected port, the traffic is
forwarded in the usual manner. Once the ports are protected, traffic between
them can only be forwarded by a Layer 3 device.
This means that our clients will not know that each other exist. This is
requires because VLANs are still using layer 2 functions and will Forward,
Flood or Filter. If traffic from 192.168.1.1 came into our access-layer
switch on physical port 2, logical VLAN 2 and was bound for 192.168.1.2 on
physical port 3, logical VLAN 2 the traffic would be forwarded. 192.168.1.2
would automatically receive the information that 192.168.1.1 had sent. What
switchport protected will do is block that communication deny communication
between devices on the same Virtual LAN. The port protection will be dropped
when the frame hits the layer 3 device to become a packet.
That means that a packet originating at 192.168.1.1 (remember this was, for
example, Port 2 - VLAN 2) and bound for 192.168.2.1 (Port 4 - VLAN 3) will
not be protected using port protection. This is where our layer 3 switch at
the collapsed core and distribution layers comes into play. Placed on the
layer 3 switch are a series of access-lists which are combined to form a
VLAN Map. This VLAN Map allows us to filter Layer 2 bound data while using
Layer 3 protocols. In our example this will be DHCP. All we want to do is
eliminate rogue DHCP servers while continuing to allow all other traffic.
This will require 5 access-lists. The first list will allow traffic from
clients to port 67 on the DHCP server and the second list will be its
counter part allowing traffic from the DHCP server back to its clients on
port 68. The next two rules will limit our DHCP traffic. They will deny any
traffic bound for port 68 or 67. This will not apply to traffic originating
from or destined for the real DHCP server because the first rule that
matches will be applied and processing of the VLAN Map will stop. The last
rule will be an 'allow any any' this is because we don't want all our other
traffic to be blocked when the end of the access map is reached. Now we just
want to set the match statements. We want to forward anything that matches
our first to rules, while dropping anything matching the next two (Rogue
Protection) and again forwarding the traffic matching the last rule.
quote:
ip access-list extended AllowAll
permit ip any any
ip access-list extended DHCPtoClient
permit udp host 192.168.4.1 any eq bootpc
ip access-list extended DHCPtoServer
permit udp any host 192.168.4.1 eq bootps
ip access-list extended DHCPtoRogue
deny udp any any eq bootps
ip access-list extended DHCPfromRogue
deny udp any any eq bootpc
quote:
vlan access-map DHCPRogueBlock 10
action forward
match ip address DHCPtoServer
vlan access-map DHCPRogueBlock 20
action forward
match ip address DHCPtoClient
vlan access-map DHCPRogueBlock 30
action drop
match ip address DHCPtoRogue
vlan access-map DHCPRogueBlock 40
action drop
match ip address DHCPfromRogue
vlan access-map DHCPRogueBlock 50
action forward
match ip address AllowAll
These two simple steps will allow for almost complete protection from Rogue
DHCP servers on your network, while allowing for normal, uninterrupted
network communication for the remainder of your network.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Friday, September 30, 2005 7:59 PM
To: 'Victor Cappuccio'
Cc: 'Dennis J. Hartmann'; 'James Matrisciano'; 'Roy Dempsey';
ccielab@groupstudy.com
Subject: RE: Private vlans & 3550
Only protected ports cannot talk to each other. Anything else works like
normal!
_____
From: Victor Cappuccio [mailto:cvictor@protokolgroup.com]
Sent: Friday, September 30, 2005 11:54 AM
To: swm@emanon.com
Cc: 'Dennis J. Hartmann'; 'James Matrisciano'; 'Roy Dempsey';
ccielab@groupstudy.com
Subject: Re: Private vlans & 3550
Hi ..
So the anyone connected to to protected port can not talk to any protected
port ?
What about the ports that are connected on the same VLAN without the
configuration of the protected part, can they pass traffic to this protected
ports?
Can you please show us an Example about this in real life
Thanks for the Reply Scott
Saludos desde Venezuela / CYA in the BCamp - BTW do you like coffee
Victor
Scott Morris wrote:
It's "edge" as in, it can't be a trunk port. Consider your entire switch is
in two VLANs, half in VLAN 10 half in VLAN 20. Obviously the two VLANs
won't talk to each other unless you configure routing and SVIs. Beyond
that, INSIDE a VLAN, if we configure certain ports as "switchport protected"
then they will never ever talk to each other on an L2 basis. no unicast,
multicast or broadcast.
So the logic really isn't the same as a CE/VRF in the MPLS network. It's
only deployed at the access switch itself. If you had two different
switches involved, it really wouldn't have the same effect. Whereas in
"real" private VLANs the restrictions would follow.
HTH,
Scott
_____
From: Victor Cappuccio [mailto:cvictor@protokolgroup.com]
Sent: Friday, September 30, 2005 12:55 AM
To: Scott Morris
Cc: 'Dennis J. Hartmann'; 'James Matrisciano'; 'Roy Dempsey';
ccielab@groupstudy.com
Subject: Re: Private vlans & 3550
Quick Question
So only on Edge Ports?
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Fa0/2 Desg FWD 19 128.2 Edge P2p
What if are talking dot1q or ISL with another switch ?
or maybe a solution using VRF
What means the term Vlan Edge Ports == It's like a CEdge in MPLS? and this
ports looks like an Interface in a VRF?
Thanks
Scott Morris wrote:
They're listed in the release notes as an impending feature. You can do the
private vlan edge ports "switchport protected" though...
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Dennis J. Hartmann
Sent: Thursday, September 29, 2005 11:54 AM
To: 'James Matrisciano'; 'Roy Dempsey'; ccielab@groupstudy.com
Subject: RE: Private vlans & 3550
I've been reading this conversation and I wanted to share the fact
that private VLANs are NOT supported in the 3550. The 3560 and 3750 has
private VLAN support, but the 3550 does NOT (according to the feature
navigator www.cisco.com/go/fn and the latest documentation).
Cheers,
Dennis Hartmann
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
James Matrisciano
Sent: Thursday, June 02, 2005 12:31 PM
To: Roy Dempsey; ccielab@groupstudy.com
Subject: RE: Private vlans & 3550
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_1_11/conf
ig/pvlans.htm
jm
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Roy
Dempsey
Sent: Thursday, June 02, 2005 10:16 AM
Subject: Re: Private vlans & 3550
Sorry, my question should have been clearer. I think Scott may have read
between the lines anyway, and answered my question.
My current understanding is that a subset of private vlans is available and
testable (potected ports) but the full implementation of private vlans
(host, isolated, community etc) is not. The documentation seems to confirm
it, although the 3550s have the commands available.
So, as it stands, I should know protected ports. I'm also going to spend a
few minutes looking at how its implemented in the 3750 so I don't get any
nasty
shocks(http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12220
se/3750scg/swpvlan.htm),
and then I'll move on.
I think this looks like a great feature, BTW. I can think of plenty of
places I could use it.
Thanks all,
Roy
On 6/2/05, ccie2be <mailto:ccie2be@nyc.rr.com> <ccie2be@nyc.rr.com> wrote:
Lee,
I don't think private vlan's is available on 3550's although there are
plenty of other port security features.
If you have a link for private vlans on a 3550 could you post it
please?
TIA, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of Lee
Donald
Sent: Thursday, June 02, 2005 9:13 AM
To: Roy Dempsey; Cisco certification
Subject: RE: Private vlans & 3550
Roy,
It is available and it is fair game.
Start learning it !!!
-----Original Message-----
From: Roy Dempsey [mailto:roy.dempsey@gmail.com]
Sent: 02 June 2005 14:04
To: Cisco certification
Subject: Private vlans & 3550
Hi,
I'm not as clear about IOS versions on switches as I am on routers.
Anyone know if the private vlans feature is available on the 3550's
yet? If not is it likely to be? And if it does become available, does
it become fair game on the lab straight away, or should we get an
announcement?
--Regards,
Roy
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:17 GMT-3
