TLS: Eine kleine Übersicht

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.



Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.


Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank’ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.


Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.


Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.


https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.


Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.

 

 

 

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

GitLab Security Update Reviewed

NETWAYS schreibt die Sicherheit ihrer gehosteten Kundenumgebungen groß – daher kamen auch wir nicht um das Sicherheitsupdate in den GitLab Community Edition und Enterprise Edition Versionen herum.
GitLab machte Mitte März öffentlich, dass man auf eine Sicherheitslücke sowohl in der Community als auch in der Enterprise Edition gestoßen sei. Dabei soll es sich um sogenannte Server Side Request Forgery (SSRF) handeln, was Angreifern unter anderem den Zugriff auf das lokale Netzwerk ermöglich kann. GitLab löste dieses Problem nun durch ein Software Update und den Einbau der Option “Allow requests to the local network from hooks and services“, die per default deaktiviert ist und somit den Zugriff der Software auf das lokale Netz unterbindet.
Das Update auf eine neuere Version ist für viele Nutzer eine gute Lösung – allerdings nur, wenn diese keine Webhooks oder Services, die das lokale Netz als Ziel haben, nutzen. Denn wenn plötzlich die Webhooks und Services nicht mehr funktionieren und weder der Admin noch der User weiß, dass man bei der obigen Option einen Haken setzen muss, dann beginnt erst mal die Fehlersuche.
Fazit: Wer unbedingt auf Webhooks und ähnliches angewiesen ist, muss wohl oder übel vorerst mit der Sicherheitslücke leben.
Eingebaut wurde der Fix in folgende GitLab CE und EE Versionen: 10.5.6 / 10.4.6 / 10.3.9. Eine vollständige Übersicht an Releases findet man hier: GitLab Release

Managed Hosting bei NETWAYSGitLab CE und GitLab EE

NETWAYS Web Services – 30 Tage kostenfreies Testen von GitLab CE und GitLab EE

Nicole Lang
Nicole Lang
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Clever die Temperatur via Netzwerk messen – HWg-STE und Neon 110

Da noch diese Woche die Temperaturen an der 30°C-Marke kratzen, stellen wir noch einmal unsere beliebtesten Geräte zur einfachen Temperaturüberwachung vor. Spätestens wenn Sie bereits einen Hitzeschaden an Ihrer Hardware hatten, wissen Sie die Vorzüge einer günstigen Temperaturüberwachung zu schätzen.
HWg-STE_IP_SNMP_Thermometer_800
HWg-STE: Unser günstiger Allrounder – ab 149,00 € erhalten Sie ein digitales Netzwerkthermometer inkl. allem was Sie zum Messen benötigen (3m IP67-Temperatursensor, Netzteil, MIB-Table, Plugin) – Natürlich gibts die Messwerte via Webinterface, Mail oder als Ausgabe fürs Monitoring (Plugin). Natürlich bieten wir noch andere Ausführungen an, wie beispielsweise PoE, Push (Messwerte via SensDesk-Portal), Plus (2 dry-contact inputs)… Darüber hinaus haben Sie die Möglichkeit, einen weiteren 1-Wire Sensor an das HWg-STE anzuschließen.
neon
Neon 110: Unser Neon 110 gibt’s zum Tiefpreis für 99,00 € – auch inkl. Sensor  (Temperatur und Luftfeuchtigkeit) und Netzteil. Eine PoE-Version gibt es nicht, das Neon ist halt wie es ist 🙂 Dafür aber mit Weboberfläche, Mailalarmierung und Messwerten via XML und Monitoring-Plugin.
99 € sind ja auch fast geschenkt und einem geschenkten Gaul… Sie wissen schon.
Natürlich kommt es immer auf die individuellen Gegebenheiten an, aber falls Sie sich nicht sicher sind, helfen wir Ihnen natürlich gerne und jederzeit weiter. Falls Sie Interesse an Lösungen für große Umgebungen haben, stöbern Sie doch einmal im Store – Sie werden sicher fündig!
Übrigens: bis 15:30 Uhr bestellt und die Ware ist schon am nächsten Werktag bei Ihnen.
SMS-Alarmierung? Die haben wir auch, schauen Sie doch mal unsere Ethernet-SMS Gateways an!

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Neue Firmware für Neon110 verfügbar

