Securing FreeBSD step by step (for Dummies and even Geeks)

cns at minithins.net

Last Update > 23/12/2003

> fix login.conf, huge grammatical clean up

"A physician, a civil engineer, and a computer scientist were arguing about
what was the oldest profession in the world. The physician remarked, "Well, in
the Bible, it says that God created Eve from a rib taken out of Adam. This
clearly required surgery, and so I can rightly claim that mine is the oldest
profession in the world." The civil engineer interrupted, and said, "But even
earlier in the book of Genesis, it states that God created the order of the
heavens and the earth from out of the chaos. This was the first and certainly
the most spectacular application of civil engineering. Therefore, fair doctor,
you are wrong : mine is the oldest profession in the world." The computer
scientist leaned back in her chair, smiled, and then said confidently, "Ah,
but who do you think created the chaos ?"

R�sum�

Ce paper est issu comme beaucoup d'initiatives libres d'un besoin de la part
des auteurs. Dans cet article nous souhaitons faire partager ce que nous avons
travers� afin d'obtenir une machine FreeBSD configur�e au mieux pour r�sister
a toutes sortes de menaces. C'est une sorte de compilation des connaissances
disparates dont nous avons nous m�me eu besoin. Comme le faisait remarquer
Bruce Scheiner, la s�curit� est une processus, pas un produit ; c'est pourquoi
nous tentons dans ce document d'aborder un large panel de sujets et
d'utilisations en nous basant sur la branche FreeBSD 4.x-STABLE.

1. Burn out !
1.1. services
1.2. CVSup
1.3. (re)compilation et update

2. Tuning syst�me
2.1. sysctl
2.1.1. securelevel et chflags
2.1.2. performances
2.2. gestion utilisateurs
2.2.1. adduser / rmuser / chpass / watch
2.2.2. quotas et login.conf
2.2.3. jail
2.3. int�grit�
2.4. secure shell
2.5. syslog
2.6. cron
2.7. ipfw et natd

3. Outils
3.1. TCPdump
3.2. Nessus
3.3. lsof
3.4. stack smashing
3.5. tunneling

4. Conclusion

1. burn out !
Nous allons partir du fait que vous avez r�ussi � installer correctement
FreeBSD, et que vous �tes parvenu � une connexion Internet stable. Nous ne
donnerons donc aucune indication quant � ces phases. Dans ce chapitre, nous
nous concentrerons sur la configuration de base de FreeBSD, c'est-�-dire les
premi�res mesures que vous appliquerez dans une optique de s�curit�, peu apr�s
votre installation r�ussie.

1.1. services

Inetd est un super daemon qui permet de lancer plusieurs services reseau ainsi
qu'une partie de leur configuration comme ftpd, smptd ou telnetd. Le fichier
de configuration pour inetd est conserv� dans /etc/inetd.conf. En voici un
extrait :

ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l

#shell stream tcp nowait root /usr/libexec/rshd rshd

En r�gle g�n�rale, on place le caractere '#' devant une ligne que nous ne
voulons pas afin de la mettre en commentaire. Si nous ne desirons offrir aucun
de ces services - il est preferable de supprimer cette configuration de base
laxiste afin de repartir de zero - nous pouvons retirer inetd de notre fichier
de demarrage pour augmenter encore un peu la s�curit� et la convivialit�. Si
par ailleurs vous desirez tout de meme offrir un shell distant � quelques
utilisateurs, un chapitre entier couvre la configuration du sshd d'OpenSSH.
Enfin, en �clipsant inetd, nous d�cidons d'abandonner �galement TCP Wrappers
utilis� par d�faut sous FreeBSD.

Tout d'abord il est utile de v�rifier quel service tourne en �coute sur un
port actuellement. Pour cela nous allons utiliser l'utilitaire netstat qui
affiche une liste des ports et connexions actives. Nous l'allions � grep pour
pr�ciser notre recherche.

# netstat -a | grep 'listen'

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp4 0 0 *:ssh *:* LISTEN
tcp4 0 0 *:ftp *:* LISTEN
tcp4 0 0 *:smtp *:* LISTEN
udp4 0 0 *:portmap *:* LISTEN

Comme vous le voyez nous ne croulons pas sous les services. Mais si votre
machine est destin�e � devenir un serveur avec de multiples services, je vous
recommande de suivre notre solution. Bref, sur le m�me sch�ma que pr�c�demment,
tous les services r�seau que vous voudrez proposer � l'avenir tourneront sous
la forme de stand alone daemon, c'est-�-dire des daemons autonomes augmentant
la s�curit� mais aussi simplifiant la configuration et am�liorant la rapidit�
de r�ponse des services en �liminant l'interm�diaire inetd. Pour �viter
qu'inetd ne se lance au d�marrage, nous �ditons le fichier /etc/rc.conf apr�s
avoir effectu� un rapide grep permettant de savoir si nous avons
effectivement besoin d'�diter :

# grep inetd /etc/rc.conf

inetd_enable="YES"
inetd_flags="-wW"

inetd est donc lanc� au d�marrage avec par ailleurs les options -wW signifiant
la capacit� de filtrage des services internes et externes TCP via TCP Wrappers
que nous n'utiliseront pas non plus. Donc, toujours dans rc.conf,
inetd_enable="YES" devient inetd_enable="NO" et on met inetd_flags="-wW" en
commentaire. Nous d�sactivons �galement portmapper, un outil extr�mement
pratique dans le cadre de services RPC tels que NFS mais qui pr�sentent un
nombre incalculable de vuln�rabilit�s. Nous transformons donc la ligne
portmap_enable="YES" en NO. Ainsi inetd et portmapper ne seront pas ex�cut�s
la prochaine fois que vous red�marrerez. Si vous voulez killer inetd de suite,
vous pouvez faire :

# killall inetd

Notez que c'est �galement dans rc.conf que vous pourrez configurer les
programmes ou scripts � lancer d�s le d�marrage. Selon le destin de votre
machine, �a peut �tre une bonne id�e de manipuler les champs portmap_enable,
named_enable ou sendmail_enable.

1.2 CVSup

Le meilleur moyen d'obtenir un syst�me s�curis� - en plus du fait d'avoir une

configuration b�tonn�e et de conna�tre FreeBSD sur le bout des doigts bien s�r
- reste de conserver les sources syst�me et l'arborescence des ports � jour.
Ainsi d�s qu'une vuln�rabilit� ou un quelconque probl�me appara�t au sein du
syst�me ou encore qu'une nouvelle release ou plut�t qu'une nouvelle version
stable est sortie, vous maintenez votre syst�me � jour et donc prot�g� au
mieux. Une bonne id�e cons�cutive � l'update de votre syst�me consiste �
s'abonner a la liste freebsd-security afin d'�tre tenu au courant des
derniers patchs. Notez �galement la liste freebsd-questions en fran�ais utile
� tous les utilisateurs francophones. Consultez les pages suivantes :

http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications

http://www.freebsd-fr.org/local-fr/www/spec/support/liste_diffusion.html

Maintenant nous allons voir un aspect extr�mement s�duisant de la famille

*BSD : la mise � jour compl�te du syst�me par le net. Pour cela nous
utiliserons tout d'abord un utilitaire nomme CVSup. Il permet l'update simple
de collections de fichiers � travers un r�seau. Il peut efficacement et
pr�cis�ment mirrorer tous types de fichiers incluant sources, binaires, hard
links, symlinks, et m�me des noeuds de p�riph�riques. Le protocole de
communication en streaming et l'architecture multithreads font tr�s
probablement de lui l'outil de mirroring le plus performant existant � ce
jour. En plus de toutes ces qualit�s, CVSup inclut des usages et des
optimisations sp�cifiquement con�ues en fonction des repositories CVS. En
d'autres termes, CVSup se relie � la base de donn�es principale de code
source FreeBSD et met � jour les fichiers source qui ont �t� modifi�. Nous
effectuons donc un simple :

# cd /usr/ports/net/cvsup-bin && make install clean

en tant que root afin d'installer cet utilitaire.

Nous devons maintenant editer le cvs-upfile duquel cvsup recevra ses
directives pour l'update.

# mkdir /usr/share/cvsup/
# cp /usr/share/examples/cvsup/ports-supfile /usr/share/cvsup/
# cp /usr/share/examples/cvsup/doc-supfile /usr/share/cvsup/
# cp /usr/share/examples/cvsup/cvs-supfile /usr/share/cvsup/
# ee /usr/share/cvsup/cvs-supfile

------------------------------------ SNiP -------------------------------------

# nous allons rentrer une s�rie de param�tres par d�faut que nous utiliserons
# a chaque invocation de cvsup.

# nous rentrons ici le serveurs cvsup que nous voulons utiliser. Vous pouvez
# en choisir sur la liste presente sur
# http://www.freebsd.org/handbook/mirrors.html
*default host=cvsup.fr.FreeBSD.org

# ici nous informons cvsup du repertoire ou stocker les fichiers transferes

# plus quelques autres informations notamment celle de faire le menage apres
# download ou encore quel version nous desirons obtenir grace au champ Tag qui
# peut correspondre aussi bien a la version stable que current ou une version
# precedente. Enfin nous activons la compression de part notre faible bande
# passante.
*default base=/usr
*default prefix=/dist
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
*default compress

# ici nous decidons de mettre a jour l'ensemble de l'arborescence.

# Notez que les sources des programmes soumis a des limitations d'exportation
# (crypto) ne seront pas mis a jour.
src-all
------------------------------------ SNiP -------------------------------------

Pareil pour les ports ...

------------------------------------ SNiP -------------------------------------

# nous devons maintenant selectionner les ports que nous desirons mettre a jour.
# La collection de ports FreeBSD vous offre une multitude de programmes simples
# a installer et optimiser pour FreeBSD, cependant certains vous paraitront
# d'une utilite douteuse d'ou notre choix au cas par cas et la mise en
# commentaire de : ports-all

#ports-archivers
#ports-astro
ports-audio
ports-base
#ports-benchmarks
#ports-biology
#ports-cad
#ports-chinese
#ports-comms
#ports-converters
ports-databases
ports-deskutils
ports-devel
ports-editors
ports-emulators
ports-ftp
ports-french
#ports-games
#ports-german
ports-graphics
ports-irc
#ports-japanese
ports-java
#ports-korean
ports-lang
ports-mail
#ports-math
#ports-mbone
ports-misc
ports-net
ports-news
ports-palm
ports-picobsd
ports-print
#ports-russian
ports-security
ports-shells
ports-sysutils
ports-textproc
#ports-vietnamese
ports-www
# et on ne sait jamais, des fois que l'appel du graphisme soit trop fort...
ports-x11
ports-x11-clocks
ports-x11-fm
ports-x11-fonts
ports-x11-servers
ports-x11-toolkits
ports-x11-wm
------------------------------------ SNiP -------------------------------------

... puis la doc.

------------------------------------ SNiP -------------------------------------

# pour finir nous decidons de profiter de l'excellent travail de documentation
# issu du FreeBSD Documentation Project qui comporte notamment le FreeBSD
# handbook, veritable bible de cet OS et m�me traduit en francais :)
doc-all
------------------------------------ SNiP -------------------------------------

Nous en profitons �galement pour �diter le fichier /etc/make.conf afin de nous

assurer de la presence de certaines variables.

# cp /etc/default/make.conf /etc/
# ee /etc/make.conf

------------------------------------ SNiP -------------------------------------

INSTALL=install -C -S -s

PPP_NOSUID= true
ENABLE_SUID_SSH= true
ENABLE_SUID_NEWGRP= true

NO_FORTRAN= true # do not build g77 and related libraries

NO_I4B= true # do not build isdn4bsd package
NO_IPFILTER= true # do not build IP Filter package
NO_KERBEROS= true # do not build and install Kerberos 5 (KTH Heimdal)
NO_OBJC= true # do not build Objective C support
NO_SENDMAIL= true # do not build sendmail and related programs
NOGAMES= true # do not build games (games/ subdir)

COMPAT1X= no
COMPAT20= yes
COMPAT21= yes
COMPAT22= yes
COMPAT3X= yes

MAKE_RSAINTL= yes # RSA (public key exchange)

USA_RESIDENT= no

SUP_UPDATE= yes
SUP= /usr/local/bin/cvsup
SUPFLAGS= -g -L 2
SUPFILE= /usr/share/cvsup/cvs-supfile
PORTSSUPFILE= /usr/share/cvsup/ports-supfile
DOCSUPFILE= /usr/share/cvsup/doc-supfile
------------------------------------ SNiP -------------------------------------

Vous pouvez vous amuser avec les nombreux exemples de supfile et de refuse
disponibles dans le r�pertoire examples, puis, une fois votre param�trage
effectu�, il ne vous reste plus qu'� lancer une update :

# cd /usr/src && make update

Notez bien que la totalit� du syst�me est mis � jour (ou tout du moins les
sources si NO_DOCUPDATE et NO_PORTSUPDATE sont mis � "yes"). SUPFILE,
DOCSUPFILE et PORTSSUPFILE permet simplement de filtrer les modules qui
seront mis � jour pour les sources, la documentation et le ports tree,
respectivement.

1.3. (re)compilation et update

Maintenant que nous avons une arborescence des sources et de la port collection
correctement mis � jour, il ne nous reste plus (sic) qu'� 'construire' cette
arborescence.

Tout d'abord nous allons r�ellement construire l'ensemble des sources de notre
systeme de base :

# cd /usr/src && make buildworld

Cette op�ration assez importante peut durer plusieurs heures. Sur un Celeron
400, il aura fallu un peu plus d'une heure et demie. Bref le nombre de verres
que vous prendrez d�pendra de la puissance de votre machine.

Nous nous attelons maintenant � la configuration et la compilation du kernel.

Pour les configurations ult�rieures et des performances optimales, nous vous
recommandons de s�lectionner les options suivantes dans votre fichier de
configuration kernel situ� dans le r�pertoire /sys/votre_architecture/conf.
Afin de pouvoir toujours revenir en arri�re avec une configuration
fonctionnelle, nous �diterons une copie de GENERIC, � partir de laquelle nous
compilerons.

# cd /sys/i386/conf && cp GENERIC LSD

# ee LSD

------------------------------------ SNiP -------------------------------------

options INET
options INET6
options IPSEC
options IPSEC_ESP
options IPSEC_FILTERGIF
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=30
options IPFIREWALL_FORWARD
options IPSTEALTH
options BRIDGE
options IPDIVERT
options DUMMYNET
#options IPFIREWALL_DEFAULT_TO_ACCEPT
options ACCEPT_FILTER_DATA
options ACCEPT_FILTER_HTTP

options NETGRAPH
options NETGRAPH_ONE2MANY
options NETGRAPH_PPPOE
options NETGRAPH_HOLE
options NETGRAPH_ECHO
options NETGRAPH_TEE
options NETGRAPH_TTY
options NETGRAPH_ASYNC
options NETGRAPH_INTERFACE

options TCP_DROP_SYNFIN
options ICMP_BANDLIM
options RANDOM_IP_ID
options SC_DISABLE_DDBKEY
options SC_DISABLE_REBOOT
options SC_NO_HISTORY
options NO_LKM
options NO_KLD

options QUOTA
options SOFTUPDATES
options UFS_DIRHASH
options COMPAT_LINUX
options DDB
options DEVICE_POLLING

maxusers 0
options HZ=1000
options NMBCLUSTERS=32768

pseudo-device snp 4
# high because of all the security tools
pseudo-device bpf 10
# high because of IPSec
pseudo-device gif 10
pseudo-device faith 1
pseudo-device stf 1
------------------------------------ SNiP -------------------------------------

Dans l'ordre, nous s�lectionnons le support IPv4, IPv6, IPSEC et ESP. Puis nous
activons le support IPFW (que vous pouvez d�cider de remplacer par IPFilter non
trait� dans cet article) avec l'envoi des messages � syslog limit� � 30 fois la
m�me occurrence. Nous aurons eu soin avant cela de permettre � IPFW de filtrer
les paquets encapsul�s avec IPSEC et transitant via des interfaces gif, tout
ceci depuis FreeBSD 4.9. Le forwarding est aussi activ� ainsi que le forwarding
cach� (passant un paquet sans d�cro�tre son TTL), tout comme les divert sockets
permettant de modifier le transit d'un paquet dans le kernel ; et enfin le
support de dummynet, le traffic shaper basique du syst�me. Nous activons ensuite
les accept filters qui acc�l�re le processus d'admission de certains types de
connexions (comme HTTP) en les pla�ant directement dans le kernel. Notez que
mi-2002, Luigi Rizzo a totalement r��crit les m�canismes internes d'ipfw afin
d'en doubler la vitesse et de le rendre facilement extensible via un jeu de
microinstructions similaires � BPF. Ce code a �t� backport� sur stable et se
trouve totalement compatible avec vos rulesets. Bien qu'encore non document�,
vous pouvez l'activer en pla�ant l'option IPFW2 dans votre configuration.

Apr�s cela, nous activons la cohorte de noeuds du sous-syst�me NetGraph qui

permet des manipulations complexes au niveau r�seau � l'aide de nodes h�ritant
des particularit�s de leur type (hooks possibles, traitement du trafic � chaque
hook, interpr�tation des messages de contr�le...) qui peuvent �tre cha�n�s �
travers des hooks pour constituer une suite d'edges : un graphe. Plus
d'informations et la descriptions des nodes dans la manpage netgraph(4).

Nous encha�nons avec quelques s�curit�s r�seau, d'abord, comme le rejet de

certains paquets forg�s (SYN/FIN) permettant la reconnaissance d'OS, la
limitation, via sysctl, d'�mission de paquets ICMP afin de ne pas servir de
r�flecteur lors d'un DoS, et la g�n�ration al�atoire des IP ID pour r�duire les
opportunit�s de scanning. Puis s�curit� physique avec la d�sactivation des
s�quences clavier de debugging et de red�marrage, ainsi que la d�sactivation du
backscrolling pour les terminaux virtuels. Enfin, s�curit� syst�me avec la
d�sactivation des LKM ; et m�me des KLD si vous appliquez le patch suivant
http://people.freebsd.org/~cjc/kld_stable.patch.

Suivent l'activation des quotas disque, du code de compatibilit� Linux via

l'�mulation de certains appels syst�me et du debugger kernel DDB. Nous
v�rifions aussi l'activation des SoftUpdates, m�thode d'�criture et de lecture
asynchrone r�solvant les probl�mes li�s aux metadata et � leur perte.
L'approche de Linux est la journalisation (concept h�rit� des base de donn�es)
qui consiste � �crire les mises � jour de metadata avec leurs d�pendances dans
une partie distincte du syst�me de fichier : le journal. Quand les metadata
sont pr�tes, elles sont effectivement �crites. Le syst�me de fichiers de
FreeBSD nomm� UFS utilise une approche diff�rente (inspir�e de CVS) dans
laquelle les op�rations d'�criture ou de lecture sont plac�es dans une file
d'attente divis�e en un buffer d'attente et un buffer de v�rification des
d�pendances. Si un bloc appartient � une boucle de d�pendances, il est rejet�
dans le buffer d'attente. Cette approche permettra de plus � l'avenir des
red�marrage suite � un crash avec un fsck fonctionnant en t�che de fond.
Pour de plus amples explications, voir http://www.di.ens.fr/~pornin/jfs.html.
Toujours au niveau syst�me, vous appr�cierez le device polling permettant
d'am�liorer les performances kernel en limitant les interruptions et donc le
changement de contexte et l'appel � un gestionnaire d'interruption. A la place,
les p�riph�riques sont sond�s aux moments opportuns comme les interruptions
d'horloge, les appels syst�me ou pendant les p�riodes de non-activit�.

Notez enfin que le nombres maximal d'utilisateurs est plac� � 0 pour qu'il soit
calcul� au moment du boot en fonction de la m�moire physique disponible. Cette
variable ainsi que le nombre de clusters du syst�me de fichiers sont utilis�es
pour calculer l'allocation de certaines ressources m�moire. La fr�quence
d'horloge est ensuite plac�e � 1000 Hz pour augmenter l'acuit� du device
polling (et aussi limiter les burst si vous utilisez ALTQ). Viennent enfin les
pseudo-devices snoop et bpf pour la surveillance respective des tty et des
trames ethernet, et gif, faith et stf pour le tunneling v6/v4.

Certaines options seront d�j� pr�sentes, nous ne faisons que les v�rifier. Vous
pouvez �galement r�fl�chir � mettre en commentaire le support procfs et NFS qui
peuvent cr�er d'�ventuelles vuln�rabilit�s dans le syst�me, � moins bien s�r
que vous n'en ayez besoin. Pour examiner l'ensemble des options kernel
disponibles, r�f�rez vous au fichier LINT dans le m�me r�pertoire que GENERIC.

Par la s�quence de commandes suivantes, nous construisons successivement le

kernel LSD puis nous l'installons et enfin nous le prot�geons � l'aide des
flags immutables tout en nettoyant le syst�me des fichiers g�n�r�s par
l'install.

# cd /usr/src && make buildkernel KERNCONF=LSD && make installkernel \

KERNCONF=LSD && make clean

Nous en avons fini avec la premi�re partie de la recompilation compl�te du

syst�me. Le syst�me mis � jour est d�sormais fin pr�t � �tre install�.
Cependant pour plus de s�ret� il est recommand� d'effectuer la suite des
op�rations en single-user mode. Pour ce faire au moment du prompt annon�ant le
boot, pressez la barre d'espace pour entrer dans le menu de boot puis tapez
'boot -s'. Cette manoeuvre est recommand�e pour chaque mise � jour ou
manipulation entra�nant une reconstruction g�n�rale du syst�me.

# reboot

La commande suivante installe donc l'ensemble du syst�me de base mis � jour.

