Re: Centralized /etc/passwd ?
On Tue, 25 Jun 2002, Hubert Chan wrote: Paladin == Paladin [EMAIL PROTECTED] writes: [...] Paladin can the root account be centralized too? I don't know if it can or not, but it is probably not a good idea. Consider what happens if your LDAP server goes down for some reason. So you say to yourself, OK, I'll just log in as root, and Doh! Can't log in because the LDAP server is down. Not to mention the security implications. Imagine one of someone finds out the root password. Suddenly all your machines are compromised. I have 3 machines at home up and running 24/7 and the root password is different on all of them. Andrew Whether you think you can, Or whether you think you can't, You are right -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized /etc/passwd ?
* Paladin ([EMAIL PROTECTED]) [020624 16:00]: On 24 Jun 2002 15:01:47 -0500 Ron Johnson [EMAIL PROTECTED] wrote: I've heard that NIS isn't very robust. Might LDAP be a better choice? Or is there an important integration between NIS NFS? Funny... I think I've heard something about NFS being kind of old... I may be wrong though! :/ NIS LDAP... I'm on the good track now! Thanks everyone! =) BTW, what's more secure? Putting everything in the firewall PC or on The general answer to this is that it's more secure to keep your firewall machine as minimal as possible. The less it has on it, the fewer possible holes there are. any other one that's inside the firewall? Another thing (I haven't got the time to read the documentation, I'm sorry...), can the root account be centralized too? I don't know about this, but I'd urge that your firewall machine have nothing to do with it: it should have its own local root account and (probably) one local user account, and that's all. This is, of course, idealism, and assumes that you have servers (or at least a server) to spare. In my home network, I only have one always-on machine, so its duties are slightly more expanded than the paranoid firewall should be. Even with just one extra machine, it's easy to make one a stripped-down firewall-only box and the other your all-serving internal box (which can also run dmz-type services, such as web, mail, etc. via DNAT). good times, Vineet -- http://www.doorstop.net/ -- I disapprove of what you say, but I will defend to the death your right to say it. --Beatrice Hall, The Friends of Voltaire, 1906 pgp9ZuI791HZv.pgp Description: PGP signature
Re: Centralized /etc/passwd ?
On Tue, Jun 25, 2002 at 02:05:38AM -0700, Vineet Kumar wrote: * Paladin ([EMAIL PROTECTED]) [020624 16:00]: ... BTW, what's more secure? Putting everything in the firewall PC or on The general answer to this is that it's more secure to keep your firewall machine as minimal as possible. The less it has on it, the fewer possible holes there are. The more liberal stance would be to have no external services open on the firewall (blocking them at the ip level), and run only a few local only services that you really can't live without on the firewall. ... spare. In my home network, I only have one always-on machine, so its duties are slightly more expanded than the paranoid firewall should be. Even with just one extra machine, it's easy to make one a stripped-down firewall-only box and the other your all-serving internal box (which can also run dmz-type services, such as web, mail, etc. via DNAT). IMHO it's stupid to mix dmz-type services with local only services as the point of DMZ is to shield your own network and your firewall from the hostile net. I really believe it's better to have the DMZ machine do DMZ services only, and lacking an extra server to put the local only services on the firewall. The change of breaking in into the firewall seems less than the chance of breaking in into the DMZ with all it's flacky services running. -- groetjes, carel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized /etc/passwd ?
* Carel Fellinger ([EMAIL PROTECTED]) [020625 02:49]: On Tue, Jun 25, 2002 at 02:05:38AM -0700, Vineet Kumar wrote: * Paladin ([EMAIL PROTECTED]) [020624 16:00]: .. BTW, what's more secure? Putting everything in the firewall PC or on The general answer to this is that it's more secure to keep your firewall machine as minimal as possible. The less it has on it, the fewer possible holes there are. The more liberal stance would be to have no external services open on the firewall (blocking them at the ip level), and run only a few local only services that you really can't live without on the firewall. .. spare. In my home network, I only have one always-on machine, so its duties are slightly more expanded than the paranoid firewall should be. Even with just one extra machine, it's easy to make one a stripped-down firewall-only box and the other your all-serving internal box (which can also run dmz-type services, such as web, mail, etc. via DNAT). IMHO it's stupid to mix dmz-type services with local only services as the point of DMZ is to shield your own network and your firewall from the hostile net. I really believe it's better to have the DMZ machine do DMZ services only, and lacking an extra server to put the local only services on the firewall. The change of breaking in into the firewall seems less than the chance of breaking in into the DMZ with all it's flacky services running. Sure, and that's just the point. If I have a firewall machine running on an Inet address and a server machine doing apache and sendmail for the outside and also bind and samba inside, it's harder to catastrophically break into the system. Say a remote exploit is found in sendmail which allows the attacker to open a listening port that goes straight to a root shell. Without also breaking something on the firewall (which is running nothing but iptables) they can't ever connect to that backdoor. Again, the ideal assumes availability of spare servers, but my point is that with only 2 servers the setup can be much better than with only 1 doing firewall + services. In this case, it still shields your firewall from the hostile net, if not your LAN. putting them all on one box has no such shielding effect. I guess my fault was using the term DMZ which implies a degree of protection that this arrangement does not afford. good times, Vineet -- http://www.doorstop.net/ -- Satan laughs when we kill each other. Peace is the only way. pgpgdWZYxEDws.pgp Description: PGP signature
Re: Centralized /etc/passwd ?
Paladin == Paladin [EMAIL PROTECTED] writes: [...] Paladin can the root account be centralized too? I don't know if it can or not, but it is probably not a good idea. Consider what happens if your LDAP server goes down for some reason. So you say to yourself, OK, I'll just log in as root, and Doh! Can't log in because the LDAP server is down. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgp6AGOXpYc2x.pgp Description: PGP signature
Re: Centralized /etc/passwd ?
* Paladin ([EMAIL PROTECTED]) [020624 11:38]: Is it possible to have a centralized /etc/passwd (plus all necessary MD5 password files) as well as the home directories in a network? What you're looking for is NIS. Start out by reading the HOWTO: http://www.google.com/search?q=nis+howtobtnI=I good times, Vineet -- http://www.doorstop.net/ -- Computer Science is no more about computers than astronomy is about telescopes. -E.W. Dijkstra pgpMXJbruft3t.pgp Description: PGP signature
[Fwd: Re: Centralized /etc/passwd ?]
Is it possible to have a centralized /etc/passwd (plus all necessary MD5 password files) as well as the home directories in a network? Another person already suggested NIS. A more modern, scalable, and flexible alternative is an LDAP database. If your needs are very simple, though NIS may be a quicker fix. For basic LDAP info, see the OpenLDAP HOWTO at http://www.linuxdoc.org For more detailed info on OpenLDAP on Debian, see the whitepaper at http://www.metaconsultancy.com/whitepapers/ Good luck! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized /etc/passwd ?
On Mon, Jun 24, 2002 at 11:47:47AM -0700, Vineet Kumar wrote: | * Paladin ([EMAIL PROTECTED]) [020624 11:38]: | Is it possible to have a centralized /etc/passwd (plus all necessary | MD5 password files) as well as the home directories in a network? | | What you're looking for is NIS. Start out by reading the HOWTO: | | http://www.google.com/search?q=nis+howtobtnI=I Or, better yet, use LDAP. Google will likewise provide with all the documents you need and Free tools to migrate your existing /etc/passwd, etc, to LDAP. -D -- Pleasant words are a honeycomb, sweet to the soul and healing to the bones. Proverbs 16:24 http://dman.ddts.net/~dman/ pgpRXcIGFPl1P.pgp Description: PGP signature
Re: Centralized /etc/passwd ?
On Mon, 2002-06-24 at 13:47, Vineet Kumar wrote: * Paladin ([EMAIL PROTECTED]) [020624 11:38]: Is it possible to have a centralized /etc/passwd (plus all necessary MD5 password files) as well as the home directories in a network? What you're looking for is NIS. Start out by reading the HOWTO: http://www.google.com/search?q=nis+howtobtnI=I I've heard that NIS isn't very robust. Might LDAP be a better choice? Or is there an important integration between NIS NFS? -- +-+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA http://ronandheather.dhs.org:81 | | | | Object-oriented programming is an exceptionally bad idea | | which could only have originated in California. | | --Edsger Dijkstra | +-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized /etc/passwd ?
On 24 Jun 2002 15:01:47 -0500 Ron Johnson [EMAIL PROTECTED] wrote: I've heard that NIS isn't very robust. Might LDAP be a better choice? Or is there an important integration between NIS NFS? Funny... I think I've heard something about NFS being kind of old... I may be wrong though! :/ NIS LDAP... I'm on the good track now! Thanks everyone! =) BTW, what's more secure? Putting everything in the firewall PC or on any other one that's inside the firewall? Another thing (I haven't got the time to read the documentation, I'm sorry...), can the root account be centralized too? Thanks in advance to everyone! =) -- Paladin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized /etc/passwd ?
Paladin [EMAIL PROTECTED] writes: On 24 Jun 2002 15:01:47 -0500 Ron Johnson [EMAIL PROTECTED] wrote: I've heard that NIS isn't very robust. Might LDAP be a better choice? Or is there an important integration between NIS NFS? Funny... I think I've heard something about NFS being kind of old... I may be wrong though! :/ NIS LDAP... I'm on the good track now! Thanks everyone! =) In the overkill department, you might consider using Kerberos and AFS; this doesn't deal with distributing the contents of the /etc/passwd file (you'd probably need LDAP for that, something like Hesiod would *work* but you probably don't want it for new deployments). If you're dealing with significant numbers of users, AFS lets you do things like spread volumes out across servers and have actual authentication and ACLs; NFS security is a joke, and if you have just one NFS server, you're really hosed if it goes down... BTW, what's more secure? Putting everything in the firewall PC or on any other one that's inside the firewall? It's almost certainly easier to avoid publishing your NFS server to the world if you keep it inside the firewall and then tell the firewall to not forward NFS packets. (Though I've never actually tried to set this up.) It's also conceivable that network services that attempt to be clueful about network interfaces will get confused by living on the firewall machine, particularly if your setup is complicated. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
