Sealed Server

[jekillen]

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 jekillen at prodigy.net 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 have wrong, somehow. Because of this e-mail
setup issue, I had contacted the isp and they have delegated all my
static ip addresses to me and added my name servers to their database.
>
> 	Cheers,
>
> 	Matthew
>
>
Thank you very much for your assistance.
Jeff K