Results for "die zeit ist reif"

Administrators Toolbox: SSH

by Lorenz Kästle | Dec 23, 2021 | NETWAYS, Technology

SSH

“Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke.[1] Häufig wird es verwendet, um lokal eine entfernte Kommandozeile verfügbar zu machen, d. h., auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben, und die lokalen Tastatureingaben werden an den entfernten Rechner gesendet. Genutzt werden kann dies z. B. zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Servers. Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP.” [0]

Damit dürfte SSH den meisten Administratoren schon ein Begriff sein, zumindest wenn eine Maschine mit einem Unix im Netzwerk vorhanden war. Falls noch Unklarheit besteht: Wenn gelentlich PuTTY geöffnet wird, wird sehr wahrscheinlich SSH eingesetzt. Die Vorteile von SSH sind schnell benannt, es bietet schnelle, stabile, sichere (authentifiziert und verschlüsselt) und bandbreitensparsame Verbindungen ohne grossen Aufwand dafür betreiben zu müssen. Die Beginne des Protokolls liegen in den 90ern als damit mehrere klassische Unix-Dienste abgelöst wurden und seitdem gibts es nur selten grössere Neuerungen [1]. Dennoch sind einige sehr nützliche Funktionen in SSH recht unbekannt und dem soll hiermit Abhilfe geschaffen werden. Im folgenden gehe ich dabei auf zuerst ein wenig auf die Grundlagen ein und dann auf die etwas weniger bekannten Eigenschaften.

Das erste Mal

Ein typische SSH-Session beginnt mit der Eingabe des ssh-Kommandos und der Zieladdresse, also etwa eines DNS-Namens oder einer IP-Addresse:

# ssh 192.168.178.23

Ohne weitere Angaben wird dabei wird als Loginname der des aktuellen Nutzers verwendet, bei PuTTY wird man beim einwaehlen nach dem Loginnamen gefragt. Beim ersten Mal wird die folgende Meldung bzw. das Aequivalent auf PuTTY erscheinen:

The authenticity of host '192.168.178.23 (192.168.178.23)' can't be established.
ED25519 key fingerprint is SHA256:cBmwx2ZFgoK0EBvWf2CDtiu5a9hoPMn4xH4LjEnPH64.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Es ist an diesem Punkt bereits eine Verbindung zum Zielrechner aufgebaut und der öffentliche Schlüssel des Hosts abgerufen worden. Ohne jetzt auf die Details von asymmetrischer Kryptographie einzugehen zu wollen, muss dieser Mechanismus kurz erlaeutert werden. Bei der Installation erzeugt der SSH-Server ein oder mehrere Schlüsselpaare, ein Paar besteht aus einem öffentlichen und privaten Teil, diese sind mathematisch verbunden. Daten die mit dem öffentlichen Teil verschlüsselt werden sind nur mit dem privaten Teil entschlüsselbar. Mit dem privaten Teil können Daten signiert werden, was mit dem öffentlichen Teil verifiziert werden kann, dass heisst, die gesendeten Daten wurden genau so von etwas versandt, was Zugriff auf den privaten Schlüssel hat (als typischerweise die Person oder Maschine die den Schlüssel besitzt). Ein aehnliches Prinzip kommt auch an vielen Stellen beim Einsatz von TLS zum Tragen, also z.B. beim normalen Besuch einer Website (wenn oben in der Addressleiste des Browsers ein Schlosssymbol ist). Aufgrund eines Systems von Vertrauensankern kann jedoch der Browser schon mehr oder weniger garantieren, dass die Gegenstelle auch die gewünschte ist, ohne den Nutzer nach einer Bestaetigung zu fragen. Dieses Verfahren kommt bei SSH normalerweise NICHT zum Einsatz, dazu aber spaeter mehr.

Mit einem yes oder der Eingabe des Fingerabdrucks des öffentlichen Schlüssel des Ziels kann nun bestaetigt werden, dass man diesen als authentisch annimmt, bei PuTTY gibt es dementsprechende Knöpfe. Anmerkung: Diese Meldung wird, der Erfahrung nach, IMMER und ohne Verifikation ignoriert. Dies ist in einem kontrollierten Netzwerk (zuhause oder vielleicht auch in einem Betrieb) vermutlich unbedenklich, nicht jedoch, wenn die Verbindung nicht der eigenen Kontrolle unterliegt. Ein Angreifer kann sich an dieser Stelle zwischen den Nutzer und das Ziel schalten! Diese Verifikation sollte also mit Bedacht und mittels eines zweiten (gesicherten) Kanals erfolgen. Wenn man zum Beispiel über eine virtuelle serielle Schnittstelle der Virtualisierungssoftware Zugriff auf die Maschine hat, so kann man mit ssh-keygen den Fingerprint ermitteln:

# ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:cBmwx2ZFgoK0EBvWf2CDtiu5a9hoPMn4xH4LjEnPH64 root@generic-debian11 (ED25519)

