Est-ce Rentabilité tuer l'innovation?

2 septembre 2010 par Chris commentaire »1

Paul Graham possède une excellente écriture sur pourquoi Yahoo a fait faillite . L'article complet est intéressant de le lire, mais voici deux citations choix:

Je me rappelle avoir David Filo la fin de 1998 ou au début de 1999 que Yahoo devrait acheter Google, parce que je et la plupart des autres programmeurs de la compagnie ont été de l'utiliser au lieu de Yahoo pour la recherche. Il m'a dit que c'était pas la peine de s'inquiéter. Recherche n'était que de 6% de notre trafic, et nous avons une croissance de 10% par mois. Il ne valait pas mieux faire.

Et plus tard, Paul poursuit en disant:

Si les circonstances avaient été différentes, les gens qui dirigent Yahoo aurait pu réaliser plus tôt l'importance de la recherche a été. Mais ils avaient l'obstacle le plus opaque dans le monde entre eux et la vérité: l'argent. Tant que les clients ont été écrit gros chèques pour des bannières publicitaires, il était difficile de prendre au sérieux de recherche. Google n'a pas que pour les distraire.

Premièrement, une clause de non responsabilité: Les opinions que je vais exprimer sont les miennes. Ils ne représentent pas, ou ont des liens avec une organisation avec qui j'ai travaillé dans le passé, présent ou futur. Si vous voyez un manque d'innovation au sein de votre organisation, de savoir que j'ai fait le travail pour vous, et que ces opinions sont sur votre organisation, je peux vous assurer qu'ils ne sont pas. Ce sont des observations au sujet d'une organisation complètement différente.

l'article de Paul fait mouche pour moi. En repensant au fil des années j'ai passé de consultation pour des organisations différentes, j'ai remarqué un modèle distinctif. L'espace Internet est encombré avec des entreprises qui avaient une certaine innovation cool, fait des incursions dans leur part de marché, mais a ensuite perdu leur chemin dans la poursuite de la hausse des profits. On peut voir dans la culture interne de l'organisation ainsi que leur front face à l'interaction avec le public. Une fois le changement d'orientation du développement technologique à long terme à la rentabilité à court terme, l'organisation a commencé une spirale descendante.

Probablement l'un des premiers exemples a été le plus public Lotus . Pour les gens avec autant de cheveux gris autant que moi, vous souvenez sans doute que des programmes comme 1-2-3 et Notes mettre le PC sur la carte que le système de classe d'affaires de choix. Dans le début des années 90 tout le monde était en cours d'exécution de logiciels Lotus. Pour cette période de l'histoire, il était extrêmement novateur et fonctionnel. Il y avait un certain nombre d'années où littéralement chaque entreprise je n'ai eu de travail pour de grands déploiements de logiciels Lotus.

Puis vers le milieu des années 90, tout a changé. Nouvelles versions des bugs corrigés plutôt que de pousser la technologie vers l'avant. Un système de copie draconiennes de protection a été mis en œuvre. Les coûts de l'assistance téléphonique et des correctifs ont percé le toit. Je me souviens du moment exact j'ai décidé de faire ce que j'ai pu pour sortir de logiciels Lotus. J'étais assis en attente pour cc: Mail de soutien (le magasin de données s'est corrompu à nouveau) et ont réalisé qu'ils avaient embauché un disk jockey à jouer de la musique et d'annoncer les temps d'attente file d'attente (en général 30-60 minutes). Cette m'a dit que Lotus savait qu'ils avaient des problèmes de soutien, mais plutôt que de s'attaquer aux causes profondes qu'ils ont pris le chemin très bon marché et a embauché un animateur. Même si je suis sûr que cela a augmenté leur rentabilité à court terme, elle a envoyé des gens comme moi-même en cours d'exécution dans le camp Microsoft.

De rustres cours n'était pas la dernière. Nous avons même vu Microsoft à développer à pas de géant jusqu'au changement d'orientation de l'innovation à la protection de copie et de nappes de marketing. SCO changé leur modèle d'entreprise d'être une solution SMB aux avocats plaidants être, et rapidement glissé dans l'oubli. On peut même être le revoir avec Oracle. Certains prétendent que Oracle acheté soleil de ne pas transmettre leur innovation, mais plus précisément de plaider contre Google . Difficile de soutenir ce point de l'extérieur, il semble que l'autre seule chose qu'ils ont fait avec Sun est de tuer OpenSolaris , coupant ainsi une série d'innovations offertes par les programmeurs extérieurs.

Dans l'article de Paul, il reproche à l'origine sur Yahoo ne pas embaucher les meilleurs programmeurs. Dans mon expérience, le problème est plus profond que cela. Quand une entreprise entre dans cette phase d'auto destructrice ils se concentrent moins sur les innovateurs d'embauche (comme les programmeurs) et plus sur l'embauche des compteurs de haricots. Les changements portent de promouvoir de nouvelles idées pour évincer tous jusqu'au dernier sou pour le gain à court terme. Le premier signe est habituellement changements de politique absurde. Les cubes peuvent être décorés en quelque sorte l'emporte-pièce, les ingénieurs doivent vider leurs poubelles propres, vous passez plus de votre comptabilité par jour pour notre temps plutôt que de réellement accomplir quelque chose, etc etc

Même si je suis sûr que certains comptable peut montrer sur un graphique à barres jolie que ce genre de politique de changements augmentent la rentabilité, il leur manque un point très important. Les changements de créer un environnement qui est préjudiciable à la pensée innovatrice. Le changement de culture, mais toutes les garanties que les idées novatrices vont à l'échec, et des penseurs novateurs vont passer à d'autres occasions. Paul interaction avec Yahoo est un excellent exemple. Pensez-y comme étant synonyme d'investir dans les denrées alimentaires à l'épicerie. Les produits alimentaires à bas prix se traduira par une rentabilité à court terme, mais à long terme il faudra probablement augmenter considérablement vos coûts de soins de santé . Lorsque vous calculez pennies il est facile de perdre de vue l'objectif à long terme (comme une longue vie en bonne santé).

