deny unknown users

Thu May 14 16:52:07 UTC 2009

Critical Questions:  What type(s) of switches do you use in your
network?
                     Do they support multiple VLans?
                     Can they assign client machines into specific VLans
based on MAC number?

If you do not want to go the 802.1x route, I have a solution we put
together for our student network that relies on recording and managing
MAC addresses.  It uses directory authentication (Kerberos driven off of
Active Directory) behind the scenes with captured DHCP (ISC version :-)
and DNS servers and a web site to challenge the potential client
one-time.  After successfully passing the challenge, the client's MAC
address and the credentials authorizing the use thereof are recorded and
the MAC, via switch-based rules, is placed into the appropriate VLan.
The system has "hooks" (well, sort of) that allow us to manipulate the
MAC post-hoc (ban it, quarantine it, force re-authentication, et
cetera).

The beauty of the system, as compared to 802.1x, is its flexibility (we
own it, we own the database structure, we own the distribution, we can
do what we want); its simplicity (you need to know a bit of PERL & you
have to protect the "database" because it is all "flat" text files); and
the lack of need for client software on any of the controlled machines
-- you just need your credentials, your MAC number, and access to a
browser & you can register (id est: take responsibility for) any machine
not already registered by someone else.  We can control the number of
machines the user can place on our network, the location(s) allowed, et
cetera.  Within the limits we establish, the user has the ability to
manipulate their "registrations" personally; we have the ability to
query the records and see what they did & when they did it...  We can
also allow "foreign" users into our system by pointing the registration
server to their directory as an "alternate" -- in more or less the same
manner one might add "secondary DNS" servers to a system.  Thus, if the
local radio station wants to send someone to cover a Basketball game on
campus and they need network access, we can simply add their directory
server (which must, of course, be accessible to us) into the mix and
they can authenticate their own MAC addresses.  When the need passes, we
simply remove the reference and the registrations and they again become
"unknown users" to us.

The main drawback, as mentioned elsewhere, is the potential for
"spoofing" an "authorized" MAC number.  In practice, at least on our
system, this possibility is slight.  For one thing, the user has to
"pick a switch" (they see it listed as a location) where the MAC will be
authorized.  At present, we allow them up to five (5) different
locations so that people living in large residence halls can take their
machine from-place-to-place.  The number of locations is controlled by a
configuration file; at some point, we'll assess how many locations the
"average" client uses and adjust the limits accordingly.  In the mean
time, anyone "spoofing" a MAC address has to "spoof" an address that is
already authorized for their specific location; otherwise, they have to
provide their own credentials to authorize the MAC number and that won't
work because the MAC in question is already recorded as "belonging" to
someone else.  

If they do "spoof" a MAC number authorized on their local switch,
problems start "cropping up" when the real owner of the MAC number goes
on line -- and we start getting calls.  Further, at least in the student
environment, the main reason for trying to "sneak online" is to violate
our network's AUP.  Usually, this involves some sort of file sharing.
We have a "bandwidth monitor" in place (also home brew) that puts all of
our users on a "sliding bandwidth budget" -- violate that, and you get
shutdown until your sliding 24-hour (configurable) window drops back
below the (configurable) limits.  This system now interfaces with the
MAC management system -- see the "hooks" comments above.  

Odds are good that a person "spoofing" someone else's MAC number for
nefarious reasons would "trigger" one of the monitoring systems
(bandwidth, intrusion, AV, etc) and get the MAC shut down.  This would
lead to a call from the real owner about "why is my Internet not
working" (the standard phraseology used whenever a computer gets banned
from the network).  Since our Network Management System (an actual
commercial product, not home-brew :-( ) tracks the locations where MAC
numbers appear, it is usually easy to figure out where/who has been
misbehaving.  (As a result, I often have some interesting "space cadet"
conversations with some of our users.)

We are in the enviable position of having a homogenous network right out
to the edge.  Consequently, we manipulate the edge switch.  If someone
were to do something like this in a "multi-vendor" environment, they
would either need multiple routines for the multiple vendors (note: we
do have some old routines for some of our old switches); or, they would
need to install a "control point" switch in the middle of the controlled
part of their network.  The latter option would be particularly true if
the flavor of switches they used in the bulk of their network did not
support the required VLan manipulation and/or the switch model was old
enough to not support secure communications protocols.  In the latter
case, placing the control switch at the center of the network might
allow one to manipulate it with an "out of band" communications channel,
thereby preventing someone "sniffing" telnet or "SNMP V1" packets to
crack the system.

Presently, our system is written to work with Alcatel-Lucent switches;
however, it is modular and, by replacing the short routine that talks
(via SNMP) to the controlled switch(es), you could easily adapt it to
any switch gear that supports "MAC Address rules" for VLans.  If you
don't want to use SNMP, we still have an earlier routine lying about
that SSH'd into the switches and issued CLI commands.  This
routing/technique should be adaptable to most any switch that can use a
character-mode command-line interface.  

[Note: we abandoned the scripted-login technique because of a limited
number of logins available to individual switches.  At the time, the
various monitoring systems manipulated the switches "directly" (they now
go through the MAC registration System's "hooks") creating a tendency
for one system to "have" the switch ("login limit reached; access
denied!") when another wanted access.  SNMP commands, being very short;
very quick; and, typically, requiring only one or two "hits" to do their
work, alleviated this problem.  Now, of course, only the MAC management
and NMS systems (and the occasional, mostly-human, network manager) ever
touch the switches directly; so the problem is moot.]

For those of you to whom this sounds familiar, it should.  I got the
seed-idea from NetReg.  While we re-wrote most of the routines from
scratch and no longer rely upon controlling the DHCP server to achieve
"security," the basic techniques used are quite similar.  

The time of this question is good:  I have been pondering releasing some
version of this into the GNU world.  If anyone is interested in looking
over / trying out what we've got, I'll pursue permission from my
superiors for doing that sooner rather than later.  (Assuming permission
and no particular early interest, the planned release schedule is end of
Summer.) 

Later,
--LP--

********************************************  
   LARRY PERKINS, Data Networking Mgr    
********************************************  
 Snail Mail:  Perkins/CCNSS
              Gonzaga University
              502 East Boone Avenue      
              Spokane, WA 99258-0092     

 EMail:       PERKINS at its.gonzaga.edu        

 VMail:       (509) 313-5961 
              (509) 328-4220 x5961       

********************************************  

-----Original Message-----
From: dhcp-users-bounces at lists.isc.org
[mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Chuck Anderson
Sent: Thursday, May 14, 2009 6:29 AM
To: dhcp-users at lists.isc.org
Subject: Re: deny unknown users

On Thu, May 14, 2009 at 10:04:48AM +0700, winan888 at cbn.net.id wrote:
> I need to deny unknown users who knows our LAN IP address to login to
our
> LAN.. any body have solution for this?

Do your switches support DHCP Snooping?  If so, you could turn that on 
and only allow known-hosts to get an address via DHCP.  Combine that 
with Dynamic ARP Inspection and IP Source Guard, and maybe MAC Source 
Guard or MAC Security on each edge switch port.  It isn't perfect, 
because someone could spoof a known allowed MAC address, but it is 
pretty good without being as intrusive as 802.1x or captive portals.
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users