nufw-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nufw-users] Holly cow!! Why didn't anyone tell me nufw exists!!!


From: Vincent Deffontaines
Subject: Re: [Nufw-users] Holly cow!! Why didn't anyone tell me nufw exists!!!
Date: Wed, 05 Apr 2006 10:56:01 +0200
User-agent: Mail/News 1.5 (X11/20060318)

Mark Jayson R. Alvarez wrote:
> Hello!!
>
> I have been sending tons of emails to various mailing list regarding the 
> management of our Local Area Network. I have already looked into serveral 
> tools such as authpf, netreg, etc. I even have my presentation slides ready 
> after carefully evaluating our needs. I was about to present my proposed 
> solution when I landed in nufw's homepage.. I was surprised to find out that 
> someone has already come up with such requirements as ours. Now, I just 
> joined this mailing list to make sure that nufw is really the solution to our 
> problem..
>
> Ok, here is our situation.
>
> Our LAN consisting of 126 users have a very poor ip allocation strategy such 
> that users can jump to any ip block he wants making it really hard to track 
> down who is doing this and who is doing that.
>
> Or goal is to monitor all network activities of each workstation (ip address) 
> and be able to determine who's workstation is this. (DHCP with internal DNS 
> can easily be bypassed by smart users)
>
>
> My proposed solution is to have each user be assigned a static ip address, 
> with other details such as os, mac address, property no. etc all stored in 
> ldap directory. Tie up an authentication to the firewall ruleset and can also 
> do some ip/mac verification by doing ldap lookups.
>
> To accomplish this, since we don't have that much number of staffs, I 
> suggested to have a single class C ip block for all the staffs. Having 
> different ipblock groupings for staffs is not needed anymore. There's not 
> that much difference when it comes to network usage policy for all the 
> staffs. Then we put the network servers in another block just to ensure that 
> authentication will happen first before a user access those servers.
>
> Authentication is needed because:
>
> "If we are to monitor all of the network activities of each user, we must 
> make 
> sure that no one is trying to hide themselves by illegally using another 
> user's ip/mac address, or no one have accidentally used another user's ip 
> address. By doing an authentication against the pcrouter, we are ensuring 
> that every device that will be connecting to our network is registered and 
> known, so that all of his network activities can be correctly monitored."
>
> authpf lacks this sort of ip/mac verification because I guess it was designed 
> with a multi-user workstation environment in mind(in our case 1 workstation, 
> 1 ip, per 1 user).
>
> netreg is also not a good idea either.
>
> In our conversations:
> ________________________________________
> Basically, the netreg process looks like this.
>
> 1. User will login to the network registration page, using his 
> username/password(probably an ldap account).
> 2. From there, the user will fill up the registration form with his, mac 
> address, other info, etc...
> 3. After successful registration, dhcp client on the user's machine will be 
> enabled.
> 4. When the client tries to obtain the network settings from the dhcp server, 
> the server will first try to verify if the hardware address where the request 
> is coming from is already registered. If it is, then the entire dhcp 
> transaction will be carried out... unless otherwise, the request will be 
> denied.
>
> Another problem I am seeing with this kind of setup is that it doesn't 
> prevent 
> 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..
> ----------------------------------------------------------------------------------------------------
>
> I'm planning to write some custom login scripts that are tied up against the 
> firewall ruleset which can do ldap lookups also. However, as far as I can 
> understand.. nufw can already accomplish this need..
>
> Is nufw really the solution to our problem?
>
> Thanks!
> -jayson

Greetings, Jayson,

Yes, I think NuFW can help you solve your authentication problems quite
simply.
Most admins have this same problem : "how to make sure this user keeps
on this IP?"

We at NuFW believe this is a bad question. Keep in mind that IP/DHCP/Mac
address were never designed to provide any kind of authentication. They
are just technical addresses, used by computers so that "it works".

On the other hand, "classical" firewalls only know about IP objects, not
about users. But they are used to implement a security policy that is
about users, not IPs. So this leads to the classical problem you are having.


NuFW "breaks" the approach "one IP = one user". We prefer to let the
firewall "see" the user at the source of each connection. This way, no
matter what their IP address is, we know the user cannot spoof their
identity. How the firewall sees user's identity is described in our
documentations, (http://www.nufw.org/Principles.html can be good for an
overview).

So, NuFW lets you require the user to provide credentials for each
connection they try to open. And we keep log of those. As time goes by,
if you get to use NuFW, you will tend to not look at clients' IP
addresses so much anymore. Why bother, when you can get layer3 logs with
userID included? :) (Demo at http://nulog-demo.inl.fr/ , click "user
stats" and see IP filter logs containing userIDs, etc.).

I hope this helps,
Have fun with NuFW.
And have no hesitation if you have any problem installing/testing NuFW.
This channel is designed for this kind of help

Regards,

Vincent





reply via email to

[Prev in Thread] Current Thread [Next in Thread]