Main | décembre 2004 »

novembre 12, 2004

Généalogie

J'ai trouvé cette feuille [168 Ko] dans un tiroir, j'ai recopié les données si ça peut intéresser quelqu'un.

Généalogie des Filion au Québec

André Filion
Gabrielle Senler
Saint-Germain-de-l'Auxerrois, Paris, Île-de-France

1ère génération

Antoine Filion, 1666
Anne Anneville
Paris

2e génération

Jean Filion, 6 juin 1695
Françoise Simard-Senat
Québec

3e génération

Paul Filion, 12 novembre 1731
Marie-Josette Tremblay
Baie-Saint-Paul

4e génération

Antoine Filion, 29 octobre 1770
Victoire Girard
Baie-Saint-Paul

5e génération

Pierre Filion, 25 septembre 1798
Marie-Geneviève Lessard
Saint-Joachim

6e génération

Pierre Filion, 13 février 1827
Théetiste Elie Breton
Saint-Joachim

7e génération

Pierre Filion, 21 juillet 1868
Virginie Boucher
Saint-Joachim

8e génération

Sylvio Filion, 19 avril 1909
Blanche Dussault
Victoriaville

9e génération

Émile Filion (dit Jack), 24 décembre 1938
Cécile Gagné
Victoriaville

10e génération

Jacky Filion, 6 août 1946
Nicole Laliberté
Québec

11e génération

Guillaume Filion, 9 août 1980
Beaumont

Posted by gfk at 7:07 PM | Comments (0)

How to kill a unix process

Were you ever told to kill a Unix process using "kill -9 pid"? Did you know that that was wrong? Here's a copy of a Usenet posting by Randal L. Schwartz explaining why.

I keep a printed copy of the message posted on the wall.

Newsgroup:comp.unix.questions
Date:2001-01-20 (20 Jan 2001 09:58:20 -0800)
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Dangerous use of Kill -9 (was Re: kill users script?)

>>>>> "dipwad" == dipwad writes:

dipwad> kill -9 $PID
...

dipwad> Maybe this will get you started in the direction you wish to take.

Only if you want to make a script which has many unintended consequences.

As I've said before...

No no no. Don't use kill -9.

It doesn't give the process a chance to cleanly:

1) release IPC resources (shared memory, semaphores, message queues)

2) clean up temp files

3) inform its children that it is going away

4) reset its terminal characteristics

and so on and so on and so on.

Generally, send 15 (SIGTERM), and wait a second or two, and if that
doesn't work, send 2 (SIGINT), and if that doesn't work, send 1
(SIGHUP). If that doesn't, REMOVE THE BINARY because the program is
badly behaved!

Don't use kill -9. Don't bring out the combine harvester just to tidy
up the flower pot.

Just another Useless Use of Usenet,
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Posted by gfk at 6:34 PM | Comments (0)

novembre 11, 2004

GFK's, what about that nickname?

Every now and then, people are inquiring about my nickname, GFK's. Here's the story.

FAQ: GFK's, what about that nickname?

My father got a modem in the beginning of the 90's. We connected it to our Macintosh II and logged on to Synapse, the BBS of the Club Macintosh de Québec (Quebec Macintosh User Club).

I had to choose a nickname for the BBS, the Oliver Stone's movie JFK was really popular in those years. I was 12 years old at the time, and my english was pretty thin. When pronounced in english, JFK sounds like GFK pronounced in french, so GFK was an interesting souding nickname. I added the 's because I kept seeing it in english texts and I didn't know what it was used for! ;-)

The complete nickname is GFK's, even if it is not syntactically correct, i.e.: "GFK's said that it's nice". However, you can use GFK (without the 's) whenever you feel like it, i.e.: "GFK's a nice guy" and "GFK said that it's nice".

Later in the 90's, the term "GFK's Palace" was coined by Gabriel Michaud. He was the SysOp (System Operator) of MacMania BBS, a local BBS running on Hermes. I was one of the CoSysOps. MacMania was part of the FidoNet (node 1:240/318), sending a message from MacMania to the Internet would take one week! When Gabriel (and his BBS) moved to the other side of the city, I had to pay a toll charge to call the BBS. Gabriel proposed that I became a FidoNet point, so that I only had to connect for a few minutes per day. He called my node GFK's Palace. I also own the domain gfk-palace.org since 2001.

My nickname should not be confused with these entities:

