1 Sécurité

La sécurité consiste en premier lieu à avoir une vision globale de ce qui se passe. Et à ne pas créer de trous sous prétexte de régler un problème ailleurs. Primum non nocere.

1.1 Login manager

1. Le message d'accueil pour un login en mode terminal dépend du fichier /etc/issue pour un login local et du fichier /etc/issue.net pour un login distant (telnet).
2. Sous la $SuSE-8.1$, le login graphique dépendait du répertoire /opt/kdeX/share/config/kdm. Avec cette spécificité que le fichier kdmrc était réécrit par YaST à chaque occasion. Contournement : création d'une archive *.pld et ajout des lignes correspondantes dans le batch qzq_anti_suse.
3. Sous la $SuSE-9.3$, le répertoire précédent existe encore, mais n'est là que pour archive. Les fichiers actifs se trouvent dans /etc/opt/kdeX/share/config/kdm : ce sont eux qu'il faut modifier. Si l'on utilise kcontrol pour cela, les commentaires descriptifs sont écrasés.
4. Pour des raisons juridiques évidentes, les messages d'accueil doivent être inamicaux. En particulier, ils ne doivent pas contenir le mot "Welcome". Le message par défaut Welcome to SuSE Linux 9.3 (i586) - Kernel est donc totalement inapproprié. De même, il n'est pas raisonnable de publier la liste des utilisateurs.
5. Message d'accueil retenu
   Here is %h \n Unauthorised access is prohibited
6. Le fichier kdmrc contient les sections suivantes :

   [General]

   ...

   [Xdmcp]

   ...

   [Shutdown]

   ...

   [X-*-Core]

   AllowNullPasswd=false ; AllowRootLogin=true ; AllowShutdown=Root AuthNames=XDM-AUTHORIZATION-1,MIT-MAGIC-COOKIE-1 ; AutoReLogin=false ; ClientLogFile=.xsession-errors-%s ; ...

   [X-:*-Core]

    

   [X-:0-Core]

    

   [X-*-Greeter]

   BackgroundCfg=/etc/opt/kde3/share/config/kdm/backgroundrc ; ColorScheme=Keramik ; EchoMode=OneStar ; ForgingSeed=1104924527 ; GUIStyle=Keramik ; GreetString=Here is %h, %m \n unautorised login prohibited ; GreeterPos=60,80 ; Language=en_US ; LogoArea=Clock ; MaxShowUID=65000 ; MinShowUID=500 ; SelectedUsers= ; UseBackground=true ; UseTheme=false ; UserCompletion=false ; UserList=false

   [X-:*-Greeter]

    

   [X-:0-Greeter]

   EnableChooser=false ; LogSource=/dev/xconsole ; ShowLog=true ;

7. Il faut AllowNullPasswd=false partout. De même pour UserList=false.
8. Il faut AllowShutdown=Root dans la section générale et AllowShutdown=All dans la section locale.
9. Jusqu'à la $SuSE-7.3$, l'apparence du login graphique était réglée par le fichier /opt/kde2/share/config/kdmrc et proposait les sections suivantes :

   message d'invitation

   GreetString=SuSE Linux on HOSTNAME
   GreeterPosFixed=true
   GreeterPosX=100
   GreeterPosY=100
   LogoArea=KdmClock
   LogoPixmap=/opt/kde2/share/apps/kdm/pics/kdelogo.png

   login

   SessionTypes=kde,failsafe
   ShowPrevious=false
   ShowUsers=None
   EchoMode=OneStar (NoEcho)
   AutoLogin1st=false
   AutoLoginEnable=false

   shutdown

   Restart=/sbin/reboot
   Shutdown=/sbin/halt
   ShutdownButton=ConsoleOnly

1.2 Services ouverts par runlevel ou inetd

1. Examiner quels sont les services offerts à l'extérieur par la commande
   nmap -sT localhost
   Il reste à fermer tout ce qui n'est pas volontairement ouvert.
2. La TAB. 1 donne la liste des services actuellement ouverts (a=madras, i=maverick, n=monalisa, o=moonlight)

   
   

   TAB. 1: Les services ouverts.

   
   

   
   