Dabei ist zu beachten, dass heutzutage mehrere Schlüsselpaare vorhanden sind und in /etc/ssh/ das passende ausgewaehlt werden muss, hier ist das ED25519, es könnte aber auch z.B. RSA oder ECDSA sein. Dies sind verschieden Algorithmen, was hier erstmal ignoriert wird.

Anschliessend sollte die Passwortabfrage erscheinen bzw. unter PuTTY die Frage nach dem Loginname:

user@192.168.178.23's password:

Nach der Eingabe des Passwortes landet man dann auf der eingestellten Loginshell.

SSH-Schlüssel

Das Passwort jedesmal einzugeben ist natürlich unnötige Arbeit und zudem problematisch, da dann schlussendlich doch schlechte und/oder schon mal benutzte Passwörter verwendet werden. Die Lösung dafür ist recht einfach und schon vorhanden: SSH-Schlüssel. Das klingt ja erstmal wie das Thema weiter oben und tatsaechlich ist es in etwa auch das Gleiche, nur dass wir dieses Mal das Schlüsselpaar für einen Nutzer verwenden. Dafür wird zuerst mal ein Schlüsselpaar erzeugt:

ssh-keygen
Enter file in which to save the key (/home/user/.ssh/id_rsa):

hier kann nun ein gewünschter Dateipfad angegeben werden (alternativ gleich in den Befehl mit der Option -f)

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Wie die Ausgabe beschreibt, kann hier eine Passphrase gesetzt werden, dies ist natürlich empfehlenswert. Waehrend einer laufenden Nutzersitzung, kann der Schlüssel einem SSH-Agenten hinzugefügt werden, so dass das Passwort nur einmal eingegeben werden muss.

Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa
The key fingerprint is:
SHA256:NY92co2ANzzBp6P82ILfZpmRALePZJxvU1Yxpt5UgGk user@host
The key's randomart image is:
+---[RSA 3072]----+
|         ..  o=o.|
|      . .o..Eo.o |
|       +.oO+...  |
|        BooOo=   |
|       +S*+=* o  |
|        +.B+     |
|       . = =     |
|      . o.B      |
|       ..+.      |
+----[SHA256]-----+

Der weitere Output zeigt dann noch den Erfolg der Operation an und stellt (aus irgendwelchen Gründen) den Fingerprint graphisch dar. Der Schlüssel kann dann auf die Zielmaschine kopiert werden:

ssh-copy-id -i $PFAD_ZUM_OEFFENTLICHEN_SCHLUESSEL $USER@$ZIEL

(wobei natürlich alle mit $ beginnenden Parameter durch die realen Werte ersetzt werden müssen) und dann benutzt werden mittels:

ssh -i $PFAD_ZUM_PRIVATEN_SCHLUESSEL $USER@$ZIEL

Da der Aufruf immer noch recht lang ist, kann man in einer Konfigurationsdatei ein paar Parameter setzen. Die Standardkonfigurationsdateien auf Unix-Systemen ist vermutlich ~/.ssh/config.

Host bla
    User $USER
    Hostname $ZIEL
    IdentityFile $PFAD_ZUM_PRIVATEN_SCHLUESSEL

Danach ist der Aufruf nur noch ssh bla. In PuTTY ist das Erstellen von Schlüssel und den Konfigurationseintraegen durch Klicken möglich.

Dateitransfer

Es gibt hier verschiedene Möglichkeiten:

1.scp Die Verwendung von scp ist relativ simpel und auch brauchbar für Skripte:

scp $LOKALE_DATEI $ZIELHOST:$ZIELORT_ODER_DATEI
scp $ZIELHOST:DATEI $LOKALE_ZIEL_DATEI

2.sftp Die Verwendung erinnert an die des Kommandos ftp und ist interaktiv, inklusive Verzeichniswechsel usw.

3.sshfs Eine FUSE-Implementierung von einem Dateisystem über SSH.

sshfs $ZIELHOST:$PFAD $LOKALES_VERZEICHNIS

haengt $PFAD des $ZIELHOST im $LOKALES_VERZEICHNIS ein.

Netzwerk

Ein paar sehr nützliche Features sind die Netzwerkoptionen von SSH, z.B.:

ssh -L 5555:bla:80 foo

transportiert alle Anfragen die an den lokalen Port 127.0.0.1:5555 gehen über SSH an den Host foo von wo aus sie über den normalen Netzwerkpfad (ohne SSH-Tunnel) dann auf Port 80 auf bla gehen. Sehr nützlich, wenn man etwa ein nur lokal erreichbares Webinterface besuchen möchte.

ssh -R 5555:localhost:6767 $ZIEL

Das Gegenstück, öffnet auf dem $ZIEL den Port 5555 und leitet in an den lokalen Port 6767 weiter.

ssh -J hop1,hop2 ziel

“Springt” per SSH über hop1 und hop2 zu ziel. Natürlich muss sich der Nutzer auf allen Systemen authentifizieren, aber benötigt keine Shell. Es können damit reine Gateways benutzt werden, die als “Eingangstor” in ein Netzwerk dienen.

ssh -D 6767 $ZIEL

