Friday, January 8, 2010

How to Turn File Sharing On or Off in Vista

SkyHi @ Friday, January 08, 2010
1. Open the Control Panel (Classic View).

2. Click on the Networking and Sharing Center icon.

3. Click on Manage network connections in the upper left corner.

4. Right click on the Network Connection you want to share the Public folder with, and click on Properties.

5. Click on Continue in the UAC prompt.

6. Check File and Printer Sharing for Microsoft Networks and click on OK. (See screenshot below)
NOTE: This is checked by default. This must be checked to be able to turn on file sharing in STEP TWO below.

Turn File Sharing On or Off
1. Open the Control Panel (Classic view).
A) Click on the Network and Sharing Center icon.

B) Go to step 3.

2. Right click on the taskbar Network system tray icon.
A) Click on Network and Sharing Center.
3. Click on the down arrow to the right of File sharing to expand it. (See screenshot below)
4. To Turn On File Sharing -
NOTE: With file sharing on, all people on your network will have access to the files and printers that you have set to Share on your computer.
A) Select (dot) Turn on file sharing. (See screenshot below step 7)

B) Go to step 6.
5. To Turn Off File Sharing -
NOTE: With file sharing off, all people on your network will not be able to access the files and printers that you have set to Share on your computer.
A) Select (dot) Turn off file sharing. (See screenshot below step 7)
6. Click on the Apply button.

7. If prompted, click on Continue in the UAC prompt.

Enable Simple File Sharing
1. For how, see: How to Enable Simple File Sharing in Vista

That's it,


ClamAV as a sendmail milter

SkyHi @ Friday, January 08, 2010
Step 1 - Compiling sendmail
Step 2 - Compiling ClamAV
Step 3 - Configuring and starting ClamAV
Step 4 - Tying ClamAV into sendmail


ClamAV is a popular tool which scans e-mail for Windows-based viruses1. It can work in several manners, such as the traditional Unix way of accepting the data through stdin and sending reports out through stdout, stderr and/or an appropriate exit code, or it can be used as a sendmail milter.

The principle of a sendmail milter is simple. As the mail is coming down the pipe from the remote host, sendmail feeds it through the milter and then waits for the milter's reaction. If the reaction is "all is well" then processing carries on as usual. If, on the other hand, the result of the milter operation is "I didn't like this!" then the mail is rejected right there and then.

The aim of this becomes apparent in the current climate of 'Net abuse in which the number of junk e-mails and virus infections2 outweighs the amount of genuine e-mail by far, and in which viruses routinely forge the From: address from which they claim to be sent. If we were to accept the mail, discover that it was infected after having accepted it, and then strive to comply with the relevant RFC which states that the sender must be informed in the event of mail not being delivered to the final recipient, we'd be bouncing mail back to innocent bystanders whose only mistake (admittedly a big mistake given the abysmal security track record of the most widespread operating system for desktop PCs) was to have their e-mail address in a friend's address book or in the clear on a web page.

Note that bouncing the original mail back on the one hand, and sending a thoughtful message saying "Your message to XYZ was not delivered because it contained virus ABC" on the other are both equally abusive!

There is only one way we can reject an infected mail outright without generating an abusive bounce, and that is to reject the mail during the SMTP session in just the same way you'd reject spam from a blacklisted IP address or domain. This is precisely the purpose of using ClamAV as a sendmail milter.

I'll be assuming that you're not a total newbie in this document. It is assumed that you're familiar with compiling software and playing with configuration files, above all sendmail's configuration files.

Step 1 - Compiling sendmail

If you're using a binary distribution of sendmail prepared by a Linux distribution supplier such as Debian, Mandrake, SuSE or Red Hat/Fedora, the chances are that your binary has been compiled with milter support and you can skip this part and move straight on to step 2. As a general rule, if you have a file called libmilter.a in /usr/lib or /usr/local/lib and a directory called libmilter in /usr/include or /usr/local/include, then your version of sendmail has been compiled with libmilter support. If not, read on.

Grab a source tarball from a mirror (see for a list of mirrors) and untar the tarball. As of writing this (23/JUL/2004) the latest stable version of sendmail is 8.13.0.

Now set it up so that milter support will be added. Go into the devtools/Site directory under the source root and edit (or create if it doesn't already exist) site.config.m4 so that it contains these 2 lines:
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
Now go back to the source root and build/install sendmail as usual.

Before running sendmail, we'll need to build libmilter. Go into the libmilter directory under the sendmail source tree root and run:
# sh Build
# make install
The libmilter library and include files are now installed.

Step 2 - Compiling ClamAV

Start by creating the "clamav" user and group as which the milter will run (it's not a good idea for it to run as root):
# groupadd clamav
# useradd -g clamav clamav
Create the directory /usr/local/share/clamav in which we'll be instructing ClamAV to put its virus signature database, then give the directory appropriate permissions:
# mkdir /usr/local/share/clamav
# chown clamav:clamav /usr/local/share/clamav
Now grab the ClamAV source from A list of available downloads is available at Latest is 0.75 as of today.

Untar the tarball, build and install ClamAV:
# tar -xzf clamav-0.75.tar.gz
# cd clamav-0.75
# ./configure --disable-clamuko --enable-milter --with-dbdir=/usr/local/share/clamav
# make
# make install
Step 3 - Configuring and starting ClamAV

No particular "--prefix=..." option was given while compiling ClamAV, meaning that its installation prefix is the default /usr/local. ClamAV will therefore expect to find its configuration file in /usr/local/etc/clamav.conf. The sample configuration in the etc directory under the ClamAV source tree root is well commented and should give you plenty of information on what needs changing and what it should be changed to.

Once your clamav.conf file is set up in /usr/local/etc you can start the ClamAV daemon:
# /usr/local/sbin/clamd
It is also recommended that you make sure clamd is started when the machine boots. You can do this by appending the required command to your /etc/rc.d/rc.local file:
# echo "/usr/local/sbin/clamd" >> /etc/rc.d/rc.local
Next, before ClamAV can recognise viruses it needs a signature database. Furthermore, this database must be kept up to date as new varieties of virus are being released every day. ClamAV provides a tool called freshclam for this. This tool also needs a configuration file, /usr/local/etc/freshclam.conf. The sample provided in the ClamAV distribution can also be used as a starting point for your own configuration.

Once that's set up, we need to grab an initial virus signature database. We'll be logging the database retrieval in /var/log/clam-update.log, so create the file and above all give it permissions such that freshclam (running as user clamav, group clamav) will have write access to it:
# touch /var/log/clam-update.log
# chown clamav:clamav /var/log/clam-update.log
# chmod 640 /var/log/clam-update.log
Now invoke freshclam and get it to download the latest definitions (this can take some time on a slower connection):
# /usr/local/bin/freshclam -l /var/log/clam-update.log
ClamAV update process started at Sat Jul 24 17:04:12 2004
Reading CVD header (main.cvd): OK
Downloading main.cvd [*]
main.cvd updated (version: 24, sigs: 21793, f-level: 2, builder: tomek)
Reading CVD header (daily.cvd): OK
Downloading daily.cvd [*]
daily.cvd updated (version: 420, sigs: 1062, f-level: 2, builder: tomek)
Database updated (22855 signatures) from (
If you get a warning about there being no support for digital signatures while downloading the virus definition files, it's because you don't have the GNU MP arbitrary precision mathematical libraries installed. These are available from While they're not absolutely necessary, they are strongly recommended because they help ClamAV provide greater security and data integrity.

/var/log/clam-update.log should look something like this now:
ClamAV update process started at Sat Jul 24 17:04:12 2004
main.cvd updated (version: 24, sigs: 21793, f-level: 2, builder: tomek)
daily.cvd updated (version: 420, sigs: 1062, f-level: 2, builder: tomek)
Database updated (22855 signatures) from (
It will also contain the warning about the lack of support for digital signatures if the GMP libraries are not installed.

This update process should be automated and should happen at least twice a day. As root, run crontab -e and create this cron job:
# Update ClamAV database twice a day
0 2,13 * * * /usr/local/bin/freshclam --quiet -l /var/log/clam-update.log
Now you can test the software to make sure it's installed correctly. 'cd' into the test directory under the ClamAV source tree root. You'll see several files in there which contain ClamAV test signatures that ClamAV should pick up. Try scanning the 'test' file:
# clamdscan test
test: ClamAV-Test-Signature FOUND

----------- SCAN SUMMARY -----------
Infected files: 1
Time: 0.006 sec (0 m 0 s)
If you get something like this:
# clamdscan test
connect(): No such file or directory
ERROR: Can't connect to clamd.

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.003 sec (0 m 0 s)
then the chances are that clamd isn't running. Try launching it and checking that it is indeed running afterwards:
# /usr/local/sbin/clamd
# ps ax | grep clamd | grep -v grep
11752 ?        S      0:00 /usr/local/sbin/clamd
If clamd refuses to start then double-check your /usr/local/etc/clamav.conf file and the permissions on all the objects it references. Remember that clamd runs as user clamav, group clamav.

Testing it on controlled test data is one thing, testing it on a real, "out there in the wild" virus infection is another. Below is a link to an infected e-mail I received, which contains the Worm.SomeFool.Gen-1 worm.


Note to users of Microsoft Windows: The "Download virus" link below points to an e-mail which contains a virus. DO NOT CLICK ON IT! The file is provided to serve as a testbed for users of GNU/Linux who are not vulnerable to the malevolent code it contains.

Let me make this clear for those who have difficulties understanding strong recommendations: IF YOU USE MICROSOFT WINDOWS, DO NOT CLICK ON THE "DOWNLOAD VIRUS" LINK BELOW.

This text in large font and in red cannot be considered insufficient warning by any stretch of the imagination. The author of this page and the ISP hosting it decline any and all responsibility for any infection arising from the misuse of or the inability to use this online resource. In other words, if you still want to go and download the virus then on your own head be it. You have been given fair warning.


Grab a copy of the virus from here: Download virus.

Now run it through clamdscan:
# clamdscan somefool.dat
somefool.dat: Worm.SomeFool.Gen-1 FOUND

----------- SCAN SUMMARY -----------
Infected files: 1
Time: 0.048 sec (0 m 0 s)
Now that we've ascertained that the virus scanning is working, we need to integrate it into sendmail's processing queue so that infected mails get rejected during the SMTP session.

Step 4 - Tying ClamAV into sendmail

First we need to start the daemon, clamav-milter, which sets up the unix socket that sendmail will use, and which therefore acts as a go-between between sendmail and the clamd analyser:
# /usr/local/sbin/clamav-milter -l -o -q /var/milter/clmilter.sock
`man clamav-milter' will give full explanations on the options in the above command line. This particular combination scans all inbound and outbound mail (-o) as well as that sent from within the LAN (-l) and suppresses messages to postmaster (-q) each time a virus is detected - I'm getting about 10 a day (which is a lot less than some) so I don't want to receive notification each and every time.

Also, add the command to your /etc/rc.d/rc.local so that the daemon is started whenever the machine is:
# echo "/usr/local/sbin/clamav-milter -l -o -q /var/milter/clmilter.sock" >> /etc/rc.d/rc.local
The final step is to get sendmail to use the milter. To do so, add the following lines to your /etc/mail/ file:
INPUT_MAIL_FILTER(`clmilter',`S=local:/var/milter/clmilter.sock, F=, T=S:4m;R:4m')dnl
define(`confINPUT_MAIL_FILTERS', `clmilter')
Build a new and restart sendmail, you're ready to start blocking viruses.

  1. I'm using the generic (and somewhat incorrect) term "virus" here in its sense which englobes all forms of malevolent code: virus, trojan, worm... They each have a different modus operandi, but going into details here would be beyond the purpose of this howto.
  2. Junk e-mail, aka "spam", and viruses are now firmly linked instead of being two totally independent scourges as they were not that long ago. What happens as a general rule is that the target PC becomes infected with a virus which turns it into an open proxy for relaying spam, or into something else which ultimately helps spammers, such as a nameserver for their spam domains or a reverse proxy which directs web requests back to the spammers' webservers while preserving their anonymity. You might find these links informative:

Installing Mailscanner ClamAv and Spamassassin

SkyHi @ Friday, January 08, 2010

Installing Mailscanner ClamAv and Spamassassin


In this article we will see how to install a basic system to avoid your system to spread spam, virus and any type of crap to your users.

Since it is what we use, the machine which we are speaking about is a CentOS 4.0 with BlueQuartz control panel, to be honest, the one provided by

The installation procedure has been tested several times on different servers, and everything went OK.

The software we installed is MailScanner 4.56 , Spamassassin version 3.1.7 on Perl 5.8.5,  ClamAV 0.90RC1.1

First steps

Well, let's go on!

To be nice we will download the packages in a brand new directory, let's call it "installation_dir" so that you will always be able to track down the installation process.

Log in to your machine and become root with su command.

Then type the following:

mkdir installation_dir
cd installation_dir


Locate the MailScanner package, go to MailScanner site and grab the stable release.

wget http://%%%SOMEPATH%%%%%/MailScanner-4.56.8-1.rpm.tar.gz

Then untar it and install the software with the install script provided with the package:

tar -xzvf MailScanner-4.53.8-1.rpm.tar.gz
cd MailScanner-4.53.8-1

Everything should be ok, let's make some changes to the init scripts:

cd /etc/init.d/
mv sendmail sendmail.orig
ln -s MailScanner sendmail
./sendmail.orig stop
./sendmail start

If you run

tail -f /var/log/maillog

you should see some mailscanner-related lines of logs


This is the antivirus part of the job. Locate the last package of clamav from the official site, then:

yum install gmp-devel
cd /root/installation_dir/
wget http://##SOMEPATH###/clamav-0.90RC1.1.tar.gz
tar -xzvf clamav-0.90RC1.1.tar.gz
cd clamav-0.90RC1.1
/usr/sbin/groupadd clamav
/usr/sbin/useradd -g clamav -s /bin/false -c "Clam AntiVirus" clamav
./configure --disable-zlib-vcheck
make install

To test if everything is ok type

clamscan /root/installation_dir/

You  should see something like this:

/root/installation_dir/clamav-0.90RC1.1.tar.gz: ClamAV-Test-File FOUND
/root/installation_dir/MailScanner-4.56.8-1.rpm.tar.gz: OK

Now we configure the signature download process:

pico /usr/local/etc/freshclam.conf

Here locate the UpdateLogFile directive and uncomment it out. It must look like:

UpdateLogFile /var/log/freshclam.log

Now we create the freshclam.log file, setting the right permissions

touch /var/log/freshclam.log
chown clamav /var/log/freshclam.log
chmod 660 /var/log/freshclam.log

By now it is possible to run



To install SpamAssassin there are two ways:

1) install it by compiling the tar.gz you can obtain on the official site
2) install it using CPAN

Actually we prefer the second way.. is very easy!

Let's log to CPAN by typing:

perl -MCPAN -e shell

If it's the first type you run CPAN the system will ask you a lot of informations... Follow the instructions on screen.  When you get the CPAN prompt ( cpan> ) type:

install Digest::SHA1
install Net::DNS
install Mail::SPF::Query
install IP::Country
install Net::Ident
install IO::Socket::INET6
install IO::Socket::SSL
install Time::HiRes
install Archive::Tar
install IO::Zlib

And finally....

install Mail::SpamAssassin

Then restart sendmail:

/etc/init.d/sendmail restart

Vipul's Razor

Now that we have SpamAssassin installed, we can provide to it some additional software, suc as Vipul's Razor. Locate the two tars and download them into the installation dir:

cd /root/installation_dir/
wget http://##SOMEPATH###/razor-agents-sdk-2.07.tar.bz2
wget http://##SOMEPATH###/razor-agents-2.82.tar.bz2

Then uncompress and install:

tar -jxvf razor-agents-sdk-2.07.tar.bz2
tar -jxvf razor-agents-2.82.tar.bz2
cd razor-agents-sdk-2.07
perl Makefile.PL
make test
make install
cd ../razor-agents-2.82
perl Makefile.PL
make test
make install

Now that Razor is installed we must run three utilities to make it working:

razor-admin -home=/etc/mail/spamassassin/.razor -create
razor-admin -home=/etc/mail/spamassassin/.razor -discover
razor-admin -home=/etc/mail/spamassassin/.razor -register


To install Pyzor locate the tar with the latest version and download it:

cd /root/installation_dir/
wget http://##SOMEPATH###/pyzor-0.4.0.tar.bz2

then uncompress it and proceed to install:

tar -jxvf pyzor-0.4.0.tar.bz2
cd pyzor-0.4.0
python build
python install
python -c 'import gdbm' && echo 'gdbm found'

run the next command to complete pyzor installation

pyzor --homedir /etc/mail/spamassassin discover


This is the last step, locate DCC and download it:

cd /root/installation_dir/
wget http://##SOMEPATH###//dcc.tar.Z

uncompress it, compile and install it:

tar -xzvf dcc.tar.Z
cd dcc-1.3.42/
make install

We must now edit the following enabling DCC:

pico /etc/mail/spamassassin/v310.pre

Locate the line

#loadplugin Mail::SpamAssassin::Plugin::DCC

and uncomment it

loadplugin Mail::SpamAssassin::Plugin::DCC

Save the file and that's done

How to test the installation

To test SpamAssassin installation you can copy a complete message into a file on the server:

pico /etc/mail/spamassassin/testmsg

Here place a whole message. Test the installation by typing the following:

spamassassin -t -D -p /etc/MailScanner/spam.assassin.prefs.conf < /etc/mail/spamassassin/testmsg


How to set up a home email server (without being spammed to death)

SkyHi @ Friday, January 08, 2010

Why host your own mail?

There are many reasons to host your own email. Perhaps you don't like the limits placed on you by your current ISP. Maybe they aren't willing to host the domain you want, or give you the access you want. And if they do fit your needs, they want to charge a small fortune. Maybe you want complete privacy. Or perhaps you just want to access your email from anywhere using a web-based frontend. The list goes on and on...
There are several many ways to accomplish this task. Everyone has their preferred MTA program, but for the purposes of this article, we'll use sendmail. The same can also be done using postfix, or exim. Each approach has its own merits.
Let's get started.


I'm going to assume that when setting up your email server, you'll want to do so with your own personalized domain name. While I'm not going to explain how to register a domain name, if you're unsure, you can always click here for an explanation on how to do so. The domain that I'll refer to in this article will be, with the hostname of the machine being server1. I'm also going to assume, at least for now, that your IP address is static, and your inbound and outbound connections on port 25 are unrestricted.
The first thing you'll need will be your physical infrastructure: a computer running Red Hat® Enterprise Linux®, a high-speed Internet connection, and a registered domain name. After you have installed Red Hat Enterprise Linux on your system you will want to make sure the following packages are installed:
  • dovecot
  • sendmail
  • sendmail-cf
  • squirrelmail
  • perl
  • gcc
There are other packages we will need later on.

Configuring your mail exchanger

After you've set up your domain name with your favorite registrar, you will need to configure your Mail Exchanger (MX) record. You will do this through your domain registrar. After you find the page that will allow you to set up your MX record, I recommend you do the following:
  • Setup the MX record in the format So, for our example domain, we would choose "" as our MX record.
  • Configure your mail exchanger with a priority of 0 (zero).
  • Create a hostname/address (A RECORD) that associates with the IP address that your ISP has assigned you.
After you're done setting this up, you can test to see if it worked by dropping to a shell prompt and issuing the following command. If your setup is correct, you should see some synthesis of:
[root@server1 ~]$ nslookup -query="MX"

Non-authoritative answer:    mail exchanger = 0

Authoritative answers can be found from:    nameserver =    nameserver =    nameserver =    nameserver =    nameserver =       internet address =  internet address =  internet address =  internet address =  internet address =  internet address =
Please note that it may take some time for the changes you have made to propagate through DNS. If you check immediately after you make these changes and do not see your settings reflected, try a few minutes later.

Configuring s`endmail

The next step will be setting up and configuring sendmail. The process for doing this is somewhat arduous, so please read all of the information presented before beginning.
The file /etc/mail/ is the main configuration file for sendmail. This "cf file" contains the directives that sendmail will operate under. Much more friendly, however, is the file /etc/mail/ This "mc file" should be the base that you use for making all changes to sendmail's operating parameters. Additionally, the "cf file" is created from the parameters listed in this "mc file". Red Hat has done a wonderful job creating a template for your "mc file" and as such, the bulk of the changes that need to be made are just editing directives that are already present. Below are the directives that you must search for within your "mc file" and change accordingly:
DAEMON_OPTIONS(`Port=smtp,Addr=, Name=MTA')dnl  - change to -  DAEMON_OPTIONS(`Port=smtp, Name=MTA')
LOCAL_DOMAIN(`localhost.localdomain')dnl                 - change to -  LOCAL_DOMAIN(`')
dnl MASQUERADE_AS(`')dnl                     - change to -  MASQUERADE_AS(`')
dnl FEATURE(masquerade_envelope)dnl                      - change to -  FEATURE(`masquerade_envelope')
dnl define(`SMART_HOST',`smtp.your.provider')            - change to -  define(`SMART_HOST',`your.trusted.smtp.relay')
Add in the line:
Please note: You must replace "your.trusted.smtp.relay" with the name of your ISP's SMTP server. While omitting this change will not prevent your e-mail server from operating properly, there are several filters that are often employed that will block any "at home Cable, xDSL" port 25 connections for fear of spam.
After you have made these changes and are back in your server's /etc/mail directory, run the command "make -C /etc/mail". This compiles the "cf file" based on the instructions given in your "mc file". Each time you make a change to your "mc file", you must re-compile your "cf" file by issuing this command.

Edit your hosts file

Sendmail will make use of your /etc/hosts file, so you need to modify it so that mail is routed properly. Edit your /etc/hosts file and include a line that reads:
where is the IP address that is assigned to you by your ISP.

Obtaining and installing MailScanner, SpamAssassin, and ClamAV

Out of the box, sendmail works to deliver mail only. As such, you are quite vulnerable to spam and virus threats that will very quickly become a problem if you do not take action early. These three applications will process received mail and scan it for viruses and spam before it is delivered. You can download the latest versions of these applications from
Download the latest "for Red Hat, Fedora, and Mandrake Linux (and other RPM-based Linux distributions)" release of MailScanner, as well as the latest "ClamAV and SpamAssassin easy installation packages."
The installation package for all of the applications is quite good; it will resolve most of the dependencies that are required to gunzip, un-tar, and run both of these applications. As MailScanner checks for the presence of ClamAV when it installs, I recommend installing the SpamAssassin/ClamAV package first:
[root@server1 ~]# wget
[root@server1 ~]# tar zxvf install-Clam-0.88.5-SA-3.1.7.tar.gz 
[root@server1 ~]# cd install-Clam-0.88.5-SA-3.1.7
[root@server1 install-Clam-0.88.5-SA-3.1.7]# ./
There will be significantly more output produced as ClamAV and SpamAssassin are installed on your system. After they are installed, you should see a message similar to this:
Now you need to install:
1) Razor-agents-sdk and Razor2 from and
2) DCC from
Follow the links above to download the three applications that will assist SpamAssassin in processing your email. Below are the list of commands I used to download and install them. For clarity, I have removed all of the output that was produced for each command. You can expect to see significantly more than what I have listed. What is shown are the base commands to download, compile, and install the helper applications.
[root@server1 ~]# wget
[root@server1 ~]# wget
[root@server1 ~]# wget

[root@server1 ~]# bunzip2 razor-agents-sdk-2.07.tar.bz2 
[root@server1 ~]# tar xvf razor-agents-sdk-2.07.tar 
[root@server1 ~]# cd razor-agents-sdk-2.07
[root@server1 razor-agents-sdk-2.07]# perl Makefile.PL
[root@server1 razor-agents-sdk-2.07]# make
[root@server1 razor-agents-sdk-2.07]# make test
[root@server1 razor-agents-sdk-2.07]# make install
[root@server1 razor-agents-2.82]# cd ..

[root@server1 ~]# bunzip2 razor-agents-2.82.tar.bz2
[root@server1 ~]# tar xvf razor-agents-2.82.tar
[root@server1 ~]# cd razor-agents-2.82
[root@server1 razor-agents-2.82]# perl Makefile.PL
[root@server1 razor-agents-2.82]# make
[root@server1 razor-agents-2.82]# make test
[root@server1 razor-agents-2.82]# make install
[root@server1 razor-agents-2.82]# cd ..

[root@server1 ~]# tar zxvf dcc.tar.Z
[root@server1 ~]# cd dcc-1.3.42/
[root@server1 dcc-1.3.42]# ./configure
[root@server1 dcc-1.3.42]# make install
[root@server1 dcc-1.3.42]# cd ..
Now that these applications are installed, we can proceed to download, compile, and install MailScanner.
[root@server1 ~]# wget
[root@server1 ~]# tar zxvf MailScanner-4.56.8-1.rpm.tar.gz
[root@server1 ~]# cd MailScanner-4.56.8-1
[root@server1 MailScanner-4.56.8-1]# ./ 
As with ClamAV and SpamAssassin, there will be a significant amount of output produced. You should, however, end up with:
Preparing...                ########################################### [100%]
   1:mailscanner            ########################################### [100%]
Good, SpamAssassin site rules found in /etc/mail/spamassassin

To activate MailScanner run the following commands:

service sendmail stop
chkconfig sendmail off
chkconfig --level 2345 MailScanner on
service MailScanner start

For technical support, please read the MAQ at
and buy the book at

Please buy the MailScanner book from!
It is a very useful administration guide and introduction
to MailScanner. All the proceeds go directly to making
MailScanner a better supported package than it is today.
Now, before we issue the commands to start MailScanner, please be sure within the /etc/MailScanner/MailScanner.conf file, the following lines exist:
  • Virus Scanners = clamav
  • Use SpamAssassin = yes
These directives tell MailScanner to use ClamAV to scan for viruses, and SpamAssassin to process email for spam. From here we can issue the commands below to start MailScanner and begin processing email. I highly recommend you view the /var/log/maillog file while starting MailScanner and scan the output for undesirable actions, as well as to verify that Mail is being processed properly.
[root@server1 MailScanner-4.56.8-1]# service sendmail stop
[root@server1 MailScanner-4.56.8-1]# chkconfig sendmail off
[root@server1 MailScanner-4.56.8-1]# chkconfig --level 2345 MailScanner on
[root@server1 MailScanner-4.56.8-1]# service MailScanner start

Setting up web access to your email

I am going to assume that you have your apache server running. If you don't you should review the steps to install and configure apache.
After you have verified that your web server is running, execute the following commands at your shell prompt:
[root@server1 ~]# chkconfig dovecot on
[root@server1 ~]# service dovecot start
These commands will start your IMAP server, which will be used by the Squirrel Mail package to access the mail stored on your server. With good luck, you should now have a fully functional, protected email server running. Keep in mind you may need to make changes to your /etc/mail/local-host-names file and /etc/mail/relay-domains file. Each case will be different, so I recommend you review your /var/log/maillog file and use the links provided to perform any final setting changes. Enjoy!


Pipes in ~/.forward File

SkyHi @ Friday, January 08, 2010
Forwarding of UNIX e-mail is accomplished through a ~/.forward file. This file, commonly referred to as "dot forward", contains a location to send your incoming mail. If the file does not exist, mail is saved in your inbox. Beginning with V8 sendmail, a user must have a valid shell to run programs from the ~/.forward file. Because sendmail sorts all addresses and deletes duplicates before delivering to any of them, it is important that programs in ~/.forward files be unique.  Commends can be used to ensure this (  .forward  file uses shell style comments which start with a # character). 
Sendmail temporarily switch to user ID before trying to read the ~/.forward file so that reads will work across NFS. If sendmail cannot read the ~/.forward file (for any reason), it silently ignores that file. First sendmail checks to see whether it is a "safe" file - one that is owned by the user or root and that has the read permission bit set for the owner. If the ~/.forward file is not safe, sendmail silently ignores it. After that, sendmail opens the file for reading and gathers a list of recipients from it. Internally, the ~/.forward file is exactly the same as a :include: file. Each line of text in it may contain one or more recipient addresses. Recipient addresses may be email addresses, the names of files onto which the message should be appended, the names of programs through which to pipe the message, or :include: files.
Four types of destination can be used.
  1. Address
    Remote email address to relay the mail to, such as This is th traditional use of the ~/.forward file, as its name implies. Unfortunately, as users move from machine to machine, they can leave behind a series of ~/.forward files, each of which points to the next machine in a chain. As machine names change and as old machines are retired, the links in this chain can be broken. One common consequence is a bounced mail message ("host unknown") with a dozen or so Received: header lines.
  2. Force local delivery
    To force delivery to the local mailbox, precede the mailbox name (typically the username) with a backslash: \user. Recall that prefixing a local address with a backslash tells sendmail to skip additional alias transformations. For \user this causes sendmail to deliver the message (via the local delivery agent) directly to the user's spool mail box.
  3. Appending to file
    To specify a literal file where mail should be deposited, use a fully qualified path: /home/user/archive/mailstore.
    Such filenames must begin with a slash character that cannot be quoted. For example, if a user wishes to keep a backup copy of incoming mail:
    The first line (\user) tells sendmail to deliver directly to the user's mail spool file using the local delivery agent. The second line tells sendmail to append a copy of the mail message to the file specified (in.backup).
  4. Pipe. The syntax is as follows:
    "|prg args"
    |"prg args"
  5. Note:  prg should contain the full path to executable like in "|$HOME/bin/your.program" (the environment variable PATH is not available). If command-line arguments are needed for the program, they must follow prg, and the entire expression must be quoted. The leading full quotation mark may either precede or follow the |. If the address is quoted with full quotation marks, the leading quotation mark is ignored in determining the leading | character. For example
    "|IFS=' '&&exec /usr/local/bin/procmail -f-||exit 75 #YOUR_USERNAME"
    "|IFS=' ';if /usr/bin/sparc;then exec /home/berg/bin.sun4/procmail;else exec /home/berg/bin.sun3/procmail;fi ||exit 75 #YOUR_USERNAME"
    or alternatively:
    "|IFS=' ' && export IFS && exec /home/berg/bin.`/usr/bin/arch`/procmail || exit 75 #YOUR_USERNAME"
The above can be combined as comma separated values on a single line, or on multiple lines to split mail delivery to multiple destinations.
There are several type of information you can put in the .forward file. Vacation Program also allows you to send a message back to the person sending you mail with information about your availability (e.g. if you're on vacation) or that your e-mail address has changed.
Security restrictions have been placed users using  .forward    files  to pipe mail to a program or redirect mail to a file. The default shell (as listed in /etc/passwd) of these  users must  be  listed  in  /etc/shells. This restriction does not affect mail that is being redirected to another alias. Additional restrictions have been put in place  on  .forward and :include: files. These files and the directory structure that they are placed in cannot be group-  or  world-writable. 

Forwarding to an address

To forward mail to to another address, you need to place the email address of the account you want to forward to in the .forward file.
     echo someone@somewhere.else > .forward (replace someone... with an email address)
To stop forwarding, remove the .forward file.
The .forward file may contain multiple locations to forward your e-mail. For example, you may wish to forward mail from one account to several, or keep a copy of the mail you forward in your local account. To do this, simply add a line in your .forward for every location you wish to forward e-mail to. So, if Bob wanted to forward his mail to Mary and Joe, but also keep a copy of it, he could have a .forward that looks like this:
The backslash (" \ ") before Bob's address leaves a copy of the message in Bob's account as well as forwards a copy of the message to Mary and Joe.
Warning: Please take care when forwarding mail. Place the .forward file in the account you want to forward mail from containing the destination e-mail address. The destination address should NOT be the same as the source address. Also, the destination address should NOT be an address which will forward mail back to the source address. These kinds of loops cause mail to be bounced between machines and will eventually cause your mail not to be delivered.

Appending to Files

The ~/.forward file can contain the names of files onto which mail is to be appended. Such filenames must begin with a slash character that cannot be quoted. For example, if a user wishes to keep a backup copy of incoming mail:
The first line (\user) tells sendmail to deliver directly to the user's mail spool file using the local delivery agent. The second line tells sendmail to append a copy of the mail message to the file specified (in.backup).
If the SafeFileEnvironment option is set, the user should be advised to specify the path of that safe directory:
/arch/bob.backup           here /arch was specified by the SafeFileEnvironment option
When the SafeFileEnvironment option is used, the cooperation of the system administration may be needed if users are to have the capability of saving mail to files via the ~/.forward file.

Pipes in ~/.forward file

Any delivery agent for which the F=| flag is set can also pipe messages through programs. To disable this ability, simply remove the F=| flag from all delivery agent declarations in your configuration file.
The syntax is as follows:
"|prg args"
|"prg args"
Here, prg is the full path of the program to be run (the environment variable PATH is not available). If command-line arguments are needed for the program, they must follow prg, and the entire expression must be quoted. The leading full quotation mark may either precede or follow the |. If the address is quoted with full quotation marks, the leading quotation mark is ignored in determining the leading | character.
To execute the program, sendmail executes the command in the P= equate of the prog delivery agent. That command is one of the following:
/bin/sh -c
/bin/smrsh -c
These tell sendmail to run /bin/sh (the Bourne shell) or /bin/smrsh (the sendmail restricted shell) to execute the program specified by prg. The -c tells that shell to take any arguments that follow and execute them as though they were commands typed interactively to the shell. These arguments are constructed by removing the leading | from the program address and appending what remains, quotation marks and all, to the P= command. For example, if an alias looked like this:
jim: "|/etc/local/relo jim@otherhost"
the Bourne shell would be executed with the following command line:
/bin/sh -c "/etc/local/relo jim@otherhost"
he result of all this is that sendmail runs the Bourne shell and then the Bourne shell runs the /etc/local/relo program.
Mail is delivered under this scheme by attaching the output of sendmail to the standard input of the shell and attaching the standard output and standard error output of the shell to the input of sendmail. The sendmail program simply prints the mail message to the shell and reads any errors that the shell prints in return.
Although this process appears to be fairly straightforward, there are many things that can go wrong. Failure usually results in the mail message being bounced.
 A user must have a valid shell listed in /etc/shells to run programs from the ~/.forward file. Because sendmail sorts all addresses and deletes duplicates before delivering to any of them, it is important that programs in ~/.forward files be unique. Consider a program that doesn't take an argument and suppose that two users both specified that program in their ~/.forward files:
user 1   \user1, "|/bin/notify"
user 2   \user2, "|/bin/notify"
The address /bin/notify appeared twice in the list of addresses. The sendmail program might eliminate what seems to be a duplicate.  V8 sendmail uses the owner of the ~/.forward file in addition to the program name when comparing.
If a program requires no arguments (as opposed to ignoring them), the ~/.forward program specifications can be made unique by including a shell comment:
user 1   \user1, "|/bin/notify #user1"
user 2   \user2, "|/bin/notify #user2"
Rather than expecting users to write home-grown programs for use in ~/.forward files, offer them any or all of the publicly available alternatives. The most common are listed below.
  • The deliver(1) program, by Chip Salzenberg, is specifically designed to handle all types of final delivery for users. It is intended for use in the ~/.forward file but also functions as a local delivery agent. The deliver program supports a large number of command-line options and can reliably handle delivery to files and through programs. It is typically used in the~/.forward file like this:
"|/usr/local/bin/deliver user"
The deliver program is available via anonymous FTP from many archive sites.
  • The procmail(1) program, by Stephen R. van den Berg, is purported to be the most reliable of the delivery programs. It can sort incoming mail into separate folders and files, run programs, preprocess mail (filtering out unwanted mail), and selectively forward mail elsewhere. It can function as a substitute for the local delivery agent or handle mail delivery for the individual user. The procmail program is typically used in the ~/.forward file like this:
"|exec /usr/local/bin/procmail #user"
  • The slocal program, distributed with the mh distribution, is useful for sorting incoming mail into separate files and folders. It can be used with both UNIX-style mail files and with mh-style mail directory folders. It is typically used in the ~/.forward file like this:
"| /usr/local/lib/mh/slocal -user user"
The disposition of mail is controlled using a companion file called ~/.maildelivery.
Normally, a program in the user's ~/.forward file is executed with the Bourne shell. The precise means that is used is defined by the prog delivery agent.
Mprog, P=/bin/sh,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u
                                              The Bourne shell
One drawback to using the Bourne shell to run programs is that it exits with a value of 1 when the program cannot be executed. When sendmail sees the exit value 1, it bounces the mail message.
There will be times when bouncing a mail message because the program could not execute is not desirable. For example, consider the following ~/.forward file:
"| /usr/local/lib/slocal -user george"
If the directory /usr/local/lib is unavailable (perhaps because a file server is down or because an automounter failed), the mail message should be queued, rather than bounced. To arrange for requeueing of the message on failure, users should be encouraged to construct their ~/.forward files like this:
"| /usr/local/lib/slocal -user george || exit 75"
Here, the || tells the Bourne shell to perform what follows (the exit 75) if the preceding program could not be executed or if the program exited because of an error. The exit value 75 is special, in that it tells sendmail to queue the message for later delivery, rather than to bounce it.
The ~/.forward file can contain the names of programs to run. A program name is indicated by a leading pipe (|) character, which may or may not be quoted. For example, a user may be away on a trip and want mail to be handled by the vacation(1) program:
\user, "|/usr/ucb/vacation user"
Recall that prefixing a local address with a backslash tells sendmail to skip additional alias transformations. For \user this causes sendmail to deliver the message (via the local delivery agent) directly to the user's spool mail box.
The quotes around the vacation program are necessary to prevent the program and its single argument (user) from being viewed as two separate addresses. The vacation program is run with the command-line argument user, and the mail message is given to it via its standard input.

Unscrambling Forwards

The traditional use of the ~/.forward file, as its name implies, is to forward mail to another site. Unfortunately, as users move from machine to machine, they can leave behind a series of ~/.forward files, each of which points to the next machine in a chain. As machine names change and as old machines are retired, the links in this chain can be broken. One common consequence is a bounced mail message ("host unknown") with a dozen or so Received: header lines.
As the mail administrator, you should beware of the ~/.forward files of users at your site. If any contain offsite addresses, you should periodically use the SMTP expn command to examine them. For example, consider a local user whose ~/.forward contains the following line:
This causes all local mail for the user to be forwarded to the host remote.domain for delivery there. The validity of that address can be checked with telnet(1) at port 25 [9] and the SMTP expn command:
% telnet remote.domain 25
Trying ...
Connected to remote.domain.
Escape character is '^]'.
220 remote.domain Sendmail 8.6.13/8.6.12 ready at Tue, 7 May 1996 13:39:21 -0700
220 ESMTP spoken here
expn user
221 remote.domain closing connection
Connection closed by foreign host.
This shows that the user is known at but also shows that mail will be forwarded (yet again) from there to By repeating this process, you will eventually find the site at which the user's mail will be delivered. Depending on your site's policies, you can either correct the user's ~/.forward file or have the user correct it. It should contain the address of the host where that user's mail will ultimately be delivered.

Forwarding Loops

Because ~/.forward files are under user control, the administrator occasionally needs to break loops caused by improper use of those files. To illustrate, consider a user who wishes to have mail delivered on two different machines (call them machines A and B). On machine A the user creates a ~/.forward file like this:
\user, user@B
Then, on machine B the user creates this ~/.forward file:
\user, user@A
The intention is that the backslashed name (\user) will cause local delivery and the second address in each will forward a copy of the message to the other machine. Unfortunately, this causes mail to go back and forth between the two machines (delivering and forwarding at each) until the mail is finally bounced with the error message "too many hops."
On the machine that the administrator controls, a fix to this looping is to temporarily edit the aliases database and insert an alias for the offending user like this:
user:  \user
This causes mail for user to be delivered locally and that user's ~/.forward file to be ignored. After the user has corrected the offending ~/.forward files, this alias can be removed.


Wednesday, January 6, 2010

How to use cisco ios Access list

SkyHi @ Wednesday, January 06, 2010

How to Use Cisco IOS Access Lists – Part 1

by David Davis, vExpert, VCP, CCIE 9369 - January 7, 2009

A Cisco IOS Access-List (ACL) is used to specify network traffic. Once you specify traffic with an ACL, you can then do a variety of things with it. For example, you could allow it, deny it, limit it, or use it to restrict routing updates. In this article, we will learn the basics of Cisco IOS Access-Lists.

What do ACL’s do?

A Cisco IOS Access-list is commonly abbreviated ACL. ACL is usually pronounced like A.C.L.; however, some people do pronounce it like “ankle”, but without the “n”. In other words, it can be pronounced “akkl”. My preference is to pronounce it A.C.L., as you would pronounce FBI or CIA, not as you would pronounce NASA or FEDEX. As I stated before, an ACL is used to specify or define traffic. By just creating an ACL, you have made NO effect on anything. It is simply an unused definition of network traffic. Once it is defined, you can then use it for a wide-ranging list of purposes.

What are the types of ACL’s?

Access-lists can be one of two types: standard or extended. Numbered IP access-lists fall within the following numerical range: - 1 to 99 Standard IP - 100 to 199 Extended IP - 1300 to 1999 Standard IP - 2000 to 2699 Extended IP A standard access-list can only define the SOURCE IP of the traffic. An extended IP access-list can define the source and destination IP address of traffic, along with source and destination port numbers. Also, while a standard access-list only defines IP traffic, an extended access-list can define TCP, UDP, ICMP, IP, AHP, EIGRP, IGRP, ESP, IGMP, OSPF, and PIM traffic. Here is an example of the most basic standard IP access-list that can be defined:

This access-list was numbered “1” and it is permitting traffic from the source IP address of Since we brought up the numbering of access-lists, let me point out that these numbers are not like line numbers in a program. The access-list statements are not processed in the order of the numbers. The numbers on the access-lists are there to group those access-list statements together. In other words, all lines of an access-list that have the number 1 are in the same access-list and are used together.

Top down Processing

The lines of an access-list are processed from the top down, in the order that they are entered. When the network packet being processed through that access-list matches a statement in the access-list, all processing for that packet is stopped. Let’s look at an example. Say that I have this access-list:

Say that this access-list is being used to filter traffic in-bound to a router. A packet comes in with the source IP address of Look at the access-list. Will that traffic be permitted or denied? Because the access-list is processed from the top down, that traffic will be denied, even though it would have been permitted later down the list. This is because, when the traffic is denied, processing of the access-list is stopped. The important thing for you to know is that the order of the statements is crucial. If you are using access-lists to filter traffic, you want to stop the traffic closest to the source of that traffic to conserve WAN bandwidth.

The three P’s of access-lists and filtering traffic

When it comes to filtering traffic, the rule of access-lists is the “three Per’s”. The rule goes like this: “You can have one access-list per PROTOCOL, per DIRECTION, and per INTERFACE”. So, you can have an access-list for each protocol (IP, IPX, Appletalk, bridging, etc). You can have an access-list for each direction- either IN, or OUT. You can have an access-list on each interface- FastEthernet0/0, Serial0/0, Serial1/0, etc. In other words, you can’t have two IN-BOUND IP access-lists on the same interface. Those access-lists would need to be combined to use both of them.

Wildcard Mask

A very important thing to remember is that, when specifying a range of hosts on a network, or an entire network, ACL’s use something called a wildcard mask. The wildcard mask is an inverted subnet mask. In other words, take the subnet mask for the network (or range of hosts), turn it into binary, reverse the 0’s and 1’s, and turn it back into decimal. I won’t go into how to do that with a sub-netted range of hosts but, if your octets are all 255’s or all 0’s, you can just reverse these. Here are some examples: Subnet mask = wildcard mask Subnet mask = wildcard mask Subnet mask = wildcard mask

Implied Deny

Another very important rule about access-lists is that there is always an “implied DENY” at the end of each ACL. What this means is that every access-list has the following statement at the end of it: access-list X deny ANY (if this is a standard access-list) or access-list X ip deny ANY ANY (if this is an extended access-list) So, if your traffic isn’t explicitly permitted by a statement in the ACL, then your traffic is DENIED. If you manually type the “deny any” statement in, it will appear but if you don’t type it in, it is still there. Here is an example: What traffic is allowed through this ACL?

The answer is that NO traffic is allowed through this access-list. That is because the only statement is a deny statement and, after that, there is the implied deny which denies everything.


Understanding how ACL’s work can be confusing at first. However, I hope this article has cleared up that confusion. The proper usage of Cisco IOS access-lists are essential knowledge for any network administrator. In Part 2 of this article, you will have a real-world demonstration of how to create and apply an access-list.

How to Use Cisco IOS Access Lists – Part 2

In Part 1 of this article, we explained how access-lists work. In this article, we’ll take a sample network and explain how to create and apply an access-list. Remember that an Access-List (ACL) is used to specify network traffic. Once you specify traffic with an ACL, you can then do a variety of things with it. For example, you could allow it, deny it, limit it, or use it to restrict routing updates. We will also explain how to filter traffic with an ACL because this is the most common use.

Example of Filtering with an Access-list

Now, let me provide an example of how to filter inbound traffic with access-list. Here is our sample network: Let’s say that we are on the Chicago router. We want to only allow inbound www traffic from the IP addresses on the San Diego LAN. Those IP addresses are the network, which has a subnet mask of We want to log any traffic that is denied to our logging buffer. Let’s do this in two steps. First, create your access-list: Note that the second line of the access-list denied all traffic, and used the log-input keyword at the end to log all denied traffic. Also, note how the wildcard mask was used instead of the subnet mask. It is important to know the direction of the traffic (the ACL uses source, then destination), and how the traffic works (WWW or HTTP) traffic contacts the web server with a destination port on the server of port 80, or WWW. Second, apply your access-list: Note the direction of “IN” when we applied the access-list. This says that the ACL applies to IN-BOUND traffic, coming into the Serial interface from the T1 WAN circuit (in this case, from San Diego, CA). Finally, let’s see what the access-list looks like with our show command, and also where the ACL is applied to the Interface. Here is output from the show ip access-lists and show ip interface serial0 command. In the first command, you can see the access-list that we created. In the second command, you can see where the access-list was applied and in what direction. Of course, you can see both of these things with the show running-config command.

Example of Restricting Telnet access with an Access-list

Quickly, let me provide another example of using an ACL. Say that you are still on the Chicago router. You want to only allow your PC’s IP address (on the Chicago LAN) access to TELNET, to the router. Yes, you could do this with an ACL on the Interface but, instead, let’s do it by using the access-class statement on the vty lines. To do this, you only need a standard access-list. Say that your PC’s IP address is First, create an access-list to specify traffic with that source, like this:

Next, apply this ACL to all 5 VTY lines using the vty range configuration, using the access-class statement, like this: By creating this ACL and applying it to all 5 VTY lines, we are saying that only IP address can TELNET to this Cisco router. This is just another example of the many uses of an ACL.


The proper usage of Cisco IOS access-lists are essential knowledge for any network administrator. In Part 2 of these articles on Access-Lists, you saw a real-world network, and how to create and apply access-lists on that network. You saw how access-lists could be used to filter traffic that is flowing through the network, and also how an ACL can be used to specify what IP address can telnet to the router. If you haven’t read Part 1 of this series, please take a look. Part 1 covered the essentials of Access-List that everyone should know. Cisco IOS Access-lists have so many more options and uses than what we were able to explore in this short article. To learn more, go to your router and type access-list ?, or consult the Cisco IOS documentation on Access-lists.


What you need to know about Cisco IOS access-list filtering

SkyHi @ Wednesday, January 06, 2010

Let’s face it, if you don’t use Cisco IOS access lists (ACL) every day, they can be very painful to use. Why are ACLs so painful? Besides just being difficult to use, the penalty for mistake is huge. In one swift swoop, you could incorrectly permit malicious attackers onto your network or incorrectly deny all valid users from your network. Either way, the consequences could be devastating to your company and to your career. So how do you prevent this from happening? If you follow these guidelines, you will be “feeling good again” about your Cisco ACLs.

Know what an ACL can and cannot do

In the simplest of terms, a Cisco IOS ACL is used to define traffic. Once that traffic is defined, some action can then be taken on that traffic.

Commonly, an ACL is associated with the filtering of IP packets (Network Layer 3 of the OSI Model) as they pass through a router. In other words, it is used to permit or deny traffic through a router. However, if you just define the ACL only and don’t apply it to an interface using the access-group command, nothing happens.

While ACLs can be used for many functions like QoS, route filtering, and allowing access to the router, in this article, we will focus on using ACLs for filtering traffic in and out of the router.

Know the syntax of ACLs

To configure an ACL you need to include some basic information about which packets to permit or deny.

The general syntax for a standard access list is:

access-list {list number} permit | deny | [source address} [source mask]

Note that the standard ACL can only permit or deny traffic based on the source of the traffic.

The general syntax of a TCP extended access list is:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name] [fragments]

You should also know that extended ACL can filter IP traffic, TCP, UDP, ICMP, and other types of traffic. The syntax above is to filter TCP traffic.

Know that ACLs use wildcard masks

Cisco IOS ACLs use wildcard masks. These wildcard masks are required anytime you enter an IP address in your ACL. The only way NOT to enter an IP address (thus, using a wildcard mask) is to enter a keyword like “any” or use the keyword “host” before the absolute IP address of a host on the network.

Wildcard masks are the binary reverse of a subnet mask. Thus, to calculate a wildcard mask, you take the subnet mask of a network address or IP address, convert it to binary, turn all the 1s into 0s and the 0s into 1s, and convert it back to decimal. Sounds complicated, but it really isn’t. If the subnet mask is masked at the 8-bit subnet boundaries, then a 0 will turn into a 255 and a 255 will turn into a 0. Here are a few examples:

  • SN = wildcard
  • SN = wildcard
  • SN = wildcard
  • SN =

Do NOT use a subnet mask in a wildcard mask on a Cisco IOS router or switch, or you will end up with unintended results. (On the other hand, if you are configuring an ACL on a Cisco PIX, use regular subnet masks, not wildcard masks).

Know how to create an ACL and apply it to an interface

For example, here’s how a sample configuration might look for access list 1:

Router(config)# access-list 1 permit
Router(config-if)# interface e0/0
Router(config-if)# ip access-group 1 out

The ip access-group command is used to apply an ACL to an interface and specify the direction that it applies.

The commands above permit any traffic coming from IP network going OUT the router’s Ethernet 0/0 interface.

Know the implicit deny

Let me ask you this: What is allowed through the ACL above? Answer: Only the traffic from the /24 network. Why is that? That is because at the end of every ACL, whether you see it or not, ALL TRAFFIC IS IMPLICITLY DENIED.

So, what traffic is allowed through the ACL below?

Router(config)# access-list 1 deny

That’s right - NO TRAFFIC is allowed because certain traffic is explicitly denied and ALL OTHER TRAFFIC IS DENIED by the implicit deny.

How do you see the traffic being denied? You can enter your own explicit deny with the log keyword, like this:

Router(config)# access-list 1 permit
Router(config)# access-list 1 deny any log

Know that ACLs use top-down processing

Cisco IOS ACLs use top-down processing. This means that when a condition in the ACL is met, all processing is stopped. Thus, if there is a permit for network in the fifth line of the ACL but it is denied in the third line of the ACL, then that traffic is denied.

Know the three Ps of ACLs

Remember, you can only apply ONE ACL:

  • Per Interface
  • Per Protocol
  • Per Direction

As most of us are applying IP ACLs, the protocol doesn’t matter that much, but the important thing to know is that you can apply only ONE ACL on each interface in each direction. In other words, you can apply only one INBOUND and one OUTBOUND ACL per interface.

Know how to verify which ACLs are applied and which are configured

Showing what ACLs are created and what ACLs are applied is easy if you know just a few commands. These commands are:

  • show access-lists
  • show ip interface
  • show running-config

Know that there are many methods and types of ACLs

The Cisco IOS supports IP Standard and Extended ACLs in both named and numbered versions. Additionally, there are reflexive, dynamic, and lock-and-key access lists, among many others.

Know how ACLs can be used in the real world

While you may understand the concept of ACLs and how to configure them, it is important to know how to use them in the real world.

Here are a few business applications for ACLs:

1. Basic packet filtering for security: Filter traffic from a host, a network, a protocol, or port.

2. Packet filtering for bandwidth control: Say that a streaming audio or video application was using network bandwidth, and it was on a certain port number. With an ACL, you could discard those video and audio packets to prevent overutilization of bandwidth.

3. Other functions with ACLs: Route filtering, QoS, controlling access to the router, etc.

Know where to find more resources to learn ACLs

There is a lot to know about ACLs, and we can’t cover it all in this short format. To learn more about ACLs, here are some links to other articles and videos I have created on this topic.


ACLs are the least understood feature that new Cisco administrators and CCNA candidates struggle with. I hope you find this information about Cisco IOS access lists helpful, and you keep it handy to “cure those ACL pains” whenever they come up.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David DavisDavid Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Train Signal, Inc. is the global leader in video training for IT Professionals and end users. Read his full bio and profile.


Adobe Photoshop CS Text Tool Error

SkyHi @ Wednesday, January 06, 2010

If you receive the following message when trying to enter some text on a image

 “Could not complete your request because something prevented the text engine from being initialized.”

then try Resetting the Tool. You can find that option next to the tool. If it didnt work, try to allocate more RAM as photoshop is highly resource consuming.

After all the tries, if the text tool still gives error, try to delete all the extra fonts you installed in the system and keep only the fonts required by the system. You can follow the below guide for that.


Recently when i opened Adobe Photoshop CS3 Extended, i came accross an error that was preventing me from selecting any controls.

The Hand Tool was selected by default and i wasn’t able to select anything else.

The solution was pretty simple, but took awhile to figure out.

  • Close all adobe applications running then goto C Drive
  • Open Documents and Setting Folder
  • Then $USER Directory (This is your logon username)
  • Open Application Data Folder
  • Open Adobe Folder
  • Finally you should see the folder Adobe Photoshop CS3 – Don’t delete it, instead rename it to something else (i.e Old_Adobe Photoshop Cs3).

Hopefully your problem should be solved :)

But hold on a second, i’ve noticed that some people have reported that using this method they get another error that says an error something like Something prevented the Text Engine. If thats the case continue reading below.

Adobe Photoshop CS3 Extended – Something Prevented The Text Engine

When you try to select the Text Tool from photohop and get this error – you should follow the below steps and your problem should be solved.

  • Close all adobe applications running – Then Open C Drive
  • Goto Documents and Settings
  • Then $USER directory (Just like above)
  • Open Local Settings Folder
  • Open Application Data Folder
  • Open Adobe Folder
  • Open TypeSupport Folder
  • Delete everything inside the TypeSupport Folder

Note:- Some directories are hidden by default so make sure to set the explorer to display all hidden files.

I hope this fixes your problem with Adobe Photoshop CS3 Extended – Please leave your comments if or not this has helped you solve your problem.


Ubuntu vmware workstation 7 network setup

SkyHi @ Wednesday, January 06, 2010
1. Virtual Network Editor
2. vmnet8 NAT (subnet IP:
3. VM hosts(default gateway and dns

Ubuntu host machine:
vmnet1 Link encap:Ethernet HWaddr 00:50:56:c0:00:01
inet addr: Bcast: Mask:
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vmnet8 Link encap:Ethernet HWaddr 00:50:56:c0:00:08
inet addr: Bcast: Mask:
inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
RX packets:55 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Uninstall vmware:
$sudo /usr/bin/vmware-uninstall

Install vmware:
$ chmod u+x VMware-Workstation-Full-7.0.0-203739.x86_64.bundle
$ sudo ./VMware-Workstation-Full-7.0.0-203739.x86_64.bundle

Tuesday, January 5, 2010

Ipod touch backup songs to pc

SkyHi @ Tuesday, January 05, 2010
SharePod is easy to use and works! Heres some of the main features:
  • Add & remove music and videos from your iPod
  • Add, remove and edit playlists
  • Add & remove album art
  • View and backup photos
  • Copy music, videos and playlists from your iPod to PC
  • Import music/videos into your iTunes library, including playlists and ratings
  • Tag editing
  • Drag n' drop to and from Explorer
  • Simple, clean interface
  • Quick to load and use with no unnessary complicated features
  • Support for iPhone and iTouch (Thanks to Nikias Bassen, Paul Sladen, Jonathan Beck, and Christophe Fergeau for making this possible)
And whats more, SharePod is completely free! SharePod was designed from the start to be lightweight, quick and responsive, it has all (well hopefully most...!) of the features you need and none of the features you dont.


Monday, January 4, 2010

An Illustrated Guide to the Kaminsky DNS Vulnerability

SkyHi @ Monday, January 04, 2010
The big security news of Summer 2008 has been Dan Kaminsky's discovery of a serious vulnerability in DNS. This vulnerability could allow an attacker to redirect network clients to alternate servers of his own choosing, presumably for ill ends.
This all led to a mad dash to patch DNS servers worldwide, and though there have been many writeups of just how the vulnerability manifests itself, we felt the need for one in far more detail. Hence, one of our Illustrated Guides.
This paper covers how DNS works: first at a high level, then by picking apart an individual packet exchange field by field. Next, we'll use this knowledge to see how weaknesses in common implementations can lead to cache poisoning.
By fully understanding the issues at play, the reader may be better equipped to mitigate the risks in his or her own environment.
We hope everybody who runs a DNS server patches soon.


Before we see how DNS operates, we need to define a few terms to know who the players are, software-wise. This will be review for many, and in some cases we leave out side details that an expert would find fault with. Omitted details won't matter for an understanding of this issue.
Think of this as a "domain": a collection of hostnames/IP pairs all managed together.
Our servers operate, and all the DNS records that go with it —,,, etc. — are all part of the zone.
The subtle distinction comes with subdomains: sometimes they are part of the main zone, sometimes they are a separate zone, but none of that matters for this paper.
This is server software that answers DNS questions, such as "What is the IP address for". Sometimes a nameserver knows the answer directly (if it's "authoritative" for the zone), other times it has to go out to the internet and ask around to find the answer (if it's a recursive nameserver).
There is wide variety of software that performs this service: BIND, PowerDNS, djbdns, and many others. They all answer the same questions more or less the same way, though the minor differences matter some for this paper.
Authoritative Nameserver
For every zone, somebody has to maintain a file of the hostnames and IP address associations (" is", and so on). This is generally an administrative function performed by a human, and in most cases one machine has this file. It's the zone master.
Zones with multiple public nameservers make administrative arrangements to transfer the zone data automatically to additional slave nameservers, all of which are authoritative as far as the outside world is concerned. The distinction between master and slave is unimportant for this paper.
This is the client part of the DNS client/server system: it asks the questions about hostnames. The resolver is usually a small library compiled into each program that requires DNS services, and it knows just enough to send questions to a nearby nameserver.
On Linux/UNIX systems, the location of the servers-to-ask is found in the file /etc/resolv.conf, and on Windows it's part of the Network Connections setup in the control panel. This usually consists of a list of IP addresses, each of which expects to find a nameserver on the other end.
Resolvers are usually very small and dumb, relying on the servers to do the heavy lifting.
Recursive Nameserver
This is a nameserver that's willing to go out on the internet and find the results for zones it's not authoritative for, as a service to its clients. Not all nameservers are configured to provide recursive service, or are limited to just trusted clients (say, an ISP may provide nameservice only to its customers).
Resource Record
Though most think of DNS as providing hostname-to-IP mapping, there are actually other kinds of questions we can ask of a nameserver, and this highlights the notion that DNS is really a database of "resource records".
The most common type is an IP Address (an "A" record), but other records exist too: NS (nameserver), MX (mail exchanger), SOA (Start of Authority), and so on.
When a nameserver doesn't have the contents of a zone, but knows how to find the owner, it's said to delegate service of that zone to another nameserver. Informally, it's a pass-the-buck mechanism: "I know the zone you're asking about, go ask (hostname) for the details".

Following a simple DNS query

DNS query logo - ping With a few key terms defined, we'll review how a simple recursive query works in the absence of any bugs or shenanigans; this forms the background of where the exploits can later be applied.
Though the DNS packet itself has many fields (each of which is important), we're omitting that detail for now in order to understand the high level flow of a full query, from top to bottom. Visualizing how delegation bounces requests from one server to another is vital to understanding the vulnerability will be exploited later.
We can't really tell by looking at the query itself what prompted the query in the first place. In the logo of this section, we see that the user attempted to ping our webserver, and the ping program asked the nameserver to perform this name-to-IP lookup.
But it could have just as easily been a user entering in a browser address bar. But it's not important to know why the name's being looked up, only to know how it looks up.
1 The client (noted as "User's PC") makes a request for, and it's routed to the nameserver provided by the user's ISP. It requests the A record, which represents an IP address.
The ISP's nameserver knows that it's not authoritative for, so it can't look it up in its local zone database. It also doesn't find the name it its cache of recently-seen data, so it knows it has to go out to the internet to find it for us.
DNS resolution, step 1
2 All recursive nameservers are preconfigured with a list of 13 root servers, a selection of which looks like:
Root hints
Thankfully these IP addresses don't change very often.
The nameserver picks one at random and sends off the query for the A record of; here it's going to
DNS resolution, steps 2 and 3
3 The root server doesn't know anything about, but is happy to send me the way of the Global Top Level Domain (GTLD) servers responsible for the .net domain. This is in the form of NS records of servers more qualified to answer our query: "Go ask these guys - here's a list".
.NET referrals
/* Authority section */
NET.                 IN  NS A.GTLD-SERVERS.NET.
                     IN  NS B.GTLD-SERVERS.NET.
                     IN  NS C.GTLD-SERVERS.NET.
                     IN  NS M.GTLD-SERVERS.NET.

/* Additional section - "glue" records */  IN  A  IN  A  IN  A
...  IN  A
Though technically we asked only for the NS records, the root servers also give us the IP address of each: this is known as "glue" and is provided to save us from having to look it up.
4 With the helpful referral from the root servers, this nameserver chooses one of the authoritative servers at random — here, — and sends off the same query: "I was told to ask you: what's the A record for". DNS Resolution, steps 5 and 6
5 The GTLD server doesn't know the specific answer to our query, but it does know how to get us closer. Like the root servers, it sends back a referral (a set of NS records) that are likely to have what we seek. referral
/* Authority section */        IN  NS
                    IN  NS

/* Additional section - "glue" records */     IN  A  IN  A
6 Once again the recursive nameserver is following a chain of referrals on the client's behalf, and it picks one of the nameservers at random and sends off a third query (the same as the other two). DNS resolution, steps 7 and 7
7 Unlike the other answers, that merely passed the buck onto other nameservers, this one actually has what we were looking for: it provides the A record for
In addition, the response includes a flag saying "This is an authoritative response", indicating it came from the source of truth for this domain.
8 Now with answer in hand, the ISP's recursive nameserver hands that answer back to the client, and that satisfies the entire query.
The recursive nameserver also files away this answer into its own cache in case this or some other client makes the same query later.
But we'll note that the reply to the client doesn't include the "authoritative" indicator. Even though it received one from, the recursive nameserver can't pretend to the client that it's actually the source of authority, so it's considered a non-authoritative answer.
DNS resolution, steps 7 and 7
This procedure goes on under the hood trillions of time every day over the internet. DNS is quite fast, so the eight-packet handshake (for this particular query) routinely completes in just a split second.
This reveals the distributed nature of DNS: no one machine knows everything, but they do know how to find each other via delegation.
As a side note, nothing prevents any nameserver from hosting any zone, including those it doesn't really own. A bad guy could set up a nameserver and configure an authoritative zone for, but it has no effect because no higher-level nameserver ever delegates to it.

What's in a DNS packet?

With a grasp of the high-level exchanges we dig a bit deeper into what's inside a DNS packet: the details are required to understand cache poisoning and this recent vulnerability. There's a lot of detail here, but fortunately many of the fields aren't important for an understanding of these issues.
The illustration on the right shows the overall structure of a single packet of DNS data, and it can reflect a question packet or an answer packet. We've highlighted some of the fields that are most related to this exploit.
regular DNS packet
Source / Destination IP address
These reflect the IP addresses of the machines that sent and should receive the packet. It's possible to forge the source address, but pointless to forge the destination.
Analog in the real world: on an envelope sent in the US Mail, you can put anything you want as the return address — the source address — but if you lie about the recipient, it's not going to go where you want.
Source / Destination port numbers
DNS servers listen on port 53/udp for queries from the outside world, so the first packet of any exchange always includes 53 as the UDP destination port.
The source port varies considerably (though not enough, as we'll find shortly): sometimes it's also port 53/udp, sometimes it's a fixed port chosen at random by the operating system, and sometimes it's just a random port that changes every time.
As far as DNS functionality is concerned, the source port doesn't really matter as long as the replies get routed to it properly. But this turns out to be the crux of the problem at hand.
Query ID
This is a unique identifier created in the query packet that's left intact by the server sending the reply: it allows the server making the request to associate the answer with the question.
A nameserver might have many queries outstanding at one time — even multiple queries to the same server — so this Query ID helps match the answers with the awaiting questions.
This is also sometimes called the Transaction ID (TXID).
QR (Query / Response)
Set to 0 for a query by a client, 1 for a response from a server.
Set by client to 0 for a standard query; the other types aren't used in our examples.
AA (Authoritative Answer)
Set to 1 in a server response if this answer is Authoritative, 0 if not.
TC (Truncated)
Set to 1 in a server response if the answer can't fit in the 512-byte limit of a UDP packet response; this means the client will need to try again with a TCP query, which doesn't have the same limits.
RD (Recursion Desired)
The client sets this to 1 if it wishes that the server will perform the entire lookup of the name recursively, or 0 if it just wants the best information the server has and the client will continue with the iterative query on its own. Not all nameservers will honor a recursive request (root servers, for instance, won't ever perform recursive queries).
RA (Recursion Available)
The server sets this to indicate that it will (1) or won't (0) support recursion.
Z — reserved
This is reserved and must be zero
Response code from the server: indicates success or failure
Question record count
The client fills in the next section with a single "question" record that specifies what it's looking for: it includes the name (, the type (A, NS, MX, etc.), and the class (virtually always IN=Internet).
The server repeats the question in the response packet, so the question count is almost always 1.
Answer/authority/additional record count
Set by the server, these provide various kinds of answers to the query from the client: we'll dig into these answers shortly.
DNS Question/Answer data
This is the area that holds the question/answer data referenced by the count fields above. These will be discussed in great detail later.
We'll see these in action as we disassemble our sample query shortly.

Resource Record Types

DNS Types logo Ultimately, DNS is a kind of distributed database, and each query or response includes a name, a type, and (for a response) a value. The resource types represent different purposes, and no understanding of DNS is complete without knowing about them.
There are dozens of resource record types, though only a few are in common usage. The rest are experimental, obsolete, or serve obscure purposes that rarely come up in practice.
Common DNS Resource Record Types
Type Description
A This is an IP Address record, and is the most obvious type of data supported by DNS. Indeed; many users have no idea that DNS deals with anything other than IP addresses.
NS This describes a Nameserver record responsible for the domain asked about.
MX The MX record encodes the name of a Mail Exchanger, a system responsible for handling email for the given domain. Multiple MX records can be provided for a domain (they included way to specify priority). Email server software is the main consumer of MX resource records.
Curiously, the mail exchanger for a domain doesn't have to be part of that domain; it's common for the mailserver at a large hosting operation to be primary MX for thousands of customer domains.
SOA The Start of Authorities record describes some key data about the zone as defined by the zone administrator (on the domain master machine). It includes things such as the contact address for the admin, and the amount of time that slave nameservers should hang onto the zone in case the master is unreachable.
CNAME The Canonical Name, more commonly known as an Alias, this allows providing an alternate name for a resource.
TXT A generic Text record that provides descriptive data about domain. These are essentially comments, though some applications (such as SPF) use them for programmatic purposes.
It's generally (but not universally) allowed that one name can have multiple resource records, even more than one of the same type. A common example would be a machine having multiple IP addresses, both of which are entered in DNS: IN A IN A
Here, the name has two IP address records associated with it, and both will be returned in answer to an A query for this name. Note that the order of the addresses as they appear in the file are not maintained in the responses: they're usually shuffled.
We'll note that the IN token means the INternet class, and this is virtually the only class you'll ever see in practice. Others (such as Chaos or Hesiod) are defined but are for specialized and mostly obsolete purposes.

Drilling down to a real query

Steps 4..7 Recalling our query exchange above, we're going to study steps 4 through 7 in some detail: they are most representative of the DNS name-resolution process without adding duplicative steps.
Ultimately, DNS is a kind of distributed database, and it can look up much more than just an IP address: there are multiple resource record types involved in a query, and one can't understand the packet structure without knowing their distinctions.
We'll note that not every detail is predictable even when the protocol is fully understood: nameservers have some latitude in how they accomplish a resolution, so a few alternatives are available. We're just choosing one common path through this process.
In this example, we're using the nameserver of our own ISP — — (referred to as dnsr1) as the local recursive nameserver, and we'll find a few things in common for all of them.
  • In every case, the Question section is the same: "What is the A record for". This question is also repeated in the answer — mainly as a convenience — so it's seen in common in every packet we look at.
  • The ISP's nameserver usually sets the RD=1 flag (Recursion Desired) on the odd chance that the other end is willing to do the heavy lifting and go find this answer for us. Most top-level nameservers are unwilling to do this, so they give us the best information they have and set RA=0 flag (Recursion Unavailable) to let us know that we have to do the work ourselves.
  • In this example, the source UDP port number for all queries from our ISP's nameserver is the same. It's a common practice for nameserver software to request a random port from the operating system at startup, then use it for every query.
  • We observe that the Query ID increments by one each time it sends a new query.
So with this information in hand, let's walk through the steps in detail and see how our "simple" query is actually resolved.
2&3 In this step our ISP's nameserver queried a root server for, and it replied with a list of global top-level domain servers that knew about the .net hierarchy. From this delegation, the ISP's nameserver chose one at random (, as shown in step 4. (not illustrated)
client to server
The dnsr1 server at our ISP grabs one of the GTLD nameservers received from a root server (in step 3) and fires off a second query. This is essentially the same as the first; the Question is about the A record
Because this is a query — not a response — the answer/authorities/additional records fields are blank (as shown with a count of zero).
The Query ID value was taken as the next ID available from this server's internal counter.
DNS Packet, Step 4
server to client
The GTLD server we asked doesn't know the specific answer to our question, but it knows where to ask: it responds with a series of NS records that should know how to handle our request. They show up in the Authorities section as and
We're given hostnames of the nameservers we ought to contact, but real network connections are only made by IP address: how do we look these up? Avoiding what would clearly be a chicken-and-egg problem, the GTLD nameserver provides not only the hostnames of the authoritative servers, but their IP addresses too.
These are provided as A records in the "Additional Records" section, and are known as "glue data".
Because this nameserver can't give us the final answer, it sets the AA=0 flag (Authoritative Answer) to zero, indicating that somebody else knows the real story and we have to keep asking around.
But a related note: dnsr1 is a very busy nameserver, having perhaps hundreds of queries outstanding every second. How does it know that this reply packet is a response to that specific pending request?
The answer is: by matching on the Query ID. Inbound DNS packets that don't have a waiting Query ID are ignored.
The TTL is a Time To Live, discussed later.
DNS Packet, Step 5
client to server
In step 5 we received two nameservers that are purported to know more about the domain, so one more query is created that asks the same question — again! — of these just-learned nameservers.
This request is really no different from the previous queries, though it does increment the Query ID by one before sending it off. The idea is that we keep following these delegations until we actually get a real answer, not a referral.
DNS Packet, Step 6
server to client
And at last the answer comes!
Unlike the previous replies, this one has answer count=1, and it carries an A record with the IP address to satisfy our query.
In addition, this response has the AA=1 flag set, which indicates that it's an authoritative answer (aka "from the horse's mouth"). If an answer is provided but with AA=0, we assume it's from the server's cache.
The answer also includes the authority and glue information, but this time all we're really interested in is the answer itself. And the nameserver used the Query ID of 43562 to match this reply to the pending request.

DNS Packet, Step 7
As noted previously, these transactions typically occur very rapidly across the internet, and the user is normally unaware that so much is going on under the hood on his behalf.
But local performance is further enhanced by use of a local cache in the recursive nameservers: this is an important part of the domain-name system, and gets us one step closer to our security issue.

What's in the cache?

Dollar bill: yes, it's a visual pun In the DNS lookups we've seen so far, the ISP's resolving nameserver has gone out and fully resolved each name from scratch, relying on no prior knowledge except the built-in root hints.
But in practice this full road trip is not necessary: once we get an authoritative answer for a given name, we can save it in a local cache to use to satisfy future queries directly.
The more clients serviced by a nameserver, the more benefit of the cache: the work of the full name resolutions is spread out over the whole client base. It may well require quite a bit of memory in the nameserver, but the amounts of RAM required are peanuts compared with the benefits.
TTL logo - stopwatch

The Time-To-Live

When a DNS answer is stored in the local cache, it can't keep it forever: this could lead to terribly stale data that effectively breaks the domains involved.
subset of packet showing A record TTL Fortunately, the recursive nameserver doesn't have the burden of guessing how long to cache things: the administrator of the zone specifies this information for every resource record. This is known as a Time To Live (TTL), and it's a lifetime measured in seconds.
A TTL can be a short as a few minutes, or as long as a week or more: this is entirely determined by the administrator of the zone.
In our final Step-7 answer above (with snippet to the right), we see the TTL of one hour for the A record in All client requests for this resource record in the next hour will be satisfied immediately, from the cache. But once it expires, it's removed from cache and the next request will force a full lookup from scratch.
subset of packet showing NS/glue TTL But it's not just the A record that's cached; all the other authority data (the NS data plus associated glue A records) arrive with their own TTLs, and are also cached. This means that a full lookup for a single resource record could well fill the cache with a half dozen associated records or more.

Poisoning the cache

With a good understanding of a properly-functioning DNS, it's time to see where things break. Cache poisoning is where the bad guy manages to inject bogus data into a recursive nameserver's cache, causing it to give out that bad information to unsuspecting local clients.
It's not so simple as just sending random DNS packets to a nameserver, as DNS only accepts responses to pending queries; unexpected responses are simply ignored.
How does a nameserver know that any response packet is "expected"?
  • The response arrives on the same UDP port we sent it from: otherwise the network stack would not deliver it to the waiting nameserver process (it's dropped instead).
  • The Question section (which is duplicated in the reply) matches the Question in the pending query.
  • The Query ID matches the pending query
  • The Authority and Additional sections represent names that are within the same domain as the question: this is known as "bailiwick checking".
    This prevents from replying with not only the IP address of, but also fraudulent information about (say)
If all of these conditions are satisfied, a nameserver will accept a packet as a genuine response to a query, and use the results found inside. This includes caching answers, as well as valid authority and additional data found there too.
But if the bad guy can predict and forge a DNS response packet that's just right, he can cause all kinds of shenanigans for the victims.
The bad guy normally first chooses his victim by finding a nameserver he believes vulnerable to poisoning: all of the clients of that DNS server get to unwittingly ride the victim train as well.
Then he finds a target domain, one he wishes to take over. His intent is to fool the victims into visiting his own malicious website instead of the real deal: by getting to resolve to the bad guy's IP address, the user's traffic visits the bad guy's website instead of the good one.
We noted that unexpected packets were simply dropped, so a bad guy need not get everything right every time: sending many packets attempting to guess some of the key parameters is likely to prove fruitful with enough attempts.

Guessing the Query ID

In old nameservers (and in our detailed packet trace example), the Query ID simply increments by one on each outgoing request, and this makes it easy to guess what the next one will be as long as an interloper can see a single query.
Bad guy finding Query ID We probably can't directly ask the nameserver for its query ID, but we can provoke it into telling us:
  1. Bad guy asks the victim nameserver to look up a name in a zone for a nameserver he controls (perhaps
    He might query the server directly, if it permits recursion from his location, or he might convince a user to lookup a name — perhaps by including the test hostname on a web page.
  2. Victim nameserver receives the request and makes the usual rounds to resolve the name starting at the root servers. Here, we've put the root and GTLD servers in the same category to separate them from the bad guy's nameserver.
  3. Eventually, the victim nameserver will be directed to the bad guy's nameserver: after all, it's authoritative for
  4. Bad guy monitors this lookup of by sniffing the IP traffic going to his own machine, or perhaps even with a custom modification to the nameserver software, and from this discovers the source port and Query ID used.
At this point he knows the last query ID and source port used by the victim nameserver.
But the thoughtful might wonder: so what? This hasn't poisoned anything yet, and there's no need to engage in DNS shenanigans for anyway. After all, the bad guy is already authoritative for his own zone.
True enough, but this was only the first step: the next one engages in DNS shenanigans for other domains.

Shenanigans, Version 1

With the ability to easily predict a query ID, and since our victim nameserver always sends queries from the same UDP port, it should be easy enough to cause some trouble.
In this illustration, we'll attempt to poison a particular nameserver with a fraudulent IP for a legitimate banking website, The bad guy's intention is to get all of the ISP's customers to visit his own malicious site instead of the real one operated by the Bank.
Simple Poisoning
  • Step 1 — Bad guy sends a DNS query to the victim nameserver for the hostname it wishes to hijack. This example assumes that the victim nameserver allows recursive queries from the outside world.
  • Step 2a — Knowing that the victim will shortly be asking (as directed from the root/GTLD servers) for an IP address, the bad guy starts flooding the victim with forged DNS reply packets. All purport to be from, but include the answer with the IP of badguy's fraudulent webserver.
  • Steps 2b & 3 — Root/GTLD servers provide referral to This may be multiple queries, but we're showing just one for simplicity.
  • Step 4 — victim nameserver asks for the IP address of, and it uses query ID 1001 (one higher than the previous query).
  • Step 5 — the real nameserver provides a legitimate response to this query, with QID=1001. But if the bad guy has successfully matched the query ID in the step 2a flood, this legal reply arrives too late and is ignored. Oops.
  • Step 6 — With the bogus IP address (of the bad guy's webserver) in cache it provides this poisoned answer to the requesting DNS client. Boom.
  • Step 7 (not illustrated) — future DNS clients asking for will receive the same fraudulent answer.
The rule is: first good answer wins. Most of the forged answers are dropped because the Query ID doesn't match, but if just one in the flurry of fake responses gets it right, the nameserver will accept the answer as genuine.
And because that satisfies the request, the real answer that arrives later is dropped, because the query is no longer pending.
In any case, once the bad guy gets the answer from the victim's nameserver, the matter is closed, and he can stop flooding the victim.
We'll note that even though this illustrates trying to beat just the reply from, our forged DNS traffic could actually match the query ID of any of the prior steps.
This includes matching an earlier reply from the root server or the GTLD (.com) server: if the query ID matches, our fake authoritative wins, and pollutes the cache. This is a race, but only the attacker knows it's playing.
The name can't already be in the cache
If is already in the victim nameserver's cache, all of the external queries are avoided, and there's simply no way to poison it in this manner.
If the bad guy still wants to poison that particular hostname, he has to wait for it to expire from cache (as determined by the TTL).
The bad guy has to guess the query ID
This is made easy with (now-obsolete) nameservers that increment the Query ID by one each time — even a busy nameserver has a fairly small range to guess from.
The bad guy has to be faster than the real nameserver
If the victim nameserver and the real nameserver are topologically close (network wise), then the steps 2/3 and 4/5 may complete so quickly that the bad guy has a too-small window to exploit.


An obvious mitigation here is to randomize the Query ID.
With sequential Query IDs, the bad guy has a fairly limited range of guesses required once he observes a single current Query ID. If he sees QID=999, then he may flood with QIDs 1000-1029 in an attempt to make at least one match.
Experience has shown this is an easy window to beat.
But if the nameserver chooses random Query IDs, then the attacker has the full 16-bit pool to choose from — that's 64k values — and this is a much harder target to hit in the narrow window of time while the victim is going through the routine resolution steps.
Though forging 20 packets in routine name-resolution time is straightforward enough, doing so with thousands of packets is a much more substantial challenge.
So true randomization of Query IDs raises the bar quite a bit.

Dan's Shenanigans

So far we've seen how to poison a single record, but this has less impact than expected: it's just one record, and many properties require multiple hostnames to operate, and it's harder to hack them all.
Dan Kaminsky found an approach that's dramatically more effective than this, and it caused quite a furor in the security community. The general approach is the same as the simple approach shown above, but the key difference is the nature of the forged payload.
Kaminsky Poisoning In the simple example, our intention was to poison the final answer, the A record with the IP address, but what Dan discovered is that we can go up one level and hijack the authority records instead.
Before undertaking the attack, the bad guy configures a nameserver that's authoritative for the zone, including whatever resource records he likes: A records, MX for email, etc.
There's nothing stopping anybody from configuring his own nameserver to be authoritative for any domain, but it's pointless because the root servers won't point to it: it's got answers, but nobody ever asks it a question.
  • Step 1 — bad guy client requests a random name within the target domain (, something unlikely to be in cache even if other lookups for this domain have been done recently.
  • Step 2a — As before, the bad guy sends a stream of forged packets to the victim, but instead of A records as part of an Answer, it instead delegates to another nameserver via Authority records. "I don't know the answer, but you can ask over there".
    The authority data may well contain the "real" nameserver hostnames, but the glue points those nameservers at badguy IPs. This is the crucial poisoning, because a Query ID match means that the victim believes that badguy's nameservers are authoritative for
    The bad guy now owns the entire zone.
  • Curiously, the rest of the steps don't matter: the point of this process was to fake out the victim into thinking that badguy runs the domain in question, and that would have been successful in this step.
    Once one of the victim's queries has been poisoned — it could be any in the chain — all the rest are directed to badguy's servers.
This is a devastating attack: by owning the entire target domain, the bad guy controls essentially everything with respect to that resolving nameserver. He can redirect web visitors to his own servers (imagine redirecting, he can route email to his own servers via serving up bogus MX records.
The bad guy will typically set a very high TTL in the poisoning responses so that the victim will keep the bogus data in cache as long as possible.

Flurry of queries

Our example has shown a single query being hijacked, but this is unlikely to be successful: because of Query ID randomization, it's not likely that that the bad guy will manage to get a hit in the short time required to match on 64k IDs.
Instead, the bad guy issues a flurry of queries, each for a different random name under the main domain. The first request caused the nameserver to perform the usual root-first resolution, but it eventually caches the valid values. Subsequent queries within this domain go directly to that nameserver, skipping the root steps.
But the next request for a different random name (which certainly won't be in cache) causes an immediate query to the valid ns1 server. The bad guy then throws a flood of forged data at the victim about that second random name, though the odds here are still pretty long.
Just for the sake of discussion, let's assume that the bad guy can generate 50 forged replies for each random name query before the real reply arrives from the real nameserver. This appears to be a very small chance, but when repeated over and over — and run from automated tools — success by the bad guy is likely.
It's been reported that success can commonly be achieved in 10 seconds.

Going for the top

Our examples have all focused on hijacking an end domain, but the same techniques can do the same thing up a level: taking over .COM, .NET, or the like.
By poisoning the Authority records for .COM and the like, the victim nameserver will route all DNS lookups to the bad guy's nameservers. This effectively hijacks all names under that top level, including domains he didn't actually request. This gives a great deal of flexibility even though it may well require substantial computing and network resources to serve the flood of requests that this hijacking must generate.

What's the fix?

This all sounds awful: how does one fix this?
As has been alluded to several times, it's the small space — just 16 bits — of the Query ID that makes this attack possible. Though certainly one might wish to increase that ID to something larger (perhaps 32 bits), it's simply not possible do that in the short term because it would break DNS on the internet: the fields are what they are, and they can't be changed casually.
But an additional source of randomness is required nevertheless, and that's been done by randomizing the source port. Rather than use just a single UDP port, which is trivial to discover, a much larger range of ports is allocated by the nameserver and then used randomly when making outbound queries.
As one would imagine, the nameserver would keep track of which source port was used for each query: replies arriving on the wrong port would be discarded just as if the Query ID failed to match.
Microsoft's updated DNS server is said to preallocate 2,500 UDP ports to use for these random queries, and for discussion we'll round this down to an even power of two: 2 11 = 2,048. This yields this much larger transaction space:
27 bits of entropy Increasing the search space from 64k to 134M provides far better odds for the good guys.
We presume that each nameserver provides a way of setting how large of a pool to use for these source ports, as well as a way of excluding certain port numbers known to be required for other purposes.


This has been an exceptionally serious vulnerability because it undermines the very faith in DNS: this is at the core of the internet. Most experts believe that if you can't trust DNS, all else is lost, and we're of this same mind.
There is far more detail about this vulnerability than we can present here, and we'll urge the reader to consult other resources (especially Dan's presentation).
But we can include a few (ahem) random notes about this matter that didn't seem to fit in elsewhere, and seem important and/or interesting enough to include in this paper.
  • Patch your servers: Tools exist to make exploit-in-a-box available to even low-skilled bad guys.
  • Authoritative-only nameservers are not vulnerable because they have no cache to poison, but we'd be surprised if no small number of "auth only" nameservers actually provided recursive service to at least some clients.
  • A nameserver need not be directly visible to the Internet to be exploitable. By convincing a user to visit a particular web page, it can trigger a chain of events that reliably lead to poisoning.
  • Even patched servers may still be vulnerable if an intervening firewall performs Port Address Translation in a way that un-randomizes the source ports.
  • It's been suggested that DNSSEC or IPv6 are solutions to this problem, but this is only in theory. Both of these technologies have to be fully rolled out to be effective, and this is likely years away, at best.
  • The Secure Sockets Layer (SSL) is only a partial protection against being redirected to malicious websites. Putting up a fake website will have the wrong SSL certificate name (which is a warning to the user who's paying attention), but the great majority of users skip right through those warnings.
  • But the bad guy can subvert even SSL: since many Certificate Authorities validate a user's control over a domain by sending email, hijacking a mailserver by attacking the cert vendor's resolving DNS, this may well mean that an attacker can obtain a fully-valid certificate for the target domain.
    This is very scary.