Wie üblich gibt's an Tag zwei die Roadmap Präsentation, ich bin gespannt.
In 30 Minuten geht's los, Updates gibt's hier.
#1: Automatische Checks gegen diverse Compliancekriterien, inklusive Handlungsempfehlungen.
Produkt: easy2comply
#2: Identity Awareness bekommt noch mehr Quellen, Agents und Clients. Auch hier wird Compliance zunehmend zum Thema.
#3Threatcloud & Sensornet verteiltes Netzwerk zur Angriffsfrüherkennung, Ausbau der Erkennungsvektoren.
#4: AntiBot wird auf den Endpoint ausgedehnt.
#5: Trennung der Policys (IPS, AppControl, DLP) Policys lassen sich unabhängig voneinander installieren.
#6: Ausbau der Reportingfunktionen, SmartEvent etc..
#7: IPS wird es als ManagedService geben.
#8: DocumentSecurity: die "Dropbox for the Enterprise" Geschichte nun auch hier...
#9 Management: weiteres Zusammenwachsen vom neuen SmartLog & Smartevent.
Naja, alles in allem war das Ganze recht schwammig, wir werden sehen wie sich das das Gesagte in der Praxis niederschlägt.
Donnerstag, 31. Mai 2012
Mittwoch, 30. Mai 2012
Checkpoint Experience CPX2012 Keynote
Live von der CPXin Berlin. Nach dem Intro beginnt Gil Shwed mit dem Thema "keeping your edge in security"
Natürlich ist auch 2012 das Jahr der IT-Security ... Nix neues bis hier.
Die Antwort Nummer 1: Die Cloud. Bei Checkpoint heißt das ganze ThreatCloud. Die Idee: jeder kann sein Gateway dahin gefundene Malware und Angriffe reporten lassen. Also eine große "Mitmachdatenbank", um neue Angriffe schnell erkennen zu können.
Bots, bzw. Botnetze bekommen zukünftig verstärkte Aufmerksamkeit.
R75.4 ist wahrlich mehr als ein Hotfix. Neben Gaia, dem neuen Begriebssystem, gibts jede Menge Neues.
Eine davon: SmartLog: Logfiles sind nich länger nur Files, sondern wandern in eine Datenbank, und lassen sich dadurch flexibel und schnell verwalten ( Suche, Abfrage, Analyse)
Nächstes Thema ist Gaia, dazu werde ich in den nächsten Tagen gesondert was schreiben.
Nun was Neues zum Thema Performance: SecurityCore: ein Hardwaremodul mit 108 Rechenkernen, welche die Arbeit übernehmen. Ich hoffe das Teil gibts nachher im Lab zu sehen. Die Latency, um ein Paket durch den Kernel zu bringen, soll sich von jetzt ~44 Mikrosekunden auf ~ 5 drücken lassen, zudem doppelter Durchsatz... klingt wirklich gut, zumindest für den High End Markt.
Noch ein Wort zu R75.4: ich habe nie verstanden, warum so ein großes Release nicht ein Major Release (R80?) wird. Antwort von Checkpoint: die Basis ist die selbe ( hä? wie das mit nem neuen Betriebssystem), darum die Namensgebung. Zudem will man den Kunden nicht durch neue Namensgebung abschrecken... Aha ;-)
Natürlich ist auch 2012 das Jahr der IT-Security ... Nix neues bis hier.
Die Antwort Nummer 1: Die Cloud. Bei Checkpoint heißt das ganze ThreatCloud. Die Idee: jeder kann sein Gateway dahin gefundene Malware und Angriffe reporten lassen. Also eine große "Mitmachdatenbank", um neue Angriffe schnell erkennen zu können.
Bots, bzw. Botnetze bekommen zukünftig verstärkte Aufmerksamkeit.
R75.4 ist wahrlich mehr als ein Hotfix. Neben Gaia, dem neuen Begriebssystem, gibts jede Menge Neues.
Eine davon: SmartLog: Logfiles sind nich länger nur Files, sondern wandern in eine Datenbank, und lassen sich dadurch flexibel und schnell verwalten ( Suche, Abfrage, Analyse)
Nächstes Thema ist Gaia, dazu werde ich in den nächsten Tagen gesondert was schreiben.
Nun was Neues zum Thema Performance: SecurityCore: ein Hardwaremodul mit 108 Rechenkernen, welche die Arbeit übernehmen. Ich hoffe das Teil gibts nachher im Lab zu sehen. Die Latency, um ein Paket durch den Kernel zu bringen, soll sich von jetzt ~44 Mikrosekunden auf ~ 5 drücken lassen, zudem doppelter Durchsatz... klingt wirklich gut, zumindest für den High End Markt.
Noch ein Wort zu R75.4: ich habe nie verstanden, warum so ein großes Release nicht ein Major Release (R80?) wird. Antwort von Checkpoint: die Basis ist die selbe ( hä? wie das mit nem neuen Betriebssystem), darum die Namensgebung. Zudem will man den Kunden nicht durch neue Namensgebung abschrecken... Aha ;-)
Montag, 30. April 2012
Microsoft Lizenzierung im VDI Umfeld
Besonders in Virtualisierungsprojekten ist die Frage nach der Windows Lizenzierung eine sehr häufig gestellte. Benötige ich VDA (Virtual Desktop Access) Lizenzen, reicht SA (Software Assurance) und wie gehe ich mit privaten Geräten um.
Wie verhält es sich mit Nutzern, die mehrere Geräte haben? Und was ist wenn Geräte zwischen Nutzern geteilt werden?
Auf solche und noch viel mehr Fragen bietet ein jüngst veröffentlichtes Dokument von Microsoft nahezu alle Antworten. Im wesentlichen findet sich hier nichts neues, aber dieses Dokument ist eine sehr umfassende Hilfe bei der Beantwortung der Frage "Wie Lizenziere ich richtig"
Wie verhält es sich mit Nutzern, die mehrere Geräte haben? Und was ist wenn Geräte zwischen Nutzern geteilt werden?
Auf solche und noch viel mehr Fragen bietet ein jüngst veröffentlichtes Dokument von Microsoft nahezu alle Antworten. Im wesentlichen findet sich hier nichts neues, aber dieses Dokument ist eine sehr umfassende Hilfe bei der Beantwortung der Frage "Wie Lizenziere ich richtig"
Dienstag, 17. April 2012
Checkpoint UTM-1 Appliance Upgrade auf R75.20
Das aktuelle Upgradepacket R75.20 für Appliances von Checkpoint hat einen Bug, der auf manchen Appliances die /etc/grub.conf unbrauchbar macht. Das System bootet dann nichtmehr.
Glücklicherweise kann man beim Boot (serielle Konsole anstecken) noch den Bootloader (GRUB) selber aufrufen. Sofort fällt auf, dass dort der EIntrag "Start in Normal Mode" fehlt. Selbiger ist aber unglücklicherweise der default Modus, wegen dessen Fehlen das System wie gesagt hängen bleibt.
Abhilfe: Das System im Maintainance Mode booten, und die /etc/grub.conf mittels vi reparieren. Es fehlen die rot markierten Zeilen, je nach Umgebung kann die grub.conf aber etwas anders ausschauen, also Obacht :)
Mittwoch, 4. April 2012
VmWare vShield App - das Geheimniss der boundaries.
Beim anlegen einer Regel in vShield App bin ich auf die ominöse Option "source boundary" bzw. "destination boundary" gestoßen. Man hat die Wahl zwischen "Inside" und "Outside", und auf den ersten Blick wurde mir nicht ganz klar, was sich dahinter verbirgt.
Der Admin Guide meint lapidar: "Direction in relation to source from which the communication originated.", was auch nicht wesentlich zum Verständnis beitrug. Also blieb nur: ausprobieren, und die Lösung ist dann am Ende doch recht simpel.
Die beiden unten stehenden Regeln lesen sich so:
Alles, was NICHT 'renton.ifbus.de' ist und mit Win7Flex kommuniziren will, wird geblockt. Alles was GENAU 'renton.ifus.de' ist, darf.
Sprich, die Option "Outside" ist einfach nur die Negation des verwendeten Objektes, wie man das Beispielsweise von Checkpoint kennt. Sprich: "Outside [Objekt]' als Destination erlaubt Verbindungen zu allen Zielen, außer eben zu 'Objekt', und umgekehrt.
Der Admin Guide meint lapidar: "Direction in relation to source from which the communication originated.", was auch nicht wesentlich zum Verständnis beitrug. Also blieb nur: ausprobieren, und die Lösung ist dann am Ende doch recht simpel.
Die beiden unten stehenden Regeln lesen sich so:
Sprich, die Option "Outside" ist einfach nur die Negation des verwendeten Objektes, wie man das Beispielsweise von Checkpoint kennt. Sprich: "Outside [Objekt]' als Destination erlaubt Verbindungen zu allen Zielen, außer eben zu 'Objekt', und umgekehrt.
Montag, 2. April 2012
VMWare vCenter Operations - IP Adresse ändern
Der Operations Manager von VMWare kommt als vApp, bestehend aus 2 virtuellen Maschinen, einer für's Userinterface (UI VM) und einer zum Datensammeln (Analytics VM).
Während des initialen Rollouts konfigurieren sich die beiden Maschinen gegenseitig, unteranderm werden dort die IP Adressen relativ fest im System verdrahtet.
Nun kann, je nach Umgebung, das versehen einer vApp mit IP Adressen mit unter recht hakelig sein, oder ein anderer Grund maht eine spätere Adressänderung notwendig. Da jedoch an den IP's verschiedene Konfigurationsparameter, Zertifikate etc. hängen, ist eine solche Änderung nicht eben schnell via ifconfig erledigt.
Darum im Folgenden eine kurze Anleitung, wie beide Systeme zu einer neuen IP Adresse kommen, und hernach trotzdem gewillt sind miteinander zu sprechen.
Während des initialen Rollouts konfigurieren sich die beiden Maschinen gegenseitig, unteranderm werden dort die IP Adressen relativ fest im System verdrahtet.
Nun kann, je nach Umgebung, das versehen einer vApp mit IP Adressen mit unter recht hakelig sein, oder ein anderer Grund maht eine spätere Adressänderung notwendig. Da jedoch an den IP's verschiedene Konfigurationsparameter, Zertifikate etc. hängen, ist eine solche Änderung nicht eben schnell via ifconfig erledigt.
Darum im Folgenden eine kurze Anleitung, wie beide Systeme zu einer neuen IP Adresse kommen, und hernach trotzdem gewillt sind miteinander zu sprechen.
Ändern der Analytics VM
Fangen wir mit der Analytics VM an.
- Zuerst wird an der Konsole der UI-VM (defaultname: firstvm-external) der vcops Dienst gestoppt (ggf. vorher mittels sudo admin Rechte erwerben)
- vcops-admin stop
- Danach in der Analytics VM (defaultname:secondvm-external) in der Datei /etc/sysconfig/network/ifcfg-eth0 die IP Adresse ändern und via 'service network restart' das Netzwerk neu starten.
- In der UI-VM muss nun die Konfiguration auf die neue IP angepasst werden, das geschieht mit dem Befehl 'vcops-admin repair --ipadress [neue IP der Analytics VM]' Wenn die Analytics VM unter der IP bereits erreichbar ist werden in diesem Moment auch die Dienste bereits neu gestartet.
Ändern der UI VM
- Schritte 1-3 analog zur UI VM ausführen (Dienst stoppen, ifcfg-eth0 Datei anpassen und vcops-admin repair ausführen (Achtung: auch hier mit der IP der Analytics VM als Parameter.)).
- Das vCenter vcOps Plugin muss nun noch über die Änderung informiert werden, denn dies kommuniziert mit der UI VM.
- vcops-admin register update --vc-name [vc-name] --vc-server [https://vc-server/sdk] --username [vc-username] --password [vc-password] --forceÜber die Schalter '--collection-user' & '--collection-password' können auch Credentials für den Collectordienst mitgegeben werden, wenn dieser einen eigenen Systenmaccount verwendet.
Hinweis: wer dies nicht über die CLI tun möchte kann sich auch via Browser in den Adminbereich der UI VM einloggen (https://[IP]/admin) und im Tab 'Registration' über den Button Update die Registrierung aktualisieren.
Montag, 19. März 2012
VMWare WSX: Zugriff auf VM's via Browser
Als teil der jüngsten Technology Preview bin ich über einen sehr interessantes Feature gestolpert: WSX.
Das ganze ist derzeit nur als Teil der Linux Version von VMWare Workstation verfügbar, und benötigt eine Python Umgebung (2.6).
Was ist WSX?
Im wesentlichen ist das ganze ein Dienst, der über jeden Html5 fähigen Browser angesprochen werden kann, und über eben diesen die Konsolen von virtuellen Maschinen darstellt. Und das nicht nur von lokalen Maschinen, sondern auch veröffentlichte VM's anderer Workstation Instanzen und sogar VM's von fremden ESXi Hosts.
Wozu das ganze?
Schwer zu sagen wann, ob und in welcher Form das Ganze in echte Produkte von VMWare einfließt. Dennoch setzt sich hier wohl die Strategie von VMWare fort, Applikationen oder ganze Konsolen via Html5 verfügbar zu machen, siehe Projekt AppBlast.
Das ganze ist derzeit nur als Teil der Linux Version von VMWare Workstation verfügbar, und benötigt eine Python Umgebung (2.6).
Was ist WSX?
Im wesentlichen ist das ganze ein Dienst, der über jeden Html5 fähigen Browser angesprochen werden kann, und über eben diesen die Konsolen von virtuellen Maschinen darstellt. Und das nicht nur von lokalen Maschinen, sondern auch veröffentlichte VM's anderer Workstation Instanzen und sogar VM's von fremden ESXi Hosts.
Wozu das ganze?
Schwer zu sagen wann, ob und in welcher Form das Ganze in echte Produkte von VMWare einfließt. Dennoch setzt sich hier wohl die Strategie von VMWare fort, Applikationen oder ganze Konsolen via Html5 verfügbar zu machen, siehe Projekt AppBlast.
Montag, 12. März 2012
SmartSplat - eine GUI für die Checkpoint Konsole
Das kostenlose Tool SmartSPLAT (http://www.smartsplat.com/) hilft Administratoren bei der Arbeit mit Checkpoint Gateways auf Konsolenebene.
Wer ständig Fragen wie diese hat:
Ein Video gibt eine kurze Einführung:
Wer ständig Fragen wie diese hat:
- Wie lautet gleich die Syntax für einen gewissen Befehl?
- Wie setze ich einen Filter für fwmonitor
- Wie waren gleich die Befehle zum Cluster Troublesooting?
Ein Video gibt eine kurze Einführung:
Freitag, 9. März 2012
Ethernet-Bridge Tunnel zwischen zwei ASG Gateways
Mit der Version 8.300 ist es erstmals möglich, ein VPN auf Ethernet Ebene zwischen zwei ASG's zu erstellen.
Hierzu wird auf der ersten ASG unter "RED Management" -> "Client Management" eine Konfigurationsdatei erstellt. Diese wird danach auf dem Zweiten Gerät unter "RED Management" -> "Tunnel Management" importiert, gemeinsam mit der Angabe der IP des ersten Gerätes.
Wurde hier alles richtig gemacht, wird ein Tunnel zwischen den beiden ASG's aufgebaut.
Danach entsteht auf beiden Geräten ein neues Interface namens redsx bzw. redcx, wobei x eine Fortlaufende Nummer ist.
Dieses Interface lässt sich nun zur Erstellung einer Bridge mit dem internen Netzwerk verwenden was dann dazu führt, das die Netze hinter den beiden ASG's auf Ethernet Ebene über den gerade eben erstellten Tunnel verbunden werden.
Das heißt, es ein Netzwerk verwendet werden, welches sich über beide Standorte erstereckt.
WICHTIG: auch wenn es sich um einen Tunnel auf Ethernet Ebene handelt, kontrolliert die Firewall Engine den Verkehr zwischen den beiden Segmenten, d.h. es müssen ggf. Firewallregeln angelegt werden.
Hierzu wird auf der ersten ASG unter "RED Management" -> "Client Management" eine Konfigurationsdatei erstellt. Diese wird danach auf dem Zweiten Gerät unter "RED Management" -> "Tunnel Management" importiert, gemeinsam mit der Angabe der IP des ersten Gerätes.
Wurde hier alles richtig gemacht, wird ein Tunnel zwischen den beiden ASG's aufgebaut.
Danach entsteht auf beiden Geräten ein neues Interface namens redsx bzw. redcx, wobei x eine Fortlaufende Nummer ist.
Dieses Interface lässt sich nun zur Erstellung einer Bridge mit dem internen Netzwerk verwenden was dann dazu führt, das die Netze hinter den beiden ASG's auf Ethernet Ebene über den gerade eben erstellten Tunnel verbunden werden.
Das heißt, es ein Netzwerk verwendet werden, welches sich über beide Standorte erstereckt.
WICHTIG: auch wenn es sich um einen Tunnel auf Ethernet Ebene handelt, kontrolliert die Firewall Engine den Verkehr zwischen den beiden Segmenten, d.h. es müssen ggf. Firewallregeln angelegt werden.
Abonnieren
Posts (Atom)