Warning: include_once(/home/nullvoid/blog.mikezhang.com/wp-content/plugins/wordpress-support/wordpress-support.php): failed to open stream: Permission denied in /home/nullvoid/blog.mikezhang.com/wp-settings.php on line 217

Warning: include_once(): Failed opening '/home/nullvoid/blog.mikezhang.com/wp-content/plugins/wordpress-support/wordpress-support.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/nullvoid/blog.mikezhang.com/wp-settings.php on line 217
NullVoid » 2005 » January NullVoid » 2005 » January

Archive for January, 2005

MATLAB for Econometrics

Wednesday, January 12th, 2005 -- By ET

I start to feel unconfortable to use SAS for econometrics, SAS is a great package with a lot of predefined routines to take care almost all needs of econometrics.

There are times, when SAS is not good enough. For example, when fitting a panel data model, it is very hard to get what I exactly want. Jumping arround GLM, MIXED, TSCSREG, etc, I finally gave up. Stata is a better package for panel data, but I really do not want to start learning a new software now. Matlab seems a good package for my needs. With all the formulae in econometrics books and algorithms, matrix manipulation capabilities, I can write my own routines.

Here is a good link to the documentations:

http://www.mathworks.com/access/helpdesk/help/helpdesk.html

Chinese restaurant in Boston

Tuesday, January 11th, 2005 -- By ET

http://www.areyoueye.com/restruant/ma.htm

If you want to find a Chinese restaurant in Boston, you can find it in this page.

Live Webcam

Tuesday, January 11th, 2005 -- By ET

http://www.opentopia.com/hiddencam.php

Privacy is talked about everyday, but nobody really takes it seriously, because it is very vague how one’s private information might be harmful to himself/herself.

Search in Google for

inurl:”ViewerFrame?Mode=”

gives a frightening list of live webcams. The link above is made by someone that shows a collage of these webcams.

These webcams are mostly company cams or those installed in public places. People do not know they are watched by others.

Using SMTP AUTH and STARTTLS with sendmail

Tuesday, January 11th, 2005 -- By ET

This article is copied from http://www.joreybump.com/code/howto/smtpauth.html

So that I do not have to look for it next time when I need it.

Using SMTP AUTH and STARTTLS with sendmail
A quick start guide for Red Hat Linux

SMTP AUTH allows users to supply a login and password to a server in order to relay mail to other locations. Until recently, relaying was largely controlled by restricting access to trusted IP addresses or networks. This has turned into an administrative nightmare, however, due to the wide adoption of dynamically allocated IP addresses and the demands of roaming users. It makes more sense to control relaying at the user level, regardless of the host or its location on the Internet, but care must be taken to protect passwords from being sent in the clear.

Unfortunately, implementation can be complex, documentation is sparse, and it is often difficult for the novice to understand. For that reason, I have put together this quick start guide to getting sendmail up and running securely with SMTP AUTH on Red Hat Linux. Some of the information presented here will be useful on other platforms, as well.
Tested on:

* Red Hat 9.0
* sendmail-8.12.8-6.90
* sendmail-cf-8.12.8-6.90
* cyrus-sasl-2.1.10-4
* openssl-0.9.7a-5
* m4-1.4.1-13

Also tested on:

* Fedora Core 1
* sendmail-8.12.10-1.1.1
* sendmail-cf-8.12.10-1.1.1
* cyrus-sasl-2.1.15-6
* openssl-0.9.7a-23
* m4-1.4.1-14

Please Note: The platforms used when writing this document are fading into obsolescence. Nonetheless, there is still some useful information in this document. Please choose a modern distribution that is well supported with security updates before exposing a mail server to the Internet.
In a nutshell

Make sure that sendmail was compiled with the necessary options:

sendmail -d0.1 -bv

STARTTLS and SASL must be present in the resulting list.

Verify the location of sendmail.cf:

sendmail -d0.20 -bv | grep sendmail.cf

The output might look similar to this:

Conf file: /etc/mail/sendmail.cf (default for MTA)
Conf file: /etc/mail/sendmail.cf (selected)

Back up your configuration files:

cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf~
cp /etc/mail/sendmail.mc /etc/mail/sendmail.mc~

Make your certificate:

cd /usr/share/ssl/certs
make sendmail.pem

Put this in /etc/mail/sendmail.mc (don’t cut and paste):

