A Day Late

Well, hooking up my docking station to an external monitor didn’t help with my XFree86 problem. So I just decided to modify the XF86Config file by hand. I’m not sure why I didn’t just do this in the first place. The modifications were pretty trivial and only took a couple of minutes. The hardest part was finding the right values to enter in. Anyway, I modifed the monitor and screen section. These modifications are for a Dell C800 SXGA 15.1 LCD laptop.
(more…)

I downloaded Red Hat 9.0 on Tuesday and decided to upgrade my Dell C800 laptop from 8.0. After the upgrade I can no longer get XFree86 to work. I think it’s because it upgraded to a new version (4.3.0) and created all new config files. However, I think I found a work around . As I read the post I remembered, when I originally installed Red Hat a few years ago, I had my laptop connected up to the docking station and an external monitor, which is probably why I didn’t have this same problem. I still have the docking station but not the external monitor. So I’m gonna see if it will configure the “Screen” section of the XF86Config file correctly by just connecting it up to the docking station. If it doesn’t work I guess I’ll have to borrow an external monitor for a little while…or I could just write the XF86Config file by hand, but where’s the fun in that?

It was an interesting weekend. I planned on updating the RPM packages on the system over the weekend using Red-Carpet. However, it indicated there weren’t any packages to update, which I knew was wrong. I did some checking and it appeared that my RPM database was corrupted. The solution to that seemed to be running rpm –rebuilddb. That rebuilds the database from the header files stored on the computer. Well…do you know what happens if your headers are also corrupted? You end up with a database of RPM’s significantly smaller than you had before.

(more…)

My Professor from last semester, Phil Windley, was featured in a local newspaper article about Wi-Fi security. It describes the wireless antenna he built out of a pringles can back in December, which he mentions here. He also commented on the article.

I didn’t find the article as interesting as I did the comments made about the article. Most people seemed to think the article would promote attacks on wireless networks. I’d argue that anyone capable of attacking a wireless network wouldn’t find anything in the article they didn’t already know. I think it was meant to make people aware that the neighbor kid next door is capable of snooping their insecure wireless lan, more than anything. If so, despite the authors lack of complete understanding of the technology, I think it served its purpose.

One person suggested solving the problem by enabling “WEP,” implying it was 100% secure. That was about all I could take so I decided to throw my two cents in.

As for myself, I admit to having a wireless LAN setup in my apartment and I have to say I love it. I love the freedom of being able to work on my laptop anywhere I want. I enabled WEP to keep away the casual leeches but I’m not under the impression it provides me with any security. I look at it this way. If someone wants to sniff my network traffic, fine. Any information I want private is encrypted and I’ve taken the time to make sure I don’t have any “open” network shares. So, for now, that’s good enough for me.

I’m anxious to build my own wireless antenna and sit in the courtyard of my apartment complex just to see what I can pick up. Actually, I’m right against the mountain so maybe taking a slight hike to get a better perspective on the valley would prove to be an interesting experiment. This probably won’t happen until after the semester is over though. Well, who am I kidding, I’ll probably end up doing it in the next week or two (priorities!!).

I had to go into work on a Saturday because of this stupid thing. So much for sleeping in. I’m not sure who I’m more displeased with, the person that wrote the worm or the developer(s) at microsoft that created the vulnerability.

Much like enabling SSL, confuring Sendmail to use authentication was much easier than I first thought. The hardest part was locating some decent instructions to do it. Fortunataly I eventually came across some here. It looks like they were written for RedHat 7.x but seem to work for 8.0. Basically I just had to modify my /etc/mail/sendmail.mc file and then update my /etc/mail/sendmail.cf file. Here’s the step by step process:

backed up my configuration files:
cp /etc/mail/sendmail.mc /etc/mail/sendmail.mc.bak
cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak

added to /etc/mail/sendmail.mc (NOTE: Watch the directed quotes. The first quote is made using the key just above the TAB key, the other is a normal apostrophe):
define(`confAUTH_OPTIONS’, `A’)dnl
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN’)dnl
define(`confAUTH_MECHANISMS’, `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN’)dnl

Updated the configuration file:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Restarted sendmail:
/etc/rc.d/init.d/sendmail restart

Verified it worked:
telnet 127.0.0.1 25
EHLO localhost
250-SERVERNAME Hello CLIENT NAME [CLIENTIP], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP

The 250-AUTH LOGIN PLAIN indicates that everything seems to be working. I modified my mail client to use authentication and sent myself a test email (to an email account located on a different domain, to require relaying). I received the email just fine. Just to be safe I then turned off authentication in my mail client and tried to send the same email and received the ever popular “relaying denied” error (error messages aren’t so bad when I intend to get them).

I also wanted to verify that no user or password information was getting sent in cleartext. So I enabled authentication in the mail client again, sent myself another test email and sniffed the network traffic (have I ever mentioned how much I love ethereal?). I monitored the whole transaction between the client and the server. The SSL/TLS authentication was successful after which all content was encrypted. So, I think the mail system is finally to a point I’m satisfied with.

Well, it turns out enabling SMTP over SSL wasn’t as difficult as I anticipated. I had to create another certificate for it in /usr/share/ssl/certs, although I’m sure I could have just copied the imap certificate and used it. None the less I created one for sendmail using make sendmail.pem (in the /usr/share/ssl/certs directory).

Next I had to modify my /etc/mail/sendmail.mc file. Specifically I had to add the following:
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’)

I updated the sendmail.cf file by running m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf and restarted the sendmail daemon. To test it I used telnet localhost 25 and issued the EHLO localhost command. The server returned some information including “250-STARTTLS” indicating that SSL was enabled. I changed the configuration of my mail client to use SMTP over SSL and sent a few test emails to myself. Everything looks good. All of these changes were specifically for sendmail shipped with RedHat 8.0, but sendmail has a more generic setup description on their site.

The next thing I’d like to do is enable AUTH on sendmail so relaying will be enabled by the mail client authenticating. Right now I’ve specified the hosts to allow relaying from in a file but that causes problems if I’m using DHCP or dialing in. Unfortunately it looks like I’m going to have to recompile sendmail to do that. Hmm…something for a rainy day.

I’ve been wanting to setup secure email on the server so I can use a mail client on my laptop to access and send email regardless of what network I’m connected to. Setting up IMAP over SSL was very simple. I changed the “disabled” entry in my /etc/xinetd.d/imaps file to no and then removed the default localhost imapd.pem certificate in /usr/share/ssl/certs and created a new one using make imapd.pem (here are some instructions I followed). I restarted the xinetd daemon and configured my mail client to use IMAP over SSL and everything worked. Very nice!

That takes care of receiving mail but I have a feeling setting up SMTP over SSL might be a little more difficult. Esspecially since I’m still using sendmail. Perhaps this would be a good time to switch over to postfix. Hmm… I think I’ll save all that for another day.