Archive pour la '3-err 'catégorie

«Entrées plus anciennes

Systèmes virtualisés sont plus ou moins sûr?

18 mai 2010

J'ai eu la question ci-dessus demandé suffisamment de fois que je me sentais digne d'un blog. Alors que quelques années en arrière, la réponse peut avoir été «moins sûr», aujourd'hui, la réponse est «les deux». Je sais, ça sonne comme Chris étant non-incarcération, mais cette réponse n'a vraiment plus décrire avec précision l'état actuel de la technologie.

La virtualisation change tout

J'ai entendu une remarque quelques personnes que la virtualisation est sur le point d'impact de l'industrie de la même manière que l'Internet a fait dans le 90. Pour être honnête, je pense qu'il ya du mérite à cette opinion. Au début des années 90, la plupart des gens couraient IPX, AppleTalk, Netbui et une pléthore d'autres protocoles sur des réseaux fermés. À la fin des années 90, la plupart des gens couraient IP exclusivement avec une connectivité vers le monde entier. La façon dont nous avons fait des affaires, ainsi que la façon dont nous avons appliqué la sécurité, a complètement changé au cours de ces 10 ans. Tant l'administration du réseau et les compétences de sécurité qui étaient de pointe en 1990 ont toutes été inutiles, mais d'ici 1999.

La virtualisation est de commencer à rampe jusqu'à avoir le même impact sur l'industrie. Déploiement de la virtualisation nécessite une révision complète de la façon d'appliquer la sécurité. Retour dans les années 1990, les admins qui ont simplement branché sur l'Internet, sans égard à la façon dont ce serait l'impact de leur réseau, a été brûlée grand temps. Nous font la queue pour voir un résultat similaire à celui des gens d'adopter la virtualisation.

Ce qui fait la virtualisation Moins sécurisé

Le talon d'Achille de la virtualisation est dans le logiciel lui-même. Nous espérons que nous pouvons faire confiance aux logiciels de garder les systèmes invités éloignés les uns des autres, ainsi que l'hôte et / ou hyperviseur. Il ya deux problèmes majeurs avec cette attente:

  1. Aucun logiciel n'est exempt de bugs
  2. Le logiciel peut être mal configuré

Il ya quelques années de recherches fondamentales ont montré qu'ils pouvaient sortir d'un invité et prendre le contrôle complet de l'OS hôte . Alors qu'un hyperviseur est censé limiter ce type d'exposition, nous avons certainement vu des cas où même l'hyperviseur a été contournée . Nous avons même vu des cas ont été logiciels devient exploitable uniquement lorsqu'il est exécuté dans un environnement virtualisé . Ces liens montrent une petite section transversale de la virtualisation des problèmes qui ont été découverts au cours des dernières années. Google peut vous donner une liste plus complète si vous êtes intéressé.

Ainsi, un professionnel de la sécurité prudente va être prudent de confiance aveuglément logiciel pour être sûr. Le problème est les vendeurs ne prennent pas toujours cette même approche. Prenez VMware avec leur ESX (qui sera bientôt ESXi) produit comme un exemple. Beaucoup d'entre nous ont été sidérés quand un représentant de VMware a annoncé CanSecWest à ce qu'il était théoriquement impossible d'attaquer l'hyperviseur ESX . Lorsque nous supposons simplement quelque chose est incassable, quelqu'un de plus créative va trouver un moyen de passer à travers .

Un de mes plus grandes préoccupations avec ESX / ESXi de VMware, c'est que l'a conçu pour être modulaire (via VMsafe ). Sur le plan positif, cela signifie que les fournisseurs externes peuvent créer des produits pour aider à améliorer l'hyperviseur de fonctionnalité et de sécurité. Sur le plan négatif ce qui augmente considérablement les chances de mauvais code en cours d'introduction qui peut compromettre la sécurité.

Nous avons vu un bel exemple de cela dans le passé. Marcus Ranum a créé le pare-feu Gauntlet, qui à cette époque était l'un des appareils les plus sûrs et kick butt de sécurité disponibles. Lorsque trois agences lettre voulions la meilleure sécurité, ils se tournèrent vers Gauntlet. Marcus vendus Gauntlet à Network Associates (McAfee est devenu plus tard) qui a immédiatement commencé à ajouter des fonctionnalités. Il ne fallut pas longtemps avant qu'une chaîne de caractères constante des vulnérabilités étaient découverts, chacun introduit par ces nouvelles «fonctionnalités». De là, le produit a perdu sa sécurité CRED et glissé hors du radar.

Maintenant, il est certainement possible d'ajouter des fonctionnalités et garder les choses sécurisé. Le FreeBSD gens sont un excellent exemple de comment faire cela correctement. Pour assurer la sécurité qu'ils maintenir un processus de vérification très stricte . Est-elle parfaite? Absolument pas, mais leur processus de vérification a mis la barre de mise en œuvre de logiciels sécurisés. Avec un peu de chance de VMware fera similaires, mais je n'ai pas entendu de buzz autour de cet être le cas.

Obtenir votre tête droite

OK, donc on ne peut pas se fier aveuglément le logiciel de virtualisation pour garder les attaquants à distance. Nous pouvons cependant toujours prendre des précautions pour aider à minimiser l'impact si le pire se produit. Un des plus grands étapes que vous pouvez prendre est d'examiner attentivement ce qui se serveurs hébergés, et ce sont d'autres systèmes invités autorisés à circuler sur la même case. Le concept de zone de sécurité utilisé par les architectes du réseau est tout aussi applicable ici.

Une zone de sécurité est simplement une collection de systèmes qui partagent le même niveau de risque relatif. Par exemple les serveurs Web, le nom et SMTP sont généralement situés sur une zone démilitarisée, parce qu'ils partagent les mêmes tous les risques d'attaque directe. Sur la partie interne du réseau, les ordinateurs de bureau sont généralement placés dans une zone de sécurité différente de celle des serveurs. C'est parce que les serveurs ont peu ou pas d'accès à l'Internet tout en postes de travail sont généralement autorisés à communiquer directement. Cela place les postes de travail à risque élevé d'attaque que les serveurs.

Nous pouvons appliquer cette même logique lors de l'implémentation de la virtualisation. Un serveur de DMZ et un serveur interne ne devraient pas être invités sur le même matériel (CPU et de matrice de disques). Cela pourrait permettre à un attaquant de créer une route alternative dans notre réseau. Plutôt que d'avoir à passer par un pare-feu, NIDS, NIPS, appareils etc qui a été déployée sur le fil, un attaquant peut être capable d'accéder aux ressources internes via le logiciel de virtualisation. Est-ce une attaque facile? Non de ce que nous avons vu jusqu'ici. Exploite fonctionnels ont été découverts cependant, alors pourquoi présenter des risques inutiles si nous ne disposons pas d'.

Par ailleurs, ces mêmes règles zone de sécurité doit être appliquée à votre équipement réseau virtualisé. Par exemple, il est une mauvaise idée d'utiliser le même commutateur physique au VLAN de la DMZ et le réseau interne. J'ai vu un couple de clients à obtenir buter cette façon.

Ce qui fait de virtualisation plus sécurisée

Heureusement, dans une perspective de sécurité, la virtualisation n'est pas que des mauvaises nouvelles. En fait il ya quelques pratiques de sécurité très cool que vous pouvez appliquer dans un environnement virtualisé que vous ne pouvez pas faire sans elle. Ce fut l'une des raisons que nous avons commencé en utilisant la virtualisation au sein de l' Honeynet dès 2000.

Une des questions les plus grands de sécurité auxquels nous faisons face aujourd'hui est rootkits au niveau du noyau . Ce qui rend cette souche de malware si insidieux est-il transforme efficacement le système d'exploitation lui-même dans les logiciels malveillants. Cela rend la détection extrêmement difficile, comme tous les contrôles de sécurité doit passer par le noyau. Si le noyau lui-même est compromise, nous ne pouvons pas compter sur le noyau de déclarer avec exactitude les informations de sécurité. Nous finissons par avoir à arrêter le système, monter le disque sur un connu pour être un système propre, et l'exécution de nos contrôles médico-légale à partir de là. Bien sûr Oh le problème avec ce processus est qu'il ne s'adapte pas bien. Si nous avons des dizaines ou des centaines de serveurs, il n'ya tout simplement pas assez de temps dans une journée pour les vérifier tous correctement.