Öffnet eine dynamische Port-Weiterleitung auf $Ziel. Kann auch von Browsern als SOCKS Proxy verwendet werden.

ssh $ZIEL -o "ProxyCommand=nc -X connect -x $PROXYHOST:$PROXYPORT %h %p"

Verbindet sich über den (HTTP-)Proxy $PROXYHOST auf Port $PROXYPORT zum $ZIEL

SSH-Zertifikate

Während die bisherigen Abschnitte SSH-Grundlagen und diverse Nutzungsmöglichkeiten behandelt haben, stellt sich dem interessierten Lesen oder auch dem fortgeschrittenen Nutzer schon die Frage nach der Skalierung solcher Setups. Die Authentizität einer Verbindung ist ja theoretisch durch die Schlüssel sicher gestellt, aber rein praktisch ist da die Problematik, dass man ja erstmal alle Host-Schlüssel in seiner ~/.ssh/known-hosts sammeln muss. Bei großen und dynamischen Umgebungen ein Sysiphos-Unterfangen, dass recht bald in Problemen resultiert. Das gleiche gilt natürlich für die Schlüssel der Nutzer. Da diese lokal für den sshd (den SSH-Daemon) verfügbar sein müssen, müssten potentiell ALLE Schlüssel ALLER Nutzer auf ALLE relevanten Maschinen kopiert und dort natürlich auch aktualisiert werden. Netzwerkdateisysteme sind natürlich ein Aus- oder Umweg, aber bergen das Risiko, dass bei einem Ausfall dieser Infrastruktur der Login überall sonst nicht mehr funktioniert. Naheliegenderweise gibt es dafür zumindest teilweise eine Lösung. In SSH gibt es nämlich auch Komponenten für eine Zertifikatsinfrastruktur. Diese ähnelt ein wenig der von TLS, ist jedoch deutlich rudimentärer und simpler. Dabei lassen sich SSH-Zertifizierungsschlüssel erstellen, die sowohl Host- als auch Nutzerschlüssel signieren können. Ein Nutzer muss dann nur noch dem Zertifizierungsschlüssel vertrauen um einen Host zu verifizieren und ein Host um einen Nutzer zu authentifizieren.

Der Zertifizierungsschlüssel besteht dabei, wie bisher bei den anderen Schlüsseln, auch wieder aus einem Schlüsselpaar:

# ssh-keygen -f ./ca_host_key -t ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./ca_host_key
Your public key has been saved in ./ca_host_key.pub
The key fingerprint is:
SHA256:3UmaB6K4wy/obEBhmeGYWZIKnlvF9emPY8xQgZmygPM user@host
The key's randomart image is:
+--[ED25519 256]--+
|.o* . ..+.       |
|=% . + +. o      |
|O.= o o .+. .    |
|.+ E o .oo * .   |
|. o . ..S.+ +    |
|.. . .  + o.     |
| . .+    * .     |
| .o .o  . .      |
| oo  ..          |
+----[SHA256]-----+

# cat ./ca_host_key.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICCdmjMLjw+WGI+Aj1FUHUCG16daqoyeet+GZWi1O/TS user@example.com

und damit können nun Host- oder Nutzerschlüssel signiert werden. Der Parameter -I enthält dabei die certificate_ID welche im Prinzip frei wählbar ist, aber für diesen Fall (der Host-Zertifikate) auf den eindeutigen Hostnamen gesetzt werden sollte.

# ssh-keygen -s ca_host_key -I testhost.local -h /etc/ssh/ssh_host_ecdsa_key.pub
Signed host key /etc/ssh/ssh_host_ecdsa_key-cert.pub: id "testhost.local" serial 0 valid forever

Dabei wird eine neue Datei host_ecdsa_key-cert.pub erstellt, die den unterschriebenen öffentlichen Schlüssel enthält, das sieht dann ungefähr so aus:

# cat ssh_host_ecdsa_key.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMuXZN6or69chS+ZT6++P37JeRC5km+cIbzXnfCos9hvJ9jUbB+Becozdcmhfhj6Udg6FfxwDJqc5WaKHA0uErY= root@example.com
# cat ssh_host_ecdsa_key-cert.pub
ecdsa-sha2-nistp256-cert-v01@openssh.com AAAAKGVjZHNhLXNoYTItbmlzdHAyNTYtY2VydC12MDFAb3BlbnNzaC5jb20AAAAgtZ2LJPOCioVR9tG19Zekk3x6qru6bYXCIlMXsKSc43QAAAAIbmlzdHAyNTYAAABBBMuXZN6or69chS+ZT6++P37JeRC5km+cIbzXnfCos9hvJ9jUbB+Becozdcmhfhj6Udg6FfxwDJqc5WaKHA0uErYAAAAAAAAAAAAAAAIAAAAOdGVzdGhvc3QubG9jYWwAAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAADMAAAALc3NoLWVkMjU1MTkAAAAgIJ2aMwuPD5YYj4CPUVQdQIbXp1qqjJ5634ZlaLU79NIAAABTAAAAC3NzaC1lZDI1NTE5AAAAQFgq6IqNBRjJrysFdBHHceU83AXF0Vg13uq17ZJXn2hk98H6rRnLCV8XvOtRd9o1bxtc8xQ7Poigw4wuRbMjigY= root@testhost.local