3. Certains services sont lancés par xinetd et contrôlés par les descriptifs contenus dans/etc/xinetd.d/. Dans TAB. 1, ils sont listés avec les programmes associés (user, path, args). La commande
   for i in * ; do echo $i ; grep disable $i | tr "\t" " " | \ 
      sed -e "s¶ [ ]*¶ ¶g" | grep "disable = "; done
   donne la liste de ces services avec la mention des services désactivés.
4. Dans la $SuSE-8.1$, ces services dépendaient du fichier /etc/inetd.conf.
5. D'autres services, comme 80=httpd (apache), 111=sunrpc, 139=netbios-ssn (samba), 515=printer, 1026=nterm, 6000=X11, sont lancés par le mécanisme runlevel. On en obtient la hiérarchie par le batch qyx_docs_runlevel, décrit LISTING 1.

   
   

   TAB. 2: docs_runlevel

   
   
   
   
   

6. Ce mécanisme fait intervenir les batchs figurant dans le répertoire /etc/init.d/. Un bilan en est donné TAB. 2 (avec le code 0=halt, S=pré-1, 1=single user, 2=local, 3=network, 5= graphical+net, 4=???, 6=shutdown). Les batchs concernant le boot sont en tête, et le classement est chronologique (S=start, K=kill). On constate en particulier que la somme des numéros S et K est constante..
7. Il conviendrait d'examiner
   1. apmd : Advanced Power Management (APM) daemon
   2. fbset - show and modify frame buffer device settings
   3. junkbuster - The Internet Junkbuster Proxy
   4. named - Internet domain name server
   5. nscd - name service cache daemon
8. Sont normalement activés : apache, dhcpd, smbd et nmbd
9. Ont été désactivés :
   1. dhcrelay - Dynamic Host Configuration Protocol Relay Agent
   2. /etc/pcmcia/config - PCMCIA card configuration database
   3. wvdial.dod - PPP dialer with built-in intelligence

1.3 Le path de root et de su root

1. Changer le nom de la machine : YaST fait cela, mais la prise en compte n'est uniformément effective qu'après un reboot (problèmes avec samba, print etc).
2. Path de root. En fait il y a trois valeurs souhaitables pour $PATH. Lorsque root s'est réellement logué, lorsqu'un "su root" a eu lieu, et lorsque $ipse veut administrer par un "su root", c'est à dire se trouver dans la situation 1 alors qu'il est dans la situation 2
3. Se donner les moyens de ne pas confondre un programme interactif lancé par $ipse et le programme correspondant lancé par root. Un réglage des couleurs semble utile (réglage du prompt des konsoles par pathroot ci-dessous, réglage de la couleur de kfmclient).
4. Pour des raisons de sécurité, il est important que le $PATH "su root" soit aussi réduit que possible. L'extension du $PATH doit donc résulter d'une action volontaire. Un batch, placé dans $ipse/bin, qui écrit un batch dans /root/bin. Ce deuxième batch, appelé pathroot, s'exécute par
   . /root/bin/pathroot
   et contient les commandes
   PATH=$ipse/bin:/opt/kde3/bin:/opt/kde/bin:/usr/lib/java/jre/bin  
   USER=root  
   KDEHOME=/root/.kde 
   PS1="\\033[31m\\u@\\h:\\w\\033[30m > "  
   export PATH USER PS1 KDEHOME 
   La variable KDEHOME est indispensable pour pouvoir lancer un filemanager par une commande kfmclient openProfile filemanagement . (un point à la fin).
5. remarque : la config de kedit se trouve dans ~/.kde2/share/config/keditrc... mais su-root utilise /opt/kde2/share/config/keditrc, et pas celle de /root/.kde2 ...

