Mittwoch, 31. August 2016

Performance Optimierung für virtualisierte Checkpoint Systeme

Bei neu aufgesetzten Checkpoint Systemen auf Linux Basis sind einige Default Einstellungen nicht optimal, insbesondere was das Storage Handling angeht.

Der Checkpoint KB Artikel sk104848 gibt dazu nähere Auskunft, die Silver Bullet ist das Anpassen von Queue Tiefe und ausstehenden IO Requests.

echo "256" > /sys/block/sda/queue/nr_requests
echo "128" > /sys/block/sda/device/queue_depth

Das Ergebnis kann sich sehen lassen, die erzeugten IO gehen deutlich zurück, da der Hypervisor jetzt einzelne IOs des Gastsystems zusammenfassen kann. Die Policy Installation geht deutlich schneller.






Außerdem empfiehlt des sich, die Art des Schedulers anzupassen:

echo noop > /sys/block/sda/queue/scheduler

Die Einstellungen wirken sofort, sind aber nicht rebootfest, das heißt am besten in die /etc/rc.local eintragen.


ACHTUNG: sollte sich der Wert queue_depth nicht erhöhen lassen (mit  cat /sys/block/sda/device/queue_depth kontrollieren liegt das an einem ungeeigneten virtual SCSI Adapter. In dem Fall diesen ggf. ändern.

Montag, 22. August 2016

Reverse Tunnel mit ngrok

Heute habe ich ngrok (http://www.ngrok.com) kennen gelernt, ein kleines Werkzeug um schnell einen Remote Tunnel aufzubauen, um einen lokal im LAN laufenden Dienst (hinter einer Firewall/NAT Device) aus dem Internet erreichbar zu machen.

Dieses Bild beschreibt das am besten:




Dienstag, 15. März 2016

Passwörter von Checkpoint Gateways zurücksetzen, ohne physischen Zugang zum Gerät

Manchmal vergisst (oder verlegt) man doch mal ein Passwort. Das ist recht ärgerlich, da man dann physischen Zugang zu den Geräten braucht.

Im Falle von Checkpoint Firewalls ist das zurücksetzen von Passwörtern aller Gateways aber ein leichtes, solang die Gateways noch einem zentralen Management unterstehen.
Von diesem aus ist es möglich, Befehle direkt auf den Gateways auszuführen, ohne sich an denen nochmal extra authentifizieren zu müssen - man hat ja die SIC (secure internal comunication).

Bei Gaia Plattformen erfolgt der Reset wie folgt:

1. Zuerst generieren wir uns den Hash eines neuen Passworts. Das Tool fragt nach einem Passwort, und liefert genau diesen Hash

[ Expert@HostName]# /sbin/grub-md5-crypt

2. Dann stellen wir sicher, das die Konfigurationsdatenbank schreibbar ist.

[Expert@HostName]# $CPDIR/bin/cprid_util -server -verbose rexec -rcmd /bin/clish -s -c ‘set config-lock on override’

3. Zum Schluss ändern wir das admin Passwort mit folgendem Befehl:

[Expert@HostName]# $CPDIR/bin/cprid_util -server -verbose rexec -rcmd /bin/clish -s -c ‘set user admin password-hash [Password_Hash_aus _Schritt_1]’

4. Das Ganze geht auch für den Expert Modus

[Expert@HostName]# $CPDIR/bin/cprid_util -server -verbose rexec -rcmd /bin/clish -s -c ‘set expert-password-hash [Password_Hash_aus _Schritt_1]’

Bei den 1100 Appliances mit GAIA Embedded funktioniert das zurücksetzen etwas anders, Hier wird bei vorhandenem Expert Mode Passwort eine Datei angelegt, die sich mit dem Remote Befehl weglöschen lässt:

$CPDIR/bin/cprid_util -server 80.153.57.248 -verbose rexec -rcmd /bin/bash -c 'rm /pfrm2.0/config1/expert_pass_'

Danach kann das Expert Mode Passwort neu gesetzt werden.

Montag, 14. März 2016

SimpliVity Omnicube - Auf welchem Knoten liegt die Maschine?

Sobald man mehr als zwei OmniCube Knoten in einem Cluster hat stellt sich die Frage, auf welchem der Knoten eine virtuelle Maschine physisch liegt. Es gibt immer zwei OmniCubes, auf denen die virtuelle Maschine abgelegt ist.

Welche das sind, findet man über die Kommandozeile eines beliebigen Omnicubes raus:

svt-vm-show --output xml | xmlstarlet sel -T -t -m /CommandResult/VM -s A:T:U "name" -v "concat (platformName,'|',owner,'|',replicaSet)" -n |awk 'BEGIN {FS = "|"} ; {printf "%s\n Owner:  %s\n   Replicas: %s\n",$1,$2,$3; }' | sed `svt-federation-show --output xml |xmlstarlet sel -T -t -m /CommandResult/Node -s A:T:U "hostName" -v "concat ('s/',id,'/',hostName,'/g;')"` | grep -A 2 [VM Name]

Beziehungsweise, wenn von Interesse ist welcher Host welche VM's beinhaltet:

svt-vm-show --output xml | xmlstarlet sel -T -t -m /CommandResult/VM -s A:T:U "name" -v "concat (platformName,'|',owner,'|',replicaSet)" -n |awk 'BEGIN {FS = "|"} ; {printf "%s\n Owner:  %s\n   Replicas: %s\n",$1,$2,$3; }' | sed `svt-federation-show --output xml |xmlstarlet sel -T -t -m /CommandResult/Node -s A:T:U "hostName" -v "concat ('s/',id,'/',hostName,'/g;')"` | grep -B 2 [Hostname]

Mittwoch, 2. März 2016

Checkpoint Smart Event bekommt keine Events mehr

Manchmal kommt es vor, das Smart Event keine neuen Events mehr bekommt. Logfiles erreichen den Smart Event Server, kommunikation geht, alle Dienste laufen, aber Smart Event bleibt leer.

Dann ist manchmal die Event Queue voll:

# ls -l $RTDIR/distrib/* | wc -l

Wenn dort mehr als 10 - 15 Files drin sind, dann hilft es diesen Ordner zu leeren.

# evstop
# cd $RTDIR/distrib/ (Starts with "{" ) # rm --r * # evstart

Dienstag, 28. Oktober 2014

Horizon View Composer offline Update

Wichtiger KB:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2081888

Montag, 23. Juni 2014

VMware Horizon View 6 Upgrade - View Manager nicht erreichbar

Es gibt derzeit einen Bug beim Upgrade auf VMware Horizon View 6 in Umgebungen in welchen "vCenter Operations for View" verwendet wird.

In diesen Umgebungen läuft auf den View Connection Servern der Dienst "vCenter Operations for View Broker Agent"

Der Dienst ist vor Beginn des Upgrades zwingend zu beenden, da er Dateien im Zugriff hat die andernfalls nicht aktualisiert werden.

Vergisst man dies, quitiert der View Manager das nach dem Upgrade mit Logeinträgen wie:

2014-03-25T20:06:36.074-04:00 ERROR (0EDC-0C38) [ws_java_bridgeDLL] Java Bridge Managed failed on serviceClass = jniEnv->FindClass(serviceClassName._mstr())



Freitag, 22. November 2013

vCenter Operations - Max Number of Supported Resources

vCenter Operations kann in der Standardkonfiguration max. 10.000 Objekte verwalten. In hoch dynamischen Umgebungen, etwa mit virtuellen Desktops, in denen ständig neue VM's ausgerollt werden, entstehen leicht deutlich mehr Objekte.

Der Grund: vCenter Operations 'vergisst' nichts, und schleppt diese nicht existenten Objekte ewig mit.

Das Verhalten lässt sich leicht abschalten:

In der Analytics VM als root die Datei /usr/lib/vmware-vcops/user/conf/controller/controller.properties editieren. und die folgenden Eigenschaften anpasssen:

#Die automatische Löschung ungenutzter Objekte aktivieren
deleteNotExisting = true

#Dauer in Stunden die ein gelöschtes Objekt aufgehoben wird
deletionPeriodInHours=168

#In welchem Abstand in Stunden läuft der Müllsammler
deletionSchedulePeriod = 24

Donnerstag, 31. Mai 2012

Checkpoint Experience CPX 2012 Berlin - Tag 2

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.







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 ;-)

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"

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.


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.

Ändern der Analytics VM

Fangen wir mit der Analytics VM an.
  1.  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
  2. 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.
  3. 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

  1. 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.)).
  2. 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.

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:

  • 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?
der erhält eine grafische Oberfläche, welche eben diese Befehle auflistet und ausführt. Nützlich: "gefährliche" Befehle (wie etwa cpstoplassen sich erst nach zweimaliger Bestätigung ausführen.

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.