• GfK Group, a European market research institute.


• Government Fury Kills, a punk music group from Québec City.


• Grand Forks International Airport (GFK), North Dakota’s busiest commercial airport.

Posted by gfk at 8:04 PM | Comments (1)

novembre 10, 2004

The history of Solaris

A while ago, Philip Pokorny explained to me what was up with Solaris (SunOS) version numbers. It's worth keeping as a reference.

In case you were looking for a longer history, check out this excerpt from the Solaris 8 System Administrator Guide.

Sun's operating system was originally based on BSD and called SunOS.
Numbered 4.x in line with the BSD numbering convention.

When Sun started working with AT&T and switched to the SysV code base, they renamed their OS Solaris.

In a fit of marketing confusion, they decided to rename SunOS 4.3 ->
Solaris 1.0. The new AT&T code base was called Solaris 2.0 but uname
reports it as 5.0 so that scripts that compared uname versions would see
that Solaris 2 was newer (5 > 4) than SunOS 4.

Solaris version 2.0, 2.1, 2.2, 2.3, were all generally pretty bad. 2.4
was the first Solaris release that was stable enough for my previous
employer to use. 2.5 was much better and 2.5.1 was rock solid.

Solaris 2.6 was pretty good, but major changes were coming.

With Solaris 2.7, the marketting types got involved again and renamed
the OS. They decided they couldn't compete with Red Hat 6 and Windows
NT 4.1 with a name like Solaris 2.7 so they renamed it "Solaris 7", but
uname *still* says 5.7.

The tradition continues with Solaris 8 (uname -> 5.8)

Posted by gfk at 8:51 PM | Comments (1)

À la défense de CHOI

Copie d'une lettre que j'ai envoyé au journal Voir à l'été 2004 à propos de la décision du CRTC de fermer la station CHOI-FM. Elle a été publiée dans la version papier du journal (Vol. 13 no 29 p. 8).

À la défense de CHOI

Je suis personnellement choqué par la décision du CRTC dans le dossier de CHOI-FM. Avec cette décision, le CRTC affirme que la liberté d'expression doit être restreinte lors d'une radiodiffusion, c'est-à-dire que l'on admet seulement une liberté diluée à un média très populaire dans tous les sens du terme. Il existe une expression qui dit: "La liberté de presse, c'est bien, mais il faut avant tout avoir une presse." Elle souligne qu'il n'est pas donné à tous de pouvoir exprimer son opinion à un large public. Même que dans certains pays, ce "droit" n'est accessible qu'à une poignée d'individus. Heureusement, ce n'est pas le cas chez nous, mais avec sa décision, le CRTC étrangle cette diversité d'opinions, qui est le signe d'une démocratie en santé.

Les propos des animateurs de CHOI sont certes choquants et déplacés, mais ils ne sont pas illégaux selon le Code criminel. Les ondes appartiennent au peuple, et on ne devrait jamais empêcher une partie de la population de s'en servir afin d'exprimer son opinion, aussi gênante soit-elle. Je suis d'avis que les seuls discours qui devraient êtres interdits sur les ondes sont ceux qui sont interdits par le Code criminel, et dans ce cas, on devrait poursuivre la personne qui a tenu ce discours et non la station qui l'a émis. J'ai confiance en la Charte des droits et en notre système de justice, et je suis personnellement convaincu que cette décision sera renversée, si ce n'est pas en Cour d'appel, en Cour suprême.

Vous remarquerez que mon nom est Filion. Je vous rassurerai peut-être en vous disant que je n'ai aucun lien de parenté avec l'animateur Jeff Fillion, animateur que je n'aime pas, mais dont je respecte le droit de s'exprimer. Rappelons-nous les paroles de Voltaire: "Je ne suis pas d'accord avec ce que vous dites, mais je suis prêt à me battre jusqu'à la mort pour votre droit à le dire."

Posted by gfk at 7:52 PM | Comments (0)

Software review: djbdns

Last year, I discovered djbdns from an article on rootprompt. I spent some time studying the program and summed my toughts in this article.

Software review: djbdns

For years, the de facto standard for DNS has been BIND. In the recent years, other DNS programs have appeared. Most of these newcomers are targeted at big corporations that must manage thousands of zones. These programs often use a database backend. djbdns is different in that it is designed with security in mind. In this article I explain how I see the principles that are the foundation of djbdns and their implications.

The Unix way

