Dr Fragen in the operating room

Surgical Diversions

dovecot

  • Fail2ban and OS X Server, Part Deux

    ·

    Andy Fragen

    As some of you might know I run my own installation of OS X Server. I’ve since updated it to Snow Leopard Server and I think I’ve got most of it running well. As I check my server logs frequently I find that there are all sorts of script kiddies attempting to log in to my server in various ways.
    The traditional method was to simply try an ssh session with a username and password combination. Unfortunately now I see more attempts to log in via VNC or in attempts to check or send email. It’s amazing to see 10 – 15 login attempts in a second. There’s a real motivating force to stop that kind of attention my poor little server is getting.
    As I’ve written before, I’ve found the Fail2ban scripts to to be a perfect solution. I have had to make a number of additions and improvements along the way and now I thought I’d share.
    I’ve created a couple of new jails and improved upon a couple of the distribution jails so they work better with Snow Leopard. I’ve packaged up all my modifications. Here’s how to install them for yourself.
    Download the modifications tarbell.
    Then you’ll need to issue the following commands from Terminal.

    sudo tar xzf install_fail2ban_mods.tar.gz

    This will create a folder containing all the modifications. At this point you can manually put all the files in the proper folders or you can use my installation script. The installation script, install_fail2ban_mod.sh shouldn’t delete anything. I only use the cp command. If you already have a jail.local file that is backed up. You may also need to modify the jail.local file that I have.
    Additionally, I’ve found that sometimes the fail2ban server might have hung or its process has stopped. I’ve also written a script and a couple of plists for /Library/LaunchDaemons/ that periodically check to make sure fail2ban continues to hum along. You’ll have to load these plists manually or simply restart.
    The jails that I’ve added check for SMTP, POP, IMAP, VNC and non-existant web pages. These, in addition to monitoring SSH, seem to cover most of it. Please remember that some of these filters are somewhat specific to Snow Leopard so they check against a Dovecot mail server.
    So far my only problem has been when a user has changed their password but not correctly transferred these changes to Mail.app. What happens is fail2ban sees them as a break-in attempt and bans their IP for 10 minutes or so. I’m sure it can be frustrating. Sorry, I’m doing my best to fix it for you.
    By all means, let me know how you’ve improved Fail2ban for your server.

  • Snow Leopard Sieve Rules

    ·

    Andy Fragen

    How to edit _sieve_ rules in Snow Leopard by hand. This is not really recommended especially because it seems that SL server does not utilize all the sieve rules and the ones that it does utilize are in a slightly different format than exists in [Sieve documentation][1].
    A couple of sources later and a couple of quick lines of code helps to figure out what file to edit.
    > `u=”username”; dscl /Search read Users/$u GeneratedUID | awk {‘printf “/Library/EmailRules/sievescripts/”$2″.sieven”‘} | xargs -n1 -p sudo cat`
    >
    > `u=”username”; dscl /Search read Users/$u GeneratedUID | awk {‘printf “/Library/EmailRules/sievescripts/”$2”.sieven”‘} | xargs -n1 -p sudo pico`
    Edit the command to make _u_ equal to the _username_ of the person and you can look at and edit the sieve files. I also don’t know why but I get the following error.
    > Received SIGHUP or SIGTERM
    All you have to do is simply copy the command and it will work. Not sure why it doesn’t work the first time.
    I’m quite certain if you go ahead and try to re-edit using the GUI your files might get screwed up. YMMV.
    Some say running the following command helps. Also, see **Update** below. Again, YMMV.
    > `sudo /usr/bin/wiki_sieve_manager`
    Finally a real solution to the above. Simply make sure you use the URL **https://yourdomain.com/settings/username/emailrules/**. Even if the website is not set up to use port 443 in Server Admin it seems you must use **https**.
    **Update**
    I discovered another secret. In order for the new rules to transfer you will need to add a new rule via the wiki, or at least go to the wiki and press the add rule button. This way the new rule is copied over to `/var/spool/imap/dovecot/sieve-scripts/%u`.
    [1]: http://tools.ietf.org/html/rfc3028

  • Dovecot Permissions

    ·

    Andy Fragen

    Well, I finally bit the bullet and installed OS X Snow Leopard Server. Most of what I absolutely **need** to get working is mail services. One of the peculiarities of Dovecot is that each users mail folder is owned by that user. I think in Cyrus they were all owned by *mail* or *_cyrus*.
    Anyway, I found that a couple of my files didn’t have the correct permissions and I found out by trying to open in webmail. It gave me errors I’d never seen before. Where I found better errors was in mailaccess.log where I saw a _dovecot_ service with a _failed: Permission denied_ error.
    I managed to find where the files lived and as I have quite a few mail users I didn’t want to go through individually so I figured out a script to do it.
    > `sudo ls -lA /var/spool/imap/dovecot/mail | grep -v total | awk {‘printf $3″: /var/spool/imap/dovecot/mail/”$9″n”‘} | xargs -n2 -p sudo chown -R`
    The script will ask if you want to proceed with the _chown_ command for each user.
    If you find your logs reporting permissions issues with a specific account or your webmail users have errors opening mailboxes, then the following script when provided with the offending GeneratedUID will reset the permissions similar to the above. Simply replace the GUID in the script with the one listed in your logs.
    > ` dscl /LDAPv3/127.0.0.1 -list /Users GeneratedUID | grep GUID | awk {‘printf $1″: /var/spool/imap/dovecot/mail/”$2″n”‘} | xargs -n2 -p sudo chown -R`