Alors, le problème des grandes entreprises? Est le mantra que seules les petites entreprises peuvent innover faim Si les grandes entreprises sont destine à l'échec? Personnellement, je ne pense pas que cela est vrai. J'ai vu de grandes entreprises qui sont assez intelligents pour créer des groupes de réflexion interne pour favoriser l'innovation. Des mécanismes sont mis en place afin que les nouvelles idées flottaient à la surface et l'échec ne soit pas synonyme de cessation d'emploi. Bien que la rentabilité est encore important (et à mon avis il devrait être), le risque de création en tenant verticaux potentiels des technologies sont pris en charge par la haute direction. Un bon exemple de ce qui est probablement Apple. Déménagement des ordinateurs aux téléphones a été un changement majeur dans leur marché vertical, mais cela a payé au centuple.

En fin de compte, je pense qu'il vient vraiment à la culture d'entreprise. Ce qui tue une entreprise n'est pas sa taille, mais sa capacité à promouvoir à long terme au lieu de penser à court terme. le test de validation rapide, si vous remarquez que votre organisation d'embauche compteurs de haricots plus innovateurs, vous pouvez déjà être sur la spirale à la baisse.


Fast Path VMware Versus voie lente Firewalls

30 août 2010 par Chris Pas de commentaires »

Beaucoup d'entre nous travaillons actuellement avec les pare-feu virtuel. J'ai fait un post plus haut au sujet de la forces et les faiblesses de la sécurité dans le monde virtuel , mais aujourd'hui, je veux parler de la possibilité de pare-feu avec VMware. Il ya eu beaucoup d'excitation au sujet de VMware relativement nouveau VMsafe API . Plus précisément, tout le monde est le brouillage de créer / déployer un pare-feu voie rapide. Mais toutes les implémentations sont créés égaux voie rapide? Y at-il des problèmes de sécurité d'aller avec une solution rapide chemin? Débutons notre étude et de voir.

Répartition des VMsafe

Avec la sortie de la sécurité VMsafe API, VMware a amélioré les options disponibles pour la mise en œuvre de la sécurité dans un environnement vSphere en autorisant les fournisseurs à se branchent directement sur l'hyperviseur dans l'anneau 0. VMsafe se compose de trois volets:

  • VDDK - inspection de blocs du disque. API a été publié publiquement.
  • vCompute - processeur et la mémoire de l'API. N'a pas été rendue publique. Inconnue auxquelles des tiers ont accès, le cas échéant.
  • vNetwork - API de surveiller et de filtre entre le vNIC et vSwitch. N'a pas été rendue publique. Au meilleur de ma connaissance, seuls Altor Networks & Systems Reflex avoir accès (deux fournisseurs qui ont contribué à l'élaboration de l'API).

Plus précisément, je veux parler à l'API vNetwork. Lors du contrôle de flux de trafic réseau au sein d'un hôte ESX, il ya deux la mise en œuvre possible, "voie lente" et "chemin d'accès rapide".

Voie lente

voie lente est la plus simple mise en œuvre et celle que nous avons utilisé pendant des années. En effet il s'agit juste d'un invité VM, semblable à n'importe quel invité VM d'autres, en cours d'exécution sur l'hôte ESX. En général, chaque client est connecté à un vSwitch unique, et chacun de ces vSwitches est connecté à un unique vNIC sur le pare-feu. Ceci est similaire à une configuration de pare-feu existants, mais mis en œuvre pratiquement. Le bénéfice de l'exécution en voie lente est que vous pouvez exécuter un coup en pleine OS avec toutes les bibliothèques ou les services requis pour soutenir le pare-feu.

Fast Path

voie rapide est en fait un anneau 0 pilote qui se branche directement dans le noyau hyperviseur. Cela permet à un fournisseur tiers de tirer parti de l'hyperviseur pour l'insertion entre chaque connexion vNIC vSwitch /. Parce que le conducteur voie rapide est en cours d'exécution dans le contexte du noyau, il ajoute un surcoût minime pour le système. Le résultat est l'exécution de code au sein de chemin d'accès rapide est sensiblement plus rapide que le même code en cours d'exécution au sein de voie lente (et donc la convention de nommage VMware pour chaque contexte). Charge sur l'hôte ESX est réduit au minimum, de sorte que le résultat final est que vous pouvez exécuter les clients beaucoup plus virtuel.

Vs Fast Slow

Ainsi, il semble que vous voudriez faire tout ce chemin à l'intérieur rapide, mais il ya un certain nombre de questions. voie rapide est un pilote du noyau branchant sur un hyperviseur réduits au minimum, pas un système d'exploitation plein fouet. Cela limite les bibliothèques et les services de pare-feu a disponibles pour contrôler les flux de trafic. De plus, nous sommes de brancher un pilote du noyau si il doit y avoir l'assurance qu'il ne l'hyperviseur ballonnement, augmentation de la surface d'attaque ou d'interférer avec d'autres fonctions hyperviseur. VMware effectue une revue de code sur tous les conducteurs voie rapide avant sa libération. Donc, si je pourrait théoriquement mettre en oeuvre tout mon code dans le chemin d'accès rapide, j'aurais besoin de l'approbation VMware avant chaque patch ou Feature Release.

Dans cet esprit, un fournisseur réclamant «voie rapide» de soutien est en réalité va finir par mettre en œuvre une partie de leur code en tant que chemin d'accès rapide, une partie de voie lente, puis créer un connecteur entre les deux. Comment la charge est mis sur le système dépendra de la façon dont une grande partie de ce code est mis en œuvre en voie rapide et dans quelle mesure il est exécuté en voie lente.

Possibles déploiements Fast Path

Par exemple, un fournisseur peut choisir d'écrire un pilote voie rapide que le simple fait tunnels tous les paquets de retour à une voie lente mise en oeuvre de pare-feu. Le code voie lente détermine alors si le trafic doit être adopté ou abandonné, avec des paquets transmis d'être renvoyé au code de chemin d'accès rapide pour l'insertion dans le canal de contrôle hyperviseur. Alors que ce serait la méthode la plus simple de déployer voie rapide, et sans doute la plus sûre et la plus sûre, elle offrirait des avantages au rendement. Système de charge ne serait probablement pas beaucoup mieux que la mise en œuvre pleine voie lente. Je vois cette option comme étant très attractif pour les fournisseurs de pare-feu existants, car elle nécessiterait le moins de modification de leur code existant tout en étant capable de réclamer "un soutien voie rapide».

