NuFW: Single sign-on meets firewall (Linux-Watch) [LWN.net]

Linux-Watch looks at NuFW. "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."

client

Posted Jan 9, 2007 21:15 UTC (Tue) by ccyoung (guest, #16340) [Link] (12 responses)

sound very cool, but

"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?

client

Posted Jan 9, 2007 21:56 UTC (Tue) by jhardin@impsec.org (guest, #15045) [Link] (3 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?

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?

identd

Posted Jan 9, 2007 22:05 UTC (Tue) by rfunk (subscriber, #4054) [Link] (2 responses)

Because identd is untrustworthy. Why believe what the client machine tells you?

identd

Posted Jan 10, 2007 1:43 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

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

Posted Jan 10, 2007 2:45 UTC (Wed) by drag (guest, #31333) [Link]

I have no clue how this works.. but isn't there going to be a shared secret?

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)

client

Posted Jan 10, 2007 15:48 UTC (Wed) by vstinner (subscriber, #42675) [Link] (7 responses)

When a new packet is received, NuFW asks the clients to send the new
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.

The client sends all informations of the connections (IP address, TCP
ports, TCP identifiers, etc.). It's very hard (not possible?) to guess
them, so we can trust client informations.

client

Posted Jan 10, 2007 16:15 UTC (Wed) by jhardin@impsec.org (guest, #15045) [Link] (6 responses)

> The client sends all informations of the connections (IP address, TCP
> ports, TCP identifiers, etc.). It's very hard (not possible?) to guess
> them, so we can trust client informations.

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.)

client

Posted Jan 10, 2007 16:30 UTC (Wed) by Regit (guest, #31516) [Link] (5 responses)

I completly disagree with you.

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".

client

Posted Jan 10, 2007 17:27 UTC (Wed) by rfunk (subscriber, #4054) [Link] (4 responses)

If I'm a lowly unprivileged user and I want the same access that the network administrator
has, I'll be happy to have my client claim that I'm that admin, if it gets me more access.

client

Posted Jan 10, 2007 17:33 UTC (Wed) by Regit (guest, #31516) [Link] (3 responses)

Well, then you need to provide the login/password of the admin.

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.

client

Posted Jan 10, 2007 19:11 UTC (Wed) by jhardin@impsec.org (guest, #15045) [Link] (2 responses)

> NuFW does not trust the client. It checks login/password ...

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.

client

Posted Jan 10, 2007 19:21 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

Instead of sending username and password over the network it would be better just to send the username.

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...

client

Posted Jan 10, 2007 22:41 UTC (Wed) by Regit (guest, #31516) [Link]

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.

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.

NuFW: Single sign-on meets firewall (Linux-Watch)

Posted Jan 11, 2007 6:21 UTC (Thu) by jd (guest, #26381) [Link] (1 responses)

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).

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.

NuFW: Single sign-on meets firewall (Linux-Watch)

Posted Jan 11, 2007 7:30 UTC (Thu) by Regit (guest, #31516) [Link]

Yes, but :
- 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

PS: Arguments are mainly taken from: http://www.nufw.org/Frequently-Asked-Questions.html