The Unix philosophy has always been to make small and specialized programs and to pipe the information from one to the other. On the opposite is the Microsoft approach to make the only program you'll ever need where a spreadsheet, a database and a graphics program are bundled with a word processor.

djbdns follows the Unix philosophy in dividing the task in as much different programs as possible. To have all the features of BIND with djbdns, you'll need 6 different processes running (without counting their child): supervise, multilog, svscan, tinydns, dnscachex and axfrdns. This is a good thing, since these processes don't trust each others, if dnscachex gets corrupted, tinydns will remain sane. This is different with BIND where several attacks are based on corrupting the cache portion of the program to affect the DNS data served.

There's only one way to do it

You may know perl's motto There's more than one way to do it which shows the democratic and freedom values embedded in perl's culture. When I started playing with djbdns, I realised that its motto could be There's only one way to do it. At first sight it might seem like a sad thing to say, but you'll realise that is what the army as been doing all along. And well, the army is known to be secure.

You'll never see an army manual saying:

If you want to clear your rifle, you can start by removing the cartridge, you could also check out if there's a bullet in the chamber. If you feel like it, it is possib le to remove the powder in the chamber or oil the rifle. etc.

This sound pretty awkward and certainly pretty dangerous. As any army soldier will tell you that there is a strict procedure to clean a rifle and not following this procedure can result in lots of trouble for you.

It's the same thing for djbdns, for example, you need to use daemontools to drive you daemon, not TCP wrappers (inetd) or a stand alone daemon. Yep, only one way.

Security wise this really does make sense. Imagine five sequential operations, if there are three ways to do each, then there are 243 (3^5) different possible paths. Each one of these paths must be inspected and tested by the programmer to make sure that it's not possible to abuse it. Most of the times you'll end up with a couples of esoteric paths that have not been correctly tested and end up being exploited. On the other hand, if you only have one path through these five operations, you can expect that the programmer has thoroughly tested it. That's why IPv6 support is still only available as a patch while about every other program has IPv6 support built in. The fact is that IPv6 support build in would only be used by less than 2% of the users and adding complexity to the program for 100% of the users.

I believe that there's only one way to do it is a good thing, it may not be the way that you want to use, but if you're ready to make the sacrifice and use it, you can be sure that it's a pretty safe path.

Disclaimer: I don't know much about guns, so my cleaning procedure is really inaccurate.

No freedom

As with any army, if you're a soldier, you can't tell your Sergeant what you think would be a better way to do something, you must listen to his orders or quit the army. This is the same for djbdns, if you don't agree with a way of doing things, you can write to the mailing list to offer your opinion, but I doubt that it will be incorporated in the main source code. It goes against the there's only one way to do it philosophy, because it would require a lot of efforts to incorporate that change. Of course, this is not as strict as a real army, you can always modify the code source yourself and publish a patch, but you can't publish a modified djbdns. I talk about the strange licensing later.

As long as you trust D. J. Bernstein as your General, you'll be happy in djbdns army. As said differently by some people, djbdns is a good program if you're ready to accept Mr. Bernstein's way of seeing things.

The there's only one way of doing it philosophy can really reduce the excitement and synergy of open-source software, where several people contribute to a program to make it better. That's the price to pay to use this philosophy.

Ingenuity

The traditional way of doing DNS replication of your primary server is using zone transfers. Zone transfers are requests done by secondary servers to the primary server. In order to know when to request a new version of a zone, a serial number polling mechanism has been designed in the protocol. Every couple hours, the secondary servers request, using UDP DNS, the zone's serial number on the primary server. If the serial number is bigger than the one on the secondary server, a DNS zone transfer is requested. Because of size limitations of the UDP datagram, zone transfers have to be done in TCP. As you can see, this procedure is quite awkward and can lead to a lot of problems, including outdated zones on the secondary servers and security vulnerabilities during the zone transfer.

When creating djbdns, instead of blindly implementing the zone transfer mechanism, Dan Bernstein studied what was needed to replicate the primary DNS server on the secondary servers. He realized that the existing polling mechanism was working upside down and that the good way of doing replication was by a push mechanism. The push mechanism can easily be implemented using existing UNIX tools: rsync and ssh.

When the DNS administrator modifies a zone on the primary server, he types make to have it compiled and loaded into tinydns. If there are secondary servers, two lines have been added to the Makefile to launch rsync and send the binary differences immediately to the secondary servers. Since rsync is tunnelled into ssh, the data is encrypted and authentified. The replication is done in seconds, simply, reliably and securely. Absolutely brilliant. Bernstein at his best.