Ab sofort steht für unser Neon110 Netzwerkthermometer eine neue Firmware (Version 1.5) bereit. Sie behebt einige Probleme in der Passwortverwaltung und lässt nun einige Sonderzeichen im Passwort zu. Vorher kam es zu Problemen, wenn Passworneon-110-netzwerksensor-fur-temperatur-und-luftfeuchtigkeitt Sonderzeichen enthielt. Das Gerät ließ sich in diesem Fall nicht mehr unlocken. Die Anforderung mit Sonderzeichen im Passwort kam bei einem unserer Kunden auf. Kurzer Hand haben wir die Anfrage mit dem Hersteller durchgesprochen und dieser lieferte eine entsprechende Anpassung via Softwareupdate. Die aktuelle Firmware für das Neon 110 können Sie sich hier herunter laden. In der Anleitung ist die Vorgehensweise für das Update ausführlich beschrieben.
Sie möchten auch eine angepasste Firmware für Ihr Gerät? Fragen Sie doch einfach einmal bei uns an, wir finden sicher eine Lösung für Ihre Anforderung.

neon-110-netzwerksensor-fur-temperatur-und-luftfeuchtigkeit (1)

Ansicht Webinterface Neon110

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Messen der Netzwerk Performance mit iperf

Quelle: http://www.nwlab.net


In einem Consulting- und Monitoring-Leben passiert es immer wieder das bestimmte Netzwerkverbindungen und Leitungen einfach nicht so tun wie sie eigentlich sollten. Besonders in Zeiten der Virtualisierung ist eine Bandbreite von 1GBit/s nicht mehr unbedingt 1GBit/s wert. So zeigt das Betriebssystem der virtuellen Maschine zwar dieses Gigabit an, jedoch tummeln sich auf dem physikalischen Host mehrere VMs, welche sich die verfügbare Bandbreite teilen müssen.
Man ist also gut beraten indem man den Durchsatz einfach selber misst. Hierzu empfiehlt sich unter Linux iperf! Das Tool iperf kann als Server und Client gestartet werden, wobei der benutzte Port mit der Option -p frei wählbar ist.
Starten des Servers:
root@server-2:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 35733

Start des Clients:
root@server-1:~# iperf -c 192.168.1.2
------------------------------------------------------------
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.1 port 35733 connected with 192.168.1.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 943 Mbits/sec

Des weiteren beherrscht iperf auch bidirektionale Test, Limitierung von Übertragungszeiten und übertragenen Bytes, womit es auch gut für automatische Messungen (z. B. Monitoring Plugins) geeignet ist.

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

SMS unter Linux versenden – so einfach geht's

CT63_USB_SetEin wichtiger Bestandteil von Monitoringsystemen wie Nagios oder Icinga ist die Alarmierung. Wir bekommen viele Anfragen, wie eine sichere Alarmierung neben der klassischen E-Mail realisierbar ist. Oft bleibt dabei nur noch die SMS übrig, da sie ein kostengünstiges, aber effektives Mittel zur Alarmierung ist.
Heute möchte ich einen kurzen Einblick geben wie man SMS unter Linux verschicken kann – darüber hinaus gibt es einen kurzen Einblick in die Konfiguration vom Monitoring-System zum Versand der SMS.
Ganz wichtig für den SMS-Versand ist ein GSM-Modem. Hier bieten wir unseren Kunden zwei verschiedene Klassen an.
Zum einen gibt es USB-Modems – diese sind kostengünstig aber nur direkt an den Monitoring-Server anzuschließen – die Nutzung ist entsprechend der Signalqualität eingeschränkt. An dieser Stelle empfehlen wir unseren Kunden das CEP-CT63 USB powered – es braucht nur noch eine SIM-Karte – sonst ist alles dabei. Wer gerne auf eine Lösung mit Netzteil zurück greift, sollte sich das CEP CT63 ansehen – dieses eignet sich zusammen mit unserer CAT5/USB Verlängerung.
Auf der anderen Seite bieten wir auch SMS-Gateways mit LAN-Anschlüssen an. Diese eignen sich für Kunden, die Ihre SMS von mehreren Applikationen aus verschicken möchten oder auf gewisse Zusatzdienste nicht verzichten wollen. Diese SMS-Gateways bieten alle eine HTTP-Api – eine SMS wird mittels eines Aufrufs Links verschickt – die parameter werden alle in der URL übergeben. Sie haben die freie Wahl zwischen dem MultiTech iSMS oder dem Braintower SMS Gateway S.
Das Braintower SMS Gateway S Advanced bietet darüber hinaus noch eine Mail2SMS Schnittstelle und Reverse-Nagios Checks. Wenn das Gateway den Monitoring-Server nicht mehr erreicht – so kann es eigenständig eine Alarmierungs-SMS verschicken. Falls Ihre Applikation nur in der Lage ist E-Mails zu versenden – so haben Sie mit diesem Gateway die Möglichkeit auch diese als SMS zu empfangen.
Kommen wir nun wie versprochen zur Einrichtung und dem SMS-Versand mit unserem CEP CT63 USB powered unter Linux.

  • bauen Sie die SIM-Karte wie in der Kurzanleitung beschrieben in das Gerät ein – schließen Sie die Antenne an das Gerät an
  • öffnen Sie Ihre Linux-Shell
  • führen Sie folgendes Kommando aus
  • tail -f /var/log/messages
  • schließen Sie nun das Modem an den Computer an
  • Das Gerät wird ohne weitere Treiber erkannt in unserem Beispiel als “ttyACM0”
  • notieren Sie sich Ihre Ausgabe
  • öffnen Sie die Konfigurationsdatei Ihrer zuvor installierten SMS Server Tools 3 mit einem Texteditor
  • vim /etc/smsd.conf
  • kontrollieren Sie die farblich hervorgehobenen Feld und passen Sie diese ggf. an.