Nun fehlt nur noch ein Eintrag in die known_hosts Datei:

@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICCdmjMLjw+WGI+Aj1FUHUCG16daqoyeet+GZWi1O/TS

Damit werden alle Host-Schlüssel akzeptiert, die von einem Host mit dem Namensmuster *.example.com kommen und mit dem Zertifizierungsschlüssel signiert sind.

Dasselbe lässt sich prinzipiell gleichartig auf Nutzerschlüssel übertragen, auf ein Beispiel wird hier nun verzichtet um diese Vorstellung hier knapp zu halten. Jedoch gibt es den einen oder anderen Punkt, der erwähnt werden sollte: Da es sich hier nicht um TLS handelt und die ganze Struktur sehr viel schmaller ist, ist das Widerrufen von Schlüsseln anderst gelöst. Es gibt keine zentrale Stelle die Revocation Lists führt, die abgefragt werden können. Eine solche Liste muss sich lokal auf der Maschine befinden, also etwa mit Ansible, Puppet, Salt, Chef… plaziert und aktualisiert werden. Dies ist natürlich gerade für Nutzerschlüssel zu empfehlen. Zusätzlich sollte erwähnt werden, dass es durchaus die Möglichkeit gibt, das System zu erweitern und eigene Erweiterungen zu erstellen, beispielsweise mit der AuthorizedKeysCommand-Direktive in der sshd-Konfiguration die einem erlaubt ein eigenes Programm zu erstellen/verwenden um die Nutzer zu authentifizieren und damit wiederum eine Anbindung an Datenbanken oder Netzwerkdienste.

Rekapitulation

SSH als Protokoll und mit den gängigen FOSS-Implementierungen ist ein sehr mächtiges Werkzeug für den Umgang mit vernetzten Computern und leider, zumindest in meiner Wahrnehmung, unterschätzt. Nicht nur lassen sich enorm viele Aufgaben damit erledigen, es ist dabei auch flexibel, schnell und ressourcensparend. Etwas, was in einer Zeit der eher penetranten, langsamen Anwendungen als Abwechslung doch mal wieder angenehm ist. Die Netzwerk-Tricks erlauben das sinnvolle Arbeiten, auch in Umgebungen mit eher kreativen Firewall-Regeln und mit ein wenig Einrichtung ist der Zugriff auf entfernte Rechner kaum noch von dem auf den eigenen, lokalen zu unterscheiden (ich würde zu eine Shell-Prompt raten, die dies farblich hervorhebt, es kann leicht zu Verwirrungen kommen). Mit ein bisschen zusätzlicher Arbeit kann das System auch gut skaliert werden. Und das schönste: Es ist schon da! Die Chancen sind gut, dass es bereits auf jedem Linux-System im Netzwerk vorhanden ist (und auf dem meisten aktiv) und auf jedem anderen Unix-System ist es sehr sicher verfügbar. Sogar auf den Windows-Systemen ist relativ einfach zu installeren (Microsoft bietet einfach auch OpenSSH als Dienst zur Installation an). Es lohnt sich hier auf jeden Fall mal ein wenig Zeit in das Setup zu investieren um die Arbeit ein wenig angenehmer und flüssiger zu gestalten und ich hoffe, dass dieser Artikel ein paar Anstösse in diese Richtung gegeben hat.

Danksagung

An dieser Stelle möchte ich kurz Dank ausrichten an das Entwicklungsteam von OpenSSH die das Protokoll und die wohl populärste Implementierung warten und stetig weiterentwickeln und etwas gebaut haben, was mir und vielen anderen den sinnvollen Umgang mit vernetzten Computern ermöglichen. Zusätzlich vielen Leuten im Internet die mir mit vielen Beispielen, Anleitungen und Erklärungen geholfen haben an diesen Punkt zu kommen, was sonst so nicht ohne weiteres möglich gewesen wäre.

Quellen

https://de.wikipedia.org/wiki/Secure_Shell
https://www.openssh.com/history.html
https://www.openssh.com/
https://wiki.archlinux.org/title/OpenSSH
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-ssh-configuration
https://wiki.debian.org/SSH

Lorenz Kästle

Systems Engineer

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Read more from Lorenz and meet the Team

Azubi Tagebuch: Das erste Ausbildungsjahr ist um

by Andre Paskowski | Nov 30, 2021 | NETWAYS, Soziales

Azubi Tagebuch: Das erste Ausbildungsjahr ist um