Licensing

djbdns distribution restrictions are quite exotic: you can download djbdns source code free of charge at cr.yp.to (cool address!), you can modifiy that source code at your will, but cannot distribute a modified version of djbdns. You are allowed, however to distribute a patch for people to apply over the unmodified djbdns. My guess is that these distribution restrictions are made to prevent software manufacturer from distributing a broken version of djbdns.

The problem is that most software manufacturers have standard naming procedures, so they often need to modify programs that they distribute so that they respect these standards. They can't do that under that license, that's why RedHat refuses to distribute a djbdns RPM(1). The debian people found a solution to this distribution restriction, they distribute a script that downloads djbdns unmodified from cr.yp.to, applies a patch, then compiles and installs it. This is indeed a very smart trick that completely bypasses the distribution restriction.

I really don't understand why Mr. Bernstein does not release djbdns under a less restrictive license, the debian script really show that this license is easy to bypass, making it totally ineffective. I guess that there's something that I don't understand here, because it seems to me that this licensing only results in problems. In my humble opinion, this restrictive license is the worst problem with djbdns right now.

1: Several individuals have released djbdns RPM, but at the time of writing RedHat has not.

Conclusion

djbdns is a real secure program. Everything has been designed with security in mind. There's even a US$ 500 reward if you can find a security hole in the latest version. To this date, none was found. (Lots of you will say that 500 bucks is worth not much for a security audit, but some people have a lot of free time on their hands these days.) Security has been chosen at the expense of other things, like experimentations and even some parts of the protocol. If you're looking for a production program that is secure and not going to change much, then djbdns is for you. If you want to experiment with DNS and try esoteric sections of the protocol, djbdns will not let you do it.

Posted by gfk at 6:38 PM | Comments (0)

novembre 9, 2004

Simple email virus scanning with Sanitizer and ClamAV

This article is the result of hours of trying to figure out how to clean up my email box. I was tired of receiving several spams and virii every day. I managed to set up spamassassin pretty easily, but I had several frustrating problems with automated antivirus email scanning.

Note that this article was written in 2003, so it might not be accurate anymore. By the way, I'm now using qpsmtpd to scan my incoming mail.

Simple email virus scanning with Sanitizer and ClamAV

I spent several hours trying to make Amavis work, at times it would even eat my emails without saying anything. When I finally managed to make it work on my system, its daemon would use 18 MB of RAM, which is a lot for a program that only starts an external antivirus program.

I finally abandoned Amavis and searched for something else that would simply work (and work simply). Surprisingly, it only took me about half an hour on Google to find out what I was looking for. Should I have done that before trying Amavis, it would have saved me of lot of pain. Here's what I found.

Anony Sanitizer

Anony Sanitizer is a relatively simple perl script that is called from procmail, it is designed to manage email attachments. It decides what to do with them depending on their filenames using regular expressions. It works with an external antivirus program, it is really easy to make it work with about any command line virus scanner out there.

Here's the formal description available on its web site.

The Anomy sanitizer is what most people would call an email virus scanner. That description is not totally accurate, but it does cover one of the more important jobs that the sanitizer can do for you - it can scan email attachments for viruses. Other things it can do:

• Disable potentially dangerous HTML code, such as javascript, within incoming email.
• Protect you from email-based break-in attempts which exploit bugs in common email programs (Outlook, Eudora, Pine, ...).
• Block or "mangle" attachments based on their file names. This way if you don't need to receive e.g. visual basic scripts, then you don't have to worry about the security risk they imply (the ILOVEYOU virus was a visual basic program). This lets you protect yourself and your users from whole classes of attacks, without relying on complex, resource intensive and outdated virus scanning solutions.

The sanitizer is designed not to waste important system resources (CPU, memory, disk space) unnecessarily, and does so by treating it's input as a stream which is scanned and rewritten a little bit at a time.

One of the core ideas behind the design of the sanitizer, is that just because a message contains an infected attachment doesn't mean that the rest of it shouldn't be delivered. Email often contains important information, and it is vital that a tool like this interrupt the normal flow of communication as little as possible. It's common courtesy to inform the user of any changes that are made. The Anomy sanitizer tries to follow these rules.

