Translation by eberkut - http://www.chez.com/keep
Qu'est-ce que l'ID ?
ID représente Intrusion Detection, qui est l'art de détecter une activité
inappropriée, incorrecte ou anormale. Des sytèmes ID qui opèrent sur un hôte
pour détecter une activité malveillante sur cet hôte sont appelés host-based
ID systems, et des systèmes ID qui opèrent sur un flux de données réseau
sont appelés network-based ID systems.
Parfois, une distinction est faite entre abus et détection d'intrusion. Le
terme intrusion est employé pour décrire des attaques à partir de
l'extérieur ; considérant que, l'abus est employé pour décrire une attaque
qui provient du réseau interne. Cependant, la plupart des personnes ne font pas
de telles distinctions.
Les approches les plus communes en ID sont la détection statistique d'anomalie
et la détection de pattern-matching.
Dirk Lehmann
Siemens CERT
Qu'est-ce qu'un bastion host ?
Un bastion host est un ordinateur qui est entièrement exposé à l'attaque. Le
système est du côté public de la zone démilitarisée (DMZ), non protégé
par un firewall ou un routeur filtrant. Fréquemment les rôles de ces systèmes
sont critiques au système de sécurité de réseau. En effet les firewall et
les routeurs peuvent être considérés comme des bastion hosts. En raison de
leur grande exposition, un grand effort doit être mis dans la conception et la
configuration des bastion hosts pour minimiser les chances de pénétration.
D'autres types de bastion hosts inclus des servers web, mail, DNS et FTP.
Quelques administrateurs réseau utiliseront également les bastion hosts comme
des sacrifices, ces systèmes sont délibérément exposé aux intrus
potentiels pour faciliter la traçabilité des tentatives d'intrusion.
Les bastion hosts pertinents sont configurés très différemment des hôtes
typiques. Chaque bastion host accomplit un rôle spécifique, tous les services
inutiles, protocoles, programmes, et les ports réseau sont déconnectés ou
supprimés. Les bastion hosts ne partagent pas de services d'authentification
avec les hôtes de confiance dans le réseau de sorte que si un bastion est
compromis l'intrus n'ait néanmoins pas 'les clés du château'. Un bastion host
est durci pour limiter les méthodes d'attaque potentielles. Les étapes
spécifiques pour durcir un bastion host particulier dépendent du rôle
destiné de cet hôte aussi bien que le système d'exploitation et le logiciel
qu'il exploitera. Access Control Lists (ACLs) sera modifié sur le système de
fichiers et d'autres objets système ; tous les ports inutiles de TCP et de UDP
seront stoppés ; tous les services et démons non critiques seront supprimés ;
autant d'utilitaires et d'outils de configuration système seront retirés. Tous
les service packs appropriés, bug fix, et patches devront être installés. Le
logging de tous les événements associés à la sécurité doit être permis et
des mesures doivent être prises pour assurer l'intégrité des logs de sorte
qu'un intrus ne puisse pas effacer l'évidence de sa visite. Toutes les bases de
données locales de compte et de passwords d'utilisateur devraient être
cryptés si possible.
La dernière étape pour sécuriser un bastion host peut être la plus difficile
: sécuriser les applications réseau que l'hôte exécute. Très souvent le
vendeur d'un serveur web ou de media streaming ne considère pas les risques de
sécurité tout en développant leur produit. Il appartient habituellement à
l'administrateur système de déterminer en testant quel ACLs ils doivent
modifier pour verrouiller de la demande de réseau aussi complètement que
possible sans invalider les dispositifs mêmes qui font est un outil utile. Il
est également nécessaire de surveiller avec attention les dernières annonces
du constructeur concernant des problèmes de sécurité et des patchs. Les
applications réseau les plus diffusées tendent également à inspirer la
création de mailing-lists, de newsgroups, et des sites web indépendants qui
peuvent être surveillés pour des avis supplémentaires.
Kurt Dillard
Collective Technologies, Inc
Qu'est-ce que la behavior-based intrusion
detection ?
Il y a 2 approches complémentaires pour détecter des intrusions, l'approche
knowledge-based et l'approche behavior-based. Cet article décrit la seconde
approche. Notez que très peu d'outils mettent en application aujourd'hui une
telle approche, même si l'article fondateur de Denning {D. Denning, An
Intrusion Detection Model, IEEE transactions on software engineering} identifie
ceci comme condition pour des systèmes de détection d'intrusion .
les techniques behavior-based intrusion detection supposent qu'une intrusion
peut être détectée en observant une modification du comportement normal ou
prévu du système ou des utilisateurs. Le modèle du comportement normal ou
valide est extrait à partir d'informations de référence rassemblées par de
divers moyens. Le système de détection d'intrusion compare plus tard ce
modèle à l'activité courante. Quand un changement est observé, une alarme
est générée. En d'autres mots, tout ce qui est fait qui ne correspond pas à
un comportement préalablement appris est considéré comme une intrusion. Par
conséquent, le système de détection d'intrusion pourrait être complet (i.e.
toutes les attaques devraient être détectées), mais son exactitude est un
facteur difficile (i.e. vous allez beaucoup d'alarmes).
Les avantages des approches basées sur le comportement sont qu'elles peuvent
détecter des tentatives d'exploitation de nouvelles et imprévues
vulnérabilités. Ils peuvent même contribuer (partiellement) à la découverte
automatique de ces nouvelles attaques. Ils sont moins dépendants des
mécanismes spécifiques des systèmes d'exploitation. Ils aident également à
détecter les types d'attaques "d'abus de privilèges" qui
n'impliquent pas réellement d'exploiter aucune vulnérabilité de sécurité.
En bref, c'est l'approche paranoïaque : Tout ce qui n'a pas été vu
précédemment est dangereux.
Le nombre élevé de fausses alarmes est généralement citée comme
inconvénient majeur des techniques basées sur le comportement parce que la
portée entière du comportement d'un système d'information ne peut être
couverte pendant la phase d'apprentissage. En outre, le comportement peut
changer avec le temps, présentant le besoin de réapprentissage en ligne
périodique du profil de comportement, ayant comme conséquence
l'indisponibilité du système de détection d'intrusion ou de fausses alarmes
supplémentaires. Le système d'information peut subir des attaques en même
temps que le système de détection d'intrusion assimile le comportement. En
conséquence, le profil comportemental contient le comportement intrusif, qui
n'est pas détecté comme anormal.
Herve Debar
IBM Zurich Research Laboratory
Qu'est-ce que la knowledge-based intrusion
detection ?
Il y a 2 approches complémentaires pour détecter des intrusions, l'approche
knowledge-based et l'approche behavior-based. Cet article décrit la première
approche. Presque tous les outils d'IDS sont aujourd'hui knowledge-based. Cela
se réfère également dans la littérature comme détection de mauvaise
utilisation.
les techniques de détection d'intrusion basé sur la connaissance appliquent
les connaissances accumulées au sujet des attaques et des vulnérabilités
spécifiques du système. Le système de détection d'intrusion contiennent des
informations sur ces vulnérabilités et recherche des tentatives d'exploiter
ces vulnérabilités. Quand une telle tentative est détectée, une alarme est
déclenchée. En d'autres termes, toute action qui n'est pas explicitement
identifiée comme une attaque est considérée acceptable. Par conséquent,
l'exactitude des systèmes de détection d'intrusion basé sur la connaissance
est considérée bonne. Cependant, leur perfection (i.e. le fait qu'ils
détectent toutes les attaques possibles) dépend de la mise à jour régulière
des connaissances concernant les attaques.
Les avantages des approches basées sur la connaissance sont qu'elle ont un
potentiel de fausses alarmes vraiment faible, et l'analyse contextuelle
proposée par le système de détection d'intrusion est détaillée, facilitant
pour l'administrateur sécurité l'utilisation du système de détection
d'intrusion afin de prendre des mesures correctives ou préventives.
Les inconvénients incluent la difficulté de recueillir l'information exigée
sur les attaques connues et de la maintenir à jour avec de nouveaux
vulnérabilités et environnements. L'entretien de la base de connaissance du
système de détection d'intrusion exige l'analyse soigneuse de chaque
vulnérabilité qui est donc une tâche longue. Les approches basées sur la
connaissance doivent également faire face à la généralisation des sorties.
La connaissance concernant les attaques est très réduite, dépendant du
système d'exploitation, de la version, de la plate-forme, et des applications.
L'outil de résultat de la détection d'intrusion est par conséquent
étroitement rattaché ) un environnement donné. En outre, la détection des
attaques internes comportant un abus de privilèges est considérée plus
difficile parce qu'aucune vulnérabilité n'est exploitée réellement par
l'attaquant.
Herve Debar
IBM Zurich Research Laboratory
Pourquoi mon système de détection d'intrusion génère de fausses alarmes / pas d'alarmes ?
Tout d'abord, il est extrêmement difficile de
détecter les intrusions. Nous voyons seulement la génération des outils
commerciaux, et ils sont limités dans la portée. Cependant, il est clair que
l'un ou l'autre de ces outils contemporains indiquent beaucoup de fausses
attaques positives (i.e. signaler des attaques quand il n'y en a pas) ou les
omettent. Même les outils basés sur des signatures d'attaque produisent d'un
grand nombre de fausses alarmes, dans les cas les plus inattendus.
Une des raisons les plus évidentes pour lesquelles les fausses alarmes se
produisent est parce que les outils sont sans état. Pour détecter une
intrusion, un simple pattern matching des signatures est souvent insuffisant.
Cependant, c'est ce que font la plupart des outils. Alors, si la signature n'est
pas soigneusement conçue, il y aura un bon nombre d'alertes. Par exemple, les
outils détectent des attaques sendmail en recherchant les mots
"DEBUG" ou "WIZARD" comme premier mot d'une ligne. Si c'est
dans le corps du message, il est en fait innofensif, mais si l'outil ne
différencie pas l'en-tête et le corps du courrier, alors une fausse alarme est
produite.
Un autre exemple traite des requêtes HTTP pour de mauvais scripts. On voudrait
réellement savoir si la requêtes était réussie ou pas, parce que la
réaction est vraiment différente. Dans le second cas, c'est un ennui mineur,
dans le premier une infraction dangereuse de sécurité. Puisque les outils
n'ont pas la notion de la session, créer une telle signature est tout à fait
difficile.
Dans le royaume faux positif , les outils ne peuvent pas faire face à la
quantité de données à analyser. Gardez à l'esprit que 99,99% des données
analysées le sont pour rien, et que pour chacun de ces blocs de données, tous
les essais d'attaque doivent être exécutés ! Par conséquent, l'exactitude
est souvent sacrifiée au profit de la vitesse. En outre, il y a beaucoup de
manières de détecter une attaque, et parfois les attaquants arrivent
rapidement avec de nouvelles méthodes qui rendent obsolète le mécanisme de
détection.
En conclusion, il y a beaucoup d'événements se produisant au cours de la vie
normale de n'importe quel système ou réseau qui peut être confondue avec des
attaques. Beaucoup d'activité de sysop peut être cataloguée comme anormale.
Par conséquent, une corrélation claire entre les données d'attaque et les
données administratives devrait être établie pour contre-vérifier que tout
qui se produit sur un système est désirée réellement.
Herve Debar
IBM Zurich Research Laboratory
L'ID basé sur l'hôte implique de charger un
ou des blocs de logiciel sur le système à surveiller. Le logiciel chargé
utilise des fichiers logs et/ou des agents auditant le système comme sources
d'information. En revanche, un système ID basé sur le réseau moniteur le
trafic sur son segment de réseau comme source d'information. Les capteurs ID
network-based et host-based ont tous 2 des avantages et des inconvénients, et
à la fin, vous voudrez probablement utiliser une combinaison de chacun. La
personne chargée de surveiller les IDS doit être alerte, un administrateur
système compétent, qui est familier de la machine hôte, des connexions
réseau, des utilisateurs et de leurs habitudes, et de tous logiciel installé
sur la machine. Ceci ne signifie pas que lui ou elle doit être un expert du
logiciel lui-même, mais a besoin plutôt de sentir la façon dont la machine
est censée fonctionner et quels programmes sont légitimes. Beaucoup
d'intrusions ont été contenus par des Sys Admin attentifs qui ont noté
quelque chose de "différent" au sujet de leurs machines ou qui ont
noté à la fois le log d'un utilisateur et une entrée atypique pour cet
utilisateur.
L'ID basé sur l'hôte implique de regarder non seulement le trafic des
transmissions dans et hors d'un ordinateur simple, mais également de contrôler
l'intégrité de vos fichiers système et d'observer les processus soupçonneux.
Pour atteindre l'assurance complète votre site avec l'ID host-based, vous devez
charger le logiciel ID sur chaque ordinateur. Il y a 2 classes primaires de
logiciel de détection d'intrusion basé sur l'hôte : wrappers/firewall
personnel hôte et logiciel basé sur des agents. L'une ou l'autre approche est
beaucoup plus efficace en détectant des attaques d'intrusion par des hôtes de
confiance (prétendue activité anormale) que ne l'est l'ID network-based, et
toutes les 2 sont relativement efficaces pour détecter des attaques à partir
de l'extérieur.
Les wrappers ou firewall personnels hôtes peuvent être configurés pour
regarder tous les paquets du réseau, tentatives de connexion, ou tentatives de
login sur la machine surveillée. Ceci peut également inclure des dial-in ou
d'autres ports de communication non-réseau relatés. Les meilleurs exemples
connus des package wrapper sont TCPWrappers (http://coast.cs.purdue.edu/pub/tools/unix)
pour Unix et NukeNabber (http://www.amitar.com.au/DOWNLOADS/INTERNET/PROTECTION/NukeNabber_2_9b.html)
pour Windows. Les firewalls personnels peuvent également détecter des
logiciels sur l'hôte tentant de se connecter au réseau, tel que WRQ's AtGuard
(http://www.atguard.com).
En outre, les agents basés sur l'hôte peuvent pouvoir surveiller des accès et
des modifications de fichiers de système critiques et des changements de
privilège d'utilisateur. Les versions commerciales bien connues incluent des
produits d'Axent (www.axent.com), CyberSafe,
(www.cybersafe.com) ISS, (www.iss.net)
et Tripwire (www.tripwiresecurity.com).
(Il y a également une Academic Source Release de Tripwire disponible si votre
site est un département académique d'une université d'état.)
En outre, UNIX a un ensemble riche d'outils logiciel pour performer de la
détection d'intrusion. Un unique package ne fera tout, et le logiciel devrait
être conçu en fonction de l'ordinateur individuel qui est surveillé. Par
exemple, si une machine a seulement une poignée d'utilisateurs, peut-être
seuls des connexions de l'extérieur et l'intégrité des fichiers système
nécessitent d'être surveillé ; considérant que, une machine avec beaucoup
d'utilisateurs ou le trafic réseau peut avoir besoin de surveillance plus
rigoureuse. Les types de logiciel qui aident la surveillance des hôtes inclus :
fichiers logs système et utilisateur (syslog) ; surveillance des connexions (TCPwrappers,
lastlog) ; surveillance des processus (lsof (http://vic.cc.purdue.edu/pub/tools/unix/lsof),
process accounting) ; surveillance de l'usage du dissque (quotas) ; surveillance
des sessions (options de ftpd pour logger tous les transferts de fichier,
process accounting) ; audit du système (audit).
La détection d'intrusion basée sur l'hôte d'UNIX est seulement aussi bonne
qu'un logger. Des programmes peuvent être écrits pour analyser des fichiers de
logs et pour alerter l'admin système par l'intermédiaire d'un mail ou d'un
pager quand quelque chose va de travers. La sortie de journal système peut
être envoyée à un site à distance ou être modifiée, de sorte que les
fichiers logs soient mis dans les endroits non standard pour empêcher des
intrus d'effacer leurs traces. Avec la prédominance des scripts de hacking, la
surveillance peut être installé pour observer pour des exemples spécifiques
des intrusions. Quelques "must-reads" pour l'admin système nouveau
dans la détection d'intrusion basée sur l'hôte sont Practical Unix &
Internet Security par Simson Garfinkel et Gene Spafford, (2nde édition, publié
par O'Reilly) et Intrusion Detection : An Introduction to Internet Surveillance,
Correlation, Trace Back, Traps, and Response, par Edward Amoroso", (publié
par Intrusion.Net Books). Les pagss de manuel pour des daemons réseau
fournissent des informations sur la façon dont effectuer le logging. Une partie
quelconque des programmes xxxstat (vmstat, netstat, nfsstat) ou de logiciel
comme top (ftp.groupsys.com/pub/top) peuvent aider à préciser l'activité
soupçonneuse. Connaissez votre système, et connaissez-le bien.
Un IDS véritablement pertinent utilisera une combinaison de détection
d'intrusion host-based et network-based. L'utilisation de chaque type et
l'intégration des données est un réel soucis croissant.
Laurie Zirkle, CSE
Virginia Tech CNS
Un système ID network-based surveille le
trafic sur son segment de réseau comme source d'informations. Ceci est
généralement accompli en plaçant la carte d'interface réseau en mode
promiscuous pour capturer tout le trafic réseau qui croise son segment réseau.
Le trafic réseau sur d'autres segments, et le trafic sur d'autres moyens de
communication (comme les lignes téléphoniques) ne peuvent pas être
surveillés. Les capteurs ID network-based et host-based ont des avantages et
des inconvénients. En fin de compte, vous voudrez probablement une combinaison
des 2.
L'ID basée sur le réseau implique de regarder les paquets sur le réseau
pendant qu'ils passent par un certain capteur. Le capteur peut seulement voir
les paquets qui s'avèrent justement être destiné à son segment réseau. Des
paquets sont considérés d'intérêt s'ils correspondent à une signature.
Trois types primaires de signatures sont des signatures de strings, des
signatures de ports, et des signatures d'header condition.
Les signatures de strings recherchent une strings textes qui indique une attaque
possible. Une signature de string type pour UNIX pourrait être "cat"
"> /.rhosts", qui si ils réussissent, pourraient rendre un
système UNIX extrêmement vulnérable aux intrusions réseau. Pour raffiner la
signature de string afin réduire le nombre de faux positifs, il peut être
nécessaire d'employer une signature composée de strings. Une signature
composée de strings pour une attaque commune de serveur web pourrait être
"cgi-bin" ET "aglimpse" ET "IFS".
Les signatures de ports surveillent simplement la connexion essaye aux ports
bien connus et fréquemment attaqués. Les exemples de ces ports incluent telnet
(port 23 TCP), ftp (port 21/20 TCP), SUNRPC (port 111 TCP/UDP), et IMAP (port
143 TCP). Si aucun de ces ports n'est employé par le site, alors les paquets
entrants à ces ports sont soupçonneux.
Les signatures d'header surveillent des combinaisons dangereuses ou illogiques
dans des en-têtes de paquet. L'exemple le plus célèbre est Winnuke, où un
paquet est destiné à un port de NetBIOS et le pointeur Urgent ou Out of Band
est placé. Ceci a eu comme conséquence le "Blue Screen of the Death"
pour des systèmes Windows. Une autre signature d'header bien connue est un
paquet de TCP avec les flags SYN et FIN enclenchés, signifiant que le demandeur
souhaite commencer et arrêter une connexion en même temps.
Les systèmes de détection d'intrusion basés sur le réseau bien connus inclus
AXENT (www.axent.com), Cisco (www.cisco.com),
CyberSafe (www.cybersafe.com), ISS (www.iss.net),
and Shadow (www.nswc.navy.mil/ISSEC/CID).
Un IDS véritablement pertinent utilisera une combinaison de détection
d'intrusion host-based et network-based. L'utilisation de chaque type et
l'intégration des données est un réel soucis croissant.
Stephen Northcutt
SANS Institute
J'ai entendu dire que la meilleure approche en sécurité informatique était d'utilisé une approche par couche. Pouvez-vous décrire cette approche et comment un IDS l'applique-t-elle ?
L'approche par couches peut être comparée à
l'analogie météorologique d'un orage hivernale. Beaucoup de gens connaissent
le sentiment d'être coincé à la maison pendant une tempête de neige en
hiver. Les choses à faire lors d'un tempête hivernale sont de faire du potage,
d'allumer le four, de se réfugier sous les couvertures, et de commencer un feu
dans la cheminée. Toutes ces choses mènent à un sentiment de chaleur et de
sécurité en attendant que l'orage passe. C'est cette utilisation des choses
séparées dans le ménage dont résultent dans une approche globale le
sentiment chaud et brouillé dans une tempête hivernale. Ainsi, le degré de
sécurité informatique est le plus pertinent quand des couches multiples de
sécurité sont utilisées dans une organisation.
L'idée fausse la plus commune est qu'un firewall sécurisera vos installations
informatiques et des mesures supplémentaires n'ont pas besoin d'être prises.
Un firewall est juste un composant d'un modèle pertinent de sécurité. Des
composants ou des couches supplémentaires devraient être ajoutés pour fournir
un modèle efficace de sécurité dans votre organisation. Le modèle de
sécurité qui protégera votre organisation devrait être établi selon les
couches suivantes :
L'utilisation de couches multiples dans un
modèle de sécurité est la méthode la plus efficace de décourager
l'utilisation non autorisée des systèmes informatiques et des services
réseau. Chaque couche assure une certaine protection contre l'intrusion, et la
défaite d'une une couche peut ne pas mener à la compromission votre
organisation entière. Chaque couche a de l'interdépendance sur d'autres
couches. Par exemple, les systèmes de détection d'intrusion et le plan de
réponse d'incident ont quelques interdépendances. Bien qu'ils puissent être
mis en application indépendamment, c'est mieux quand ils sont mis en
application ensemble. Avoir un système de détection d'intrusion qui peut vous
alerter de tentatives non autorisées sur votre système a peu de valeur à
moins qu'un plan de réponse d'incident soit en place pour traiter des
problèmes. La partie la plus importante de l'organisation globale de sécurité
est la politique de sécurité. Vous devez savoir ce que vous devez protéger et
à quel degré. Toutes autres couches du modèle de sécurité suivent
logiquement après la mise en place de la politique de sécurité
d'organisation.
En résumé, un système de détection d'intrusion est juste un composant d'un
modèle pertinent de sécurité pour une organisation. L'intégrité globale de
sécurité de votre organisation dépend de la mise en place de toutes les
couches du modèle de sécurité. La mise en place de l'approche par couches de
sécurité devrait être entreprise d'une façon logique et méthodique pour les
meilleurs résultats et assurer la validité globale du personnel de sécurité.
Peter Watson
Senior Security Architect
Purolator Courier Corp.
Nous avons vu des sondes sur le port 1080, j'ai demandé à un analyste de prendre une minute et un document pour savoir ce qui se passe avec le 1080. Voici ce que Christopher Misra écrit et il fait toujours un peu de recherche :
Le port 1080 est employé par le protocole de networking proxy SOCKS. Il est conçu pour permettre à un hôte de l'autre d'un firewall de se connecter d'une manière transparente et solidement par firewall. Par conséquent, quelques sites peuvent avoir le port 1080 ouvert pour les connexions entrantes sur un système exécutant un daemon socks. Une des utilisations les plus communes de SOCKS semble permettre le trafic d'Icq aux hôtes qui sont derrière un firewall.
Un package commun qui fournit cette fonction est Wingate (wingate.deerfield.com). Un package notoirement peu sûr qui fournit la redirection telnet entre l'autre mauvaise choses... En scannant il semnble possible que le port 1080 recherche probablement un redirecteur telnet (selon wingate). Avec le package Wingate, apparaissent seulement certaines versions plus chères du package permettant l'authentification de l'utilisateur.
Il a pu également rechercher d'autres services proxies par SOCKS. Un rapport de sécurité concernait des systèmes exécutant Socks5 beta-0.17.2 de NEC. Quand socks5 fonctionnait sur le port 1080 le daemon écrit son PID dans /tmp/socks5.pid. Si ce fichier n'existe pas, un symlink pourrait être possible par exemple /etc/passwd et l'overwirter quand socks5 démarre. (trouver sur www.safenetwork.com/Linux/socks.html)
C'est tout ce que j'ai trouvées jusqu'ici. Vraisemblablement si quelqu'un avait son firewall malconfiguré permettant à tout le trafic entrant de passer à travers le port 1080, s'il y avait un wingate fonctionnant sur la machine à l'intérieur du firewall le système pourrait être employé pour réorienter des connexions telnet à l'intérieur du firewall.