Ultimate Linux Server Part 1: Web Proxy

Ultimate Linux Server
Part 1: Web Proxy

    What is the “Ultimate Linux Server”? I suppose that if you asked ten different people you would get just as many different answers. My definition is a basic server running a stripped down operating system to which services can be added as necessary. Simplicity and security go hand-in-hand; the fewer services or “bells and whistles” a server is running, the more secure and reliable it will be.

    My version of the “Ultimate Linux Server” starts with a minimal install of Debian Linux and an application called Webmin. Webmin is a web based administrative interface for managing all aspects of a Linux server.

    This article is the first in a series of several installments. For now, we will build the basic server and install a web proxy application on it. Future articles will explain how to build upon this base server, adding services such as a mail server, anti-spam filter, DHCP server, DNS server, etc. The Webmin application also contains features to manage the server itself, such as back up, service monitoring and alerts to email and SMS, etc. These features will also be covered in future articles.

    As the title of this article infers, we will be installing a web proxy application. Why do you need a web proxy? A question was posed by a colleague recently concerning how to monitor web traffic and report on which users were going to what sites on the internet. A web proxy can be used to intercept all HTTP traffic destined for the internet and log which computers are going where. In addition, the web proxy we are going to install (Squid) acts as a caching web proxy which can speed up the loading of previously accessed web sites. An additional application called “SARG” produces very nice reports of all web traffic based upon such criteria as source IP, destination web site, the time frame web sites were accessed, the most active users of HTTP, etc.

    In an attempt to make the installation and configuration as easy as possible, we will use a method where-by the server is accessed remotely from your own desktop PC and commands are run on the server via a terminal application (with the exception of the initial installation of the operating system which must be done using a keyboard and monitor attached directly to the server).  These commands are presented in bold type and can simply be copied and pasted into the terminal window. This server is designed to run “lights out” without a monitor or keyboard attached during normal operation.

    The recommended minimum hardware configuration would be a P4 1.5 GHz (or equivalent), 512Mb RAM, and a 40 GB (or bigger) hard drive. Linux isn’t as resource intensive as some other operating systems so the above recommendations should work very nicely. Feel free to add more RAM as you install additional services.

    Let’s begin by getting the operating system installed. Download and burn a copy of Debian Linux. I recommend getting the network install image; it’s very small and you only need a very few basic packages anyway. Go here: Debian and download the appropriate “netinst” image (i386 for most of you). Make sure you burn this as an ISO “image” and then boot your new server to this CD. Go ahead and install Debian, making sure that you are plugged into the network and the internet is accessible. You can safely accept the defaults most of the way through, with the following exceptions:

1.    If your server grabs a DHCP address, use the tab key to choose “go back”, then choose “configure network manually” and assign an appropriate static IP.
2.    When you get to the “Software selection” screen, unselect everything (trust me). This is done by using the space bar to toggle your selection and the “down” arrow key to move through the menu. Once you have deselected all options, use the “tab” key to choose continue and hit “enter”.

    After it installs grub (the boot loader), it will spit the CD out at you and you simply hit “enter” to continue and boot into your new Debian system.

    At this point, you should be staring at a login prompt (yes, it’s all text based, no “point and click” here). Simply type root, hit “enter”, and then the password you chose for root when you installed the OS. Now, we’re going to do some basic setup:

1.    Type nano -w /etc/apt/sources.list. This will open a file up in an editor.
2.    Using your arrow keys to move around, put a “#” sign in front of the second line that starts with “deb cdrom” (this is called a “comment” and it means that the line will be ignored). Then move the cursor to the end of the first line that starts with “deb http” and add “contrib” and “non-free”. It should look something like this:
“deb http://ftp.debian.org/debian/ etch main contrib non-free”
3.    Do the same for the remaining lines.
4.    Hit “ctrl o” (the ctrl button and the letter “o” at the same time), then “enter”, and then “ctrl x” to save and exit.
5.    Type the command apt-get update.
6.    Type the command apt-get install openssh-server (just hit enter when it asks you if you want to continue).

    It is a very bad idea to allow root logins via SSH so we need to edit the SSH configuration file to prevent this