The sanitizer is based on solid foundations - most of the ideas implemented in the first versions of the sanitizer were ported from John D. Hardin's email security through procmail package. The sanitizer, like the code it is based on, is Free Software in the GNU sense of the term - the sanitizer may be modified and redistributed according to the terms of the GNU General Public License.

Sanitizer development is for the most part sponsored by FRISK Software International. Please consider buying their anti-virus products to show your appreciation.

Now that I had something to parse the messages and fire up the antivirus, I only needed an antivirus program.

Clam AntiVirus

I spent a lot of time trying every antivirus program listed on Amavis' web site and was disappointed by every single one of them. I finally found satisfaction when searching on packages.debian.org, where I found Clam AntiVirus (ClamAV for short).

ClamAV is a simple antivirus program using the OpenAntiVirus.org virus signatures. It's written in C and, like Sanitizer, it's licensed under the GPL. In my humble opinion, the only thing it lacks is a way to repair infected files like other antivirus programs do.

Here's the formal description from its web site.

Clam AntiVirus is an anti-virus toolkit for UNIX. The main purpose of this software is the integration with mail servers (attachment scanning). The package provides a flexible and scalable multi-threaded daemon, a command line scanner, and a tool for automatic updating via Internet. The programs are based on a shared library distributed with the Clam AntiVirus package, which you can use in your own software. Clam AV uses a virus database from OpenAntiVirus.org, we also help with signature generating.

Installation

I did the installation on Debian so I just ran apt-get install sanitizer clamav clamav-testfiles and everything was installed and configured.

On other systems, you may have to use RPMs or to compile the source, check out ClavAV docs and Sanitizer docs for more information.

Configure Clam Antivirus

On Debian this step is done by the installer, but you'll have to do it manually for other operating systems.

The only thing you need to do to configure Clam Antivirus is to have its virii signatures downloaded every night.

Set up a cronjob to start this every night: sudo -u clamav /usr/bin/freshclam --quiet -l /var/log/clam-update.log

The definitions will be saved to directory /var/lib/oav-virussignatures

Test ClamScan

To make sure that your Antivirus installation is working correctly, do the following steps.

ali:# cd /usr/share/clamav-testfiles/
ali:# /usr/bin/clamscan --recursive --unzip --unrar --tar --tgz
Archive:  /usr/share/clamav-testfiles/test2.zip
  inflating: clamtest                
/tmp/fe5346b6358e37b5/clamtest: ClamAV-Test-Signature FOUND
/usr/share/clamav-testfiles/test2.zip: Infected Archive FOUND
/usr/share/clamav-testfiles/README: OK
/usr/share/clamav-testfiles/test1: ClamAV-Test-Signature FOUND
/usr/share/clamav-testfiles/ha: OK

UNRAR 2.71 freeware      Copyright (c) 1993-2000 Eugene Roshal



Extracting from /usr/share/clamav-testfiles/test3.rar

Extracting  test2.zip                                                Ok

All OK

Archive:  /tmp/5928df3a8015eea3/test2.zip

  inflating: clamtest                

/tmp/b1c9441d58318672/clamtest: ClamAV-Test-Signature FOUND

/tmp/5928df3a8015eea3/test2.zip: Infected Archive FOUND

/usr/share/clamav-testfiles/test3.rar: Infected Archive FOUND

----------- SCAN SUMMARY -----------

Known viruses: 7271

Scanned directories: 4

Scanned files: 5

Infected files: 3

Data scanned: 0.00 Mb

I/O buffer size: 131072 bytes

Time: 2.403 sec (0 m 2 s)

If it reports 3 infected files like in the example above, then it is working properly. You can remove the clamav-testfiles if you want, they won't be needed anymore.

Configure Sanitizer

Sanitizer works with policies, you define policies for attachments depending on their filenames -- mainly their extension -- using regular expressions. The actions that you can do for each policy is: Accept, Mangle, Save or Drop.

I decided to define two simple policies:

1. Drop any attachment of type: pif, com, cmd, bat
2. Scan any attachment of type: exe, zip, tar, tgz, tar.gz, rar, doc, xls, pps, ppt
   1. Drop it if it contains a virus
   2. Accept it if it didn't contained a virus
   3. Save it in quarantine in case of an error.
   
   
   
   

The default policy is to accept attachments.

This policy is quite lax, that's what I wanted, you may want to make your policy more strict.

Here's the Sanitizer configuration (/etc/sanitizer.conf) file that I'm using.

