Ist Rentabilität Kill Innovation?

2. September 2010 von Chris Keine Kommentare »

Paul Graham hat einen ausgezeichneten Beitrag auf , warum Yahoo pleite ging . Der vollständige Artikel wert ist zu lesen, aber hier sind zwei Zitate Wahl:

Ich erinnere mich erzählt David Filo Ende 1998 oder Anfang 1999, dass Yahoo Google kaufen sollte, weil ich und die meisten anderen Programmierern in der Firma waren Sie es anstelle von Yahoo für die Suche zur Verfügung. Er erzählte mir, dass es nicht der Mühe wert. Suchen war nur 6% unseres Verkehrs, und wir waren Monate wächst um 10% ein. Es war nicht wert, besser zu machen.

Und später Paul fährt fort:

Wenn die Umstände anders gewesen wären, die Menschen mit Yahoo könnte die früher erkannt haben, wie wichtig Suche war. Aber sie hatten die meisten undurchsichtigen Hindernis in der Welt zwischen ihnen und der Wahrheit: das Geld. Solange Kunden wurden schriftlich großen Schecks für Bannerwerbung, war es schwer, ernst zu nehmen suchen. Google nicht haben, dass sie abzulenken.

Erstens Haftungsausschluss: Die Stellungnahmen Ich freue mich über ausdrücken, sind meine eigenen. Sie stellen keine, oder keine Assoziation mit einer Organisation mit denen ich gearbeitet habe in der Vergangenheit, Gegenwart oder Zukunft. Wenn Sie einen Mangel an Innovation innerhalb Ihrer Organisation zu sehen, weiß, ich habe Arbeit für dich getan, und denke, diese Meinungen über Ihre Organisation, kann ich Ihnen versichern, sind sie nicht. Sie sind Beobachtungen über eine ganz andere Organisation.

Paul's Artikel wirklich getroffen Heimat für mich. Denken wir zurück über die Jahre hinweg habe ich verbrachte Beratung für verschiedene Organisationen, bemerkte ich ein unverwechselbares Muster. Der Internet-Raum ist mit Firmen, die ein paar coole Innovation übersät war, machte Eingriffe in ihre Marktanteile, verlor dann aber ihren Weg in Ausübung der höhere Gewinne. Man könnte es innerhalb der Organisation der internen Kultur sowie ihre Front nach Interaktion mit dem Publikum. Sobald der Fokus auf der langfristigen technologischen Entwicklung auf kurzfristige Rentabilität änderte, begann die Organisation einer Abwärtsspirale.

Wahrscheinlich eines der frühesten Beispiele für die meisten öffentlichen war Lotus . Für die Leute mit so viel graue Haare als ich, Sie erinnern sich wahrscheinlich, dass Programme wie 1-2-3 und nimmt den PC auf die Karte gesetzt, als die Wahl der Business-Klasse-System. In den frühen 90er Jahren lief jeder Lotus Software. Für diese Zeit in der Geschichte war es extrem innovativ und funktional. Es gab eine Reihe von Jahren, in denen buchstäblich jeder Firma für die ich arbeite tat, hatte einen großen Einsatz von Lotus Software.

Dann etwa Mitte der 90er Jahre alles verändert. Neue Versionen Bugs behoben, anstatt schob die Technologie voran. Eine drakonische Kopierschutz-System wurde implementiert. Die Kosten für Telefon-Support und Patches ging durch das Dach. Ich erinnere mich genau in dem Moment beschloss ich, ich würde das tun, was immer ich konnte, um weg von Lotus Software zu erhalten. Ich war zu halten, sitzen für cc: Mail-Support (den Datenspeicher beschädigt hatte sich wieder) und realisiert sie hatten eine Scheibe Jockey angeheuert, um Musik abzuspielen und zu verkünden Warteschlange Wartezeiten (in der Regel 30-60 Minuten). Dieser sagte mir, dass sie hatten Lotus Support-Problemen wusste, aber anstatt an der Wurzel verursachen sie die günstige Möglichkeit holte und ein Entertainer engagiert. Zwar bin ich mir sicher das ihre kurzfristige Profitabilität erhöht, schickte es Leute wie mich läuft in die Microsoft Camp.

Natürlich Flegel war nicht der letzte. Wir selbst sahen in Microsoft sprunghaft wachsen, bis sich der Schwerpunkt von Innovation verändert um den Schutz und die Vermarktung Slicks zu kopieren. SCO verändert ihr Geschäftsmodell davon entfernt, ein SMB-Lösung zu sein litigators und rutschte schnell in Vergessenheit. Wir können sogar sehen, es wieder mit Oracle. Einige behaupten, dass Oracle Sun erworbene nicht zu übermitteln ihre Innovation, sondern gezielt zu prozessieren gegen Google . Schwer zu argumentieren, diesen Punkt als von außen scheint es, dass die einzige andere Sache, die sie töten, ist getan haben mit Sun OpenSolaris , damit das Abschneiden einer Fülle von Innovationen Programmierern zur Verfügung gestellt von außen.

In Paul's Artikel er tadelt die Ursache nicht auf Yahoo, die besten Programmierer. Nach meiner Erfahrung das Problem geht tiefer. Wenn ein Unternehmen tritt dieses selbstzerstörerische Phase konzentrieren sie sich weniger auf die Einstellung von Innovatoren (wie Programmierer) und mehr auf die Anmietung Erbsenzähler. Der Fokus wechselt von der Förderung neuer Ideen zu verdrängen jeden letzten Pfennig für einen kurzfristigen Gewinn. Die ersten Anzeichen sind normalerweise absurde politische Veränderungen. Cubes können nur in einigen Ausstecher Mode gestaltet werden, Ingenieure müssen ihre eigenen Papierkorb leeren, verbringen Sie mehr aus Ihrem Tag Rechnungslegung für unsere Zeit, anstatt wirklich etwas zu erreichen, etc. etc.

Während ich bin sicher, einige Buchhalter kann auf eine ziemlich Balkendiagramm, dass diese Art von politischen Veränderungen die Rentabilität steigern und sie ein sehr wichtiger Punkt vermisse zeigen. Die Änderungen schaffen eine Umgebung, die schädlich für innovatives Denken ist. Die Verlagerung der Kultur, sondern alle garantiert, dass innovative Ideen sind zum Scheitern verurteilt, und innovative Denker sind nun zur anderen Möglichkeiten zu bewegen. Paul's Interaktion mit Yahoo ist ein hervorragendes Beispiel. Betrachten Sie es als Synonym für Investitionen in Lebensmitteln im Supermarkt. Einkaufsführer billige Lebensmittel wird die Rentabilität führen kurzfristig, aber langfristig wird es wahrscheinlich drastisch erhöhen Sie Ihre Kosten im Gesundheitswesen . Wenn Sie zählen Groschen ist es leicht, aus den Augen verlieren, das langfristige Ziel (wie ein langes gesundes Leben).

Also das Problem ist ein großes Geschäft? Ist das Mantra, dass nur kleine Hunger Unternehmen innovieren können, während große Unternehmen prädestiniert zum Scheitern verurteilt sind? Persönlich glaube ich nicht, das ist wahr. Ich habe große Unternehmen, die intelligent genug, um zu erstellen internen Think-Tanks zur Förderung von Innovation gesehen werden. Die Mechanismen sind vorhanden, so dass neue Ideen zu bekommen schwamm nach oben und Misserfolg wird nicht mit Beendigung synonym gesetzt. Während Profitabilität ist immer noch wichtig (und IMHO sollte es sein), kreative Potenzial in Gefahr Technologie Vertikalen einnehmen vom oberen Management unterstützt. Ein gutes Beispiel hierfür ist wohl Apple. Umzug vom Computer bis zum Handy war eine große Veränderung in ihrer vertikalen Markt, aber es hat sich gelohnt in Pik.

Am Ende, denke ich, es kommt wirklich auf die Unternehmenskultur. Was tötet eines Unternehmens ist nicht seine Größe, sondern seine Fähigkeit, langfristig zu fördern, anstatt kurzfristigen Denkens. Schnelle Plausibilitätsprüfung, wenn Sie Ihre Organisation die Einstellung von mehr als Erbsenzähler Innovatoren bemerken, kann man bereits auf der Abwärtsspirale werden.


