From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Fri Sep 30 2005 - 22:18:38 GMT-3
Cool Dennis & Thanks a lot to all..
Dennis J. Hartmann wrote:
>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
>
>To: ccielab@groupstudy.com
>
>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
>
>
>
>
>
>
>
>_______________________________________________________________________
>
>
>
>Subscription information may be found at:
>
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>_______________________________________________________________________
>
>
>
>Subscription information may be found at:
>
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
>
>--
>
>Regards,
>
>Roy
>
>
>
>_______________________________________________________________________
>
>Subscription information may be found at:
>
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>_______________________________________________________________________
>
>Subscription information may be found at:
>
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>_______________________________________________________________________
>
>Subscription information may be found at:
>
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>_______________________________________________________________________
>
>Subscription information may be found at:
>
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:17 GMT-3
