Obwohl das neue Jahr nur wenige Tage alt ist, hatte es mit Meltdown und Spectre bereits einiges an sicherheitsrelevanten Bugs im Petto.
Auch in Juniper Produkten wurde jetzt eine schwerwiegende Sicherheitslücke entdeckt.
Immerhin ist der Workarround im Gegensatz zu Meltdown und Spectre einfach: Auf den betroffenen Geräten muss das Web-Management deaktiviert werden.
Das knuddelige Observium Maskottchen(tm)
Wer kennt sie nicht, die Qual der Wahl.
Monitoring und Graphing Werkzeuge gibt es zuhauf und jedes hat seine eigenen Vorzüge und Besonderheiten. Man hat meist die Wahl zwischen den „full blown“ Enterprise Tools wie HP OpenView und Solarwinds, den „Schweizer Bastelmessern“ wie Nagios & Friends oder anschaulichen Nischenlösungen wie PRTG. Viele dieser traditionellen Tools haben oftmals die Eigenschaft, dass erhebliche Anpassungen und Konfigurationsarbeiten im Tool von Nöten sind, um die gewünschten Erfolge zu erzielen.
Heute wollen wir euch einen weiteren Kandidaten für die „Qual der Wahl“ vorstellen, der oftmals im „Enterprise Umfeld“ noch nicht weit bekannt ist und gerade bei der Überwachung von großen, heterogenen Netzwerken seine Stärken ausspielen kann: Observium.
In der Überschrift steht zwar schon das Ergebnis, aber diesmal wollen wir euch mal einen Blick hinter die Kulissen von teamix gewähren, was so eine profane Überschrift an Arbeit nach sich zieht.
Vorgeschichte: Bei teamix hat es sich zur Trandition entwickelt, dass selbst wenn wir wegen Kindern oder Weihnachts-Anti-IT-Blues nicht mehr so zahlreich auf dem Congress vertreten sind zumindest dafür zu sorgen, dass die Jungs ein halbwegs solides LAN und WAN haben. Darum kümmern wir uns immer rechtzeitig mit den Organisatoren vom CCC darum, dass ausreichende Mengen an Leihequippment von Juniper bereit gestellt werden. Weiterlesen
Hat man die Aufgabe eine größere Menge (>10) an SRX Firewalls auszurollen, ist es sinnvoll sich vorher kurz Gedanken zu machen, wie man dies automatisiert und standardisiert bewerkstelligen kann. Das spart neben Zeit auch noch Nerven und viele mögliche Fehlerquellen.
Darum wollen wir euch heute zeigen welche Mittel Juniper uns da an die Hand gibt.
Hi @all,
heute Nacht ist es soweit: Wir erhalten eine zusätzliche Sekunde bzw. eine sog. Schaltsekunde (= Leap Second). Was heisst das? Die Zeit könnte je nach System/OS/Applikation auf eine Uhrzeit von 23:59:60 UTC (01:59:60 Uhr CEST) springen. Die letzte Schaltsekunde gab es im Jahr 2012.
Das Problem: Gewisse Systeme haben diesen Fall bereits bedacht, andere Systeme nicht. Die Auswirkungen unterscheiden sich je System und reichen von: „nicht betroffen“ über „100% CPU Last“ bis hin zu „Absturz des Systems“.
In diesem Blogartikel findet ihr eine gesammelte Liste mit Links, in der die nicht-betroffenen und betroffenen Systeme aufgelistet sind. Bitte prüft eure kritischen Systeme, ob sie von der „Leap Second“ betroffen sind, verwendet umgehend die angegebenen Workarounds und prüft am Besten heute Nacht nach 00:00:00 Uhr UTC (02:00:00 Uhr CEST) direkt, ob alle Systeme noch sauber laufen. Nicht, dass morgen das „böse Erwachen“ bzw. der „große Knall“ kommt und eure User nicht arbeiten können…
Hier die gesammelte Liste der Fa. teamix GmbH mit den Links bzgl. dem Thema „Leap Second“:
In meiner 3-teiligen Blogserie „Software-defined networking with VMware NSX“ möchte ich euch zeigen, wie man technisch
Zusätzlich zum technischen Deployment dieser Funktionen werde ich die einzelnen Basis“rollen“ und -funktionen der beteiligten NSX-Komponenten in jedem Kapitel beim entsprechenden Schritt erläutern. Wer weiterführende Informationen zu den einzelnen Komponenten und möglichen Konzepten benötigt, wird im VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide fündig.
Im ersten Teil der „Software-defined networking with VMware NSX“ Blogserie haben wir bereits die NSX Infrastrukturkomponenten implementiert. In diesem Kapitel möchte ich euch näher bringen, wie einfach es ist, ein neues logisches Netzwerk für virtuelle Maschinen zu erstellen, wie man ein hochverfügbares Edge Services Gateway ausrollt und deren NAT-Funktion nutzen kann.
In meiner 3-teiligen Blogserie „Software-defined networking with VMware NSX“ möchte ich euch zeigen, wie man technisch
(Wer noch nie etwas mit Software-defined networking zu tun hatte, findet hier eine Erläuterung, was ein sogenanntes „SDN“ ist.)
Zusätzlich zum technischen Deployment dieser Funktionen werde ich die einzelnen Basis“rollen“ und -funktionen der beteiligten NSX-Komponenten in jedem Kapitel beim entsprechenden Schritt erläutern. Wer weiterführende Informationen zu den einzelnen Komponenten und möglichen Konzepten benötigt, wird im VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide fündig.
Im 1. Teil der Serie möchte ich euch das Deployment der VMware NSX for vSphere Infrastrukturkomponenten näher bringen:
Gerade in größeren Unternehmensnetzwerken besteht die Notwendigkeit, dass Router oder Switches neben dem normalen In-Band Zugriff auch per seriellem Out Of Band Management bedient werden können, um im Störfall noch handlungsfähig zu sein.
Auf dem Markt existieren sehr viele sehr gute Lösungen, aber für den wirklich kleinen Geldbeutel ist in der Regel sehr wenig Gutes geboten – gerade wenn man auf Betriebssicherheit und „Frickelvermeidung(tm)“ Wert legt.
Dieser Artikel beschreibt ein konkretes Kundenprojekt, welches die Anforderung hatte, für möglichst wenig Budget, monatliche Mehrkosten und Komplexität einen sicheren Zugriff auf die seriellen Consolen von redundanten WAN-Routern zu ermöglichen.
Juniper stellt mit seiner „Branch SRX“ Serie für den normalen und gehobenen Mittelstand eine sehr flexible und auch preissensitive Plattform für Firewalling, VPN und Routing bereit.
Durch den sogenannten „Chassis Cluster“ besteht die Möglichkeit Hochverfügbarkeit zum administrativen Aufwand eines Einzelsystems zu bekommen, indem man zwei Firewalls zu einer logischen kombiniert.
Soweit die Theorie und auch die Praxis, wenn man sich genau an die entsprechenden KB-Artikel halten kann. Spannend wird es, wenn Anforderungen wie z.B. das Aufteilen des Clusters auf zwei Rechenzentren ins Spiel kommen.
Weiterlesen
Heute möchten wir Sie an ein etwas fortgeschrittenes Thema heranführen: BGP Route Reflection. Wir erklären, warum man so etwas braucht, wann man es idealerweise einsetzt, welche Devices man dazu verwenden kann und wie man diese konfiguriert. Dieser Artikel richtet sich an halbwegs erfahrene oder interessierte Netzwerker, die schon mit dem Border Gateway Protocol in Berührung gekommen sind, aber bisher noch nie einen Route Reflector brauchten – oder einfach nicht wussten, dass sie einen gebrauchten können.
Südwestpark 43
90449 Nürnberg
Mo. - Fr. von 09.00 - 17.00 Uhr