VMware Fast Path Versus langsamen Weg Firewalls

30. August 2010 von Chris Keine Kommentare »

Viele von uns sind jetzt die Arbeit mit virtuellen Firewalls. Ich habe einen früheren Beitrag über die Stärken und Schwächen der Sicherheit innerhalb der virtuellen Welt , aber heute möchte ich VMware sprechen über die Möglichkeiten mit Firewall. Es hat ein neues wurden eine Menge Aufregung in Bezug auf die relativ VMware VMsafe API . Insbesondere ist jeder Scrambling zu erstellen / deploy schnelle Weg Firewalls. Aber sind alle schnell weg Implementierungen gleich geschaffen? Gibt es Sicherheitsprobleme mit dem Gehen mit einer schnellen Weg Lösung? Let's eintauchen und sehen.

Aufschlüsselung der VMsafe

Mit der Freigabe der Sicherheit VMsafe API, hat VMware verbessert die Möglichkeiten für die Durchführung von Sicherheitsmaßnahmen in einer Umgebung von vSphere ermöglicht Anbietern, um direkt in das Plug-Hypervisor auf Ring 0. VMsafe besteht aus drei Komponenten:

  • VdDK - Disk Block Inspektion. API wurde öffentlich freigegeben.
  • vCompute - CPU und Speicher-API. Hat nicht veröffentlicht worden. Unbekannt zu denen Dritte Zugang haben, wenn überhaupt.
  • vNetwork - API zur Überwachung / zwischen den vNIC und vSwitch Filter. Hat nicht veröffentlicht worden. Um das Beste aus meinem Wissen, nur Altor Networks & Reflex Systems Zugriff haben (zwei Anbieter, die API unterstützt bei der Entwicklung der).

Insbesondere möchte ich auf die vNetwork API sprechen. Bei der Steuerung des Verkehrsflusses Netzwerk innerhalb eines ESX-Host, gibt es zwei mögliche Umsetzung "langsamen Weg" und "schnellen Weg".

Langsamen Weg

Slow-Pfad ist der einfachste Implementierung und die, die wir seit Jahren mit. Effektiv ist dies nur ein VM-Gast, ähnlich wie bei jeder anderen VM-Gast läuft auf dem ESX-Host. Normalerweise ist jeder Gast ein einzigartiges vSwitch verbunden, und jedes dieser vSwitches ist eine einzigartige vNIC auf der Firewall verbunden. Dies ist vergleichbar mit einem Legacy-Firewall-Setup, sondern praktisch umgesetzt. Der Vorteil der Ausführung in langsamen Weg ist, dass man eine volle Schlag ausführen OS mit allen Bibliotheken oder Dienstleistungen benötigt, um die Firewall zu unterstützen.

Fast Path

Schneller Weg ist tatsächlich ein Ring 0 Treiber, die direkt an den Hypervisor-Kernel. Dies ermöglicht ein Drittanbieter zu nutzen, den Hypervisor zum Einbau zwischen den einzelnen vNIC / vSwitch Verbindung. Da eine schnelle Weg Treiber im Kernel-Kontext ausgeführt wird, fügt es minimalem Aufwand in das System. Das Ergebnis ist die Codeausführung innerhalb schnelle Weg ist wesentlich schneller als der gleiche Code innerhalb langsamen Weg ausgeführt (also die VMware Namenskonvention für jeden Kontext). Legen Sie auf dem ESX-Host wird minimiert, so dass das Endergebnis ist, können Sie weit mehr virtuellen Gäste laufen.

Fast Vs Slow

So klingt es wie Sie wollen würde, alles zu tun innerhalb schnelle Weg, aber es gibt eine Reihe von Fragen. Schneller Weg ist ein Kernel-Treiber Einstecken in eine minimierte Hypervisor, nicht eine vollständige Schlag Betriebssystem. Dies schränkt die Bibliotheken und die Firewall-Dienste zur Verfügung hat für die Steuerung des Verkehrsflusses. Darüber hinaus sind wir in der Kernel-Treiber Einstecken so muss es versichert, dass es nicht funktioniert aufblasen den Hypervisor werden, erhöhen die Angriffsfläche stört, oder mit anderen Hypervisor-Funktionen. VMware führt einen Code-Review auf allen Fahrern schnelle Weg vor der Veröffentlichung. Wenn ich also theoretisch könnten alle meine umzusetzen Code in schnellen Weg, würde ich VMware Genehmigung vor jedem Patch oder Feature Release brauchen.

In diesem Sinne, ein Hersteller behauptet "schnellen Weg" zu unterstützen ist eigentlich zu Ende gehen bis zur Durchführung einen Teil ihres Codes als schneller Weg, einen Teil so langsam weg, und erstellen Sie dann ein Verbindungsstück zwischen den beiden. Wie viel Last auf dem System platziert wird, wie viel von diesem Code wird in schnelle Weg umgesetzt und wie viel davon abhängen wird in langsamen Weg ausgeführt.

Mögliche Fast Path-Bereitstellungen

Zum Beispiel könnte ein Anbieter zu wählen, um einen schnellen Weg-Treiber zu schreiben, dass einfach alle Pakete Tunnel wieder zu einem langsamen Weg umgesetzt Firewall. Der langsame Weg Code ermittelt dann, wenn der Verkehr sollte weitergegeben oder fallen gelassen werden, mit übergebenen Pakete, zurück zu der schnelle Weg-Code zum Einfügen in die Hypervisor-Kontroll-Kanal gesendet. Während dies die einfachste Methode der Bereitstellung von schnellen Weg sein würde, und wohl auch der sicherste, wäre dies die am wenigsten Leistungsvorteile. System laden würde wahrscheinlich nicht viel besser als eine vollständige Umsetzung langsamen Weg. Ich sehe diese Option als sehr attraktiv für Legacy-Firewall-Anbieter, da es die geringste Änderung ihrer bestehenden Code erfordern würden, während noch in der Lage zu behaupten, "schnelle Weg zu unterstützen."

Eine andere Möglichkeit wäre, den langsamen Weg Raum für administrative Funktionen mit der schnelle Weg Treiber als die Firewall-Engine verwenden. So zum Beispiel die Firewall-Administrator würde die Politik über eine Schnittstelle auf einem langsamen Weg VM, die dann drücken Sie die Politik auf eine schnelle Weg Treiber. In diesem Setup der schnelle Weg Fahrer hat eine Kopie der Police so Flugsicherung sofort umgesetzt werden können. Das Ergebnis ist eine schnellere Bearbeitung Verkehr mit minimaler Systembelastung. Die Trade-off ist sperriger Code in Ring 0.

Es ist auch möglich, ein Gemisch der beiden umzusetzen. Zum Beispiel habe ich der schnelle Weg Treiber verwenden könnten, um die Firewall-Richtlinie umzusetzen, aber dann gehen alle "angenommen" Pakete wieder zu dem langsamen Weg-System für die Überprüfung Intrusion, Viren-Scanning, oder was auch immer notwendig ist. Acceptable Pakete werden dann zurückgezahlt der schnelle Weg Treiber für Einfügung. Also in diesem Setup alle "fallengelassen"-Pakete werden über schnelle Weg abgewickelt, während akzeptiert Pakete mit einem langsamen Weg Komponente interagieren.

Als Seite beachten, müssen Sie die oben genannten Informationen im Hinterkopf behalten, wenn unter Berücksichtigung aller vNetwork Implementierungen, nicht nur Firewalls. Die vNetwork API kann auch für die politische Durchsetzung, QoS, die Sammlung von Netzwerk-Statistiken, etc. Zum Beispiel das erste vNetwork Umsetzung war eigentlich VMWare's Lab Manager verwendet werden. Dieses Tool ist für Self-Service Provisioning verwendet und enthält nicht eine Firewall-Komponente (dies ist über VShield implementiert).

Zusammenfassung

Während ein VMware Produkt, das mit VMsafe kann streng eine "langsame Weg sein" Umsetzung, ist es höchst unwahrscheinlich, dass ein Produkt allein betrachtet werden können für einen "schnellen Weg" Umsetzung integriert. Jede schnelle Weg Produkt ist am ehesten zu einer hybriden werden. Es ist nur eine Frage davon, wie viel Code existiert in der "schnellen Weg" Raum gegenüber dem "langsamen Weg" Raum. Wenn ein Produkt schnelle Weg zu unterstützen Forderungen, müssen Sie ein bisschen tiefer graben, um die Umsetzung zu analysieren, um eine wirkliche Performance-Vorteile zu identifizieren.