SMS-Servertools-Configblau: Gerätename – muss in der Definition und Konfiguration gleich sein
rot: Devicename: diesem haben wir ein paar Schritte vorher in /var/log/messages ermittelt
orange: keep open auf yes setzen – dies lässt die Verbindung zum Modem geöffnet und vermeidet Probleme

  • Speichern Sie nun Ihre Konfiguration und starten Sie SMS Server Tools neu
  • /etc/init.d/smsd restart
  • Testen Sie die erfolgreiche Konfiguration, geben Sie folgendes Kommando auf der Befehlszeile ein, ersetzen Sie die Telefonnummer durch die, wohin Sie die SMS schicken möchten
  • sendsms +4917185247569 ‘Hello, how are you?’
  • Wenige Sekunden später bekommen Sie die SMS auf die angegebene Rufnummer zugeschickt – wenn nicht, suchen Sie nach dem Fehler in /var/log/smsd.log

In Nagios oder Icinga lässt sich das Modem mit folgender Konfiguration einbinden:
define command {
command_name    host-notify-by-sms
command_line    /usr/local/bin/sendsms  “$CONTACTPAGER$” “$HOSTSTATE$ alert for $HOSTALIAS$! Check nagios”
}

define command {
command_name    service-notify-by-sms
command_line    /usr/local/bin/sendsms “$CONTACTPAGER$” “$HOSTALIAS$n$SERVICEDESC$n$SERVICESTATE$nDate/Time: $DATE$ $TIME$n$SERVICEOUTPUT$”
}
Thats it – die Alarmierung läuft!
Wem die Alarmierung per SMS zu wenig ist – der sollte sich mal bei unseren Voice-Alarmierungen umsehen. Übrigens: für die SMS-Gateways mit LAN-Anschluss bieten wir auch einen Einrichtungsservice vor Ort an.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Neu im NETWAYS-Online Store: HW group HWg-PWR – intelligentes M-Bus Ethernet Gateway

HWg-PWR_25_main_1024
Auch diese Woche machen wir unsere Kunden wieder mit neuen Produkten glücklich! Ab sofort gibt es bei uns im Shop jetzt die Geräte der PWR-Reihe aus dem Hause HW-group.
Das sind:

HWg-PWR25_Mbus_gateway_snmp
Die jeweilige Zahl hinter dem Produkt beschreibt die Anzahl der maximal anschließbaren M-Bus Metern. Das PWR ist ein Gateway für digitale M-Bus Meter und ermöglicht so die Übertragung der Messwerte in das eigene Netzwerk. Darüber hinaus bietet es noch folgende Features:

  • Webinterface mit Passwortschutz
  • 8 potentialfreie Eingangskontakte
  • E-Mail Alarmierung
  • Datenlogger
  • Hutschienenkompatibilität
  • voll SNMP-Fähig
  • Auch für Nagios oder Icinga geeignet

Nachfolgend noch eine kleine Skizze für ein besseres Verständnis:
HWg-PWR25_M-Bus_icon_400
 
Preise, Details, eine Online-Demo und noch viel mehr gibt es auf der Artikelseite. Sie haben Fragen zum Produkt?  Kontaktieren Sie uns!

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

