| |||||||||||
clientclientPosted Jan 10, 2007 16:15 UTC (Wed) by jhardin@impsec.org (guest, #15045)In reply to: client by haypo Parent article: NuFW: Single sign-on meets firewall (Linux-Watch)
> The client sends all informations of the connections (IP address, TCP
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.)
(Log in to post comments)
client Posted Jan 10, 2007 16:30 UTC (Wed) by Regit (guest, #31516) [Link] 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] If I'm a lowly unprivileged user and I want the same access that the network administratorhas, 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] 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] > 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 (subscriber, #31333) [Link] 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.
|
|||||||||||