Ich habe grade eine E-Mail von unserem Vorsitzenden des Ortsausschusses Todenfeld – Rheinbach in meinem Postfach. Er leitet eine Warnung bezüglich einer Sichtung einer Großkatze weiter.
Öhm, also… Großkatze? Ich bin mal gespannt 😀
Kategorie: Allgemein
Ich selbst habe kein Problem mit Spinnen – das ist aber beim Rest meiner Familie nicht immer gegeben. Wie auch immer: Ich bilde mir ein, die meisten Spinnenarten, die hier in NRW so im Garten vorkommen, schon mal irgendwann gesehen zu haben. In den letzten Wochen finde ich aber immer mal wieder ein paar – für meinen Eindruck – recht große Exemplare, wenn auch bisher immer nur tot.
Eines habe ich mal fotografiert und zum Größenvergleich neben eine 10-Cent-Münze gelegt. Die AI sagt, dass es eine Wolfsspinne ist. Da würde ich aber spontan eher nach Nordamerika schielen. Kurz: Ich habe keine Ahnung. Fällt jemandem von euch etwas ein? Was ist das für eine Spinne?!
Vor Kurzem habe ich einen Vulnerability Report erhalten. Ich freue mich natürlich immer über solche Hinweise – sie helfen mir, zu wachsen und mein Setup zu verbessern, bevor jemand eine Schwachstelle tatsächlich ausnutzt.
Der Report lautet wie folgt:
Subject: Vulnerability Report: Vulnerable System Detected at openpgpkey.kernel-error.com
Hello Team,
I have identified a security issue in your system related to a vulnerability (CVE-2023-48795) in Terrapin.
Vulnerability Details:
- CVE Identifier: CVE-2023-48795
- Vulnerability Type: javascript
- Severity: medium
- Host: openpgpkey.kernel-error.com
- Affected Port: 22
Description: A security vulnerability (CVE-2023-48795) related to Terrapin has been detected in your system. This vulnerability could be exploited to compromise your system's security. Please see the details below for more information.
Impact: Impact:
1. Potential for Unauthorized Access: Attackers may exploit this vulnerability to gain unauthorized access.
2. System Compromise: Vulnerable systems could be compromised, leading to data loss or further attacks.
3. Increased Attack Surface: Exposing systems with this vulnerability increases the risk of exploitation.
Recommendation: Recommendation:
1. Apply patches for CVE-2023-48795: Ensure your systems are updated to address this vulnerability.
2. Conduct a Security Review: Regularly review and update your security policies and procedures.
3. Monitor for Suspicious Activity: Implement continuous monitoring to detect any potential exploitation attempts.
4. Restrict Access: Limit access to systems vulnerable to exploitation.
Best Regards,
Security Team
Ich war mir eigentlich sicher, dass ich Terrapin schon vor langer Zeit überall gepatcht und in den SSH-Konfigurationen berücksichtigt hatte.
Dann kam der Hinweis auf openpgpkey.kernel-error.com. Die Domain existiert als CNAME und gehört zur Web Key Directory (WKD), was im Groben dazu dient, öffentliche GPG-Keys möglichst automatisiert abrufen zu können. Wenn mir also jemand eine Mail schreiben möchte, aber meinen öffentlichen Key nicht hat, kann er diesen einfach über WKD beziehen. Ich habe das Ganze als CNAME zu wkd.keys.openpgp.org angelegt, weil dieser Keyserver zumindest eine E-Mail-Validierung beim Hochladen öffentlicher Schlüssel durchführt. Ich muss ja nicht jede Infrastruktur selbst betreiben.
Allerdings gehört der betroffene SSH-Server und das gesamte Zielsystem somit gar nicht zu meiner Infrastruktur – ich kann also selbst nichts tun.
Vulnerability Type: JavaScript
Das verstehe ich nicht ganz. Vermutlich hat der Finder einfach sein Standard-Template benutzt und nicht angepasst?! Aber zumindest wollte ich prüfen, ob seine Einschätzung zum SSH-Server überhaupt zutrifft:
# general
(gen) banner: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3
(gen) software: OpenSSH 8.4p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# security
(cve) CVE-2021-41617 -- (CVSSv2: 7.0) privilege escalation via supplemental groups
(cve) CVE-2016-20012 -- (CVSSv2: 5.3) enumerate usernames via challenge response
# key exchange algorithms
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
`- [info] default key exchange since OpenSSH 6.4
(kex) ecdh-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
`- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256 -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) rsa-sha2-512 (2048-bit) -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (2048-bit) -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 7.2
(key) ssh-rsa (2048-bit) -- [fail] using broken SHA-1 hash algorithm
`- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
`- [info] deprecated in OpenSSH 8.8: https://www.openssh.com/txt/release-8.8
(key) ecdsa-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [warn] using weak random number generator could reveal the key
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com -- [info] available since OpenSSH 6.5
`- [info] default cipher since OpenSSH 6.9
(enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
# message authentication code algorithms
(mac) umac-64-etm@openssh.com -- [warn] using small 64-bit tag size
`- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com -- [fail] using broken SHA-1 hash algorithm
`- [info] available since OpenSSH 6.2
(mac) umac-64@openssh.com -- [warn] using encrypt-and-MAC mode
`- [warn] using small 64-bit tag size
`- [info] available since OpenSSH 4.7
(mac) umac-128@openssh.com -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256 -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512 -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1 -- [fail] using broken SHA-1 hash algorithm
`- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
# fingerprints
(fin) ssh-ed25519: SHA256:vwCCSg+OuRwAflHQs/+Y22UJ7p2lM57vbukGFt5AAaY
(fin) ssh-rsa: SHA256:o+WUM9bAmH2G5xMAsJfZRsmh8hvMoU4dx9gdmahLM+M
# algorithm recommendations (for OpenSSH 8.4)
(rec) -ecdh-sha2-nistp256 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521 -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256 -- key algorithm to remove
(rec) -hmac-sha1 -- mac algorithm to remove
(rec) -hmac-sha1-etm@openssh.com -- mac algorithm to remove
(rec) -ssh-rsa -- key algorithm to remove
(rec) !rsa-sha2-256 -- key algorithm to change (increase modulus size to 3072 bits or larger)
(rec) !rsa-sha2-512 -- key algorithm to change (increase modulus size to 3072 bits or larger)
(rec) -diffie-hellman-group14-sha256 -- kex algorithm to remove
(rec) -hmac-sha2-256 -- mac algorithm to remove
(rec) -hmac-sha2-512 -- mac algorithm to remove
(rec) -umac-128@openssh.com -- mac algorithm to remove
(rec) -umac-64-etm@openssh.com -- mac algorithm to remove
(rec) -umac-64@openssh.com -- mac algorithm to remove
# additional info
(nfo) For hardening guides on common OSes, please see: <https://www.ssh-audit.com/hardening_guides.html>
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present. The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com. If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.
Joar, das sieht tatsächlich nicht ganz so optimal aus. Ein Hinweis darauf ist also nicht unberechtigt. Ich habe dem Finder also freundlich und dankbar geantwortet, aber auch darauf hingewiesen, dass das System nicht zu meiner Infrastruktur gehört. Zusätzlich habe ich ihm die relevanten Whois-Informationen zur IPv4 des angegebenen Hosts mitgeschickt.
Seine Antwort hat nicht lange auf sich warten lassen:
Thank you for your answer.
Let me know if you need anything else from myside
I hope this type of hard efforts deserves something reward
Hm… „hard efforts“. Ich will das jetzt nicht schlechtreden. Wäre der Hinweis im beruflichen Umfeld angekommen, hätte ich mich vielleicht sogar für eine Kleinigkeit stark gemacht. Aber da es hier nur um meine private Infrastruktur geht – und dann noch mit dem JavaScript-Hinweis und der Meldung zu einem fremden System – wirkt das Ganze doch etwas oberflächlich. Also habe ich ihn freundlich darauf hingewiesen.
Mein Tipp für den Umgang mit solchen Meldungen
Wenn euch mal eine solche Nachricht erreicht: Schnell und freundlich reagieren! Den Report ernst nehmen, bewerten und eine angemessene Rückmeldung geben. Die Mühe des Finders sollte wertgeschätzt werden. Zwei Wochen später mit „Anzeige ist raus!“ zu antworten, wäre der falsche Weg. Denn ganz ehrlich: Es ist für jemanden deutlich aufwendiger, sich die Mühe zu machen, eine Meldung zu schreiben, als einfach das Ganze in ein passendes Darknet-Forum zu posten und dort ein paar XMR oder Bitcoin einzusammeln.
Macht es den Leuten also möglichst einfach, euch zu kontaktieren. Eine security.txt oder klare Kontaktinformationen für eine Security-Mailbox helfen ungemein. Hauptsache, jemand kann seinen Report unkompliziert abgeben – und er wird von jemandem gelesen, der das Ganze bewerten kann.
Hier noch etwas zum klicken für die security.txt:
https://securitytxt.org/
https://de.wikipedia.org/wiki/Security.txt
https://www.allianz-fuer-cybersicherheit.de/Webs/ACS/DE/Home/_/infos/20240430_securitytxt.html
Meine SSH Konfiguration sieht von außen wie folgt aus:
# general
(gen) banner: SSH-2.0-OpenSSH_9.7 DemMeisterSeinRennAuto
(gen) software: OpenSSH 9.7
(gen) compatibility: OpenSSH 8.5+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
`- [info] default key exchange since OpenSSH 6.4
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
`- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) ext-info-s -- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
(enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2
# fingerprints
(fin) ssh-ed25519: SHA256:kPRXNCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl1aLc
# algorithm recommendations (for OpenSSH 9.7)
(rec) +rsa-sha2-256 -- key algorithm to append
(rec) +rsa-sha2-512 -- key algorithm to append
Es gibt aktuell einen EEEECCCHHHTTTT guten Deal um günstig an bis zu 10 YubiKeys 5 NFC und/oder 5C NFC zu kommen.
Man benötigt dafür einen Cloudflare Account, der ist ja schnell geklickt. Dann klickt man ein paar Links und wartet auf eine E-Mail mit seinem Discount Code.
Da die Keys in der Regel etwas um die 50€ Kosten, ist dieses schon eine extreme Ersparnis.
Oh der Link: https://www.reddit.com/r/yubikey/comments/xrcly7/cloudflare_deal_for_1011_keys/
Ich bin beim sehen fast vor Lachen umgefallen. Nur gut, dass ich zwischendurch auch weinen musste. So hat es sich etwas ausgeglichen. Viel "Spaß"..
Der Raspberry Pi 4 , egal ob mit 4GB oder 8GB RAM, ist in der Kombination mit Kodi eine wunderbare Erweiterung am Fernseher. Leider sorgte die letzte Version Kodi v19.3 (Matrix) bei mir für ein paar Problemchen. So stockte oder ruckelte die Wiedergabe von Videos oder die Wiedergabe lief für einige Minuten gut, dann wurde gebuffert, nur damit sich dieses Spielchen alle paar Minuten wiederholte. Egal ob im WLAN oder direkt am LAN.
Folgende Änderungen haben bei mir für eine Lösung der Probleme gesorgt:
- Erstellen einer XML Datei, welche die default Einstellungen des Cachings überschreibt.
Speicherort und Dateiname ist: /storage/.kodi/userdata/advancedsettings.xml
<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
<cache>
<memorysize>524288000</memorysize>
<buffermode>1</buffermode>
<readfactor>6</readfactor>
</cache>
</advancedsettings>
Achtung… Bei XML Dateien, spielt das richtige „Einrücken“ schon mal eine Rolle 😉
2. Erweitern des Arbeitsspeichers für die GPU, sowie das Erzwingen des „Turbo“ Modus.
Dafür einfach die Datei /flash/config.txt um folgende Zeilen erweitern/einpassen:
# Default GPU memory split, 76MB are needed for H264 decoder gpu_mem=256 force_turbo=1
Wer dieses gerne per SSH machen möchte, muss das Volume /flash einmal schreibfähig mounten:
mount -o remount,rw /flash
Die Option gpu_mem setzt recht einfach den, für die Grafikkarte, reservierten Arbeitsspeicher fest auf 256MB. Dieses macht selbst bei der 4GB Raspberry PI 4 Version kein Problem.
force_turbo deaktiviert das dynamische, lastabhängige takten der CPU, GPU und des Arbeitsspeichers, sowie der Spannungen. Alles läuft daher auf Maximum, aber ohne zu übertakten. Dieses hat weniger Auswirkungen auf die Probleme bei der Wiedergabe, sorgt aber für ein allgemein „flüssigeres“ Verhalten. Dafür steigt die Stromaufnahme und die Temperatur. Da wir hier über einen Raspberry sprechen, ist es wohl für die Meisten zu vernachlässigen.
3. Um Temperatur und Geräuschpegel im Zaum zu halten, empfiehlt sich ein gutes passiv gekühltes Gehäuse. Folgendes kann ich empfehlen: https://amzn.to/3qF61pe
Das mitgelieferte Netzteil hat ausreichend Power, man kommt noch an „alles“ ran, das Gehäuse ist sehr massiv und selbst bei großer Last/langem Betrieb, wird alles nur handwarm.
Ich nutze Joomla seit 2006, als es aus Mambo hervorging. Die Datenbank und einige Plugins/Teils sind inzwischen also sehr alt und machen bei Versionssprüngen immer mehr Probleme. Den Wechsel vom CMS habe ich dennoch immer von mir weggeschoben, denn es macht viel Arbeit und für eine solch kleine Spielerei lohnt der Aufwand kaum. Da ich es inzwischen eh nur noch für einfache Blogeinträge nutze… Nun ich werde wohl in der nächsten Zeit auf WordPress wechseln. Damit wird es ebenfalls einen neuen RSS Feed geben und sicher wird ebenfalls viel Content verschwinden.
Ein Kollege hat mir folgenden curl Tipp gegeben:
➜ ~ curl v2.wttr.in
Das Ergebnis ist tatsächlich der Wetterbericht für die GeoIP Daten der abfragenden IP Adresse in der Konsole!
➜ ~ curl v2.wttr.in ┌┤ weather report for: Hilden, Germany ├───────────────────────────────┐ │ │ │ │ │ Thu 27 Feb Fri 28 Feb Sat 29 Feb │ │ ╷ ╷ │ │ │ │ │ │+6 ⡠⠔⠊⠉⠉⠉⠢⡀ │ │ ⡠⠒⠉⠉⠑⠢⡀ ⡠⠊ ⠑⢄ │ │ ⢀⡊ ⠑⢆ ⢀⠊ ⠑⠢⢄⣀ │ │ ⢀⠎ ⠑⠤⡠⠔⠁ ⠑⠢⣀ │ │ ⢀⠎ ⠑⡀ │ │0 ⡠⠃ ⠉⠂│ │⡇ ⣀⠤⠒⠉⠉⠒⢄ ⢀⠒⠑⠄ ⢀⠔⠒⠒⠒⠊ │ │⠡⣀ ⣀⠔⠊ ⠉⠊⠁ ⢣ ⡔⠁ │ │ ⠉⠉ ⢇ ⡜ │ │-5 ⠈⢆⢀⠎ │ │ │ │─────┴─────┼─────┴─────╂─────┴─────┼─────┴─────╂─────┴─────┼─────┴─────╂│ │ 6 12 18 6 12 18 6 12 18 │ │ │ │ 5.53mm|85% │ │ ▂_ ▇█▁ │ │ ▁███▂ ▇███_ │ │ ▂█████▂ ▁█████▃▁▁ │ │ ▄███████▃ ██████████▅▁ _____ │ │ ________ _▂▇██████████▅▃▂▁▁__ ▂████████████████████████▅▃│ │ │ │ │ │❄️ ❄️ ❄️ ❄️ ☁️ ❄️ ? ? ? ? ❄️ ❄️ ☁️ ☁️ ☁️ ☁️ ? ? ? ? ? ? ? ? │ │ → → ↗ ↑ ↑ ↑ ↗ ↗ → → → → ↗ ↑ ↑ ↖ ↑ ↑ ↗ ↗ ↗ ↗ ↗ → │ │ 15 14 12 15 22 27 25 24 28 28 23 17 12 11 13 20 21 19 17 16 23 25 20 18│ │ │ │? ? ? ? │ │ ─━━━━━━━━━━━ ─━━━━━━━━━━━ ─━━━━━━━━━━━ │ │ │ │ │ └────────────────────────────────────────────────────────────────────────┘ Weather: ? Light Rain, Rain, +3°C, 93%, ←19 km/h, 994hPa Timezone: Europe/Berlin Now: 15:04:14+0100 | Dawn: 06:49:42 | Sunrise: 07:23:08 Zenith: 12:45:09 | Sunset: 18:07:10 | Dusk: 18:40:36
Lustig oder?
Regeln oder gute Vorsätze!
Meine Erfahrungen im Zusammenhang mit der IT haben gezeigt, dass es sehr hilfreich seien kann, wenn ich mich an ein paar Regeln halt. Diese Regeln oder besser guten Vorsätze habe ich mir selbst aufgestellt. Da ich immer und sehr gerne dazu lerne, ändert sich die eine oder andere Regeln hin und wieder. Hinter vielen Regeln steht meist eine kleine Geschichte. Immer mal wieder ist eine der Regeln aus einem Fehler entstanden, welcher mir passiert ist. Tja, wer ist schon fehlerlos? Aus Fehlern lernt man ja schließlich doppelt so gut, oder?
#01 – Nenne das Kind beim Namen!
Ich habe oft erlebt wie einige Informationen etwas „verschönert“ oder lange umschrieben wurden. So lang bis keiner mehr verstanden hat um was es geht und welche Probleme jetzt wirklich hinter dieser Entscheidung stehen können. Ich glaube eine klar verständliche und genaue Ansage ist wichtig. Sprechen alle über das Gleiche und haben die gleichen Informationen, passieren viele Fehler erst gar nicht und wenn doch, haben sich alle bewusst dafür entschieden.
Abschließend eine E-Mail mit den Absprachen an alle Beteiligten und schon schlafen alle besser!
#02 – Nicht ohne Backup!
Mal eben schnell den Patch einspielen oder das Upgrade auf die neue Version der Warenwirtschaft…. Im Raidverbund ist eine Platte kaputt, ich tausche die mal kurz und stoße das Resilvering an! Das habe ich schon tausend mal gemacht, das ist tausend mal ohne ein Problem durchgelaufen. Ich spare mir jetzt die Zeit fürs Backup…. Der alte Server wird jetzt über die nächsten 4 Tage migriert. Hier für beide Systeme eine Datensicherung einzurichten, kostet unnötig Geld und braucht viel Zeit, wir lassen das.
Nein, so geht es nicht! Immer wenn man etwas nicht gebrauchen kann geht etwas schief. Daher Regel #02: Nicht ohne Backup.
Natürlich gibt es eine Ausnahme von dieser Regel. Dafür muss Regel #01 beachtet werden und die entscheidenden „Internetausdrucker“ müssen einen Zettel unterschreiben, auf welchem so was steht wie: Ja, wir haben keine Dasi und ja, wenn etwas schief geht ist alles weg… Warum unterschreiben? Ganz einfach: Die „Internetausdrucker“ werden meist erst nervös, wenn sie etwas unterschreiben und sich selbst damit in der Pflicht sehen.
#03 – Geht das Backup?
Klar haben wir ein Backup. Das läuft jeden Tag und wir achten darauf das es immer ohne Fehler und zu 100% durchläuft. Das ist vor 5 Jahren von einem Experten eingerichtet worden. Seither läuft es ohne ein Problem.
Schön schön… Hat denn schon mal jemand versucht Daten aus diesem Backup zurück zu hohlen? Kann jemand diese komische Sicherungssoftware bedienen und bekommt man die Software im Fall der Fälle noch oder hat man dann nur einen Datenhaufen der einem nichts bringt? Hin und wieder sollte man doch mal testen ob sich die Daten aus dem Backup wirklich wiederherstellen lassen. Klappt es nicht, weiß man es bevor es ein Problem ist, klappt es weiß man wie lange es wohl dauern könnte! Ist es aus Kostengründen nicht gewünscht: Regel #01
Regelmäßige Tests des kompletten Backupsystems gehören in einen disaster revocery plan (DRP) Regel #13
#04 – Wie wichtig ist das überhaupt?
Es sollte immer abgesprochen und möglichst schriftlich fixiert sein, welche Priorität welches System für das jeweilige Unternehmen hat. Eine Firma kann problemlos drei oder vier Tage ohne E-Mails auskommen, andere sind nach 4 Stunden pleite. Unter Beachtung von Regel #01 sollte dieses _VORHER_ durchgesprochen werden. Wenn man jetzt noch Preise neben die gewünschte Verfügbarkeit schreibt, findet man schon zusammen.
#05 – Datenschutz!
Selten ist man als Systemadministrator der Datenschutzbeauftragte. Da man als Systemadministrator oft der Einzige mit „dem Überblick“ ist, sollte man entdeckte Probleme ansprechen und festhalten. Ein Administrator ist für mich eine besondere Vertrauensperson. Daher sollte ein Administrator immer darauf achten, dieses Vertrauen zu verdienen und zu behalten!
#06 – Ansprechpartner
Der Serverraum brennt, wie war noch gleich die Nummer von / wem überhaupt? Ohne Ansprechpartner geht es nicht. Je nach Unternehmensgröße sollte(n) der/die Ansprechpartner und deren Vertretung klar sein. Ein guter Ansprechpartner hat dabei ein gewisses technisches Grundverständnis (und versteht den Humor von Technikern). Ein richtig guter Ansprechpartner hat sogar noch die Möglichkeit einige Dinge selbst zu entscheiden. Ansprechpartner fallen ebenfalls aus Regel #13 heraus 🙂
#07 – Ein totes Pferd kann man nicht reiten.
Ein richtig altes Windows System kann man nur in ganz ganz ganz ganz extrem sehr sehr engen Grenzen noch „warten“, ähnlich es mit verbrauchter Hardware und und und… Selbst ein Microsoft Windows Server der vorletzten Generation machen in vielen Fällen keinen Sinn mehr. Natürlich muss man es immer abwägen und man sollte es selbst gut begründen können. Dennoch sollte man keine Angst vor einem _NEIN_ haben. Es gibt einfach Systeme und Techniken die sind tot und für diese kann man einfach keine Verantwortung übernehmen. Microsoft soll hier nur als Beispiel herhalten, ich bin ebenfalls schon Debian Systemen über den Weg gelaufen die aus den Archive quellen bedient wurden *kopfschüttel*.
Klar geht immer noch mal „etwas“, dieses nur im Zusammenhang mit Regel #01
#08 – Vergesse die Workarounds nicht!
Es gibt Probleme die sich nicht lösen lassen. Dieses weil, man es selbst gerade nicht besser weiß, es einfach wirklich nicht geht oder die Kosten für eine echte Lösung nicht zu rechtfertigen sind. Für diese Fälle gibt es Workarounds, welche man nur nicht vergessen sollte. Nicht da man später suchen müsste wie es noch gleich ging, nein damit der Workaround nicht der Standard wird! Unter Beachtung von Regel #01 sollte das Thema immer mal wieder aufgegriffen und bewertet werden. Selbstreden mit Sinn und Verstand. Es soll ja keine ABM werden.
#09 – Es lebe die Dokumentation!
Jetzt mal unter Freunden. Niemandem macht Dokumentation Spaß! Es ist nur leider wichtig…. Man kann sie nicht mal an den Azubi abgeben, denn beim Korrekturlesen muss man so viel ändern, da hätte man es direkt selbst machen können.
Zur Dokumentation muss ich mich in einigen Fällen selbst immer wieder motivieren. Vor allem wenn ich selbst davon überzeugt bin es nie wieder zu brauchen (da irrt man sich schon mal). Vielleicht braucht es mal ein Kollege?!?!
#10 – Hohl den Schraubendreher!
Wenn ich mit dem kleinen unpassenden Schraubendreher nur feste genug an der Schraube hier, dann müsste! Nein, im Werkzeugkasten (der immer im Auto liegt, welches wie immer viel zu weit weg steht da mal wieder kein Parkplatz…) ist ein passender. Also los, hohlen. Das richtige Handwerkszeug ist wichtig. Nicht nur in Hard- sondern auch in Software.
#11 – Ist der Stecker drin?
Es klingt dumm, ja. Der Benutzer sagt er habe alles schon probiert, dennoch sollte man zumindest einen kurzen Blick darauf werfen um sich ein eigenes Bild zu machen. Zu oft war zwar der Stecker drin, nur leider der von der Kaffeemaschine 🙂 Ein gutes, angepasstes troubleshooting erleichtert einem extrem das Leben. Man sollte sich selbst einmal damit auseinandersetzten und für sich einen klaren „Wegweiser“ erstellen. Es hilft einem den Punkt zu finden an dem man sich verrannt hat.
#12 – Jedem sein Login!
Jeder sollte einen personalisierten Account mit eigenem Kennwort haben. Nicht um dem jeweiligen vorhalten zu können was er da wieder verfriemelt hat oder um bei Problemen auf jemanden zeigen zu können. Meist werden Probleme am System ja nicht vorsätzlich verursacht. Personalisierte Accounts helfen sehr dabei, nachvollziehen zu können, was gelaufen ist und davon zu lernen. Wenn sich jeder mit seinem Namen anmeldet verändert dieses alleine schon den Umgang mit dem System. Zusätzlich lassen sich erteilte Berechtigungen so schnell und einfach in einem Audit kontrollieren. Hat mein ein zentrales Benutzermanagement lassen sich Zugänge und Rechte schnell und einfach sperren. Es soll ja Mitarbeiter geben die kündigen oder sogar gekündigt werden!
#13 – DRP
Es sollte immer einen DRP (disaster recovery plan) geben. Schon beim erstellen dieses Planes werden einem extrem viele Dinge bewusst die man sonst schnell unbeachtet lässt. Systeme werden priorisiert, es gibt Verantwortliche und Ansprechpartner. Es gibt einen Plan! Dieser wird regelmäßig geprüft usw… Ein DRP gibt nicht nur dem Admin Sicherheit auch das Unternehmen kann ruhig schlafen da es einen Plan für den Notfall gibt. Von genau diesem Plan profitieren dauerhaft und sofort viele andere Projekte und Systeme. Denn alles muss sich daran messen!