Une autre option serait d'utiliser l'espace voie lente pour les fonctions administratives avec le pilote de chemin à action rapide comme le moteur pare-feu. Ainsi, par exemple l'administrateur de pare-feu créerait la politique grâce à une interface fonctionnant sur une voie lente VM, qui serait ensuite pousser la politique vers le bas pour un pilote de voie rapide. Dans cette configuration, le pilote de voie rapide a une copie de la politique de contrôle de la circulation alors peut être mis en œuvre immédiatement. Le résultat est plus rapide de traitement du trafic avec une charge minimale du système. Le compromis est plus volumineux de code dans l'anneau 0.

Il est également possible de mettre en oeuvre un mélange des deux. Par exemple je ne pouvais utiliser le pilote voie rapide à mettre en œuvre la politique de pare-feu, mais ensuite passer tous les "accepté" les paquets vers le système de voie lente pour le contrôle d'intrusion, détection de virus, ou tout ce qui est nécessaire. paquets acceptables sont ensuite répercutés sur le conducteur voie rapide pour l'insertion. Donc, dans cette configuration tous les «laisser tomber» les paquets sont traités par un chemin rapide, tandis que les paquets acceptés interagir avec un composant de chemin lent.

En remarque, vous avez besoin de garder les informations ci-dessus à l'esprit lors de l'examen toutes les implémentations vNetwork, et pas seulement un pare-feu. L'API vNetwork peut également être utilisé pour l'application des politiques, la QoS, la collecte des statistiques du réseau, etc Par exemple, la mise en œuvre vNetwork première était en fait de VMWare Lab Manager. Cet outil est utilisé pour le service d'auto approvisionnement et ne contient pas de composant pare-feu (ce qui est mis en œuvre par VShield).

Résumé

Si un produit qui s'intègre avec VMware VMsafe peut être strictement une «voie lente» mise en œuvre, il est hautement improbable que tout produit peut être considérée uniquement comme une «voie rapide» mise en œuvre. Tout produit voie rapide est le plus susceptible d'être un hybride. C'est juste une question de combien de code existe dans le chemin d'accès "rapide" d'espace par rapport à la «voie lente» de l'espace. Quand un produit demandes de soutien voie rapide, vous avez besoin de creuser un peu plus loin pour analyser la mise en œuvre afin d'identifier tous les avantages de performance réel.

La Scam Comcast

25 août 2010 par Chris Pas de commentaires »

Complètement sans rapport avec la sécurité, mais a été surpris quand ça m'est arrivé et je pensais que j'allais jeter un heads up.

Lorsque vous payez votre carte de crédit ou une hypothèque, il existe des lois en place pour (essayer) de tenir les créanciers de gougeage vous. Par exemple, si vous effectuez un paiement par carte de crédit, le créancier doit demander que le paiement de la plus ancienne d'achat. S'ils ne le faisaient pas, ils pourraient facilement vous assommer avec des intérêts plus élevés et les pénalités que de rembourser les achats récents. La loi est conçue pour fournir un certain niveau de protection des consommateurs.

Apparemment, les mêmes règles ne s'appliquent pas à Comcast. Début Juin je suis allé dans le bureau local de Comcast et ramassé deux boîtes nouveau câble. Ces qu'il fait sur mon projet de loi Juin, que j'ai complètement raté à cause de Voyage. J'ai ma configuration banque pour faire l'auto-paiements, mais l'auto-Juin paiement a fini par être 18 $ à court. Aller à Juillet et j'ai eu le même problème. Je n'ai pas regardé le projet de loi et de laisser l'auto-payer faire sa chose. Sauf maintenant ce n'est pas seulement 18 $ Bref, il est de 18 $ plus les frais et pénalités.

Nous voici donc au mois d'août. Moins de 30 jours depuis mon dernier a effectué un paiement et Comcast ont tué mon service. Téléphone, télévision et Internet, tout en mode hors connexion. Quand j'ai appelé pour savoir le problème, on m'a dit mon compte était de 60 jours de retard. Après avoir parlé à trois personnes différentes on m'a dit que Comcast a une telle exigence ne s'applique aux paiements à la plus ancienne des dettes. Ainsi, alors que mon projet de loi a été examiné Juillet actuelle, mon projet de loi a été examiné Juin 60 jours de retard. Ainsi, l'interruption de service, ainsi que les frais multiples pour redresser la chose à tout. Si Comcast a eu lieu aux mêmes normes que la plupart des créanciers, je dois encore les 18 $. Parce qu'ils ne sont pas, avec leur structure de frais, je dois maintenant 47 $, et ce nombre continue de grimper (apparemment leur service Tivo ne peut pas être remis en marche sans un service de technologie).

Postmortem

  • Regroupement des services à domicile peuvent économiser de l'argent, mais en fait un point de défaillance unique méchant
  • Soyez prudent en utilisant une banque basée auto-payer les factures qui peuvent varier
  • structure des taxes Comcast leur permet d'obtenir un taux de rendement annuel de 967% si vous êtes si bien que 1 $ en retard et il manque le mois suivant

La marée se tournant?

3 juin 2010 par Chris Pas de commentaires »

J'ai dit depuis des années que l'anti-virus n'est plus en vigueur et qu'une bonne posture de sécurité doit inclure la liste des applications blanc. Voici une citation de George Kurtz cool, directeur de la technologie de McAfee:

"Vous ne pouvez pas compter uniquement sur les logiciels antivirus - et nous sommes une société d'antivirus. Et les pare-feu ne suffisent pas à assurer une protection adéquate ", at-il dit.

Antivirus, pare-feu et détection d'intrusion sont un début. Mais "liste blanche" offre une meilleure protection. C'est essentiellement de verrouillage des ordinateurs bas de sorte que seuls les programmes approuvés sont autorisés à courir. Rien ne peut être modifié ou ajouté ou mis à jour, sauf par un administrateur système.

McAfee estime que «c'est là que l'avenir va», dit Kurtz.

Lien vers histoire

Fashionably retard à la fête, mais je vais le prendre. ;-)

Les systèmes virtualisés plus ou moins sûre?

18 mai 2010 par Chris Pas de commentaires »

J'ai eu la question ci-dessus demandé suffisamment de fois que je me sentais digne d'un billet de blog. Alors il ya quelques années 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.

Virtualisation Everything Changes