1.4 Enregistrement des fichiers /var/log/*.log

1.4.1 Généralités

1. Nous avons divisé nos remarques sur les fichiers *.log en trois parties : enregistrement, rotation, traitement. Ces fichiers constituent à la fois un outil de sécurité et un point de vulnérabilité (denial of service et coulage). Leur gestion doit être faite avec attention.
2. Chaque fois qu'un fichier *.log est créé, le problème de sa rotation doit être géré. De plus, il semble raisonnable que ces fichiers s'appellent tous *.log.
3. Une méthode générale d'enregistrement des fichiers *.log est fournie par syslog, mais de plus en plus d'applications gèrent leurs fichiers elles-mêmes.

1.4.2 La méthode syslog

1. Dans le système , un message est caractérisé par une signature (facility) et une priorité (level).

   facility

   auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, (security= auth), syslog, user, uucp and local0 ... local7.

   level

   debug, info, notice, warning (warn= warning), err, (error= err), crit, alert, emerg, (panic= emerg). Les acronymes warn, error et panic ont été maudits par les instances maudissantes : ne pas les utiliser.

2. Un script peut émettre un message en direction de syslog par la commande logger. Exemples, issu de /etc/ppp/ip-up :

   logger -p auth.notice -t poll.tcpip

   logger -p auth.notice -t ip-up.local

   Ces commandes envoient des messages facility=auth, level=notice, avec le tag indiqué (qui sera répété à chaque ligne).

3. Le script lanceur /etc/init.d/syslog est paramétré par le fichier /etc/sysconfig/syslog (cf. LISTING 2). La commande principale est le choix du démon.

   
   
   

4. Depuis la $SuSE-9.3$, le démon d'enregistrement est syslog-ng, contrôlé par le fichier /etc/syslog-ng/syslog-ng.conf. Auparavant ($SuSE-8.1$), le démon était syslog, contrôlé par le fichier /etc/syslog.conf.
5. Utiliser /etc/init.d/syslog restart pour relancer le démon après chaque modification. La nouvelle version tient compte des émetteurs de messages qui s'exécutent en mode chrooted (comme dhcpd ou named). En effet, ces démons émettent depuis /var/lib/xxx/dev/log au lieu d'émettre depuis /dev/log comme tout le monde.
6. Lorsqu'un message est émis vers syslog, la façon dont un couple signature-priorité se traduit par un routage vers un fichier ou un autre est sous le contrôle du fichier /etc/syslog-ng/syslog-ng.conf (LISTING 3).

   
   
   

7. Pour la $SuSE-9.3$, le fichier de configuration est SuSE-compilé à partir de /etc/syslog-ng/syslog-ng.conf.in et de /etc/sysconfig/syslog. Après avoir modifié ces deux fichiers source, il faut lancer SuSEconfig : SuSEconfig -verbose -module syslog-ng. Ce dispositif n'est plus actif sous $SuSE-10.2$.
8. *** Voici les déclarations des différents fichiers *.log que nous utilisons

   /var/log/auth.log

   /var/log/boot.log

   /var/log/cron.log

   /var/log/firewall.log

   /var/log/kdm.log

   /var/log/local.log

   /var/log/mail.log 

   /var/log/messages.log

   /var/log/news/*.log

   /var/log/SaX.log

   /var/log/warn.log

   /var/log/XFree86.*.log

   /var/log/Xorg.*.log

   /var/log/xinetd.log 

1.4.3 Gestion directe par les applications

1. Un certain nombre de programmes décrivent leurs propres méthodes dans leurs propres fichiers de configuration. Cela se traduit souvent par des sous répertoires.
2. Il est efficace d'imposer cette utilisation de sous répertoires par toutes les applications utilisant une gestion directe.

apache2

/etc/httpd/httpd.conf ($SuSE-9.3$) ou /etc/sysconfig/apache2 ($SuSE-10.2$)

ErrorLog  /var/log/httpd/error.log

CustomLog /var/log/httpd/access.log combined

SSLLog    /var/log/httpd/ssl_engine.log 

TransferLog /var/log/httpd/access.log

CustomLog /var/log/httpd/ssl_request.log

en + :/var/log/httpd/rcapache.log 

en + :/var/log/httpd/ssl_scache.dir 

en + :/var/log/httpd/ssl_scache.pag

cups

($SuSE-9.3$) /etc/cups/cupsd.conf

AccessLog /var/log/cups/access.log

ErrorLog /var/log/cups/error.log

PageLog /var/log/cups/page.log

dhcp-start

/etc/init.d/dhcp

STARTPROC_LOGFILE=/var/log/dhcpd/rc.dhcpd.log

dhcp

/etc/dhcpd.conf

log-facility local0 ==info==> /var/log/dhcpd/dhcpd.log

ircd

 

news

 

ppp

/etc/ppp/options

log-facility local2 ==info==> /var/log/pppd.log

quagga

 

radius

 

samba

/etc/smb.conf

log level=3 

log file=/var/log/samba/%m.log 

/var/log/samba/xxx.log 

/var/log/samba/nmbd.log

/var/log/samba/smbd.log

scpm

($SuSE-9.3$) /etc/scpm.conf

LOGFILE=/var/log/scpm.log 

smpppd

 

squid

 

vsftp

($SuSE-9.3$) /etc/vsftpd.conf

logsyslog_enable=NO

log_ftp_protocol=NO

xferlog_enable=YES

vsftpd_log_file=/var/log/vsftp/vsftpd.log

xferlog_std_format=NO

xferlog_file=/var/log/vsftp/xfer.log

dual_log_enable=YES

setproctitle_enable=YES 

YaST2

 

1.5 Rotation des fichiers /var/log/*.log

1. Il faut s'assurer que tous ces fichiers *.log vont bien être transformés en *.gz lorsqu'ils auront dépassé une certaine taille. Les taux de compression étant énormes, le gain de place est évident. Les messages étant très répétitifs, ce taux peut atteindre $1000$. En outre, cela permet de découper les archives en morceaux datés et utilisables.
2. Aucun fichier du répertoire /var/log ne doit dépasser la taille prescrite, et en tout cas pas 4 Mo. Un tel dépassement est soit le signe d'un mauvais réglage, soit le signe d'un autre genre de problèmes.
3. Jusqu'à $SuSE-7.2$, le mécanisme d'archivage se règle dans /etc/logfiles. Une tentative pour réutiliser ce mécanisme dans les distributions suivantes, imposait de reprendre l'ancien script /etc/cron.daily/aaa_base_rotate_logs et ... de tout gérer à la main. En particulier, donner une valeur non nulle à la variable MAX_DAYS_FOR_LOG_FILES (le fichier rc.config ayant disparu).
4. A partir de la $SuSE-8.0$, le mécanisme logrotate s'installe par défaut. Le fichier /etc/cron.daily/logrotate/ appelle chaque jour la commande /usr/sbin/logrotate, en utilisant le fichier de configuration /etc/logrotate.conf. Celui-ci contient quelques commandes "en facteur" pour tous les fichiers. Utiliser :

   daily

    

   rotate

   365

   maxage

   365

   create

    

   compress

   ; compresscmd /usr/bin/bzip2 ; uncompresscmd /usr/bin/bunzip2

   dateext

    

   include

   /etc/logrotate.d

   missingok

    

   notifempty

    

5. Configurations individuelles fournies par $SuSE-10.2$ et incluses à partir du répertoire /etc/logrotate.d/ :

   apache2

   yast

   mcelog

   yast

   mysql

   yast : caveat /var/lib/mysql/mysqld.log

   net-snmp

   yast

   ntp

   gestion lourdement modifiée $\mapsto$ ntpd

   rsync

   yast

   scpm

   yast

   syslog

   séparer mail et news

   syslog-ng

   yast

   vsftpd

   yast

   wtmp

   yast

   xdm

   yast

   xinetd

   yast

   zmd-backend

   yast

   zypper.lr

   modifié en YaST

6. Configurations individuelles écrites spécialement :

   YaST

   gère zypper.lr et déclare quelques autres fichiers pour compatibilité.

   audit

    

   auth-cron

   la gestion des scripts cron (non prévue par défaut)

   cups

   n'était pas prévue = surprise

   dhcpd-named

    

   mail

   séparé de syslog

   net-snmp

    

   news

   séparé de syslog

   ntpd

    

   sax-video

   ces fichiers sont écrasés par SaX à chaque utilisation. Utile pour compatibilité.

   speciaux

   boot et evms

   zmd-message

   non prévu par yast. On obtient des fichiers non comprimés et valables pour un seul jour d'activité.

7. Il faut donc vérifier qu'un traitement est effectivement prévu pour chacun des fichiers *.log existants. Le batch qyl_docs_logs fait cela.

   
   
   

8. Après chaque modification "sensible", il faut lancer /etc/cron.daily/logrotate afin de vérifier qu'il n'y a pas d'erreur de syntaxe. Sans quoi, logrotate se bloque totalement, et tous les fichiers *.log grossissent hors contrôle.
9. Dans une énumération de fichiers à traiter, on passe à la ligne en passant à la ligne, et surtout pas avec un backslash à la fin (à la bash). Ceci serait compris comme un fichier qui s'appellerait "\r"... avec empoisonnement du fichier /var/lib/logrotate.status.
10. La signification précise de daily, weekly et monthly n'est pas claire. S'agit-il de tourner quoi qu'il arrive à la fin de la période, ou bien de tourner au plus une fois par période (et cela seulement si la taille est dépassée) ?

1.6 Traitement des *.log

1. La TAB. 3 donne la liste des logs pour lesquels un traitement est écrit .

   
   

   TAB. 3: Liste des *.log pour lesquels un traitement est écrit

   
   

   
   

2. Il semble utile de créer un nouvel utilisateur secur:secur de façon à ne pas être root lors de cette exploitation, et de ne pas être non plus l'utilisateur usuel (problème de taille et de sauvegardes). Et alors, de façon à pouvoir travailler aisément après une commande su secur, il est utile :
   1. d'inclure les lignes suivantes dans /home/secur/.bashrc

      export PATH=$PATH:~/bin:/opt/kde3/bin  
      export KDEHOME=~/.kde  
      export MAIL=/var/mail/secur  
      export GTK_RC_FILES=/etc/gtk/gtkrc:~/.gtkrc

   2. de créer dans ~/bin une commande kfm contenant

      kfmclient openProfile midnightcommander

3. Fichiers boot. Il est intéressant de comparer le fichier runlevel avec les messages émis lors du boot et conservés dans /var/log/boot.msg. Avec la pagaille introduite dans le mécanisme rc.config, il faut retravailler ce fichier. Tel est le but du script (secur) qsb_boot, conduisant au fichier boot_joli.log. On constate que l'ordre des messages reçus est fort différent de l'ordre des runlevels.

1.7 SuSEfirewall2

1. Ne fonctionnait pas sous $SuSE-7.3$. Sous $SuSE-8.1$, le batch de lancement est /sbin/SuSEfirewall2. Ce fichier lit et interprète le fichier descripteur de règles /etc/sysconfig/SuSEfirewall2. Caveat : stop a pour résultat de laisser les portes ouvertes. Pour tout fermer, utiliser close... sauf pour une machine distante !!!
2. Les fichiers /etc/init.d/SuSEfirewall2{init, setup, final} exécutent des morceaux choisis du script principal (à différentes étapes du boot) et ne sont pas destinés à un usage humain.
3. La configuration consiste à décrire quels sont l'intérieur, l'extérieur et la dmz. Il règle le forwarding ainsi que le masquerading du réseau interne.
4. Le firewall doit être déclaré dans les runlevels init=2,3,5 ; setup,final=3,5.

• Il faudrait examiner les ipchains engendrées (repartir du batch qyr, LISTING 11).
• Comment ne pas enregistrer les martiens ???? les commandes

  echo 0 > /proc/sys/net/ipv4/conf/all/log_martians 

  echo 0 > /proc/sys/net/ipv4/conf/eth1/log_martians

  sont annulées à chaque recharge du réseau.

1.8 Exploitation de firewall.log

*** revoir pour $SuSE-9.3$

1. Il est important de ne pas noyer les messages critiques sous des montagnes d'inutilités. Par exemple, une connexion wanadoo engendre les montagnes de "martian sources". Il faut en bloquer l'enregistrement, par une commande :
   echo 0 > /proc/sys/net/ipv4/conf/*/log_martians
   Il faut mettre à zéro les deux drapeaux all et ethx, car il y a un ou booléen entre les deux.
   • A ceci près que root est, par construction, le seul à pouvoir écrire dans ce genre de fichiers, et qu'un batch suid root ne suffit pas. Comment mettre cela dans un script ? (le problème étant que les drapeaux repassent à 1 à chaque déconnexion).