Die Comcast Scam

25. August 2010 von Chris Keine Kommentare »

Völlig unabhängig von der Sicherheit, war aber überrascht, wenn das passiert mir so, ich würde hinauswerfen einem Heads-up gedacht.

Wenn Sie Ihre Kreditkarte oder Hypothek zu bezahlen, gibt es Gesetze in Kraft zu (versuchen) halten die Gläubiger aus Fugenhobeln Sie. Zum Beispiel, wenn Sie eine Zahlung per Kreditkarte zu machen, muss der Gläubiger auf, dass die Zahlung auf die älteste Kauf gelten. Wenn sie nicht, könnten sie leicht whack Sie mit höheren Zinsen und Strafen nur auszahlen bisherigen Einkäufe. Das Gesetz soll bis zu einem gewissen Maß an Verbraucherschutz bieten.

Offenbar die gleichen Regeln gelten nicht für Comcast gelten. Bereits im Juni ging ich in das lokale Büro Comcast und hob zwei neue Kabel-Boxen. Diese machte es auf meine Rechnung Juni, die ich komplett verpasst wegen zu reisen. Ich habe meine Bank Setup, um auto-Zahlungen zu leisten, aber der Juni-auto-Zahlung Endes als 18 $ kurz. Wechseln zu Juli und ich hatte das gleiche Problem. Haben Sie nicht auf die Rechnung schauen und lassen Sie auto-zahle seine Sache. Aber jetzt ist es nicht nur 18 $ Kurz gesagt, ist es $ 18 plus Gebühren und Sanktionen.

So hier sind wir im August. Weniger als 30 Tage seit ich zuletzt ein Zahlungs-und Comcast getötet meinem Dienst. Telefon, TV und Internet alle offline. Wenn ich, um herauszufinden, das Problem genannt wurde, war ich mein Konto sagte betrug 60 Tage überfällig. Nach dem Gespräch mit drei verschiedenen Leuten, die ich gesagt, dass Comcast keine solche Forderung, die Zahlungen an älteste Schulden gelten hat, war. Während also meine Rechnung Juli wurde als aktuelle, war mein bill Juni als 60 Tage überfällig. So die Unterbrechung des Dienstes, sowie mehrere Gebühren zu begradigen, während die Sache aus. Wenn Comcast nach den gleichen Standards wie die meisten Gläubiger gehalten wurde, würde ich noch schulden ihnen 18 $. Weil sie nicht, sind mit ihrer Tarifstruktur verdanke ich jetzt 47 $ und diese Zahl ist weiter im Steigen begriffen (anscheinend ihre Tivo-Dienst kann nicht zurückgedreht werden, ohne einen Service-Tech).

Postmortem

  • Bundling Home Services können Geld sparen, sondern sorgt für eine böse single point of failure
  • Seien Sie vorsichtig mit einem Bank-basierte Auto-zahlen für Rechnungen, die variieren können
  • Comcast Tarifstruktur erlaubt ihnen, eine jährliche Rendite von 967% verdienen, wenn man so viel wie $ 1 überfällig und verpassen sie den folgenden Monat werden

Ist das Blatt drehen?

3. Juni 2010 von Chris Keine Kommentare »

Ich habe seit Jahren sagen, dass Anti-Virus nicht mehr wirksam ist und dass eine gute Sicherheitslage muss Anwendung Whitelisting gehören. Hier ist ein cooles Zitat von George Kurtz, Chief Technology Officer bei McAfee:

"Man kann nicht einfach auf Antiviren-Software angewiesen - und wir sind ein Anti-Unternehmen. Und Firewalls allein nicht ausreichenden Schutz ", sagte er.

Antivirus, Firewalls und Intrusion Detection sind ein Anfang. Aber "weißen Liste" bietet eine stärkere Verteidigung. Das ist im Wesentlichen Verriegelung Computern nach unten, so dass nur vertrauenswürdige Programme ausgeführt werden dürfen. Nichts kann geändert oder ergänzt oder aktualisiert werden, außer durch einen Systemadministrator.

McAfee glaubt, "das ist, wo die Zukunft geht", sagte Kurtz.

Link to full story

Modisch spät, um die Partei, aber ich werde es dauern. ;-)

Sind virtualisierten Systemen mehr oder weniger sicher?

18. Mai 2010 von Chris Keine Kommentare »

Ich habe die obige Frage gebeten hatte genug Zeit, dass ich es verdient einen Blog-Post zu spüren. Während vor ein paar Jahren die Antwort gewesen sein mag "weniger sicher", ist heute die Antwort "beides". Ich weiß, dass klingt wie Chris unverbindliche, aber diese Antwort wirklich am genauesten beschreibt den aktuellen Stand der Technik.

Virtualisierung Changes Everything

Ich habe ein paar Leute bemerken, dass Virtualisierung über die Branche Auswirkungen der gleichen Weise, dass das Internet in den 90er Jahren hat zu hören ist. Um ehrlich zu sein, ich glaube, es ist Verdienst in dieser Stellungnahme. In den frühen 90er Jahren die meisten Leute liefen IPX, AppleTalk, NETBUI und eine Fülle von anderen Protokollen über geschlossene Netze. Bis Ende der 90er Jahre waren die meisten Leute laufen ausschließlich mit IP-Konnektivität, um die ganze Welt. Die Art und Weise haben wir Unternehmen, sowie die Art, wie wir Applied Security, völlig verändert, dass mehr als 10 Jahren. Sowohl die Netzwerk-Administration und Sicherheit Fertigkeiten, die Schnittkante im Jahr 1990 waren alle aber nutzlos bis 1999.

Virtualisierung beginnt, Rampe bis zu den gleichen Auswirkungen auf die Branche haben. Virtualisierung erfordert den Einsatz einer kompletten Überdenken, wie Sicherheit gelten. Zurück in den 1990er Jahren, Admins, die einfach in das Internet angeschlossen, ohne Rücksicht auf, wie dies ihr Netz auswirken, bekam große Zeit verbrannt. Wir stehen Schlange, um ein ähnliches Ergebnis zu sehen, wie Leute treffen Virtualisierung.

Was macht weniger sichere Virtualisierung

Die Achillesferse der Virtualisierung ist in der Software selbst ist. Wir hoffen, wir können die Software, um Gast-Systeme von einander entfernt zu halten Vertrauen, als auch die Host-und / oder Hypervisor. Es gibt zwei große Probleme mit dieser Erwartung:

  1. Keine Software ist fehlerfrei
  2. Software kann falsch konfiguriert sein

Ein paar Jahre zurück Core Research zeigte sie konnten OS ausbrechen und ein Gast die volle Kontrolle des Rechners . Während ein Hypervisor soll Expositionsgrenzwert diese Art von, haben wir sicherlich auch gesehen Fällen, in denen der Hypervisor umgangen wurde . Wir haben sogar Fälle gesehen wurden Software wird nur bei nutzbaren Umgebung laufen in einer virtualisierten . Diese Links zeigen einen kleinen Querschnitt der Virtualisierung Probleme, die in den letzten Jahren entdeckt worden sind. Google kann Ihnen eine komplette Liste, wenn Sie daran interessiert sind.

So ein umsichtiger professionelle Sicherheit geht vorsichtig zu sein, der blind vertrauenden Software sicher zu sein. Das Problem ist Anbieter nicht immer die gleiche Vorgehensweise. Take VMware mit ihren ESX (bald werden ESXi) Produkt als ein Beispiel. Viele von uns waren verblüfft, wenn ein Vertreter VMware CanSecWest kündigte an, dass es theoretisch unmöglich, den Angriff Hypervisor ESX . Wenn wir einfach annehmen, was ist unzerbrechlich, jemand mehr kreative wird herausfinden, einen Weg zu durchschlagen .

Einer meiner größten Sorgen mit ESX / ESXi ist, dass VMware hat es entworfen werden modular (via VMsafe ). Auf der positiven Seite bedeutet dies, dass außerhalb Anbieter können Produkte zu schaffen zur Verbesserung der Hypervisor-Funktionalität und Sicherheit. Auf der Kehrseite dieser dramatisch erhöht die Chancen schlecht Code eingeführt, welche die Sicherheit gefährden können.

Wir haben gesehen. Ein großartiges Beispiel für das in der Vergangenheit Marcus Ranum erstellt der Gauntlet Firewall, die damals eine der sichersten und Kick Butt Sicherheitseinrichtungen zur Verfügung. Bei drei Buchstaben Agenturen die beste Sicherheit wollte, wandten sie sich an Gauntlet. Marcus verkauft zu Gauntlet Network Associates (McAfee später), die sofort gestartet indem in Funktionen. Es war nicht lange vor stetige Reihe von Schwachstellen wurden entdeckt, die jeweils "eingeführt, die durch diese neuen" Features. Von dort aus, verlor das Produkt die Sicherheit cred und rutschte von dem Radar.

Nun ist es sicherlich möglich, neue Features und die Dinge fügen sichern. Die FreeBSD- Leute sind ein hervorragendes Beispiel, wie man richtig tun. Zur Gewährleistung der Sicherheit sie ein sehr strengen Prüfprozess . Ist es perfekt? Absolut nicht, aber ihre Auditing-Prozess hat die Messlatte für sichere Software-Anwendung eingesetzt werden. Mit etwas Glück wird VMware keine vergleichbaren, aber ich habe keine Summen über dieses nicht der Fall gehört.

Getting Your Head Straight

OK, so können wir nicht blind vertrauen Virtualisierungssoftware Angreifer in Schach zu halten. Wir können aber noch Vorsichtsmaßnahmen treffen, um die Auswirkungen zu minimieren, wenn das Schlimmste nicht eintreten. Einer der größten Schritte können Sie sich genau überlegen, welche Server gehostet bekommen, und welche anderen Gast-Systeme dürfen auf dem gleichen Feld laufen. Die Sicherheitszone Konzept von Architekten-Netzwerk verwendet wird, so wie hier anwendbar.

Eine Sicherheitszone ist einfach eine Sammlung von Systemen, die die gleiche relative Risiko zu teilen. Zum Beispiel Web, sind Name und SMTP-Servern in der Regel alle auf einer DMZ befinden, weil sie ähnliche All Share Risiko aus dem direkten Angriff. Auf dem internen Teil des Netzwerks sind in der Regel Desktops in einer anderen Sicherheitszone als der Server platziert. Dies liegt daran, Server wenig bis gar kein Zugang zum Internet, während Desktop-PCs sind in der Regel gestattet, direkt zu kommunizieren. Dies stellt den Desktops ein höheres Risiko als der Angriff der Server.

Wir können dieses gleiche Logik bei der Umsetzung von Virtualisierung. Ein DMZ-Server und einen internen Server Gäste sollten nicht auf der gleichen Hardware (CPU und Disk-Array werden). Dies könnte einem Angreifer erlauben, eine alternative Route in unser Netzwerk zu schaffen. Anstatt durch eine Firewall passieren, NIDS, NIPS, Geräte, etc. auf dem Draht bereitgestellt wurde, kann ein Angreifer in der Lage sein, den Zugang zu internen Ressourcen über die Virtualisierungs-Software zu gewinnen. Ist es eine einfache Attacke? Nicht aus dem, was wir bisher gesehen haben. Funktionelle Exploits wurden jedoch entdeckt, warum so vorstellen unnötiges Risiko, wenn wir nicht tun müssen.

By the way, sollten dieselben Regeln Sicherheitszone um Ihre virtualisierte Netzwerk-Getriebe eingesetzt werden. Zum Beispiel ist es eine schlechte Idee, um die gleichen physikalischen switch to VLAN der DMZ und dem internen Netzwerk verwenden. Ich habe ein paar von Kunden erhalten, schlug gesehen so.

Was macht Virtualisierung Mehr Secure

Glücklicherweise ist aus sicherheitspolitischer Sicht ist Virtualisierung nicht nur schlechte Nachrichten. In der Tat gibt es einige sehr coole Sicherheit Praktiken, die Sie in einer virtualisierten Umgebung, die man einfach nicht ohne sie tun können, beantragen können. Dies war einer der Gründe, begannen wir mit Virtualisierung innerhalb des Honeynet so früh wie 2000.

Eines der größten Sicherheitsprobleme wir heute gegenüberstehen, ist der Kernel-Ebene Rootkits . Was macht diese Sorte von Malware so heimtückisch ist es wirksam wird das Betriebssystem selbst in die Malware. Dies macht Nachweis extrem schwierig, da alle Sicherheitskontrollen muss durch den Kernel übergeben. Wenn der Kernel selbst gefährdet ist, können wir nicht auf den Kernel, um genau zu berichten Sicherheit Informationen verlassen. Wir haben schließlich zum Herunterfahren des Systems, das Laufwerk auf einem bekanntermaßen sauberen OS und der Erfüllung unserer forensischen Überprüfungen von dort. Oh natürlich das Problem bei diesem Verfahren ist, dass es nicht gut skalierbar. Wenn wir Dutzende oder Hunderte von Servern haben, es wird einfach nicht genug Zeit, an einem Tag, um sie alle zu überprüfen richtig.

Wie bereits erwähnt, ist VMware nun erlauben Drittanbieter Zugang zu den Hypervisor API via VMsafe. Dies ermöglicht den Zugriff auf privilegierte Informationen Zustand, wie Speicher-und Netzwerk-Verkehr, auf jedem der Gastbetriebssysteme. Mit dem Einstecken in den Hypervisor, werden einige sehr coole Sicherheits-Optionen möglich.

Zum Beispiel sagen wir mal ein Gast-Betriebssystem durch ein Rootkit auf Kernel-Ebene angegriffen wird. Durch die Analyse von Gast-Speicher, kann das Rootkit von außerhalb der virtuellen Betriebssystem erkannt werden. Bei der Durchführung der Kontrollen über den Hypervisor, es ist weit weniger eine Chance, dass ein Rootkit kann seine Aktivitäten Heimlichkeit und unentdeckt bleiben. Wie bereits erwähnt, gibt es keine vergleichbare Option mit einem nicht-virtualisierten System.

Die API-Plug schafft auch neue Möglichkeiten für den Umgang mit verschlüsselten Datenverkehr. Als End-Verschlüsselung Ende zu beschäftigt ist (wie ein VPN), Netzwerk-basierte Kontrolle der Anwendungsschicht sind leicht zu umgehen. Ihre einzige reale Möglichkeit bestand darin, Agent-Software auf dem Endpunkt ausgeführt, so dass die Sicherheit könnte nach der Entschlüsselung Prozess implementiert werden. Natürlich ist das Problem hier ist, dass, wenn der Agent angegriffen wird, sind alle Wetten ausgeschaltet sind. Wiederum durch Einstecken in den Hypervisor sind wir in einer besseren Position, um sicherer zu prüfen diese Daten.

Wir beginnen gerade zu sehen neue Produkte, die Hebelwirkung der VMsafe API Plugin . Da alle Produkte sind relativ neu ist, ist das letzte Wort noch nicht auf, wie effektiv sie sein kann. Führen Sie die Angebote von Gambit ersetzen Host-basierte Firewall-und IDS Schutz zur vollen Durchsetzung von Richtlinien. Es wird interessant sein zu sehen, wie dieses Produkt Nische heraus schüttelt Laufe des nächsten Jahres.

Zusammenfassung

So wie ich am Anfang dieses Posts erwähnt, hat die Fähigkeit zur Virtualisierung Ihrer Umgebung entweder mehr oder weniger sicher zu machen, je nachdem wie Sie es einsetzen. Wenn Sie einfach alles auf Start Ausführen einer einzigen Box, sind Sie wahrscheinlich zu gerädert zu erhalten. Wenn Sie verlängern die besten Praktiken, die im Laufe der Jahre in die Virtualisierung Bereich entwickelt wurden, sowie Leverage einige der neuen Sicherheits-Features, die freigesetzt werden, können Sie sogar eine bessere allgemeine Sicherheitslage.

Kombinieren Logwatch und OSSEC - Teil 4

18. Februar 2010 von Chris 3 Kommentare »

In meinem letzten Beitrag haben wir installiert Logwatch sowie OSSEC. Es ist nun Zeit, sich Logwatch OSSEC und spielen zusammen in der gleichen Sandbox. In diesem Beitrag werde ich erörtern, wie sich Logwatch zu den Informationen durch OSSEC generiert zusammenzufassen.

Deployment-Optionen

Wir haben zwei Wegen, die wir folgen, um dies einzurichten kann:

  1. Haben Logwatch analysieren die Protokolle direkt OSSEC.
  2. Haben OSSEC schicken ihre Warnungen an einen Syslog-Server geben, dann laufen Logwatch auf dem Syslog-Server.

Der Nutzen für die Option # 1 ist, dass wir nur noch ein einziges System. Logwatch wird über das System der OSSEC Hosting-Server ausgeführt werden. Das Problem wir zu laufen sind jedoch beinhaltet die OSSEC Alert-Datei. Log-Einträge nicht normalisiert bekommen. Dies bedeutet, das Format kann von Eintrag zu Eintrag ändern, und kann sogar über mehrere Zeilen verteilt. Es wird ein wahrer Albtraum zu einem Logwatch Skript, das Filter und wird einen Überblick über die Ausschreibung Informationen zu erstellen.

Wenn wir mit der Option # 2 zu gehen, benötigen wir ein anderes Feld als unseren zentralen Logging-Server handeln. Um die OSSEC Server akzeptieren Log-Einträge aus Nicht-Agenten-Systeme, hat es auf UDP/514 hören. Dies ist die gleiche Schnittstelle von einem zentralen Logging-Server verwendet, und Sie können nicht zwei Anwendungen den gleichen Port (außer bei Windows, aber Socket-Zugang ist extrem chaotisch). Auf der positiven Seite, wird der Alarm-Einträge normalisiert, wenn sie an den Syslog-Server übertragen werden, so die Schaffung eines Logwatch Zusammenfassung Skript wird viel einfacher. Weitere, bereits Logwatch weiß um die Standard-Syslog-Dateien, damit wir weniger Anpassung zu tun haben.

Schließlich erwähnte ich in einem früheren Post, dass OSSEC nicht entworfen, um eine SIM werden. Das ist, weil es nicht alles aufnehmen, nur die Ereignisse, die einen Alarm zu generieren. So sind wir wahrscheinlich zu einem zentralen Server ohnehin wollen, und es macht Sinn, um es für die Informationsspeicherung durch OSSEC generiert.

Also, wenn es, wie ich dir bin Scheibe in Richtung Option # 2 klingt, sind Sie absolut richtig. Mit dieser sagte, ich bin eigentlich los mit Option # 1 decken, da sie eine weitaus komplexer Setup ist.

Der Umgang mit Datum / Uhrzeit-Stempel

Werfen Sie einen Blick auf die wichtigsten OSSEC logfile und Sie sollten sehen, wie die folgende:

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

2010/02/18 12.32.05 ossec-rootcheck: INFO: Ending rootcheck scannen.

2010/02/18 14.27.06 ossec-syscheckd: INFO: Starting syscheck scannen.

2010/02/18 14.39.21 ossec-syscheckd: INFO: Ending syscheck scannen.

Beachten Sie die Darstellung des Datums-und Zeitstempel formatiert ist. Dies ist anders als die meisten anderen Anwendungen, so dass das erste, was wir brauchen zu tun ist, sagen Logwatch Umgang mit diesem Format. Wir müssen ein Skript, das wir können anrufen, wenn nötig, die versteht der gezeigten Form zu erstellen.

Start durch Umzug in das gemeinsame Verzeichnis scripts:

cd / usr / share / logwatch / scripts / shared

Benutzen Sie Ihre Lieblings-Editor eine Datei namens "applylongdate":

vi applylongdate

Hier ist was Sie in dieser Datei benötigen. Fühlen Sie sich frei copy / paste von dieser Seite:

Verwendung Logwatch ": Termine";

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

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

if ($ debug> 5) (

print STDERR "DEBUG: Inside ApplyLongDate ... \ n";

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

)

while (defined ($ ThisLine <stdin> =)) (

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

print $ ThisLine = ~ s / ^ .... \ / .. \ / .. ..:..:.. / /;

print $ ThisLine;

)

)

# Vi: shiftwidth = 3 = Syntax Perl tabstop = 3 et

Sobald Sie die Datei speichern, müssen wir jetzt die richtigen Berechtigungen gesetzt werden:

chmod 755 applylongdate

Die Log-Dateien konfigurieren

Als nächstes müssen wir sagen, wo der Logwatch OSSEC Log-Dateien befinden. Immer, wenn Sie neue Protokolldateien erstellen oder fügen Sie neue Dienste in Logwatch überwachen, sollten Sie Ihre Änderungen unter der / etc / logwatch ablegen. Wir werden zwei Konfigurationsdateien zu erstellen. Der erste Griff wird OSSEC Nachrichten, und die zweite wird OSSEC Warnungen und aktive Reaktion Veränderungen umgehen.

Beginnen wir mit der Erstellung der Konfigurationsdatei für die wichtigsten OSSEC Log-Datei:

cd / etc / logwatch / conf / logfiles

vi ossec.conf

Der Inhalt der Datei sollte wie folgt:

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

* = ApplyLongDate

Jetzt können Sie speichern und schließen Sie die Datei. Als Nächstes erstellen wir die Konfigurationsdatei für die verbleibenden Protokolldateien:

vi ossec-alert.conf

Der Inhalt dieser Datei sollte wie folgt:

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

LogFile = / var / OSSEC / logs / Warnungen / alerts.log

LogFile = / var / OSSEC / logs / Firewall / firewall.log

Wenn Sie fertig sind, speichern und schließen. Die Standard-Berechtigungen sollten für unser Setup akzeptabel.

Konfigurieren OSSEC Services

Als nächstes müssen wir die OSSEC Dienste zu definieren und zu identifizieren, was wir als einen Titel, wenn die Berichte erzeugt werden, verwenden möchten. Hier ist, wie die erste Datei zu erstellen:

cd / etc / logwatch / conf / Dienstleistungen

vi ossec.conf

Der Inhalt dieser Datei ist recht einfach:

Title = "OSSEC Messages"

LogFile = OSSEC

Nach Fertigstellung können Sie speichern und schließen. Wir müssen noch eine Datei in diesem Verzeichnis zu erstellen:

vi ossec-alert.conf

Der Inhalt dieser Datei sollte:

Title = "OSSEC Alerts"

LogFile = OSSEC-alert

Wenn Sie fertig sind, speichern und schließen wie gewohnt.

Die Parsing Einträge

Als nächstes müssen wir sagen, wie Logwatch Format der Log-Einträge innerhalb des Berichts. Wir müssen eine Anpassung Skript für jeden Satz von Diensten zu schaffen. Wir werden mit Hilfe eines mitgelieferten Test Logwatch Skript starten; nur um sicher alles funktioniert.

Start durch den Wechsel in das entsprechende Verzeichnis:

cd / etc / logwatch / scripts / Dienstleistungen

Benutzen Sie Ihre Lieblings-Editor, um Ihre erste Skript zu erstellen:

vi OSSEC

Der Inhalt des Skripts sollte wie folgt:

#! / Bin / bash

# Das ist so schön Skript, das zeigen Ihnen die Zeilen, die Sie wird

# Werden, die Verarbeitung und die Berichterstattung über. Es wird zuerst angezeigt werden sollen die

# Standard-Umgebungsvariablen und dann dauert es STDIN und

# Dump es rechts wieder heraus zu STDOUT.

# Dies sind die Standard-Umgebungsvariablen. Sie können festlegen,

# Mehr in Ihrem Dienst config-Datei (siehe oben).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Detail Level: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Level: $ LOGWATCH_DEBUG"

# Nun nehmen STDIN und STDOUT dump es

Katze

Erstellen Sie nun Ihr zweites Skript:

vi OSSEC-alert

und enthalten exakt die gleichen Inhalte:

#! / Bin / bash

# Das ist so schön Skript, das zeigen Ihnen die Zeilen, die Sie wird

# Werden, die Verarbeitung und die Berichterstattung über. Es wird zuerst angezeigt werden sollen die

# Standard-Umgebungsvariablen und dann dauert es STDIN und

# Dump es rechts wieder heraus zu STDOUT.

