Transport Verschlüsselung E-Mail Provider

Da Stiftung Warentest aktuell die erneuten Tests für E-Mail Server heraus gibt, habe ich mir mal die Mühe gemacht, die Transport Verschlüsselung auf unseren E-Mail Servern herauszufiltern um diese nach Ihrer ciphers zu untersuchen. Spannend war, dass mittlerweile alle eingehenden Verbindungen eine Recht hohe Sicherheit aufwiesen. Microsofts hotmail.com outlook.com so wie Mail.de waren die einzigsten, die noch ein CBS Mode verwenden. Alle anderen sind schon auf den neuen GCM Mode umgestiegen. Bei web.de, mail.de und mailbox.org haben anscheinend unersichtliche Server Infrastruktur die mit unterschiedlichen ciphers E-Mails Ausliefern.

google.com
ECDHE-RSA-AES128-GCM-SHA256

yahoodns.net
ECDHE-RSA-AES128-GCM-SHA256

t-online.de
ECDHE-RSA-AES256-GCM-SHA384

gmx.net und gmx.de
DHE-RSA-AES256-GCM-SHA384

web.de
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

hotmail.com
ECDHE-RSA-AES256-SHA384

outlook.com
ECDHE-RSA-AES256-SHA384

freenet.de
DHE-RSA-AES256-GCM-SHA384

icloud.com
ECDHE-RSA-AES128-GCM-SHA256

mail.de
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
ECDHE-RSA-AES256-GCM-SHA384

mailbox.org
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

posteo.de
ECDHE-RSA-AES256-GCM-SHA384

Die Resultate habe ich unter 100.000 E-Mailserver-Verbindungen der letzten Woche herauszufiltern. Sortiert sind die aufrufe nach Anzahl der Verbindungen wobei die Anzahl der letzten 3 Anbieter < 1% liegt.

mount cifs als guest: mount error(13): Permission denied

Beim mounten eines NFS unter Ubuntu 16.04 mit folgenden Kommando bekam ich immer eine Fehlermeldung die leider sehr häufig vor kommt.

sudo mount.cifs -v //10.0.0.1/MEMORYCARD/ /mnt -o guest,sec=ntlm
mount.cifs kernel mount options: ip=10.0.0.1,unc=\\10.0.0.1\MEMORYCARD,sec=ntlm,user=,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Durch das einfügen von User und Passwort war das mounten möglich:

sudo mount.cifs -v //10.0.0.1/MEMORYCARD/ /mnt -o sec=ntlm,user=guest,pass=

drbd: storage live migration

Um VMs zwischen HDD und SSD zu migrieren wäre ein „lvmove“ äquivalent ganz praktisch. Dies kann es aber nicht geben, da der Pfad zum lv dann auch angepasst werden muss. Um meine Master Slave Setup dennoch Live migrieren zu können, habe ich ein neues gleich großes lv erstellt, die Platte ausgehangen und die neue wie folgt eingegangen.

Zunächst habe ich geprüft ob ich Master oder Slave bin (ro:Secondary)

grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:1176552 nr:236 dw:1176788 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Dann habe ich dem DRBD Verbund die Storage aus gehangen:

drbdadm detach drbdvm11
grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:Diskless/UpToDate C r-----
    ns:1176552 nr:272 dw:1176824 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Dies DRBD Config Datei editiert und bei der localen node das neue lv auf der neuen vg eingetragen.

vim /etc/drbd.d/drbdvm11.res
disk       /dev/mapper/vg2-drbdvm11;

Danach muss das neue lv von DRBD initialisiert werden:

drbdadm create-md drbdvm11
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
success

Anschließend wird alles wieder gestartet und die Synchronisation begibt automatisch.

drbdadm attach drbdvm11
grep -A2 '^11:' /proc/drbd 
11: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:184320 dw:184320 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:7155452
         [>...................] sync'ed:  9.4% (116080/127996)M
grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:7339804 dw:7339804 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Zusammenfassung der geplanten Stromabschaltung zwischen 08:00 und 13:00.

In der Bayernallee war für den Samstag 09.08. eine geplanten Stromabschaltung zwischen 08:00 und 13:00 durch die Stawag angekündigt worden.

Leider hatten wir den CISCO Switch seit über 5 1/2 Jahren nicht neu gestartet, aber der reihe nach.
cisco-4006

8:15 wurde der Strom abgeschaltet.
8:43 gingen die USVs der Ciso 4006 gingen zu neige.
10:13 Strom wurde wieder eingeschaltet.

12:56 Eintreffen meinerseits in der Bayernalle für eine erste Analyse:

  • Cisco zeit den Status Fail an. Ein Neustart der Cisco so wie das Resetten
    der Superviso war ohne Erfolg. Nach 3Sec Grünen Blinken fällt die Sup in den
    Status Fail zurück.
  • Suchen nach Cisco Konsolen Kable.

14:00 Abreise meinerseits mit neuer Terminfindung für den späten Abend.

14:00 – 23:45 Mehrere Koordinationsgespräche. Suche von privater Hardware.
23:50 Eintreffen mit einem Kollegen in der Bayernallee. Erneute Analyse mit Konsolenkable.

  • Sup gab aber leider keinerlei Status
  • CF Karte war Leer ohne Dateisystem
  • Vorbeiteitung Notlösung, suche nach dem zweitem HP Switch und den SFP Adaptern.
  • Einbau der 3com Karte in Chistoph Router
    Begründung: Hier sind bereits alle Routing Funktionalitäten Installiert
    und VLAN Feachers vorhanden.

03:00 Erfolgreicher Funktionstest und Verbindung zum Internet. Vorbereitung umbau der
Netzwerkinfrastruktur auf 100Mbit Switches.
04:00 Erster Netzwerk Test nicht erfolgreich, vermutlich eine Loop
gesteckt.

04:30 Zweiter Netzwektest Erfolgreich. Edorome Test erfolgreich. Fahrt
nach hause!

Nach dem Umstecken sah unsere Notlösung etwas chaotisch aus, die CISCO 4006 etwas leer, dafür waren die 144 Bewohner am nächsten morgen wieder sehr glücklich.
nwr12

Pause Taste

Immer wenn ich meinen Arbeitsplatz verlasse Sperre ich meinen Bildschirm. Vor eingestellt ist ALT + L. Das geht aber einfacher. Unter Systemeinstellungen => Tastatur kann man im Reiter „Tastenkürzel“ die voreingestellten Einstellungen bearbeiten. Unter System => Bildschirm sperren habe ich hier die Pause Taste hinterlegt.

Damit ich aber weiß, wann ich in Pause gegangen bin habe ich mir ein kleine Script geschrieben:

bin/pause

#!/bin/bash
gnome-screensaver-command -l
logger "PAUSE"

Dieses sperrt den Bildschirm und schreibt eine Logzeile ins Syslog:
Jun 6 17:00:00 desktop user: PAUSE

Hierfür habe ich mir unter Systemeinstellungen => Tastatur kann man im Reiter „Tastenkürzel“ ein eigenes Tastenkombination definiert
pause

Im auth.log steht equivalten wann ich mich wieder eingeloggt habe:
Jun 6 18:00:00 desktop compiz: gkr-pam: unlocked login keyring