1.    Enter the command nano -w /etc/ssh/sshd_config, this will open up a file in an editor. Using the same method that you used earlier to edit the “apt” file, look for the line that reads “PermitRootLogin Yes”, change “yes” to “no”, and save your changes (crtl o/enter/crtl x).
2.    Enter the command etc/init.d/ssh restart and hit enter.

    We can now finish the install remotely from our desktop by simply cutting and pasting commands into a terminal window connected to the Debian box. Linux users can simply open a terminal and connect to the Debian box using SSH. Windows users will need to download a small program that will allow terminal connections to a Linux box. This program, called “putty”, allows a Windows box to use SSH (the secure shell protocol) and can be found here: putty (just grab “putty.exe” and save it to your desktop). Open up putty, enter the IP address of your Debian box, the “regular user” name (that you created when you installed Debian), and the corresponding password.

    Once you have connected to the server via SSH, you can simply copy and paste the remaining commands (one line at a time unless otherwise noted, followed by hitting the “enter” key) into the terminal window to complete the installation and configuration.

    The next step is to add an additional repository to our /etc/apt/sources.list file and then perform a quick upgrade (“apt” is the package manager for Debian, it is used to download and install any of the tens of thousands of freely available software applications). Use the code below:

su
(enter root password)
nano -w /etc/apt/sources.list
(cut and paste the following on a new line at the bottom of the file)
deb http://download.webmin.com/download/repository sarge contrib
save your changes (crtl o/enter/crtl x)
apt-get update
apt-get dist-upgrade (choose “yes” when asked if you want to continue, if any dialog boxes pop up, hit “tab” and then “enter”)
reboot

    The reboot will knock you out of the remote session, so wait a minute for the box to reboot, then reconnect with SSH (or putty). We will now install Squid (the web proxy application) and SARG (Squid Analysis Report Generator). Use the code below:

su
(enter root password)
apt-get install squid sarg
(answer “yes” to any questions asked)

    If all went well, Squid and SARG are now installed but we need to edit the Squid configuration file to allow our local network to use the proxy server. While this can be accomplished through the Webmin interface, it involves several detailed steps to do it that way and it is much easier just to edit the underlying configuration file on the command line. Use the code below:

nano -w /etc/squid/squid.conf
(scroll waayyyy down to “# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS” and uncomment “acl our_networks” by removing the “#” at the beginning of the line and then adapt as necessary for your network)
(mine looks like this: “acl our_networks src 192.168.12.0/24”)
(uncomment the  “http_access allow our_networks” line)
save your changes (crtl o/enter/crtl x)
/etc/init.d/squid restart

    Now we need to install Webmin and any other packages that it depends upon to function properly. Use the code below:

apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl libmd5-perl mailx webmin (NOTE: this command should all be on one line!)
(choose “yes” to any questions asked)

    That should do it as far as the installation and configuration goes, now it’s time to log into Webmin and have a look around. Open up a browser and point it to:

 https://the_IP_address_of_your_new_Debian_server:10000

    Log in as “root” with the same root password that you use to log into the server itself. You should now be looking at the Webmin interface. Take some time and explore a bit; you’ll get an idea of how powerful this interface really is! You will also discover that quite a few options are either unavailable or not installed/configured yet. We’ll get to those in a future article.

    Expand “Servers” in the left side panel, then click on “Squid Analysis Report Generator”.  Now, click on “Generate Report Now”. Whoops! Error, no records found. This is because there is no information in the log files to report. We now need to configure the web browsers on all the PC’s on our LAN to use our new proxy server to get to the internet. Configure the settings in the web browsers of your LAN machines to use a proxy (but ONLY for HTTP!). Enter the IP address of the new server as a proxy and 3128 as the proxy port. (The specifics on how to do this depend on which browser you use.) I also recommend checking the “do not use proxy for local connections” setting.  If you are a Microsoft shop and use IE, you should be able to push this out with a GPO. Now, hit a few web sites from a LAN PC then go back to Webmin and click on “Generate Report Now”. Click on “View completed report”, then click on the date under “FILE/PERIOD”. You should see some data. Everything in blue is a link to detailed data, the tiny icons are clickable too. Use the browser “back” button to return to the previous page. (Cool stuff, huh?)

    I must advise you that there is a bug with the software: If you click the “Log Source and Report Destination” icon, there is an option to enter an email address to have reports sent to. When you enable this particular option and enter an email address, subsequent report generation will fail. Bottom line is do not enable the “Email report to” option. (This is really no big deal because the emailed reports are nothing but a simple text message with very little useful information anyway). Otherwise, feel free to play with the other settings for SARG.

    One last note: savvy users will probably catch on to the fact that you are watching them and will change their proxy settings back to “connect to internet directly” to avoid being monitored. To prevent this, you should create an egress (outbound) rule on your firewall that will only allow outbound HTTP traffic if it originates from the proxy server IP (heh heh).

    As always, if you have any questions, comments, problems, or want to make a large charitable donation in my name, please feel free to contact me at thughes@fwpm.com.

RESOURCES:
Squid: http://www.squid-cache.org/

SARG: http://sarg.sourceforge.net/sarg.php

Webmin: http://www.webmin.com/

Debian: http://www.debian.org/

Putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/

Burning CD images: http://www.petri.co.il/how_to_write_iso_files_to_cd.htm

Copyright 2007 Todd Hughes
 
{mos_fb_discuss:no_discuss} 

Email Troubleshooting: Back to Basics

Email has undergone a major transformation in the past decade . What began as a simple means to send a quick message has evolved into a business critical application.  This increased use of email as a primary communication method has placed an emphasis on maintaining the availability of this service to the users. One of the best methods for diagnosing problems with email is what I refer to as “getting back to the basics”.

    Getting back to the basics means separating the email application software from the protocol itself.  Application software can be either an MUA (Mail User Agent) such as Outlook or Thunderbird, or an MTA (Mail Transport Agent) such as Exchange or Postfix. We will concentrate on working with the underlying protocols only.  Troubleshooting  software beyond basic configuration (proper user name and password, correct mail server IP and port number, mailbox setup, etc.) is beyond the scope of this article.

    There are 3 main protocols we will deal with when troubleshooting email. SMTP (Simple Mail Transfer Protocol) is used to send email. The SMTP protocol “pushes” messages, whether it's from the desktop to the internal email server, or from one email server to another. It is important to keep in mind that this is a “best effort” or “store and forward” protocol which means that there is no guarantee of successful delivery. POP3 (Post Office Protocol 3) and IMAP (Internet Message Access Protocol) are used to retrieve email. POP3 and IMAP “pull” messages from an email server to the desktop. POP3 downloads the entire message to the desktop when an email is read. IMAP downloads only the email header information when a mail check is performed, the message itself is actually opened and read right on the mail server (making IMAP a bit more bandwidth friendly). Both of these protocols send login credentials to the mail server in clear text unless the secure version of the protocol (POP3S or IMAPS) is used. While there are other proprietary email protocols in use, we will concentrate on the aforementioned 3 which are considered the standards for internet email transport.

    The most important tip I can give is to pay very close attention to any error messages you may receive related to mail delivery. If a user states “I sent an email, but I got an error message back”, you need to tell that user to copy the error message down verbatim. Email error messages are usually very specific about what the problem is. Here's an example:

This is the Postfix program at host mail.mydomain.com.

 

I'm sorry to have to inform you that your message could not

be delivered to one or more recipients. It's attached below.

 

For further assistance, please send mail to <postmaster>

 

If you do so, please include this problem report. You can

delete your own text from the attached returned message.

 

         The Postfix program

 

<joeshmoe@budweiser.com>: host mail1.synacor.com[64.8.70.127] said: 553 sorry,

  your envelope recipient is in rejected. either it has been deactivated or

  does not exist (#5.7.1) (in reply to RCPT TO command)

 

    The above message comes from my mail server (mail.mydomain.com) and is telling me that my message to joeshmoe@budweiser.com could not be delivered. Specifically, the mail server for “budweiser.com” (mail1.synacor.com[64.8.70.127]) said that the recipient (joeshmoe) either doesn't exist or his account has been deactivated. Note the “553”, this is an SMTP reply code. Anything in the 500 range means “permanent error”, the 400 range means “temporary error/will try again”, and anything in the 200 range means “success/OK”.

    Troubleshooting sending (SMTP) errors is done on the command line using the SMTP commands. If you suspect a problem between the desktop and the internal mail server you should do this from the desktop, if the issue is suspected to be outside of your network you need do this from the mail server itself. We'll make a connection to the recipients mail server and attempt to send a message “by hand” using some basic SMTP commands and see what happens. If you are testing from the desktop, you already know what the mail server's IP of FQDN is, if you are testing from your internal mail server to an outside server, you need to look up the name or IP of the recipient's mail server. This can be done with “nslookup” (Windows) or the “dig” command (Linux). Once we know how to get to the recipient's server, we'll make a telnet connection to port 25 (SMTP), then we'll introduce ourselves (the “helo” or “ehlo” command), and finally we will send an email and see what type of reply codes we get. Open up a terminal or command prompt and let's get started!

Look up the mail server:

thughes@thughes:~$ dig mydomain.com mx
;; QUESTION SECTION:
;mydomain.com.                        IN      MX
;; ANSWER SECTION:
mydomain.com.         736     IN      MX      5 mail.mydomain.com.

Make a connection (telnet) to that mail server on port 25 :

thughes@thughes:~$ telnet mail.mydomain.com 25
Trying 73.42.65.188…
Connected to mail.mydomain.com.
Escape character is '^]'.
220 mail.mydomain.com at your service ESMTP NO UCE 
 

(notice the 220…that means OK)       

Now, introduce yourself by typing “ehlo <something>” (I typed “ehlo howdy!”):

Trying 74.41.65.188…
Connected to mail.mydomain.com.
Escape character is '^]'.
220 mail.mydomain.com at your service ESMTP NO UCE
ehlo howdy!
250-mail.mydomain.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250 8BITMIME

If you get an error when using the “ehlo” (extended helo) command, the server probably doesn't support the extended version of the command so just use the standard “helo” command. Again, notice all the 250 codes, these mean that this server supports all of the listed options.

Let's send an email:

Type “mail from: <your email address>” (the “<” and “>” are necessary in this command)

Trying 74.41.65.188…
Connected to mail.mydomain.com.
Escape character is '^]'.
220 mail.mydomain.com at your service ESMTP NO UCE
ehlo test
250-mail.mydomain.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250 8BITMIME
mail from: <thughes@fwpm.com>
250 Ok

(There's that 250 again)

Type “rcpt to: <recipient's email address>”

Trying 74.41.65.188…
Connected to mail.mydomain.com.
Escape character is '^]'.
220 mail.mydomain.com at your service ESMTP NO UCE
mail from: <thughes@someotherdomain.com>
250 Ok
rcpt to: <thughes@mydomain.com>
250 Ok

(250 again)

Now we need to add some data to the email, so type “data” and hit the “enter” key,  then type “SUBJECT:” (add a subject), hit “enter”, type “FROM:” (type the from address), hit “enter”, type “TO:” (type the to address), hit “enter” twice, and then type the body of your email. When you're done typing your message, hit the “.” key and you should get a message that the email was sent (“queued”) on the recipient's server, then type “quit”. All of the commands that I typed in the following example are in bold type:

Trying 74.41.65.188…
Connected to mail.mydomain.com.
Escape character is '^]'.
220 mail.mydomain.com at your service ESMTP NO UCE
mail from: <thughes@someotherdomain.com>
250 Ok
rcpt to: <thughes@mydomain.com>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
FROM: mickeymouse@donaldduck.com
TO: thughes@mydomain.com
SUBJECT: test email

This is a test email
.
250 Ok: queued as 56CBE3B018E
quit
221 Bye
Connection closed by foreign host.

This message was sent successfully (“250 Ok: queued as 56CBE3B018E”). If there was a problem, the reply code would have told me exactly what the problem was. You may also have noticed that when I typed in the “FROM:” field, I used an address other than the one that I used in the initial “mail from:” command, this is because the “FROM:” in the headers of the email do NOT have to match the original connecting (“envelope”) sender. This is how spammers spoof email (heh heh).

    Alright, delivery works, now we need to test mail retrieval. Let's do some POP command line magic next. First, we need to telnet to our internal mail server on port 110 (995 for POPS):

thughes@thughes:~$ telnet mail.mydomain.com 110
Trying 192.168.12.80…
Connected to mail.mydomain.com.
Escape character is '^]'.
+OK dovecot ready.

Now we need to authenticate by typing “user <username>”, hit “enter”, then type “pass <your password>” and hit “enter” again:

thughes@thughes:~$ telnet mail.fwpm.com 110
Trying 192.168.12.80…
Connected to mail.fwpm.com.
Escape character is '^]'.
+OK dovecot ready.
user thughes
+OK
pass *********
+OK Logged in.

We're in!  Now type “list” to see all the emails (they are listed numerically, the first number  is the message number, the second number is the message size), type “retr (message #)”  and hit “enter”, and your message will be displayed. Type “quit” to disconnect from the POP server.

    Finally, let's try email retrieval using IMAP. Telnet to the internal mail server on port 143 (993 for IMAPS) and log in by typing “a01 login <user name> <password>”:

thughes@thughes:~$ telnet mail.mydomain.com 143
Trying 192.168.12.80…
Connected to mail.mydomain.com.
Escape character is '^]'.
* OK dovecot ready.
a01 login thughes ********
a01 OK Logged in.

Next, lets list our mailboxes. Type “a02 list “” “*”” and hit “enter”:

ao2 list "" "*"
* LIST (\NoInferiors) "/" INBOX
* LIST (\NoInferiors \UnMarked) "/" "Trash"
* LIST (\NoInferiors) "/" "Ebay"
* LIST (\NoInferiors) "/" "Sent"
ao2 OK List completed.

Now we can enter a mailbox:

a02 select INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk $Label1 $Label2 $Label3 $Label4 $Label5 NonJunk)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk $Label1 $Label2 $Label3 $Label4 $Label5 NonJunk \*)] Flags permitted.
* 1142 EXISTS
* 3 RECENT
* OK [UNSEEN 1131] First unseen.
* OK [UIDVALIDITY 1157335433] UIDs valid
* OK [UIDNEXT 26939] Predicted next UID
a02 OK [READ-WRITE] Select completed.