# Dies sind die Standard-Umgebungsvariablen. Sie können festlegen,

# Mehr in Ihrem Dienst config-Datei (siehe oben).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Detail Level: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Level: $ LOGWATCH_DEBUG"

# Nun nehmen STDIN und STDOUT dump es

Katze

Schließlich müssen wir die entsprechenden Berechtigungen gesetzt werden:

chmod 755 OSSEC *

Testen der Einrichtung

Der einfachste Weg zu unserem neuen Setup-Tests ist es, den Befehl auszuführen:

logwatch | less

Wenn Sie nur wollen, um die Änderungen zu sehen, können Sie einen Bericht über jeden Dienst ein zu einer Zeit:

logwatch-Service OSSEC | less

logwatch-Service OSSEC-alert | less

Weitere Customization

Sobald Sie alle oben genannten Arbeiten zu bekommen, können Sie sich auf immer Logwatch zu filtern und zusammenfassen der Log-Einträge zu konzentrieren. Logwatch ist ziemlich flexibel, und Sie können die Ausgabe wie Sie wollen anpassen. Eines der schönen Dinge, über die oben genannten Test-Skript ist, dass Sie zeigt genau, was Sie mit der Arbeit zu haben. Also mit ein wenig Magie regulären Ausdruck Sie die Einträge zusammenfassen kann, wie Sie für angemessen halten. Für einige Ideen, überprüfen Sie die Dateien befindet sich unter:

/ Usr / share / logwatch / scripts / Dienstleistungen

Dies sind die Standard-Skripte enthalten Zusammenfassung mit Logwatch. Insbesondere haben Sie einen Blick auf die Dateien "pam" und "sshd". Sie sind großartige Beispiele für eine einfache und eine komplexe Reihe von Filtern Zusammenfassung.

Wie entwickeln Sie Ihre Skripte, Aufmerksamkeit schenken, um die $ LOGWATCH_DETAIL_LEVEL "Variable. Dies ermöglicht Ihnen, den Ausgangspegel des Berichts abhängig, wie viel Persönliche Ausführlichkeit der Nutzer sucht. Zum Beispiel, während Sie noch in den oben genannten Diensten Verzeichnis befinden, führen Sie den folgenden Befehl ein:

weniger sshd

Wenn die erste Seite der Inhalt der Datei angezeigt wird, geben Sie in:

/ Detail <Geben key>

Der Backslash lässt uns suchen Sie die Datei für einen bestimmten Text-String. In diesem Fall sind wir für die Suche sind das Wort "Detail". Sobald Sie Enter drücken wird die Suche durch die Datei zu überspringen, bis es die erste Instanz der Zeichenfolge fest. Ein weiterer Höhepunkt ist der Suchbegriff. Im ersten Spiel werden Sie feststellen, dass der Autor die Variable "$ Detail" zugeordnet, die gleiche wie die Variable $ LOGWATCH_DETAIL_LEVEL werden ". Dies ist um sie zu retten Tipparbeit.

Jetzt drücken Sie die Taste erneut Backslash durch die Enter-Taste. Dies wird durch die Datei auf die nächste Instanz zu springen "Detail". Sie sollten sehen:

if ($ Detail> = 20) (

$ ($ Benutzer Benutzer) ($ Host) ($ method) + +;

) Else (

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

$ ($ Benutzer Benutzer) ($) (Host "(alle )"}++;

Anmerkung des Autors finden Sie weitere Informationen, wenn die Detail-Level ist auf 20 (auf halbem Weg zwischen niedrigen und mittleren Reihe) oder höher. Halten Sie springen über die Datei und Sie werden andere Beispiele, wo der Autor dieser Technik Leveraged sehen.

Nun Seite bis zum Ende der Datei, und Sie sollten diese Aussage zu sehen:

if (keys% OtherList) (

print "\ n ** ** Einzigartige Einträge \ n";

print "$ _: $ OtherList ($ _) time (s) \ n" foreach keys% OtherList;

)

Dieser Abschnitt ist äußerst wichtig, da sie eine endgültige Catchall ist. Denken Sie an eine Firewall-Richtlinie für einen Augenblick. Die meisten von uns eine endgültige Regelung zu schaffen, die sagt: "Wenn ich nicht ausdrücklich erlaubt hat, einen Verkehrsunfall Muster durch, deny it". In anderen Worten, wenn etwas Unerwartetes passiert, das ist, wie ich Sie damit umgehen wollen.

Die obige Anweisung dient dem gleichen Zweck beim Parsen der Logdatei. Alle der früheren "if"-Anweisungen Versuch, einen bestimmten Text-String in den Log-Eintrag, um es richtig Format entsprechen. Dieser Eintrag sagt: "Wenn Sie noch nicht abgestimmt und druckte eine spezifische Log-Eintrag noch, drucken Sie es aus in einem Abschnitt mit der Überschrift" ** ** Einzigartige Entries ". Dieser Schritt ist äußerst wichtig, denn ohne sie werden wir nie sehen unerwarteten Eingaben. Es ist die unerwartete Einträge, die wahrscheinlich sind die wichtigsten und interessantesten.

Exec Zusammenfassung

Beide OSSEC und Logwatch sind ausgezeichnete kostenlose Tools. OSSEC zeichnet sich warne dich, wenn eine bekannte Angriffsmuster stattfindet. Logwatch ist ein hervorragendes Werkzeug für die Zusammenfassung einer Zeit, Stück logs so Menschen tatsächlich leisten kann Gespür dafür, was los ist. Durch die Kombination der beiden Werkzeuge können Sie eine wesentlich robuster Verteidigung eingehende Körperhaltung. Das Ganze wird größer als die Summe der Teile.

Kombinieren Logwatch und OSSEC - Teil 3

17. Februar 2010 von Chris Keine Kommentare »

In meinen letzten zwei Stellen I diskutiert und Logwatch OSSEC, und wie sie Einfluss auf die aktuelle Sicherheitslage zu vermehren können. In dieser Tranche werde ich erörtern, wie diese beiden Tools zu installieren.

Installieren Logwatch

Logwatch ist recht einfach zu installieren. In der Tat ist es standardmäßig auf vielen Linux-Distributionen installiert, so dass Sie möglicherweise bereits eine Kopie auf Ihrem System. Um zu überprüfen, melden Sie sich als root ein und versuchen Sie Logwatch mit dem "-v" zu wechseln. Wenn Sie sehen:

[Root @ fubar logwatch] # logwatch-v

Logwatch 7.3.6 (released 05/19/07)

Logwatch installiert ist und Sie eine Kopie der neuesten Version. Wenn Sie nicht die neueste Version können Sie den Greifer aus Logwatch Download-Seite .

Es gibt drei Varianten von Logwatch, die heruntergeladen werden können; Binaries im RPM-Format, Quelle im RPM-Format oder Quelle in einem Tar-Ball. Wenn Ihr System unterstützt RPM-Paket-Management, das binäre RPM ist Ihre beste Wahl ist. Es ist einfach zu installieren und RPM wird nun automatisch die Software aktualisieren, wenn neue Versionen verfügbar sind.

Installieren von RPM Logwatch

So installieren Sie die binäre Version des RPM, einfach melden Sie sich als root und navigieren Sie zu dem Verzeichnis wo Sie die RPM-Datei heruntergeladen. Nun führen Sie das Kommando:

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

Vergessen Sie nicht, können Sie die Tab-Taste, um auto-complete den Dateinamen anstatt Art in der ganzen Sache zu verwenden.

Installieren Logwatch From Source

Installation von den Quellen ist ein wenig zeitaufwändiger. Denken Sie daran, dass im Hinblick auf Source-Code installieren, müssen Sie bereits einen Compiler (gcc wie) auf Ihrem System installiert. Melden Sie sich als root und navigieren Sie zu dem Verzeichnis wo Sie die heruntergeladene Tar Kugel. Um das Archiv entpacken, den Befehl auszuführen:

tar xvzf logwatch-7.3.6.tar.gz

Sie wird eine Verzeichnis-Struktur unterhalb Ihres aktuellen Standorts zu sehen bekommen geschaffen und viele Dateien kopiert in. Wir müssen jetzt in die Top bewegen meisten Verzeichnis, das erstellt wurde:

cd logwatch-7.3.6

Damit Logwatch zu laufen, gibt es eine Reihe von Verzeichnissen, die auf Ihrem System erstellt werden müssen. Diese sind in der README im aktuellen Verzeichnis dokumentiert. Glücklicherweise enthält Logwatch ein Installationsskript, dass die ganze Arbeit für Sie tun können. Leider hat das Skript die falschen Berechtigungen festlegen, damit es nicht standardmäßig ausgeführt wird. Dies ist recht einfach, aber fix mit dem Befehl chmod:

chmod 500 install_logwatch.sh

Jetzt können wir das Skript ausführen, um das Setup unseres Systems:

. / Install_logwatch.sh

Vergessen Sie nicht den Punkt am Anfang der Zeile.

Testen Logwatch

So testen Sie Logwatch Setup, den Befehl auszuführen:

logwatch | less

Sie werden Ihren Terminal-Bildschirm sehen, gehen leer, aber das ist normal. Sie werden schließlich sehen Logwatch Bericht auf dem Bildschirm ausgegeben bekommen, dass man durch den Einsatz der "Page Up" und "Page Down"-Tasten navigieren. Wie log dauert es für den Bericht zu zeigen, bis auf dem Bildschirm auf, wie viel log Informationen müssen analysiert angewiesen. Es könnte ein paar Sekunden dauern oder ein paar Minuten. In jedem Fall wird es Ihnen eine Chance geben, sich mit dem Bericht-Format vertraut zu machen.

Installieren OSSEC

Wie ich in meinem letzten Beitrag erwähnt, haben Sie zwei Möglichkeiten der Installation mit OSSEC, lokalen oder Client / Server. In diesem Beitrag werde ich auf der Kundenorientierung / Server-Setup bin, da es ein wenig komplexer ist. Wenn Sie eine lokale Installation sind, wählen Sie einfach die "local"-Option während der Installation und überspringen Sie den Abschnitt über die Einrichtung eines sicheren Kanals zwischen dem Handelsvertreter und dem Server.

Beginnen Sie mit dem Server

OSSEC verwendet Blowfish-Verschlüsselung, um die Kommunikation zwischen Client und Server zu sichern. Blowfish ist symmetrisch Schlüssel basiert, so dass beide Seiten, was Schlüssel-Wert zu verwenden, um zu kommunizieren wissen müssen. Der Server ist verantwortlich für die Generierung der symmetrischen Schlüssel, so müssen wir die Server-Software zuerst installieren. Während der Client installieren wir werden nach einem Schlüssel-Wert so offensichtlich dazu aufgefordert werden müssen wir haben, dass praktisch vor der Zeit.

Hier ist eine zeitsparende Spitze. Der Schlüsselwert ist lang und fast unmöglich zu merken. Der einfachste Weg, um den Schlüssel-Wert aus dem Server-System bewegen, um den Agenten-System ist die Verwendung von SSH. Erstellen Sie eine sichere Verbindung zum Server OSSEC und extrahieren Sie die entsprechende Taste (Wegbeschreibung weiter unten). In einem zweiten Terminal-Fenster, erstellen Sie eine SSH-Sitzung auf das System, wo Sie die Installation wird der Agent. Wenn der Client installiert werden Sie aufgefordert, nach dem Schlüssel-Wert, können Sie einfach kopieren und zwischen den beiden Terminals einfügen.

Die Installation von Server OSSEC

Die Server-Software ist verfügbar als tar ball, so können Sie das Grab eine Kopie der neuesten Version von OSSEC Download-Seite . Sie müssen dann den Inhalt des Tar Ball zu extrahieren:

tar xvzf ossec-HIDS-2.3.tar.gz

Verschieben Sie als nächstes in die Verzeichnisstruktur, die Sie gerade erstellt haben:

cd ossec-HIDS-2.3

OSSEC bietet ein Installationsskript, um Sie durch den Prozess der Installation des Servers laufen. So starten Sie das Skript ein:

. / Install.sh

Vergessen Sie nicht den Punkt am Anfang des Befehls. Sie werden nun durch eine Reihe von Optionen aufgefordert werden, installieren:

  • Language - Die Standardeinstellung ist Englisch. Nach Bedarf ändern.
  • Bestätigung der Installation - Drücken Sie einmal Enter haben Sie am Bildschirm zu lesen.
  • Installieren Sie - Typ in "server" ohne die Anführungszeichen ein und drücken Sie Enter.
  • Install location - Übernehmen Sie die Standardeinstellung.
  • E-Mail-Benachrichtigung - Standard ist ja, wenn Sie möchten, wählen Sie E-Mail-Benachrichtigung. Wenn Sie Ja auswählen, werden Sie eine gültige E-Mail-Adresse und Mail-Server dazu aufgefordert werden.
  • Integrity Check - Der Standardwert ist yes. Wählen Sie, wenn Sie wollen, dass die lokalen System in regelmäßigen Abständen für Eingriffe überprüft.
  • Rootkit-Erkennung - Default ist ja. Gute Wahl, da wir ein hohes Maß an Integrität auf diesem System aufrechterhalten müssen.
  • Active Response - Default ist ja. Wählen Sie diese Option, wenn Sie in der Lage, auf Ereignisse zu reagieren wollen.
  • Firewall Drop - Erlaubt die OSSEC Server zu verteidigen, wenn es sich von selbst ein direkter Angriff erkannt wird.
  • Weisse Liste - Dies ermöglicht Ihnen das Hinzufügen IP Adressen, von denen mögliche Angriffe ignoriert. Seien Sie vorsichtig mit dieser Option. Wenn du es nicht haben Zugriff auf die Konsole OSSEC Server, könnte es klug sein, eine IP-Adresse, die immer in. kann nur gewährleistet die Quell-IP ist ein vertrauenswürdiges System zu erhalten identifizieren.
  • Enable Syslog - Default ist ja. Wählen Sie diese Option, wenn Sie sammeln möchten Logs von System, das nicht ausführen kann eine OSSEC Anbieters (wie Firewalls, Switches, Router, Access Points, etc.).
  • Log-Dateien überwacht werden - Dieser Bildschirm identifiziert alle lokalen Protokolldateien OSSEC überwacht. Es ist lediglich Informationen, so dass alles, was Sie tun können, ist die Eingabetaste drücken, um daran vorbei zu bewegen. Wenn Sie eine oder mehrere Log-Dateien Hinweis aus der Liste fehlen, können Sie sie später hinzufügen, um die Datei ossec.conf.

An diesem Punkt wird OSSEC Zugriff auf das lokale Compiler und installieren Sie alle benötigten Dateien auf das System. Wenn Sie fertig sind, können Sie die OSSEC Server mit dem Befehl starten:

/ Var / OSSEC / bin / OSSEC-control starten

Definieren OSSEC Agents

Wir sind nicht mit dem Server durchgeführt OSSEC nur noch. Als nächstes müssen wir vor, alle Systeme zu definieren, die ausgeführt werden, wird die OSSEC Anbieters (Client) Software. Dies erfolgt mit dem Befehl manage_agents. Zunächst aber müssen wir ein bisschen Hausaufgaben machen. Machen Sie eine Liste aller Systeme, die ausgeführt werden, wird die OSSEC Agent-Software. Für jedes System, benötigen Sie einen aussagekräftigen Namen wie auch die System-IP-Adresse.

Nun führen Sie die folgenden von der Kommandozeile aus:

/ Var / OSSEC / bin / manage_agents

Dies wird die Agent Manager Hauptmenü. Drücken Sie "A" durch die Enter-Taste, um Ihre erste System definieren gefolgt. Geben Sie einen aussagekräftigen Namen für das erste System, gefolgt von der System-IP-Adresse. Mach dir keine Sorgen über die Agent-ID-Nummer. Simply akzeptieren Sie die Standardeinstellung und wird auto-OSSEC ordnen Sie die nächste verfügbare ID-Nummer. Once you confirm the information you entered, you will be returned to the Agent Manager main menu. Repeat the above process for each system that will be running an OSSEC agent.

Generating Keys

Once you have added in all of your systems, it is time to generate encryption keys. This step is also performed with the manage_agents utility. If you closed the tool after the last step, relaunch it now.

Press the “E” key followed by Enter to select the “Extract key for an agent” menu option. You will then be prompted for the ID number of the key you wish to extract. The descriptive names and IP addresses are listed with each ID number, so it should be trivial to identify which one you want. Start with the system you plan to install the agent software onto first.

OSSEC Agent Install On Linux

When installing the agent software on a Linux or UNIX client, you use the exact same Tar ball we used to install the server software. Run the same install script, but this time when you are prompted for the type of install you wish to perform, type in “agent” followed by the Enter key.

The client install has many of the same prompts as the server install. Use the info above to guide you through the process. The prompt that will vary however is that you will be asked to provide the IP address of the OSSEC server. Once complete, OSSEC will access the local complier and install all required files onto the system.

Next we need to import the Blowfish key from the OSSEC server. While still on the agent system, run the command:

/var/ossec/bin/manage_agents

When the Agent Manager menu appears, select “I” to import the Blowfish key.

When the next prompt appears, you need to manually enter the appropriate Blowfish key. Again, if you are running SSH to both systems at the same time, you can simply copy/paste between the two terminals. Make sure the key looks correct, press the Enter key, and then select “y” to confirm that the key looks correct. You will be returned to the Agent Manager menu. Select “q” in order to return to the command line.

Now we simply need to start the OSSEC agent. You can do so by executing the following command:

/var/ossec/bin/ossec-control start

You should see all of the OSSEC agent components start up, followed by a “Completed” message.

OSSEC Agent Install On Windows

OSSEC has a self-extracting executable that will permit you to install the agent software on a Windows system. Simply double click the executable to start the install process. You will be prompted to agree to the license as well as which components you wish to install. Simply follow the prompts till the OSSEC Agent Manager window appears.

The OSSEC Agent Manager window will prompt you for the IP address of the OSSEC server. It will also prompt you for the Blowfish key value to use, so extract the appropriate key on the server and enter the value in this field. Make sure you delete the prompt within this field before you paste in the Blowfish key. Otherwise communication with the server may fail.

Next, select “Manage” from the OSSEC Agent Manager menu, followed by “Start OSSEC”. You should now see the “Status:” indicator change to “Running…”.

Testing OSSEC

Once you have the server and agent software installed, started and the appropriate keys configured, it is now time to check our setup. Execute the following command on the OSSEC server:

cd /var/ossec/logs

And check out the ossec.log file:

less ossec.log

Check the log file for any errors. A common error is that OSSEC reports it cannot send e-mail. Make sure the mail server is running and that it is accepting connections. Once you are happy with the server setup, it is now time to check out the agents. Move down to the “alerts” directory:

cd alerts

And check out the alerts.log file:

less alerts.log

Specifically, you are looking for entries similar to the following:

2010 Feb 17 16:09:16 (desktop) 192.168.1.10->ossec

Rule: 501 (level 3) -> 'New ossec agent connected.'

Src IP: (none)

User: (none)

ossec: Agent started: 'test_system->192.168.1.10′.

You should see an entry for every system on which you installed the agent software.

More To Come

Puh! That's more than enough for one post! In my next post I'll get into leveraging Logwatch to parse all of the alert information being generated by OSSEC.

Kombinieren Logwatch und OSSEC - Teil 2

February 16th, 2010 by Chris No comments »

In my last post I described how Logwatch could be used to simplify the log review process. In this post we'll look at OSSEC and what it brings to the table.

What Is OSSEC?

OSSEC , short for “Open Source SECurity”, is a host based intrusion detection system (HIDS). In other words, it is designed to detect attacks or policy violations if and when they occur. While it does not have the ability to protect against unknown or 0-Day attacks (that would be host based intrusion prevention), it does include a wide range of tools which can help you identify an intrusion when it occurs, as well as the extent of the damage that has been caused.

Supported Platforms

To take advantage of all of the features OSSEC has to offer, you have to run an agent on the system being protected. OSSEC agents can run on Windows, Mac OS X, Linux, and a wide range of UNIX systems. If you are just interested in the log analysis portion however, an even wider range of systems can be supported. This includes hardware from both Cisco and Juniper. A number of specific products are also supported like Checkpoint firewalls, Symantec Anti-Virus, Snort, Squid, and Arpwatch, just to name a few.

When you install OSSEC you have two configuration options, local or client/server. A local install is used when you need to run everything on a single system. The client/server installation lets you run a distributed environment protecting multiple systems at the same time. While most deployments are client/server based, if you want to give OSSEC a spin you can easily run everything on a single test system using a local install.

Log Analysis

OSSEC includes a Log-based Intrusion Detection System (LIDS). This has the ability to review log files in near real time, while scrutinizing them for known attack patterns. When a log is generated on a protected system, the agent takes care of securely transmitting the log (Blowfish encryption using a pre-shared secret) back to the server. The server then takes care of performing the analysis.

Most log analysis tools process their rules in a linear format. By that I mean if we have 500 rules, rule one is checked, then rule two, then rule three and so on till a match is found or we reach the end of the rule set.  OSSEC works a bit differently as it implements a hieratical structure to the rules. Log entries are first classified and then checked only against whichever rules are appropriate. The result is that rather than needing to process all 500 rules, most events will get checked against 10 rules or less. This dramatically reduces the amount of overhead required to process the rule set.

Integrity Checking

OSSEC includes a tool called Syscheck for performing file and directory integrity checking. If you are running a Windows agent, you can also include specific keys within the Windows registry to be monitored as well. File changes can be detected using both MD-5 and SHA-1 hash algorithms. The system is extremely customizable. You can include or exclude single files, or entire directory structures. You can even set a flag to detect new file creation.

The agent software is designed to use a minimal amount of CPU during the integrity check. While this means the check will take longer, it also helps to minimize the performance hit to the system. Hash information is transmitted back to the server. The server then takes care of performing the hash comparison to see if any of the system's critical files have been changed. The server also stores a copy of the integrity check policy, so that if policy changes are made on the agent, they can be detected and reported as well.

Anomaly detection

OSSEC goes far beyond log checking to verify system integrity. Usage policies can be centrally managed from the server, and then pushed out to the appropriate agents. For example you could define a policy regarding which Windows applications are acceptable (Office, Firefox, etc.) and which ones are not (IM client, Skype, etc.). You can even define acceptable configuration options like verifying that NT hashes are being used for password stored but not LanMan hashes.

OSSEC includes a number of other goodies in order to help verify a system's integrity. For example OSSEC has the ability to execute commands from the agent and monitor the output that gets generated. For example you could have the Linux agent execute the “df” command at regular intervals and generate an alert if disk usage exceeds 90%. A Windows example may be to have OSSEC generate an alert whenever file information is written to the alternate data streams area of NTFS.

Active Response

Finally, OSSEC includes the ability to respond when suspicious activity is detected. Responses can be generated from the server or the agent, which ever you specify. Responses can be as benign as generating an e-mail alert, to being as proactive as blocking a remote IP address for a limited amount of time. There are a number of included active response scripts you can draw on, or you can easily write your own.

Secure Architecture

The OSSEC authors have gone to great lengths to secure all of the components within the product. Tasks such as integrity checking are performed on the server, rather than the agent, so the trustworthiness of the hashes cannot be compromised during an attack. Processes are run with the lowest level of permissions possible, and different accounts are used to run each OSSEC component. This means that a compromise of a single application within OSSEC will not immediately lead to a compromise of the full package. Further, most components are run within a chrooted jail so their access to the system is even further restricted.

Final Words

While OSSEC is a powerful tool, it is important to remember that it is a HIDS and not a log management solution. OSSEC can review log entries looking for suspicious patterns, but it will only save alert information. So while OSSEC will not replace your Security Information Management (SIM) solution, it can most certainly augment it. You can easily setup OSSEC to forward all alerts it generates to a central logging server .

While OSSEC is open source software, Trend Micro is primarily developing it. If you need commercial support, you can purchase a support contract through them at a reasonable fee.

More To Come

In my next installment we'll look at installing OSSEC and Logwatch. After that, we'll move into integrating the two together.

Kombinieren Logwatch und OSSEC

February 15th, 2010 by Chris No comments »

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?

How It Works

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.

More To Come

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.

Tag 2 Keynote

January 12th, 2010 by Chris No comments »

Thanks to all who came out to the Encryption/DLP summit. Here are the slides from my keynote on day 2.

encryption-dlp-keynote