2.2. Inspection des ports ouverts pour immuniser les programmes

Une méthode automatisée de recherche des démons de serveur réseau devant être profilés consiste à utiliser l'outil non confiné. Vous pouvez également consulter simplement un rapport de ces informations dans l'interface graphique de YaST. Reportez-vous à Section 4.3.1.1, « Rapport d'audit d'application » (↑Guide d'administration de Novell AppArmor 2.0) pour obtenir des instructions.

L'outil non confiné utilise la commande netstat -nlp pour inspecter vos ports ouverts depuis votre ordinateur, détecter les programmes associés à ces ports et inspecter l'ensemble de profils Novell AppArmor que vous avez chargés. L'outil non confiné signale ensuite ces programmes avec le profil Novell AppArmor associé à chacun d'entre eux, ou signale « aucun » si le programme n'est pas confiné.

[Note]Remarque

Si vous créez un nouveau profil, vous devez redémarrer le programme ayant été profilé comme non confiné pour détecter et signaler le nouvel état profilé.

Vous trouverez ci-dessous un exemple de résultat non confiné :

2325 /sbin/portmap not confined 
37021 /usr/sbin/sshd2 confined
   by '/usr/sbin/sshd3 (enforce)' 
4040 /usr/sbin/ntpd confined by '/usr/sbin/ntpd (enforce)' 
4373 /usr/lib/postfix/master confined by '/usr/lib/postfix/master (enforce)' 
4505 /usr/sbin/httpd2-prefork confined by '/usr/sbin/httpd2-prefork (enforce)'
5274 /sbin/dhcpcd not confined 
5592 /usr/bin/ssh not confined 
7146 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (complain)'
  
1

La première partie est un nombre. Il s'agit du numéro PID du programme d'écoute.

2

La deuxième partie est une chaîne représentant le chemin absolu du programme d'écoute.

3

La dernière partie indique profil qui confine le programme, le cas échéant.

[Note]Remarque

L'outil non confiné nécessite des privilèges root. Il ne doit pas être exécuté à partir d'un shell confiné par un profil AppArmor.

L'outil non confiné ne fait pas la distinction entre une interface réseau et une autre. Il signale ainsi tous les processus non confinés, même ceux qui écoutent éventuellement une interface LAN interne.

La recherche d'applications clientes du réseau de l'utilisateur dépend des préférences que vous avez définies. L'outil non confiné détecte et signale les ports réseau ouverts par les applications clientes, mais uniquement les applications clientes qui fonctionnent lors de l'analyse de l'outil non confiné. Il s'agit d'un problème ; en effet, les services réseau tendent à fonctionner en permanence, tandis que les applications clientes du réseau tendent à ne fonctionner que lorsque l'utilisateur s'y intéresse.

L'application de profils Novell AppArmor aux applications clientes du réseau de l'utilisateur dépend également des préférences de l'utilisateur. Novell AppArmor est davantage conçu pour les serveurs que pour les postes de travail. Nous laissons donc l'utilisateur s'exercer au profilage des applications clientes du réseau.

Pour confiner des applications de bureau de façon agressive, la commande non confinée prend en charge une option Paranoïa, qui signale tous les processus en cours d'exécution, et les profils AppArmor correspondants qui peuvent ou non être associés à chaque processus. L'utilisateur non confiné peut ensuite décider si chacun de ces programmes nécessite un programme AppArmor.

Si vous avez des profils nouveaux ou modifiés, vous pouvez les envoyer à la liste de messagerie apparmor-general@forge.novell.com accompagnés d'un cas d'utilisation correspondant au comportement de l'application. L'équipe AppArmor l'examinera avant d'éventuellement l'envoyer à openSUSE. Nous ne pouvons pas garantir que chaque profil sera inclus, mais nous ferons tous nos efforts pour en inclure le plus grand nombre possible afin que les utilisateurs puissent contribuer aux profils de sécurité livrés avec openSUSE.

2.2.1. Immunisation des tâches Cron

Pour trouver les programmes exécutés par cron, vous devez inspecter votre configuration cron locale. Malheureusement, la configuration cron est assez complexe et il faut inspecter un grand nombre de fichiers. Des tâches cron périodiques sont exécutées à partir des fichiers suivants :

/etc/crontab 
/etc/cron.d/* 
/etc/cron.daily/* 
/etc/cron.hourly/*
/etc/cron.monthly/* 
/etc/cron.weekly/*

Vous pouvez éditer les tâches cron root avec crontab -e et en afficher la liste avec crontab -l. Vous devez être un utilisateur root pour que cela soit possible.

Après avoir trouvé ces programmes, vous pouvez utiliser Ajouter un assistant de profil pour leur créer des profils. Reportez-vous à la Section 3.3.1, « Ajout d'un profil à l'aide de l'assistant » (↑Guide d'administration de Novell AppArmor 2.0).

2.2.2. Immunisation d'applications Web

Pour trouver des applications Web, vous devez rechercher dans la configuration de votre serveur Web. Le serveur Web Apache est hautement configurable. Les applications Web peuvent être stockées dans un grand nombre de répertoires, en fonction de votre configuration locale. SUSE Linux, par défaut, stocke les applications Web dans /srv/www/cgi-bin/. Dans la mesure du possible, chaque application Web doit avoir un profil Novell AppArmor.

Après avoir trouvé ces programmes, vous pouvez utiliser Ajouter un assistant de profil dans AppArmor pour leur créer des profils. Reportez-vous à la Section 3.3.1, « Ajout d'un profil à l'aide de l'assistant » (↑Guide d'administration de Novell AppArmor 2.0).

2.2.2.1. Confinement des programmes CGI et des sous-processus dans des applications Web

Du fait que les programmes CGI sont exécutés par le serveur Web Apache, le profil d'Apache lui-même usr.sbin.httpd2-prefork (pour Apache2 sur SUSE Linux) doit être modifié pour ajouter des autorisations d'exécution à chacun de ces programmes. Par exemple, l'ajout de la ligne /srv/www/cgi-bin/my_hit_counter.pl rpx accorde à Apache l'autorisation d'exécuter le script Perl my_hit_counter.pl et nécessite la présence d'un profil dédié pour my_hit_counter.pl. Si aucun profil dédié n'est associé à my_hit_counter.pl, la règle doit indiquer /srv/www/cgi-bin/my_hit_counter.pl rix pour que my_hit_counter.pl hérite du profil usr.sbin.httpd2-prefork.

Certains utilisateurs trouveront peu pratique de spécifier des autorisations d'exécution pour chaque script CGI susceptible d'être appelé par Apache. À la place, l'administrateur peut accorder l'accès contrôlé à ces ensembles de scripts CGI. Par exemple, l'ajout de la ligne /srv/www/cgi-bin/*.{pl,py,pyc} rix permet à Apache d'exécuter tous les fichiers de /srv/www/cgi-bin/ se terminant par .pl (scripts Perl) et .py ou .pyc (scripts Python). Comme ci-dessus, la partie ix de la règle fait hériter les scripts Python du profil Apache, ce qui est approprié si vous ne souhaitez pas écrire des profils individuels pour chaque script Python.

[Note]Remarque

Si vous souhaitez la fonctionnalité du module de confinement de sous-processus (mod-apparmor) lorsque des applications Web gèrent des modules Apache (mod_perl et mod_php), utilisez les fonctions ChangeHat lorsque vous ajoutez un profil dans YaST ou à la ligne de commande. Pour bénéficier du confinement de sous-processus, reportez-vous à la Section 5.1, « Apache ChangeHat » (↑Guide d'administration de Novell AppArmor 2.0).

Le profilage d'applications Web utilisant mod_perl et mod_php nécessite une manipulation légèrement différente. Dans ce cas, le « programme » est un script interprété directement par le module au sein du processus Apache. Aucune exécution ne se produit donc. À la place, la version Novell AppArmor d'Apache appelle change_hat() pour nommer un sous-profil (un « hat ») correspondant au nom de l'URI demandée.

[Note]Remarque

Le nom présenté que le script doit exécuter peut ne pas être l'URI, selon la façon dont Apache a été configuré en matière de recherche de scripts de module. Si vous avez configuré Apache pour placer les scripts à un emplacement différent, les différents noms apparaissent dans syslog lorsque Novell AppArmor se plaint de violations d'accès. Reportez-vous au Chapitre 4, Gestion des applications profilées (↑Guide d'administration de Novell AppArmor 2.0).

Pour les scripts mod_perl et mod_php, c'est le nom du script Perl ou de la page PHP demandée. Par exemple, l'ajout de ce sous-profil permet à la page localtime.php de s'exécuter et d'accéder à l'heure locale du système :

/usr/sbin/httpd2-prefork^/cgi-bin 
localtime.php { 
/etc/localtime                        r, 
/srv/www/cgi-bin/localtime.php        r, 
/usr/lib/locale/**                    r, 
}

Si aucun sous-profil n'a été défini, la version Novell AppArmor d'Apache applique le hat DEFAULT_URI. Ce sous-profil est généralement suffisant pour afficher une page Web HTML. Par défaut, Novell AppArmor fournit le hat DEFAULT_URI suivant :

/usr/sbin/suexec2 ixr, 
/var/log/apache2/** rwl,
/home/*/public_html/**             r, 
/srv/www/htdocs/**                 r, 
/srv/www/icons/*.{gif,jpg,png}     r, 
/usr/share/apache2/**              r,
    

Si vous souhaitez un seul profil Novell AppArmor pour l'ensemble des pages Web et des scripts CGI servis par Apache, une bonne approche consiste à modifier le sous-profil DEFAULT_URI.

2.2.3. Immunisation des agents réseau

Pour trouver les démons de serveur réseau devant être profilés, vous devez inspecter les ports ouverts sur votre machine, vérifier les programmes qui répondent sur ces ports et fournir des profils pour le plus grand nombre possible de ces programmes. Si vous fournissez des profils pour tous les programmes ayant des ports réseau ouverts, un attaquant ne peut pas atteindre le système de fichiers de votre machine sans passer par une stratégie de profil Novell AppArmor.

Recherchez manuellement sur votre serveur les ports réseau ouverts depuis l'extérieur de la machine à l'aide d'un outil de recherche tel que nmap, ou depuis l'intérieur de la machine avec netstat. Inspectez ensuite la machine pour déterminer les programmes qui répondent sur les ports ouverts non découverts.