Comme mentionné précédemment, VMware permet maintenant des fournisseurs tiers l'accès à l'API VMsafe hyperviseur via. Cela permet l'accès à des informations d'état privilégié, comme la mémoire et le trafic réseau, sur chacun des OS invités. En branchant sur l'hyperviseur, certaines options de sécurité extrêmement cool deviendra possible.

Par exemple, disons un OS invité est attaqué par un rootkit au niveau noyau. En analysant la mémoire invité, le rootkit peut être détecté à l'extérieur du système d'exploitation virtuel. Lorsque vous effectuez les contrôles via l'hyperviseur, il ya beaucoup moins de chance qu'un rootkit peut furtivité de ses activités et passer inaperçus. Comme mentionné précédemment, il n'existe aucune option comparable à un système non virtualisé.

La fiche API crée également de nouvelles possibilités pour traiter le trafic crypté. Lorsque le chiffrement de bout en bout est employée (comme un VPN), des chèques de réseau basée sur la couche application sont facilement contournés. Votre seule option réelle a été d'exécuter un logiciel agent sur le point de fin, donc la sécurité pourrait être mise en œuvre après le processus de décryptage. Bien sûr, le problème ici est que si l'agent est attaqué, tous les paris sont ouverts. Encore une fois, en se branchant sur l'hyperviseur nous sommes dans une meilleure position pour examiner de façon plus sécuritaire de ces données.

Nous commençons tout juste à voir de nouvelles produits qui s'appuient sur ​​la fiche VMsafe API . Comme tous les produits sont relativement nouveaux, le jury est encore sur la façon dont ils peuvent être efficaces. Offrandes exécuter le Gambit du remplacement de pare-feu basés sur l'hôte et la protection de l'IDS à l'application de la politique complet. Il sera intéressant de voir comment ce produit de niche secoue l'année prochaine.

Résumé

Alors que je l'ai mentionné au début de ce post, la virtualisation a la capacité de rendre votre environnement plus ou moins sûr, selon la façon de le déployer. Si vous avez simplement commencer à courir tout sur une seule boîte, vous allez probablement obtenir buter. Si vous étendre les meilleures pratiques qui ont été développées au fil des ans dans le domaine de virtualisation, ainsi que le levier certaines des nouvelles fonctionnalités de sécurité qui sont libérés, vous pouvez réellement créer une meilleure posture de sécurité globale.

Pas de commentaires »

Publié dans 3-err , sécurité générale , la virtualisation

Tags:

Combinant Logwatch et OSSEC - Partie 4

18 février 2010

Dans mon dernier post, nous avons installé Logwatch ainsi que OSSEC. Il est maintenant temps de Logwatch et OSSEC jouer ensemble dans le même sandbox. Dans ce post, je vais discuter de la façon d'obtenir Logwatch pour résumer l'information générée par OSSEC.

Options de déploiement

Nous avons deux chemins que nous pouvons suivre pour le mettre en place:

  1. Avez Logwatch analyser les logs OSSEC directement.
  2. Avez OSSEC envoyer ses alertes à un serveur de type Syslog, puis exécutez Logwatch sur le serveur Syslog.

L'avantage pour l'option # 1 est que nous besoin d'un seul système. Logwatch sera exécuté sur le système hébergeant le serveur OSSEC. Le problème que nous allons courir en revanche implique le fichier OSSEC alerte. Les entrées du journal ne sont pas normalisées. Cela signifie que le format peut changer d'entrée à l'entrée, et peut même étalée sur plusieurs lignes. Il va être un véritable cauchemar pour créer un script qui va Logwatch filtre et résumer les informations d'alerte.

Si nous passons avec l'option # 2, nous aurons besoin d'une autre boîte d'agir comme notre serveur de journalisation centralisée. Afin d'avoir le serveur OSSEC accepter les entrées du journal de la non-agents, il a pour écouter sur UDP/514. C'est le même port utilisé par un serveur de journalisation centralisée, et vous ne pouvez pas avoir deux applications partagent le même port (sauf avec Windows, mais l'accès est extrêmement salissant prise). Sur le plan positif, les entrées d'alerte aura normalisés quand ils sont transmis au serveur Syslog afin de créer un script de synthèse Logwatch sera beaucoup plus facile. En outre, Logwatch sait déjà sur les fichiers Syslog standard, donc nous aurons moins de travail de personnalisation à faire.

Enfin, je l'ai mentionné dans un précédent poste que OSSEC n'est pas conçu pour être une carte SIM. C'est parce qu'il n'a pas tout enregistrer, les événements qui génèrent une alerte. Donc nous allons probablement vouloir un serveur centralisé de toute façon, et il est logique d'avoir le stocker les informations générées par OSSEC.

Donc, si ça sonne comme je vous orienter vers l'option # 2, vous avez absolument raison. Cela dit, je vais encore pour couvrir l'option # 1 car c'est une configuration beaucoup plus complexe.

Traiter avec date / heure

Jetez un oeil sur le fichier de log principal OSSEC et vous devriez voir semblable à la suivante:

[Root @ fubar logs] # tail -3 / var / ossec / logs / ossec.log

18/02/2010 12:32:05 ossec-rootcheck: INFO: fin de balayage rootcheck.

18/02/2010 14:27:06 ossec-syscheckd: INFO: Démarrage syscheck numérisation.

18/02/2010 14:39:21 ossec-syscheckd: INFO: Fin syscheck numérisation.

Notez la façon dont le timbre à date / heure actuelle est formaté. Ceci est différent de la plupart des applications, donc la première chose que nous devons faire est de dire Logwatch façon de traiter avec ce format. Nous aurons besoin de créer un script que nous pouvons appeler en cas de besoin qui comprend le format indiqué ci-dessus.

Commencez par déplacer dans le répertoire partagé des scripts:

cd / usr / share / logwatch / scripts / partagé

En utilisant votre éditeur favori, créez un fichier nommé "applylongdate":

vi applylongdate

Voici ce dont vous avez besoin à l'intérieur de ce fichier. N'hésitez pas à copier / coller à partir de cette page:

l'utilisation Logwatch ': Les dates';

my $ Debug = $ ENV {'LOGWATCH_DEBUG'} | | 0;

$ SearchDate = TimeFilter ('% Y /% m /% d% H:% M:% S');

if ($ Debug> 5) {

print STDERR "DEBUG: ApplyLongDate intérieur ... \ n";

print STDERR "DEBUG: Looking for:". $ SearchDate. "\ N";

}

while (defined ($ thisline = <STDIN>)) {

if ($ thisline = ~ m / ^ $ SearchDate / o) {

Imprimer thisline $ = ~ s / ^ .... \ / .. \ / .. ..:..:.. / /;

print $ thisline;

}

}

# Vi: shiftwidth = 3 = la syntaxe perl tabstop = 3 et

Une fois que vous enregistrez le fichier, il nous faut maintenant définir les autorisations appropriées:

chmod 755 applylongdate

Configurer les fichiers Log

Ensuite, nous devons dire à Logwatch où les fichiers journaux sont situés OSSEC. Chaque fois que vous ajoutez de nouveaux fichiers journaux ou de créer de nouveaux services à surveiller dans Logwatch, vous devez placer vos modifications sous le répertoire / etc / logwatch. Nous allons créer deux fichiers de configuration. La première sera de gérer les messages OSSEC, et le second traitera des alertes et des changements OSSEC réponse active.

Commençons par créer le fichier de configuration pour le fichier journal principal OSSEC:

cd / etc / logwatch / conf / logfiles

ossec.conf vi

Le contenu du fichier doit être aussi suivies:

LogFile = / var / ossec / logs / ossec.log

* = ApplyLongDate

Vous pouvez maintenant sauvegarder et quitter le fichier. Ensuite, nous allons créer le fichier de configuration pour les fichiers journaux restants:

vi ossec-alert.conf

Le contenu de ce fichier doit être aussi suivies:

LogFile = / var / ossec / logs / active-responses.log

LogFile = / var / ossec / logs / alertes / alerts.log

LogFile = / var / ossec / logs / firewall / firewall.log

Une fois terminé, sauvegarder et quitter. Les autorisations par défaut devrait être acceptable pour notre configuration.

Configuration des services OSSEC

Ensuite, nous avons besoin de définir les services OSSEC et d'identifier ce que nous voulons utiliser comme un titre lorsque les rapports sont générés. Voici comment faire pour créer le premier fichier:

cd / etc / logwatch / conf / services

