sysadmin

Sometimes we are using a publicly available Wifi hot spots and would like a better privacy when browsing the internet. Although our credit-card or bank account website are probably using secure connection, other websites are not and we simply would like to have more privacy. One way to do it is by setting up your own proxy server and using it as a private proxy.

However using our own proxy server still does not increase the privacy / security of our connection over the exposed wireless link, unless we use encryption. Encryption in this case is easily accomplished by using SSH tunneling. The benefits of this is two prongs. First, we have SSL level encryption, second, we keep our proxy server private by off-loading the authentication burden to the SSH server. In this entry I explain how to do it.

I assume that we are using a fairly modern linux distribution for our web proxy and SSH server. I also assume that we have SSH access to our machine set up securely. Most major linux distribution include Apache 2 web server and its proxy module in the distribution. It's better to use that than compiling Apache yourself, unless you know what you are doing. Assuming all that, then it is really easy to set up our proxy server.

First, we need to enable the web server to be a proxy server. The relevant configuration in

httpd.conf

file is as follow

LoadModule proxy_module modules/mod_proxy.so
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
#
<Proxy *>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Proxy>
</IfModule>
# End of proxy directives.

The first line loads the proxy module to the web server. Proxy directives allow you specify by IP address the request that it will serve. In this case, we deny all request except request from

127.0.0.1

, which is

localhost

. This is how we keep your proxy server private, i.e. not an open proxy.

Now to use our proxy server from a different machine, -- let's call this is the laptop with wireless access --, we first have to connect to the server via SSH tunneling. This is both the encryption and authentication part. The simple proxy server cannot authenticate us, and hence only allows connection from

127.0.0.1

. The authentication part comes from the fact that we have to connect via SSH first to the proxy machine before we can use the proxy forwarding. To have SSH tunnel, simply do

$> ssh -L 3000:localhost:80 myproxyserver.myisp.net

This means, port 3000 in my laptop actually listen to port 80 on the proxy server via SSH tunneling, i.e. it is an encrypted tunnel. The port 3000 is random. We can use any port number that is unused in the laptop. Port 80 is the port where the web server binds to in the proxy server machine (of course one can set up the Apache to binds to different port in

httpd.conf

).

Now that we have tunneling set up to our proxy server, all we need to do is to configure web browser to use this. This differs slightly for different web browsers, but as an example, in Firefox 2, this is done via

Preference --> General tab --> Connection Settings

. Here we set

Pick "Manual Proxy Configuration:"
HTTP Proxy: localhost
Port: 3000
Use this proxy for all protocols: check

Now we can start browsing securely via this SSL encrypted tunnel to our proxy server. If we check the web server log in our proxy server machine, we should see that our request from the laptop's web browser is being forwarded by the proxy server. Also noticed that from the web server point of view, our request comes from

127.0.0.1

.

I have been using Sendmail as a personal mail server on my own domain. To send email, I use Sendmail's Smarthost to relay the mails through my ISP SMTP server. This is to avoid being flagged as "spam" by some spam filter since I am on dynamic IP.

Recently, my SMTP blocks port 25, which is the default port uses to relay mails, and require us to use Submission port 587. Some people thing this is a good thing (?) and has becoming standard with ISPs. (Whether you agree or not is beside the point of this post).

So anyway, I have to change my Sendmail configuration to do this. This post is a documentation / recipes on what I did. To change the smarthost relaying to use port 587, have the following in your sendmail.mc:

define(`SMART_HOST',`smtp.myisp.net')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')
define(`ESMTP_MAILER_ARGS', `TCP $h 587')
FEATURE(`authinfo',`Hash -o /etc/mail/authinfo.db')dnl

The last line is to have sendmail authenticate as client to your ISP SMTP server. You also need to create your credential file, in this case

/etc/mail/authinfo.db

. First create

/etc/mail/authinfo

; in that file I have:

AuthInfo:ispdomain.net "U:my_username" "P:my_password" "M:PLAIN"
AuthInfo: "U:my_username" "P:my_password" "M:PLAIN"

In this case, I use the authentication mechanism

PLAIN

. You may need different authentication mechanism, depending on your ISP. Now generate the

authinfo.db

file by doing:

chmod 600 /etc/mail/authinfo
makemap hash /etc/mail/authinfo < /etc/mail/authinfo

The first line is to have your plain text authinfo file more secure by making it readable to root only. As usual, rebuild

sendmail.cf

and restart sendmail.

I have a collection of TrueType fonts that I would like to add to my Fedora 7 installation. Installing (TrueType) fonts on recent version of Fedora turns out to be quite easy. To install the font system wide, all you need to do is put it in the fonts in a directory. To be consistent, create a new directory under "/usr/share/fonts". For example, I created directory:

mkdir /usr/share/fonts/handwritten

to store a collection of handwritten-like font. To make sure that the fonts is accessible to the world, do

chmod 775 -R /usr/share/fonts/handwritten

Then all needs to be done is run "fc-cache" command on that directory, e.g

cd /usr/share/fonts
fc-cache handwritten

And voila! the new fonts appear on all applications such as Gimp, openoffice, koffice, etc.

Often time I have a group of people that I constantly exchanging emails with. This group is sometimes informal enough, fluid enough (a changing memberships or only temporary), or small enough to make it not worth the trouble to create a mailing-list for, but can benefit from having the most important feature of a mailing-list: the easyness to distribute email messages to its members. Sometimes the group is such that using a publicly hosted mailing list like Yahoo! group is not appropriate . Sometimes it's just not tech-savvy enough (no offense intended) that the process of registering to a mailing-list would become a hurdle, and it would be so much easies if only one person takes care of registering them all.

These are the cases that I deal with as a (self-)volunter sysadmin in small organizations. So instead of going through the trouble setting up Mailman/Mojordomo run lists, I choose a liberal use of /etc/aliases, formail, and procmail to set up a small scale mailing-list like system. Notice that I said "small organizations", plural, so setting up a Mailman on a single system would be inappropriate (different domains, machines, policies, etc). The following are quick notes on how I set the system up.

As I mentioned in my previous post, we can use an alias in virtual user table. So even if we have several virtual hosts on the mail server, this still works. So suppose we're creating this distribution list called: managers@company1.com. On /etc/mail/virtusertable, we should have:

managers@company1.com managers-company1

"managers-company1" is an alias, so define it at /etc/aliases for the real email addresses which the message should go to:

managers-company1: harry@company1.com, sally@company1.com, harry-home@homeaddress.net, bob@company1.com

Now we are pretty much done, all email sent to the virtual address "managers@company1.com" gets distributed to the real addresses. The problem, if the one of the people who gets the email reply to the email, the reply address would be the original person who sent the original message, not the "list address." This is because the email does not have the appropriate header that tells the mail client program whom to reply to. So here is where formail and procmail comes into play.

Header Munging with Formail
Formail is a linux mail re-formatter program, and can do mail header generation, munging, and extraction. To tell the mail client program whom to reply, we need to add either "Reply-To" header or "List-Reply" header. There has been arguments for and against "Reply-To" header which you can find easily on the web, but I won't comment on them here. I'll simply leave that decision to you. In my case, I choose to use the Reply-To header because I consider it appropriate. If you disagree, you can always use List-Reply header instead, since most modern mail clients program support it.

Anyway, we need to pass the message to formail before distributing it to the real email addresses. We do this by using procmail. So we call procmail, like before, from /etc/aliases. The procmail recipe will then call formail, and then distribute the message to the real addresses. So instead of the above, /etc/aliases should looks like:

managers-company1:  | procmail-managers-company1

Of course, we put the executable script "procmail-managers-company1" under /etc/smrsh so that sendmail can execute it using the restricted "smrsh" shell. On that file, we have the actual call to procmail with the correct procmailrc as argument, as follows:

exec procmail /etc/procmailrc.d/managers-company1-dist

Now on the procmailrc file is where we pass the filtered message to formail, do the header munging with formail, then distribute it to the real email addresses using procmail forwarding comand. So the recipes look like:

:0 fhw
| /usr/bin/formail -I "Reply-To: managers@company1.com"
:0 c
! harry@company1.com, sally@company1.com, harry-home@homeaddress.net,bob@company1.com

So that's it. Now you have a small-scale email distribution system with mailing-like feature using several simple scripts and readily available linux tools.

I am very protective of my personal email account. I don't usually want to give it away for anything other than to someone that I know personally. I am doing this to keep it from getting spamed, and it has been largely successful. I should probably have a server-based spam filter like spamassasin, and a probably even a virus scanner. But since I have my own mail server at home, setting up a spam filter feels like a pain and a big hassle. Plus mostly we runs linux (Fedora distro) anyway so we are less worry about viruses. Even when we use Windows, we use sane email program; my wife and I are also very cautius about opening any attachment (and we open them on linux if we are a little bit unsure). So as you can see, we hope that we can just use common sense to fight againts spams and viruses. But recently a very small amount of spams have managed to get into my personal mailbox, so I may just have to bit the bullet at some point and install a spam filter anyway, when the numbers start to get annoying.

Anyhow, one of the advantageous of having one's own mail server is that one can easily create (and remove) "pseudo" mail accounts. So that's what my mode of practice has been. For example, for creating account at Amazon, I would create a pseudo account something like "my-amazon-email@mydomain.com". The same thing for my bank accounts, credit card accounts, etc, I would have a "personalized" account for each and every single one of them. Sometimes I create a single account for registering at several different sites (ie. Slashdot, Digg), so it all depends on my mood and my discretion at the moment. I also create several throw-away accounts like "myself001, myself002, mywife001, etc" which we can use when we're pressed to give out email address to uncertain entity while travelling. This is done using Sendmail virtual user table for my domain which then route the email message to a valid local user.

The advantage of doing this is at least two fold. First, if the "personalized" email account get spammed, I can just remove them and create a new one easily. Secondly, I know which what service / website I registered that email accounts for, so if gets spammed, I could justify having a very strong suspicion that the company either intentionally spamming me, or sell / give out my email account to other companies / services. Then I will just have to make sure that I won't have anymore bussinesses with it, infact I would go so far as discouraging any people that I know that are considering doing bussiness with the company / website / service.

So this practice has been working well for me, except for one loophole. Having my own domain, I need to put an email address for domain registration, which is available publicly via Whois lookup. So this address really becomes the source of nearly all spams coming into my mailbox, other than the spam attempts to find random valid addresses on my domain (ie. "accounting, billing, sales, ..."). For all of that, I have a catch-all trap in my virtual user table that goes to an alias called "spam", which then re-route the messages to /dev/null.

The email account for domain registration, -- let's call that "dom_reg@mydomain.com"--, is routed directly to my local user from the virtual user table. So I've been trying to block this using several procmail recipes, but somehow some spam messages are clever enough to get though. My procmail recipes for this account basically say "if the email is to dom_reg AND from My Registrar, deliver to Inbox, otherwise send to /dev/null." But the spams come in like this, the "To: " header would make it seems that it's addressed to "accounting@mydomain.org", yet somehow it's sent to my domain registration email account. So the recipes never catch it! I am still not sure how this happens, but it does. The problem is, I have to filter on the "To:" header also in the recipes, otherwise the recipes will catch all messages send to my personal email account. If only I could directly invoke these recipes when the message comes, -- ie. go a level higher on when to filter these messages --, I'd be just fine.

But I could ! It just occured to me, that I could invoke procmail directly from the aliases file. So what I needed to do is to create alias for this dom_reg@mydomain.com and changed the virtual user table so that mail goes to this address is routed to the alias. So here is what I did.

First created a directory on the system where specific promail recipes for this situation would go, I called it /etc/procmailrc.d (following Redhat/Fedora convention for directory containing configurations). Then I created recipe file for this situation, basically it says "If the mail is from My Registrar, accept it, otherwise, throw it away." Now the problem is how to call procmail from /etc/aliases.

Sendmail uses smrsh to invoke programs, which is a restricted shell for security. It can only executes programs that are in /etc/smrsh directory (or symbolically linked from there). So I could create a symlink to /usr/bin/procmail in /etc/smrsh, but that would be the best way since procmail then can execute any program. So my solution is to create yet another wrapper for procmail under /etc/smrsh, which call procmail with the correct procmailrc as argument. So I have the following files:
/etc/smrsh/procmail-dom_reg:

exec procmail /etc/procmailrc.d/dom_reg

OK, so now in the /etc/aliases, I have the line:

dom_reg: |promail-dom_reg

And for completeness, in my virtual user table files, which is /etc/mail/virtusertable, I have the following:

dom_reg@mydomain.com dom_reg

and /etc/procmailrc.d/dom_reg contains something like:

:0
* ^From:.*godaddy\.com
! my_real_email@mydomain.org

So there you have it, a creative way of using virtual user table, aliases, and procmail. All this trouble is actually to fight spams that are coming to dom_reg account, and to catch email from my registrar which probably only comes once a year, if at all, to remind me when my domain registration is about to expire . Now I'm starting to wonder if installing a real spam filtering software would actually be easier.