Sealed Server
Hello; I am planning on setting up Cyrus on a machine and the documentation says that it is intended' for use on 'sealed' servers (servers for which there are no accounts that can log into the system) However: If I use ssh to administer the system, I have to set it up so I can ssh directly to root, right. and Since there are references to use of MySQL and the MySQL user is set up as a normal user with a login/pwrd, How do I get around that? (have MySQL running on a different machine, or something?) Please forgive my lack of sophistication on this issue, I am learning. (I have also been looking at Dovecot) I have assembled some documentation on this but have not found a direct answer, thus the query here. system uses Postfix on FreeBSD 6.2 One FYI that may be of interest: I had my own dns servers listed in resolv.conf before the isp's dns servers and messages sent from this machine (FreeBSD w/Postfix) were failing to deliver to [EMAIL PROTECTED] due to dns lookup failures. So I changed the order in resolv.conf (listing isp dns servers first) and the messages were then delivered. I thought that if one server could not respond with enough info, the next server would be tried until one was successful (making order insignificant). Thank you for any info; Jeff k ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sealed Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 jekillen wrote: Hello; I am planning on setting up Cyrus on a machine and the documentation says that it is intended' for use on 'sealed' servers (servers for which there are no accounts that can log into the system) This is really just trying to say that you don't need a Unix login account in order to have an e-mail account via Cyrus IMAPd. Of course any server will require user accounts for its administrators to be able to log in. However: If I use ssh to administer the system, I have to set it up so I can ssh directly to root, right. Wrong. The best practice is to require users to log in as themselves (thus establishing some sort of audit trail) and then use some program like su or sudo to gain rootly powers. At work we use a second instance of sshd bound to a high-numbered port on the loopback so you can ssh to root only after you've logged in and only if you've using ssh-agent and your ssh public key is in root's ..ssh/authorized_keys file. and Since there are references to use of MySQL and the MySQL user is set up as a normal user with a login/pwrd, No -- mysql runs as a non-privileged user which doesn't need to have any password set or any ability for anyone to get a login session as the mysql user. All that ID is for is to own some files and the various mysqld processes. This is a standard practice with most long-running daemons exposed to the network: it limits the damage that can be done by remote compromise of the software. How do I get around that? (have MySQL running on a different machine, or something?) Unless you're running a particularly heavyweight Cyrus installation (ie. lots of users + lots of e-mail) or you've got really weedy hardware, then you're better off running MySQL on the same machine as the rest of the mail system. Remember that there is a completely separate set of logins and passwords *within* MySQL -- nothing to do with the system logins from /etc/passwd. The best way to configure MySQL in that situation is to * use 'skip-networking' in the configuration file. This forces all connections to mysql to be via the unix domain socket in /tmp/mysql.sock * Run 'mysql_secure_installation' to remove remote root access, set the root password, get rid of wildcarded logins etc. * Review all user IDs and GRANTS carefully -- if you aren't using networking, then all your MySQL users should be 'userid'@'localhost' Adopt a polict of *minimum privilege* -- allow only the necessary access required for things to keep working. * In order to prevent the MySQL root password being used routinely (which makes it far more likely to be disclosed), create a file /root/.my.cnf with contents like: [client] user = root password = yourpassword Make sure the file is mode 600: read-write only for the owner With this in place, then once you've become the Unix root user you can then just type 'mysql' and get a root MySQL session without having to type any passwords. ie. you rely on the security of your Unix root account to protect your MySQL root account. Please forgive my lack of sophistication on this issue, I am learning. (I have also been looking at Dovecot) I have assembled some documentation on this but have not found a direct answer, thus the query here. system uses Postfix on FreeBSD 6.2 Dovecot is good, and its configuration -- particularly where stuff like SASL is concerned -- is a lot easier for inexperienced users. It will run a mail server for tens of hundreds of users perfectly satisfactorily. On the other hand, if you're looking at thousands of users then Cyrus IMAPd is what you need. One FYI that may be of interest: I had my own dns servers listed in resolv.conf before the isp's dns servers and messages sent from this machine (FreeBSD w/Postfix) were failing to deliver to [EMAIL PROTECTED] due to dns lookup failures. So I changed the order in resolv.conf (listing isp dns servers first) and the messages were then delivered. I thought that if one server could not respond with enough info, the next server would be tried until one was successful (making order insignificant). Sounds like your own recursive DNSes weren't actually working. Flaky DNS is the cause of most of the delays or failures that spoil your user experience: until you've thoroughly mastered managing DNS servers, I'd recommend using your ISPs servers. Having reliable DNS will help you a great deal while you are debugging your mail server setup. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG
Re: Sealed Server
On Nov 17, 2007, at 12:13 PM, Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 jekillen wrote: Hello; I am planning on setting up Cyrus on a machine and the documentation says that it is intended' for use on 'sealed' servers (servers for which there are no accounts that can log into the system) This is really just trying to say that you don't need a Unix login account in order to have an e-mail account via Cyrus IMAPd. Of course any server will require user accounts for its administrators to be able to log in. However: If I use ssh to administer the system, I have to set it up so I can ssh directly to root, right. Wrong. The best practice is to require users to log in as themselves (thus establishing some sort of audit trail) and then use some program like su or sudo to gain rootly powers. At work we use a second instance of sshd bound to a high-numbered port on the loopback so you can ssh to root only after you've logged in and only if you've using ssh-agent and your ssh public key is in root's ..ssh/authorized_keys file. Thank you this answers these questions and Since there are references to use of MySQL and the MySQL user is set up as a normal user with a login/pwrd, No -- mysql runs as a non-privileged user which doesn't need to have any password set or any ability for anyone to get a login session as the mysql user. All that ID is for is to own some files and the various mysqld processes. This is a standard practice with most long-running daemons exposed to the network: it limits the damage that can be done by remote compromise of the software. and this accept, I know that MySQL has a separate set of user/passwords and various levels of access privilege, When I built and installed MySQL I had to create a mysql user as a normal user with password, unless I misunderstood. Someone who knew this password would be able to log into the system as user mysql (or the name that was given to mysqld to run as) The best way to configure MySQL in that situation is to * use 'skip-networking' in the configuration file. This forces all connections to mysql to be via the unix domain socket in /tmp/mysql.sock * Run 'mysql_secure_installation' to remove remote root access, set the root password, get rid of wildcarded logins etc. * Review all user IDs and GRANTS carefully -- if you aren't using networking, then all your MySQL users should be 'userid'@'localhost' Adopt a polict of *minimum privilege* -- allow only the necessary access required for things to keep working. * In order to prevent the MySQL root password being used routinely (which makes it far more likely to be disclosed), create a file /root/.my.cnf with contents like: [client] user = root password = yourpassword Make sure the file is mode 600: read-write only for the owner With this in place, then once you've become the Unix root user you can then just type 'mysql' and get a root MySQL session without having to type any passwords. ie. you rely on the security of your Unix root account to protect your MySQL root account. Please forgive my lack of sophistication on this issue, I am learning. (I have also been looking at Dovecot) I have assembled some documentation on this but have not found a direct answer, thus the query here. system uses Postfix on FreeBSD 6.2 Dovecot is good, and its configuration -- particularly where stuff like SASL is concerned -- is a lot easier for inexperienced users. It will run a mail server for tens of hundreds of users perfectly satisfactorily. On the other hand, if you're looking at thousands of users then Cyrus IMAPd is what you need. One FYI that may be of interest: I had my own dns servers listed in resolv.conf before the isp's dns servers and messages sent from this machine (FreeBSD w/Postfix) were failing to deliver to [EMAIL PROTECTED] due to dns lookup failures. So I changed the order in resolv.conf (listing isp dns servers first) and the messages were then delivered. I thought that if one server could not respond with enough info, the next server would be tried until one was successful (making order insignificant). Sounds like your own recursive DNSes weren't actually working. Flaky DNS is the cause of most of the delays or failures that spoil your user experience: That is probably the cause, but editing resolv.conf was the quick fix. until you've thoroughly mastered managing DNS servers, I'd recommend using your ISPs servers. Having reliable DNS will help you a great deal while you are debugging your mail server setup. Actually they work fine for what I set them up for. It was the recursive aspect that I had forgotten about, but as I remember, there was a security issue with regard to recursive queries so I have them disabled. I have the isp's servers set up to relay queries to in my primary named.conf and that is probably what I
