From: Church, Chuck (cchurch@netcogov.com)
Date: Sat Dec 24 2005 - 16:36:26 GMT-3
Seems like a few different ways to do this in a more secure way:
Don't do dynamic trunk negotiation. A PC plugging into the port won't
understand tagged frames. Make sure you're not using the native VLAN.
Some NICs can do dot1q tagged frames though. Using ISL should be able
to block this.
If the switch can do layer 3, like a 3550, why not let it route between
VLANs on it, and use a separate /30 subnet/VLAN to uplink to the
upstream switch? There'd be no DHCP on the link, and you could enable
port security on the upstream switch to allow only the MAC belonging to
the switch in the conf room.
Just a few thoughts...
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 864-266-3978
cchurch@netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Curt Girardin
Sent: Friday, December 23, 2005 5:18 PM
To: Curt Girardin; Mike Louis
Cc: ccielab@groupstudy.com
Subject: RE: Re: Secure trunk links
Usually another switch... We'll often get "same-day" notice that someone
needs to use a conference room for a couple of weeks for training
purposes. They'll put 20 or so computers in one room, and since they
are for training purposes, they usually need the same access/vlan
assignments as normal production computers. That's just one example...
So far it doesn't look like there is much out there that really suits my
situation, so it's looking like I'm going to have to start playing some
politics to get the business to follow best practices... And realize
that there is a real need for security and best practices,
Thanks,
Curt
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Mike Louis
Sent: Friday, December 23, 2005 8:15 AM
To: ccielab@groupstudy.com
Subject: Fwd: Re: Secure trunk links
Mike Louis CCNP,CCDA
Network Engineer
Granville County Schools Technology Team
919-693-4613 (office)
919-693-3791(fax)
919-691-0682(mobile)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Granville County School System does not discriminate on the basis of
race,color, national origin, sex, disability,religion, or age in its
programs or activities.
If you have an inquiry regarding the nondiscrimination policies, please
contact: Assistant Superintendent for Human Resources and Operations
Granville County Schools,Oxford, North Carolina 27565, 919-693-4613 <<<<
GWAVASIG >>>>
Date: Fri, 23 Dec 2005 08:14:28 -0500
From: "Mike Louis" <louism@gcs.k12.nc.us>
To: <tveillette@myeastern.com>
Subject: Re: Secure trunk links
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
What is the trunk link terminating on in the conference room area?
Another switch, ip phone, server?
Mike Louis CCNP,CCDA
Network Engineer
Granville County Schools Technology Team
919-693-4613 (office)
919-693-3791(fax)
919-691-0682(mobile)
>>> "Todd Veillette" <tveillette@myeastern.com> 12/23/05 12:32 AM >>>
As another option, is put all common areas in the proverbial internet
only vlan - out of band in our case. Its is dynamic for trusted users as
we VPN to what ever network as need dictates.
-TV
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'Curt Girardin'" <curt.girardin@chicos.com>;
<ccielab@groupstudy.com>
Sent: Thursday, December 22, 2005 9:23 AM
Subject: RE: Secure trunk links
> Well... I guess the first thing I'd ask you is why you wanted to put
> a trunk into a conference room anyway... :)
>
> VPMS isn't bad, providing you have a server. But that's not a trunk
port.
> That's a dynamically assigned access vlan.
>
> 802.1X requires client software. Other switches don't have client
> software.
> So that doesn't help.
>
> Being that you're a trunk port you're moving things at Layer 2 which
> means you won't rewrite the MAC headers for everything, so MAC-based
> port security likely isn't a help. (besides, I believe it's not
> allowed on trunk ports, at least not earlier IOS releases and certain
> switch types). There are very specific requirements for when port
> security is allowed on a trunk, and that just covers a MAC list in
> general not the specific one connected on the other side of the link.
>
> Soooo... From a security perspective, you shouldn't have dynamic
> ports at all. You shouldn't have trunk ports in open areas. If you
> have some true need to enable trunking to some area like a conference
> room, I would set it up to only allow particular VLANs across
> (whatever one(s) are truly
> needed)
> and make sure that I designed the network so that they are different
> than any of my other VLANs. That way you can have routing filters in
> place to restrict traffic and make sure you don't have some malicious
> user lurking around.
>
> There's not really any pat answer there. But you need to assess what
> is supposed to be happening.
>
> HTH,
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of Curt Girardin
> Sent: Thursday, December 22, 2005 8:11 AM
> To: ccielab@groupstudy.com
> Subject: Secure trunk links
>
> Team,
>
> Is there a way to authenticate or secure a trunk link between
switches?
> I'm not talking about VTP, but the links themselves...
>
> For example, every switchport in my business is running either
> port-security, VMPS, or 802.1x to keep the bad guys out.... If I put a
> switch into a public area, such as a conference room, there is nothing
> preventing a malicious user from plugging into the trunk port that
> feeds the switch in the conference room and having full-access to the
> network.
>
> Thanks,
>
> Curt
>
> ______________________________________________________________________
> _ 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 : Mon Jan 09 2006 - 07:07:52 GMT-3