From: Robert Lowe (Robert.H.Lowe@lawrence.edu)
Date: Thu Apr 08 2004 - 12:28:54 CDT
Mike Husmann wrote:
> David,
> I'm also running Netreg on a flat network - the only router we have
> is the firewall on the Internet.
>
> Router issue:
> What I've done is to set up the unregistered pools to not receive a
> default gateway - the entry is simply left out of the dhcpd config
> file for those pools.
Security by obscurity is no security at all. You have to establish
ACLs on your firewall to block outbound access for these pools. If
you were smart, then the pools can be uniquely covered by a network
mask. If you weren't, then, well... it's an exercise for you to
correct that.
> Subnetting issue:
> I do have two subnets running on the physical network (without a
> router), and I have the netreg box set up with an IP address on each
> subnet, and it works fine - unregistered clients get an IP address
> with the netreg box as the dns server, and that's about it. Once
> they register, they get a valid config with the real dns servers and
> the firewall for a router.
>
> Manual Registration by admins:
> If you want to do that, then you really don't need the entire
> netreg package - the ability to deny unknown clients is built in to
> the ISC Dhcp server (which netreg uses). If you want to go that way
> and not use netreg, but register clients by hand, you can simply set
> up one subnet with a valid configuration limited to "registered"
> users only, and use the "non-authoritative" global option to tell the
> dhcp server not to answer to requests that don't apply to it. This
> way, it will only hand out a valid config to those who are in the
> list, and will simply ignore DHCPDISCOVER packets from unknown
> clients...
Not DHCPDISCOVER, but DHCPREQUEST, i.e. not unknown clients, but for
unknown networks. When authoritative, the server should be configured
with information about all networks, and will send DHCPNAKs to clients
requesting addresses it doesn't know about, forcing the client to start
over with DHCPDISCOVER. Just use pools specifically for known and
unknown clients.
Three things for David:
1. Use NetReg *if* you want to force users of your network through
one-time authentication (registration) prior to initial use.
2. If you need to track problems back to a user, rather than just
an IP or MAC address, use NetReg, or a manual registration process,
otherwise just use pools for known and unknown clients.
3. NetReg cannot identify endstations with viruses. If can be configured
to do some vulnerability scanning, but this is not the same thing.
-Robert
> If there is anything wrong about the way I have things set up, or
> if anything is insecure, please let me know!
>
> Hope this helps,
>
> Mike
>
> ---- Original Message ----
> From: david@santafe.edu
> To: netreg@southwestern.edu
> Subject: Re: NetReg: Netreg on a LAN
> Date: Wed, 7 Apr 2004 17:14:14 -0600
>
>
>>Hi Mike-
>>
>>Yes, your second idea seems to be plausible. We could "simply"
>>subnet
>>our LAN, in which case we WOULD need a router and NetReg would be in
>>its element.
>>
>>The first idea is not applicable because we don't care if people go
>>to
>>the greater internet. We just don't want them to have free rein
>>within
>>our firewall.
>>
>>It might be acceptable for us admins to manually register new
>>systems,
>>and have the DHPC server just hand out bad IP addrs or no addr at all
>>
>>for unregistered systems. So the fact that the Netreg server is
>>unavailable is not so very bad.
>>
>>I hope this thread will continue...
>>
>>-David Borton
>>
>>On Apr 7, 2004, at 3:22 PM, King, Michael wrote:
>>
>>
>>>Hi David
>>>
>>>
>>>First of all, you can hand out fully routable ip's via Netreg for
>>>unregistered address, and you can just block them on the firewall.
>>
>>>This
>>>is the orginal config, and if you look at the primary distribution,
>>
>>I
>>
>>>believe the config files reflect this.
>>>
>>>Second.. A DHCP server has to hand out an IP address, otherwise,
>>
>>you
>>
>>>can't contact the Netreg server to register.
>>>
>>>Now...
>>>Multiple subnet can exists on the same wire. We have both our
>>>registered and unregistered address on the same wire. The key work
>>
>>is
>>
>>>a
>>>"secondary" interface in cisco speak.
>>>
>>>Did I give you enough info to hang yourself yet? Or are you still
>>
>>with
>>
>>>me.
>>>
>>>Mike
>>>
>>>
>>>>-----Original Message-----
>>>>From: owner-netreg@southwestern.edu
>>>>[mailto:owner-netreg@southwestern.edu] On Behalf Of David Borton
>>>>Sent: Wednesday, April 07, 2004 4:44 PM
>>>>To: netreg@southwestern.edu
>>>>Subject: NetReg: Netreg on a LAN
>>>>
>>>>
>>>>Hi folks,
>>>>
>>>>I'm new to NetReg and haven't implemented it yet. I hope someone
>>
>>can
>>
>>>>answer my basic capability question.
>>>>
>>>>Reading the very nice doc by Patrick M. Jacques, I see that NetReg
>>>>works by giving a non-routable IP address to the unregistered user
>>
>>or
>>
>>>>assigning them a bogus DNS server.
>>>>
>>>>I am not sure if that will work here at my Institute, where
>>>>we are all
>>>>on a single LAN, visitors and permanent hosts alike. The only
>>
>>router
>>
>>>>is a firewall between us and the internet. Our main desire
>>>>is to make
>>>>sure that visitors who bring in viruses can be identified,
>>>>and prevent
>>>>visitors (there are a lot of them, and they bring in their own
>>>>Windows/Mac/Linux laptops) from using our LAN and resources until
>>>>virus-checking can be applied.
>>>>
>>>>It would seem to do little good to prevent them from being
>>>>routed since
>>>>we have no internal routers.
>>>>
>>>>Maybe NetReg could be adapted so that the DHCP server returns no
>>
>>IP
>>
>>>>address at all for unregistered folks?
>>>>
>>>>Thank you all,
>>>> David Borton
>>>> Computer Systems Manager
>>>> Santa Fe Institute
>>>> 505-946-2716
**********************************************************************
To unsubscribe from this list, send an e-mail message to
majordomo@southwestern.edu containing a single line with the words:
unsubscribe netreg
Send requests for assistance to: owner-netreg@southwestern.edu
**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu Aug 12 2004 - 12:01:45 CDT