Fetch the headers for the first email in the list:

ao2 fetch 1 all
* 1 FETCH (FLAGS (\Seen) INTERNALDATE "18-Aug-2006 09:43:33 -0400" RFC822.SIZE 21975 ENVELOPE ("Thu, 17 Aug 2006 13:06:55 -0400" "Official: Jul-Aug 2006 (ISC)2 Newsletter" (("(ISC)2 Management" NIL "management" "isc2.org")) (("(ISC)2 Management" NIL "management" "isc2.org")) (("(ISC)2 Management" NIL "management" "isc2.org")) ((NIL NIL "thughes" "mydomain.com")) NIL NIL NIL "<LYRIS-1619473-1789-2006.08.17-16.13.08–thughes#mydomain.com@isc16.isc2.org>"))
ao2 OK Fetch completed.

Read some mail:

ao2 fetch 1 body[text]

(This should show you the message body)

Close the connection by typing “ao2 logout”:

a02 logout
* BYE Logging out
a02 OK Logout completed.
Connection closed by foreign host.

   
    That's about it for command line troubleshooting using the basic protocols. The point of the preceding exercises is to confirm that mail can be sent and received. If you are successful using the command line to send/retrieve mail but it doesn't work when using applications such as Outlook or Thunderbird, you can now concentrate your efforts on troubleshooting the software application and configuration.

    The logs on your mail server can provide a wealth of information to aid you in diagnosing problems. Becoming proficient in reading the logs is one of the most important things you can do. Take a look at the mail logs and learn how to read them. Try to follow an email through the logs from the time it hit the server until it was delivered to the recipient.  

    Email headers are also a valuable source of information. You can view the complete headers in most email clients by choosing an option such as “view > all headers”, right clicking the email and choosing “view internet headers”, etc. The exact method depends on which client you are using, Google it if you can't figure out how. Headers are read from the bottom up (use the time stamps as a reference). Below is an example of a full set of headers (I added the comments in bold):

