RE: [vps-mail] Setting up a secure SquirrelMail system on VPS1 in more than 5 minutes

[Bruce Armstrong <bruce@xxxxxxxxxxxxxxxxxxxxx>]

This response baffles me.  We are not in high school, we are
professionals trying to make a living.  Marjolein went to the trouble of
giving a detailed account of how to securely set up SquirrelMail along
with an interesting commentary/instructions on security.  This is the
kind of thing that makes this list great.  Please don't discourage her
or anyone else from contributing.

I found the information about this particular use of mail quite
interesting.  

	--Bruce

On Fri, 2004-04-23 at 12:31, John Oligario wrote:
> Sounds like Marjolein needs a new boy friend!
> 
> -----Original Message-----
> From: owner-vps-mail@xxxxxxxxxxxx [mailto:owner-vps-mail@xxxxxxxxxxxx] On
> Behalf Of Marjolein Katsma
> Sent: Friday, April 23, 2004 2:20 PM
> To: vps-mail@xxxxxxxxxxxx
> Subject: [vps-mail] Setting up a secure SquirrelMail system on VPS1 in more
> than 5 minutes
> 
> All,
> 
> The 'more than 5 minutes' in the subject (while true) is a little private
> joke - sorry, I couldn't resist...
> 
> [For later reference, this report is also available from the web - but (so
> far) as plain text only; download from http://iamback.com/doc/SM_story.txt
> for more comfortable reading.]
> 
> 
> Setting up a secure SquirrelMail system on VPS1 in more than 5 minutes
> ----------------------------------------------------------------------
> 
> A report of my adventures... hoping that my experiences will provide some
> useful ideas for others. My path wasn't as straight as described below, and
> involved a number of dead ends, wrong turns, and stones to trip over. May
> your path be smooth and straight.
> 
> For some subjects I made separate notes, which I put on my website; I'm
> simply referring to them here to make this email a litlle "shorter". All
> just plain text, I'm afraid, no time to make it into pretty web pages. Just
> download the files if they don't read well in your browser - sorry.
> 
> Here goes with the report:
> 
> 
> (1) The use case.
> 
> I'm going to make a long trip, all across Asia. I'd like to keep a
> "travelblog" on a website for those who stay at home: a blogging system
> where I can easily add my travel notes from Internet cafes I may find along
> the way.
> 
> Since working from an Internet cafe is inherently insecure (port sniffers,
> key loggers and other spyware may be installed) I didn't want to set up my
> blogging system so it could be directly used from a web interface: better
> not expose a maintenance interface and password for the travelblog website
> in a "public place", so I devised a system where I send an email to a
> special mailbox, and a background PHP script pulls out the mails and adds
> the content to the database. Designing and setting up the database was easy
> enough. The script to read (and validate) mails and fill the database
> (archiving everything) needs some tidying up but is essentially ready.
> 
> Then I started looking at emailing from Internet cafes. Discussions in
> various locations... My original idea was to set up a string of (free)
> webmail accounts, discarding each after use, so as not to "leave anything
> behind" on the computer used. That idea essentially fell flat: FastMail
> (FM) doesn't even allow multiple free accounts; TMicha does, but like FM
> will discard an account that hasn't been used for 45 days - and I'll be gone
> for 65. A combination of the two might work but would be complicated. 
> Other solutions came up: a USB stick with a pre-installed email application
> (will work only where a USB connection is present and allowed to be used -
> not guaranteed); using an anonymous email web form that doesn't require
> login (I'm keeping that as a backup). After long discussions the brilliant
> idea (thanks SikaSpam!): install SquirrelMail on your own VPS system; there
> is a nice virtual keyboard plugin that can protect your login password from
> keyloggers. While continuing other discussions, I decided to explore that.
> 
> Meanwhile the public end of the travelblog system (displaying the data from
> the database in various ways) is nearly ready as well, but needs a little
> refinement; and I have some wishes for extra features if I still have time
> left before I leave.
> 
> 
> (2) Installing SquirrelMail
> 
> "It takes only 5 minutes". Well, not for me (hence the "5 minutes" in the
> subject :)). SM is a PHP application; while some will automatically assume
> that means it needs to be installed in the webserver's the document root, my
> assumption is the opposite: only a user interface needs to be visible to a
> browser, everything else needs to be found by PHP, not the webserver, so it
> can be installed *away* from the webserver, which is more secure. That's how
> I design my own PHP apps, and my experience with others as well.
> 
> The INSTALL file in the SM archive states: "Untar (...) SquirrelMail in a
> directory that is readable for your webserver." Well, OK. So it put it in
> the server root - not the document root. Oops. It actually needs to be
> installed in the *document* root.
> 
> SM also has requirements; apart from PHP (no problem) and Perl (not strictly
> needed, but no problem anyway) it needs an IMAP server. I've only ever used
> IMAP against my will, and know next to nothing about it  in fact, I didn't
> know it was provided with a VPS account. OK, so IMAP is provided. 
> I don't know *which* IMAP server is installed though, nor do I know how to
> find out...
> 
> The same INSTALL file also has some instructions about data directories to
> be created and their ownership. That confused me, since I found the commands
> given did not work. Ignore those instructions: you can actually configure
> these directories to be invisible from the browser or even the
> webserver: a complete path can be defined using SM's configuration. As long
> as SM can find it, it's secure enough when you just put those directories
> outside of the webserver's view. See Configuring SquirrelMail below.
> 
> Simple install: create a directory (which I'll call [SUB] in the rest of
> this story) and untar SM into that. Move the data directory somewhere else
> if you wish. Configure.
> 
> 
> (3) Configuring SquirrelMail
> 
> SM provides a Perl script (to be run from the command line) for
> configuration; it's a nice menu system but the menu choices *themselves*
> don't tell you very much about what they are for: the explanation appears
> only when you choose a menu option. I found this very confusing at first. 
> An alternative is to copy config_default.php to config.php and directly edit
> that: it is well-commented and thus provides a better overview of
> configuration options. It also provides a way to directly specify the
> location of the data directory and the directory to be used for storing
> attachments to be sent. (Using the Perl script will also create this file.)
> After a while though much-used configuration options become easy to do from
> the Perl config.pl script, reducing the chance of typos and syntax errors. 
> I find I use both now. :)
> 
> I created a new user (as instructed, with both FTP and mail, though I don't
> know why FTP is needed for IMAP!). Then, after what I "judged" was minimal
> configuration, I proceeded to test SM with my main account, as well as with
> the newly-created user. No problems with the latter, but with the main
> account I found that using the "Folders" menu from the web interface
> invariably leads to a running out of memory error. Worse, after that
> happens, SM is completely inoperational until Apache is restarted... I
> almost gave up at this point: I can't telnet into my server from an insecure
> Internet cafe!
> 
> Searching a bit, I found such errors in fact are known, and can have
> different causes, but there is no single solution or workaround. This page
> lists some memory problems similar to what I encountered:
> 	http://www.squirrelmail.org/wiki/en_US/LowMemoryProblem
> I suspect (after a lot of poking and digging) that the problem has something
> to do with the fact that the 'special' mail folders SENT, DRAFTS and TRASH
> for the main account are in a different location from those for other users.
> A possible workaround (suggested on that page) may be to set up SM for a
> particular IMAP server of which it "knows" a few. Can't do that since I
> don't know which IMAP server is running on VPS accounts, let alone whether
> it's one of the ones SM knows about.
> 
> In the end, I decided to ignore this (still unsolved!) problem since it
> didn't occur with my newly-created user. All I need is to *send* email and
> that's best done with a special user account anyway.
> 
> I've put together some configuration hints in a separate note:
> 
> 	==> http://iamback.com/doc/SM_config_hints.txt
> 
> 
> (4) Setting up SSL
> 
> Looking at my phpinfo(), I found that not only OpenSSL is present and
> active; and Apache has the Apache_SSL module loaded as well. Seems I'm all
> set.
> 
> So off I go (RTFM idjit that I am) and read up on setting up SSL on Apache. 
> I learn that I can actually sign my own certificate (useful: for using
> webmail from an Internet cafe all I need is encryption, after all); I learn
> that to use SSL you need IP -based virtual hosts (the IP address needs to be
> resolved first, or something) and this also means you can use only a single
> certificate for a single IP address; I learn that there is actually a way
> around that, by telling the server to listen not only to port 443 (the
> default SSL HTTP port) but others as well, and defining each virtual host
> that needs its own certificate with one of those ports. And I learned that
> Apache is more usually combined with mod_ssl which isn't the same as
> apache_ssl and actually uses some different directives in httpd.conf.
> 
> All useful knowledge - but, it seems, not for VPS. Whatever I tried in
> httpd.conf, I either got internal server errors (500) indicating the SSL
> directives were not understood, or 'no connect' from the browser, seemingly
> indicating port 443 wasn't listened to, regardless what I put in httpd.conf.
> A mail to my (reseller) hoster's support explained it (more or
> less): you don't need to make *any* change in httpd.conf at all - all you
> need is to request that SSL is activated. Which turns out to cost me $55. 
> YMMV, but it seems SSL does need to be "set up" on a VPS system, regardless
> whether Apache has apache_ssl alreday loaded.
> 
> Oh, well. It works now. So much for RTFM. :)
> 
> The details of how to create your own "self-signed" certificate, and how to
> set it up on a VPS(1) system, can be read here:
> 
> 	==> http://iamback.com/doc/SSL_certificate.txt
> 
> Note that VPS is doing things differently than you'd deduce from all the
> information found on the web about using SSL with Apache. I suspect this has
> to do with the fact you're not (actually) running your own server, but a
> virtual one. There are both pros and cons with this. Major con is that you
> *cannot* use the "different ports" trick to use different certificates; if
> you run several domains and use anything but a wildcard certificate
> ($$$!) any domain that doesn't match the domain the certificate is *for*
> will result in a "domain mismatch" in the browser. Major pro is that it's
> very easy to set up a new certificate (no changes needed in httpd.conf): 
> just put the files with the correct (VPS-specific) names in the correct
> (VPS-specific) directory, restart Apache (restart_apache), and you're set.
> 
> For encryption-only, for my own use, this is certainly good enough.
> 
> 
> (5) Setting up Squirrel Mail to use the secure server.
> 
> The next step is to make sure Squirrel Mail (at least) uses the secure
> server. One potential problem with that: the certificate uses 128-bit
> encryption. In most Western countries certainly no problem (not any more)
> but I'm not sure that will be the case in all Asian countries I'm going to
> visit. So what I need is a way to *preferably* use Squirrelmail with SSL,
> but provide a way around that as well.
> 
> Since we've already concluded that I cannot really define to use *only* on
> SSL on a particular subdomain with httpd.conf, enforcing it that way is not
> feasible anyway. I'll try a more gentle approach by only "suggesting" using
> SSL where possible.
> 
> And if I do encounter a situation where I cannot use SSL and would also want
> to avoid "exposing" my SquirrelMail password, there are some "anonymous"
> webmail forms that allow sending an email without any login necessary. Not
> for general email purposes, but good enough to be able to send a mail to my
> travelblog.
> 
> Configuration (httpd.conf) details, as well as some anonymous webmail
> addresses, here:
> 
> 	==> http://iamback.com/doc/SM_secure_subdomain.txt
> 
> 
> (6) Securing SquirrelMail
> 
> Finally, SquirrelMail itself can be made more secure, not just with respect
> to using SSL, but also to defeat keyloggers, and other potential pitfalls. 
> I've put together a package of SM plugins that make it more secure to use on
> the road, as well as a few that come in handy for my particular usage for my
> travelblog system.
> 
> An annotated list of the plugins I installed (as well as a few I UNinstalled
> after testing!) can be found here:
> 
> 	==> http://iamback.com/doc/SM_security_plugins.txt
> 
> 
> 
> -----------------------------------------------
> Marjolein Katsma, 2004-04-23
> 
> --
> Marjolein Katsma
> 
> ======================================================================
> This is <vps-mail@xxxxxxxxxxxx>       <http://www.perlcode.org/lists/>
> Before posting a question, please search the archives (see above URL).
> 
> ======================================================================
> This is <vps-mail@xxxxxxxxxxxx>       <http://www.perlcode.org/lists/>
> Before posting a question, please search the archives (see above URL).

======================================================================
This is <vps-mail@xxxxxxxxxxxx>       <http://www.perlcode.org/lists/>
Before posting a question, please search the archives (see above URL).