ossec.conf vi

Le contenu de ce fichier est assez simple:

Titre = "OSSEC Messages"

LogFile = ossec

Une fois terminée, vous pouvez sauvegarder et quitter. Nous avons besoin de créer un autre fichier dans ce répertoire:

vi ossec-alert.conf

Le contenu de ce fichier doit être:

Titre = "Alertes OSSEC"

LogFile = ossec alerte

Une fois terminé, enregistrer et quitter comme d'habitude.

Parsing Les Entrées

Ensuite, nous devons dire à Logwatch comment formater les entrées du journal dans le rapport. Nous aurons besoin de créer un script de personnalisation pour chaque ensemble de services. Nous allons commencer par utiliser un script de test Logwatch fourni; juste pour que tout fonctionne bien sûr.

Commencez par déplacer dans le répertoire approprié:

cd / etc / logwatch / scripts / services

Utilisez votre éditeur favori pour créer votre premier script:

vi ossec

Le contenu du script doit être aussi suivies:

#! / Bin / bash

# Ceci est un script aussi beau que vous montrera les lignes que vous allez

# Être le traitement et les rapports sur. Il va d'abord afficher les

# Variables d'environnement standard et ensuite il prend STDIN et

# Dump it de retour vers STDOUT.

# Ce sont les variables d'environnement standard. Vous pouvez définir

# Plus dans votre fichier de configuration du service (voir ci-dessus).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Niveau de détail: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp dir: $ LOGWATCH_TEMP_DIR"

echo "Niveau de débogage: $ LOGWATCH_DEBUG"

# Maintenant, prenez STDIN et STDOUT c'est de vidage

cat

Maintenant créez votre second script:

vi ossec alerte

et comprennent le contenu exact même:

#! / Bin / bash

# Ceci est un script aussi beau que vous montrera les lignes que vous allez

# Être le traitement et les rapports sur. Il va d'abord afficher les

# Variables d'environnement standard et ensuite il prend STDIN et

# Dump it de retour vers STDOUT.

# Ce sont les variables d'environnement standard. Vous pouvez définir

# Plus dans votre fichier de configuration du service (voir ci-dessus).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Niveau de détail: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp dir: $ LOGWATCH_TEMP_DIR"

echo "Niveau de débogage: $ LOGWATCH_DEBUG"

# Maintenant, prenez STDIN et STDOUT c'est de vidage

cat

Enfin, nous avons besoin de définir les autorisations appropriées:

chmod 755 ossec *

Test de la configuration

La meilleure façon de tester notre nouvelle configuration est d'exécuter la commande suivante:

logwatch | less

Si vous voulez seulement voir vos modifications, vous pouvez exécuter un rapport sur chaque service, un à la fois:

logwatch service ossec | less

logwatch service d'alerte ossec | less

Une personnalisation plus poussée

Une fois que vous obtenez tous les travailler au-dessus, vous pouvez vous concentrer sur l'obtention Logwatch de filtrer et de résumer les entrées du journal. Logwatch est assez flexible, et vous pouvez personnaliser la sortie comme vous le souhaitez. Une des choses gentilles sur le script de test ci-dessus est supérieure à celle qu'il vous montre exactement ce que vous avez à travailler avec. Donc, avec une magie expression régulière peu, vous pouvez résumer les entrées que vous jugez appropriée. Pour quelques idées, consultez les fichiers situés sous:

/ Usr / share / logwatch / scripts / services

Ce sont les scripts de synthèse par défaut inclus avec Logwatch. Plus précisément, ont un regard sur les fichiers "pam" et "sshd". Ils sont d'excellents exemples de la fois simple et un ensemble complexe de filtres de synthèse.

Comme vous développer vos scripts, une attention particulière à l'$ LOGWATCH_DETAIL_LEVEL «variable. Cela vous permettra de personnaliser le niveau de sortie du rapport en fonction de combien de verbosité l'utilisateur est à la recherche d'. Par exemple, lorsque vous êtes encore dans le répertoire ci-dessus les services, exécutez la commande suivante:

moins sshd

Lorsque la première page du contenu du fichier est affiché, tapez:

/ Détail <Enter key>

La barre oblique inverse nous permet de rechercher dans le fichier pour une chaîne de texte particulier. Dans ce cas, nous sommes à la recherche pour le mot "détail". Une fois que vous appuyez sur Entrée à la recherche va sauter dans le fichier jusqu'à ce qu'il trouve la première occurrence de la chaîne de texte. Il mettra également en lumière la chaîne de recherche. Dans le premier match, vous remarquerez que l'auteur assigné la variable "$ Détail" pour être la même que la variable $ LOGWATCH_DETAIL_LEVEL ". C'est pour leur faire économiser quelques frappes.

Maintenant, appuyez sur la touche antislash nouveau suivi par la touche Entrée. Ce sera un saut dans le dossier à la prochaine occurrence de "Détail". Vous devriez voir:

if ($ Détail> = 20) {

Utilisateurs $ {$ utilisateur} {$ host} {$ Méthode} + +;

} Else {

if ($ Host! ~ / $ IgnoreHost /) {

Utilisateurs $ {$ utilisateur} {} {$ Host "(tous )"}++;

Remarque de l'auteur fournit de plus amples informations, si le niveau de détail est fixé à 20 (mi-chemin entre basse et moyenne) ou supérieure. Gardez sauter à travers le fichier et vous verrez d'autres exemples où l'auteur de cette technique à effet de levier.

Maintenant la page jusqu'à la fin du fichier et vous devriez voir cette déclaration:

if (keys% autreliste) {

print "\ n ** Entrées ** inégalée \ n";

print "$ _: $ autreliste {$ _} heure (s) \ n" foreach autreliste keys%;

}

Cette section est extrêmement important, car il est un fourre-finale. Pensez à une politique de pare-feu pour un moment. La plupart d'entre nous de créer une règle définitive qui dit: «Si je n'avais pas spécifiquement permettre à un modèle de trafic à travers, le nier". En d'autres termes, si quelque chose d'inattendu arrive, voilà comment je veux que vous pour y faire face.

La déclaration ci-dessus a le même objectif lors de l'analyse du fichier journal. Toutes les précédentes instructions "if" tenter de faire correspondre une chaîne de texte spécifique dans l'entrée du journal, afin de le formater correctement. Cette entrée indique «Si vous n'avez pas adapté et imprimé une entrée de journal spécifique encore, l'imprimer dans une section intitulée« Entrées ** ** incomparable ". Cette étape est extrêmement importante parce que sans elle nous ne verrons jamais les entrées inattendues. Il est des entrées inattendues qui sont probablement les plus importantes et plus intéressantes.

Résumé Exec

Les deux OSSEC et Logwatch sont d'excellents outils gratuits. OSSEC excelle à vous avertir quand un modèle d'attaque connus a lieu. Logwatch est un outil formidable pour résumer un morceau de temps de grumes afin humains peuvent réellement donner un sens à ce qui se passe. En combinant les deux outils, vous pouvez créer une défense beaucoup plus robustes en profondeur la posture. L'ensemble devient supérieure à la somme des parties.

3 commentaires »

Publié dans 3-err , journalisation

Combinant Logwatch et OSSEC - Partie 3

17 février 2010

Dans mes deux derniers messages j'ai discuté Logwatch et OSSEC, ainsi que la façon dont ils peuvent être un levier pour augmenter votre posture de sécurité. Dans cet épisode, je vais discuter comment installer ces deux outils.

Installation Logwatch

Logwatch est assez facile à installer. En fait, il est installé par défaut sur de nombreuses distributions Linux que vous pouvez déjà en avoir une copie sur votre système. Pour vérifier, ouvrez une session en tant que root et essayez d'exécuter Logwatch avec le "-v". Si vous voyez:

[Root @ fubar logwatch] # logwatch-v

Logwatch 7.3.6 (publié 19.05.07)

Logwatch est installé et vous avez une copie de la dernière version. Si vous ne possédez pas la dernière version, vous pouvez le saisir de la page de téléchargement Logwatch .

Il ya trois saveurs de Logwatch qui peuvent être téléchargés; Binaires au format RPM, la source au format RPM, ou de la source dans une boule de goudron. Si votre système supporte la gestion de paquets RPM, le RPM binaire est votre meilleur choix. Il est simple à installer et RPM mettra à jour automatiquement le logiciel lorsque de nouvelles versions sont disponibles.

Installation Logwatch De RPM

Pour installer la version binaire du RPM, il suffit de connecter en tant que root et naviguez vers le répertoire où vous avez téléchargé le fichier RPM. Maintenant exécutez la commande:

rpm-U-7.3.6-logwatch 1.noarch.rpm

N'oubliez pas que vous pouvez utiliser la touche de tabulation pour compléter automatiquement le nom du fichier plutôt que d'avoir à taper dans l'ensemble.

Installation Logwatch De la source

Installation à partir de la source est un peu plus considérable. Rappelez-vous que pour pouvoir installer le code source, vous devez déjà disposer d'un compilateur (comme gcc) installé sur votre système. Connexion en tant que root et naviguez vers le répertoire où vous avez téléchargé l'archive tar. Pour extraire l'archive, exécutez la commande suivante:

tar xvzf logwatch-7.3.6.tar.gz

Vous verrez une structure de répertoire en dessous de votre emplacement actuel sont créées et beaucoup de fichiers copiés en jeu. Nous devons maintenant passer à l'annuaire le plus haut qui a été créé:

cd logwatch-7.3.6

Pour Logwatch de courir, il ya un tas de répertoires qui doivent être créés sur votre système. Ces fonctions sont documentées dans le fichier README dans le répertoire courant. Heureusement, Logwatch inclut un script d'installation qui peut faire tout le travail pour vous. Malheureusement, le script a les autorisations mauvais jeu de sorte qu'il ne sera pas lancé par défaut. C'est assez facile à corriger mais avec la commande chmod:

chmod 500 install_logwatch.sh

Maintenant, nous pouvons exécuter le script pour l'installation de notre système:

. / Install_logwatch.sh

Ne pas oublier la période au début de la ligne.

Test Logwatch

Pour tester votre configuration Logwatch, exécutez la commande suivante:

logwatch | less

Vous verrez l'écran de votre terminal de se vide, mais c'est normal. Vous allez finir par voir un rapport Logwatch obtenir imprimée à l'écran que vous pouvez naviguer à travers l'aide la «Page Up» et «Page Down» clés. Comment connecter qu'il faut pour que le rapport d'apparaître sur l'écran dépendra de combien d'informations du journal a besoin d'obtenir analysée. Elle pourrait prendre quelques secondes ou quelques minutes. De toute façon, il vous donnera une chance de vous familiariser avec le format du rapport.

Installation OSSEC

Comme je le mentionnais dans mon dernier post, vous avez deux options d'installation avec OSSEC, local ou client / serveur. Dans ce post, je vais me concentrer sur la configuration client / serveur, car il est un peu plus complexe. Si vous effectuez une installation locale, il suffit de sélectionner l'option "local" au cours du processus d'installation et de sauter la section sur la mise en place d'un canal sécurisé entre l'agent et le serveur.

Commencez avec le serveur

OSSEC utilise le cryptage Blowfish pour sécuriser la communication entre le client et le serveur. Blowfish est basée clé symétrique, donc les deux côtés doivent savoir quelle est la valeur clé à utiliser pour communiquer. Le serveur est chargé de générer la clé symétrique, nous devons donc installer le logiciel serveur en premier. Au cours de l'installation du client, nous serons amené pour une valeur de clé de toute évidence, nous devons avoir cette pratique à l'avance.

Voici une astuce gain de temps. La valeur de la clé est longue et presque impossible à retenir. La meilleure façon de déplacer la valeur de la clé du système de serveur pour le système d'agent est d'utiliser SSH. Créer une connexion sécurisée avec le serveur OSSEC, et extraire la clé appropriée (instructions fournies ci-dessous). Dans une seconde fenêtre de terminal, de créer une session SSH sur le système où vous allez installer l'agent. Lorsque l'installation du client vous demande la valeur de clé, vous pouvez simplement copier / coller entre les deux terminaux.

Installation du serveur OSSEC

Le logiciel serveur est disponible comme une boule de goudron, de sorte que vous pouvez récupérer une copie de la dernière version de la page de téléchargement OSSEC . Vous aurez alors besoin d'extraire le contenu de la boule de goudron:

tar xvzf OSSEC-HIDS-2.3.tar.gz

Ensuite, déplacez dans la structure de répertoire que vous venez de créer:

cd-OSSEC HIDS-2.3

OSSEC fournit un script d'installation qui vous guidera dans le processus d'installation du serveur. Pour lancer le script, tapez:

. / Install.sh

Ne pas oublier la période au début de la commande. Vous allez maintenant être invité par un certain nombre d'options d'installation:

  • Langue - La valeur par défaut est l'anglais. Changer si nécessaire.
  • Confirmation de l'installation - Appuyez sur Entrée une fois que vous avez lu l'écran.
  • Installez le type - Tapez "serveur" sans les guillemets et appuyez sur Entrée.
  • Emplacement d'installation - Acceptez la valeur par défaut.
  • E-mail de notification - par défaut est oui, choisissez si vous voulez des alertes e-mail. Si vous sélectionnez oui, vous serez invité à entrer une adresse e-mail et votre serveur de messagerie.
  • Contrôle d'intégrité - par défaut est oui. Sélectionnez si vous voulez que le système local vérifiés périodiquement pour les intrusions.
  • Détection de root kit - par défaut est oui. Bonne option puisque nous devons maintenir un haut niveau d'intégrité de ce système.
  • Réponse active - par défaut est oui. Sélectionnez cette option si vous souhaitez être en mesure de réagir aux événements.
  • Baisse de pare-feu - permet au serveur OSSEC pour défendre l'auto, si une attaque directe est détecté.
  • Liste blanche - Cela vous permettra d'ajouter des adresses IP à partir desquelles d'éventuelles attaques seront ignorés. Soyez prudent avec cette option. Si vous n'avez pas accès à la console sur le serveur OSSEC, il pourrait être sage d'identifier une adresse IP qui peut toujours y entrer simplement veiller à l'adresse IP source est un système fiable.
  • Activer Syslog - par défaut est oui. Sélectionnez cette option si vous voulez collecter des journaux à partir du système qui ne peut pas exécuter un agent OSSEC (comme les pare-feu, commutateurs, routeurs, points d'accès, etc.)
  • Les fichiers journaux à surveiller - Cet écran identifie l'ensemble des fichiers journaux OSSEC locale suivra. Il est purement d'informations, tout ce que vous pouvez faire est appuyez sur Entrée pour passer devant elle. Si vous remarquez un ou plusieurs fichiers journaux manquants de la liste, vous pouvez les ajouter plus tard pour le fichier ossec.conf.

À ce point d'accès sera OSSEC le compilateur locales et d'installer tous les fichiers nécessaires sur le système. Une fois terminée, vous pouvez démarrer le serveur OSSEC en exécutant la commande:

/ Var / ossec / bin / ossec-commande de démarrage

Définir les agents OSSEC

Nous ne sommes pas fait avec le serveur OSSEC juste encore. Ensuite, nous avons besoin de pré-définir tous les systèmes qui seront exécute l'agent OSSEC (client) de logiciels. Ceci est réalisé en utilisant la commande manage_agents. D'abord cependant, nous devons faire un peu de devoirs. Faites une liste de tous les systèmes qui seront exécutant le logiciel de l'agent OSSEC. Pour chaque système, vous aurez besoin d'un nom descriptif ainsi que l'adresse IP de ce système.

Maintenant, exécutez la commande suivante depuis la ligne de commande:

/ Var / ossec / bin / manage_agents

Ceci va produire le menu Gestionnaire principal agent. Appuyez sur "A" suivie de la touche Entrée pour définir votre premier système. Entrez un nom descriptif pour le premier système, suivie par l'adresse IP du système. Ne vous inquiétez pas pour le numéro d'agent. Il suffit d'accepter la valeur par défaut et OSSEC sera automatiquement attribuer le numéro d'identification suivant disponible. Une fois que vous confirmez les informations que vous avez entré, vous serez renvoyé au menu principal du gestionnaire d'agents. Répétez le processus ci-dessus pour chaque système qui sera exécutant un agent OSSEC.

Génération de clés

Une fois que vous avez ajoutés dans tous vos systèmes, il est temps de générer des clés de chiffrement. Cette étape est aussi réalisée avec l'utilitaire manage_agents. Si vous avez fermé l'outil après la dernière étape, il relance aujourd'hui.

Appuyez sur la touche "E" suivi par Enter pour sélectionner la «clé Extrait d'un agent" dans le menu. Vous serez alors invité à entrer le numéro d'identification de la clé que vous souhaitez extraire. Les noms descriptifs et les adresses IP sont répertoriés avec chaque numéro, donc il doit être trivial d'identifier celui que vous voulez. Commencez avec le système que vous envisagez d'installer le logiciel agent sur la première.

OSSEC agent installer sous Linux

Lorsque vous installez le logiciel agent sur un client Linux ou UNIX, vous utilisez la boule de goudron exactement la même, nous avons utilisé pour installer le logiciel serveur. Exécuter le script d'installation même, mais cette fois-ci lorsque vous êtes invité pour le type d'installation que vous souhaitez effectuer, le type de «mandataire» suivi par la touche Entrée.

L'installation du client a plusieurs des mêmes invites comme l'installation du serveur. Utilisez les informations ci-dessus pour vous guider dans le processus. L'invite de commande qui varie cependant, c'est que vous serez invité à fournir l'adresse IP du serveur OSSEC. Une fois terminé, aura accès à OSSEC le compilateur locales et d'installer tous les fichiers requis sur le système.

Ensuite, nous devons importer la clé Blowfish à partir du serveur OSSEC. Alors qu'il était encore sur le système d'agent, exécutez la commande:

/ Var / ossec / bin / manage_agents

Lorsque le menu d'Agent Manager apparaît, sélectionnez «I» pour importer la clé Blowfish.

Lorsque l'invite suivante s'affiche, vous devez entrer manuellement la clé appropriée Blowfish. Encore une fois, si vous utilisez SSH pour les deux systèmes en même temps, vous pouvez simplement copier / coller entre les deux terminaux. Assurez-vous que la clé semble correct, appuyez sur la touche Entrée, puis sélectionnez "Y" pour confirmer que la clé semble correct. Vous serez renvoyé au menu du gestionnaire de l'agent. Sélectionnez "q" pour revenir à la ligne de commande.

Maintenant nous avons simplement besoin de démarrer l'agent OSSEC. Vous pouvez le faire en exécutant la commande suivante:

/ Var / ossec / bin / ossec-commande de démarrage

Vous devriez voir l'ensemble des composants de l'agent OSSEC démarrage, suivi par un message «Terminé».

OSSEC agent installé sur Windows

OSSEC a un exécutable auto-extractible qui vous permettra d'installer le logiciel agent sur un système Windows. Il suffit de double cliquer sur l'exécutable pour démarrer le processus d'installation. Vous serez invité à accepter la licence ainsi que les composants que vous souhaitez installer. Il suffit de suivre les instructions jusqu'à la fenêtre du gestionnaire d'agents OSSEC apparaît.

La fenêtre Gestionnaire d'agents OSSEC vous invite à l'adresse IP du serveur OSSEC. Il sera également vous invite à la valeur de clé Blowfish à utiliser, afin d'extraire les clés appropriées sur le serveur et entrez la valeur dans ce domaine. Assurez-vous supprimer l'invite dans ce domaine avant que vous collez dans la clé Blowfish. Sinon la communication avec le serveur peut échouer.

Ensuite, sélectionnez "Gérer" dans le menu du gestionnaire d'agents OSSEC, suivi par "Démarrer OSSEC". Vous devriez maintenant voir le "Status:" Le changement indicateur pour "Running ...".

Test OSSEC

Une fois que vous avez le serveur et le logiciel de l'agent installé, lancé et configuré les touches appropriées, il est maintenant temps de vérifier notre configuration. Exécutez la commande suivante sur le serveur OSSEC:

cd / var / ossec / logs

Et extraire le fichier ossec.log:

moins ossec.log

Vérifiez le fichier journal de toute erreur. Une erreur courante est que les rapports OSSEC il ne peut pas envoyer un courrier électronique. Assurez-vous que le serveur de messagerie est en marche et qu'il accepte les connexions. Une fois que vous êtes satisfait de la configuration du serveur, il est maintenant temps de vérifier les agents. Descendre à la "alertes" répertoire:

alertes cd

Et extraire le fichier alerts.log:

moins alerts.log

Plus précisément, vous êtes à la recherche d'entrées semblables aux suivantes:

17 février 2010 16:09:16 (bureau) 192.168.1.10-> ossec

Règle: 501 (niveau 3) -> 'Nouveau ossec agents connectés.

IP Src: (aucun)

Utilisateur: (aucun)

OSSEC: Agent commencé: «test_system-> 192.168.1.10.

Vous devriez voir une entrée pour chaque système sur lequel vous avez installé le logiciel de l'agent.

Plus à venir

Ouf! C'est plus que suffisant pour un poste! Dans mon prochain post je vais entrer s'appuyant Logwatch pour analyser toutes les informations d'alerte générés par OSSEC.

Pas de commentaires »

Publié dans 3-err , journalisation

Combinant Logwatch et OSSEC - Partie 2

16 février 2010

Dans mon dernier message j'ai décrit comment Logwatch pourrait être utilisé pour simplifier le processus d'examen du journal. Dans ce post nous allons voir OSSEC et ce qu'elle apporte à la table.

Qu'est-ce que OSSEC?

OSSEC , abréviation de «sécurité Open Source", est un hôte système basé détection d'intrusion (HIDS). En d'autres termes, il est conçu pour détecter des attaques ou des violations de politique, si et quand ils se produisent. Bien qu'il ne possède pas la capacité de protéger contre les attaques inconnues ou 0-Day (ce qui serait la prévention d'intrusion basée sur l'hôte), il inclut un large éventail d'outils qui peuvent vous aider à identifier une intrusion quand elle survient, ainsi que dans la mesure des dommages qui ont été causés.

Plates-formes supportées

Pour profiter de toutes les fonctionnalités de OSSEC a à offrir, vous devez exécuter un agent sur le système à protéger. Agents OSSEC peut fonctionner sur Windows, Mac OS X, Linux, et un large éventail de systèmes UNIX. Si vous êtes simplement intéressé à la partie analyse des journaux cependant, une gamme encore plus large de systèmes peuvent être pris en charge. Cela comprend le matériel à la fois de Cisco et Juniper. Un certain nombre de produits spécifiques sont également pris en charge comme les firewalls Checkpoint, Symantec Anti-Virus, Snort, Squid, et Arpwatch, pour n'en nommer que quelques-uns.

Lorsque vous installez OSSEC vous avez deux options de configuration, local ou client / serveur. Une installation locale est utilisée lorsque vous devez tout faire sur un seul système. L'installation du client / serveur vous permet d'exécuter un environnement distribué protection des systèmes multiples dans le même temps. Alors que la plupart des déploiements sont client / serveur basée, si vous voulez donner un tour OSSEC vous pouvez facilement lancer le tout sur un système de test unique en utilisant une installation locale.

Connexion Analyse

OSSEC comprend un système basé sur le journal de détection d'intrusion (couvercles). Cela a la possibilité de consulter les fichiers journaux en quasi temps réel, tout en les scrutant des schémas d'attaque connus. Quand un journal est généré sur un système protégé, l'agent prend soin de transmettre en toute sécurité le journal (Cryptage Blowfish avec un secret pré-partagé) vers le serveur. Le serveur se charge ensuite d'effectuer l'analyse.

La plupart des outils d'analyse de journaux traitent leurs règles dans un format linéaire. J'entends par là que si nous avons 500 règles, seule règle est vérifiée, alors la règle des deux, alors la règle de trois et ainsi de suite jusqu'à une correspondance est trouvée, ou nous rejoindre à la fin du jeu de règles. OSSEC fonctionne un peu différemment car il met en œuvre une structure hiératique aux règles. Les entrées du journal sont d'abord classés et ensuite vérifié que contre celui règles sont appropriées. Le résultat est que plutôt que de devoir traiter tous les 500 règles, la plupart des événements auront vérifié contre 10 règles ou moins. Cela réduit considérablement le montant des frais généraux nécessaires au traitement de l'ensemble de règles.

Vérification de l'intégrité

OSSEC inclut un outil appelé syscheck pour effectuer la vérification d'intégrité de fichier et de répertoire. Si vous utilisez un agent de Windows, vous pouvez également inclure des touches spécifiques dans le registre de Windows pour être surveillés aussi bien. Modifications de fichiers peuvent être détectés en utilisant les deux MD-5 et SHA-1 algorithmes de hachage. Le système est extrêmement personnalisable. Vous pouvez inclure ou exclure des fichiers uniques, ou des structures de répertoires entières. Vous pouvez même définir un indicateur pour détecter la création du nouveau fichier.

Le logiciel agent est conçu pour utiliser une quantité minimale de CPU lors de la vérification d'intégrité. Tout cela signifie que le chèque sera plus long, il contribue également à minimiser la perte de performance du système. Hash informations sont transmises au serveur. Le serveur se charge ensuite d'effectuer la comparaison de hachage pour voir si l'un des fichiers critiques du système ont été modifiés. Le serveur stocke également une copie de la politique de contrôle d'intégrité, de sorte que si des changements de politiques sont faites sur l'agent, ils peuvent être détectés et signalés ainsi.

Détection des anomalies

OSSEC va beaucoup plus loin log vérifiant pour vérifier l'intégrité du système. Politiques d'utilisation peuvent être gérés de manière centralisée depuis le serveur, puis poussé vers les agents appropriés. Par exemple vous pouvez définir une politique concernant les applications Windows qui sont acceptables (Office, Firefox, etc) et celles qui ne sont pas (client de messagerie instantanée, Skype, etc.) Vous pouvez même définir des options de configuration acceptable, comme vérifier que les hachages NT sont utilisés pour mot de passe stocké mais pas hachages LanMan.

OSSEC comprend un certain nombre d'autres goodies afin d'aider à vérifier l'intégrité d'un système. Par exemple OSSEC a la capacité d'exécuter des commandes de l'agent et de surveiller la sortie qui est généré. Par exemple vous pourriez avoir l'agent Linux d'exécuter le "df" commande à intervalles réguliers et générer une alerte si l'utilisation du disque dépasse 90%. Un exemple de Windows peut être d'avoir OSSEC générer une alerte à chaque fichier d'informations sont écrites dans le flux de données alternatif domaine de NTFS.

Active Response

Enfin, OSSEC inclut la capacité à réagir lorsqu'une activité suspecte est détectée. Les réponses peuvent être générés à partir du serveur ou de l'agent, qui jamais vous spécifiez. Les réponses peuvent être aussi bénin que générer une alerte e-mail, d'être aussi proactif que le blocage d'une adresse IP distante d'une quantité limitée de temps. Il ya un certain nombre de scripts inclus réponse active vous pouvez dessiner sur, ou vous pouvez facilement écrire le vôtre.

Une architecture sécurisée

Les auteurs ont OSSEC fait de grands efforts pour sécuriser l'ensemble des composants dans le produit. Les tâches telles que la vérification de l'intégrité sont effectués sur le serveur, plutôt que de l'agent, donc la fiabilité du hash ne peuvent pas être compromises lors d'une attaque. Les processus sont exécutés avec le plus bas niveau d'autorisations possibles, et les différents comptes sont utilisés pour faire fonctionner chaque composant OSSEC. Cela signifie qu'un compromis d'une demande unique au OSSEC ne sera pas immédiatement conduire à un compromis sur le paquet complet. En outre, la plupart des composants sont gérés au sein d'une prison chrooté afin de leur accès au système est encore plus restreint.

Final Words

Bien OSSEC est un outil puissant, il est important de se rappeler que c'est un HIDS et non une solution de gestion des logs. OSSEC pouvez consulter les entrées de journal à la recherche d'habitudes suspectes, mais il ne fera que sauvegarder des informations d'alerte. Ainsi, alors que OSSEC ne remplacera pas votre Security Information Management (SIM) en solution, il peut très certainement l'augmenter. Vous pouvez facilement configurer OSSEC à l'avant toutes les alertes qu'il génère à un serveur de journalisation central .

Bien OSSEC est un logiciel open source, Trend Micro est principalement son développement. Si vous avez besoin de support commercial, vous pouvez acheter un contrat de support à travers eux à un prix raisonnable.

Plus à venir

Dans mon prochain épisode, nous allons voir l'installation de OSSEC et Logwatch. Après cela, nous allons passer en intégrant les deux ensemble.

Pas de commentaires »

Publié dans 3-err , journalisation

Combinant Logwatch et OSSEC

15 février 2010

J'ai récemment eu un étudiant me poser une question concernant l'intégration des Logwatch avec OSSEC. Je me sentais comme cela a été une idée complexe et pourtant assez cool qu'il justifie d'une série de messages pour le couvrir en entier. Donc, au cours des prochains jours je vais vous parler de chacun de ces outils, comment les intégrer ensemble, ainsi que ce que la visibilité de sécurité supplémentaires peuvent être acquises une fois le processus terminé.

Qu'est-ce que Logwatch?

Logwatch est un outil open source excellente pour générer des rapports humains quotidiens log lisible. Les entrées du journal ont tendance à tomber dans l'une des trois catégories suivantes:

  • Stuff vous savez qui est mal
  • Stuff vous savez qui est normal et peut être ignoré
  • Tout le reste

C'est que «tout autre» catégorie où Logwatch brille vraiment. Pour les choses que nous savons, c'est le mal, nous mettrons en place une certaine forme de système d'alerte. Par exemple, nous pouvons écrire une signature d'alerte qui prévient l'analyste en sécurité quand un compte est brutale forcé. Mais quid des attaques, nous ne savons pas au sujet ou vous ne savez à quoi ils ressemblent? Ce serait un exemple clair de ce «tout autre» catégorie. Le trafic n'est pas normal, mais nous n'avons pas vu avant d'avoir une signature d'attente pour générer une alerte. Depuis, nous serons incapables d'attraper l'attaque en temps réel, nous aurons besoin de l'attraper lors d'un examen journal quotidien.

Bien sûr, le problème avec les critiques faites journal quotidien, c'est qu'il est longue et fastidieuse. Je veux dire, soyons honnêtes, qui veut vraiment passer leur journée en revue un millions d'euros plus les entrées de journal? Même si vous n'avez, vous êtes sûr que vous fait prendre le hors de la circulation ordinaire?

Comment ça marche?

Que ne Logwatch très bien, c'est vous permettre de réorganiser vos données dans un format qui est facile pour les humains à suivre. Sa vraie force, c'est qu'il vous permet de déplacer les trucs que vous comprenez de la route (normal ou mal), de sorte que les entrées du journal inattendu se démarquer comme un pouce endolori. En d'autres termes, Logwatch vous permet de résumer vos entrées de journaux de sorte que le truc inhabituel est plus facile à repérer.

Qu'est-ce que j'aime vraiment à propos Logwatch est que vous ne perdez rien. Beaucoup d'outils de révision log ne vous montrera que les trucs qui a été pré-défini comme étant le mal. Le problème qu'ils partagent tous, c'est que quand quelque chose se passe mal, mais inattendus, il vole à droite sous le fil. Parce Logwatch vous permet de tout voir, vous n'avez plus manquer à l'inattendu.

Logwatch En action

Permet de discuter de la façon Logwatch fonctionne en utilisant le SSH service de serveur comme un exemple. Les scripts pour faire face à SSH ont déjà été définies dans Logwatch, vous n'avez donc pas besoin de faire aucune modification de recevoir les caractéristiques que nous allons discuter.

Lors de l'examen d'un fichier journal, la première chose que Logwatch ne se réorganisent les entrées du journal en fonction de leurs types de messages. Par exemple toutes les connexions SSH réussies sont regroupés, ainsi que les échecs de connexion trop nombreux, ont refusé les connexions, les comptes verrouillés, des comptes sans une coquille adéquate, le protocole mis-allumettes, etc etc etc Une fois que tous les messages de SSH sont regroupés par leur type, les données sont ensuite résumées afin de réduire la quantité d'information ont été signalés.

Par exemple, la valeur par défaut est de résumer les tentatives de connexion a échoué par compte et par adresse IP source. Ainsi, une section typique échoué rapport d'ouverture pourrait ressembler à ceci:

Echecs d'authentification à partir de ces:

bsmith / mot de passe de 1.2.3.4: 637 fois (s)

jsmith / mot de passe de 1.2.3.5: 2 heure (s)

Ainsi, plutôt que d'avoir à examiner les entrées de journal 639 rapports une mauvaise tentative de connexion, nous avons toutes les informations pertinentes résumées en trois lignes (si vous incluez le titre). Continuez ce processus pour tous les messages SSH autres, et nous avons considérablement réduit la quantité de temps nécessaire pour revoir nos journaux.

Mais que faire si quelque chose arrive qui Logwatch n'est pas pré-programmé pour reconnaître? Quand une entrée du journal inattendu est trouvé, Logwatch ajoute une section à la fin du rapport de service appelé «Entrées inégalée". Donc, si nous voyons ce titre dans la section serveur SSH, nous savons qu'un événement s'est produit qui est soit anormal ou inattendu pour le service SSH. Cela pourrait très bien être une forme d'attaque qui nous ne sommes pas conscients fait le tour.

En se concentrant sur la section inégalée entrées, nous pouvons identifier rapidement l'activité inattendue. Comme je l'ai indiqué précédemment, ceci est vraiment l'objectif principal de faire des critiques journal quotidien. Pour trouver les choses que nous ne prévoyons pas ce qui va se faufiler à notre système d'alerte. Logwatch rend ce processus soit aussi rapide et indolore que possible.

Résumé des fonctionnalités

Dans l'exemple ci-dessus, je parlé de faire des critiques journal quotidien, mais pour être honnête, Logwatch est hautement personnalisable. Vous pouvez spécifier n'importe quelle plage que vous souhaitez utiliser jusqu'à un intervalle d'une seconde. Par exemple, disons que je suis une enquête sur une intrusion plutôt que d'effectuer un examen journal quotidien. Je ne pouvais spécifier une plage comme "14/02/2010 17:05:00 pour cette heure" à se concentrer juste sur les informations qui m'intéressent. Je peux aussi se concentrer sur un seul fichier journal ou un service spécifique.

Le niveau de détail du rapport est également personnalisable. En général, lorsque vous traitez avec la sécurité que vous prenez l'habitude de toujours vouloir plus haut niveau en détail des rapports. Pour être honnête, avec Logwatch un haut niveau de détail est probablement plus que vous aurez jamais besoin. Personnellement, je généralement s'en tenir à "med" pour les moyennes et qui fonctionne à bien. Vous pouvez également spécifier le niveau de rapport comme «faible» ou «élevé» ou utiliser une plage numérique de 0-10 pour un niveau supérieur de granularité (faible = 0, med = 5, haute = 10).

Logwatch peut être exécuté automatiquement ou comme un processus manuel. Typiquement, vous voudrez le configurer pour qu'il s'exécute automatiquement chaque jour et de résumer pour une journée d'entrées de journal. Si jamais vous avez besoin de développer ou de se concentrer le rapport, vous pouvez toujours courir Logwatch partir de la ligne de commande tout en précisant exactement ce que vous voulez voir. Vous pouvez ensuite utiliser l'option "-sauver" option pour spécifier un nom de rapport et de l'emplacement du répertoire de stockage.

Plus à venir

Le ci-dessus devrait vous donner une bonne idée quant aux caractéristiques Logwatch peut apporter à la table. Dans le prochain post je vais discuter OSSEC dans le même niveau de détail. Après cela, je vais entrer dans l'installation de chaque outil ainsi que la façon de les intégrer ensemble.

Pas de commentaires »

Publié dans 3-err , journalisation

Jour 2 Keynote

12 janvier 2010

Merci à tous qui sont venus à l'Cryptage / sommet de DLP. Voici les diapositives de mon discours le jour 2.

cryptage-DLP-keynote

Pas de commentaires »

Publié dans 3-err , Sécurité générale

Tags:

ICMPv6 défi -

13 décembre 2009

Le défi était: "Ecrire un filtre tcpdump / WinDump qui va capturer les paquets ICMPv6 Multicast Listener.« J'ai une vaste écrire sur ce qui fait la réponse si complexe. Si vous connaissez l'IPv6 et veulent juste la réponse, passez à la fin.

D'abord, le contexte

Steinar a fait quelques commentaires sur les publications précédentes et a été de 100% sur la bonne voie. Si vous les lisez et j'ai pensé «Wow, ça sonne vraiment désordre», vous comprenez l'ampleur du problème ainsi. :)

Protocole Vs. Champ-tête suivant

Avec IPv4 nous avons eu le champ des options. Cela pourrait provoquer l'en-tête IP pour passer de 20 octets à aussi grande que 60 octets en taille. Avec IPv6, il n'est plus un champ de possibilités et de l'en-tête est fixé à 40 octets. Lorsque les options sont nécessaires, nous utilisons têtes d'extension pour les identifier. Cela jette une balle courbe intéressante à nous, car avec le champ protocole IPv4 (octet 9) serait (presque) toujours d'identifier le transport de niveau supérieur (TCP, UDP, etc.) Avec IPv6 le champ d'en-tête suivant (octet 6) pourraient identifier le transport de la couche supérieure, ou il pourrait identifier une tête d'extension qui comprendra un certain nombre d'options.

Voici une liste de quelques têtes d'extension IPv6 que vous pourriez rencontrer, ainsi que les RFC qui les définissent:

Option # Option Description RFC
0 Hop-by-Hop 2460
6 TCP 793
17 UDP 768
43 Routage 5095
44 La fragmentation 2460
50 ESP 4303
51 AH 4302
58 ICMPv6 4443
59 Aucun en-tête suivant 2460
60 Options de destination 2460
135 Mobilité 3775

IPv6 ne limite pas le nombre de têtes d'extension, vous pouvez utiliser dans une seule packet.There est cependant une publication "afin recommandé" la façon dont les têtes doivent être énoncées. L'ordre est:

  • Tête IPv6
  • Hop-by-Hop options
  • Entête de routage
  • Fragment tête
  • AH
  • ESP
  • Options de destination
  • Tête de mobilité
  • TCP/UDP/ICMPv6

Notez que cette liste est «recommandé», mais pas obligatoire. Un hôte IPv6 doit être capable de traiter les en-têtes de ce que jamais l'ordre de leur réception. Cela signifie que vous trouverez probablement fournisseurs suivants cette liste, mais pas les attaquants. J'ai personnellement vu des dispositifs de commencer à agir vraiment bizarre quand vous salir avec l'ordre d'en-tête. En fait j'ai couru à travers un peu de "code compatible IPv6", qui ne peut pas traiter si l'ordre de préférence n'est pas utilisé.

Chasing l'entête du protocole

Donc, avec l'IPv6 que nous pouvons avoir plusieurs en-têtes derrière la tête IPv6. Si cela ressemble à un nouveau concept, il n'est pas réellement. En fait, vous avez probablement déjà travaillé avec elle. Lorsque vous déployez les deux protocoles IPSec de sécurité possibles sont ESP et AH. Il s'agissait en fait empruntée à l'IPv6 et massé à travailler sur IPv4. AH et ESP inclure un champ d'en-tête suivante pour identifier ce type de paquet, ils sont protecting.This est appelée chaînage du protocole, comme vous avez effectivement plusieurs en-têtes assis derrière l'en-tête du protocole de couche 3.

Donc, pour comprendre ce que le transport de niveau supérieur (TCP, UDP, etc) est utilisé, vous pouvez avoir à chercher dans plusieurs en-têtes avant de trouver la réponse. Ceci est appelé «chassant l'en-tête", et tcpdump / WinDump nous donner une option de filtre pour effectuer cette tâche. Vous pouvez être fimiliar avec le filtre proto. Dans le monde IPv4, si je dis:

ip proto tcp

Ce filtre se lit «chèque octet 9 de l'en-tête IPv4 et si la valeur est égale à 6 (valeur de protocole pour TCP), un match sur le paquet". Ce filtre n'est pas aussi efficace dans le monde IPv6, bien sûr, car l'octet 6 de l'en-tête IPv6 pourraient identifier le transport de la couche supérieure, ou il peut simplement identifier un en-tête d'extension optionnel qui est utilisé. Pour résoudre ce problème, le filtre protochain a été introduite. Rédaction:

ip6 protochain tcp

Se lit comme "Check octet 6 de l'en-tête IPv6 pour voir si la valeur est égale à 6. Si au contraire vous trouver une valeur qui identifie une tête d'extension en option, vérifiez le champ d'en-tête d'extension de tête suivant pour une valeur de 6. Si vous trouvez plus de têtes d'extension optionnelle, ne cesse de répéter le dernier test jusqu'à ce que vous trouver la tête de la dernière prolongation ».

Assez simple d'écrire en anglais, mais cela est un cauchemar pour mettre en œuvre dans le code. La plupart des têtes d'extension optionnels sont de longueur variable, qui ne fait qu'ajouter à la complexité. J'ai fait quelques tests avec Scapy et vous pouvez réellement voir la différence dans les performances lors de protochain est invoquée. En fait, vous pourriez probablement faire un bon travail de dosage un IDS / IPS en le forçant à traiter un grand nombre de têtes d'extension inutile.

Ecrire notre filtre

Donc, notre premier problème par écrit le filtre défi est que l'en-tête ICMPv6 peuvent ne pas apparaître immédiatement après l'en-tête IPv6. Nous devons nous méfier des têtes d'extension optionnelle. En fait RFC 2710 stipule: "Tous les messages MLD décrites dans ce document sont envoyés avec une adresse de lien local IPv6 source, une limite de 1 IPv6 Hop, et une option routeur IPv6 Alert [RTR-ALERT] dans un Hop-by-Hop tête Options ". Cela signifie que nos paquets Multicast Listener est nécessaire d'avoir une tête d'extension Hop-by-Hop avec l'option d'alerte du routeur. Dans cet esprit, notre première vérification devrait être:

ip6 protochain icmp6

Pour nous assurer que nous ne regardant paquets ICMPv6. Maintenant, il est juste une question de vérification pour voir si le champ Type (octet 0) est fixé à 130 (Multicast Listener Query) ou 131 (Multicast Listener Report). Ceci nous amène à notre second problème cependant. Dans le monde IPv4 je peux faire un:

ICMP [0] = valeur <type de interest>

Si j'essaie cela avec icmp6 j'obtiens:

[Root @ fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 protocole de couche supérieure n'est pas supporté par proto [x]

En d'autres termes, je ne peux pas utiliser les compensations avec les icmp6 pour rechercher des valeurs spécifiques. WinDump et tcpdump sont annoncés comme compatibles avec IPv6, mais ne vous attendez pas à obtenir toutes les mêmes fonctionnalités que vous avez avec IPv4. Beurk!

Alors, que faisons-nous? Nous aurons à se replier sur le référencement de la valeur à partir d'un ip6 offset. En d'autres termes, nous aurons à mesurer à travers l'en-tête IPv6, à travers la nécessaire Hop-by-Hop-tête, et dans la tête ICMPv6 pour voir si le champ type est fixé à 130 ou 131. Certaines choses à prendre en considération:

  • Tête IPv6 est fixé à 40 octets
  • Hop-by-Hop-tête est variable, mais 4 octets avec Router Alert jeu
  • Le champ type est de 0 octet dans l'en-tête ICMPv6

Alors voici ce que nous nous retrouvons avec:

ip6 protochain icmp6 et (ip6 [44] = 130 ou ip6 [44] = 131)

Ouf! Nous avons finalement eu! Ou avons-nous?

Q: Que faire si le paquet a-têtes d'extension supplémentaires?

R: Notre filtre ne fonctionnera pas.

Q: Que faire si l'entête Hop-by-Hop a plus d'options mis à Router Alert?

R: Notre filtre ne fonctionnera pas.

Q: Peut-on fixer les deux problèmes ci-dessus?

R: Non jusqu'au tcpdump / WinDump filtrage ajoute SI soutien boucle / THEN.

Donc, si nous voulons capturer le trafic ML normal, le filtre ci-dessus fonctionne parfaitement. Si toutefois nous voulons nous assurer que nous rattraper rouerie attaquant ainsi, le filtre ne va pas voler.

Que si nous essayons quelque chose comme ceci:

tcpdump-nn-s 1500-x ip6 protochain icmp6 | grep-i multidiffusion> multicast.txt

et ensuite il suffit d'utiliser l'outil Wireshark text2cap pour le convertir en format de Libpcap? Le problème ici est que nous ne recevoir que les informations d'en-tête. Grep va correspondre à la ligne de résumé, qui contient le mot «Multicast» mais ensuite sauter toutes les Hex-dessous de lui qui est le contenu réel du paquet.

Donc la réponse finale est: "Impossible d'obtenir à partir theyâ haya" ;)

Alors que faire si vous avez vraiment besoin d'être en mesure de voir ce trafic? Jusqu'au support IPv6 arrive à maturité, la seule méthode 100% est de saisir l'ensemble du trafic ICMPv6 et ensuite trier manuellement à travers elle.

Du moins c'est mon avis à ce sujet. Si quelqu'un peut effectivement arriver à une solution de travail à 100%, je serais ravi de l'entendre.

Pas de commentaires »

Publié dans 3-err , Packet Décodage

Tags:

ICMPv6 Challenge - Astuces

9 décembre 2009

OK, voici un indice pour vous diriger dans la bonne direction.

Le défi était: "Ecrire un filtre tcpdump / WinDump qui va capturer les paquets ICMPv6 Multicast Listener".

Cela semble facile, non?

Avec un peu d'aide de Google, vous trouverez que le «type» pour Multicast Listener est de 130, et le champ type ICMPv6 est le premier octet de l'en-tête. Donc, ce devrait être aussi simple que:

tcpdump-nn-p-v-s 0 icmp6 [0] = 130

Toutefois, si vous exécutez la commande que vous obtiendrez de retour:

tcpdump: IPv6 protocole de couche supérieure n'est pas supporté par proto [x]

En d'autres termes, vous pouvez utiliser "icmp6" pour voir tous les paquets ICMPv6, mais vous ne pouvez pas l'utiliser pour filtrer sur l'un des champs d'entête ICMPv6.

Nous avons donc besoin d'un «plan B». Figure dehors de plan B et que vous avez résolu le problème. :)

4 commentaires »

Publié dans 3-err , Packet Décodage

Tags:

ICMPv6 Défi

4 décembre 2009

S'appuyant sur le défi IPv6 depuis la dernière fois, j'ai une nouvelle pour vous: écrire un filtre tcpdump / WinDump qui capture les paquets ICMPv6 Multicast Listener.

Ça y est! Assez facile, non? ;)

Pas de commentaires »

Publié dans 3-err , Packet Décodage

Tags:

Défi Week-End - Réponses

3 décembre 2009

Eh bien aujourd'hui jeudi son alors j'ai pensé de son temps de poster les réponses à contester week-end dernier. ;)