define(`confAUTH_OPTIONS’, `A p y’)dnl
TRUST_AUTH_MECH(`LOGIN PLAIN’)dnl
define(`confAUTH_MECHANISMS’, `LOGIN PLAIN’)dnl
define(`confCACERT_PATH’,`/usr/share/ssl/certs’)
define(`confCACERT’,`/usr/share/ssl/certs/ca-bundle.crt’)
define(`confSERVER_CERT’,`/usr/share/ssl/certs/sendmail.pem’)
define(`confSERVER_KEY’,`/usr/share/ssl/certs/sendmail.pem’)

If you plan on using a DNSBL that blocks dialup IP addresses, you may want to add this line to support roaming users, as well:

FEATURE(delay_checks)dnl

Generate sendmail.cf using the location you verified earlier, and restart sendmail:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
service sendmail restart

If you are running Fedora Core 1, you must also issue the following commands:

chkconfig saslauthd on
service saslauthd restart

That’s it! You now have SMTP AUTH with encrypted logins!
Verbose mode

In order to provide encrypted logins, you must use a version of sendmail that was compiled to use SASL and STARTTLS. The binaries provided with Red Hat 9.0 and Fedora Core 1 have been compiled with all of the necessary options. In fact, Red Hat has done an excellent job in finally providing a version of sendmail that is relatively easy to secure. Most of the of the options mentioned are already present in the provided sendmail.mc, and merely need to be uncommented.

Note: Users of Fedora Core 1 (and presumably Red Hat Enterprise Linux) need to run the saslauthd daemon. The following commands will start the daemon and ensure that it gets launched at boot time:

chkconfig saslauthd on
service saslauthd restart

Now let’s go through each step:
Step 1: Back up important files

Red Hat has finally placed sendmail.cf in /etc/mail, where it belongs. To verify the location of your configuration file, type this command:

sendmail -d0.20 -bv | grep sendmail.cf

The default installation outputs this:

Conf file: /etc/mail/sendmail.cf (default for MTA)
Conf file: /etc/mail/sendmail.cf (selected)

Be sure to use this path when generating your new sendmail.cf from sendmail.mc, or no changes will take place. Back up your current sendmail.cf and the m4 file that generated it (probably /etc/mail/sendmail.mc):

cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf~
cp /etc/mail/sendmail.mc /etc/mail/sendmail.mc~
Step 2: Make your certificate

We are also setting up STARTTLS, which allows sendmail to communicate over an encrypted layer using TLS. This is very important, as it allows us to use the LOGIN or PLAIN authentication mechanisms without transferring the password in plain text. It also allows the entire message to remain encrypted from the user’s machine to the mail server. If sendmail relays the message to another server that offers STARTTLS, the message will be encrypted again. But the most important advantage of this approach is that we get to authenticate using regular system logins and passwords, with no need to maintain a separate user database.

Red Hat’s openssl package includes a Makefile that makes it extremely easy to generate a certificate:

cd /usr/share/ssl/certs
make sendmail.pem

Just follow the prompts and be sure to use the fully qualified domain name of the mail server for the Common Name prompt. Users will still be warned that the certificate is self-signed or not trusted, but you will prevent a warning that the certificate doesn’t match the host offering it. This certificate is suitable for testing, but you may want to investigate further about the use of certificates before deploying it in a production environment, a topic that is beyond the scope of this howto.
Step 3: Edit sendmail.mc

If you take a look at the sendmail.mc provided by Red Hat, you will notice that the necessary directives are already present but have been commented out (m4 doesn’t use the # symbol for comments, it starts a line with dnl, which stands for “delete until new line”). Since we want the easiest method possible, without sacrificing security, we need to edit these lines. Don’t cut & paste from this web page, or you may introduce unwanted characters into your configuration file that will prevent sendmail from starting.

The confAUTH_OPTIONS macro allows you to instruct sendmail not to offer plain text authentication until after a secure mechanism such as TLS is active (the p option). We are also prohibiting anonymous logins (the y option). The A option is a workaround for broken MTAs:

define(`confAUTH_OPTIONS’, `A p y’)dnl

Now we define which authentication mechanisms we will trust and use:

TRUST_AUTH_MECH(`LOGIN PLAIN’)dnl
define(`confAUTH_MECHANISMS’, `LOGIN PLAIN’)dnl

Next, we tell sendmail where to find the certificates:

define(`confCACERT_PATH’,`/usr/share/ssl/certs’)
define(`confCACERT’,`/usr/share/ssl/certs/ca-bundle.crt’)
define(`confSERVER_CERT’,`/usr/share/ssl/certs/sendmail.pem’)
define(`confSERVER_KEY’,`/usr/share/ssl/certs/sendmail.pem’)

And finally, it may be useful to increase the log level for debugging purposes (delete or comment out this line after everything is working properly):

define(`confLOG_LEVEL’, `14′)dnl

Use the m4 command to generate a new sendmail.cf:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Be sure to use the right location for sendmail.cf, as determined earlier. Alternatively, you can use the following command in a stock Red Hat 9.0 or Fedora Core 1 installation:

make -C /etc/mail sendmail.cf
This uses the commands in /etc/mail/Makefile to generate the new sendmail.cf configuration file.
Step 4: Test the configuration

This is where things get really interesting. sendmail must be restarted before it can use the new configuration file. Rather than simply restarting sendmail with our fingers crossed, we can test it to verify that every thing works properly. You can stop sendmail and then start it with command line options that cause it to log to a specified file. There are various ways to stop sendmail on a Red Hat system:

service sendmail stop

or

cd /etc/mail
make stop

or

make -C /etc/mail stop

or

/etc/init.d/sendmail stop