USB einfach verlängern – so geht's

usb-verlangerung-cat5e-bis-zu-60mEinige unserer Kunden, die zum Beispiel ein Teltonika Modem oder eine Ampel bestellen, ordern gleich noch unsere USB Verlängerung über CAT5e dazu. Der Vorteil von dieser Verlängerung gegenüber einer handelsüblichen Verlängerung ist ganz einfach: Mit “normalen” USB-Verlängerungen sind die Grenzen schnell mit 5 Metern Verlängerungskabel ausgeschöpft. Mit der USB-Verlängerung über CAT5e können ganz einfach bis zu 60 Meter USB-Erweiterung geschaffen werden. Natürlich muss man auch hier ein paar Rahmenbedingungen beachten, welche nachfolgend erläutert werden.
Die Verlängerung besteht aus 2 Einzelteilen. Das mit dem USB-Stecker wird direkt an den Rechner angeschlossen. Anschließend verbindet man diesen Teil mit dem CAT5e Kabel in der benötigten Länge und schließt an der anderen Seite den zweiten USB Wandler (mit der USB-Buchse) an. Zuletzt noch das USB-Gerät in die Buchse einstecken – fertig. Natürlich funktioniert das Ganze ohne zusätzlichen Treiber. Die 60 Meter Verlängerung beziehen sich auf den maximal möglichen Wert. Die reelle Länge hängt im Wesentlichen von 4 Faktoren ab.

  • Qualität des CAT-Kabels (es wird mindestens CAT5e benötigt)
  • Eigenverbrauch des USB-Gerätes
  • Stromversorgung des USB-Ports auf dem Hostsystem
  • passiver oder aktiver Endverbraucher

Im Versuch bei uns hat sich auch ein Vorteil mit einem aktiven USB-Hub am Ende der Verlängerung gezeigt, dieser macht den Endverbraucher sozusagen aktiv.
Nachfolgend noch die Vorteile der Verlängerung zusammen gefasst:

  • USB-Geräte die an einem Server angeschlossen sind, können durch die Verlängerungen an Orten mit besserem GSM-Empfang aufgestellt werden (z.B. Teltonika Modem)
  • Die Ampel, welche am Icinga-Server angeschlossen ist, kann an einem gut einsehbaren Ort platziert werden.
  • Die bestehende Infrastruktur-Verkabelung kann verwendet werden (mindestens CAT5e, ohne Switche Router etc. – Patchpanel funktioniert)
  • Funktioniert mit jedem Betriebssystem ohne zusätzlichen Treiber

Natürlich funktioniert das auch mit den von mir gestern vorgestellten USB-Sensoren.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Wunderwelt ssh

Jahrelalang habe ich ssh, wie wahrscheinlich die meisten von uns, nur zum administrieren und direkten Zugriff auf entfernte Server benutzt. Ab und zu vielleicht nochmal scp aber dann war’s das auch wirklich.
In den letzten Monaten habe ich aber so viele coole Funktionen von ssh kennengelernt, dass ich die hier jetzt nochmal sammeln möchte um nicht alles in der nächsten Woche wieder vergessen zu haben.

Authentifizierung

Ein Feature, das die tägliche Arbeit sehr erleichtert ist das authorized_keys file in ~/.ssh
Hier trägt man einfach den public key des users ein der sich auf diesen Host verbinden darf und alle Passworteingaben haben sich erstmal erledigt.

Portweiterleitung

Man kann ssh nicht nur für die direkte Kommunikation auf eine remote shell benutzen sondern alle Möglichen Dienste durch ssh tunneln und so Firewallgrenzen überspringen und sich die Arbeit erleichtern.
Ich benutze als Beispiel mal einen Webserver, der auf einem entfernten Host läuft und nur über einen weiteren Hop erreichbar ist. Die Firewall im Bild lässt bloß Port 22 auf HostA zu.

Aufbau ssh environment

ssh environment


Beispiel 1: Zugriff von HomeLaptop auf auf webserver.
Um dieses Szenarion zu realisieren kann man z.B. den Port 80 des webservers über HostA durch den ssh tunnel auf den lokalen Port 8080 des HomeLaptops weiterleiten.
Hierbei hat man zwei Möglichkeiten. Entweder man baut 2 Tunnel hintereinander, oder man sagt ssh wie es von LaptopHome zum webserver kommt.