D'abord, pourquoi devriez-vous même les soins au sujet d'IPv6 si vous n'avez pas commencé à le déployer? J'ai senti la même manière jusqu'à ce que je trouve IPv6 étant utilisé comme un canal de communication secrète au sein du réseau d'un client. Les données ont ensuite été poussés hors de l'Internet via Teredo. Si vous n'êtes pas familier avec la technique, Scott Hogg a certains postes excellents sur le sujet.

Donc même si vous n'utilisez pas actuellement IPv6, il paye pour commencer à couper le remède à la technologie ainsi que de regarder pour cela sur votre réseau local.

Donc, pour examen, le défi était:

Ecrire un filtre tcpdump ou WinDump qui va capturer tout le trafic avec une adresse IPv6 source de l'année 2001: db8:: 10 à 2001: db8:: 20.

Il ya un couple de mises en garde avec l'écriture de ce filtre. L'J'ai quelques premiers couverts dans le dernier post. Le dernier, que je connaissais, mais jamais vraiment pensé a un problème jusqu'à ce que je commence à travailler avec IPv6 assez fortement, c'est que tcpdump / WinDump ne vous laisser utiliser 1, 2 ou 4 masques d'octets. Ainsi, alors que nous serions ravis de résoudre ce avec une déclaration initiale filtre "ip6 [8:14] =", nous ne pouvons pas parce que nous sommes limités à 4 octets. Il est en fait un moyen de contourner ce problème, mais je vais y revenir.

Alors, voici le filtre, j'ai travaillé avec:

(Ip6 [08:04] = 0x20010db8 et ip6 [12:04] = 0 et ip6 [16:04] = 0 et (ip6 [20:04]> = 0 × 0010 et ip6 [20:04] <= 0050 ))

Peu long, mais ça fonctionne. Elisabeth a trouvé une solution qui est beaucoup plus élégante que le mien:

src net 2001: db8:: / 122 et ip6 [23]> = 0 × 10 & & ip6 [23] <= 0 × 20

Ainsi, en commençant par le format libpcap, elle est capable de combiner mes trois premiers relevés en un seul. Pour ne pas être une reine de taille, mais qui rend sa solution est beaucoup plus courte que la mienne. Dans ce cas c'est une bonne chose. :)

C'est à ce sujet. Je vais poster un autre défi de type IPv6 demain.

5 commentaires »

Publié dans 3-err , Packet Décodage

Tags: