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

Papier en francais traitant de la securisation d’un environnement FreeBSD. Tres complet, travail vraiment reussi . [ Original et mise a jour ? cette adresse :
http://www.minithins.net/warehouse/FreeBSD.txt ]

Securing FreeBSD step by step (for Dummies and even Geeks)
cns at minithins.net

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. D

Laisser une réponse

Vous devez être connecté pour publier un commentaire.