# als erstes einen tunnel vom webserver zum HostA
user@LaptopHome:# ssh kalle@HostA
user@HostA:# ssh -L 8080:127.0.0.1:80 manfred@webserver
# als nöchstes in einem anderen terminal
user@LaptopHome:# ssh -L 8080:127.0.0.1:8080 user@HostA

Die Alternative finde ich persönlich viel schöner.
Man öffnet auf LaptopHome die ~/.ssh/config Datei und trägt folgenden Zeilen ein.

Host HostA
   User Kalle
   Hostname HostA
Host webserver
   User manfred
   # mit -a bewirkt dass der public key des gateway hosts auf dem Zielsystem sein muss
   ProxyCommand ssh -x -a -q HostA nc %h 22
   # kein -a bewirkt, dass der public key des initiierenden users auf dem Zielsystem sein muss
   ProxyCommand ssh -x -q HostA nc %h 22

Am Ende kann man mit einem kurzen Befehl den Tunnel aufbauen

user@LaptopHome:# ssh -L 8080:127.0.0.1:80 webserver

Einen Wunsch könnte man im Zweifelsfall noch haben. Eventuell möchte man vom HomePC auch auf den webserverzugreifen. Jetzt könnte man natürlich die .ssh/config Datei um ein weiteres ProxyCommand erweitern. Es gibt jedoch noch eine andere Möglichkeit. Mit Hilfe der ssh option -g kann man den lokalen Port allgemein Verfügbar machen.

user@LaptopHome:# ssh -L 8080:127.0.0.1:80 webserver -g

Und schon kann von HomePC auf http://LaptopHome:8080 zugegriffen werden.
Beispiel 2: Den Kollegen auf der Arbeit den Datenbankserver zur Verfügung stellen.
Der Datenbankserver HomeDB stellt im LAN eine mysql Datenbank auf Port 3306 bereit.

user@HomeDB:# ssh kalle@HostA -R 10000:HomeDB:3306

Das führt dazu, dass auf der man auf der Arbeit auf HostA, Port 10000 der mysql Dienst zur Verfügung steht.

magical bash

Das ProxyCommand Beispiel bedient sich, um die direkte Weiterleitung sicherzustellen, des Linux tools netcat alias nc. Es soll allerdings in der großen weiten Welt Systeme geben, auf denen kein netcat existiert. Im Beispiel müsste dieses auf HostA installiert sein. Sollte es sich bei diesem jedoch z.B. um ein älteres Solaris oder AIX System handelt so könnte es auch sein, dass dem nicht so ist.
Möchte man jetzt aber trotzdem das ProxyCommand nutzen gibt es noch eine Möglichkeit mit Hilfe der /dev/tcp Schnittstelle, die einem von BASH bereitgestellt wird, ein netcat nachzubilden.

Host HostA
   User Kalle
   Hostname HostA
Host HostA
   User Manfred
   ProxyCommand ssh webserver "/bin/bash -c 'exec 3<>/dev/tcp/HostA/22; cat <&3 & cat >&3;kill $!'"

Sollte ich noch weitere ssh magic herausfinden werde ich nicht zögern euch diese mitzuteilen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Mein Netzwerk in der Hand

Heim-Netzwerke werden immer größer und unübersichtlicher: LCD-Fehrseher, Receiver, Drucker, Telefone, AccessPoints, MediaPlayer, meist über DHCP eingerichtet, verrichten ihren Dienst ganz von allein. Ein Inventar solcher Internet fähiger Geräte pflegt man kaum für sich allein – denn die Freundin zeigt meistens wenig Interesse für die IT Infrastruktur im SoHo Bereich.
Auch ist mittlerweile die Zeit alter PIII Kisten im Keller, welche die Überwachung und Telefonie übernahmen, vorbei. Zu groß ist die Gefahr nach einem dist-upgrade erst Tage später festzustellen, daß einen die Großmutter nicht mehr telefonisch erreichen kann. Was aber tun?
Einige Android Wekzeuge für das SmartPhone schaffen hier Abhilfe z.B. Fing.
Features wie Network Discovery bieten Überblick in schnelllebigen Netzweken – Handys und Gastlaptops eingeschlossen. Diagnosehilfen wie Portscans (Was bietet mein Fernseher eigentlich so an), Pingtests oder TraceRoute runden das Ergebnis ab machen das Tool zu einem mächtigen Beobachter im Netz – Natürlich nur im eigenem…

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.