Return-Path: <apache@isc18.isc2.org>
 X-Original-To: thughes@fwpm.com
 Delivered-To: thughes@fwpm.com

This is my mail gateway delivering the message to my mail server:

 Received: from fw.fwpm.com (unknown [192.168.12.1])
by mail.fwpm.com (Postfix) with ESMTP id 280A23B019E
for <thughes@fwpm.com>; Mon,  1 Oct 2007 10:51:03 -0400 (EDT)

This is my mail gateway processing the mail internally:

 Received: from fw.fwpm.com (localhost [127.0.0.1])
by fw.fwpm.com (Postfix) with SMTP id 4E54FAC07F
for <thughes@fwpm.com>; Mon,  1 Oct 2007 11:08:13 -0400 (EDT)

This is the spam processing and scoring on my mail gateway (spamassassin):

(sender vscan@fw.fwpm.com)
 X-Spam-Checker-Version: mailDefender 3.1.3 (2006-06-01)
 X-Spam-Level: S
 X-Spam-Status: No, hits=1.9 reqd=5.0 tests=NO_REAL_NAME=0.55,
SPF_HELO_SOFTFAIL=0.1,SPF_SOFTFAIL=0.1,XD_DYNAMIC_IP=0.9, XD_MULTIPART=0.2
Bayes=0.5
 X-Spam-Report: *  0.9 XD_DYNAMIC_IP At least one relay is a dynamic IP *  0.6
NO_REAL_NAME From: does not include a real name *  0.2 XD_MULTIPART Email
contain several alternative views *  0.1 SPF_SOFTFAIL SPF: sender does not
match SPF record (softfail) *      [SPF failed: ] *  0.1 SPF_HELO_SOFTFAIL
SPF: HELO does not match SPF record (softfail) *      [SPF failed: ]

This is my mail gateway receiving the email from the sender's server:

 Received: from isc18.isc2.org (isc18.isc2.org [216.12.146.142]) (using TLSv1
with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate
requested) by fw.fwpm.com (Postfix) with ESMTP id E5E2BAC07E for
<thughes@fwpm.com>; Mon,  1 Oct 2007 11:07:48 -0400 (EDT)

This is the sender's server receiving the mail from an internal process:

 Received: from isc18.isc2.org (isc18.isc2.org [127.0.0.1]) by isc18.isc2.org
(8.13.1/8.13.1) with ESMTP id l91F7mL0022786 for <thughes@fwpm.com>; Mon, 1
Oct 2007 10:07:48 -0500

Here's the message:

 Message-Id: <200710011507.l91F7mmV022784@isc18.isc2.org>
 Content-Transfer-Encoding: binary
 Content-Type: multipart/related; boundary="_———-=_1191251268227820"
 MIME-Version: 1.0
 X-Mailer: MIME::Lite 3.01 (F2.73; B3.07; Q3.07)
 Date: Mon, 1 Oct 2007 15:07:48 UT
 To: thughes@fwpm.com
 From: service@isc2.org
 Subject: (ISC)2: Confirmation of change to CISSP CPE Record
 X-AVAS-Signature: pfilter.pl Version 1.73
 X-AVAS-EmailID: 20070901-110749-7603
 Status: RO
 X-UID: 26809
 Content-Length: 761
 X-Keywords:
 X-Length: 3068
 
=== This is a system generated message from (ISC)2 ===

Dear T. Hughes:

This email message is blah…blah…blah.

    As you can see, the headers provide a detailed record of mail routing. You can use the time stamps at each hop to determine where any latency in delivery may be. Another trick is to use the header information to verify a spoofed email. If an email appears to come from somebody you know but looks suspicious, view the headers to determine the IP address of the original sending server. Perform a “whois” lookup on that IP address; if it comes back as registered to a Chinese or Eastern European domain (for example) you can be certain it is a spoof.

    Lastly, I want to comment about email security. Today's users tend to send anything (including very sensitive or personal information) via email without any thoughts of security or confidentiality. Email is not secure! As mentioned earlier, SMTP, POP3, and IMAP are all clear text protocols. This is akin to sending your snail mail on postcards instead of inside an envelope, safe from prying eyes. There are a few basic precautions you can take to secure your email. One would be to use POP3S and IMAPS to retrieve mail. Secondly, you should configure your mail server to support TLS (Transport Layer Security). TLS will allow encrypted SMTP communication with any recipient's server that also supports TLS. It should be noted that you must configure TLS to be optional, if the receiving server does not support TSL the communication will fall back to plain text.
Thirdly, I would suggest the use of an email encryption application (such as Zix mail) to ensure sensitive information is transmitted securely. Finally, user training is a must. Your users need to have a basic understanding of how email works. They need to know that it is neither secure (in it's default configuration) nor guaranteed to be delivered to the intended recipient.

    I hope you have found the information and tips in this article interesting and informative. Feel free to contact me if you if you have additional input or would like further information about the techniques I have presented.

Todd Hughes is a Network Security Analyst and long time Linux fan in the Upstate New York area. Send your Questions, comments or feedback to: thughes@fwpm.com.

Copyright  Todd Hughes  2007. Printed by permission.

 

{mos_fb_discuss:174} 

Linux as an alternative to Windows

    If you are anything more than a very casual computer user,  you've probably heard someone talking about Linux recently. Perhaps you're wondering exactly what Linux is and what all the fuss is about?  Well, read on and we'll attempt to answer some of the questions you may have and hopefully dispel a few myths and misconceptions along the way.

    Linux is an operating system much like Windows XP or Vista, Mac OSX, etc. An operating system is basically just a bunch of instructions that manage the software and hardware on your computer. Software refers to all of the applications that you use, such as word processing programs, web browsers, email clients, etc. Hardware is the physical parts of your computer such as the processor, memory, CD drives and the like.

    Why would I want to try Linux? I would have to say that the main reason for using Linux is that it's free. Yes, FREE! Linux is an “open source” operating system. The definition of open source is software that has been developed by a community of folks and provided to the general public, free of cost.  A second reason is that it runs very well on an older computer that may not be capable of running the newest version of Windows. Thirdly, there are literally tens of thousands of open source applications (software) that are available for download. Lastly, there is security.  Linux was developed from the start with security in mind. The Linux operating system is not as susceptible as Windows is to a majority of the threats that are common on the internet today.

    OK, so what's the catch? Well, there is a new user interface to learn. The Linux desktop doesn't “look” like a Windows desktop. Of course, a Vista desktop doesn't look like an XP desktop and a Mac desktop doesn't look like a Windows desktop, so there is a bit of a learning curve going from one operating system to another, regardless of which one you choose.  Linux also has a reputation of being a “techie's” operating system, requiring a bit more knowledge to set up and use than the typical user may possess but this has been largely eliminated as of late. Another issue is that Linux may not work with the latest cutting edge hardware, although as the use of Linux becomes more widespread this is less of a problem that it has been in the past.

    Who is Linux good for? This operating system works very well for those of us that simply need the basics: browsing the web, checking email, writing documents, working with spreadsheets, etc. Linux is a great choice for those Windows 98/2000/XP users whose old computers are running really slow and are considering upgrading but have to buy a new PC just to run Vista. It's also good for those power users that like to dig around and play “under the hood” so to speak. Linux will not work for those users that need to run Windows only software such as QuickBooks, or “gamers” who play games written exclusively for Windows.

    Alright, so you've decided that you want to try Linux, now what? My suggestion is to download a copy from the internet and see how you like it. Linux comes in many varieties called “distributions” (or “distros”). There are several distros that I can recommend for a new user; these are listed at the end of this article. All of these are available in what is referred to as a “live” format, meaning that they can be run from a CD without actually having to install them on the hard drive of your computer. You simply download and burn the CD, put it in your CD player, and reboot your computer. (Keep in mind that they will run a bit slower than they would if they were actually installed). This allows you to get a feel for Linux and how it works, as well as testing whether a particular distribution can detect and correctly configure all of your hardware. If you decide that you like one of these, there is usually an “install to hard drive” option right on the desktop. You can even install Linux in parallel to Windows and choose which operating system to load when your computer boots up!

    What if I have problems, where can I get help? There is a fantastic community of Linux users on the internet that are more than happy to help new users. Google is your friend. Most communities have a local Linux User's Group (LUG) that holds open meetings on a regular basis; new members are always welcome. These LUG's usually have occasional “Install Fests” where you can bring you computer and they will help you install Linux and answer any questions you may have. Check you local computer magazines for information on these type activities and groups.  Again, Google is your friend.

    I hope this article has answered some of your questions about Linux and maybe even made you consider giving it a try. Below is a list of resources you will find helpful if you decide to pursue this further.

Todd Hughes is a Network Security Analyst and long time Linux fan in the Upstate New York area. Send your Questions, comments or feedback to: thughes@fwpm.com.

Copyright  Todd Hughes  2007. Printed by permission.
   

Resources:

Recommended Distributions:

http://www.pclinuxos.com/index.php?option=com_ionfiles&Itemid=28
http://www.xpresslinux.com/download.php
http://www.kubuntu.org/download.php
http://www.knopper.net/knoppix/index-en.html
http://www.mepis.org/mirrors
http://www.mandriva.com/en/download/free

Other Distributions:

http://distrowatch.com/

How to “burn” a disk properly:

-using Windows XP
http://www.petri.co.il/how_to_write_iso_files_to_cd.htm

-using Nero
http://www.wizardskeep.org/mainhall/tutor/neroiso.html

-using Roxio
http://onlinepubs.trb.org/onlinepubs/burning_iso.html

 

{mos_fb_discuss:35}