Le buildworld pr�c�dent correspondait � la compilation des sources (d'o� sa
dur�e) tandis qu'ici nous nous contentons d'installer les binaires g�n�r�s
(d'o� une moindre attente).

# cd /usr/src && make installworld

Nous appliquons ensuite le script mergemaster, tr�s pratique puisqu'il

effectue une comparaison entre les anciens fichiers de configuration et ceux
par d�faut de l'installation. Tout cela afin de mettre � jour la configuration
du nouveau syst�me et nous �viter de recommencer un travail fastidieux.

# cd /usr/src/usr.sbin/mergemaster
# ./mergemaster -sv -D /etc/

Voil�, le syst�me est fin pr�t pour attaquer sa r�elle configuration. Nous
red�marrons une nouvelle fois afin de repasser en multiuser mode.

# reboot

Reportez-vous au handbook en cas de probl�mes :

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html.

2. Tuning Syst�me

Maintenant que notre syst�me est comme neuf et on ne peut plus � jour, il ne
nous reste plus qu'� entamer sa r�elle s�curisation. Pour cela nous allons
d'abord voir ce que nous pouvons faire par d�faut avec le syst�me de base afin
d'augmenter la s�curit� de notre syst�me et de limiter se fen�tre d'exposition
aux attaques.

2.1. sysctl

Sysctl est un outil extr�mement pratique au sein de FreeBSD puisqu'il va nous

permettre de v�rifier ou de manipuler l'�tat du kernel � chaud. Les
informations sont stock�es et affich�es � travers une Management Information
Base ou MIB selon le m�me mod�le que SNMP. Par exemple pour afficher une liste
des diff�rentes variables d'�tat kernel, il vous suffit d'effectuer un simple
# sysctl -a

de la m�me mani�re que vous utiliseriez un ls. Notez que vous pouvez pr�ciser
l'entr�e de la MIB si vous la connaissez juste apr�s l'option afin de
n'afficher qu'elle. Suivant le principe des MIB, vous pouvez r�duire
l'affichage en pr�cisant un champ de la MIB. Par exemple pour afficher toutes
les entr�es en rapport avec IP

# sysctl net.inet.ip.*

Notez aussi que certaines variables ne sont pas modifiables et que certaines
entr�es de la MIB sont sous forme de tableaux utilis�s � l'occasion par ps,
netsat ou systat. Enfin, pour obtenir une liste des variables sysctl que vous
pouvez modifier, consultez la page de manuel de sysctl.

2.1.1. securelevel et chflags

L'une des fonctionnalit�s int�ressantes de FreeBSD consiste en l'�tablissement

de secure level au sein du syst�me. Il existe ainsi 5 niveaux de s�curit� au
sein de FreeBSD qui ne peuvent pas �tre diminu�s sans relancer init. Ils
peuvent cependant �tre augment�s par un processus root via la MIB sysctl, et
ce m�me en cours d'ex�cution.

Pour d�finir le securelevel mis en place par init, modifiez les lignes
suivantes dans rc.conf :

kern_securelevel_enable="YES"
kern_securelevel="N"

N repr�sente ici l'entier correspondant � l'un des 5 entiers possibles.

Remplacez-le par le niveau qui vous convient. Puis si vous souhaitez l'�lever
une fois votre syst�me initialis�, modifiez l'entr�e sysctl suivante :

# sysctl -w kern.securelevel=N

Outre des limitations inscrites dans le code kernel, donc inchangeable, propres
� chacun d'eux, chaque level d�finit �galement les op�rations possibles sur des
file flags, attributs de fichiers permettant d'am�liorer la s�curit� fournie
par les classiques permissions Unix. Ci-dessous, les 5 niveaux et leurs
limitations :

- -1 qui instaure le mode insecure (0) de mani�re permanente. C'est la valeur

par d�faut.
- 0 indique le mode insecure dans lequel les files flags 'immutable' et
'system append only' peuvent �tre retir�s et o� l'on peut effectuer des
op�rations de lecture/�criture sur tous les p�riph�riques avec pour seule
restriction les droits d�j� instaur�s, par exemple, dans la fstab.
- 1 indique nous sommes en secure mode dans lequel les flags 'system immutable'
et 'system append only' ne peuvent �tre d�sactiv�s. L'acc�s � /dev/mem et
/dev/kmem est interdit en �criture et les KLD ne peuvent plus �tre charg�s ou
d�charg�s.
- 2 instaure le highly secure mode qui est strictement le m�me que le secure
mode � la diff�rence pr�s que les seules op�rations d�sormais effectu�es sur
les disques sont le montage et d�montage.
- 3 signifie l'instauration du network secure mode qui est similaire au level
pr�c�dent avec en plus l'impossibilit� de modifier les r�gles ipfw ou la
configuration du traffic shaper bas� sur ipfw dummynet.
Pour une station de travail, l'utilisation devient probl�matique d�s le
securelevel 1. Par exemple, XFree86 peut n�cessiter l'acc�s � /dev/mem alors
que cela lui est interdit. Les niveaux suivants sont adapt�s � des serveurs, et
le dernier est plus particuli�rement destin� � une passerelle. Notez le niveau
2, tr�s restrictif, qui force l'acc�s des disques en read-only. A ce niveau,
m�me un serveur risque de se voir perturb� par les securelevel, encore plus
s�il n�cessite des compilations ou modifications de configuration r�guli�res.
Notez que le niveau prot�ge tr�s bien de la plupart des backdoors bas�es sur
des modules kernel. Il pourrait cependant �tre judicieusement de remplacer ou
d'ajouter l'option kernel NO_LKM.

Pour param�trer les file flags sur vos fichiers en fonction de ces levels, il
vous faudra utiliser la commande chflags. Les flags disponibles sont list�s
ci-apr�s.

- arch, uniquement utilisable par root, transforme le fichier en archive.

- opaque, rend le fichier "opaque" � certaine lecture (utile contre la lecture
par d'autres applications) et modifiable uniquement par l'owner ou le root.
- nodump, permet d'interdire un backup du fichier via l'utilitaire dump.
Modifiable uniquement par le owner ou le root.
- sappnd, instaure le flag system append-only uniquement modifiable par le root
en securelevel sup�rieur � 0. Append signifie qu'on ne peut que rajouter des
donn�es et non en retirer.
- schg place le flag system immutable qui, comme son nom l'indique, est cens�
emp�cher toute �v�nement. Modifiable par le root uniquement en niveau 0.
- sunlnk permet d'interdire la suppression d'un fichier, sachant que cette
option n'est modifiable que par le root
- uappnd, uchg et uunlnk sont les pendant respectifs de sappnd, schg et sunlnk.
La diff�rence r�side dans le fait que, outre le root, le owner du fichier a
�galement le droit de modifier les file flags.

La syntaxe pourra par exemple �tre la suivante :

# chflags -RH schg /bin

# chflags -RH schg /sbin
# chflags -RH schg /usr/libexec
# chflags -RH schg /usr/lib
# chflags -RH schg /usr/share/lib
# chflags -RH schg /boot
# chflags -RH sappnd /var/log/*
# chflags -RH sappnd /home/*/.*history
# chflags schg /kernel

Notez qu'en effectuant un man chflags, vous d�couvrez les quelques options -
notamment la r�cursivit� - que propose cette commande. Pour retirer un file
flag ce sont les m�mes options avec le prefix no tel que nosappnd. Les file
flags sont int�ressants � placer sur certains fichiers sensibles pr�cis ou
alors carr�ment sur un r�pertoire dont vous souhaitez vous assurer de
l'int�grit� et qui sera rarement modifi�. Dans l'exemple, R et H permettent de
suivre les liens symboliques et ce r�cursivement, la commande �tant appliqu�e �
des r�pertoires entiers de binaires.

Dernier d�tail qui n'a pas grand chose � voir avec sysctl mais qui importe
beaucoup dans la gestion des droits et des fichiers. Vous avez le loisir de
modifier la fstab afin de monter vos diverses partitions avec certaines
options. Sous FreeBSD, au lieu de ne cr�er qu'une unique partition root /, le
syst�me cr�e simultan�ment une partition /usr et /var. Vous pouvez d�finir dans
votre fstab pour l'ensemble de vos syst�mes de fichiers :
- les droits d'�criture avec l'option rw pour read-write, ou ro pour read-only.
- les droits d'ex�cution avec l'option noexec.
- les privil�ges accord�s avec l'option nosuid.

# ee /etc/fstab

#device mountpoint fs options dump pass

/dev/ad0s2b none swap sw 0 0
/dev/ad0s2a / ufs rw 2 2
/dev/ad0s2f /usr ufs rw,nodev 2 2
/dev/ad0s2c /home ufs rw,nosuid,nodev,userquota 2 1
/dev/ad0s2e /var ufs rw,noexec,nosuid,nodev 2 2
/dev/acd0c /cdrom cd9660 ro,noauto 0

Nous limitons ici l'ex�cution dans /var afin d'�viter qu'un intrus tente d'y
placer des binaires et nous limitons la pr�sence de binaires suid ou de devices
dans les autres r�pertoires majeurs.

Notez au passage que les soft updates que nous avons mis en place dans notre
configuration kernel ne s'activent pas via la fstab mais gr�ce � l'utilitaire
tunefs qui modifie directement, et de mani�re persistante, l'ent�te du syst�me
de fichier. Pour effectivement activer ces soft updates, suivez la ligne
suivante :

# tunefs -n enable /usr

# tunefs -n enable /home

Remplacez alors enable par disable pour d�sactiver cette option.

2.1.3. Performances

Sysctl peut �galement nous apporter une aide pr�cieuse dans la configuration
syst�me et r�seau � des fins de performances �lev�es. Il va ainsi nous
permettre d'activer certaines capacit�s r�seau que supporte parfaitement la
pile TCP/IP BSD - qui est cela dit en passant certainement la plus stable, la
plus performante et la plus standard des piles TCP/IP - mais qui ne sont pas
activ�es par d�faut.

La premi�re entr�e int�ressante est l'option log_in_vain qui va loguer �

travers une simple entr�e dans le fichier de log correspondant de syslogd,
toute tentative d'acc�s � un service m�me si aucun service n'est � l'�coute sur
le port de la tentative d'acc�s. Ceci peut nous permettre dans un environnement
s�curis�, alli� de pr�f�rence avec un outil d'analyse de log tel que logcheck
ou ASAX, de rep�rer des tentatives de network mapping m�me si nous avons un
minimum de services disponibles et qui plus est un firewall. Cependant je ferai
remarquer 2 difficult�s : tout d'abord log_in_vain ne logue en r�alit� que les
paquets avec un flag SYN, ce qui n'est pas assez pour r�ellement d�tecter un
scan. Et d'autre part, dans un environnement "chaud" comme une machine servant
de passerelle ou un serveur au sein d'une DMZ, l'utilisation de log_in_vain
peut entra�ner une quantit� de log assez impressionnante et capable d'occuper un
analyste ou un administrateur sans outils d'analyse pendant des semaines. Mais
au sein d'un r�seau d'hors et d�j� s�curis� ou sur une machine critique, cette
capacit� de log peut �tre int�ressante. Pour l'activer, il vous suffit de saisir :

# sysctl -w net.inet.tcp.log_in_vain=1
# sysctl -w net.inet.udp.log_in_vain=1

Les astuces suivantes sont int�ressantes si votre machine doit servir de

passerelle, de filtre ou de load balancer pour d'autres machines. La commande
suivante vous offre la possibilit� d'activer le forwarding IP et donc de
transformer notre machine en gateway ce qui s'av�rera utile pour le partage de
connexion ou le d�ploiement d'une jail. Vous pouvez lui adjoindre l'entr�e
fastforwarding qui active un syst�me de cache des routes menant � des adresses
externes au r�seau local. L'int�r�t est de contourner de cette mani�re
l'inspection par la couche IP pour obtenir un passage direct des trames entre
les niveaux 2 des interfaces de la passerelle.

# sysctl -w net.inet.ip.forwarding=1
# sysctl -w net.inet.fastforwarding=1

Les entr�es suivantes sont particuli�rement utiles dans le cadre d'un serveur
qui n�cessit� une haute disponibilit� ou une grande fiabilit�. En effet, nous
allons apporter � notre machine le support des extensions TCP pour hautes
performances. Ces extensions sont d�crites dans la RFC 1323 que je vous
recommande d'�tudier. Elles sont constitu�es de 3 extensions. La premi�re est
le champ Window Scale qui est un facteur appliqu� au champ Window Size et utile
sur les Large Fat Network (LFN) afin d'optimiser le flux de donnees sur ces
grands reseaux et d'apporter un meilleur contr�le en multipliant la Window
Size. Nous trouvons ensuite 2 options extr�mement utiles dans le cas
d'utilisation de load balancing en fournissant des informations aux algorithmes
de r�partition de charge. Le Round-Trip Time Mesurement (RTTM) et le Protection
Against Wrapper Sequence Numbers (PAWS) se basent tous les 2 sur l'adjonction
d'une option de timestamp aux segments TCP. Avec de simples v�rifications de
timestamp on peut ainsi calculer le temps d'aller retour entre 2 ACK et ainsi
optimiser le flux ou modifier la route. On peut �galement se pr�venir du
hijacking, de l'overlapping et surtout du rejeu en effectuant une double
v�rification sur le num�ro de s�quence et le timestamp. Ces options viennent
s'ajouter � la suite d'algorithmes NewReno, �volution de la pile Reno,
permettant de d�tecter et corriger une congestion dans le r�seau en jouant sur
la perte de paquets, les d�lais et les tailles de fen�tre TCP. L'unique b�mol
est que ces options ne fonctionnent bien s�r qu'entre des machines les
supportant toutes les 2 de mani�re similaire, or elles ne semblent pas �tre
tr�s utilis�es - notez que la branche 4.x supporte la RFC 1323 par d�faut
depuis la release 4.4 - et enfin vous pourriez risquer des d�sagr�ments face �
certains firewalls ou plugins de normalisation de trafic s'ils ne reconnaissent
pas ces options. Cependant nous d�cidons de l'aborder dans cet article afin de
faciliter sa diffusion et nous l'appliquons � notre syst�me par acquis de
conscience ! Vous trouverez ensuite une entr�e r�cente qui force FreeBSD �
calculer, pour chaque connexion TCP, la quantit� de donn�es en cours de
transmission dans le r�seau (� partir du produit delay*bw), afin de limiter
l'envoi de paquets � m�me d'entra�ner une surcharge non pertinente des routeurs
et/ou switchs pr�sent sur la route. Cette configuration rapproche alors le
comportement de FreeBSD de la suite d'algorithmes TCP Vegas. Nous n'avons plus
ensuite qu'� augmenter les tailles par d�faut de nos buffers d'envoi et de
r�ception (aussi bien pour TCP que pour UDP), qui ont une influence directe sur
le champ TCP window size. Du fait de l'influence possible de ces valeurs sur le
d�lai, il est recommand� d'exp�rimenter plusieurs valeurs, en suivant par
exemple la r�gle wnd = bw / 8 * RTT. Par exemple, nous avons volontairement
limit� la taille des buffers pour UDP qui ne poss�de pas de m�canisme de
d�tection et �vitement de congestion et s'y trouve donc plus sensible. Nous
avons �galement attribu� des valeurs diff�rentes aux buffers d'envoi et de
r�ception pour TCP, la vitesse de download se trouvant souvent plus �lev�e que
celle d'upload (pensez aux lignes xDSL). Pour finir, les deux derni�res entr�es
sysctl indiquent de ne pas g�n�rer de paquets avec l'option source route, ni de
les accepter, cette option IP facilitant le spoofing d�j� �voqu� en faisant
remonter les paquets IP strictement par le chemin utilis� � l'aller.

Pour tout cela, il vous suffit d'effectuer les commandes suivantes :

# sysctl -w net.inet.tcp.rfc1323=1
# sysctl -w net.inet.tcp.newreno=1
# sysctl -w net.inet.tcp.inflight_enable=1
# sysctl -w net.inet.tcp.inflight_min=6144
# sysctl -w net.inet.tcp.sendspace=32768
# sysctl -w net.inet.tcp.recvspace=65535
# sysctl -w net.inet.udp.sendspace=32768
# sysctl -w net.inet.udp.recvspace=32768
# sysctl -w net.inet.udp.maxdgram=28672
# sysctl -w net.inet.ip.sourceroute=0
# sysctl -w net.inet.ip.accept_sourceroute=0

Ensuite, nous activons l'impl�mentation de la RFC 1948 appliquant la

recommandation de Steve Bellovin sur la g�n�ration al�atoire d'ISN selon
l'�quation ISN = M + F(localhost,localport,remotehost,remoteport) o� M est un
timestamp. Cependant, la s�curit� de cette recommandation repose
essentiellement sur le caract�re al�atoire de la cl� secr�te et la puissance de
l'algorithme de hashage. En effet, l'�tude de Michal Zalewski
(http://razor.bindview.com/publish/papers/tcpseq.html), concernant
l'utilisation des attracteurs �tranges � des fins de construction de spoofing
sets r�pondant au probl�me de pr�diction d'ISN TCP de mani�re aveugle, a
d�montr� qu'avec la libert� laiss�e par la recommandation de ne g�n�rer une cl�
secr�te qu'au d�marrage seulement et avec la r�utilisation des adresses IPv4,
il est possible pour un serveur au long uptime qu'un attaquant puisse cr�er un
attracteur �trange assez large pour s'assurer d'un bon taux de r�ussite en
utilisant la m�me adresse IP source. Malgr� l'absence de d�monstrations
math�matiques pour cette �tude, nous activons la r�g�n�ration de secret � un
intervalle de 3600 secondes. Sachez que la phase de r�g�n�ration brise le
m�canismes de recyclage TIME_WAIT, permettant de purger avant les 240 secondes
r�glementaires les connexions TCP en cours de fermeture (�tat TIME_WAIT),
allouant donc des ressources un peu plus longtemps. A titre personnel je me
demande aussi de quelle mani�re le projet CBOSS a concili� l'int�gration des
syncookies dans FreeBSD � partir de la release 4.5 avec le respect de la RFC
1948. Nous rappelons enfin les diff�rentes entr�es relatives aux m�canismes de
syncookies et de syncache limitant fortement les risques li�s au SYN flood tout
en am�liorant le fonctionnement normal.

# sysctl -w net.inet.tcp.strict_rfc1948=1
# sysctl -w net.inet.tcp.isn_reseed_interval=1800
# sysctl -w net.inet.tcp.syncookies=1
# sysctl -w net.inet.tcp.syncache.hashsize=512
# sysctl -w net.inet.tcp.syncache.cachelimit=15359
# sysctl -w net.inet.tcp.syncache.bucketlimit=30
# sysctl -w net.inet.tcp.syncache.rexmtlimit=3

Nous d�cidons maintenant de nous prot�ger face � certaines tentatives de DoS

ainsi que de diverses techniques de network mapping. A l'aide des lignes
suivantes, vous pourrez donc notamment modifier la valeur de TTL par d�faut,
qui peut �tre utilis� pour identifier l'OS, ou interdire les r�ponses aux ICMP
mask reply menant � une �ventuelle cartographie r�seau, mais aussi aux ICMP
broadcast, tr�s souvent source de smurf ou DoS par amplification, et de mettre
la limite maximale de paquets ICMP en r�ponse � 200 par seconde. Pour TCP, nous
activons les delayed acknowledgments, restreignant l'inclination du syst�me �
envoyer des ACK pour chaque segment re�u. Ceci permet d'�viter le Silly Window
Syndrome (SWS) qui tend � r�duire la window size et donc d'assurer une
meilleure efficacit� (voir RFC 813, 896 et 2581). Nous activons �galement les
keepalive, segments TCP permettant de v�rifier si une transmission TCP est
toujours r�ellement active et non pas conserv�e dans un �tat artificiel (suite
� un SYN flood ou Naptha, par exemple). Vient ensuite l'activation des
blackholes consistant � emp�cher votre syst�me d'�tre scann� en ne r�pondant ni
par un RST pour TCP ni par un ICMP port unreachable pour UDP aux paquets
envoy�s sur un port ferm� et donc transformer votre syst�me en "trou noir". La
derni�re ligne n'est applicable que sur les h�tes finaux puisqu'elle induit la
v�rification � chaque arriv�e de paquets que son adresse de destination
corresponde � une adresse de l'interface de r�ception.

# sysctl -w net.inet.ip.ttl=128
# sysctl -w net.inet.icmp.maskrepl=0
# sysctl -w net.inet.icmp.bmcastecho=0
# sysctl -w net.inet.icmp.icmplim=200
# sysctl -w net.inet.tcp.delayed_ack=1
# sysctl -w net.inet.tcp.always_keepalive=1
# sysctl -w net.inet.tcp.blackhole=2
# sysctl -w net.inet.udp.blackhole=1
# sysctl -w net.inet.ip.check_interface=1

Par ailleurs nous poss�dons �galement quelques astuces afin d'�viter les
tentatives de cache poisoning en acc�l�rant le temps de rafra�chissement de la
table de routage et de la table ARP.

# sysctl -w net.inet.ip.rtexpire=60
# sysctl -w net.inet.ip.rtminexpire=10
# sysctl -w net.link.ether.inet.max_age=1200

Finissons avec quelques modifications li�es au syst�me � modifier :

# sysctl -w vfs.vmiodirenable=1
# sysctl -w kern.coredump=1
# sysctl -w kern.corefile=%N.sexfault
# sysctl -w kern.ps_showallprocs=0

La premi�re entr�e permet d'am�liorer le traitement notamment sur des larges

volumes de fichiers. Il concerne les fichiers Unix qui seront cach�s dans le
buffer cache plut�t que directement sur le disque exploitant ainsi pleinement
la m�moire virtuelle FreeBSD par ailleurs d�j� tr�s performante. Ensuite nous
d�cidons d'activer l'application savecore qui permet de conserver une trace du
core dump associ� � un kernel dans un but d'�tude apr�s un crash par exemple
afin d'en d�terminer les causes. En dernier lieu, nous faisons en sorte que
les utilisateurs ne voient que leurs propres processus et que seul le root
puisse voir l'ensemble.

Notez que nous disposons �galement de quelques fonctionnalit�s configurables

par l'interm�diaire du loader. Par exemple, si vous disposez d'un disque IDE,
la commande suivante permet d'activer le cache en �criture :

# loader set hw.ata.wc=1

Toujours dans les protections contre les DoS mais cette fois-ci c�t� ressources
plut�t que r�seau. Les entr�es suivantes de la MIB vont nous permettrent
d'abord de limiter le nombre de processus par utilisateur et le nombre fichiers
(incluant file descriptor et IPC) qu'il peut ouvrir. Nous augmentons aussi la
taille de la queue de connexions de pair avec le nombre maximal de sockets
(2 fois le maximum de connexion approximativement). de m�me que la taille
maximal des buffers pour sockets (empiriquement 8 fois la taille de
{recv,send}space). Enfin, nous augmentons �galement le nombre maximum de
fichiers. Toutes ces valeurs paraissent �lev�es, mais elles ne servent en
r�alit� qu'� l'allocation de ressources.
# sysctl -w kern.maxprocperuid=512
# sysctl -w kern.maxfilesperproc=1024
# sysctl -w kern.ipc.somaxconn=4096
# sysctl -w kern.ipc.maxsockbuf=262144
# sysctl -w kern.maxfiles=16384

Si vous disposez de disques IBM DPTA ou DTLA, vous pouvez utiliser � la place
l'entr�e hw.ata.tags mais � vos risques et p�rils puisqu'elle est encore
exp�rimentale.

Ces modifications doivent �tre r�percut�es sur /boot/loader.conf. De la m�me

mani�re, les options sysctl que voudrez retrouver � chaque demarrage doivent se
trouver dans le fichier /etc/sysctl.conf sous la forme 'entr�e=param�tre'.

Ci-dessous notre sysctl.conf final.

------------------------------------- SNiP ------------------------------------

net.inet.tcp.rfc1323=1
net.inet.tcp.newreno=1
net.inet.tcp.inflight_enable=1
net.inet.tcp.inflight_min=6144
net.inet.tcp.sendspace=32768
net.inet.tcp.recvspace=65535
net.inet.tcp.log_in_vain=1
net.inet.tcp.always_keepalive=1
net.inet.tcp.blackhole=2
net.inet.tcp.delayed_ack=1
net.inet.tcp.strict_rfc1948=1
net.inet.tcp.isn_reseed_interval=1800
net.inet.tcp.syncookies=1
net.inet.tcp.syncache.hashsize=512
net.inet.tcp.syncache.cachelimit=15359
net.inet.tcp.syncache.bucketlimit=30
net.inet.tcp.syncache.rexmtlimit=3
net.inet.icmp.maskrepl=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.icmplim=300
net.inet.udp.sendspace=32768
net.inet.udp.recvspace=32768
net.inet.udp.maxdgram=28672
net.inet.udp.blackhole=1
net.inet.udp.log_in_vain=1
net.inet.ip.ttl=128
net.inet.ip.forwarding=1 # ou check_interface=1
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.ip.rtexpire=60
net.inet.ip.rtminexpire=10
net.link.ether.inet.max_age=1200
vfs.vmiodirenable=1
kern.coredump=1
kern.corefile=%N.sexfault
kern.ps_showallprocs=0
------------------------------------- SNiP ------------------------------------

Et la m�me chose pour /boot/loader.conf

------------------------------------- SNiP ------------------------------------

kern.maxprocperuid=512
kern.maxfilesperproc=1024
kern.maxfiles=16384
kern.ipc.somaxconn=4096
kern.ipc.maxsockbuf=262144
------------------------------------- SNiP ------------------------------------

2.2. Gestion utilisateurs

Dans un syst�me multi-utilisateurs, chaque utilisateur local ou distant se

doit d'avoir un compte propre permettant de converser l'environnement de
chacun dans l'�tat d�sir� ainsi qu'une gestion plus claire de l'activit� du
syst�me. En marge des comptes utilisateur classiques nous vous recommandons
fortement de cr�er plusieurs comptes dit 'syst�me' destin�s � ex�cuter avec un
minimum de risques de compromission ou d'exploitation de compte compromis, les
services r�seau sensibles que vous d�sirez mettre en place. Parmi les plus
int�ressant sur lesquels appliquer cette pratique, on trouve les serveurs DNS,
les serveurs web ou encore les serveurs smtp et pop3/imap4. Notez aussi la
pr�sence du compte nobody correspondant a l'utilisateur syst�me non privil�gi�
g�n�rique, mais plus il y a de services qui utilisent nobody, plus ce compte
acquiert de privil�ges. Cette m�thode est par ailleurs utilis�e par beaucoup
de proc�dures d'installation dans les ports, r�duisant votre charge de
travail.

Notez que les multiples chapitres sur sysctl, la configuration kernel, la

gestion des utilisateurs ou la mise en place d'une jail, nous pensons pouvoir
nous dispenser d'un chapitre suppl�mentaire sur les commandes basiques que sont
chroot, chmod et chown accompagn� d'une explication rapide sur les privil�ges.
Donc ne cherchez pas d'information sur ces commandes dans nos colonnes.

Notez par ailleurs que l'utilisation du compte root or des op�rations limit�es
de maintenance est fortement d�conseill�e pour des raisons de s�curit�. Chaque
manipulation du root peut entra�ner des cons�quences importantes pour
l'int�grit� du syst�me ou bien si le compte est compromis, alors toute la
machine passe sous contr�le de l'intrus. Bref, il est pr�f�rable de se
constituer un compte utilisateur appartenant lui aussi au group wheel et ayant
la capacit� d'ex�cuter des commandes en root par sudo qui nous permet de rester
sous un compte utilisateur et effectuer des op�rations ponctuelles n�cessitent
des droits root ou encore d'intervenir dans sur d'autres comptes si besoin est.
Par exemple nous pouvons �diter l'index de notre serveur web sur le compte
syst�me www en utilisant l'option -u qui permet de pr�ciser l'utilisateur dont
on souhaite endosser les droits

# sudo -u eberkut vi ~eberkut/CNS/FreeBSD.txt

Bien s�r cette libert� de manipulation peut �tre dangereuse c'est pourquoi nous
avons besoin d'�diter et de configurer /etc/sudoers afin de limiter les acc�s.
Le sch�ma de /etc/sudoers est le suivant : vous pouvez d�finir des alias pour
un ou plusieurs utilisateurs, ou encore une ou plusieurs commandes puis vous
d�finissez les autorisations selon le schema WHO WHERE=WHAT.

------------------------------------ SNiP -------------------------------------

# options
Defaults syslog=auth, mail_no_user, lecture, insults,\
syslog_badpri=alert, rootpw, passwd_timeout=3, authenticate
Defaults:FULLTIMERS !lecture

# alias utilisateurs > root

User_Alias FULLTIMERS = eberkut
User_Alias PARTTIMERS = bindmaster,webmaster

Run_alias OP = root,named,www

# alias commandes
Cmnd_Alias DEBUG = /usr/bin/mt,/usr/sbin/dump,/usr/sbin/restore, \
/usr/sbin/dd,/usr/bin/gdb,/usr/bin/ktrace, \
/usr/bin/kdump,/usr/bin/file,/usr/bin/truss, \
/usr/bin/ldd,/usr/bin/objdump,/usr/bin/strings, \
/usr/bin/nm,/usr/bin/size,/usr/bin/kill
Cmnd_Alias KILL = /usr/sbin/shutdown,/usr/sbin/halt,/usr/sbin/reboot
Cmnd_Alias SHELLS = /usr/bin/sh,/usr/bin/csh,/usr/local/bin/zsh, \
/usr/bin/ssh,/usr/X11R6/bin/startx
Cmnd_Alias USER = /usr/bin/su,/usr/sbin/adduser, /usr/sbin/rmuser, \
/usr/bin/chsh
Cmnd_Alias NET = /usr/sbin/ppp,/usr/sbin/ifconfig,/usr/sbin/ipfw
Cmnd_Alias DAEMON = /usr/sbin/named,/usr/local/apache,/usr/bin/sshd
Cmnd_Alias RIGHTS = /usr/sbin/chroot,/usr/sbin/jail,/usr/sbin/chown, \
/usr/bin/chmod
Cmnd_Alias CDROM = /sbin/umount /cdrom, /sbin/mount_cd9660 /dev/acd0c /cdrom

#directives
root ALL = (ALL) ALL
FULLTIMERS ALL = NOPASSWD: DEBUG, KILL, SHELLS, RIGHTS, USER, NET, DAEMON
PARTTIMERS ALL = DEBUG, NET, (OP) NOPASSWD: DAEMON
ALL ALL = NOPASSWD: CDROM
------------------------------------ SNiP -------------------------------------

Sudo se base sur des timestamp entre les diff�rences commandes entr�es pour
assurer un minimum de s�curit� en pla�ant un timeout. Pour updater votre
timestamp sans ex�cuter de commandes, vous pouvez taper sudo -v et pour le tuer
d�finitivement, sudo -K.

2.2.1. adduser / rmuser / chpass / watch

adduser est un outil extr�mement utile qui nous permet d'ajouter de nouveaux
utilisateurs de mani�re tr�s simple. Il permet en une op�ration de g�rer
l'ensemble des actions n�cessaire � la cr�ation d'un nouveau compte. Une simple
commande effectue une configuration pas � pas du compte ceci incluant la
cr�ation des entr�es n�cessaires dans /etc/passwd et /etc/group, la cr�ation du
r�pertoire de l'utilisateur et la copie des fichiers requis par d�faut jusqu'�
une notification de bienvenue.

Nous devons tout d'abord cr�er le fichier de configuration adduser par :

# adduser -s -config_create

Puis nous lan�ons la cr�ation de l'utilisateur.

# adduser -v
Use option ``-silent'' if you don't want to see all warnings and questions.
Check /etc/shells
Check /etc/master.passwd
Check /etc/group
Enter your default shell: csh date no sh tcsh zsh [sh]: sh
Your default shell is: sh -> /usr/local/bin/sh
Enter your default HOME partition: [/home]:
Copy dotfiles from: /usr/share/skel no [/usr/share/skel]:
Send message from file: /etc/adduser.message no
[/etc/adduser.message]: no
Do not send message
Use passwords (y/n) [y]: y

Write your changes to /etc/adduser.conf? (y/n) [n]: y

Ok, let's go.

Don't worry about mistakes. I will give you the chance later to correct any
input.
Enter username [a-z0-9_-]: eberkut
Enter full name []: eberkut
Enter shell csh date no sh tcsh zsh [zsh]:
Enter home directory (full path) [/home/eberkut]:
Uid [1000]:
Enter login class []: root
Login group wheel [wheel]:
Login group is ``eberkut''. Invite eberkut into other groups: guest no
[no]:
Enter password []:
Enter password again []:

Name: eberkut
Password: ********
Fullname: eberkut
Uid: 1000
Gid: 1000
Class: root
Groups: wheel
HOME: /home/eberkut
Shell: /usr/local/bin/zsh
OK? (y/n) [y]: y
Added user ``eberkut''
Copy files from /usr/share/skel to /home/eberkut
Add another user? (y/n) [y]: n
Goodbye!

Notez que vous pouvez facilement remarquer que nous utilisons ici adduser pour
la premi�re fois puisqu'il nous a fallu cr�er le fichier de configuration puis
adduser nous a demande ses valeurs par d�faut. De plus pour plus de simplicit�
nous �tions en mode verbose (-v). A l'avenir vous n'aurez que les informations
de l'utilisateur � entrer et vous pourrez effectuer cette op�ration en mode
silent (-s).

Adduser poss�de un programme fr�re, rmuser, qui va nous permettre de mani�re

sym�trique � adduser, de supprimer en une seule op�ration un utilisateur et
toutes les d�pendances que cela suppose. Rmuser effectue ainsi la suppression
de l'entr�e utilisateur dans le fichier de mots de passe, de son repertoire
(dans /home), de son courrier en attente (dans /var/mail), de ses fichiers
temporaires (dans /tmp), et son entr�e dans /etc/group voire la suppression du
groupe s�il devient vide. Mais rmuser efface �galement les entr�es de
l'utilisateur dans la crontab ou encore tue tous les processus en cours
appartenant � l'utilisateur en question.

# rmuser eberkut
Matching password entry:
eberkut:*:1000:1000::0:0:eberkut:/home/eberkut:/usr/local/bin/zsh
Is this the entry you wish to remove? y
Remove user's home directory (/home/eberkut)? y
Updating password file, updating databases, done.
Updating group file: trusted done.
Removing user's incoming mail file /var/mail/jru: done.
Removing files belonging to eberkut from /tmp: done.
Removing files belonging to eberkut from /var/tmp: done.
Removing files belonging to eberkut from /var/tmp/vi.recover: done.

Enfin, chpass est un autre outil merveilleux de plus nous permettant de

faciliter grandement la gestion utilisateur. Il permet de modifier les
informations de base d'un utilisateur telles que son password, son shell ou
des informations plus personnelles. Seul le root et l'utilisateur lui-m�me
peuvent modifier les informations avec chpass. Chpass fonctionne de la m�me
mani�re que edquota, c'est-�-dire qu'il va ouvrir un �diteur permettant de
modifier notre configuration.

# chpass eberkut
#Changing user database information for eberkut.
Login: eberkut
Password: ********
Uid [#]: 1000
Gid [# or name]: 1000
Change [month day year]:
Expire [month day year]:
Class:
Home directory: /home/eberkut
Shell: /usr/local/bin/zsh
Full Name: eberkut
Office Location:
Office Phone:
Home Phone:
Other information:

Lorsque vous d�sirez mettre en place un service, en plus de le faire

fonctionner en stand alone comme expliquer pr�c�demment, et s�il n�cessite
certains droits, alors lui assigner un utilisateur sp�cifique peut permettre
de limiter partiellement avec des m�canismes suppl�mentaires comme jail ou
chroot les d�g�ts provoqu�s par une intrusion par l'interm�diaire de ce
service. Cette remarque est vraie aussi pour BIND qui avec les bonnes options
ne reste root que quelques instants ou pour Apache qui tourne en nobody -
et ses scripts aussi ce qui peut donner des vuln�rabilit�s en cas de
mauvaise configuration.

Enfin, lorsqu�un utilisateur vient � se loguer et que vous avez remarqu� de sa

part un comportement ill�gitime ou intrusif, les options pour les snoop device
que nous avons plac� au moment de la configuration kernel vont nous permettre
de prendre possession afin d'observer et m�me d'�crire sur le tty d'un
utilisateur. Pour cela nous allons utiliser l'outil watch. Nous cr�ons d'abord
les p�riph�riques suivants :

# cd /dev
# ./MAKEDEV snp0
# ./MAKEDEV snp1
# ./MAKEDEV snp2
# ./MAKEDEV snp3

Puis nous pouvons lancer watch. Avant cela nous v�rifions les utilisateurs
actifs sur le syst�me afin de sp�cifier le tty device � surveiller. Nous
pla�ons l'option t pour obtenir un timestamp au d�but de l'observation, n
pour emp�cher l'utilisateur de changer de tty attach� et l'option W pour
permettre d'�crire au sein du tty surveill�.
# who
# watch -tnW ttyp1

2.2.2. quotas et limites

Les quotas sont une option de FreeBSD qui vous permettant de limiter la
quantit� d'espace disque ou encore le nombre de fichiers auxquels a le droit
un utilisateur ou tous les utilisateurs du m�me groupe, sur un syst�me de
fichiers donn�. Dans un syst�me multi-utilisateurs avec des acc�s distant,
cette m�thode �vite qu'un seul utilisateur ne consomme tout l'espace disque.

Les quotas devant �tre activ�s manuellement au sein du fichier de configuration

du kernel et n�cessitant donc une recompilation, nous vous avons recommande de
v�rifier la pr�sence de l'option quotas ainsi que plusieurs autres au d�but de
ce texte. Une fois cette �tape pass�e, vous devez activer une fois de plus les
quotas manuellement cette fois-ci au sein du fichier /etc/rc.conf. Pour cela
nous l'�ditons et y ajoutons la ligne suivante :

enable_quotas="YES"

Pour un contr�le accru, vous disposez �galement d'une seconde option mais qui
va lancer un programme - quotacheck - qui peut consid�rablement ralentir le
d�marrage de votre machine. Cependant la s�curit� primant, nous vous
recommandons d'�diter la ligne ci-dessous :

check_quotas="YES"

Vous devez enfin �diter le fichier /etc/fstab pour mettre en service les quotas
syst�me de fichiers par syst�me de fichiers. C'est l� que vous dites si vous
voulez des quotas d'utilisation des disques par utilisateur, par groupe ou les
deux, pour chaque syst�me de fichiers.

Pour mettre en service des quotas par utilisateur, ajoutez l'option userquota �
la zone d'options de l'entr�e de /etc/fstab pour le syst�me de fichiers sur
lequel vous voulez des quotas. Par exemple :

/dev/ad0s1c /home ufs rw,nosuid,userquota 2 2

Pour des quotas par utilisateur on utilise userquota et pour des quotas par
groups, on utilisera groupquota. Pour appliquer des quotas � la fois �
l'utilisateur et � son groupe, on combinera les 2 commandes pr�c�dentes comme
nous l'avons fait pour notre fichier. Il ne vous reste plus qu'� red�marrer
afin d'activer la prise en compte de quota et la g�n�ration des fichiers
/etc/quota.user et /etc/quota/group.

Les quotas peuvent etre instaur�s sur un syst�me selon plusieurs crit�res. Tout
d'abord en plus de pouvoir appliquer des quotas par utilisateur et/ou par
groupes, vous avez la possibilit� d'appliquer ces limitations selon differents
formats soit en termes d'espace disque, les blocs, soit en terme de fichiers,
les inodes. Par ailleurs, il faut ajouter des degr�s dans les limitations :
strictes ou souples. Les premi�res suivent les r�gles de quotas � la lettre,
mais lorsqu'un utilisateur atteint son quota, il ne peut plus rien ajouter. Le
second degr� de limitation offre � l'utilisateur un d�lai - valable durant une
semaine par d�faut - lui permettant de ne pas �tre subitement limit�
dans son travail par un quota trop strict et d'ajouter ou (surtout) retirer des
fichiers pendant ce d�lai. Cependant s�il n'est pas revenu � un niveau normal
une fois le d�lai �coul�, la limitation devient stricte et il ne peut plus rien
ajouter jusqu'� ce qu'il redescende en dessous de sa limitation.
Pour �diter nos quotas, nous utiliserons la commande edquota qui va ouvrir un
�diteur (vi par d�faut) :

# edquota
Quotas for user eberkut:
/usr/home/eberkut: blocks in use: 0, limits (soft = 80, hard = 100)
inodes in use: 0, limits (soft = 40, hard = 60)
/usr/var: blocks in use: 0, limits (soft = 80, hard = 90)
inodes in use: 0, limits (soft = 60, hard = 80)

Pour se simplifier l'attribution de quotas, on peut appliquer un quota

prototype � une plage d'uid par l'interm�diaire de l'option -p de edquota une
fois les quotas d�finis une premi�re fois :

# edquota -p eberkut 1000-10000

La commande quota peut �tre utilis�e afin de conna�tre les quotas et

l'utilisation de l'espace disque d'un utilisateur et/ou d'un groupe. Comme pour
la majorit� des autres commandes relatives aux informations utilisateurs, seul
le root peut aller consulter les quotas de tous comptes et tous groupes.

# quota -u eberkut

Un autre avantage majeur de FreeBSD, est de disposer, avec /etc/login.conf,

d'un fichier centralis� permettant de d�finir des classes renvoyant � un
utilisateur ou un groupe (au sens Unix) afin de sp�cifier le plus simplement
possible plusieurs restrictions touchant � l'authentification, aux permissions,
ou aux limitations de ressources des utilisateurs. C'est �galement un moyen
tr�s pratique de limiter les ressources des comptes utilis�s par vos services.

Les diff�rents attributs sont group�s par classes. Celles-ci repr�sentent donc
une politique coh�rente � appliquer � un utilisateur ou un groupe, comme d�j�
sugg�r�. Mais ces diff�rentes classes ont la particularit� de pouvoir �tre
h�rit�es. Ainsi, les valeurs sp�cifi�es dans une classe donn�es peuvent �tre
reprises dans une autre classe gr�ce � l'attribut 'tc'. Il existe ainsi une
classe 'default' qui contient une configuration basique dont tous les
utilisateurs pourront h�riter (et dont ils h�ritent effectivement si aucune
politique sp�cifique n'est indiqu�e). Il peut �tre alors int�ressant d'y
ajouter une classe 'root' qui augmentera la rigueur de l'authentification et
limitera au plus juste les ressources allou�es. La classe 'daemon' quant � elle
s'applique � tous les services lanc�s par /etc/rc au d�marrage. De plus, nous
pouvons m�me remplacer certains attributs, ou en ajouter de nouveaux, en les
�crivant dans la nouvelle classe, apr�s avoir sp�cifi� un h�ritage (toujours
avec 'tc').

Le format suivi dans login.conf est celui de termcap(5), avec ses bien-connues
colonnes s�par�es par des : ou ses valeurs s�par�es par des virgules. Un aper�u
en est donn� dans la manpage getcap(3) :

example|an example of binding multiple values to names:\

:foo%bar:foo^blah:foo@:\
:abc%xyz:abc^frap:abc$@:\
:tc=more:

Comme vous le voyez, l'attribution se fait un peu de la m�me mani�re que pour
/etc/sysctl.conf, c'est-�-dire 'nom=valeur'. En plus de pouvoir �tre modifi�s
dans login.conf entre deux classes parentes, les utilisateurs peuvent changer
certains attributs en pla�ant un fichier .login_conf dans leur home directory
avec, pour seule classe, 'me'. Les variables que l'utilisateur peut lui-m�me
sp�cifier ne sont pas nombreuses, puisque authentification, limitation des
ressources et comptabilit� en sont soustrait. Cela permet tout de m�me de
sp�cifier dans un fichier unique lu par login(1) des variables d'environnement,
par exemple. Cette fonctionnalit� est sp�cifique � FreeBSD.

Il existe de nombreux attributs param�trables, tombant dans plusieurs

cat�gories allant de simples bool�ens, jusqu'aux chemins d'acc�s, en passant
par des tailles (en b, kb, mb, gb ou tb) et des horaires (en s, m, h, d, w ou
y, indiquant ainsi les secondes, minutes, heures, jours, semaines ou mois).

Nous continuerons maintenant de suivre la manpage en reprenant la description

des attributs selon les cat�gories de limites de ressources, variables
d'environnement, authentification, et comptabilit�. Vous trouverez ci-dessous
des explications des attributs qui nous ont sembl� les plus pertinents.

o les limites de ressources

- cputime, permet de limiter le temps CPU que peut exploiter
temps absolu, pas en pourcentage. Correspond � l'option -f de limits(1).
- datasize, indique la taille maximale du segment 'data' d'un processus lanc�
sous cette classe. Un peu d�suet puisque cette limite s'applique aux appels
� brk(2) et sbrk(2). Identique � l'option -d de limits(1).
- maxproc, subordonn� � l'entr�e sysctl kern.maxproc, indique le nombre
maximal qu'un utilisateur de cette classe peut poss�der. Comme le fait
judicieusement remarquer la section 8.7 du FreeBSD Handbook, prenez garde
� ne pas trop restreindre les utilisateurs compilant beaucoup, utilisant
plusieurs sessions, ou simplement pr�vu pour des serveurs fortement bas�s
sur fork() comme Apache 1.x. Option -u de limits(1).
- memoryuse, sp�cifie la quantit� maximale de m�moire utilis�e par un
processus, auss bien RAM que swap. Voir �galement 'memorylock' qui a le
m�me sens vis-�-vis des appels � mlock(2). Options -m et -l de limits(1).
- openfiles, subordonn� � kern.maxfiles, d�finit le nombre maximal de file
descriptors (fichiers, IPC, sockets) qu'un processus peut avoir. Voir
l'option -n de limits(1).
- sbsize, pour socket buffer size, permet de contr�ler la quantit� de m�moire
allou�e pour tous les sockets buffers d'un utilisateur, c'est-�-dire la
m�moire utilis�e pour les transmissions sur le r�seau. Il est certainement
soumis aux entr�es sysctl net.inet.{tcp,udp}.{send,recv}space, et son
int�r�t a diminu� avec l'augmentation des protections disponibles contre
les SYN floods, � cause desquels cet attribut fut cr��. Option -b de
limits(1).
- vmemoryuse, fixe la quantit� maximale de tous types de m�moire virtuelle
(y compris via mmap()), qu'un processus peut exploiter.
- stacksize, que vous retrouverez avec l'option -s de limits(1), indique la
taille maximale jusqu'� laquelle le syst�me peut �tendre la stack d'un
processus.
- filesize, pr�cise la taille maximale d'un fichier qu'un utilisateur de
cette classe peut d�tenir. Correspond � l'option -f de limits(1). Notez que
les quotas sont prioritaires sur cet attribut.
- coredumpsize, subordonn� � filesize, permet de d�finir la taille maximale
acceptable pour un coredump. De tr�s gros programmes peuvent en effet
g�n�rer des coredumps importants, qui finissent �ventuellement par remplir
un disque ou une partition. Identique � l'option -c de limits(1).

Chacun des attributs est valable pour tous processus lanc�s par un utilisateur
concern� par la classe d�finissant les premiers. Notez que pour des d�finitions
pr�cises de chacun d'entre eux, il faudra vous r�f�rer aux manpages de
{set,get}rlimit(2) qui sont les fonctions contr�lant ces limites. D'autre part,
chacun d'entre eux peut �tre pr�cis� comme une limite soft ou hard en ajoutant
respectivement le suffixe -cur et -max. Sans suffixe, la valeur de l'attribut
vaut pour les deux types de limites. Enfin, ces attributs d�crivent rapidement
toute l'API *rlimit, ce qui explique en partie le temps pass� dessus. Nous
t�cherons d'�tre plus succints par la suite.

o Les variables d'environnement

- lang, permet de sp�cifier $LANG, la variable d'environnement indiquant votre
langue.
- manpath, pour le chemin d'acc�s par d�faut au manpages
- nologin, le chemin d'acc�s � un �ventuel fichier 'nologin' � afficher juste
avant de terminer une tentative d'ouverture de session ayant abouti sur
/sbin/nologin.
- requirehome, attribut bool�en, permet de requerir un r�pertoire
/home valide afin d'autoriser l'ouverture de la session. Ceci permet
d'ajouter une couche de s�curit� en obligeant chaque utilisateur � passer
par un processus d'authentification complet.
- priority, d�finit la priorit� initiale des processus lanc�s par les
utilisateurs de la classe, selon la syntaxe de nice(1). Ceci peut faciliter
l'imposition de pr�c�dence entre utilisateurs et services, par exemple.
- setenv, permet de sp�cifier une liste de variables d'environnement s�par�es
par des virgules.
- shell, indique le shell � ex�cuter apr�s l'authentification d'un utilisateur.
Cet attribut est prioritaire sur celui indiqu� dans /etc/passwd.
- term, d�termine le type de terminal
- umask sp�cifie la valeur du masque de cr�ation de fichier (ex : 022 = 755),
en octal.
- timezone, permet d'indiquer la valeur de la variable $TZ, afin de
param�trer votre horaire local.
- welcome d�fini le fichier contenant le message de bienvenue

o les variables d'authentification

- minpasswordlen permet d'imposer une longueur minimale pour un mot de passe.
La longueur Unix typique de 8 caract�res est un bon choix pour commencer.
Vous pouvez aller jusqu'� 128 caract�res.
- mixpasswordcase entra�nera la g�n�ration d'alertes de la part de passwd(1),
courant aussi bien parmis les utilisateurs que dans les scripts, si le mot
de passe ne comporte que des minuscules, le rendant faible et vuln�rable
aux attaques par dictionnaire.
- passwd_format permet de sp�cifier l'algorithme utilis� pour le stockage des
mots de passe. Par d�faut, cet attribut vaut 'des', pour DES, qui est
relativement faible, mais assure une grande compatibilit� avec les nombreux
services et syst�mes d'authentification. Vous pouvez le mettre � 'md5' pour
disposer de mots de passe MD5 et, plus r�cemment, � 'blf' pour utiliser
Blowfish.
- login-backoff indique le nombre de tentatives de login infructueuses au
cours d'une unique connexion avant que login(1) ne commence � introduire
des d�lais entre chaque tentatives afin de r�duire l'efficacit� d'une
attaque par brute-force. Dans la m�me veine, 'login-tries' indique le
nombre de tentatives avant que login(1) ne ferme la connexion.
- ttys.allow et ttys.deny permettent de sp�cifier une liste de tty
utilisables par les membres d'une classe
- host.allow et host.deny offre la possibilit� d'indiquer une liste d'h�tes
(adresses IP ou nom d'h�te) depuis lesquels on autorise ou pas les logins.
Pratique au sein d'un r�seau local o� les utilisateurs ne risquent pas de
changer de poste ou d'adresse.
- times.allow et times.deny servent � d�finir des horaires pendant lesquels
les logins sont autoris�s ou interdits. Il est de cette mani�re tr�s simple
d'interdire l'acc�s � certaines machines en dehors des heures habituelles
de travail, etc. Attention cependant � la syntaxe ; elle se d�compose en
 [dd[dd]...]start-end o� 'dd' indique des jours de la semaine (deux
premi�res lettres des jours en anglais, comme Mo pour Monday), et 'start'
et 'end' sont le d�but et de fin de la limite horaire en format 24h,
repr�sent�s par quatre chiffres attach�s. Exemple : MoTuWeThFr0080-0020
autorise ou interdit l'acc�s de lundi � vendredi entre 8h et 20h. Remarquez
que times.deny est prioritaire sur times.allow en cas de chevauchement des
horaires.

o comptabilit�
- accounted est un attribut bool�en activant les options de comptabilit� pour
cette classe, avec le m�me effet que accton(8).
- passwordtime permet de d�finir la dur�e de validit� des mots de passe
- warnpassword indiquera alors quand il sera n�cessaire d'avertir
l'utilisateur avant d'atteindre passwordtime.
- expireperiod indique la dur�e au bout de laquelle un compte li� � une
classe expire.
- avec warnexpire, vous pouvez d�cider combien de temps avec l'expiration de
son compte un utilisateur sera pr�venu.
- avec graceexpire vous indiquez pendant combien de temps un utilisateur peut
encore se connecter avant l'expiration d�finitive.
- autodelete permet de d�finir la dur�e apr�s expiration au bout de laquelle
un compte expir� est effectivement supprim�. L'expiration du compte
n'implique en effet aucunement sa suppression automatique.
- daytime, weektime et monthtime permettent quant � eux de sp�cifier la dur�e
maximale de connexion d'un membre d'une classe, � l'�chelle du jour, de la
semaine et du moins respectivement.
- warntime d�finit le moment auquel il un utilisateur est averti, avant que
le temps de session n'ait expir�. Lorsque cette limite est atteinte,
'gracetime' permet de laisser un sursis � ce m�me utilisateur avant de
couper la connexion. Ces valeurs sont exprim�es en temps avant que la
limite ne soit atteinte.
- sessiontime sp�cifie la dur�e maximale que peut atteindre une session.
- sessionlimit sp�cifie le nombre maximal de sessions concurrentes, en
limitant le nombre de tty simultan�ment ouverts possible.
- ttys.accounted, ttys.exempt, host.accounted, host.exempt ont les m�mes sens
et syntaxes que les variables d'authentification ttys.* et host.*, mais
pour la comptabilit� bien s�r.

Je vais maintenant �tre dans l'obligation de vous d�cevoir. Votre serviteur

ainsi que bien d'autres utilisateurs de FreeBSD ont pu tristement remarquer que
plusieurs, si ce n'est toutes, les options de comptabilit� propos�es � travers
login.conf sont sans effet aucun. Les tests limit�s et la sp�cificit� de
plusieurs d'entre elles interdisent de dresser la moindre liste. Il est
cependant ais� de voir que plusieurs d'entre elles ne correspondent � aucun
symbole dans les sources. J'ai tout de m�me maintenu leurs descriptions dans
l'espoir qu'une �me charitable soit tent�e d'impl�menter ces fonctionnalit�s
(t�che sans doute rendue plus ardue par la PAM'ification massive de la s�rie
5.x).

Vous trouverez ci-dessous un login.conf d'exemple comportant une classe

default, une classe root, une classe users pour les utilisateurs, ainsi qu'une
classe wheel pour les administrateurs. Enfin, nous configurons une classe
daemon qui concernera donc la plupart des services lanc�s au d�marrage.

# vi /etc/login.conf

------------------------------------ SNiP -------------------------------------

default:\
:copyright=/etc/COPYRIGHT:\
 :welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
:path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin
/usr/X11R6/bin ~/bin:\
:nologin=/var/nologin:\
:cputime=unlimited:\
:datasize=unlimited:\
:stacksize=unlimited:\
:memorylocked=unlimited:\
:memoryuse=unlimited:\
:vmemoryuse=unlimited:\
:filesize=unlimited:\
:coredumpsize=unlimited:\
:openfiles=unlimited:\
:maxproc=unlimited:\
:sbsize=unlimited:\
:priority=10:\
:umask=022:\
:minpasswordlen=8:\
:mixpasswordcase=true:\
:passwd_format=blf:\
:login-backoff=3:\
:login-retries=6:\

root:\
:tc=default:
:priority=5:\

# une valeur �lev�e pour memoryuse-max sera n�cessaire en cas d'utilisation

# d'un server graphique (XFree)

users:\
:tc=default:
:cputime=2h:\
:filesize=100m:\
:coredumpsize=1m:\
:memoryuse-cur=5m:\
:memoryuse-max=15m:\
:vmemoryuse-cur=5m:\
:vmemoryuse-max=15m:\
:maxproc=32:\
:openfiles=128:\
:priority=20:\
:passwordtime=90d:\
:warnpasswordtime=7d:\
:sessionlimit=3:\
:times.allow=MoTuWeThFr0080-0020:\
:requirehome:\

wheel:\
:tc=users
:requirehome:\
:sessionlimit=unlimited:\
:times.allow=unlimited:\

# de m�me, ici nous donnons pour exemple des utilisations m�moire �lev�es,
# dans l'hypoth�se de serveurs charg�s
daemon:\
:tc=default:
:memoryuse-cur=20m:\
:memoryuse-max=60m:\
:vmemoryuse-cur=20m:\
:vmemoryuse-max=60m:\
:filesize=500m:\
:coredumpsize=5m:\
:openfiles=512:\
:maxproc-cur=128:\
:maxproc-max=512:\
:sbsize-cur=4k:\
:sbsize-max=16k:\
:priority=10:\
------------------------------------ SNiP -------------------------------------

Apr�s chaque modification de login.conf, il est n�cessaire de mettre � jour la

base de donn�es des utilisateurs afin de mettre en place la nouvelle politique,
gr�ce � cap_mkdb, comme ci-dessous :

# cap_mkdb /etc/login.conf

Afin de tester des limites de ressources, ou bien de modifier en urgence

celles-ci avant une modification de politique, vous disposez de la commande
limits(1). Celle-ci vous permettra de modifier les restrictions impos�es � un
daemon par exemple, au cours de son ex�cution. Avec les options -S ou -H vous
pouvez m�me sp�cifier des limites hard ou soft (ou bien les deux confondues,
via -B).

# limits -E -C www -B -n 1024

La ligne pr�c�dente permet par exemple de permettre � l'utilisateur www (qui

lance apache httpd sous FreeBSD) d'utiliser jusqu'� 1024 file descriptors
(tout �tant fichier sous Unix, ceci concerne aussi bien les fichiers au sens
classiques que les sockets). Les diverses options sont d�taill�es dans
limits(1).

2.2.3. jail

Jail est un m�canisme tr�s puissant qui, comme son nom l'indique, offre la
la possibilit� d'affiner les privil�ges et la gestion des utilisateurs selon
un principe, similaire � chroot, d'emprisonnement des processus. Jail va
cependant beaucoup plus loin puisqu'il propose la reproduction d'un
environnement complet � l'int�rieur d'un environnement parent. La fonction
jail() se base sur une version renforc�e de chroot().

Construire une jail peut s'av�rer tr�s utile pour confiner un utilisateur ou
service auquel on ne fait aucune confiance ou bien qui risque de menacer
l'int�grit� et la stabilit� du syst�me. Pour cela jail offre un environnement
FreeBSD virtuel totalement op�rationnel avec ses propres fichiers de
configuration ou gestion des utilisateurs, le tout rattach� � un alias IP. De
plus, un processus une fois dans la jail est comme derri�re une glace sans
teint, il �volue librement mais ne peut pas voir au-del� de son environnement
tandis que l'h�te de la jail peut tout observer et surveiller. Ainsi, un
processus dans la jail ne peut pas en sortir, et vous pouvez d�l�guer des
comptes root au sein de chaque jail. Dans l'hypoth�se d'une attaque, l'intrus
obtiendrai par exemple d'abord un acc�s local par un exploit distant, puis un
acc�s root par un exploit local mais se verrait confiner � sa jail
(th�oriquement, jail �tant bas� sur chroot(), rien n'est s�r).
Jail se pose ici en pr�curseur du concept plus r�cent de honeypot, et peut tr�s
bien �tre utilis� comme tel pour inciter et surveiller des intrusions avec un
risque limit� de compromission totale de la machine, tout en conservant logs et
informations � l'abri. Pour conserver son int�grit�, une jail restreint les
actions possibles par rapport � un environnement complet. Il est ainsi interdit
de modifier le kernel (qui reste unique pour l'ensemble du syst�me) et charger
des modules kernel, modifier la configuration r�seau, monter des syst�mes de
fichiers, cr�er des devices, utiliser des raw sockets, modifier la MIB sysctl
ou les les securelevels. Tout ce qui n'est pas directement li� au
fonctionnement de la jail est interdit. Nous pouvons cependant utiliser comme
d'habitude des ports privil�gi�s, modifiers les permissions des fichiers et
utilisateurs � l'int�rieur de la jail, etc. afin de r�ellement cloner un
environnement classique.

La mise en place effective d'une jail s'effectue � l'aide de la s�quence de

commandes suivante :

# ifconfig fxp0 alias $jail_IP_alias netmask 255.255.255.0

# mkdir -p /jail/jailone
# cd /usr/src
# export JONE=/jail/jailone
# make world DESTDIR=$JONE
# cd /etc
# make distribution DESTDIR=$JONE NO_MAKEDEV=yes
# cd $JONE/dev
# ./MAKEDEV jail
# ln -sf null /boot/kernel/<kernelname>
# touch ../etc/fstab

Nous attribuons une adresse alias IP � notre jail puis nous cr�ons le
r�pertoire /jail/jailone dans lequel sera confiner notre environnement virtuel.
La commande make permet alors de construire un syst�me complet avec pour
destination la jailone, incluant binaires, fichiers de configuration et
arborescence des devices. Notez � la fin le lien symbolique vers le kernel,
ainsi que la cr�ation d'une fstab vide pour s'assurer du bon fonctionnement de
certains programmes.

Les jails ne sont pas encore persistantes, il est donc n�cessaire de configurer
votre rc.conf principal pour conserver la configuration ifconfig � chaque
reboot :

ifconfig_fxp0="alias $jail_IP_alias netmask 255.255.255.0"

Puis il faudra copier la ligne suivante au sein de rc.local pour rendre la jail
persistante entre deux red�marrages :

# jail /jail/jailone/ $hostname $jail_IP_alias /bin/sh

Si vous pr�voyez d'utiliser cron ou syslog, nous vous recommandons de recr�er

enti�rement votre fichier de configuration en adaptant les entr�es � la jail.

Pour l'utilisation de cron, nous vous recommandons de recr�er enti�rement votre

fichier de configuration avec vos propres entr�es. Par ailleurs tous les
fichiers copi�s le sont apr�s configuration compl�te de l'environnement h�te,
ce qui signifie que ces fichiers ont �t� chmod�, pensez donc � faire de m�me
avec crontab, httpd.conf et named.conf.

En utilisant adduser et chpass comme vue pr�c�demment, nous n'avons plus qu'�
changer le password du root de la jail, puis � cr�er un utilisateur par service
que nous souhaitons confiner. Nous prendrons comme exemple named et httpd. Si
vous d�sirez autoriser l'acc�s � votre jail � des utilisateurs pr�existants,
il va vous falloir copier spwd.db. Pour cela nous n'allons recopier que les
informations qui nous int�ressent :

# fgrep $username /etc/passwd > $JONE/etc/passwd

# fgrep $username /etc/master.passwd > $JONE/etc/master.passwd
# cd $JONE/etc/ && pwd_mkdb -d master.passwd

Pour une s�curisation du syst�me, en marge de fichier de configuration utile

que nous avons d�j� copi�, vous pouvez utiliser les fonctionnalit�s de chmod,
ou m�me les chflags, pour modifier les permissions sur les correspondants
confin�s des r�pertoires /bin, /sbin, /usr/lib, /usr/share/lib afin d'�viter
toute modification ou compromission.

Nous pouvons �galement rajouter au sysctl.conf de l'environnement h�te

certaines variables concernant les jails. Notez que maintenant que nous avons
mis en place une jail, nous nous referons � la jail comme l'environnement jail
et � la machine normale comme � l'environnement h�te. Les entr�es sysctl
suivantes permettent de d�cider si la jail a le droit de changer son propre nom
de domaine, d'utiliser des IPC standards System V pour la communication inter
processus lui permettant de communiquer et donc d'alt�rer des processus en
dehors de la jail, et enfin de limiter ou pas l'acc�s � des types socket plus
nombreux et non soumis aux restrictions jail :

# sysctl -w jail.set_hostname_allowed=0
# sysctl -w jail.socket_unixiproute_only=1
# sysctl -w jail.sysvipc_allowed=0

Si vous d�sirez configurer un nombre important de jail, comme ce sera le cas

si vous confiner chaque service ou site h�berg� ind�pendamment, pour � la fois
plus de s�curit� et aussi limiter la taille occup�e par la jail, vous pouvez
utilisez des pseudo-devices vn exploitant le driver vnode qui permet de traiter
un fichier comme un device. Lorsque vous avez d�cid� de la taille maximale par
jail, utilisez 'truncate' pour cr�er un fichier de cette taille (ici 1 Go) :

# truncate 1G jailfile

Puis, pour mounter ces fichiers comme des partitions sur lesquelles installer
vos jail, utilisez 'vnconfig' pour transformer le fichier pr�c�dent en un
device (ici vn0c). Si aucun fichier n'est sp�cifi�, vnconfig utilisera la swap
pour cr�er le device. Vous pourrez alors en sp�cifier la taille avec l'option
-S suivi de la taille (en ko, mo, go et to), et la remplir de z�ros avec -T,
supplantant ainsi l'utilisation de truncate :

# vnconfig -e vn0c jailfile

ou, pour supprimer le recours � truncate :

# vnconfig -S 1g -T vn0c

Vous pouvez ensuite le monter et d�monter comme d'habitude. Vous devrez

ins�rer ces nouveaux p�riph�riques dans vote fstab afin de les monter au
d�marrage en tant que partition jail (un p�riph�rique vn par jail). L'int�r�t
en est la grande souplesse puisque vous pouvez ais�ment augmenter ou r�duire la
taille du fichier utilis� pour �muler des quotas. Pour retransformer votre
device vn en fichier, ex�cutez :
# vnconfig -u /dev/vn0c

Si vous fa�tes tourner plusieurs services dans vos jails, il peut arriver
qu'une faille de s�curit� soit d�couverte, n�cessitant le patching de ce
service. Gr�ce � la virtualisation de la jail, vous pourriez utiliser NFS entre
celle-ci et l'environnement h�te. Il existe cependant une solution plus simple
consistant � utiliser mount_null qui permet de dupliquer une partie d'un
syst�me de fichier afin qu'elle soit vue par un chemin diff�rent. Comme patcher
et recompiler n�cessite l'acc�s � /usr/src, vous pr�servez votre s�curit� en
montant ce chemin en read-only du point de vue de la jail.

# mount_null -o ro /usr/src $JONE/usr/src

Il ne vous reste plus alors qu'� appliquer le patch et � recompiler

normalement vos binaires userland.

A noter tout de m�me qu'il est recommand� d'utiliser l'utilisateur named depuis
lequel bind - qui se placera quelques instants avec les droits root pour
r�cup�rer les file descriptor avant de revenir � des privil�ges plus
raisonnables - sera utilis�. Avec BIND il est �galement fortement recommand�
d'utiliser une cl� d'authentification TSIG entre vos serveurs DNS, de limiter
les AXFR ou transferts de zone � des serveurs DNS secondaires s�rs ou encore de
modifier la r�ponse � la requ�te host -l chaos version.bind qui peut donner �
l'attaquant des informations sur la version de BIND et donc d'�ventuels remote
buffer overflow possibles.

Si vous utilisez Apache en tant que httpd, n'oubliez pas d'�diter httpd.conf
afin de sp�cifier comme owner l'utilisateur www afin de ne pas avoir recourt �
nobody qui plus il sera utilis�, plus il gagnera de drois. Veillez aussi � ne
pas surcharger le syst�me et, plus particuli�rement, � ne pas atteindre trop
facilemenent le nombre de processus maximal par utilisateur (dans un tel cas si
le trafic est l�gitime passez en root jail pour adapter le param�tre par
sysctl).

Si vous �tes inquiet d'une d�pendance quelconque � chroot(), et recherchez des

capacit�s de configuration plus pr�cises, vous pouvez vous tourner vers la
r�impl�mentation partielle de Robert Watson : jailNG. Celle-ci fournit
plusieurs am�liorations pour ce qui est de la configuration et de la gestion de
la jail. Il vous suffit de r�cup�rer le patch sur
http://www.watson.org/~robert/jailng/ et de l'appliquer de la fa�on suivante :

# cd /usr/src && patch -p1 < jailng.1.diff

Il ne reste plus qu'� recompiler votre kernel. L'utilisation s'effectue ensuite

par l'interm�diaire de 'jailctl' disposant � l'heure actuelle de 3 commandes :

- 'jailctl create' ou 'destroy' qui prennent en argument le nom de la jail

et permettent de cr�er ou supprimer une jail
- 'jailctl join prenant en argument le nom de la jail � rejoindre, le chemin �
confiner avec l'option -c, et enfin une commande, telle que le lancement d'un
shell.

Les droits de chaque jail pourra �tre g�rer plus finement gr�ce � des entr�es
sysctl sp�cifique, de la forme jail.jail_name.entry_name, pour chacun d'entre
elles. Ces nouvelles entr�es sont les suivantes :

# sysctl jail.jail_name.set_hostname_permitted=0
# sysctl jail.jail_name.sysvipc_permitted=1
# sysctl jail.jail_name.socket_ipv4_permitted=1
# sysctl jail.jail_name.socket_unix_permitted=1
# sysctl jail.jail_name.socket_route_permitted=1
# sysctl jail.jail_name.socket_other_permitted=0
# sysctl jail.jail_name.ipv4addr=192.168.1.1

Les jails peuvent - ou non - ainsi modifier leur hostname, les processus en
leur sein peuvent utiliser les IPC SysV, les sockets INET, les sockets UNIX,
les sockets route, tout autre type de socket, et enfin vous pouvez param�trer
l'adresse IP de la jail.

Une petite remarque mais de poids apr�s cet encensement : le projet jailNG est
d�j� vieux et ne montre plus aucun signe d'activit� nulle part depuis
longtemps. Le code risque donc de causer de nombreux probl�mes, et les
nouvelles fonctionnalit�s tardent � venir, sans doute depuis que Robert Watson,
d�sormais membre de la core team, est � la t�te du massif projet TrustedBSD,
visant l'impl�mentation du standard POSIX.1e � partir de FreeBSD 5.x, et
l'un des instigateurs du projet CBOSS qui chapeaute plusieurs d�veloppements
open source dans le domaine de la s�curit�. FreeBSD 5.0 a tout de m�me quelques
maigres am�liorations comme la configuration de securelevel ind�pendant pour
chaque jail.

2.3. int�grit�

Le chapitre pr�c�dent abordant une sorte de syst�me dans le syst�me, il sort un

peu du chemin logique et pas � pas de cet article. N'oubliez donc pas de tenir
compte des astuces suivantes dans la configuration de vos environnements jail
en plus de vote environnement host. Nous nous int�ressons ici � l'int�grit� des
fichiers et notamment par les permissions et privil�ges accord�s dans le cadre
de l'utilisation ou de la gestion de certains fichiers.

Un danger majeur de la s�curit� des fichiers est repr�sent� par le bits SUID.
Ce bit plac� sur un fichier permet de l'utiliser avec les m�mes droits que le
propri�taire du fichier ce qui peut se r�v�ler dangereux si le propri�taire est
le root. Mais tout d'abord, nous recherchons les fichiers marqu�s SUID et SGID
(similaire � SUID mais � l'�chelle d'un groupe) avec find

# find / -perm 02000 -o -perm 04000 print

Nous obtenons une liste de tous les fichiers ou repertoires avec le bit SUID ou
SGID. Parmi tout cela, il y a des ex�cutables que nous ne voulons pas forc�ment
laisser � la port�e de n'importe qui ou bien que nous n'avons pas l'intention
d'utiliser. La s�lection � effectuer parmi les fichiers SUID est laiss�e �
votre discr�tion selon votre utilisation. Cependant, il est fortement
recommand� de ne pas laisser des proc�dures shell en SUID surtout appartenant
au root, ceci pouvant �ventuellement entra�ner l'ex�cution ill�gitime de
commandes.

Pour effectuer nos modifications, nous utilisons l'utilitaire chmod qui nous
permet de modifier les permissions allou�es � un fichier. Pour calculer les
modes que nous d�sirons appliquer � tel fichier, nous nous basons sur le sch�ma
de permissions suivant :

4000 bit SUID (SetUserID on execution) dont nous avons d�j� parl�
2000 bit SGID (Set-Group-ID-on-execution) que nous avons �galement abord�
1000 sticky bit, sous freebsd ceci ne fonctionne que sur les r�pertoires et
permet aux utilisateurs de supprimer ou renommer uniquement les fichiers
dont ils sont propri�taires
0400 permet la lecture par le propri�taire
0200 permet l'�criture par le propri�taire
0100 permet l'ex�cution d'un fichier par le propri�taire et la recherche au
sein d'un r�pertoire
0040 permet la lecture par les membres du group
0020 permet l'�criture par les membres du group
0010 permet l'ex�cution d'un fichier par les membres du group et la recherche
au sein d'un r�pertoire
0004 permet la lecture par tous les autres utilisateurs
0002 permet l'�criture par tous les autres utilisateurs
0001 permet l'ex�cution d'un fichier par tous les autres utilisateurs et la
recherche au sein d'un r�pertoire

Lorsque vous faites un ls, ce sont les omnipr�sents srwxrwxrwx. Vous

trouverez plus de pr�cisions sur les permissions et l'utilisation de chmod par
un man 1 chmod.

Nous pouvons tout d'abord d�cider de limiter les modifications apport�es �

certains de nos fichiers de configuration. Nous permettons donc la lecture et
l'�criture par l'owner, la lecture par le groupe et aucun droit au reste des
utilisateurs

# chmod 600 /etc/fstab

# chmod 600 /etc/rc.*
# chmod 600 /etc/syslog.conf /etc/newsyslog.conf
# chmod 600 /etc/ppp/ppp.conf
# chmod 600 /etc/ssh/sshd_config
# chmod 600 /etc/racoon.conf /etc/ipsec.conf
# chmod 600 /etc/passwd
# chmod -RH 640 /etc/nessus/

Et vous pouvez en faire de m�me avec certains r�pertoires que vous ne souhaitez
absolument pas voir compromis. En l'occurrence nous n'autorisons la lecture,
�criture et ex�cution par le root et uniquement l'ex�cution pour tous les
autres. Ceci pourra entra�ner � l'avenir des probl�mes d'acc�s, dans ce cas
un rapide chmod 755 sur le fichier ou ex�cutable incrimin� r�soudra l'affaire.

# chmod -RH 755 /bin /sbin /boot

# chmod -RH 711 /usr/libexec /usr/lib /usr/bin /usr/sbin
# chmod -RH 711 /usr/local/libexec /usr/local/lib /usr/local/bin \
/usr/local/sbin
# chmod -RH 644 /var/log

Notez que nous pouvons combiner ces op�rations avec quelque chose de plus
drastique dans le cas o� nous disposerions d'un securelevel assez �lev�. Ainsi,
si vous recompilez ou mettez � jour rarement vous pouvez �galement appliquer la
commande chflags �tudi�e plus haut sur les r�pertoires et fichiers de votre
choix en prenant garde aux probl�mes ult�rieurs en cas de compilation ou de
configuration. Profitez �galement es messages d'erreurs de chmod pour v�rifier
vos bits SUID/SGID et le d�s�lectionner sur les binaires sensibles.

Nous allons ensuite nous inqui�ter de l'int�grit� de nos fichiers et de notre

syst�me. Pour cela nous allons tout d'abord nous servir de mtree. Mtree peut
�tre consid�r� comme un v�rificateur d'int�grit� syst�me int�gr� dans le m�me
style que AIDE ou TripWire. Il va nous permettre de g�n�rer une sp�cification
de notre file system contre laquelle comparer r�guli�rement notre syst�me afin
de d�tecter d'�ventuelles modifications ill�gitimes. Pour g�n�rer notre
sp�cification nous entrons la commande suivante

# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p /your/path > \

/etc/mtree/file.spec
L'option s permet d'obtenir un unique checksum pour tous les fichiers auxquels
on a appliqu� le keyword 'cksum' et n�cessite un chiffre en keyword (�
conserver � l'abri). L'option K pr�cise un keyword � appliquer qui sera stock�
dans la sp�cification et compar� plus tard sachant que par d�faut on a les
keywords flags (pour les file flags), gid (pour le group), mode (pour les
permissions en octal), nlink (pour les hard link), size (pour la taille), link
(pour les liens symboliques), time (pour le dernier timestamp de modification),
et uid (pour l'owner) auxquels nous ajoutons cksum pour obtenir un checksum
selon le sch�ma de la commande cksum(1), sha1digest pour obtenir une signature
� l'aide de l'algorithme � sens unique SHA-1 et uname afin d'obtenir l'owner
sous forme de nom. Ensuite l'option x permet de ne pas sauter les points de
mountage, c permet de sortir les informations sur l'output standard et p
pr�cise le chemin. Ce qui nous donnera en pratique

# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p /bin > \

/etc/mtree/bin.spec
# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p /sbin > \
/etc/mtree/sbin.spec
# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p /usr/libexec \
> /etc/mtree/libexec.spec
# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p /usr/lib > \
/etc/mtree/lib.spec
# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p \
/usr/share/lib > /etc/mtree/sharelib.spec
# mtree -s 31337 -K cksum -K sha1digest -K uname -x -c -p /boot > \
/etc/mtree/boot.spec

Puis pour comparer nos sp�cifications et communiquer les r�sultats au root avec
un minimum d'indentation, nous n'avons plus qu'� effectuer

# mtree -x -i -f file.spec | mail -s 'mtree results' root

Une bonne id�e est de lancer les premi�res commandes une fois apr�s chaque
recompilation du syst�me et la v�rification une fois par semaine ou bien d�s
que vous avez un doute sur l'int�grit� de votre syst�me. Tout cela bien s�r par
l'interm�diaire de cron.

Vous pourrez trouver plusieurs am�liorations d�di�es � l'utilisation de mtree

en tant qu'outil de v�rification d'int�grit� - notamment son utilisation via
/etc/periodic/security - � http://people.freebsd.org/~fanf/FreeBSD/.

Un dernier outil tr�s utile que nous allons utiliser pour nous assurer de
l'int�grit� de notre syst�me sera KSEC pour Kernel Security Checker. KSEC ne
fait pas partie de la distribution officielle FreeBSD et n'est pas non plus
dans les ports. KSEC est l'adaptation � FreeBSD de l'outil de s�curit� Linux
KSTAT (Kernel Security Therapy Anti Trolls) par s0ftpr0ject. Pour vous procurer
l'un ou l'autre, rendez vous � http://www.s0ftpj.org/en/site.html.
Ces outils fonctionnent selon une conception hautement parano�aque du syst�me
et d�cide donc de ne prendre leurs informations que du kernel en utilisant la
librairie KVM et en limitant les op�rations sur le syscall ioctl(). Il va donc
nous servir � d�tecter la pr�sence de backdoors dans le syst�me sous leur
forme la plus redoutable, les modules kernel. KSEC est si pouss� qu'il peut
nous servir de remplacement � ifconfig pour la lecture. En effet, en observant
directement les structures ifnet ou les files descriptor bpf, il peut d�tecter
si une interface se trouve ou pas en mode promiscuous r�v�lateur d'un sniffer
et m�me fournir des informations et statistiques sur le trafic ou l'�tat des
interfaces. Ces v�rifications peuvent �tre effectu�es � travers les op�rations
suivantes pour l'interface fxp0 -- pr�ciser 'all' pour toutes les interfaces
disponibles :

# ksec -i fxp0

Mais KSEC va �galement nous servir � d�tecter une alt�ration de notre int�grit�
syst�me en v�rifiant si les adresses indiqu�es dans notre syscall table sont
effectivement les m�mes qu'annonc�es par /dev/kmem. La modification de la
syscall table est une m�thode tr�s r�pandue dans la conception de backdoors LKM
mais qui devient un peu ancienne et peut se voir remplacer par des m�thodes
d'hijacking des syscalls ou des pointeurs vers la syscall table, ou encore d'un
patching de /dev/kmem pour �viter ce type de d�tection. C'est sur ce dernier
point que l'utilisation des securelevels, emp�chant toute modification de
/dev/kmem, est judicieuse. Il peut �galement effectuer diff�rentes op�rations
de v�rification d'int�grit� des protocoles ou d'int�grit� des fichiers link�s
entre eux. Il ne nous reste plus qu'� effectuer une compilation de ces options
afin d'obtenir un rapport complet d'int�grit� syst�me :

# ksec -i interface -b -k -p

Par ailleurs nous vous recommandons d'essayer en cas de doutes � la suite de

rapports mtree et ksec, d'effectuer une ultime v�rification � l'aide de
chkrootkit qui lui se base essentiellement sur des signatures connues signalant
des fichiers trojanis�s mais fournit �galement une petite batterie de tests
dans un style similaire � KSEC mais moins kernel-dependant. Voir
http://www.chkrootkit.org et les ports security pour plus d'informations.

2.4. secure shell

SSH signifie Secure Shell. A l'origine SSH est un remplacement des Berkeley r*
commandes tels que rsh, rlogin ou rcp consid�r�es comme tr�s peu s�res. SSH
utilise pour s�curiser la transmission un tunnel crypt� entre les 2 machines.
SSH a rapidement d�pass� toutes les attentes et il est devenu un remplacement
int�ressant pour telnet ou ftp lorsqu'ils sont n�cessaires pour des utilisateurs
r�guliers poss�dant un compte sur la machine en leur offrant une m�thode d'acc�s
� distance hautement s�curis�e et tr�s bien support�e. En particulier OpenSSH
est une version libre et recod�e du protocole SSH et fournit un client et un
serveur pour des nombreuses plate-formes unix. C'est lui que nous allons
maintenant utiliser pour la configuration de SSH.

Tout d'abord nous allons �diter le fichier de configuration du daemon sshd.

# ee /etc/ssh/sshd_config

------------------------------------ SNiP -------------------------------------

# This is ssh server systemwide configuration file.

Port 22
# �vitez SSHv1 soumis � plusieurs vuln�rabilit�s
Protocol 2,1

# lorsque vous copierez ce fichier pour votre jail user pensez � mettre ici
# l'alias de votre jail.
ListenAddress 127.0.0.1, public_IP, jail_IP

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 60
KeyRegenerationInterval 3600
RhostsAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

# ordre de pr�f�rences des algorithmes de chiffrement et d'authentification

Ciphers blowfish-cbc,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour
MACs hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96

# envoi d'un message apr�s un intervalle donn�

# et deconnexion apr�s plusieurs envois
KeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 5

# Pour eviter les similis flooding du a des tentatives de connexion repetees,

# nous installons une sorte de quotas au niveau de la gestion des connexions.
# 10 pour le nombre de connexions non authentifiees, 40 pour le pourcentage de
# refus apres le premier nombre atteint, et 50 signifiant qu'au bout de 50
# tentative toute connexion non authentifiee est refusee.
MaxStartups 10:40:50

# ici nous eliminons les vulnerabilites lies aux fichiers ~/.rhosts et

# ~/.shosts et a leurs relations de confiance.
IgnoreRhosts yes

# verifier permissions et ownership des fichiers et du /home avant d'accepter

# un login
StrictModes yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd yes

# Syslog
SyslogFacility AUTH
LogLevel DEBUG

# Ci-dessous nous privilegions l'utilisation de cles RSA et DSA pour

# l'authentification au lieu du password
PasswordAuthentication no
# si vous choississez de mettre l'option precedente a yes, ajoutez celle
# ci-dessous pour interdire les passwords vides
# PermitEmptyPasswords no

# d�sactive l'authentification s/key

SkeyAuthentication no
KbdInteractiveAuthentication yes
ChallengeResponseAuthentication no

# ces blocs sont relatifs a l'authentification kerberos

#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
#Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

PermitRootLogin no
CheckMail yes
UseLogin yes

# nous ne le recommandons pas du fait de sa relative experimentalite mais cette

# ligne vous permet le cas echeant d'utiliser sftp.
#Subsystem sftp /usr/libexec/sftp-server
------------------------------------ SNiP -------------------------------------

Il ne nous reste plus maintenant qu'� �diter encore une fois le fichier
rc.conf afin de s'assurer que sshd se lancera bien au d�marrage. Nous
transformons donc la ligne sshd_enable="NO" en sshd_enable="YES" et nous lui
adjoinions �galement la ligne sshd_flags="-4" afin de limiter l'utilisation �
des connexions IPv4. Pour g�n�rer vos cl�s il vous suffira alors d'ex�cuter
ssh-keygen ; bien que celui-ci soit d'hors et d�j� utilis� par rc.network avec
sshd_enable.

Vous pourrez enfin d�cider de ne pas offrir de shell � vos utilisateurs

distants. Ceci peut �tre effectuer � l'aide de chpass ou de chsh en pr�cisant
comme shell /sbin/nologin.

# chsh -s /sbin/nologin user

2.5. logging

Nous allons maintenant nous pencher sur les facilites que nous offre FreeBSD
dans le logging des diverses activit�s syst�me et utilisateur. Nous allons plus
particuli�rement �tudier le system accounting, le system logging et l'analyse
de ces logs par des moyens automatis�s.

Sous FreeBSD, nous avons la possibilit� d'activer le system accounting qui nous
offre la possibilit� d'enregistrer et de r�capituler les commandes ex�cut�es et
nous permet de conserver des informations d�taill�es sur les ressources syst�me
utilis�es, leur r�partition entre les utilisateurs, et de surveiller le
syst�me. Pour ce faire, nous disposons de accton et de sa. Accton permet
d'activer ou de d�sactiver le system accounting comme dans l�exemple
ci-dessous :

# accton /var/account/acct

Nous sp�cifions ici un fichier vers lequel sera redirige les donnes de
l'accounting, pour d�sactiver il suffit d'ex�cuter la m�me commande sans le
fichier en argument. Pour consulter les donnes de l'accounting il suffit
d'ex�cuter sa avec un classement par utilisateur

# sa -u

Nous obtenons ainsi des statistiques d�taill�es de l'activit� syst�me par

utilisateurs. Vous pouvez �galement vous servir de l'option rc.conf
accounting_enable="YES" au m�me effet.

Nous avons �galement a notre disposition la famille syslog, au premier rang

de laquelle nous trouvons syslogd qui nous permet d'enregistrer les messages
d'erreurs et autres messages syst�mes dans le r�pertoire /var/log. Pour
l'activer, nous �ditons encore une fois rc.conf pour y ajouter les entr�es
suivantes :

syslogd_enable="YES"
syslogd_flags="-ss -m 0"
Nous avons de plus ajoute des flags faisant en sorte que le daemon syslog
fonctionne en secure mode sans possibilit� de log ou de transmission depuis
l'ext�rieur. Puis pour affiner l'enregistrement des messages, nous allons
editer /etc/syslog.conf. Syslog.conf poss�de toute une syntaxe particuli�re :

o Les blocs de directives sont classes par programme

o les directives sont de la forme facility.level suivi de la destination des
messages qui peut aussi bien etre un fichier qu'un utilisateur ou un
p�riph�rique.

Les diff�rentes facilities sont :

- AUTH, rapporte les messages du syst�me d'autorisation comportant des
programmes tel que login, su ou getty
- AUTHPRIV, est similaire a AUTH mais permet de limiter la lecture du fichier
de log
- CRON, est relatif au script cron aborde plus bas
- DAEMON, est relatif aux daemons syst�me qui ne beneficient pas d'un champ
facility d�di�
- FTP, se reporte aux daemons ftpd et tftpd
- KERN, rapporte les messages g�n�r�s par le kernel
- LPR, est relatif � tous les p�riph�riques et outils d'impression tels que
lpr, lpc, lpd
- MAIL, permet de loguer les messages relatifs au courrier
- NEWS, similaire a MAIL mais pour usenet
- SECURITY, concerne les sous syst�mes de s�curit� tels que IPF ou ipfw
- SYSLOG, est relatif aux messages g�n�r�s par syslogd lui-m�me
- USER, indique les messages issus de processus utilisateur ne relevant
d'ancune des cat�gories pr�c�dentes, c'est donc la valeur par d�faut si rien
n'est sp�cifi�.
- UUCP, d�signe la facility se rapportant au protocole Unix-to-Unix Copy
Program
- local0 � local7, d�signent des facilities variables qui peuvent �tre utilis�s
ponctuellement par certains softs
- * l'asterisque repr�sente ici l'ensemble des entr�es pr�c�dentes

Suivis du champ level :

- EMERG, alerte g�n�rale, habituellement diffus�e � tous les utilisateurs
- ALERT, d�signe une alerte n�cessitent une attention/correction imm�diate
- CRIT, conditions critiques telles que des probl�mes de p�riph�riques
- ERR, relatif aux messages d'erreur
- WARNING, relatif aux messages d'alertes basiques
- NOTICE, d�signe un �v�nement pas forcement en rapport avec un erreur mais qui
peut demander une gestion particuli�re
- INFO, g�n�re de simples messages � titre d'information
- DEBUG, se rapporte � des messages permettant d'approfondir le compr�hension
du fonctionnement d'un logiciel et donc �ventuellement de le debugger en cas
de probl�me
- NONE, permet de d�sactiver ce champ

Nous pouvons �galement utiliser des op�rateurs de comparaison comme < (plus
petit que), = (�gal), et > (plus grand que) afin de pr�ciser plusieurs niveaux
de logging pour un m�me facility.

------------------------------------ SNiP -------------------------------------

# facility destination
*.=<notice /var/log/messages
*.=<crit root

auth,authpriv.* /var/log/authlog
cron.info /var/log/cron
mail.info /var/log/maillog
kern.* /var/log/kernel
security.* /var/log/security
security.=<err /dev/console

!ppp
*.* /var/log/ppp.log
!ipfw
*.* /var/log/ipfw.log
!sudo
*.* /var/log/sudo.log
!racoon
*.* /var/log/racoon.log
!nessusd
*.* /var/log/nessus.log
!argus
*.* /var/log/argus.log

# configuration syslog � ajouter dans la jail

#!apache
#*.* /var/log/access_log
#!bind
#*.* /var/log/named
------------------------------------ SNiP -------------------------------------

Pour pr�venir l'augmentation exponentielle des fichiers de logs mis en place

plus haut, nous avons a notre disposition newsyslog qui permet de creer un
nouveau fichier de log et m�me de l'archiver (Z pour gzip ou J pour bzip2), de
sp�cifier combien de fichiers de log suppl�mentaires sont autorises (count), a
partir de quelle taille (size en ko) ou combien de temps (time) archiver - ce
qui peut aussi bien �tre un intervalle qu'une date, ou encore les droits de ses
fichiers (mode). Nous pouvons ainsi obtenir un archivage logique au niveau de
l'espace et du temps et plus ais�ment g�rable par l'administrateur. Notez que
l'heure d'archivage est encod�e selon le format ISO 8601 qui nous donne :

ccyymmddThhmmss
20010915 000000 ou bien,
le 15 septembre 2001 � minuit. Ce format pouvant �tre simplifier en retirant
les champs superflus.

Enfin vous avez la possibilit� de sp�cifier un chemin pour obtenir le PID d'un
daemon particulier ainsi que la possibilit� de lui envoyer un signal (HUP par
d�faut) permettant d'�viter les conflits autour du fichier de log.

------------------------------------ SNiP -------------------------------------

# logfilename [owner:group] mode count size time flags
/var/log/maillog 440 10 * @T00 J
/var/log/messages 440 15 100 * J
/var/account/acct 440 15 * @T00 J
/var/log/cron 440 10 40 * J
/var/log/ppp.log 440 10 40 * J
/var/log/nessus.log 440 10 40 * J
/var/log/alias.log 440 10 40 * J
/var/log/authlog root:wheel 400 10 20 @T00 J
/var/log/security root:wheel 400 10 20 @T00 J
/var/log/ipfw.log root:wheel 400 10 20 @T00 J
/var/log/sudo.log root:wheel 400 10 20 @T00 J
/var/log/racoon.log root:wheel 440 10 20 * J
#/var/log/access_log www:wheel 1440 10 40 * J
#/var/log/named named:wheel 1440 10 40 * J
/var/log/wtmp 440 15 * @01T01 B
------------------------------------ SNiP -------------------------------------

Une astuce int�ressante � mettre en pratique mais peu utilis�e consiste en une
synchronisation NTP. NTP signifie Network Time Protocol et permet a une machine
cliente de synchroniser son horloge sur un serveur de strate N lui-m�me se
synchronisant sur un serveur de strate sup�rieure ou directement sur un serveur
de r�f�rence. Le client peut aussi bien d�cider de se synchroniser � un serveur
de r�f�rence directement. C'est cette architecture pyramidale qui caract�rise
NTP. Maintenant qu'est ce que peut bien venir faire NTP dans la configuration
du syst�me de logging ? Et bien dans un avenir tr�s proche la corr�lation de
log a la recherche d'attaques ou d'information sur des attaques detectees par
un autre moyen se fera de mani�re centralis�e et dans ce cadre, une corr�lation
efficace doit se baser sur un timestamp fiable et universel a une portion de
r�seau concern�. Par ailleurs les applications critiques comme les serveurs
DNS ou les serveurs de services SMTP/NNTP fournissant une r�f�rence temporelle
a un utilisateur se doivent d'�tre � l'heure. Pour configurer notre machine
cliente, la configuration est extr�mement simple sous FreeBSD. Il nous suffit
d'�diter rc.conf et d'y placer les 2 lignes suivantes :

ntpdate_enable="YES"
ntpdate_flags="ntp-sop.inria.fr"

Enfin, il y a un outil que ne fait pas partie du syst�me proprement dit mais qui
peut s'av�rer grandement utile dans la surveillance et l'audit du r�seau et du
trafic, il s'agit d'Argus, un Audit Record Generation and Utilization System.
Argus est un programme userland agissant d'une mani�re similaire � un sniffer
en capturant le trafic passant sur une interface r�seau et g�n�rant des
rapports d'audit. Pour la capture du trafic, Argus se base sur TCPdump et la
libpcap. Concernant cet outil, vous trouverez un howto int�ressant sur
http://minithins.net ou http://www.hsc.fr/ressources/breves/argus_fr.html.en.

Par ailleurs, toutes ces configurations vont consid�rablement augmenter les

donn�es � analyser et auditer. C'est pourquoi nous vous recommandons de tester
et de comparer plusieurs outils d'analyse de logs parmi lesquels :
o ASAX, ftp://ftp.info.fundp.ac.be/pub/projects/asax
o Abacus Logcheck, http://www.psionic.com/abacus/logcheck
o SWATCH, http://www.oit.ucsb.edu/~eta/swatch/
o logsurfer, http://www.cert.dfn.de/eng/logsurf/

2.6. cron

Cron est l'un des outils Unix les plus classiques et les plus utiles qui soient
puisqu'il va nous permettre de lancer une t�che pr�cise � une date pr�cise.
Cron est de plus lanc� d�s le d�marrage puis tourne automatiquement en mode
daemon et se r�veille toutes les minutes pour v�rifier s�il a une t�che �
effectuer dans la minute � venir et, en passant, note toute modification de la
crontab. La crontab repr�sente le fichier depuis lequel cron va chercher les
informations, les commandes qu'il doit ex�cuter. Cron cherchera cette crontab
dans /var/cron/tab puis /etc/crontab.

Nous �ditons tout d'abord rc.conf afin de nous assurer que cron se lance bien.
Nous v�rifions et si besoin est ajoutons la ligne suivante :

cron_enable="YES"

Puis, pour ajouter de nouvelles entr�es � cron, il nous suffit d'�diter la

crontab. Cependant, m�me si la crontab suit une logique �vidente, elle
n�cessite une certaine syntaxe.

mm[0-59] hh[0-23] jour_du_mois[0-31] mois[1-12] jour_de_la_semaine[0-7]

Cette syntaxe �tant accompagn�e de quelques options bien pratiques telles que
l'indefinition (*), les listes (1,2,3,4) ou encore la fr�quence soit au sein
d'un champ(0-23/2) soit de mani�re g�n�rale gr�ce aux options :

@reboot, pour le lancement � chaque d�marrage

@yearly ou @annually, pour un lancement annuel
@monthly, pour un lancement mensuel
@weekly, pour un lancement hebdomadaire
@daily ou @midnight, pour un lancement quotidien
et @hourly, pour un lancement toutes les heures.

# ee /etc/crontab

------------------------------------ SNiP -------------------------------------

# vous avez la possibilite de specifier avec quel shell executer les commandes
SHELL=/bin/sh
# cette option permet d'indiquer a cron qui prevenir en cas de probleme
MAILTO=root
#
# update des plugins Nessus chaque semaine
@weekly nessus-update-plugins
# verification d'integrite mtree tous les semaines
@weekly mtree -x -i -f bin.spec | mail -s 'mtree /bin \
results' root
@weekly mtree -x -i -f sbin.spec | mail -s 'mtree /sbin \
results' root
@weekly mtree -x -i -f libexec.spec | mail -s 'mtree \
/usr/libexec results' root
@weekly mtree -x -i -f lib.spec | mail -s 'mtree /usr/lib \
results' root
@weekly mtree -x -i -f sharelib.spec | mail -s 'mtree \
/usr/share/lib results' root
@weekly mtree -x -i -f boot.spec | mail -s 'mtree /boot \
results' root
# accompagn�e d'une v�rification des services par lsof
@weekly lsof -niU
# et d'une v�rification KSEC
@daily ksec -i interface -b -k -p
# update ports tree uniquement pour l'environnement host
@monthly make update PORTSFILE
# newsyslog
@hourly newsyslog
# ntpdate quotidiennement si vous avez des uptimes importants
@daily ntpdate ntp-sop.inria.fr
# lancement de racoon au d�marrage
@reboot racoon -f /etc/racoon.conf
------------------------------------ SNiP -------------------------------------

Voil�, une crontab utile et de la maintenance en moins !

2.7. ipfw et natd

Dans ce chapitre nous allons aborder un m�canisme de s�curit� extr�mement

utilis� de nos jours, � savoir le firewalling. Le firewalling peut se traduire
par plusieurs aspects allant du packet filtering sobre mais efficace aux
complexes mais utiles proxies applicatifs. Afin d'illustrer nos propos et
d'appliquer le firewalling � notre syst�me, nous utiliserons ipfw livr� avec
FreeBSD et que nous avons activ� gr�ce � quelques options kernel au tout d�but
de notre configuration. Beaucoup de monde se laisse s�duire par IPFilter. La
raison g�n�ralement avanc�e est son comportement dit stateful qui doit
permettre de suivre une connexion afin d'effectuer un meilleur filtrage sur
l'ensemble de cette connexion. Cependant ipfirewall est int�gr� directement �
FreeBSD ce qui nous assure d�j� de bonnes performances au niveau r�seau. Par
ailleurs, l'option keep-state de ipfw impliquant la cr�ation automatique d'une
state table permettant le suivi des flux pour le filtrage de paquets. La state
table et les r�gles ipfw qui vont avec, cr�ent pour chaque paquet que 'match'
une r�gle une nouvelle r�gle dynamique permettant de suivre - certes de mani�re
moins tatillonne qu'IPFilter - et autoriser la connexion. Pour ce faire, ipfw
utilise notamment pour la OSI 4 un m�canisme dit de lifetime qui permet de
conserver une r�gle dynamique active en attente d'un nouveau paquet qui
relancera la d�cr�mentation de ce lifetime. Si le lifetime arrive � zero sans
nouveau paquet, alors la r�gle dynamique dispara�t et les paquets sont refus�s.
Les entr�es sysctl suivantes vous permettent de sp�cifier la dur�e du lifetime
correspondant � chaque �tat TCP, UDP et autres. Puis vous pouvez configurer la
taille de la table hashage destin�e aux r�gles dynamiques de votre ruleset,
cette modification ne prenant effet qu'apr�s un flush. Enfin, la derni�re
entr�e fait suite � l'application d'un patch
(http://people.freebsd.org/~cjc/ipfw_verbose_stable.patch) permettant
d'augmenter encore la verbosit� d'ipfw en ajoutant � l'affichage dans les logs
des champs DiffServ, IP ID et TTL (en sus des classiques adresses et ports
source et destination), les champs ack number, sequence number et TCP flags.

# sysctl -w net.inet.ip.fw.dyn_ack_lifetime=300
# sysctl -w net.inet.ip.fw.dyn_syn_lifetime=20
# sysctl -w net.inet.ip.fw.dyn_fin_lifetime=10
# sysctl -w net.inet.ip.fw.dyn_rst_lifetime=5
# sysctl -w net.inet.ip.fw.dyn_udp_lifetime=15
# sysctl -w net.inet.ip.fw.dyn_short_lifetime=30
# sysctl -w net.inet.ip.fw.dyn_max=1000
# sysctl -w net.inet.ip.fw.verbose=2

Bien qu'elles ne soient pas abord�es ici m�me, sachez qu'IPF dispose d'entr�es
similaires une fois install�, sous net.inet.ipf.* .

Pour voir les r�gles actuellement appliqu�es et notamment les r�gles

dynamiques, entrez :

# ipfw show

N'oubliez pas �galement d'editer rc.conf afin d'y ajouter les lignes concernant
le firewalling telles que firewall_enable="YES", firewall_quiet="YES",
firewall_logging="YES" et firewall_type="simple". Pour ins�rer des r�gles dans
le ruleset, vous pouvez soit �diter la section simple de /etc/rc.firewall, soit
utiliser la commande ipfw selon le sch�ma suivant

ipfw command <number> action <protocol> from <host> <port> to <host> <port>
<ifspec>

- Les commandes peuvent �tre 'add' pour ajouter une r�gle, 'delete' pour
supprimer une r�gle individuellement et 'flush' pour la totalit� des r�gles,
ainsi que 'show' ou 'list' pour avoir les r�gles actuelles.
Chaque r�gle doit avoir un num�ro unique pour �viter la confusion et les
r�gles sont class�es selon l'ordre du matching.
- Les actions peuvent �tre 'allow' pour laisser passer un paquet, deny pour le
refuser silencieusement et 'reject' pour envoyer un icmp host unreachable
(erreur sp�cifiable avec les actions 'unreach' et 'reset'), 'check-state'
afin de v�rifier une correspondance avec les r�gles dynamiques, ou encore
'fwd' suivi de l'IP et �ventuellement du port si vous poss�dez des IP
routables. Nous avons �galement la possibilit� de logger - comme action
unique ou suppl�mentaire aux pr�c�dentes - avec 'log' auquel vous pouvez
ajouter 'logamount' pour overwriter l'option IPFIREWALL_VERBOSE_LIMIT.
- Les protocoles peuvent �tre 'all' ou 'ip' pour faire correspondre tous les
protocoles, ou bien le nom ou num�ro du protocole d�sir� en accord avec
/etc/protocols.
- Nous pouvons ensuite pr�ciser la source apr�s le champ 'from', la destination
apr�s le champ 'to' ainsi que les ports juste apr�s l'adresse source ou de
destination. Notez �galement la pr�sence de 'me' permettant de r�cup�rer l'IP
de notre firewall depuis ifconfig ce qui s'av�re tr�s utile en cas de
configuration dynamique. Enfin, pour les ports ou les adresses, IPFW supporte
d�sormais les op�rateurs logiques.
- Les mots cl�s ifspec nous permettant de travailler sur les interfaces. Nous
pouvons par exemple sp�cifier le matching des paquets uniquement en ingress
avec 'in' et en egress avec 'out', ou les interfaces v�rifi�es avec 'via'
suivi de l'interface, recv pour ne v�rifier que l'interface de r�ception et
xmit pour ne v�rifier que l'interface d'envoi.
- Pour la stateful inspection, 'keep-state' annonce un suivi dynamique pour ce
filtre, 'setup' matche les paquets avec le flag SYN uniquement, 'etablished'
concerne les paquets avec les flags ACK ou RST. Mais vous pouvez �galement
pr�ciser des 'ipoptions' (lssr, ssrr, rr, ts) ou 'tcpoptions' (mss, window,
cc, sack, ts) ainsi que des 'tcpflags' (fin, syn, rst, psh, ack et urg) ou
des 'icmptypes' (0, 3, 4, 5, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18).
D'autre part, le mot cl� 'limit' a �t� introduit r�cemment (4.5-RELEASE) pour
permettre de limiter le nombre de connexions simultan�es par association pour
un filtre donn�, ceci en pr�cisant l'adresse et/ou le port source, l'adresse
et/ou le port de destination puis la limite de connexions. Sachez enfin que
vous pouvez au niveau du firewall lui-m�me filtrer les utilisateurs via les
options 'uid' et 'gid' suivis de leur valeur.
Enfin, face � la menace d'abus de trust relationship par les tunnels IPSEC
ESP, il est d�sormais possible, depuis FreeBSD 4.9, de filtrer les connexions
initi�es via de tels tunnels, ce gr�ce au mot-cl� 'ipsec'. Attention, cette
option n'est valable que si vous utilisez des tunnels gif pour monter votre
tunnel.

Pour obtenir la totalit� des champs et notamment une description de

l'utilisation de dummynet comme traffic shaper basique, reportez vous � la page
de man d'ipfw. Mais dans ce domaine nous vous recommandons vraiment ALTQ
d�velopp� dans le cadre du projet KAME (et donc r�guli�rement merg�)
impl�mentant notamment les disciplines CBQ, WFQ/SFQ ou encore HFSC ainsi que
les algorithmes RED et ses variantes RIO ou Blue et enfin les extensions ECN,
RSVP (avec CBQ et HFSC) ainsi qu'un support pour le mod�le DiffServ. Plus
d'informations sur le site d'ALTQ,
http://www.csl.sony.co.jp/person/kjc/software.html#ALTQ. L'int�gration
d�finitive de ALTQ au main tree FreeBSD est en cours pour la release 5.0

Notez pour en finir avec les commandes ipfw qu'il existe un int�ressant patch
depuis FreeBSD 4.3 dit lifetime qui permet d'imposer une timeout � une
transmission via une r�gle du firewall qui la bloquera une fois ce timeout
atteint. Ce patch n'�tant pas int�gr� au syst�me de base, nous ne nous
attarderons pas sur son utilisation. Vous pourrez trouver toutes les
informations n�cessaires � l'installation du patch et � l'utilisation du nouveau
keyword � http://www.aarongifford.com/computers/ipfwpatch.html.
Lorsque vous lancez votre machine avec les options activant le firewall pour la
premi�re fois, environ 200 r�gles basiques sont automatiquement
g�n�r�es. Nous commen�ons donc par purger nos r�gles :

# ipfw flush

Au d�but du ruleset, nous d�finissons quelques variables comme la commande ipfw

avec l'option -q pour un output discret, le masque de notre r�seau interne,
l'adresse de notre jail, et nos interfaces d'entr�e et de sortie.

Nous rejetons ensuite sur l'interface d'entr�e tous les paquets avec pour source
une adresse r�serv�e non routable ou bien l'adresse de notre r�seau interne, et
nous journalisons ces cas manifestes de spoofing. Ces adresses sont r�pertori�es
sur le site de l'IANA et dans la RFC 1918.

Puis nous faisons diverger le trafic pour passer par natd pour la translation
d'adresses et de ports vers nos adresses priv�es. Cette r�gle est suivie de la
v�rification de chaque paquet contre la state table pour savoir si
il appartient ou non � une connexion d�j� accept�e. Nous pouvons ensuite
rejeter tous les paquets en �tat TCP �tabli ou les fragments IP puisqu'ils
seront assur�s de ne pas faire partie d'une connexion en cours.

Puis nous autorisons certaines communications comme DNS dont nous aurons repris
les adresses dans /etc/revolv.conf, suivi de l'administration de la machine via
SSH, et enfin nous autorisons Racoon, Argus et Nessus � communiquer. Pour les
clients derri�re le firewall, nous autorisons aussi en sortie les connexions
ftp, smtp, ssh, http, pop3, ntp, imap ainsi que https, ircs, pop3s.

Viennent ensuite les restrictions ICMP utilis� aussi bien en scanning qu'en
DoS. Nous laissons passer depuis l'ext�rieur les les echo reply, destination
unreachable, time exceeded, parameter problem, et timestamp reply. Vers
l'ext�rieur, nous autorisons les echo request, time exceeded (fragment
reassembly) et les timestamp request. Avec ceci, nous avons le minimum pour
assurer le path discovery, la v�rification de connectivit� et la d�tection.

Pour appliquer maintenant un filtrage de paquets aux services fournit par une
jail, nous faisons comme si c'�tait un filtrage sur l'environnement h�te,
seulement nous y substituons l'alias priv�e de la jail que nous filtrons en
passant par l'interface de loopback lo0.

Lors de la cr�ation de vos r�gles, faites attention � l'ordre dans lequel vous
les placez dans votre ruleset, aux interfaces sur lesquelles il faut les
appliquer et � leur destination. Comme sp�cifi� par les implementations notes
de ipfw(8), le nombre de fois o� un paquet est inspect� varie : de une fois
pour les paquets ayant une extr�mit� en local et pour les paquets bridg�s, �
2 fois pour les paquets dont les 2 extr�mit�s sont locales ou pour les paquets
forward�s. La seule mani�re de changer ce comportement est � travers sysctl :

# sysctl -w net.inet.ip.fw.one_pass=1

Mais soyez extr�mement prudent dans ce cas lors de l'�criture de ces r�gles
pour ne pas laisser entrer n'importe quel paquet construit sp�cialement apr�s
analyse des r�gles. Prendre en compte toutes ces informations, c'est v�rifier
qu'un paquet sera bien inspect� et au bon endroit.

Pour finir, nous refusons tout autre trafic que celui express�ment autoriser et
pour plus de s�ret�. Voir ci-dessous le fichier /etc/rc.firewall final.

------------------------------------ SNiP -------------------------------------

# variables ...
fwcmd="ipfw -q"
net="192.168.0.0"
mask="255.255.255.0"
jail="192.168.0.2"
intif="fxp0"
extif="fxp1"
forbidden="192.168.0.0/16,172.16.0.0/12,10.0.0.0/8,127.0.0.0/8,224.0.0.0/3,\
169.254.0.0/16,0.0.0.0/8,192.0.2.0/24,204.152.64.0/24"

${fwcmd} -f flush

# adresses r�serv�es
${fwcmd} add 201 deny log all from ${forbidden},${net}:${mask} to any in via \
${extif}

# divert vers natd

${fwcmd} add 300 divert 8668 all from any to any in via ${extinf}

# v�rification par rapport � la state table

${fwcmd} add 400 check-state
${fwcmd} add 401 deny tcp from any to any in established
${fwcmd} add 402 deny ip from any to any in frag

# communication DNS, SSH, Racoon, Argus et Nessus

${fwcmd} add 403 allow udp from ${net}:${mask} to primary_DNS 53 in keep-state
${fwcmd} add 404 allow tcp from any to me 22 keep-state setup limit src-addr 5
${fwcmd} add 405 allow udp from any 500 to any keep-state
${fwcmd} add 406 allow udp from any to any 500 keep-state
${fwcmd} add 407 allow tcp from any to any 561,3001 keep-state limit dst-addr 2

# communications vers des serveurs classiques

${fwcmd} add 408 allow tcp from ${net}:${mask} to any \
20,21,22,25,80,110,123,143,443,994,995,6667 keep-state setup

# limitations ICMP (ping, Van Jacobson's traceroute...)

${fwcmd} add 500 allow icmp from any to ${net}:${mask} in icmptypes \
0,3,11,12,13,14
${fwcmd} add 501 allow icmp from ${net}:${mask} to any out icmptypes 1,8,11
${fwcmd} add 502 allow udp from ${net}:${mask} to any in 33400-33500
${fwcmd} add 503 deny log icmp from any to any

# redirection services jail

${fwcmd} add 602 allow udp from any to ${jail} 53 in keep-state via lo0
${fwcmd} add 603 allow tcp from any to ${jail} 80,443 in keep-state setup via \
lo0

# Restrictive stance : everything not explicitely allowed is forbidden.

${fwcmd} add 900 deny log all from any to any
${fwcmd} add 901 deny log all from any to ${jail} via lo0
------------------------------------ SNiP -------------------------------------

Pour que ces r�gles soient appliqu�es, vous devez soit redemarrer, soit
relancer init qui initialisera ces r�gles.

# kill -HUP init

Le NAT pour Network Translation Adress est un m�canisme � l'origine cr�� pour
palier � la p�nurie d'adresses IP disponibles. Il permet d'utiliser une gateway
qui pour chaque communication va rediriger les transmissions entre adresses
externes routables et adresses internes non routables en r��crivant les ent�tes
correspondantes et en stockant les informations de correspondances dans une
hash table. Ainsi nous n'utilisons qu'une seule IP routable qui est celle de la
gateway NAT. Le NAT est un m�canisme de partage de connexion int�ressant mais
il ne fera pas l'affaire en cas de load balancing puisque sa m�thode de
queueing est bas� sur un Weighted Round Robin qui sert � tour de r�le chaque
queue en attente, or le NAT par WRR traite la priorit� selon l'impl�mentation
DiffServ Assured Forwarding rejetant ainsi les paquets basse priorit� sous
fortes contraintes. De plus le d�bit de congestion du NAT est assez bas, encore
plus si vous utilisez natd qui est userland entra�nant une copie depuis le
kernel vers le userland. Pr�f�rez ipnat/ipf en module kernel pour de meilleures
performances.

L'autre couple �tant ipfw/natd, nous allons maintenant voir une configuration
minimale de natd afin de relayer les requ�tes de notre h�te vers notre jail ou
toute autre machine se trouvant derri�re notre FreeBSD.

Pour commencer, nous �ditons le fichier rc.conf pour y ajouter les lignes
suivantes

gateway_enable="YES"
natd_enable="YES"
natd_interface="fxp0"
natd_flags="-f /etc/natd.rules"

Ainsi natd sera lanc� � chaque d�marrage avec comme fichier de configuration
natd.rules, que nous allons maintenant �diter. Pour plus d'informations sur les
r�gles utilis�es, reportez vous � la man page. Nous ne faisons qu'une rapide
introduction en rapport avec notre configuration s�curis�e. Cependant, notez
que la redirection via natd peut se faire � partir de l'adresse avec
redirect_adress, par port avec redirect_port et par protocoles avec
redirect_proto. Une derni�re r�gle peut s'av�rer tr�s utile pour les
utilisateurs d'IRC et FTP : la r�gle punch_fw suivi de basenumber:count
respectivement le num�ro de la r�gle de d�part suivi du nombre de r�gles
dynamiques pouvant �tre cr��es.

------------------------------------ SNiP -------------------------------------

log yes
deny_incoming no
use_sockets yes # alloue une socket limitant les conflits de ports
# dynamiques
same_ports yes # tente d'utiliser le m�me port pour la translation
verbose no
port natd
unregistered_only yes # NAT uniquement pour les adresses type RFC 1918
log_ipfw_denied yes # log les paquets non r�-inject� pour cause de
# blocage par ipfw (utile pour debugger)

# DNS
redirect_port udp jail_IP_alias:53 public_IP_adress:53

# HTTP et HTTPS
# LSNAT > RFC 2391
redirect_port tcp jail_IP_alias:80,443 80,443
redirect_adress tcp www1_IP:80, www2_IP:80 jail_IP_adress:80

# SSH sur la seconde jail

redirect_port tcp jail_user_IP_alias:22
# static NAT pour d'autres machines
redirect_address internal_IP1 public_IP
redirect_address internal_IP2 public_IP
redirect_address internal_IP3 public_IP
------------------------------------ SNiP -------------------------------------

Notez que natd int�gre naturellement des fonctionnalit�s de suivi de connexions.

Donc, lorsque vous configurez une passerelle pour utiliser natd, il n'est plus
vraiment utile d'utiliser la stateful inspection au niveau d'ipfw. Vous pouvez
simplement configurer un firewall statique et natd s'occupe de l'inspection
d'�tats pour les connexions relay�es. Si vous sentez encore le besoin de
conserver des r�gles keep-state, alors le mot cl� skipto renvoyant � une autre
r�gles peut s'av�rer utile.

3. Outils

Nous allons nous pencher sur certains outils plus ou moins en rapport direct
avec le syst�me mais qui ne sont pas forc�ment disponible par d�faut ou alors
par les ports mais pas � jour, ou encore qui sont une caract�ristique du
syst�me bien sp�cifique. Ainsi nous allons ici d�couvrir quelques outils
permettant de renforcer notre s�curit� aussi bien de mani�re proactive que
r�active.

3.1. TCPdump

TCPdump est l'outil ultime pour sniffer le trafic d'un r�seau afin d'effectuer
son debugging. Il nous permettra de capturer tout ou partie du trafic r�seau
local afin de nous permettre de l'analyser afin de v�rifier le bon
fonctionnement de nos configurations r�seau. Pour ce faire TCPdump se base sur
la couche syst�me BPF pour Berkeley Packet Filter afin d'intercepter les trames
Ethernet et les paquets IP transitant par la machine en mode promiscuous (mode
o� le Network Interface Card ou NIC peut voir l'ensemble du trafic r�seau)
selon des expressions bpf similaires aux concepts d'expressions r�guli�res.
Cette m�thode de capture par BPF est fournit par la librairie libpcap
facilitant �norm�ment le d�veloppement de sniffers �volu�s.

TCPdump fournit un nombre d'options impressionnant dont nous aborderons les

plus utiles ici. Tout d'abord � chaque capture nous vous recommandons la
syntaxe suivante :

# tcpdump -X -s 1500 -e -n -i fxp0

Cette ligne de commande permet d'obtenir un dump � la fois en hexa et ascii,

d'une longueur de 1500 octets, affichant les informations d'en-t�te au niveau
de la couche liaison qui sera g�n�ralement Ethernet, nous n'effectuons pas de
r�solution de noms afin de gagner en rapidit�, discr�tion et facilit�
d'analyse ; et enfin nous sp�cifions la NIC sur laquelle �couter ce qui peut
s'av�rer utile lorsque la console admin poss�de plusieurs interfaces ou sert
de passerelle.

La sortie quant � elle se pr�sente - dans le cas d'un paquet TCP ici - sous la
forme d'un timestamp, puis l'Initial Sequence Number suivi du num�ro de
s�quence du paquet, la taille du paquet entre parenth�ses, les flags TCP, le
num�ro d'acknowledgment, la window size, le flag IP renseignant sur l'etat de
la fragmentation et enfin les options TCP. La sortie peut bien s�r varier si
on capture un paquet UDP ou ICMP (avec dans ce dernier cas le type ICMP). Avec
les options d�j� pr�sent�es, nous obtenons �galement dans le dump les headers
de la couche liaison, vous pouvez bien s�r supprimer cette option pour plus de
simplicit�.

Une combinaison d'options �galement int�ressantes et �ventuellement � utiliser

avec les options d�j� vues, est la suivante :

# tcpdump -i fxp0 -l > file && tail -f file

Cette entr�e nous permet de rediriger le trafic captur� sur l'interface

sp�cifi�e vers un fichier 'file' que nous pourrons ensuite voir s'actualiser
par groupe de 10 lignes � l'aide de tail. Ceci permet une surveillance continue
des flux locaux sans surcharger la console. Le nombre de lignes affich�es par
tail devra �tre adapter � la vitesse de transmission du r�seau pour que cette
commande reste utile.

Bien entendu, nous n'avons pas besoin de capturer la totalit� des paquets
lorsque nous ne recherchons qu'une transmission particuli�re afin d'effectuer
du debugging ou autre analyse. Pour cela nous avons la possibilit� d'utiliser
les expressions BPF introduites plus haut. Elles nous permettent de tester
un octet donn� d'un paquet IP ou m�me de sa partie TCP/UDP/ICMP. Il est
�galement possible, gr�ce � des expressions bool�ennes de tester un ou
plusieurs bits de chaque octet. Les expressions BPF se placent simplement � la
fin des options de la ligne de commande TCPdump. Les expressions BPF classiques
sont subdivis�es en 3 groupes qui peuvent �tre combin�s entre eux pour
effectuer n'importe quel (ou presque :) matching.

Le premier groupe est constitu� des 'types' qui peuvent �tre 'host' pour
recherche une adresse IP ou un domaine, 'net' pour une classe r�seau - ce champ
peut �tre affin� en pr�cisant un 'mask' � sa suite - et 'port' pour un port.
Ces types sont les op�rateurs de base de la capture.
Nous avons ensuite les 'dir' qui sp�cifie la direction � rechercher. Nous avons
ici � notre disposition les mots-cl�s 'src' pour l'origine et 'dst' pour la
destination.
Enfin, nous avons le group 'proto' qui permet de rechercher des paquets
correspondants. Nous y trouvons 'ether' ou 'fddi' pour les couches liaisons
ethernet et assimil�s, 'arp' et 'rarp' pour les protocoles du m�me nom, 'ip' et
ip6' pour les versions d'IP v4 et v6, 'icmp' et 'icmp6' de mani�re similaire et
enfin 'tcp' et 'udp'.
A ces 3 groupes, il nous faut ajouter plusieurs expressions suppl�mentaires
telles que 'gateway' qui permet de matcher un paquet dont l'adresse Ethernet
correspond � l'expression mais pas l'adresse IP source ni destination et donc
d'obtenir les paquets ayant traverser une passerelle donn�e. Nous avons �galement
less
et greater afin de capturer les paquets inf�rieurs ou sup�rieurs � une longueur
donn�e.
Enfin nous avons les classiques op�rateurs logiques or, and et not repr�sentant
l'inclusion, la concat�nation ou l'exclusion.

ping of death
# tcpdump -Xni fxp0 icmp greater 65535

trafic HTTPS et IRCS

# tcpdump -Xni fxp0 (tcp port 443) or (tcp port 994)

Il existe �galement des expressions avanc�es permettant de r�aliser des

op�rations de capture plus fines sur les paquets. La syntaxe d'une expression
BPF est la suivante

proto[offset:longueur] operation logique

o� proto est similaire � un des champs du groupe 'proto' cit� plus haut, offset
d�signe le d�calage du champ � tester par rapport au d�but du champ proto, la
longueur d�signe la longueur du champ � rechercher et l'op�ration logique le
test lui-m�me. Ceci n�cessite une connaissance pr�cise des champs des
diff�rents protocoles ce qui peut se faire apr�s une �tude des RFC
correspondantes. Pour rechercher un champ pr�cis, il est bon de rappeler la
structure d'un datagramme IP et d'un segment TCP en consid�rant le dump
suivant :

4500 003c 0a66 4000 4006 a320 c0a8 0001

c0a8 0002 04c5 0016 801e 78e3 0000 0000
a002 3fc4 fe70 0000 0204 05cc 0402 080a
0014 7e59 0000 0000 0103 0300

4 = IP Version
5 = IP header length
003c = IP total length
0a66 = IP ID
4000 = IP fragmentation (flags puis offset multiple de 8)
40 = IP TTL
06 = IP Protocol
a320 = IP checksum
c0a8 0001 = IP source
c0a8 0002 = IP destination
04c5 = TCP source port
0016 = TCP destination port
801e 78e3 = TCP sequence number
a = TCP data offset
002 = TCP Control bits (flags, ici SYN)
3fc4 = TCP Window Size
fe70 = TCP Checksum
0000 = Urgent Pointer
0204 05cc = TCP Maximum Segment Size (only with SYN)
0402 = TCP SackOK Permitted (only with SYN)
080a 0014 7e59 0000 0000 = TCP Timestamp (champ reply � 0, puisque SYN)
0103 = Padding
0300 = TCP Window Scale (only with SYN)

Pour ne pas avoir � retenir ce lourd sch�ma (qui est juste celui d'un flux
classique), vous pouvez ex�cuter � la suite de votre commande tcpdump et apr�s
un pipe unix, tcpdumpx �crit par Wietse Venema qui commente pr�cis�ment les
donn�es dump�es. Vous pourrez trouver ce programme �
ftp://ftp.porcupine.org/pub/debugging/.

Ci-dessus une s�rie de filtres pr�ts � l'emploi.

* paquets TCP avec flags

SYN : tcp[13] & 2 != 0
ACK : tcp[13] & 16 != 0
FIN : tcp[13] & 1 != 0
RST : tcp[13] & 4 != 0
PSH : tcp[13] & 8 != 0
URG : tcp[13] & 32 != 0

* Christmas Tree Scan

# tcpdump -Xni ed0 '(tcp[13] & 1 != 0) and (tcp[13] & 8 != 0) and
(tcp[13] & 32 != 0)'

* capture d'icmp echo request et replies

 # tcpdump -Xni ed0 '(icmp[0] = 8) or (icmp[0] = 0)'

* paquets IP fragment�s
MF : ip[6] & 32 != 0
DF : ip[6] & 64 != 0
offset : ip[6:2] & 0x1fff != 0

En marge de TCPdump, nous vous recommandons de jeter un oeil aux programmes

suivants inspir�s, bas�s sur TCPdump ou encore servant d'extensions :
o ethereal, http://www.ethereal.org
o Shadow, http://www.nswc.navy.mil/ISSEC/CID/
o NStreams, http://www.hsc.fr/ressources/outils/nstreams/

3.2. Nessus

Nessus est ce qu'on appelle un scanner de vuln�rabilit�s (assessment scanner).

Il a pour particularit� d'effectuer r�ellement les tests correspondant � une
attaque connue contre la machine, et ce en exploitant aussi bien des attaques
logicielles classiques que des erreurs de configuration. Par ailleurs, il est
dot� d'une architecture moderne alliant modularit� et mod�le client-serveur. Le
serveur nessusd effectue les tests tandis que l'interface graphique nessus -
qui peut �tre GTK, Java ou m�me Win32 - permet de s�lectionner les tests et de
lire les rapports de scan en contr�lant le serveur. Cette architecture permet
d'imaginer toutes les configurations comme un daemon distant pour plusieurs
op�rateurs ou un op�rateur pour plusieurs daemons sur plusieurs r�seaux (cette
id�e n'ayant pas �chapp�e aux soci�t�s effectuant des tests d'intrusion en
partant de nessus et en contribuant rarement). Par ailleurs, Nessus est
modulaire, ce qui signifie que chacune des attaques est un plugin en NASL
(Nessus Attack Script Language, un langage � la syntaxe similaire au C pour
l'�criture de tests) ou en C appel� par nessusd pour effectuer les tests.
Les plugins sont g�r�s par une Knowledge Base, v�ritable architecture de
communication inter plugins dans laquelle ils se voient tri�s en fonction de
leur type, d�pendance, besoin ou exclusion et par laquelle ils peuvent partager
des informations afin d'�viter la redondance de tests. Une derni�re
particularit� notable est qu'� travers la KB, il ne tient pas compte du port
scann�, mais uniquement du service �vitant ainsi d'�tre tromp� par des ports
bind�s exotiques.
Nessus va nous servir � v�rifier si nos configurations pr�c�dentes au
niveau r�seau n'ont pas entra�n�es la cr�ation d'erreurs exploitables par
un intrus et �galement v�rifier si nos services et notre syst�me sont
vuln�rables ou pas aux centaines d'attaques que Nessus teste. Il ne nous
restera plus ensuite qu'� prendre les mesures n�cessaires comme patcher
notre machine ou en modifier la configuration.
Vous pouvez r�cup�rer Nessus � http://www.nessus.org ou depuis le ports
tree � /usr/ports/security/nessus-1.2.3. Vous pourriez avoir aussi besoin
de Queso, Nmap ou � l'avenir Whisker ou un IDS qui parse les ruleset Snort
comme Prelude.

En premier lieu, une fois l'installation termin�e, vous devez lancer la

commande nessus-adduser afin d'ajouter un utilisateur au daemon nessus.

------------------------------------ SNiP -------------------------------------

# nessus-adduser
Using /var/tmp as a temporary file holder

Add a new nessusd user

----------------------

Login : eberkut
Authentication (pass/cert) [pass] : pass
Login password : foobar

User rules
----------
nessusd has a rules system which allows you to restrict the hosts
that astro has the right to test. For instance, you may want
him to be able to scan his own host only.

Please see the nessus-adduser(8) man page for the rules syntax

Enter the rules for this user, and hit ctrl-D once you are done :
(the user can have an empty rules set)
^D

Login : eberkut
Password : foobar
DN :
Rules :

Is that ok ? (y/n) [y] y

user added.
------------------------------------ SNiP -------------------------------------

Notez que la syntaxe des r�gles d'acc�s est plut�t simpliste puisqu�elle
compte comme r�gles deny pour emp�cher le scan, accept pour l'autoriser et
default pour d�finir la policy par defaut � deny ou accept. Pour chaque r�gle,
vous sp�cifiez une adresse IP �ventuellement suivie d'un netmask en notation
CIDR ou la variable client_ip d�signant automatiquement la machine source du
client. Vous pouvez de plus vous servir de nessusd.users pour d�finir des
r�gles par utilisateurs (authentifi�s par password ou cl�). Voir nessusd(8)
pour plus de d�tails.

# password
eberkut:foobar
# rules
accept client_ip
default deny

Ces r�gles ainsi que d'autres options sont encore configurables apr�s
nessus-adduser par l'interm�diaire de nessusd.conf que nous allons d�cider
de conserver dans /etc plut�t que dans le r�pertoire nessus.

# cp /usr/local/nessus/etc/ /etc/nessus/ && cd /etc/nessus/

# ee nessusd.conf

------------------------------------ SNiP -------------------------------------

# chemin d'acc�s aux plugins
plugins_folder = /nessus/lib/nessus/plugins

# nombre de tests simultan�s, doit �tre �gal au nombre de devices bpf

max_threads = 20
track_iothreads = yes

# log file
logfile = syslog

# log tous les d�tails des attaques ?

log_whole_attack = yes
# log les noms de plugins � leur chargement ?
log_plugins_names_at_load = yes

# dump file for debugging purpose

dumpfile = /nessus/var/nessus/nessusd.dump

# rules file
rules = /etc/nessus/nessusd.rules

# user database
users = /etc/nessus/nessusd.users

# CGI path
cgi_path = /cgi-bin

# espace de ports pour nmap

port_range = 1-32768

# optimize test
optimize_test = yes

# language (english or francais)

language = francais

# Crypto options
negot_timeout = 600
force_pubkey_auth = yes
# peks has been deprecated, and the author of this document does'nt have any
# box to install Nessus and update this part of the configuration file. Sorry
peks_username = nessusd
peks_keylen = 1024
peks_keyfile = /etc/nessus/nessusd.private-keys
peks_usrkeys = /etc/nessus/nessusd.user-keys
peks_pwdfail = 3
cookie_logpipe = /etc/nessus/nessusd.logpipe
cookie_logpipe_suptmo = 2

# optimization
# read timeout for the test sockets
checks_read_timeout = 15
# espace entre 2 tests contre le m�me port en secondes
delay_between_tests = 5
------------------------------------ SNiP -------------------------------------

Pour la totalit� des tests impliquant l'utilisation de SSL ainsi que si vous
avez d�cid� d'utiliser l'authentification client/serveur par certificats, vous
allez devoir g�n�rer une certificat. Nessus dispose pour ce faire d'un script
nessus-mkcert (et nessus-mkcert-client pour g�n�rer une paire certificat/cl�
pour votre client).

------------------------------------ SNiP -------------------------------------

# nessus-mkcert
This script will now ask you the relevant information to create the SSL
certificate of Nessus. Note that this information will *NOT* be sent to
anybody (everything stays local), but anyone with the ability to connect to your
Nessus daemon will be able to retrieve this information.
CA certificate life time in days [1460]:
Server certificate life time in days [365]:
Your country (two letter code) [CH]: FR
Your state or province name [none]:
Your location (e.g. town) [Paris]:
Your organization [Nessus Users United]: CNS

Congratulations. Your server certificate was properly created.

/usr/local/etc/nessus/nessusd.conf updated

The following files were created :

. Certification authority :
Certificate = /usr/local/com/nessus/CA/cacert.pem
Private key = /usr/local/var/nessus/CA/cakey.pem

. Nessus Server :
Certificate = /usr/local/com/nessus/CA/servercert.pem
Private key = /usr/local/var/nessus/CA/serverkey.pem

Press [ENTER] to exit

------------------------------------ SNiP -------------------------------------

Si vous ne d�sirez pas utiliser SSL, placez ssl_version � none dans

nessusd.conf, ou bien changez les makefiles de nessus-libraries et nessus-core
pour ajouter -disable-cipher aux ./configure. Plus d'informations dans
README_SSL disponibles dans nessus-core.

Pour lancer le daemon nessus maintenant configur�, il ne vous reste plus qu'�
ex�cuter

# nessusd -c /etc/nessus/nessusd.conf -D

Notez aussi l'option -L permettant de lister la base d'utilisateurs.

Du c�t� du client, vous disposez comme expliqu� pr�c�demment de diverses

interfaces graphiques client, � savoir une X11 en GTK, une Java et m�me
2 Win32. Cependant, souvenez-vous que nessusd ne fonctionne que sous unix.
Lorsque vous lancez le client nessus pour la premi�re fois, il va s'occuper
de g�n�rer une paire de cl�s puis vous demandera une passphrase. La seconde
fois, vous n'aurez plus qu'� rentrer votre passphrase. Vous �tes ensuite face
� une fen�tre de login vous permettant de vous connecter � un nessusd
distant (champs Nessusd Host, Port, Encryption et Login).
Vous �tes ensuite dirig� vers le panel Plugins vous permettant de s�lectionner
les plugins de test. La liste sup�rieure classe les plugins par types, et sont
affich�s dans la liste inf�rieure vous permettant de les s�lectionner ou non.
Vous disposez aussi des boutons Enable All pour un scan complet, Enable all
but dangerous plugins pour ne pas effectuer les tests comme les DoS capables
de planter une machine faible (i.e. Windows) ou Disable All.
Pour certains plugins, vous aurez besoin de sp�cifier des arguments
suppl�mentaires comme pour le POP2 overflow, le FTP privilege escalation et
surtout la configuration queso ou nmap -- peut �tre � l'avenir Whisker, le
CGI scanner par Rain Forrest Puppy. Ceci peut �tre fait dans le panel Prefs.
Vous avez ensuite le panel Scan options dans lequel vous pouvez configurer
le Port Range, le nombre maximum de threads concurrents, ou le chemin
d'acc�s au CGI - ceci �tant d�j� configur� dans le fichier configuration
nessusd - plus quelques autres fonctionnalit�s et surtout les options du
port scanning (avec nmap)
Puis viens le panel Target Selection dans lequel vous sp�cifiez, sous forme
d'IP avec ou sans netmask ou de domaine, la ou les machines que vous
souhaitez scanner, s�par�es par des virgules. Vous pouvez �galement avoir
des fichiers tout pr�t sp�cifiant ces r�gles et les faire lire par Nessus.
Vous trouvez ensuite le panel User dans lequel vous pouvez g�rer votre cl�
ou changer votre passphrase et �galement sp�cifier ici encore des r�gles de
scanning cette fois sp�cifique � ce scan en 'reject' les h�tes � ne pas
scanner.
Une fois tous ces panels pass�s en revue, il ne vous reste plus qu'� faire
un start scan et � attendre les r�sultats qui seront pr�sent� sous forme
d'arbres. Vous pourrez ensuite les sauvegarder sous la forme d'un m�me
report Nessus (.nsr) ou bien sous forme de fichier html avec graphiques,
de fichier postscript ou encore de fichier LaTeX et de nombreux autres.
Dans les versions � venir, vous pourrez m�me directement exporter les
r�sultats sous forme de r�gles Snort et ainsi utilisez un IDS compatible
comme Snort ou Prelude pour surveiller vos machines vuln�rables.

Nous ajouterons enfin une petite parenth�se sur quelques fonctionnalit�s pour
le moment experimentales mais qui seront officiellement mises en place lors de
la release 1.1.0. La premi�re est la sauvegarde de Knowledge Base. En effet,
les informations receuillies et partag�es � travers la KB sont lib�r�es de la
m�moire apr�s chaque scan n�cessitant de refaire tout le processus
d'information gathering � chaque fois. Si vous d�sirez scanner r�guli�rement
votre r�seau, vous pourez pr�f�rer utiliser l'option du panel KB de l'interface
permettant d'activer la sauvegarde de la KB. Avant la version 1.1.0, cette
option n'existe que si vous avez compil� Nessus-core avec

# ./configure --enable-save-kb

Dans ce m�me panel KB, vous pouvez ensuite sp�cifier si il est n�cessaire de
scanner la totalit� des h�tes, uniquement ceux d�j� scann�s pr�c�demment ou
bien uniquement les h�tes nouveaux jamais scann�s. Par ailleurs vous pouvez
sp�cifier la r�utilisation de l'ancienne KB qui sera alors recharg�e en m�moire
et avec elle pr�ciser quels plugins vous ne voulez pas voir r�ex�cut�s : ne pas
refaire les scans, ne pas refaire les �tapes d'information gathering, ne pas
refaire les attaques ou bien ne pas refaire les DoS. Enfin, vous avez la
possibilit� de d�finir une limite de temps pendant laquelle l'ancienne KB est
valable en secondes.
Une autre fonctionnalit� exp�rimentale all�chante est la possibilit�
d'effectuer des scans d�tach�s, sans intervention du client. Apr�s l'activation
de la sauvegarde de KB, nous disposons dans le panel Scan options de nouvelles
entr�es : detached scan signifiant que le client n'obtiendra pas les donn�es en
temps r�el, continuous scan fait recommencer nessusd apr�s chaque fin de tests,
send results to this email adress permet de sp�cifier une adresse � laquelle
envoyer les r�sultats et enfin delay between two scans d�fini le temps en
secondes entre 2 scans de l'option continuous scan.
En combinant ces 2 fonctionnalit�s et en pla�ant une update des plugins dans la
crontab, nous avons la capacit� d�sormais d'effectuer un scan de mise � jour
r�gulier sans plus nous soucier de Nessus. Pour ce faire, nous devons activer
les options Enable KB saving, Only test hosts that have never been tested in
the past, Reuse the knowledge bases about the hosts for the test et les 4
options Do not execute dans le panel KB ; et enfin nous d�cidons que la KB sera
valable pour une semaine soit 604800 secondes. Puis, dans le panel Scan
options, nous cochons les options detached scan et continuous scan et pla�ons
le delai entre 2 scans � une heure, soit 3600 secondes. Vous pouvez sp�cifier
l'adresse root tout simplement comme destination des rapports. Ainsi, Nessus ne
scannera que les h�tes qui n'ont pas d�j� �t� scann� depuis les 7 derniers
jours, attendra une heure et recommencera qui plus est avec des plugins � jour
gr�ce � l'entr�e d'update dans la crontab.
Si vous avez quelques talents en programmation et en s�curit� et/ou que
vous souhaitez contribuer � Nessus, vous pouvez apprendre � cr�er des
plugins, qui font toute la valeur et la puissance de Nessus, � l'adresse
http://www.nessus.org/doc/nasl.html.

3.3. lsof

L'utilitaire lsof - signifiant LiSt Open File - est un remplacement avantageux

� netstat, fstat et sockstat sous FreeBSD. Il est capable de lister tous les
fichiers ouverts pas tous les processus et peut donc �tre utilis� pour lister
des ports et services ouverts ainsi que leurs propri�taires. Vous pouvez
installer lsof depuis les ports � /usr/ports/sysutils/lsof.

Par exemple nous pouvons lister uniquement les fichiers sockets Internet avec
l'option -i, l'option -n permettant de ne pas r�soudre les adresses.

# lsof -ni
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
portmap 156 daemon 3u IPv4 0xc3dabf00 0t0 UDP *:sunrpc (LISTEN)
ssh 259 root 16u IPv4 0xc3ddcd80 0t0 TCP *:ssh (LISTEN)
sendmail 287 daemon 4u IPv4 0xc3dddb60 0t0 TCP *:smtp (LISTEN)

Vous voyez que la pr�sentation du listing permet de voir les types de sockets,
TCP ou UDP, dans la colonne NODE puis l'adresse et le port d'�coute dans la
colonne NAME. Les lignes correspondant � des connexions en cours sont affich�es
avec une fl�che "->" s�parant les adresses et ports sources et destinations.
Les ports en �coute n'ont pas de fl�che et ne comportent qu'une adresse et un
port. Dans ce dernier cas, l'adresse peut �tre une �toile si le processus
�coute sur toutes les adresses simultan�ment.

Il est possible de demander � lsof de n'afficher qu'un port et/ou une adresse
IP donn�e. Notez que lsof supporte aussi bien les adresses IPv4 que v6, il
suffit d'adopter la notation correcte (loopback = 127.0.0.1 et ::1)

# lsof -ni proto@host:port

Mais lsof offre de nombreuses autres possibilit�s. Nous pouvons par exemple
lister l'ensemble des sockets quel que soit leur domaine (UNIX ou Internet)

# lsof -U -n -i

Ou bien lister des fichiers ouverts selon leur propri�taire par l'option -u ou
leur PID par l'option -p ainsi que par l'options -g pour filtrer � partir du
groupe. Nous pouvons sp�cifier plusieurs PID, GID et user en pla�ant des
virgules

# lsof -p pid -g gid -u username

Lsof poss�de enfin quelques fonctions bien pratiques. Tout d'abord � l'aide de
l'option -a, nous pouvons filtrer selon plusieurs arguments similaires. Ce qui
sur des sockets de domaine Internet, peut nous permettre de rechercher
plusieurs services ou adresses bien sp�cifiques.

# lsof -a -n -i proto@host:port -i proto@host:port

Il faut aussi savoir que lsof peut s'effectuer en repeat mode afin d'obtenir
une surveillance constante ou r�guli�re. Ceci s'effectue � l'aide de l'option
+|-r temps o� temps d�signe le temps entre chaque r�p�tition en secondes.
L'option param�tr�e avec + au lieu de - permet d'arr�ter lsof lorsqu'il ne
liste plus rien en plus de l'arr�ter par un SIGINT.

# lsof -ni +r30

3.4. stack smashing

Nous allons ici aborder 2 outils extr�mement pratiques pour FreeBSD permettant
d'emp�cher les attaques de type buffer overflow consistant � d�passer une
m�moire tampon statique pour �crire un code original ex�cut� avec les droits
du programme dont d�pend ce buffer. Nous disposons de libparanoia et du gcc
protector patch.

libparanoia est une librairie qui intercepte les appels � des fonctions
pr�sum�es sensibles et les remplace par des fonctions similaires en tous
points et fonctionnalit�s, � la seule diff�rence que ces fonctions sont
modifi�es pour emp�cher toutes tentatives de corruption de la pile m�moire
ce qui permet de nous pr�venir des failles de type stack overflow ou return-
into-libc tr�s document�es et largement r�pandues ces derni�res ann�es.
Les fonctions ANSI C pr�sum�es sensibles sont strcpy, strcat, gets, sprintf et
scanf qui sont connues pour �tre souvent exploit�es � des fins ill�gitimes. Le
probl�me essentiel vient du fait que le langage C n'inclut aucunes techniques
natives de v�rification lorsque nous manipulons des variables dans une m�moire
tampon. Ce comportement permet, � l'occasion, d'�crire dans cette m�moire afin
d'y faire ex�cuter diverses commandes - pouvant entra�ner jusqu'� la
compromission compl�te du syst�me si ledit programme est ex�cut� avec les
droits root. L'id�e de base de libparanoia est de ne jamais ex�cuter de
nouvelles instructions suite � ces fonctions si la stack a �t� modifi�. On
pr�f�rera alors tuer le processus ou appeler une fonction d'exit. La m�thode
peut para�tre brutale mais ceci suppose une corruption de la m�moire tampon
de ce programme et, dans ce contexte, entraver un instant le bon d�roulement
d'un programme ou d'un unique processus para�t bien moins grave que de risquer
la compromission compl�te du syst�me.
Nous installons libparanoia par son port dans /usr/ports/security/libparanoia.
Nous vous recommandons ensuite d'ex�cuter le script copy-to-libc qui permet de
patcher directement la libc FreeBSD quelque en soit la version.

# ./copy-to-libc

Le GCC Protector Patch consiste, quant � lui, en une s�rie de v�rification

effectu�e directement par le GNU Compiler Collection lors de la compilation de
programmes. Il tire une partie de ses techniques du travail effectu� pour le
patch StackGuard pour Immunix OS, une distribution Slackware GNU/Linux
renforc�e par une s�rie de patchs de s�curit�. Ainsi, il utilise une guard
variable ins�r�e juste apr�s le pointeur de trame pr�c�dente. Comme ce guard
se trouve plus haut dans la pile qu'un tableau ou une string susceptible d'�tre
d�tourn�e, il prot�ge les arguments, l'adresse de retour et le pointeur de
trame pr�c�dente. La valeur de cette variable est al�atoire ainsi un
attaquant ne peut pas la calculer pour la contourner.

|------------------------|
| arguments |
|------------------------|
| return adress |
|------------------------|
| previous frame pointer |
|------------------------|
| guard |
|------------------------|
 | arrays |
|------------------------|
| local variables |
|------------------------|

Suivant ce mod�le, les donn�es en m�moire en dehors d'une fonction ne peuvent

pas �tre endommag�es lorsque la fonction retourne et les attaques sur les
pointeurs en dehors ou au sein de la fonction ne passeront pas du fait des
limitations d'usage de la pile. Le GCC protector patch introduit donc ici un
mod�le dit Safety Protection Model de limitations d'usage de pile.

Toutes ces protections se heurtent bien s�r aux limitations du langage C, par
exemple on ne peut prot�ger un pointeur faisant partie d'une structure contenant
�galement un tableau puisque le r�agencement est interdit. Ou encore,
l'utilisation des options d'optimisation de GCC peut entra�ner la non
utilisation des protections du patch. Cependant, le GCC Protector Patch reste
une option int�ressante dans la lutte contre les attaques par stack overflow.
Pour l'installer et construire FreeBSD avec cette protection, nous devons
d'abord patcher GCC puis le construire ind�pendamment du syst�me.

# cd /usr
# patch -p1 < protector.patch

# cd /usr/src/gnu/lib/libgcc
# make depend && make all install clean

# cd /usr/src/gnu/usr.bin/cc
# make depend && make all install clean

Puis avant d'effectuer les op�rations de recompilation de FreeBSD, nous

d�finissons la variable d'environnement CFLAGS indiquant les options � passer
au compilateur

# setenv CFLAGS=-O -pipe -fstack-protector

A noter que l'options -fstack-protector et son oppos� -fnostack-protector

pass�es � GCC permettent d'activer ou non la protection du patch.
Nous mettons maintenant la libc � jour.

# cd /usr/src/lib/libc
# make depend && make all install clean

Et nous n'avons plus qu'� recompiler le monde ! Ce patch est valable depuis
FreeBSD 4.3 et fonctionne avec les versions de GCC 2.95.2, 2.95.3 et 3.0.
Cependant, des probl�mes peuvent appara�tre � la compilation d'un programme ne
faisant pas appel � la variable d'environnement CFLAGS comme XFree. Plus
d'informations � http://www.trl.ibm.com/projects/security/ssp/.

3.5. tunneling

Nous allons maintenant �tudier les diff�rentes m�thodes de tunneling

disponibles avec FreeBSD. Le tunneling nous permet d'encapsuler des sessions
applicatives parfois sensibles comme la manipulation de courrier (POP/SMTP),
l'IRC, la navigation web, FTP ou toute autre transmission qui peut voir passer
des mots de passe, au sein d'un tunnel crypt�. Nous en avons retenus 2
m�thodes : OpenSSH et OpenSSL/Stunnel.

Depuis la configuration de sshd plus haut, vous devez avoir OpenSSH d'or et
deja install�. Nous allons donc nous contenter ici de d�velopper ses options de
tunneling. Nous ex�cutons la commande suivante

# ssh -N -f -L localport:localhost:remoteport user@remotehost

L'option -N nous met en tunnel only, l'option -f permet de faire tourner ssh en
T�che de fond et -L permet de pr�ciser les donn�es du tunnel qui sont le port
local puis le port distant entre lesquels s'effectuera le tunnel. Il ne reste
alors plus qu'� rentrer l'h�te distant comme d'habitude. Une fois le tunnel
�tabli, toute connexion avec comme source le port local indiqu� dans le tunnel
et comme destination le port distant indiqu� dans le tunnel, transitera au sein
du tunnel SSH mis en place.

La seconde solution consiste � cr�er et utiliser des tunnels SSL avec Stunnel,
c'est notamment la solution appliqu�e dans le cadre d'IRCS, le r�seau IRC
securis�. Pour ce faire, nous avons besoin d'OpenSSL qui est install� dans le
catalogue cvsup src-all et de Stunnel que nous trouverons dans
/usr/ports/security.

# cd /usr/ports/security/stunnel && make install clean

Puis pour lancer une connexion distante en mode client, nous ex�cutons la
commande suivante

# stunnel -c -d localhost:localport -r remotehost:remoteservice

L'option -c pr�cise que nous sommes en mode client effectuant ainsi un

tunneling, et l'option -r permet de pr�ciser les donn�es de l'h�te distant que
sont l'adresse distante - qui peut �tre une IP ou un domaine - et le service
distant qui peut aussi bien �tre un port qu'un nom de service contenu dans
/etc/services (en passant vous pouvez faire un copier/coller depuis
http://www.iana.org/assignments/port-numbers). Vous pouvez �galement pr�ciser
un certificat permettant d'authentifier l'h�te distant (recommand�) et le
verifier en ajoutant les options -v2 et -A path/to/certificat.pem.

Nous abordons maintenant une derni�re m�thode de tunneling diff�rant des 2

pr�c�dentes par son fonctionnement au layer OSI 3, et sa capacit� � servir � la
mise en place d'un v�ritable Virtual Private Network entre 2 LAN distants qu'on
veut r�unir par 2 passerelles IPSec - supposant que vous diposez � la fois d'une
adresse publique et priv�e - plut�t qu'� une communication end-to-end. Nous
allons donc maintenant �tudier la configuration des options de s�curit� IPSec
avec IPv4. Sous FreeBSD, nous nous servons pour se faire de la dual stack TCP/IP
d�velopp�e dans le cadre du projet KAME et qui supporte parfaitement IPv6 et
IPSec. Vous pouvez obtenir plus d'information sur KAME � http://www.kame.net.

Nous devons tout d'abord configurer une interface gif pour le tunneling IPv6/4
over IPv6/4 afin de cr�er le tunnel IPSec. Pour ne pas avoir � le retaper au
d�marrage, ajoutez une entr�e ifconfig_gif0 � votre rc.conf.

# ifconfig create gif0

# ifconfig gif0 tunnel localhost_public_IP remote_public_IP

Nous utilisons l'interface gif pour qu'elle g�re le tunnel entre IP publique et
nous permette donc d'utiliser nos IP priv�es pour la configuration des r�gles
de chiffrement. De cette mani�re, les paquets seront bien rout�s au niveau de
la routing table du kernel, et non pas via la SPD, suivant un forwarding path
classique et les connexions apparaissent dans netstat. Avec gif, il est
possible de filtrer et sniffer au niveau de l'interface gif. Sans gif
(c'est-�-dire en utilisant les adresses publiques des passerelles IPSec), il
reste possible de filtrer sur les interfaces priv�es et �ventuellement sniffer
via des r�gles tee.

Pour utiliser IPSec, le kernel manipule 2 bases de donn�es � savoir la Security

Policy Database (SPD) qui permet de d�finir les r�gles d'application du tunnel
IPSec avec notemment la sp�cification des associations de s�curit� (SA) ; et la
Security Association Database (SAD) qui contient les cl�s des SA
correspondantes. L'administrateur doit tout d'abord configurer la policy de la
SPD par l'intermediare de la commande setkey, le kernel se r�f�re ensuite � la
SPD pour v�rifier si un paquet requiert IPSec, si c'est le cas, il utilise la
SA sp�cifi�e dans la SAD. En cas d'erreur ou d'impossibilit� d'obtenir la cl�,
le kernel fait appelle au daemon IKE racoon qui va effectuer l'�change de cl�s
afin de permettre la SA normalement en modifiant directement la SAD. Avec une
syntaxe et une utilisation similaire � ipfw, nous utilisons setkey pour vider
les databases avant d'y ajouter nos nouvelles policy.

# setkey -FP
# setkey -F

Puis nous entrons notre policy dans la SPD sous la forme

action net_src net_dst upperspec -P direction action \
protocol/mode/gw_src-gw_dst/level

action peut prendre comme valeur : spdadd, spddelete ou spdflush - ce dernier

correspondant � -FP.
net_src et net_dst d�signe les adresses priv�es des r�seaux qu'on cherche �
r�unir.
uppersec d�signe les protocoles de la couche OSI 4 pour lequel la r�gle
s'applique. Le champ peut �tre tcp, udp ou any.
L'option -P sp�cifie la policy elle-m�me suivi de la direction qui peut �tre in
ou out, de l'action c'est-�-dire ipsec pour appliquer ipsec, none pour faire un
tunnel simple ou discard pour rejeter le paquet ; suivi du protocol qui peut
�tre ESP (Encapsulated Security Playload) offrant ainsi confidentialit� par
encryption ou AH (Authentification Header) offrant l'authentification, ou enfin
IPCOMP. L'int�grit� et la protection contre le rejeu des donn�es sont assur�es
pour ESP et AH. Ensuite vient le mode qui peut �tre transport dans lequel IPSec
intervient entre la couche OSI 4 et 3 ainsi le paquet final utilise des
adresses IP claires, ou tunnel dans lequel IPSec intervient apr�s la couche OSI
3 en rajoutant un header et en encryptant la totalit� du paquet jusqu'� la
passerelle de destination. Nous avons ensuite l'adresse de la passerelle source
et de la passerelle de destination et pour finir le level qui peut prendre les
valeurs default pour utiliser les variables kernel par d�faut, use pour
utiliser une SA ou poursuivre la transmission normalement en cas d'�chec, ou
require pour imposer l'utilisation d'une SA. Les premi�res variables sysctl
sont toutes mises � default, suivies d'une entr�e qui nous permet de rejeter
(discard) les paquets tentant d'utiliser le VPN sans IPSec parce qu'ils ne
correspondent pas � la security policy. Puis, nous param�trons une entr�e
sysctl permettant de forcer la ren�gociation via Racoon suite � la perte d'une
des 2 extr�mit�s du tunnel (en d�pr�ciant l'ancienne SA). Enfin, nous activons
la compatibilit� Explicit Congestion Notification pour IPSec avec le traitement
suivant : � l'encapsulation les bits ToS sont copi�s except� l'ECN CE, � la
d�capsulation, les bits ToS sont copi�s mais si l'ECN CE est pr�sent, il est
copi� au paquet d�capsul�.

# sysctl -w net.inet.ipsec.esp_trans_deflev=1
# sysctl -w net.inet.ipsec.esp_net_deflev=1
# sysctl -w net.inet.ipsec.ah_trans_deflev=1
# sysctl -w net.inet.ipsec.ah_net_deflev=1
# sysctl -w net.inet.ipsec.def_policy=0
# sysctl -w net.key.prefered_oldsa=0
# sysctl -w net.inet.ipsec.ecn=1

# setkey -c << EOF

spdadd internal_net/24 remote_internal_net/24 any -P out ipsec \
esp/tunnel/localhost_public_IP-remote_public_IP/default;
spdadd remote_internal_range/24 internal_range/24 any -P in ipsec \
esp/tunnel/remote_public_IP-localhost_public_IP/default;

Maintenant que notre tunnel IPSec est pr�t � servir, il nous reste � configurer
Racoon afin d'assurer l'�change des cl�s sym�triques et SAs. Pour obtenir notre
configuration IPSec, nous modifions rc.conf pour ex�cuter setkey au d�marrage
avec le fichier ipsec.conf en argument.

...
ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
...

------------------------------------ SNiP -------------------------------------

flush
spdflush

# SAD entry
# SA AH avec cle 160 bits
add localhost_public_IP remote_public_IP ah 1500 -A hmac-sha1 123ABC456EFG789HIJ10
add remote_public_IP localhost_public_IP ah 1600 -A hmac-sha1 123ABC456EFG789HIJ10
# SA ESP avec cle 128 bits
add localhost_public_IP remote_public_IP esp 1500 -E blowfish-cbc 123ABC456EFG789H
add remote_public_IP localhost_public_IP esp 1600 -E blowfish-cbc 123ABC456EFG789H

# SPD entry
spdadd internal_net/24 remote_internal_net/24 any -P out ipsec \
esp/tunnel/localhost_public_IP-remote_public_IP/default;
spdadd remote_internal_range/24 internal_range/24 any -P in ipsec \
esp/tunnel/remote_public_IP-localhost_public_IP/default;
------------------------------------ SNiP -------------------------------------

Nous d�finissons ensuite pour la configuration de racoon un fichier psk.txt

contenant les cl�s utilis�es pour l'identification dans la premi�re phase de
l'�change de cl�s.

# cat /etc/racoon/psk.txt
remote_public_IP shared_key

Puis nous nous occupons de racoon.conf lui-m�me que nous �ditons � partir du
fichier de configuration par d�faut.

# cp /usr/local/etc/racoon/racoon.conf.dist /etc/racoon.conf
# ee racoon.conf

------------------------------------ SNiP -------------------------------------

path pre_shared_key "/etc/racoon/psk.txt" ;
path certificate "/usr/local/openssl/certs/";

# Padding options
padding
{
maximum_length 20;
randomize off;
 strict_check on;
exclusive_tail off;
}

# Timing Options. Elles peuvent �tre modifi�es par l'h�te distant.

timer
{
counter 5;
interval 10 sec;
persend 1;
phase1 1 min;
phase2 30 sec;
}

# Phase 1. anonymous signifie que cette phase est appliqu�e � tous les h�tes.
# Vous pouvez configurer des phases 1 et 2 pour des h�tes particuliers.
remote anonymous
{
exchange_mode main,aggressive ;
# mode de negociation, aggressive est plus rapide, mais main offre
# un m�canisme de cookie, la prot�ction d'identit� et la fixation du
# Diffie-Hellman group id
doi ipsec_doi;
situation identity_only;
nonce_size 16;
lifetime time 1 min; # sec,min,hour
lifetime byte 2 MB; # B,KB,GB
initial_contact on;
proposal_check obey; # obey, strict ou claim
#support_mip6 on; # support de Mobile IPv6 (cf. snapshots KAME)

proposal
{
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key ;
# groupe Diffie-Hellman
dh_group 2 ;
}
}

# Phase 2.
sainfo anonymous
{
pfs_group 2;
lifetime time 2 hour ;
lifetime byte 100 MB ;
encryption_algorithm 3des, blowfish, rijndael, twofish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
# compression IPCOMP
compression_algorithm deflate ;
}
------------------------------------ SNiP -------------------------------------

Vous pouvez aussi utiliser pour plus de s�curit� des certificats au format PEM
en lieu et place des psk toujours sujettes au brute force. L'utilisation des
certificats de type X.509v3 support�s par racoon nous permet de rester
parfaitement interop�rable en conformit� avec le standard PKIX. Nous allons
avoir besoin d'openssl qui se trouve dans la base FreeBSD pour g�n�rer une
paire de cl�s priv�/publique puis un certificat � signer.

Commen�ons par g�n�rer notre paire de cl�s RSA � 1024 bits et stock�es au
format PEM (Privacy Enhanced Mail).

# openssl genrsa -out privkey.pem 1024

Une fois cette (longue) op�ration termin�e, la commande suivante nous permet
d'effectuer une requ�te PKCS#10 de certification d'une cl� publique et d'un
distinguished name voire d'une certains nombres d'attributs (voir RFC 2986).

# openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \
privkey.pem -outform PEM -out request.pem

Ceci d�clenche une proc�dure semblable � celle d'adduser o� il vous faudra

r�pondre � certains champs qui d�finiront votre certificat.
Nous devons maintenant faire signer ce certificat soit par une autorit� de
certification en lui envoyant le r�sultat de la requ�te PKCS#10 soit en la
signant nous-m�me � l'aide toujours d'openssl avec la syntaxe suivante

# openssl x509 -req -in request.pem -signkey privkey.pem -out cert.pem

Nous obtenons ainsi le certificat cert.pem au format pem stock� dans

/usr/local/openssl/certs/.

Maintenant pour utiliser les certificats en lieu et place des psk, nous allons
devoir proc�der � quelques modifications de racoon.conf. Tout d'abord dans la
section remote, nous devons placer

...
certificate_type x509 "certificat" "cle_privee";
my_identifier user_fqdn "cns@minithins.net";
...

Sp�cifiant ainsi l'utilisation de certificats X.509 puis le certificat et la

cl� priv�e, � aller chercher dans le path openssl d�fini au d�but de
racoon.conf. My_identifier est le nom unique utilis� pendant la requ�te. Puis
dans la section proposal, nous pla�ons

...
authentication_method rsasig;
...

D�signant la m�thode d'authentification, qui est ici signature RSA, la seule

disponible avec la certification X.509 pour le moment.

Nous ajoutons finalement une entr�e dans la crontab pour que racoon se lance �
chaque reboot ou bien nous pouvons placer un script lan�ant racoon dans
/usr/local/etc/rc.d/.

4. Conclusion

Voila, ce paper est desormais termin�. Vous devez maintenant �tre en

possession d'une machine FreeBSD configur�e de mani�re � r�duire grandement
les risques d'intrusion ou de compromission. Cependant n'oubliez jamais que
la s�curit� absolue n'est pas de ce monde, tout ce que nous pouvons faire
c'est g�rer le risque et mettre le plus de b�tons possible dans les roues de
l'attaquant. Fa�tes �galement tr�s attention � toutes les relations de
confiance que vous �tablissez avec des h�tes distants. En effet, via ce qu'on
appelle la contamination par m�tastases, vous pourriez rapidement �tre
compromis si vous ne pr�tez aucune attention � vos connexions et que vous avez
toujours confiance en n'importe qui. Souvenez-vous enfin que la s�curit� ne
peut pas se r�sumer � un programme ou une technique unique, c'est une cha�ne de
processus dont aucun maillon n'est s�r � 100% ce qui nous donne avec la th�orie
des syst�mes lin�aires un processus extr�mement fragile. Le but est de rendre
la t�che de l'intrus la plus ardue possible.

-------------------------------------------------------------------------------

Copyright (c) 2001,2002,2003 CNS <cns at minithins.net>

Free Document Dissemination Licence -- FDDL version 1

http://pauillac.inria.fr/~lang/licence/v1/fddl.html

This document may be freely read, stored, reproduced, disseminated, translated

or quoted by any means and on any medium provided the following conditions are
met:

* every reader or user of this document acknowledges that he his aware that
no guarantee is given regarding its contents, on any account, and
specifically concerning veracity, accuracy and fitness for any purpose;
* no modification is made other than cosmetic, change of representation
format, translation, correction of obvious syntactic errors, or as
permitted by the clauses below;
* comments and other additions may be inserted, provided they clearly
appear as such; translations or fragments must clearly refer to an
original complete version, preferably one that is easily accessed
whenever possible;
* translations, comments and other additions must be dated and their
author(s) must be identifiable (possibly via an alias);
* this licence is preserved and applies to the whole document with
modifications and additions (except for brief quotes), independently of
the representation format;
* whatever the mode of storage, reproduction or dissemination, anyone able
to access a digitized version of this document must be able to make a
digitized copy in a format directly usable, and if possible editable,
according to accepted, and publicly documented, public standards;
* redistributing this document to a third party requires simultaneous
redistribution of this licence, without modification, and in particular
without any further condition or restriction, expressed or implied,
related or not to this redistribution. In particular, in case of
inclusion in a database or collection, the owner or the manager of the
database or the collection renounces any right related to this inclusion
and concerning the possible uses of the document after extraction from
the database or the collection, whether alone or in relation with other
documents.

Any incompatibility of the above clauses with legal, contractual or judiciary

decisions or constraints implies a corresponding limitation of reading, usage,
or redistribution rights for this document, verbatim or modified.