Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: You have three issues: Shared Authentication... Kerberos or LDAP File Sharing Looked at GFS? Could also use NFS I guess. Sigh. Look at autofs Security! NFS and LDAP by default do stuff in plain text... over an open network this plain sucks... Set up Freeswan on all the nodes. If you have control of or access to any DNS you can set them all up to use opportunistic encryption. Once this is in place, and the list of nodes (ie keys that are trusted) is made, then I'd be very happy to have single signon and NFS automounted home directories... even on disparate nodes across the internet. But only once they are all VPN'd. -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: You have three issues: Shared Authentication... Kerberos or LDAP File Sharing Looked at GFS? Could also use NFS I guess. Sigh. Look at autofs Security! NFS and LDAP by default do stuff in plain text... over an open network this plain sucks... Set up Freeswan on all the nodes. If you have control of or access to any DNS you can set them all up to use opportunistic encryption. Once this is in place, and the list of nodes (ie keys that are trusted) is made, then I'd be very happy to have single signon and NFS automounted home directories... even on disparate nodes across the internet. But only once they are all VPN'd. -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Wed, Apr 10, 2002 at 12:21:13AM +0100, Gareth Bowker wrote: On Tue, Apr 09, 2002 at 04:02:34PM -0500, Rob VanFleet wrote: On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? The point is that it's made accessible only from localhost. Whether this is by using a firewall to block connections from anyone else, using tcpwrappers or that it only binds to the lo interface. This last case (binding to lo): how would I go about doing that? Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 12:37:27PM +0200, Wichert Akkerman wrote: Previously Alan Shutko wrote: An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. There is also SFS which works very nicely indeed. After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 04:02:34PM -0500, Rob VanFleet wrote: On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? The point is that it's made accessible only from localhost. Whether this is by using a firewall to block connections from anyone else, using tcpwrappers or that it only binds to the lo interface. If someone has an exploit, rather than being able to exploit it remotely, they have to be running the exploit from the local machine. Gareth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
Previously Alan Shutko wrote: An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. There is also SFS which works very nicely indeed. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 12:37:27PM +0200, Wichert Akkerman wrote: Previously Alan Shutko wrote: An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. There is also SFS which works very nicely indeed. After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: After doing some reading about it, the only thing that turns me off to SFS is that you still have to run the usual NFS services for it to work. A large part of the reason I am seeking alternatives is that those services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 04:02:34PM -0500, Rob VanFleet wrote: On Tue, Apr 09, 2002 at 07:23:28AM -0700, Luca Filipozzi wrote: You run those service locally on each machine only. You don't make them available to other hosts. Sorry if I'm being completely dense here, but aren't the ports still open, even if they are only serving localhost? The point is that it's made accessible only from localhost. Whether this is by using a firewall to block connections from anyone else, using tcpwrappers or that it only binds to the lo interface. If someone has an exploit, rather than being able to exploit it remotely, they have to be running the exploit from the local machine. Gareth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
Hi, Just thought I'd chip inn some support for LDAP. Also a kerberos pointer: www.bayour.com has a very good ldap+kerberos howto for debian written by Turbo Fredrikson. Also you should check out directory administrator for admining your directory. A simple ldap client for administrating ldap users. Now, the last thing: Does anyone have a URL for the SFS fileserver system? Tarjei -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 10:36:17PM -0700, Luca Filipozzi wrote: this also allows crackers to access your userbase, unlike libpam-ldap, where you are not forced to allow userpassword read access to the database. The cracker just needs to hack this machine, read the password from config and voila, ur nt3w0rk has been 0wn3d! You don't need to put a binddn/bindpw into libnss-ldap if you make userPassword readable by all. libnss-ldap can bind anonymously. It's NIS-equivalent, however, so if the hashes are weak based on weak passwords, a dictionary attack is possible (just like NIS). heh, in this case you would be screwed without root permissions, anyone could make lookups to your ldap database and crack any of your boxes =) anyways, it does not matter if it's a DN-binded or anonymous connection, the password would be visible to the user and it would be possible to break the password. although, you are absolutely right, the anonymous bind is the equivalent of NIS... Also, if you were to use a binddn/bindpw, you wouldn't use the rootdn/rootpw. why not? the basic use for rootdn is to allow root to change any password in the system. (or did you mean admin DN, and it's password) Note for non-LDAP folk: userPassword is the hashed password, not the cleartext password. ahh, good note... it's just too obvious for me, i forget that it's not that obvious to others =) anyways this discussion is going outside the scope of the thread, the point being, use LDAP, it's re-usable.. you can build bridges to NIS from ldap, you can use it as your global addressbook. to put it simply, LDAP+TLS a good solution for the user distribution. =) Sami -- - Sami Haahtinen - -[ Is it still a bug, if we have learned to live with it? ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C - msg06267/pgp0.pgp Description: PGP signature
Re: NFS, password transparency, and security
On Sun, 7 Apr 2002, Luca Filipozzi wrote: I suspect that if all your boxes are running Debian that your life will be made easier by all the Debian kerberos packages. This is an interesting thread, and this comment just gave me an idea. What if you use FreeS/WAN (or really, any sort of IPsec)? It can be set up in a mode that's called opportunistic encryption that will use IPsec for communication when it's available and allow other traffic to proceed as normal. In this way, you won't care if things like LDAP (or even NIS) pass passwords around in cleartext, just as long as the workstation - file-server or authentication server connections are encrypted. Although I haven't done it, you should be able to run the server services bound to a specific IP that is only accessible via clients that have successfully IPsec-attached. 0.02, tony [EMAIL PROTECTED] | An ounce of perception, http://www.debian.org | a pound of obscure... |(Peart) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:22:12PM -0700, tony mancill wrote: What if you use FreeS/WAN (or really, any sort of IPsec)? It can be set up in a mode that's called opportunistic encryption that will use IPsec for communication when it's available and allow other traffic to proceed as normal. In this way, you won't care if things like LDAP (or even NIS) pass passwords around in cleartext, just as long as the workstation - file-server or authentication server connections are encrypted. Although I haven't done it, you should be able to run the server services bound to a specific IP that is only accessible via clients that have successfully IPsec-attached. For the NFS traffic, opportunistic encryption seems like a very intersting idea. There's no way I would use libpam-ldap without knowing *for certain* that it was going over a TLS/SSL connection, however. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 08:14:26PM -0700, Luca Filipozzi wrote: Two choices (I like lists :) ): (1) use libpam-ldap: i recommend this. Even though the current pam system is a pain to modify.. if you modify one file and it gets updated in the package it will nag about it.. you can't tell if it's a needed change or not, luckily i have heard rumours about new design for the pam system and i'm eagerly waiting for it to arrive =) (2) don't use libpam-ldap: You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). i don't recommend the above to anyone (do as i say, not as i do.. =) it will cause problems, you are forced to enter the database access password to the configuration, which you will then need to make readable to root, which in turn forces you to use nscd. There is nothing wrong with nscd, it's just plain stupid.. if you have a small database, there is no problem, but if you have a big database (max cached entries +1) you might start running in to trouble. apparently the caching mechanism is quite stupid and it can't just expire an entry becuse someone needs a new one.. =( this also allows crackers to access your userbase, unlike libpam-ldap, where you are not forced to allow userpassword read access to the database. The cracker just needs to hack this machine, read the password from config and voila, ur nt3w0rk has been 0wn3d! Sami -- - Sami Haahtinen - -[ Is it still a bug, if we have learned to live with it? ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C - pgpVDaoq2aJYv.pgp Description: PGP signature
Re: NFS, password transparency, and security
On Mon, Apr 08, 2002 at 08:23:17AM +0300, Sami Haahtinen wrote: On Sun, Apr 07, 2002 at 08:14:26PM -0700, Luca Filipozzi wrote: Two choices (I like lists :) ): (1) use libpam-ldap: i recommend this. I also recommend this. (2) don't use libpam-ldap: You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). i don't recommend the above to anyone (do as i say, not as i do.. =) it will cause problems, you are forced to enter the database access password to the configuration, which you will then need to make readable to root, which in turn forces you to use nscd. No, you don't. You can set the ACLs in slapd.conf for userPassword to 'by * read'. Sure, it's not a good choice. That's why I said that it is the equivalent of NIS. this also allows crackers to access your userbase, unlike libpam-ldap, where you are not forced to allow userpassword read access to the database. The cracker just needs to hack this machine, read the password from config and voila, ur nt3w0rk has been 0wn3d! You don't need to put a binddn/bindpw into libnss-ldap if you make userPassword readable by all. libnss-ldap can bind anonymously. It's NIS-equivalent, however, so if the hashes are weak based on weak passwords, a dictionary attack is possible (just like NIS). Also, if you were to use a binddn/bindpw, you wouldn't use the rootdn/rootpw. Note for non-LDAP folk: userPassword is the hashed password, not the cleartext password. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
Hi, Just thought I'd chip inn some support for LDAP. Also a kerberos pointer: www.bayour.com has a very good ldap+kerberos howto for debian written by Turbo Fredrikson. Also you should check out directory administrator for admining your directory. A simple ldap client for administrating ldap users. Now, the last thing: Does anyone have a URL for the SFS fileserver system? Tarjei -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 10:36:17PM -0700, Luca Filipozzi wrote: this also allows crackers to access your userbase, unlike libpam-ldap, where you are not forced to allow userpassword read access to the database. The cracker just needs to hack this machine, read the password from config and voila, ur nt3w0rk has been 0wn3d! You don't need to put a binddn/bindpw into libnss-ldap if you make userPassword readable by all. libnss-ldap can bind anonymously. It's NIS-equivalent, however, so if the hashes are weak based on weak passwords, a dictionary attack is possible (just like NIS). heh, in this case you would be screwed without root permissions, anyone could make lookups to your ldap database and crack any of your boxes =) anyways, it does not matter if it's a DN-binded or anonymous connection, the password would be visible to the user and it would be possible to break the password. although, you are absolutely right, the anonymous bind is the equivalent of NIS... Also, if you were to use a binddn/bindpw, you wouldn't use the rootdn/rootpw. why not? the basic use for rootdn is to allow root to change any password in the system. (or did you mean admin DN, and it's password) Note for non-LDAP folk: userPassword is the hashed password, not the cleartext password. ahh, good note... it's just too obvious for me, i forget that it's not that obvious to others =) anyways this discussion is going outside the scope of the thread, the point being, use LDAP, it's re-usable.. you can build bridges to NIS from ldap, you can use it as your global addressbook. to put it simply, LDAP+TLS a good solution for the user distribution. =) Sami -- - Sami Haahtinen - -[ Is it still a bug, if we have learned to live with it? ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C - pgpM5YbegKQZJ.pgp Description: PGP signature
NFS, password transparency, and security
I have a situation where my superiors are leaning heavily on me to make life more convenient for them by having total availability of data from a group of machines. They basically want to log into any one machine within this group with the same password, and be able to access any disks they choose from any pariticular machine (within this group). What makes me nervous is that is that I have little to no control over the network. The particular setup at our university is that every single ethernet drop has a unique and world accessible IP (most of this is done with DHCP, so most change, but the machines that have purposes, like the afformentioned group - don't). These machines also share subnets with machines I don't control, which makes using non-encrypted authentication even more dangerous than usual - it is a switched network, but that doesn't protect against much at all. The best I can do to keep these machines from being affected from the world is to have iptables firewalls set up on each of them, basically denying everything including pings from outside specified subnets. This is a less than desirable solution, not to mention the scalability issues inherent with every single machine having its own set of firewall rules. What I am curious to know what is the best way possible to implement what they want and to do so as securely as possible. I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. While I'm aware that this can be done just as easily with Linux, I am going to assume that many places who run NIS/NFS do so inside a strictly internal network, not on several Machines that have external IPs to themselves on subnets shared by student lab machines and other untrusted nodes. What I have done so far is just have a few users's home directories mounted over NFS on a central machine, making sure that they have the same UIDs across the board. I am rapidly realizing that this solution does not scale well, plus it does not provide a full solution. I apologize in advance for any rambling or over-generalizations. Please add any advice or corrections you may have. Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Several choices for authorisation (pam_access.so): (1) local /etc/secuirty/access.conf listing all users (2) local /etc/secuirty/access.conf listing a group or netgroup - use local group file - use LDAP-distributed group or netgroup map Several choices for file sharing: (1) NFS + iptables + tcpwrappers (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Hope this (probably incomplete) list helps, Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
Rob VanFleet [EMAIL PROTECTED] writes: They basically want to log into any one machine within this group with the same password, and be able to access any disks they choose from any pariticular machine (within this group). An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! Ban the bomb. Save the world for conventional warfare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
hi ya why not do the following ??? make one machine be your primary NIS server... - all passwds defined there... all other machines uses the NIS server for passwd authentication and turn on ssh logins ( ~/.shosts ) w/o checking passwd use automounter for /n/machines/directories http://www.Linux-Consulting.com/AutoFS/autofs-HOWTO.html add additional security as needed - turn on tcp_wrappers - use secure nfs/portmapper - do NOT allow insecure operations in a secure environment ( no wireless stuff, no dchp stuff, no pop3, no telnet, no ftp ) and magically its just like sun-environment... sorta ... c ya alvin http://www.Linux-Sec.net On Sun, 7 Apr 2002, Luca Filipozzi wrote: On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Several choices for authorisation (pam_access.so): (1) local /etc/secuirty/access.conf listing all users (2) local /etc/secuirty/access.conf listing a group or netgroup - use local group file - use LDAP-distributed group or netgroup map Several choices for file sharing: (1) NFS + iptables + tcpwrappers (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Hope this (probably incomplete) list helps, Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. I've looked at Kerberos, but at least a cursory glance at leaves the impressions that it is ridiculously complicated to set up and requires multiple servers. If someone has used it and can correct me, please do. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Without using SSL or Kerberos, would LDAP still be sending passwords across the net in plain text? [...] Several choices for file sharing: (1) NFS + iptables + tcpwrappers Doing that right now. (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Both of these sound very promising. I had heard of AFS before, but not SFS. I'll have to research them further. I'll probably have even more questions after that though. :) Hope this (probably incomplete) list helps, Immensely. Thanks for the information. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 10:04:01PM -0500, Rob VanFleet wrote: On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. I've looked at Kerberos, but at least a cursory glance at leaves the impressions that it is ridiculously complicated to set up and requires multiple servers. If someone has used it and can correct me, please do. I suspect that if all your boxes are running Debian that your life will be made easier by all the Debian kerberos packages. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Without using SSL or Kerberos, would LDAP still be sending passwords across the net in plain text? Two choices (I like lists :) ): (1) use libpam-ldap: libpam-ldap sends the password to the ldap server. If not using TLS/SSL, then it is sent in the clear. By sending the password to the server (rather than using a salt+hash), you can use whatever hash algorithm you want on the server. The server takes the password and does the hashing locally. So, you *must* use TLS/SSL if you are using libpam-ldap, imo. (2) don't use libpam-ldap: You You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, 7 Apr 2002, Luca Filipozzi wrote: I suspect that if all your boxes are running Debian that your life will be made easier by all the Debian kerberos packages. This is an interesting thread, and this comment just gave me an idea. What if you use FreeS/WAN (or really, any sort of IPsec)? It can be set up in a mode that's called opportunistic encryption that will use IPsec for communication when it's available and allow other traffic to proceed as normal. In this way, you won't care if things like LDAP (or even NIS) pass passwords around in cleartext, just as long as the workstation - file-server or authentication server connections are encrypted. Although I haven't done it, you should be able to run the server services bound to a specific IP that is only accessible via clients that have successfully IPsec-attached. 0.02, tony [EMAIL PROTECTED] | An ounce of perception, http://www.debian.org | a pound of obscure... |(Peart) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:22:12PM -0700, tony mancill wrote: What if you use FreeS/WAN (or really, any sort of IPsec)? It can be set up in a mode that's called opportunistic encryption that will use IPsec for communication when it's available and allow other traffic to proceed as normal. In this way, you won't care if things like LDAP (or even NIS) pass passwords around in cleartext, just as long as the workstation - file-server or authentication server connections are encrypted. Although I haven't done it, you should be able to run the server services bound to a specific IP that is only accessible via clients that have successfully IPsec-attached. For the NFS traffic, opportunistic encryption seems like a very intersting idea. There's no way I would use libpam-ldap without knowing *for certain* that it was going over a TLS/SSL connection, however. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 08:14:26PM -0700, Luca Filipozzi wrote: Two choices (I like lists :) ): (1) use libpam-ldap: i recommend this. Even though the current pam system is a pain to modify.. if you modify one file and it gets updated in the package it will nag about it.. you can't tell if it's a needed change or not, luckily i have heard rumours about new design for the pam system and i'm eagerly waiting for it to arrive =) (2) don't use libpam-ldap: You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). i don't recommend the above to anyone (do as i say, not as i do.. =) it will cause problems, you are forced to enter the database access password to the configuration, which you will then need to make readable to root, which in turn forces you to use nscd. There is nothing wrong with nscd, it's just plain stupid.. if you have a small database, there is no problem, but if you have a big database (max cached entries +1) you might start running in to trouble. apparently the caching mechanism is quite stupid and it can't just expire an entry becuse someone needs a new one.. =( this also allows crackers to access your userbase, unlike libpam-ldap, where you are not forced to allow userpassword read access to the database. The cracker just needs to hack this machine, read the password from config and voila, ur nt3w0rk has been 0wn3d! Sami -- - Sami Haahtinen - -[ Is it still a bug, if we have learned to live with it? ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C - msg06261/pgp0.pgp Description: PGP signature
NFS, password transparency, and security
I have a situation where my superiors are leaning heavily on me to make life more convenient for them by having total availability of data from a group of machines. They basically want to log into any one machine within this group with the same password, and be able to access any disks they choose from any pariticular machine (within this group). What makes me nervous is that is that I have little to no control over the network. The particular setup at our university is that every single ethernet drop has a unique and world accessible IP (most of this is done with DHCP, so most change, but the machines that have purposes, like the afformentioned group - don't). These machines also share subnets with machines I don't control, which makes using non-encrypted authentication even more dangerous than usual - it is a switched network, but that doesn't protect against much at all. The best I can do to keep these machines from being affected from the world is to have iptables firewalls set up on each of them, basically denying everything including pings from outside specified subnets. This is a less than desirable solution, not to mention the scalability issues inherent with every single machine having its own set of firewall rules. What I am curious to know what is the best way possible to implement what they want and to do so as securely as possible. I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. While I'm aware that this can be done just as easily with Linux, I am going to assume that many places who run NIS/NFS do so inside a strictly internal network, not on several Machines that have external IPs to themselves on subnets shared by student lab machines and other untrusted nodes. What I have done so far is just have a few users's home directories mounted over NFS on a central machine, making sure that they have the same UIDs across the board. I am rapidly realizing that this solution does not scale well, plus it does not provide a full solution. I apologize in advance for any rambling or over-generalizations. Please add any advice or corrections you may have. Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Several choices for authorisation (pam_access.so): (1) local /etc/secuirty/access.conf listing all users (2) local /etc/secuirty/access.conf listing a group or netgroup - use local group file - use LDAP-distributed group or netgroup map Several choices for file sharing: (1) NFS + iptables + tcpwrappers (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Hope this (probably incomplete) list helps, Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
Rob VanFleet [EMAIL PROTECTED] writes: They basically want to log into any one machine within this group with the same password, and be able to access any disks they choose from any pariticular machine (within this group). An AFS-based setup is used at many places to great effect, especially on untrusted nets, but I don't know how bad setup is. I suspect it's evil. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! Ban the bomb. Save the world for conventional warfare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
hi ya why not do the following ??? make one machine be your primary NIS server... - all passwds defined there... all other machines uses the NIS server for passwd authentication and turn on ssh logins ( ~/.shosts ) w/o checking passwd use automounter for /n/machines/directories http://www.Linux-Consulting.com/AutoFS/autofs-HOWTO.html add additional security as needed - turn on tcp_wrappers - use secure nfs/portmapper - do NOT allow insecure operations in a secure environment ( no wireless stuff, no dchp stuff, no pop3, no telnet, no ftp ) and magically its just like sun-environment... sorta ... c ya alvin http://www.Linux-Sec.net On Sun, 7 Apr 2002, Luca Filipozzi wrote: On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: I work for several University astronomers who basically want something like what they're used to at other places: a pure sun shop, running NIS and NFS. Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Several choices for authorisation (pam_access.so): (1) local /etc/secuirty/access.conf listing all users (2) local /etc/secuirty/access.conf listing a group or netgroup - use local group file - use LDAP-distributed group or netgroup map Several choices for file sharing: (1) NFS + iptables + tcpwrappers (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Hope this (probably incomplete) list helps, Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. I've looked at Kerberos, but at least a cursory glance at leaves the impressions that it is ridiculously complicated to set up and requires multiple servers. If someone has used it and can correct me, please do. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Without using SSL or Kerberos, would LDAP still be sending passwords across the net in plain text? [...] Several choices for file sharing: (1) NFS + iptables + tcpwrappers Doing that right now. (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Both of these sound very promising. I had heard of AFS before, but not SFS. I'll have to research them further. I'll probably have even more questions after that though. :) Hope this (probably incomplete) list helps, Immensely. Thanks for the information. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 10:04:01PM -0500, Rob VanFleet wrote: On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. I've looked at Kerberos, but at least a cursory glance at leaves the impressions that it is ridiculously complicated to set up and requires multiple servers. If someone has used it and can correct me, please do. I suspect that if all your boxes are running Debian that your life will be made easier by all the Debian kerberos packages. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Without using SSL or Kerberos, would LDAP still be sending passwords across the net in plain text? Two choices (I like lists :) ): (1) use libpam-ldap: libpam-ldap sends the password to the ldap server. If not using TLS/SSL, then it is sent in the clear. By sending the password to the server (rather than using a salt+hash), you can use whatever hash algorithm you want on the server. The server takes the password and does the hashing locally. So, you *must* use TLS/SSL if you are using libpam-ldap, imo. (2) don't use libpam-ldap: You You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
