Norberto Meijome <[EMAIL PROTECTED]> wrote: On Tue, 4 Apr 2006 18:22:42 -0700
Mark Jayson Alvarez wrote:
> Hi Nikos
> Nikos Vassiliadis wrote: On Monday 03 April
I mentioned DHCP registration - i found the link :
http://www.netreg.org/ it may do what you need.
I have already looked into it, as well as the CMU version of netreg which is
far more feature rich and matured. http://www.net.cmu.edu/netreg/
However, we are on the process of having a centralized LDAP directory of each
equipment (including ip, mac address, os, owner, property number etc.) Both
implementations uses a separate backend to store each machine's mac addresses.
We don't want to have redundant data. Also, during our discussion:
"Another problem I am seeing with this kind of setup is that it doesn't
someone from using other user's network information. There's not that much of
authentication happening in the process of dhcp. The server only looks if the
mac address is already registered(in my case, a simple ifconfig will allow me
to change my mac address to that of a registered user). There are a couple of
suggestions and workarounds to this however, and with these at hand, were're
only left with that redundancy issue.."
> Our main problem is that in our company, each user has his own
> workstation(no one else uses it).. However, due to poor
> implementation of ip allocation strategy, any user can change his ip
> to whatever ip address he wants, thus it would be hard for us to
> really monitor who is doing this and who is doing that (because it
> would be useless to see the ip address of the one who's eating up or
> bandwidth or doing p2p when we cannot determine who is this user this
> ip belongs to.
have you considered changing the policy in this regards? do users need
that much control over their own workstation?
According to the policy, the NMG is the only responsible for software
installation, removal, patching etc of each workstation.. However, the MIS has
very few manpower, they cannot have full control over all of the user's
workstation. That's why we have proposed another policy that the user will be
held responsible for every outcome that will be originating from his machine...
be it p2p, or worm flooding.
> This leads us to our decision to have every user
> assigned a static ip address and have him register his mac address,
> all stored in ldap directory, and have him authenticate to the pc
> router first before being allowed to access any server. Authpf is
> somewhat close to this idea but perhaps it was designed for
> environment wherein users have no permanent workstation, or user can
> come from any location, even outside the company(at home).... I have
> created a draft of my proposed solution:
> First, user will
> authenticate to a web based login form which is tied up against the
> ip[f|fw|tables] ruleset.
can you run iptables on BSD?
| > When the user submits the form, the cgi will
> then verify if the user is really who he claims to be by doing an
> ldapbind using the credentials provided. Also, the script will check
> if the request is coming from an ip address that is assigned to that
> user, by comparing it to his ldap attributes (somewhat prevents users
> from using other user's ip address).
>If everything goes well, the
> script will happily change the router's firewall ruleset to allow the
> user to pass thru. (note that in our setup, we have allocated a
> single class C ip block for all the staffs(120) (no need to have
> separate blocks since all policies applies to all).
> Also, we have
> placed all the servers (mail, proxy, file, printer, im etc) in a
> different block to make sure that authentication will happen first
> before a user is allowed to access any of those servers.
and your pcrouter is the gateway between the users and the servers,
right? and different physical segment too
Yup.. just to make sure that they will have to get authenticated first before
using any network services.. If they are known, that is the time when
monitoring and accounting will make sense (since it is useless to know the ip
address of the one doing p2p when we can't find out the user whom this ip is
> Next, we
> will also provide a logout form(the same as logging out from ssh
> session in authpf) so that the ruleset can be reverted back when the
> user does not want to access any network server anymore. The problem
> with this is that users may be too lazy to logout to the network
> authentication.. In authpf, even the user did not logout from his ssh
> session, when he turns off his computer, the ssh session will
> automatically be terminated. I'm thinking perhaps I can have a nagios
> server constantly monitoring each user's network connectivity and
> then changing the firewall ruleset once the user's machine is
what if they leave their PC on overnight downloading / uploading files?
what if they leave their PC on , but logged out, so anyone else can
walk in and log in and use the already authorised pc? you may want to
have something that disables the firewall rule when the user logs out
(nagios agent on the client checking if the user is logged in,etc...)
> Another problem I am thinking is that, when a user
> has already authenticated to the router and have his ip address
> verified and has been allowed in the firewall, another smart user
> might immediately change his ip/mac address to that of the
> authenticated user, and thus making it hard to track his network
> activity again..
and this will affect also the other user's connectivity, so there would
be some disruption.
I am assuming that you have unmanaged switches.... otherwise you could
should be able to create ACLs on the switch so only a client MAC
connects to each port and avoiding the 'switched IP' issue
Managed switches is not an option in our workplace. We don't have that much of
luxury to spend on them. We have existing infrastructure where in unmanaged
switches are cascading everywhere... That is why we have decided to just put
them in a single block and create a standard policy for everyone..
> I'm still going to investigate if arpwatch can fill
> this need....
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"