Hallo mein Name ist André und ich bin jetzt im zweiten Jahr der Ausbildung zum “Fachinformatiker für Systemintegration” bei der Firma NETWAYS. Aber fangen wir doch der ‘Einfachheit’ halber auch am Anfang an. Grundlegend würde ich sagen, dass ich ohne größere Vorkenntnisse in mein jetziges Berufsfeld gestartet habe. Das heißt zwar nicht, dass ich einen Blind-Start hatte, jedoch würde ich mein Wissen zu diesem Zeitpunkt keinesfalls als ‘fachlich’ bezeichnen. Mein vorheriger Berufszweig hat zudem nichts mit Informatik zu tun gehabt. Also war es nur natürlich, dass bei der Bewerbung, dem darauf folgenden Bewerbungsgespräch und nach dem Ausbildungsstart immer wieder Unsicherheiten auftraten. Man stellt sich Fragen wie:

– Schaffe ich das?

– Kann ich dem Ganzen gerecht werden?

– Was wenn ich einen Fehler mache?

Aber jetzt mal ehrlich, wir Menschen machen uns manchmal einfach zu viele Sorgen. Noch befindet sich mein Kopf auf dem

dafür vorgesehen Hals und das, obwohl ich sicherlich ein paar “kleinere” Fehler gemacht habe. Und wenn ich etwas nicht schaffe, dann frage ich eine:n Kollegen:in. Wie man vielleicht schon aus diesen mit leichtem Humor an

gereicherten Zeilen lesen kann, geht es mir schon seit Tag eins, ziemlich gut in meiner Firma.

Genug geredet – Was habe ich meinem ersten Jahr alles so gelernt?

Ich arbeite bei “ITSM” dem “IT Service Management”, d. h. wir sind für alle internen Angelegenheiten zuständig.

“Mein Name ist Admin, Sys- ach lassen wir das.”

Ich habe in meinem ersten Ausbildungsjahr einen großen Teil unserer Server-Welt kennengelernt. Der Aufbau, warum sich wo was befindet und wie ich darauf zugreifen kann. Linux war für mich persönlich auch ein komplett neues Universum, mit welchem ich mich auseinandersetzen musste. Die Nuss ist auch noch nicht ganz geknackt, aber wie man so schön sagt: “Rom wurde auch nicht an einem Tag erbaut”. In einer Server-Welt kommt natürlich auch die passende Hardware zum Einsatz. Ich habe hauptsächlich mit klassischen Netzwerkgeräten wie Switches, Server und Kabel zu tun. Zudem kommen die Geräte der Endbenutzer wie z. B. deren Laptops oder Arbeitsplatz Materialien, wie Tastaturen, Mäuse,

Telefone und Drucker hinzu. Wirklich cool war der Verbau und das Einrichten neuer Sicherheitskameras im Büro.

Des Weiteren hatte ich in diesem Jahr mit Containern/Docker, Ansible, VMs, ActiveDirectory, programmieren von kleineren Scripten und vieles mehr zu tun. Und damit hört die Liste noch lange noch nicht auf, jedoch verzichte ich aufgrund der Länge dieses Blogs auf weitere Auflistungen.

Was war der größte Schock, den ich bisher in meiner Ausbildung hatte?

Das ist relativ einfach, weil ich mich noch ganz klar an diesen einen Moment erinnere. Ich habe an diesem schicksalhaften Tag in unserem Kesselhaus einen Cloud-Key installiert, der unsere dortige Netzwerkstruktur überwachen und verwalten sollte. Ich hatte von Anfang an Probleme mit dem Gerät, da es sich erst nicht updaten lassen wollte und sich dann im Webinterface immer wieder verabschiedet hat. Probleme die eben gerne mal auftreten, wenn man ein neues Gerät in die schon vorhandene Netzstruktur migrieren möchte. Also sage ich dem Gerät den Kampf und nur um nach einem scheinbaren Erfolg zu merken, dass sich die komplette Netzkonfiguration im Kesselhaus verabschiedet hat. Zehn gefühlte Herzinfarkte in meinem kurzen Azubi-Leben später meldete ich mein Problem also meinen Kollegen. Wie oben schon verraten habe ich mich nicht von meinem Kopf verabschieden müssen. Im Gegenteil mein Kollege setzte sich gemeinsam mit mir hin und wir haben das Netz zusammen wieder konfiguriert. Trotzdem, diese paar Sekunden würde ich als den schlimmsten Schock meiner bisherigen beruflichen Karriere bezeichnen.

Was war für mich das absolute Highlight meines ersten Ausbildungsjahres?

Um diesen Punkt voll auskosten zu können, muss ich zwei Aspekte aufzählen

Fangen wir mit einem Arbeitsablauf an, der für mich ein absolutes Highlight war. Für manche Menschen mag Hardware ein notwendiges Übel sein. Auf mich trifft das nicht zu, ich liebe Hardware. Das mag auch daran liegen, dass ich in meiner Freizeit so ziemlich jeden PC meines Freundeskreises konfiguriert und zusammengebaut habe. Von einem normalen Desktop bis hin zu einem SLI Full-Custom-Waterloop PC war da alles dabei. Als ich das Erste mal in meinen Leben einen Server unter die Finger bekam, war meine erste Frage, ob ich diesen öffnen dürfte. Diesen moment kennen viele bestimmt als Produktwerbung. 360° Kamerafahrten um ein Produkt. Ungefähr so hat sich mein Kopf um ein so “triviales” Produkt wie einen Server gedreht. Trotzdem war es für mich ein toller Moment, der sich in jedem neuen Stück Hardware widerspiegelt.

Jetzt sagte ich bereits, dass ich auf diese Frage zwei Momente als Antwort geben möchte, denn neben dem Arbeitsleben bei NETWAYS gibt es auch ein soziales Leben. Und den Höhepunkt dieser Interaktionen hatte ich auf dem Sommerfest, welches Dank 3G-Regeln und freiwilliger Impfung durch den Arbeitgeber möglich war. Leckeres Essen, Top-Kollegen und ein schönes Ambiente sorgten für einen schönen Abend an welchem man fachsimpeln, genießen und sich austauschen konnte.

Gespannt ins neue Jahr.

Rückblickend kann ich sagen, dass ich ein Jahr voller Herausforderungen hinter mir habe. Aber diesen Aufgaben musste ich mich nicht allein stellen, sondern hatte immer ein Team hinter mir, das mich unterstützt hat. Mein Wissensstand hat sich in diesem Jahr merklich erweitert und ich bin mir sicher, dass noch viele lehrreiche Lektionen folgen werden. Ich bin froh bei NETWAYS zu arbeiten da ich die Kehrseiten vieler andere Firmen kenne. Müsste ich einen Menschen der diesen Beruf ausüben möchte eine Firma für eine Bewerbung empfehlen würde ich ohne zu zögern den Namen NETWAYS weitergeben.

Soweit ein kleiner Einblick in das erste Jahr eines Azubis bei NETWAYS. Ich hoffe, ich konnte ein wenig unterhalten und wünsche noch eine angenehme Zeit auf unseren Blog.

André Paskowski

Systems Engineer

Als Fachinformatiker für Systemintegration bei NETWAYS kann André seine Leidenschaft für Technologie voll ausleben. Vor seiner Ausbildung hat er bereits im sozialen Bereich gearbeitet und dort wertvolle Erfahrungen gesammelt. Sein beruflicher Werdegang hat ihn nicht davon abgehalten, seine großen Leidenschaften neben der Arbeit zu verfolgen: Als begeisterter Gamer findet André Entspannung und Herausforderung in virtuellen Welten, während er sich in seiner restlichen Freizeit gerne in strategischen Tabletop-Spielen verliert. Aber seine Interessen beschränken sich nicht nur auf digitale und physische Spiele. Als stolzer Besitzer von Reptilien als Haustieren ist er fasziniert von der exotischen Tierwelt und investiert viel Zeit und Sorgfalt...

Read more from André and meet the Team

Grafana 8 ist da!

by Marianne Spiller | Jun 17, 2021 | Graphite & Grafana

Ich weiß nicht, wie es euch geht — ich bin ein großer Grafana-Fan, vom ersten Moment an. Ob es nun darum geht, die per Icinga2 oder Prometheus gesammelten Daten darzustellen, das Smart Home zu visualisieren oder schlimmstenfalls den Gewichtsverlauf des Kindes für den Kinderarzt aufzubereiten: Grafana ist super. Wie Torkel Ödegaard in seinem Blogpost vom 8. Juni 2021 bekannt gab ist Grafana nun in Version 8 veröffentlicht.

Und dieses Update ist einen oder durchaus auch zwei Blicke wert: so wurden die verfügbaren Panels beispielsweise zum Teil überarbeitet und ergänzt — und allein für das „Status history panel“ habe ich direkt schon mehrere Anwendungsfälle im Hinterkopf. Außerdem ist das „Real-time streaming“ nun fester Bestandteil der Applikation und wurde erweitert: sende deine Updates über Websocket-Verbindungen aus MQTT-Datenquellen, über Streams von cURL/ Telegraf oder über den neuen Endpunkt /api/live/push in Echtzeit an deine Dashboards. Die Macher versprechen, das gehe ganz einfach — und erste Berichte Neugieriger bestätigen das bislang vollumfänglich.

Besonderes Augenmerk solltest du auch auf das „Alerting“ legen: dieses wurde vollständig überarbeitet und bietet nun eine übergreifende und durchsuchbare Oberfläche für Alarmmeldungen sowohl aus Grafana als auch aus Prometheus-kompatiblen Datenquellen, was neben Prometheus selbst auch Tools wie beispielsweise Cortex oder Loki einschließt. Und dass Alarme von Dashboards entkoppelt wurden und nun auch eine voll funktionsfähige API zur Verfügung steht dürfte ebenfalls so manchen überaus fröhlich stimmen.

Ich habe bislang zwei Instanzen — eine „gedockerte“ sowie eine über Pakete installierte — jeweils von 7.x auf 8.0.2 angehoben; verwendete Datenquellen waren Prometheus, Graphite und InfluxDB. Beide Upgrades liefen nahtlos durch, und auch wenn ich es nicht mit Zahlen belegen kann scheint die „Schwuppdizität“ (danke, Jan!) tatsächlich eine bessere zu sein als zuvor. Allerdings werde ich bei Gelegenheit ein wenig Zeit investieren müssen, um die einzelnen Panels zu prüfen und gegebenenfalls umzustellen — beispielsweise von „Graph (old)“ auf „Time Series“, so noch nicht geschehen. Aber da hältst du ohnehin bestimmt mehr Ordnung als ich, oder? 😇

Wenn du noch mehr über die neusten Änderungen erfahren möchtest, dann wirfst du am besten einen Blick in die Release Notes, schaust dich in der von Grafana bereitgestellten Demo auf play.grafana.org um — oder installierst das Update zeitnah. Es lohnt sich.

OpenBugBounty.org – was ist das?

by Tim Albert | Mar 19, 2021 | Security

So wie es heise und anderen auch schon passiert ist, hatten wir kürzlich zwei Mails von openbugbounty.org im Postfach.

Im ersten Moment wunderten wir uns, was das denn für ein Laden sein könnte, aber am Ende gestaltete sich das ganze jedoch positiv.

Kommt erstmal überraschend

Über die nicht-kommerzielle Plattform haben uns unabhängig voneinander zwei IT-Security Spezis kontaktiert. Beide hatten unterschiedliche Lücken auf einer unserer WordPress-Installationen entdeckt und anstatt diese auszunutzen (sehr niedriger Impact) oder zu verkaufen (so sie denn Käufer:innen gefunden hätten), wählten sie den Weg des Responsible Disclosure mit einer Frist von 90 Tagen. Dieses Verhalten ist vergleichbar zum bekannteren Google Project Zero.

Responsible Disclosure wird oft kritisiert

Im Grunde gibt dieses Vorgehen den Betroffenen Zeit, den Fehler zu beheben, bevor dieser öffentlich gemacht wird und somit vielleicht auch einen größeren Schaden allein durch die Reichweite anrichten kann. Sobald der Fehler behoben ist, wird der Report veröffentlicht, damit auch andere Betroffene entsprechende Maßnahmen ergreifen können.

Einschub: oft wird Responsible Disclosure kritisiert, gerne auch Bug Bounty allgemein. Zum einen nimmt man den Betroffenen aus der Pflicht sofort zu handeln, wobei je nach Schwere der Lücke Zeit ein durchaus entscheidender Faktor sein kann. Und es ist ja auch nicht gesagt, dass nur exakt eine wohlmeinende Person diese Lücke findet und kein Schindluder damit treibt. Zudem könnte sich eine gewisse Laxigkeit im Bezug auf Datensicherheit einstellen, wenn ja eh ein zusätzlicher Feedbackkanal zur eigenen verhunzten Installation zur Verfügung steht. Und solange von der Seite kein Input kommt, kann das eigene System ja keine sooo schweren Lücken haben, oder?

Wie reagieren?

Wir standen am Anfang auch erst vor der Frage „wie reagieren?“, aber NETWAYS-typisch haben wir dann halt einfach mal gemacht. Also via Twitter bei openbugbounty.org eingeloggt (was machen eigentlich Leute ohne Twitter-Account? Solche soll es ja mittlerweile auch in NETWAYS-orange geben) und die Kontaktdaten der Spezln geholt.

Eine kurze Mail später hatten wir die Details, den möglichen Impact und eine Behebung für die Lücke im Postfach. Natürlich wurde das nochmal verifiziert, wobei seitens openbugbounty.org bereits eine Verifikation erfolgt. Die Fehlerbehebung war dann auch schnell erledigt und wir konnten die Lücken auch gleich noch auf unseren anderen WordPress-Installationen überprüfen.

Der längste Teil der Geschichte war am Ende die Entscheidung, was tun wir mit der Meldung, wie belohnen wir die beiden am besten und schreibe ich diesen Blogpost auf deutsch oder englisch.

Die Plattform selbst war bei diesem Prozedere nur als Kontaktvermittlerin involviert und hat von uns exakt nichts außer diesen Blogpost erhalten. Ihre Eigenpräsentation hat das Projekt auch hochgeladen. Unsererseits war die Erfahrung also gut, die Kommunikation war immer schnell und offen und es besteht hier wirklich kein Grund zur Furcht.

Details zu den Lücken

Wer bis hier hin durchgehalten hat, ist sicher auch neugierig, was das denn nun für Lücken waren. Die erste ermöglichte es, via WordPress API alle User unserer Installation abzufragen (nur GET, kein POST). Also im Grunde diese coolen Nasen – das NETWAYS-Team.

In der zweiten hätte die WordPress-RPC Funktion ausgenutzt werden können um bspw. DDoS-Attacken auszuführen. Details zu beiden Lücken finden sich bei openbugbounty.org unter den Meldungen 1777708 und 1814148.

Wenn Du Lust auf weitere solche und ähnliche Geschichten hast, schau bei unseren Trainings oder Events vorbei. Mindestens in den Pausen werden immer Erlebnisse aus der IT Welt verglichen, manchmal auch die Länge der Pipelines oder Größe der Cluster.

Du willst davor eigene Erfahrungen sammeln? Klick Dir hier Deinen eigenen K8s-Cluster , OpenStack oder GitLab-Server.