J'ai entendu une remarque quelques gens que la virtualisation est sur le point d'impact sur l'industrie de la même manière que l'Internet a fait dans les années 90. Pour être honnête, je pense qu'il ya du mérite dans cet avis. Dans le début des années 90 la plupart des gens étaient en cours d'exécution 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é dans 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é plus que 10 ans. Les deux d'administration de 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 à avoir le même impact sur l'industrie. le déploiement de virtualisation nécessite une refonte complète de la façon d'appliquer la sécurité. admins Retour dans les années 1990, qui a simplement branché sur l'Internet, sans égard à la façon dont cela aurait un impact de leur réseau, a été brûlée grand temps. Nous sommes en train de voir un résultat similaire que des gens adoptent la virtualisation.

Qu'est-ce qui virtualisation moins sûr

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 hôtes loin les uns des autres, ainsi que l'accueil et / ou hyperviseur. Il ya deux problèmes majeurs avec cette attente:

  1. Aucun logiciel n'est sans bug
  2. Le logiciel peut être mal configuré

Il ya quelques années de base de recherche ont montré qu'ils pouvaient sortir de l'hôte et de prendre le contrôle intégral du système d'exploitation hôte . Alors qu'un hyperviseur est censé limiter ce type d'exposition, nous avons vu des cas où même l'hyperviseur a été contourné . 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 sera prudent de faire confiance aveuglément à la protection de logiciels. Le problème est que les éditeurs ne prennent pas toujours la même approche. Prenez avec leurs VMware ESX (qui sera bientôt ESXi) produit à titre d'exemple. Beaucoup d'entre nous ont été sidérés quand un représentant de VMware a annoncé au CanSecWest qu'il était théoriquement impossible d'attaquer l'hyperviseur ESX . Quand on se contenter de supposer quelque chose est incassable, quelqu'un de plus créatif va trouver un moyen pour percer .

Un de mes plus grandes préoccupations avec ESX / ESXi est que VMware a conçu pour qu'il soit modulaire (via VMsafe ). Du côté positif, cela signifie que les fournisseurs externes peuvent créer des produits pour aider à améliorer la fonctionnalité de l'hyperviseur et la 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 créé le pare-feu Gauntlet, qui à cette époque était l'un des Kick Butt et sécuriser les dispositifs de sécurité les plus disponibles. Lorsque trois agences lettre voulait 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 continue de vulnérabilités ont été découvertes, chacun introduit par ces nouvelles "features". De là, le produit a perdu sa crédibilité et de sécurité a glissé hors du radar.

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

Obtenir la tête droite

OK, nous ne pouvons pas aveuglément le logiciel de virtualisation pour maintenir la confiance des attaquants à distance. Nous pouvons cependant toujours prendre des précautions pour minimiser l'impact si le pire se produit. Une des plus grandes mesures que vous pouvez faire est d'examiner attentivement les serveurs se accueilli, et les systèmes d'autres invités sont 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 en l'espèce.

Une zone de sécurité est tout simplement un ensemble de systèmes qui partagent le même niveau de risque relatif. Par exemple Web, le nom et les serveurs SMTP sont généralement situés sur une zone démilitarisée, car ils risquent tous partagent les mêmes d'une 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érent de celui des serveurs. C'est parce que les serveurs ont peu ou pas d'accès à Internet tandis que les ordinateurs de bureau 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'application de virtualisation. Un serveur de DMZ et un serveur interne ne devraient pas être invités sur le même matériel (deux CPU et matrice de disques). Cela pourrait permettre à un attaquant de créer une autre route dans notre réseau. Plutôt que d'avoir à passer par le pare-feu, appareils etc NIDS, les PIN, qui a été déployée sur le fil, un attaquant peut être en mesure d'accéder aux ressources internes via le logiciel de virtualisation. Est-ce une attaque facile? Pas de ce que nous avons vu jusqu'à présent. exploite fonctionnels ont été découverts Toutefois, alors pourquoi présenter des risques inutiles si nous n'avons pas à.

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

Ce qui fait de virtualisation plus sécurisé

Heureusement, du point de vue de la sécurité, la virtualisation n'est pas que des mauvaises nouvelles. En fait, il existe des 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 pour lesquelles nous avons commencé à utiliser la virtualisation dans le Honeynet aussi tôt que 2000.

Un des plus gros problèmes de sécurité auxquels nous sommes confrontés aujourd'hui est rootkits niveau du noyau . Ce qui rend cette souche de malware si insidieux qu'il est effectivement tourne 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 lecteur sur un connu pour être propre OS et l'exécution de nos contrôles judiciaires à partir de là. Oh bien sûr le problème de ce procédé est qu'il ne s'adapte pas bien. Si nous avons des dizaines ou des centaines de serveurs, il n'est tout simplement pas assez de temps dans une journée pour les vérifier tous les correctement.

Comme mentionné précédemment, VMware permet aujourd'hui des tiers l'accès des fournisseurs des parties à l'API via VMsafe hyperviseur. 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 se branchant sur l'hyperviseur, certaines options de sécurité très cool devenu possible.

Par exemple disons un système d'exploitation invité est attaqué par un rootkit au niveau du noyau. En analysant la mémoire hôte, 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é ses activités et de passer inaperçues. Comme mentionné précédemment, il n'existe aucune option comparable à un système non virtualisé.

La fiche API crée aussi de nouvelles possibilités pour traiter le trafic crypté. Lorsque le chiffrement de bout en bout est employé (comme un VPN) des contrôles de réseau, sur la base de la couche application sont facilement contournés. Votre seule option réelle est de faire fonctionner le logiciel agent sur le point de fin, si la sécurité pourraient être mises 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ûre de ces données.

Nous commençons tout juste à voir les nouveaux produits qui tirent parti de l'API VMsafe plug . Comme tous les produits sont relativement nouveaux, le jury est encore sur la façon dont ils peuvent être efficaces. Offres exécuter la manœuvre de remplacement de pare-feu basés sur l'hôte et la protection IDS pour appliquer la politique intégral. Il sera intéressant de voir comment ce produit de niche secoue l'année prochaine.

Résumé

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

La combinaison de Logwatch et OSSEC - Partie 4

18 février 2010 par Chris 3 commentaires »

Dans mon dernier post, nous avons installé Logwatch ainsi que OSSEC. Il est maintenant temps de se 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 l'on peut 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, c'est que nous avons seulement besoin d'un système. Logwatch sera exécuté sur le système hébergeant le serveur OSSEC. Le problème que nous allons courir en implique cependant la OSSEC fichier d'alerte. Les entrées du journal ne sont pas normalisées. Cela signifie que le format peut varier d'entrée à l'entrée, et peut même répartis sur plusieurs lignes. Il va être un véritable cauchemar pour créer un script Logwatch qui filtre et résumer les informations d'alerte.

Si nous optons pour l'option # 2, nous aurons besoin une autre boîte pour agir comme serveur de journalisation centralisée. Afin d'avoir le serveur OSSEC accepter des entrées de journal à partir de systèmes non-agent, il doit écouter sur UDP/514. C'est le même port utilisé par un serveur centralisé l'exploitation forestière, et vous ne pouvez pas avoir deux applications partagent le même port (sauf avec Windows, mais l'accès est extrêmement salissant socket). Sur le plan positif, les entrées d'alerte obtiendrez normalisée quand ils sont transmis au serveur Syslog afin de créer un script sommaire Logwatch sera beaucoup plus facile. En outre, Logwatch sait déjà sur les fichiers Syslog, alors nous aurons moins de travail de personnalisation à faire.

Enfin, je l'ai mentionné dans un précédent post que OSSEC n'est pas conçu pour être une carte SIM. C'est parce qu'il n'a pas tout ce dossier, seulement 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 suis passe réellement à couvrir l'option # 1 car il s'agit d'une configuration beaucoup plus complexe.

Traiter avec horodatages

Jetez un oeil sur le fichier journal principal OSSEC et vous devriez voir semblable au suivant:

[root @ fubar journaux] # tail -3 / var / OSSEC / logs / ossec.log

2010/02/18 12:32:05 OSSEC-rootcheck: INFO: fin rootcheck scan.

2010/02/18 14:27:06 OSSEC-syscheckd: INFO: A partir syscheck scan.

2010/02/18 14:39:21 OSSEC-syscheckd: INFO: fin syscheck scan.

Notez la façon dont la date / heure est formaté. Ceci est différent de la plupart des applications, la première chose que nous devrons faire est de dire Logwatch la 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 passer dans le répertoire partagé 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:

utilisation Logwatch: dates;

my $ Debug = $ ENV ('LOGWATCH_DEBUG') | | 0;

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

if ($ Debug> 5) (

print STDERR "DEBUG: N à l'intérieur ApplyLongDate ... \";

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

)

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

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

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

Imprimer thisline $;

)

)

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

Une fois que vous enregistrez le fichier, il nous faut maintenant configurer les permissions:

chmod 755 applylongdate

Configurer le journal des fichiers

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 à suivre 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 gérer les alertes et les changements OSSEC réponse active.

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

cd / etc / logwatch / conf / fichiers de log

vi ossec.conf

Le contenu du fichier doit être la plus suivie:

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 la plus suivie:

LogFile = / var / OSSEC / logs / actif 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 installation.

Configurer les 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 créer le premier fichier:

cd / etc / logwatch / conf / services

vi ossec.conf

Le contenu de ce fichier est assez simple:

Titre = "Messages OSSEC"

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 = "OSSEC Alertes"

LogFile = OSSEC d'alerte

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

Analyse Les entrées

Ensuite, nous devons dire à Logwatch comment mettre en forme 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 l'aide d'un script de test fournis Logwatch; juste pour s'assurer que tout fonctionne.

Commencez par passer dans le répertoire approprié:

cd / etc / logwatch / scripts / services

Utilisez votre éditeur préféré pour créer votre premier script:

vi OSSEC

Le contenu du script devrait être aussi suivies:

#! / Bin / bash

# Ce script est aussi agréable qui va vous montrer les lignes que vous

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

# Les variables d'environnement standard et puis il faut STDIN et

# Dump-il juste 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 "Debug Level: $ LOGWATCH_DEBUG"

# Maintenant, prenez STDIN et STDOUT vidage

chat

Maintenant, créez votre second script:

vi OSSEC d'alerte

et notamment le contenu exact même:

#! / Bin / bash

# Ce script est aussi agréable qui va vous montrer les lignes que vous

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

# Les variables d'environnement standard et puis il faut STDIN et

# Dump-il juste 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 "Debug Level: $ LOGWATCH_DEBUG"

# Maintenant, prenez STDIN et STDOUT vidage

chat

Enfin, nous devons définir les autorisations appropriées:

chmod 755 OSSEC *

Tester la configuration

La meilleure façon de tester notre nouvelle installation consiste à exécuter la commande:

| Logwatch moins

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

OSSEC logwatch-service | less

| Logwatch service OSSEC d'alerte moins

Une personnalisation plus poussée

Une fois que vous obtenez tous les travail-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 belles choses sur le script de test ci-dessus ci-dessus, c'est qu'il vous montre exactement ce que vous avez à travailler avec. Ainsi, avec une expression régulière magie peu vous pouvez résumer les entrées que vous jugerez appropriées. Pour quelques idées, consultez les fichiers qui se trouvent sous:

/ Usr / share / logwatch / scripts / services

Ce sont les scripts de synthèse par défaut fourni 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 la quantité de verbosité de l'utilisateur est à la recherche. Par exemple, si vous êtes encore dans le répertoire ci-dessus services, exécutez la commande suivante:

moins sshd

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

/ Key> <Enter Détails

La barre oblique inverse nous permet de rechercher 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 instance de la chaîne de texte. Il mettra également en évidence la chaîne de recherche. Dans le premier match, vous remarquerez que l'auteur attribué à la variable "$ Détails» pour être le même que la variable $ LOGWATCH_DETAIL_LEVEL ". Il s'agit de sauver les quelques frappes.

Maintenant, appuyez sur la touche barre oblique inverse a été suivie par la touche Entrée. Cela sauter à travers le dossier à l'instance suivante de «détail». Vous devriez voir:

if ($> Détails = 20) (

$ ($ Utilisateur Utilisateur) ($ host)) ($ Méthode + +;

) Else (

if ($ host! ~ / $ IgnoreHost /) (

$ ($ Utilisateur Utilisateur) ($ host) ("(tous les )"}++;

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

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 touches% autreliste;

)

Cette section est très importante, car elle est un fourre-tout final. Pensez à une politique de pare-feu pour un moment. La plupart d'entre nous de créer une règle finale qui dit: «Si je n'avais pas expressément permis un modèle de trafic par le biais, le nier". En d'autres termes, si quelque chose d'inattendu se produit, c'est ainsi que 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. Tous les précédents "if" tenter de faire correspondre une chaîne de texte spécifique dans l'entrée du journal pour mettre en forme correctement. Cet article dit: «Si vous n'avez pas appariées et une entrée de journal imprimé spécifique encore, de l'imprimer dans une section intitulée« Entrées ** ** inégalée ". Cette étape est extrêmement important parce que sans elle nous ne verrons jamais entrées inattendues. Il est des entrées inattendues qui sont probablement les plus importants et les plus intéressants.

Résumé Exec

Les deux OSSEC et Logwatch sont d'excellents outils complémentaires. OSSEC excelle à vous avertir si un motif d'attaque connus a lieu. Logwatch est un outil formidable pour résumer une bonne partie du temps des journaux pour que les personnages peuvent effectivement donner un sens à ce qui se passe. En combinant les deux outils que vous pouvez créer une défense beaucoup plus robustes posture en profondeur. L'ensemble devient supérieure à la somme des parties.

La combinaison de Logwatch et OSSEC - Partie 3

17 février 2010 par Chris Pas de commentaires »

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

Installation Logwatch

Logwatch est assez facile à installer. En fait, il est installé par défaut sur de nombreuses distributions Linux si vous avez déjà 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 @] logwatch fubar logwatch #-v

Logwatch 7.3.6 (sortie 05/19/07)

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

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

Logwatch l'installation des RPM

Pour installer la version binaire du RPM, il suffit d'ouverture de session en tant que root et allez dans le répertoire où vous avez téléchargé le fichier RPM. Maintenant, exécutez la commande:

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

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

Installation à partir Logwatch Source

Installation de la source est la consommation d'un peu plus de temps. N'oubliez pas que pour installer le code source, vous devez déjà avoir un compilateur (comme gcc) installé sur votre système. Logon en tant que root et allez dans le répertoire où vous avez téléchargé l'archive tar. Pour extraire l'archive, lancez la commande:

xvzf logwatch tar-7.3.6.tar.gz

Vous verrez une structure de répertoire ci-dessous votre position actuelle sont créées et beaucoup de fichiers copiés en jeu. Nous devons maintenant passer à la répertoire racine qui a été créé:

cd logwatch-7.3.6

Pour Logwatch à courir, il ya un tas de répertoires qui doivent être créés sur votre système. Elles 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 permissions mal réglé de telle manière 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 de configuration de notre système:

. / Install_logwatch.sh

N'oubliez pas la période au début de la ligne.

Test Logwatch

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

| Logwatch moins