2. La partie intéressante de firewall.log est constituée des " Packet log" . Sous $SuSE-7.2$, ils sont enregistrés au niveau info (tandis que les martiens le sont au niveau warn). Sous $SuSE-8.1$, les " Packet log" sont enregistrés au niveau warn, et les martiens au niveau ***.
3. L'exploitation se fait par mise en tête de l'adresse distante. On obtient alors un tri par émetteur puis par date.
4. Une traduction des numéros de protocole facilite la lisibilité. Une liste de protocoles est rappelée dans /etc/protocols. En particulier,
   
   

5. La traduction des numéros de services est indispensable, mais il y a des cas où elle est nuisible (exploration de ports en succession). Pour l'instant, on procède en deux temps : repérage des numéros de services, sélection des lignes de filtre puis filtrage. Il est indispensable de ne pas utiliser le filtre complet car il est très long et l'algorithme se traîne abusivement (un adressage direct serait utile).
6. Tout cela est implémenté dans la commande packetian (user digger) décrite LISTING 5.

   
   
   

1.9 Modules pam

La liste des modules disponibles est donnée par la TAB. 4 (les numéros renvoient vers le manuel pam-modules).

Le traçage s'obtient en plaçant une ligne pam_warn dans le fichier /etc/pam.d/xxx concerné. Cela provoque un message étiqueté "auth.warn". Dans la configuration standard, cela se traduit par un message sur la console F10, et une ligne dans /var/log/warn. Nous avons choisi de regrouper ces messages dans un fichier spécial /var/log/auth. Dans tous les cas, être attentif à ce que ces logs ne soient lisibles que par root !!!