#
# All feature switches.
#
header_info         = X-Virus-Scanned: Scanned by Sanitizer/ClamAV
header_url          = 0      # Don't show the Mailtools URL
feat_verbose        = 0      # Warn user about unscanned parts, etc.
feat_log_inline     = 1      # Inline logs: 0 = Off, 1 =  Maybe, 2 = Force
feat_log_stderr     = 0      # Don't print log to standard error
feat_log_xml        = 0      # Don't use XML format for logs.
feat_log_trace      = 0      # Omit trace info from logs.
feat_log_after      = 0      # Don't add any scratch space to part headers.
feat_files          = 1      # Enable filename-based policy decisions.
feat_force_name     = 0      # Dont't force all parts (except text/html parts) to
                             # have file names.
feat_boundaries     = 0      # Don't replace all boundary strings with our own
                             # NOTE:  Always breaks PGP/MIME messages!
feat_lengths        = 1      # Protect against buffer overflows and null
                             # values.
feat_scripts        = 1      # Defang incoming shell scripts.
feat_html           = 1      # Defang active HTML content.
feat_webbugs        = 1      # Web-bugs are allowed.
feat_trust_pgp      = 0      # Don't scan PGP signed message parts.
feat_uuencoded      = 1      # Sanitize inline uuencoded files.
feat_forwards       = 1      # Sanitize forwarded messages
feat_testing        = 0      # This isn't a test-case configuration.
feat_fixmime        = 1      # Fix invalid MIME, if possible.
feat_paranoid       = 0      # Don't be excessively paranoid about MIME headers



# Create temporary or saved files using this template.

# An attachment named "dude.txt" might be saved as

#

#  /var/quarantine/att-dude-txt.A9Y

# 

# Note:  The directory must exist and be writable by

# the user running the sanitizer.                 

#

file_name_tpl = /var/quarantine/att-$F.$$$                 

#

# Policies

#

# We have two policies, in addition to the default which is

# to accept attachments.

file_list_rules = 2

file_default_policy = accept

file_default_filename = unnamed.file

# Policy num. 1

# Delete obviously executable attachments.  This list is VERY  

# incomplete!  This is a perl regular expression, see "man   

# perlre" for info.  The (?i) prefix makes the regexp case     

# insensitive.

#

# There is only one policy, since we aren't using an external

# scanner.

#

file_list_1  = (?i)\.(pif|com|cmd|bat)$               

file_list_1_policy = drop

file_list_1_scanner = 0

# Policy num. 2

# Scan all files for Viruses, using clamscan

# Always define FOUR potential policies, which depend on the

# exit code returned by the scanner.  Which code means what is

# defined in the scanner line, which must contain THREE entries.

# The fourth policy is used for "anything else".

#

#   "accept" if the file is clean (exit status 0)                  

#   "mangle" if the file was dirty, but is now clean (clamav doesn't 

#              support file desinfection, so we use the fictive exit status 66)

#   "drop"   if the file is still dirty (exit status 1)

#   "save"   if clamscan returns some other exit code or an error occurs.

#

file_list_2 = (?i)\.(exe|zip|tar|tgz|tar\.gz|rar|doc|xls|pps|ppt)$

file_list_2_policy = accept:mangle:drop:save

file_list_2_scanner = 0:66:1:/usr/bin/clamscan --recursive --unzip --unrar --tar --tgz %FILENAME

I believe that the syntax of policy 2 needs a little explanation. The first argument (file_list_2) states which files should be processed by this policy. The second (file_list_2_policy) and third (file_list_2_scanner) arguments are interdependent. The second argument specifies what to do with the attachment depending on what the virus scanner exit code is. As you can see, in this configuration, if clamscan returns 0 we accept the attachment; if it returns 66 we will mangle the attachment; if it returns 1 we drop the attachment and it if returns something else we save the attachment in quarantine.

Test sanitizer

I created an email message containing a fake virus signature to test sanitizer. Save this file and pass it through sanitizer using the following command.

sanitizer /etc/sanitizer.conf < fake-email-virus.txt > fake-email-sane.txt 

The infected attachment should be replaced by the following text in the sane version.

NOTE:  An attachment was deleted from this part of the message,

because it failed one or more checks by the virus scanning system.

See the attached sanitization log for more details or contact your

system administrator.


The removed attachment's name was:

        test1.doc

        

It might be a good idea to contact the sender and warn them that