Vous verrez l'écran de votre terminal est-il vide, mais c'est normal. Vous finirez par voir un rapport Logwatch faire imprimer à l'écran que vous pouvez naviguer dans l'aide de la «Page Up» et «Page Down» clés. Comment journal qu'il faut pour que le rapport pour montrer à l'écran dépendra de la quantité d'informations journal a besoin d'obtenir analysé. Cela peut prendre quelques secondes ou quelques minutes. Quoi qu'il en soit, 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 le client d'installation / serveur, comme il est un peu plus complexe. Si vous effectuez une installation locale, sélectionnez simplement le "local" option lors de l'installation et passez 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 les communications entre le client et le serveur. Blowfish est symétrique basé clés, afin que les deux parties doivent savoir ce que la valeur de 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 sera demandé pour une valeur de clé de toute évidence, nous aurons besoin d'avoir à portée de main que 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 de l'agent est d'utiliser SSH. Créer une connexion sécurisée vers le serveur OSSEC, et extraire la clé appropriée (directions 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 le client d'installation vous invite à la valeur de clé, il vous suffit de 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 obtenir une copie de la dernière version de la page de téléchargement OSSEC . Vous devrez ensuite pour 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

N'oubliez pas 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 au besoin.
  • Confirmation de l'installation - Appuyez sur Entrée une fois que vous avez lu l'écran.
  • type d'installation - Tapez "serveur" sans les guillemets et appuyez sur Entrée.
  • Emplacement d'installation - Acceptez la valeur par défaut.
  • notification par e-mail - par défaut est oui, choisissez si vous voulez alertes e-mail. Si vous sélectionnez oui, vous serez invité à entrer une adresse e-mail valide et le serveur mail.
  • 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, car nous avons besoin de 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 de la défendre soi si une attaque est détectée directement.
  • Liste blanche - Cela vous permettra d'ajouter des adresses IP à partir de laquelle les attaques possibles seront ignorées. Soyez prudent avec cette option. Si vous n'avez pas accès à la console sur le serveur OSSEC, il pourrait être judicieux d'identifier une adresse IP qui peut toujours y entrer tout simplement à s'assurer de la source IP est un système fiable.
  • Activer Syslog - par défaut est oui. Sélectionnez cette option si vous voulez collecter des journaux 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 indique tous les fichiers journal local OSSEC suivra. Il est purement d'informations, de sorte que tous vous pouvez faire est appuyez sur Entrée pour passer au travers. Si vous remarquez un ou plusieurs fichiers journaux absents de la liste, vous pouvez les ajouter plus tard pour le fichier ossec.conf.

À ce stade OSSEC auront accès au compilateur local 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 / start-OSSEC de contrôle

Définition des agents OSSEC

Nous ne sommes pas faire avec le serveur OSSEC tout de suite. Ensuite, nous avons besoin de pré-définir tous les systèmes qui seront en cours d'exécution de l'agent OSSEC (client) de logiciels. Ceci est réalisé en utilisant la commande manage_agents. Première Cependant, nous devons faire un peu de devoirs. Faites une liste de tous les systèmes qui seront en cours d'exécution du logiciel 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 les points suivants de la ligne de commande:

/ Var / OSSEC / bin / manage_agents

Cela produira 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, suivi de l'adresse IP du système. Ne vous inquiétez pas de l'agent numéro d'identification. Il suffit d'accepter la valeur par défaut et sera auto-OSSEC attribuer le numéro d'identification suivant disponible. Une fois que vous confirmer l'information que vous avez entré, vous serez renvoyé au menu Gestionnaire principal agent. Répétez le processus ci-dessus pour chaque système qui fait tourner un agent OSSEC.

La génération de clés

Une fois que vous avez ajoutés dans l'ensemble de vos systèmes, il est temps pour générer des clés de chiffrement. Cette étape est également 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 touche "Extract pour un agent" option de 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 chaque numéro d'identification, de sorte qu'il devrait être trivial pour identifier celle qui vous voulez. Commencez avec le système que vous prévoyez d'installer le logiciel agent sur premier.

Agent OSSEC installer sur Linux

Lors de l'installation du logiciel agent sur un client Linux ou UNIX, vous utilisez l'exacte même boule de goudron, nous avons utilisé pour installer le logiciel serveur. Exécutez le même script d'installation, mais cette fois lorsque vous êtes invité pour le type d'installation que vous souhaitez effectuer, le type de «agent» suivie de la touche Entrée.

L'installation du client a souvent les mêmes que les invites d'installation du serveur. Utilisez les informations ci-dessus pour vous guider dans le processus. L'invite qui variera toutefois, c'est que vous serez invité à fournir l'adresse IP du serveur OSSEC. Une fois terminé, OSSEC auront accès au compilateur local 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 agent, exécutez la commande:

/ Var / OSSEC / bin / manage_agents

Lorsque le menu 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 Agent Manager. Sélectionnez "q" pour revenir à la ligne de commande.

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

/ Var / OSSEC / bin / start-OSSEC de contrôle

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

Agent OSSEC installer 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 OSSEC Agent Manager apparaît.

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

Ensuite, sélectionnez "Gérer" dans le menu OSSEC Agent Manager, suivi de "OSSEC Start". Vous devriez maintenant voir le statut ":" Le changement indicateur "En cours ...".

Test OSSEC

Une fois que vous avez le serveur et logiciel de l'agent installé, a commencé et les touches appropriées configuré, 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 des erreurs. Une erreur fréquente est que OSSEC rapports on ne peut pas envoyer un e-mail. 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. Déplacer vers le bas pour les 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 à ce qui suit:

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

Règle: 501 (niveau 3) - Nouvel agent OSSEC> 'connecté.

Src IP: (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 agent.

D'autres à venir

Ouf! C'est plus que suffisant pour un poste! Dans mon prochain article je vais vous mettre à profit pour analyser Logwatch toutes les informations d'alerte générés par OSSEC.

La combinaison de Logwatch et OSSEC - Partie 2

16 février 2010 par Chris Pas de commentaires »

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

Qu'est-ce que OSSEC?

OSSEC , abréviation de «Open Source de sécurité», est un hôte basé le système de détection d'intrusion (HIDS). En d'autres termes, il est conçu pour détecter les attaques ou les violations des politiques 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 de prévention d'intrusion basés sur l'hôte), il comprend un large éventail d'outils qui peuvent vous aider à identifier une intrusion quand il se produit, ainsi que dans la mesure des dommages qui ont été causés.

Plates-formes supportées

Pour profiter de toutes les fonctionnalités OSSEC a à offrir, vous devez lancer un agent sur le système protégé. agents OSSEC peut fonctionner sur Windows, Mac OS X, Linux, et un large éventail de systèmes UNIX. Si vous souhaitez tout simplement dans la partie analyse de log Toutefois, un éventail encore plus large des systèmes peuvent être pris en charge. Cela comprend le matériel 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. Le client d'installation du serveur / vous permet d'exécuter un environnement distribué la protection des systèmes multiples en même temps. Bien que la plupart des déploiements sont client / serveur, si vous voulez donner un spin OSSEC vous pouvez facilement tout faire sur un système de test unique à l'aide d'une installation locale.

Log Analysis

OSSEC comprend un journal basé Intrusion Detection System (paupières). Cela a la possibilité de consulter les fichiers journaux en temps quasi réel, tout en les examinant de schémas d'attaque connus. Quand un journal est généré sur un système protégé, l'agent se charge de transmettre en toute sécurité le journal (Cryptage Blowfish avec un secret pré-partagé) sur le serveur. Le serveur se charge alors d'exécuter l'analyse.

La plupart des outils d'analyse de log processus de leurs règles dans un format linéaire. J'entends par là que si nous avons 500 règles, la règle on est cochée, l'article deux, puis la règle de trois et ainsi de suite jusqu'à ce qu'une correspondance est trouvée ou nous arrivons à la fin de la règle fixée. OSSEC fonctionne un peu différemment car il met en œuvre une hiératique structure aux règles. Les entrées du journal sont d'abord classées et ensuite vérifié que l'encontre des règles selon celles qui sont appropriées. Le résultat est que plutôt que de devoir traiter l'ensemble des 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 la règle fixée.

Vérification de l'intégrité

OSSEC inclut un outil appelé SysCheck pour effectuer la vérification d'intégrité de fichier et répertoire. Si vous exécutez un agent de Windows, vous pouvez également inclure des touches spécifiques dans le Registre Windows pour être contrôlés. les modifications de fichier peuvent être détectées en utilisant les deux MD-5 et des algorithmes de hachage SHA-1. Le système est extrêmement personnalisable. Vous pouvez inclure ou exclure des fichiers uniques, ou des structures de répertoire. Vous pouvez même définir un indicateur pour détecter la création d'un nouveau fichier.

Le logiciel de l'agent est conçu pour utiliser une quantité minimale du processeur au cours de la vérification de l'intégrité. Même si cela signifie le contrôle prendra plus de temps, il contribue également à minimiser la performance atteint dans le système. Hash information est transmise au serveur. Le serveur se charge alors d'effectuer la comparaison de hachage pour voir si 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 politique sont faites sur l'agent, ils peuvent être détectés et signalés ainsi.

détection des anomalies

OSSEC va bien au-delà journal de contrôle pour vérifier l'intégrité du système. les politiques d'utilisation peut être gérée de façon centralisée à partir du serveur, puis repoussé aux agents appropriés. Par exemple vous pouvez définir une politique concernant les applications Windows qui sont acceptables (Office, Firefox, etc) et ceux 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 tables de hachage NT sont utilisés pour mot de passe stocké mais pas hachages LanMan.

OSSEC comprend un certain nombre de goodies d'autres 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 se produit. Par exemple vous pourriez avoir l'agent Linux exécuter le "df" commande à intervalles réguliers et générer une alerte si l'utilisation du disque dépasse 90%. Un exemple Windows peut être d'avoir OSSEC générer une alerte chaque fois que des informations de fichier est écrit dans le flux de données différents domaine de NTFS.

Active Response

Enfin, OSSEC comprend la capacité de réagir lorsque l'activité suspecte est détectée. Les réponses peuvent être générés par le serveur ou l'agent, qui jamais vous spécifiez. Les réponses peuvent être aussi bénignes que générer une alerte e-mail, d'être aussi dynamique que le blocage d'une adresse IP distante pour un temps limité. Il ya un certain nombre de scripts inclus réponse active, vous pouvez dessiner, ou vous pouvez facilement écrire votre propre.

Secure Architecture

Les auteurs ont OSSEC ménagé aucun effort pour assurer l'ensemble des composants dans le produit. Des tâches comme le contrôle d'intégrité sont effectués sur le serveur, plutôt que l'agent, de sorte que la fiabilité des hachages ne peut être compromise lors d'une attaque. Les processus sont exécutés avec le plus bas niveau d'autorisation possible, et différents comptes sont utilisés pour faire fonctionner chaque composant OSSEC. Cela signifie qu'un compromis d'une seule demande dans OSSEC ne sera pas immédiatement conduire à un compromis de l'ensemble du paquet. En outre, la plupart des composants sont exécutés dans un prison chroot de sorte que leur accès au système est encore plus restreinte.

Un dernier mot

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

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

D'autres à venir

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

La combinaison de Logwatch et OSSEC

15 février 2010 par Chris Pas de commentaires »

I recently had a student ask me a question regarding the integration of Logwatch with OSSEC. I felt like this was a complex and yet cool enough idea that it warranted a series of posts to cover it in full. So over the next few days I'll talk about each of these tools, how to integrate them together, as well as what additional security visibility can be gained once the process is complete.

What Is Logwatch?

Logwatch is an excellent open source tool for generating daily human readable log reports. Log entries tend to fall into one of three categories:

  • Stuff you know is evil
  • Stuff you know is normal and can be safely ignored
  • Everything else

It is that “everything else” category where Logwatch really shines. For the stuff we know is evil, we will setup some form of alerting system. For example we may write an alert signature that warns the security analyst when an account is being brute forced. But what about the attacks we don't know about or are not sure what they look like? This would be a clear example of that “everything else” category. The traffic is not normal, but we have not seen it before to have a signature waiting to generate an alert. Since we will be unable to catch the attack in real time, we will need to catch it during a daily log review.

Of course the problem with doing daily log reviews is that it is tedious and time consuming. I mean let's be honest, who really wants to spend their day reviewing one million plus log entries? Even if you did, are you sure you would actually catch the out of the ordinary traffic?

Comment ça marche?

What Logwatch does very well is permit you to reorganize your data into a format that is easier for humans to follow. Its real strength is that it permits you to move the stuff you understand out of the way (normal or evil), so that the unexpected log entries stand out like a sore thumb. In other words, Logwatch lets you summarize your log entries so the unusual stuff is easier to spot.

What I really love about Logwatch is that you don't lose anything. Many log review tools will only show you the stuff that has been pre-defined as being evil. The problem they all share is that when something evil but unexpected happens, it flies right under the wire. Because Logwatch lets you see everything, you no longer miss the unexpected.

Logwatch In Action

Lets discuss how Logwatch works using the SSH server service as an example. The scripts to deal with SSH have already been defined within Logwatch, so you do not need to do any tweaking to receive the features we are going to discuss.

When reviewing a log file, the first thing Logwatch does is reorganize log entries based on their message types. For example all Successful SSH logons are grouped together, as well as too many logon failures, refused connections, locked accounts, accounts without a proper shell, protocol mis-matches, etc. etc. etc. Once all the SSH messages are grouped by their type, the data is then summarized to reduce the amount of information being reported.

For example, the default is to summarize failed logon attempts by account and source IP. So a typical failed logon report section might look like this:

Failed logins from these:

bsmith/password from 1.2.3.4: 637 time(s)

jsmith/password from 1.2.3.5: 2 time(s)

So rather than having to review 639 log entries reporting a bad logon attempt, we have all the pertinent information summarized into three lines (if you include the title). Continue this process for all of the other SSH messages, and we have dramatically reduced the amount of time required to review our logs.

But what if something happens that Logwatch is not pre-programmed to recognize? When an unexpected log entry is found, Logwatch adds a section to the end of the service report called “Unmatched Entries”. So if we see this title in the SSH server section, we know some event has occurred that is either abnormal or unexpected for the SSH service. This could very well be some form of attack that we are not aware is making the rounds.

By focusing in on the unmatched entries section, we can quickly identify unexpected activity. As I stated earlier, this is really the main goal of doing daily log reviews. To find the stuff we don't expect which will sneak past our alerting system. Logwatch makes this process as quick and as painless as possible.

Feature Summary

In the above example I talked about doing daily log reviews, but to be honest Logwatch is highly customizable. You can specify any range you wish to use down to an interval of one second. For example let's say I'm investigating an intrusion rather than performing a daily log review. I could specify a range such as “2010/02/14 17:05:00 for that hour” to focus right in on the information that interest me. I can also focus in on one specific log file or service.

The detail level of the report is also customizable. Typically when you deal with security you get in the habit of always wanting the highest detail level of reporting. To be honest, with Logwatch a high level of detail is probably more than you will ever need. Personally I typically stick with “med” for medium and that works out nicely. You can also specify the reporting level as “low” or “high” or use a numeric range of 0-10 for a higher level of granularity (low =0, med=5, high=10).

Logwatch can be run automatically or as a manual process. Typically you will want to set it up to run automatically each day and summarize one day's worth of log entries. If you ever need to expand or focus the report, you can always run Logwatch from the command line while specifying exactly what you want to see. You can then use the “–save” option to specify a report name and directory location for storage.

D'autres à venir

The above should give you a good idea as to the features Logwatch can bring to the table. In the next post I'll discuss OSSEC in the same level of detail. After that, I'll get into how to install each tool as well as how to integrate them together.

Jour 2 Keynote

January 12th, 2010 by Chris No comments »

Merci à tous ceux qui venaient sur le chiffrement / DLP sommet. Voici les diapositives de mon ouverture sur 2 jours.

cryptage-DLP-liminaire