Audit et sécurisation des systèmes IBM AS/400

Introduction

L’objectif de cet article est de présenter rapidement les spécificités de ces équipements ainsi qu’un retour d’expérience sur les points faibles et les axes d’amélioration les plus souvent identifiés par nos équipes lors d’audits récents sous la forme de Quick Wins facilement mis en œuvre.

L’équipe Audit Technique de Digitemis réalise régulièrement des tests d’intrusion et des audits de configuration sur des équipements IBM AS/400. Ces tests font en général partie d’une démarche d’audit du système d’information au sens large (campagne de tests d’intrusion internes), mais ils visent parfois à évaluer le niveau de sécurité de ces infrastructures en particulier. Ces audits permettent d’élaborer les scénarios d’intrusion les plus probables, mais également d’identifier les éléments de configuration pouvant être ajustés pour durcir ces équipements souvent critiques.

Lors des tests d’intrusion, nous simulons ainsi le comportement d’un attaquant cherchant à s’introduire sur ces serveurs et à en prendre le contrôle, même partiel. La première phase de tests est réalisée en boîte noire depuis le poste d’un de nos auditeurs, ne disposant d’aucune information particulière. Une approche boîte grise est également possible, au travers de la fourniture de compte utilisateur sans privilège particulier. Les tests se concentrent alors sur les possibilités d’élévation de privilèges sur les serveurs ciblés.

Ces tests d’intrusion sont souvent complémentés par une revue de la configuration d’un point de vue sécurité. Nous comparons alors la configuration existante aux meilleures pratiques en termes de sécurité, aux guides de sécurisation fournis par IBM ainsi que l’état de l’art sur le sujet (publications, guides de durcissement tiers …).

Historique et spécificités de ces équipements

Les serveurs IBM AS/400 ont vu le jour dès 1988. Ils ont successivement été renommés en eServer iSeries puis System i5, mais ils sont encore affectueusement (?) nommés AS/400. Nous conserverons donc cette dénomination pour la totalité de cet article. Ils sont particulièrement présents dans les entreprises françaises, un marché historiquement important pour IBM, notamment dans les années 90-2000. De nombreuses applications métiers ou supports critiques ont ainsi été développées sur ces plateformes au cours des années et il n’est pas rare que ces serveurs applicatifs soient encore aujourd’hui au cœur des activités de nombreuses entreprises.

Le principal atout de ces serveurs est qu’ils ont été conçus pour opérer sans que les administrateurs n’aient à réaliser d’interventions de maintenance fréquentes. Ils reposent sur un système d’exploitation ad hoc : OS/400, qui a été développé spécifiquement pour ces équipements. Longtemps monolithiques, ces machines compatibles avec les programmes développés pour IBM AIX supportent maintenant une forme de virtualisation (partitionnement logique) permettant de faire fonctionner en parallèle des systèmes Linux et OS/400 sur le même matériel.

Le système d’exploitation OS/400 présente la particularité d’être intégralement orienté objet. Ainsi tous les composants et paramètres suivants sont considérés comme des objets :

• fichiers et bases de données
• comptes utilisateur
• fonctions et menus de configuration
• journaux d’évènements.

À ce titre, ils disposent tous de contrôle d’accès (ACL), appelés Authorities par IBM, qui sont la pierre angulaire du modèle de sécurité du système d’exploitation. Par ailleurs, une discrimination assez fine entre les droits publics, privés et spéciaux, couplée à la définition de groupes de droits (profils), permet d’obtenir un niveau de sécurité élevé sur les objets du système.

Le principal atout des AS/400 vient de l’intégration en une unique plateforme de multiples outils et applications clef en main. Les lettres A et S d’AS/400 signifient d’ailleurs Application Server et un serveur type fournit d’emblée :

• des services réseau et d’administration : HTTP, DNS, DHCP, Telnet et même SSH
• des serveurs d’applications : IBM Websphere et la pile JAVA associées
• des bases de données DB2

Le système peut être étendu à l’aide de paquets logiciels. IBM effectue régulièrement le travail de portage des technologies les plus répandues : PHP, Ruby on Rails et plus récemment Node.JS.

Enfin, des mises à jour, notamment de sécurité, sont publiées régulièrement par l’éditeur sous la forme de PTF (Program Temporary Fix).

Quick Wins

Les points d’attention présentés ici n’ont pas pour objectif d’être exhaustifs, mais représentent un échantillon des défauts de configuration que nous rencontrons fréquemment ainsi que les paramètres permettant de relever rapidement le niveau de sécurité.

1) Point de vue auditeur : top 5 des vecteurs d’intrusion

Comptes par défaut

De nombreux comptes sont créés par défaut à l’installation d’un équipement neuf, parmi ceux-ci figurent des comptes d’administration disposant de privilèges importants. Par ailleurs, l’interface de connexion 5020/Telnet est assez verbeuse et il est facile d’énumérer les comptes existants.

Service HTTP

Comme mentionné plus haut, les AS/400 embarquent le plus souvent un serveur applicatif IBM WebSphere reposant sur la pile Java. Il s’agit d’une cible de choix, car la compromission de son interface d’administration permettra de déposer une application web malveillante (Webshell) et prendre le contrôle du système sous-jacent. C’est plus rare, mais il est également possible de trouver des serveurs applicatifs Apache Tomcat sur ces machines, avec les mêmes conséquences à la clef …

Les partages réseau

Au même titre que les serveurs Windows ou Linux, les serveurs AS/400 offrent des fonctionnalités de partages de fichiers, d’ailleurs compatibles avec les technologies courantes (SMB/Samba). Ils sont donc affectés par les mêmes problèmes : accès non restreints ou trop permissifs, partage de documents ou de répertoires sensibles …

Accès anonymes

De nombreux services réseau embarqués par défaut font parfois l’objet de problème de configuration. Ce n’est malheureusement pas spécifique aux AS/400, mais certains protocoles ne requièrent ainsi pas systématiquement d’authentification : FTP, LDAP, SNMP…

Les protocoles d’administration non sécurisés

Dans le cas de tests d’intrusion sur le réseau interne, la réalisation d’attaques « Man-In-The-Middle » sur les protocoles d’administration peut souvent s’avérer payante. L’administration d’AS/400 est traditionnellement réalisée au travers d’un terminal (ou plus couramment d’un émulateur de terminal) 5250 reposant sur le protocole Telnet, n’assurant pas le chiffrement des échanges. Mais d’autres protocoles, spécifiques à ces serveurs IBM, ne sont pas toujours remplacés par leurs équivalents sécurisés : as-admin-http, as-mtgc, as-database, as-file, …

Il est intéressant de noter que ces 5 principaux vecteur d’intrusion ne sont absolument pas spécifiques aux machines IBM. Il s’agit de failles très fréquemment rencontrées lors de tests d’intrusion dits classiques. Les recommandations en découlant sont évidentes et souvent assez rapides et peu complexes à mettre en œuvre.

2) Point de vue administrateur : top 5 des mesures de durcissement

Ajuster la valeur QSECURITY

Définir la bonne valeur pour cette variable système constitue la première étape indispensable pour sécuriser un AS/400. Les valeurs 40 et 50 garantissent l’authentification des utilisateurs, la sécurité des ressources et un certain niveau de protection d’intégrité des données.

Politique de mots de passe

Contrairement à un a priori répandu, la politique de mot de passe d’un serveur AS/400 peut être particulièrement robuste si elle est correctement configurée. Il est ainsi possible de configurer les tailles minimales et maximales, le jeu de caractères requis, le délai d’expiration, l’historique, etc. Il existe même la directive ANZDFTPWD permettant de passer en revue les comptes existants à la recherche de mots de passe triviaux ou présents par défaut.

Contrôle d’accès sur les fonctions système critiques

Plusieurs commandes ou menus du système OS/400 sont sensibles et peuvent être utilisées pour réaliser des opérations de maintenance critiques sur le serveur (manipulation de fichiers sans générer de trace d’audit, création et manipulation de profils utilisateur, configuration des paramètres de sécurité du système …). Il est nécessaire de restreindre les droits des utilisateurs sur ces commandes, afin de s’assurer que seuls les profils habilités peuvent les utiliser.

Droits des utilisateurs

Effectuer une revue régulière des droits appliqués aux utilisateurs du système est une opération indispensable à la tenue d’un serveur AS/400. Il est en particulier important d’auditer les droits publics (*PUBLIC), car un attaquant pourra tirer parti de droits mal configurés pour exécuter des tâches et réaliser des actions dans le contexte d’un autre utilisateur…

File d’attente d’évènements QSYSMSG

Cette file d’attente n’est pas créée par défaut lors de l’installation d’un équipement neuf ou la montée en version du système. Or celle-ci réceptionne de nombreuses informations système importantes qu’il est conseillé de journaliser (les erreurs d’authentification par exemple).

Il ne s’agit là que des exemples les plus frappants ou les plus courants. Il est par ailleurs surprenant que les serveurs AS/400 dont le socle système offre de nombreuses fonctionnalités de sécurité modernes ne soient que très rarement rencontrés dans une configuration durcie. Ces équipements n’ont pas (encore) été rendus obsolètes par le « tout-cloud » et de par leur criticité valent en général de se pencher sérieusement sur leur sécurisation…

Je partage