Wenn Du und Deine offene Fehlerkultur allerdings auch mal via WordPress-API angezogen werden sollen, ist jobs@netways.de der richtige Einstiegspunkt. Wir freuen uns darauf, den nächsten Bug Report mit Dir zusammen zu beheben!

Tim Albert

Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Read more from Tim and meet the Team

Gemeinsam was Neues starten! Die NETWAYS Startup Days 2020

by Julia Hornung | Jan 8, 2021 | NETWAYS

Anfangen – wenn ein neues Jahr beginnt, dann spielt das Thema Anfangen in der Regel eine große Rolle. Wir haben uns schon im Dezember mit dem Anfang von was Neuem beschäftigt – und zwar in unseren Startup Days.

Getöse, Gezwitscher, ein Mann mit Tarnanzug und Gasmaske sitzt am Hang eines Erdhügels inmitten umgestürzter Bäume in einem ziemlich wilden Wald. Das Notebook auf den Knien, vertieft tippend. Dann wird er aufmerksam auf uns, winkt, kommt ziemlich nah an die Kamera, nimmt die Maske ab… Ah, Servus Thomas! …

Die Startup Days finden bei NETWAYS schon seit einigen Jahren regulär kurz vor Weihnachten statt und erfreuen sich firmenintern großer Beliebtheit. Startup Days, das heißt mal anders innovativ sein, verrückte Ideen umsetzen, mal mit anderen Leuten sprechen und zusammenarbeiten als sonst und meistens auch eine Menge Spaß. Klar, dass wir uns das 2020 nicht nehmen lassen! Meisterlich moderiert von Bernd und Christian (siehe Beitragsbild).

Aber Startup Days – was ist das eigentlich genau?

Let’s get started! So funktioniert’s

Im Grunde funktionieren unsere Startup Days genau wie ein Hackathon. Innerhalb eines festgelegten Zeitraums, nämlich zwei Tage, finden wir uns in unterschiedlichen, teamübergreifend gemischten Gruppen zusammen, um nützliche, kreative oder unterhaltsame Projekte zu entwickeln. Der Bandbreite der Ideen sind keine Grenzen gesetzt. Code kann dabei eine Rolle spielen, muss aber nicht.

Den Anfang machen die Pitches, das Ende die Präsentationen – dazwischen liegt eine Menge Hirnschmalz, Gschmarri, Austausch und Kreativität. Alle NETWAYS Departments waren im Vorfeld aufgerufen, ein Projekt einzureichen – diesmal erfolgten die Pitches in Form kleiner Videos.

Die Projekte 2020

Thomas – ihr erinnert euch – sprang für Professional Services ein. Deren Thema war eines, das uns alle umtreibt und auch in anderen Startup-Projekten eine Rolle spielte: Wie können wir trotz Lockdown den Kontakt zueinander aufrecht erhalten – abseits von Meetings, Tasks und Tickets? Während die NPS-Gruppe an Team-übergreifendes dachten, scharten Marius und unsere Managed Services-Abteilung jene um sich, die speziell für Teambuilding im Homeoffice Ideen und Vorschläge entwickeln wollten.

Raus gekommen ist die Weiterentwicklung unseres Chat-Bots Elvis, der seitdem mit verschiedenen Moves lustig Leute in Chatgruppen zusammenwürfelt. Und außerdem ein buntes Potpourri von Games und Möglichkeiten sich online zu treffen.

Soziale Interaktion trieb auch die Marketing-Leute um: Jessi und Keya nahmen sich des etwas vernachlässigten NETWAYS Instagram-Accounts an und präsentierten uns sieben Ideen und direkt den passenden Content, um auf Insta in diesem Jahr so richtig durchzustarten und Spaß zu haben. Seid gespannt!

Und nochmal Kommunikation, aber wieder anders: Markus von Events und seine Gruppe haben die Startup Days genutzt, um gemeinsam eine neue App für unsere Konferenzen zu suchen und zu finden.

Allerlei Erheiterndes lieferte uns die Gruppe um unsere Knallerfrauen Leonie und Nicole von Sales. Bei diesen Video-Clips können Loriot, Juhnke, Switch und Co. einpacken. Die sind dann aber eher für intern. Sorry, Leute! Bewerbt euch gerne. 😉

Wenn ihr dann bei uns seid, könnt ihr auch in unserer neuen Institution für soziales Engagement mitmachen. Blerim, Flo und Angelika von Icinga hatten die Idee einen festen Rahmen zu schaffen, um soziales Engagement bei NETWAYS in Zukunft noch nachhaltiger gestalten zu können. In Kürze hat die neu gegründete Gruppe ihr erstes Treffen und auch hier dürft ihr gespannt sein, was da noch kommt.

Einige der Projekte werden uns sicher im Laufe dieses Jahres noch begleiten und beschäftigen. Andere werden sich vielleicht als eher kurzlebig erweisen. Aber die Möglichkeit, in diesen zwei Tagen gemeinsam etwas Neues zu starten, ist in jedem Fall immer wieder gut!