We want to start sendmail with arguments to make it log the SMTP transaction to a special file while we are testing it:

sendmail -bD -X /tmp/test.log

Now, try to send a message from an e-mail client on another computer that does not have relay access, using your server as the outgoing mail server. You should be denied relaying. Edit your preferences so that the client uses authentication, with a login and password (not Secure Password Authentication, or SPA, which is something completely different). You should still be denied access. The last thing you need to do is to instruct the client to use SSL or TLS with the outgoing mail server (there is no need to specify a special port). After making this change, you should be able to send mail (you will be prompted to accept the certificate, however, which you might want to install to prevent further prompts). Now hit ctrl-c to stop sendmail. Restart it normally:

service sendmail restart

Now it’s time to look at the log. After the first EHLO, sendmail offers something like this:

30245 >>> 250-ENHANCEDSTATUSCODES
30245 >>> 250-PIPELINING
30245 >>> 250-8BITMIME
30245 >>> 250-SIZE
30245 >>> 250-DSN
30245 >>> 250-ETRN
30245 >>> 250-STARTTLS
30245 >>> 250-DELIVERBY
30245 >>> 250 HELP

The important thing is that AUTH is not offered here, because the channel isn’t encrypted. If you see AUTH in the first exchange, and it offers PLAIN or LOGIN, something is wrong. Look at your logs, go over the previous steps, and make sure that you generated a new sendmail.cf in the right location. The next entries in our log show that TLS is activated:

30245 < << STARTTLS 30245 >>> 220 2.0.0 Ready to start TLS

Another EHLO takes place, followed by something like this:

30245 >>> 250-ENHANCEDSTATUSCODES
30245 >>> 250-PIPELINING
30245 >>> 250-8BITMIME
30245 >>> 250-SIZE
30245 >>> 250-DSN
30245 >>> 250-ETRN
30245 >>> 250-AUTH LOGIN PLAIN
30245 >>> 250-DELIVERBY
30245 >>> 250 HELP

Now AUTH is offered with the allowed mechanisms (but not STARTTLS, which isn’t needed here, as the channel is already encrypted). Authentication takes place, and the message is relayed to its destination.

It’s interesting to note that the username and password is Base64 encoded by the client, so it isn’t really sent as clear text:

30245 < << AUTH PLAIN AHJvYmVydABzbHVncw== 30245 >>> 235 2.0.0 OK Authenticated

Nevertheless, it would be trivial to decode the string into the correct username/login pair (robert/slugs, in this case). Therefore, it is best to secure the transaction with TLS. If you want to verify that the transaction is encrypted, open another terminal for root, and run tcpdump:

tcpdump -s 1500 -vvxX port 25

Send a mail with easy to identify strings. You shouldn’t see your login or the message in tcpdump’s output. Note that the certificate will be exchanged in plain text before TLS is enabled. If the mail is relayed to another server that doesn’t offer STARTTLS, you will see the content of the outgoing message in plain text.
Source Documentation

SMTP AUTH in sendmail 8.10-8.12 – The official documentation at sendmail.org. Much of it concerns compiling cyrus-sasl and sendmail, steps that are not necessary when using Red Hat RPMs.

Configuring Sendmail’s STARTTLS (SSL) and Relaying – An excellent article by Jason Heiss about STARTTLS and sendmail. He also explains how to allow relaying based on certificates offered by clients.

My Experiences (So Far) with STARTTLS and Sendmail – Weldon Whipple shares his experiences sorting out the intricacies of STARTTLS. Read this for a good introduction to the way sendmail handles encryption and certificates.

RFC 2222: Simple Authentication and Security Layer (SASL)

RFC 2487: SMTP Service Extension for Secure SMTP over TLS

RFC 2554: SMTP Service Extension for Authentication

bug me not

Thursday, January 6th, 2005 -- By ET


BugMeNot.com was created as a mechanism to quickly bypass the login of web sites that require compulsory registration and/or the collection of personal/demographic information (such as the New York Times).

Tried and it worked for many websites. Very interesting idea!

IAP: Could you get into MIT in 1876

Tuesday, January 4th, 2005 -- By ET

IAP is a month of fun time for all MIT students. Each year I feel very amazed just reading the topics of the courses offered. This year’s funniest course would be this one:

Could You Get Into MIT in 1876?: Try Your Hand at an Entrance Exam
Nora Murphy, Reference Archivist
Tue Jan 11, 11am-12:00pm, 2-105

No enrollment limit, no advance sign up
Single session event

If the same exam was offered today would you pass? Find out what questions were asked of prospective students. Come and sit for an early MIT mathematics entrance exam and test your knowledge. No slide rules or calculators allowed! Answers will be distributed at the end of the exam.
Contact: Nora Murphy, Reference Archivist, 14N-118, x3-5690, nmurphy@mit.edu
Sponsor: Libraries


BlogTimer
You are visitor number several since September 1, 2001

Copyright Xiaoquan (Michael) Zhang, 2004-2020. All rights reserved.
All trademarks property of their owners.