TAB. 4: Liste des modules pam.

1.10 Exemple de logs pam

1. login : login sur console

   PAM-warn[365]: service: login [on terminal: tty2] 
   PAM-warn[365]: user: (uid=0) -> root [remote: ?nobody@?nowhere] 
   login[365]: pam_unix session started for user root, service login 
   login[365]: pam_unix session finished for user root, service login 
   

2. passwd : changement de mot de passe

   PAM-warn[400]: service: passwd [on terminal: <unknown>] 
   PAM-warn[400]: user: (uid=0) -> root [remote: ?nobody@?nowhere] 
   PAM-warn[400]: service: passwd [on terminal: <unknown>] 
   PAM-warn[400]: user: (uid=0) -> root [remote: ?nobody@?nowhere] 
   

3. xdm : login graphique

1.11 Nouveaux utilisateurs

1. Il est utile que les mêmes utilisateurs aient les mêmes uid d'une installation à la suivante (ce qui permet de conserver les droits... ). Cette remarque est en particulier valable pour $ipse.
2. Ne pas oublier d'élaguer le squelette, c'est à dire /etc/skel avant de créer les utilisateurs.
3. useradd [-c comment] [-d home_dir] [-e expire_date] [-f inactive_time] [-g initial_group] [-G group[,...]] [-m [-k skeleton_dir]] [-o] [-p passwd] [-s shell] [-u uid] login
4. Recopier au minimum $ipse/bin et $ipse/docs/nullix

• kusers (anciennes versions) n'attribue pas correctement les droits sur les fichiers.
• kmusers semble fonctionner correctement.
• gag interplanétaire : pass ne s'écrit pas pareil dans les claviers us et fr. Or le password ne s'affiche pas (trou de sécurité dans l'anti-trou).