NuFW: Single sign-on meets firewall (Linux-Watch)
Where NuFW steers away from commonplace firewalls is by bringing the notion of user identity to the firewall's security rules. With most firewalls, the rules on what network ports are enabled or disabled is determined by the computer's network address... With NuFW, the firewall permissions follow an authenticated user instead of a PC's address."
Posted Jan 9, 2007 20:40 UTC (Tue)
by rfunk (subscriber, #4054)
[Link]
Posted Jan 9, 2007 21:15 UTC (Tue)
by ccyoung (guest, #16340)
[Link] (12 responses)
"On the PC side, users need to use a client program"
even cooler would be if it could use a browser to login. would this be possible?
Posted Jan 9, 2007 21:56 UTC (Tue)
by jhardin@impsec.org (guest, #15045)
[Link] (3 responses)
Probably not. At a guess without looking at the actual tools, the PC client program serves to map ports to users and/or programs. Simply logging in via a browser wouldn't achieve this.
I can see the need for this on Windows, but what I don't understand is why on *nix they didn't just leverage the existing identd?
Posted Jan 9, 2007 22:05 UTC (Tue)
by rfunk (subscriber, #4054)
[Link] (2 responses)
Posted Jan 10, 2007 1:43 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
Posted Jan 10, 2007 2:45 UTC (Wed)
by drag (guest, #31333)
[Link]
Like with Kerberos you have the client tell the server what the user is, but only the user and the kadmin server are going to know the password required to encrypt then decrypt the initial ticket. (then the credentials are stored in temporary file were they are valid for 8 hours or so)
Posted Jan 10, 2007 15:48 UTC (Wed)
by vstinner (subscriber, #42675)
[Link] (7 responses)
The client sends all informations of the connections (IP address, TCP
Posted Jan 10, 2007 16:15 UTC (Wed)
by jhardin@impsec.org (guest, #15045)
[Link] (6 responses)
That comment worries me, as it seems to indicate an incomplete grasp of the trust issues involved. Guessing the TCP connection details isn't the attack vector. Correctly identifying the user ID that owns that connection is the attack vector. Remember, you're not trying to prevent connection hijacking or a DoS, you're trying to authorize traffic crossing the network boundary based on the user who owns that traffic.
What's to prevent me from writing a client that responds with whatever user ID I want - for example, the user ID of the company's network administrator, who could be presumed to have much greater access permissions than rank and file users?
(Again, I haven't actually looked at the software myself, so if it incorporates something like cryptographic authentication of the client executable's checksum, then I'm simply unaware of it rather than claiming it won't work.)
Posted Jan 10, 2007 16:30 UTC (Wed)
by Regit (guest, #31516)
[Link] (5 responses)
If you have a client that answer for other peoples, you take the responsabilites of other peoples actions. This is the same as give intentionnaly your password to them.
You can do it, but this is not "legal".
Posted Jan 10, 2007 17:27 UTC (Wed)
by rfunk (subscriber, #4054)
[Link] (4 responses)
Posted Jan 10, 2007 17:33 UTC (Wed)
by Regit (guest, #31516)
[Link] (3 responses)
NuFW does not trust the client. It checks login/password and then associates the packets from the client with the given login. You can not spoof the admins unless you know their passwords.
Posted Jan 10, 2007 19:11 UTC (Wed)
by jhardin@impsec.org (guest, #15045)
[Link] (2 responses)
Exactly where is this check performed? If it is performed by the client then NuFW *IS* trusting the client.
Does the NuFW client pass the username and password (securely, I hope) to the firewall server for authentication and then get back a token that is used thereafter, or is something like Kerberos used? If so, good.
Posted Jan 10, 2007 19:21 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
Then service should send a challenge response back that is encrypted with the user's password or other shared secret. Or maybe encrypted with the user's public key in a GPG shared key sceme or something like that.
Something...
Posted Jan 10, 2007 22:41 UTC (Wed)
by Regit (guest, #31516)
[Link]
When this initial authentication phase is done, the user sends authentication packet (packet which try to authenticate IP packet) other the TLS tunnel. These auth packets are automatically associated to the user as packet is coming from an authenticated TLS tunnel.
Thus, at *NO* moment, NuFW trusts the user. It associates packets to user after the user has proven (with correct credentials) who he is.
Posted Jan 11, 2007 6:21 UTC (Thu)
by jd (guest, #26381)
[Link] (1 responses)
If you have a client-side digital certificate associated with a specific
user, can anyone enlighten me as to why they would need to "sign on"? If
client and server are required to have valid certificates and the client
public certificate is either required to be on an approved list or not on
a denied list, then your connection IS your sign-on. You have no need of
another process.
There is another problem with "sign-on", in that it typically requires a
stateful system to know that you have, indeed, signed on. With a
certificate-based system, you merely need to add what certificate is in
use, and a strong hash for your digital signature. The firewall can do an
indexed lookup of the certificate and then validate the signature. It
need not preserve the state.
Another method, similar to the above, would be to secure both the machine
AND the user, but NOT the IP address. This would run an IPSec connection
between the host machine and the firewall (thus validating the host as
the valid endpoint to talk to) and then run SSL or TLS between the user
application and the upper-layer firewall mechanism. Both sides would need
to use authenticated IPSec and authenticated SSL, so each of these needs
some shared secret OR some digital certificate that can be validated then
split into a private key and public key.
This requires nothing new on any of the stacks and requires minimal
change to the firewall software. This has several advantages. First, the
information needed to get past the firewall is not public. Second,
because you do NOT validate IP, the user can do funky stuff and the
system will still work. Third, although there is arguably more state
information, it is standard state information. It doesn't require
the use of non-standard hardware or software, it doesn't require a
browser to have a specific feature, it doesn't even require a browser.
This makes it perfect for embedded devices, $100 laptops, and so on.
Posted Jan 11, 2007 7:30 UTC (Thu)
by Regit (guest, #31516)
[Link]
PS: Arguments are mainly taken from: http://www.nufw.org/Frequently-Asked-Questions.html
While not commonplace, this concept of firewalling according to user identity isn't
exactly new; KarlNet's
KarlBridge
and KarlRouter firewalls did it over a decade ago.
NuFW: Single sign-on meets firewall (Linux-Watch)
sound very cool, butclient
> "On the PC side, users need to use a client program"client
>
> even cooler would be if it could use a browser to login.
> would this be possible?
Because identd is untrustworthy. Why believe what the client machine tells you? identd
but that's exactly what this proposal does. they use their own client-side piece instead of identd, but in both cases they are relying on the client to tell the firewall what userid the packet belongs to.identd
I have no clue how this works.. but isn't there going to be a shared secret?identd
When a new packet is received, NuFW asks the clients to send the new client
outgoing connections awaiting authorization. It only sends query to the
clients connected with the same address than the source address of the
packet. It's not possible to list new/active connections with a web
browser, that's why we need a client program.
ports, TCP identifiers, etc.). It's very hard (not possible?) to guess
them, so we can trust client informations.
> The client sends all informations of the connections (IP address, TCPclient
> ports, TCP identifiers, etc.). It's very hard (not possible?) to guess
> them, so we can trust client informations.
I completly disagree with you.client
If I'm a lowly unprivileged user and I want the same access that the network administrator client
has, I'll be happy to have my client claim that I'm that admin, if it gets me more access.
Well, then you need to provide the login/password of the admin.client
> NuFW does not trust the client. It checks login/password ...client
Instead of sending username and password over the network it would be better just to send the username.client
Authentication is done via SASL inside a TLS tunnel. NuFW is thus responsible of login/password check (check is done on an external database like an LDAP or any classical other method). This insures that the user has given correct credentials.client
Firewalls based on IP are a problem, as they don't support a wide range
of perfectly valid network operations (MIP and NEMO, for example), are
using a very weak form of host-level authentication and those that are
stateful are generally crappy when it comes to gateways onto the Internet
that load-balance between them (a very likely event for users on
Internet2, I imagine).
NuFW: Single sign-on meets firewall (Linux-Watch)
Yes, but :NuFW: Single sign-on meets firewall (Linux-Watch)
- VPN authentication does not work with multiusers computers (well, it *works*, but does not differentiate one user from another)
- VPN encryption has a huge overload in Gigabit system
- In a enterprise VPN linking different sites, authentication by VPN brings a double encapsulation which can overload link capacity by increasing packet size.
- VPN does not really guarantee the identity of users because users computer can act as a router for other computers