their system is infected.

If you get similar results, this means that Sanitizer is properly configured. Congratulations! Only one thing left, tell procmail to use sanitizer.

Configuring procmail to use sanitizer

Add this on the top of your .procmailrc file.

:0fw:
| /usr/bin/sanitizer /etc/sanitizer.conf

Since it is pretty short, let me explain what it does.

The first line. The :0 marks the beginning of a new rule. The f means that this rule is a filter. The w tells procmail to wait for sanitizer to finish. The last colon tells procmail to use a lockfile to insure that only one message will be processed at a time. This is important to use a lockfile because otherwise, if you were to receive a batch of several emails at once, procmail would process all these emails in parallel and effectively making a Denial of Service Attack on the system. Believe me, I learned that the hard way! ;-)

The second line is more simple, the pipe (|) means that the message should be directed to the standard input of sanitizer. Then we have the path to sanitizer and to its configuration.

That's it, you now have simple virus scanner attached to your inbox. You only need to test it to be sure that it works properly.

Test the whole thing

To test your new configuration, you fire up your favorite mailer program and send yourself three emails: one containing only text (no attachment), one containing a non-infected attachment and one containing one of the clamav-testfiles as attachment. Make sure that you receive these emails and that they are modified according to your sanitizer configuration.

Posted by gfk at 7:25 PM | Comments (0)

novembre 8, 2004

Hand Drills and the Art of House Building

Some people seem to think that security and cryptography are the same thing. They think that adding cryptography to a product will make it secure. I used to think that, but I was wrong. When reading Secret and Lies by Bruce Schneier, I realised that cryptography can be compared to a hand drill, and that security is like building a house. That is, cryptography is a tool for security, just like a drill is a tool for building a house.

Hand Drills and the Art of House Building

Some people seem to think that security and cryptography are the same thing. They think that adding cryptography to a product will make it secure. I used to think that, but I was wrong. When reading Secret and Lies by Bruce Schneier, I realised that cryptography can be compared to a hand drill, and that security is like building a house. That is, cryptography is a tool for security, just like a drill is a tool for building a house.

Lots of so-called security courses are in fact cryptography courses, and I believe that this misconception is a big mistake; it is like giving a course about the inner workings of a drill and calling it House Building 101, it doesn't make sense. Worse is that people following this course will think that they're able to build a house, and will end up building a crappy house. You won't be able to make a secure program if you think that cryptography in the only thing needed for security.

In fact, when building a house, you don't even need to understand how a drill works, you only need to know how to use it, the different kinds of drills and when you should or not use them. Again, this is the same for cryptography, you don't need to know the implementations differences between RSA or DH, but you need to know that DH does its key exchange during the transaction while RSA can store its public key in a file for later distribution.

It is also possible to build a house without using a drill, it will be more or less easy depending on the kind of house, but most of the times it will be possible. Once again, this is the same thing for cryptography and security, it is perfectly possible to build a secure program without using cryptography, some kind of programs will be harder to secure without cryptography, but most of the times it will be possible.

I believe that one of the reasons why a lot of security courses focus only on cryptography is because security is hard to teach, it's almost philosophy. Exams are almost impossible to make. I understand that professors can be tempted to drop these vague security ideas and go with the solid maths: explain the RSA equations, and ask the students to encrypt and decrypt Hello World at the exam. That's easy to teach, isn't it? What sucks is that you end up with drill experts trying to build houses.

That's what I witnessed at my University in the last couple years. For quite some time now, the Computer Science department wanted to start a Software Engineering program so they provided a curriculum (list of courses) for that program. One of these courses was called Security, Pirates and Cryptography (I guess they meant hackers/crackers instead of pirates), there was no description for this course, but it looked very interesting. Last year, they got the approbation to start the program, this course is now called Cryptography and Computer Security and when you look at the description, you realise that it only talks about cryptography. Why give a complete security course when you can just drop some mathematical equations on the black board?

Please make sure that you know what you're getting when you're enrolling in a security course. Be sure to read the complete course description, if it only talks about cryptography algorithms and you're interested in security, then you don't need it. You can take it if you want to, but don't pretend to know more about security when you finish the course, you'll know more about drills, but don't hope to know the art of house building. After all, security is an art, and maybe that's why it's so hard to teach. I believe that this is not a valid reason not to teach it.

Posted by gfk at 7:32 PM | Comments (0)