Autor: kernel-error (Seite 20 von 47)

Inzwischen hat ja fast jeder bei uns „schnelles“ Internet…. So lassen sich per E-Mail auch mal etwas größere Dateien verschicken. Dennoch sollte man so ab 5MB ein schlechtes Gefühl haben und sich ab 10MB Anhängen nicht mehr über abgewiesene E-Mails ärgern.

Das Problem mit großen Dateianhängen bei E-Mails ist ja nicht nur die Verstopfung der Leitungen… Mailserver arbeiten sich daran ab, der absendende und empfangende Client ebenfalls. Hängt dann noch ein Virenscanner dazwischen rechnet noch jemand. Dann liegt die Datei auf dem System des Absenders, in dessen Postfach, im Postfach dem Empfängers und natürlich noch auf dem System des Empfängers. Bei einem 500MB Anhang sind das schon mal 2GB für nix.

Inzwischen gibt es 1000 Möglichkeiten um große Dateien schnell und einfach auszutauschen. Selbst ohne seine Daten auf irgendeinen Server bei irgendeinem Anbieter zu legen. So zum Beispiel über owncloud….. Hochladen muss man die Datei ja in jedem Fall zu seinem Mailserver, warum also nicht lieber in die „Cloud“? Ok, es ist etwas aufwendig. Erst hochladen, dann teilen, dann den Link kopieren und in die E-Mail packen, usw. usw…

Für Anwender des Mailclients Thunderbird gibt es in diesem Zusammenhang eine noch schönere Lösung. Sie nennt sich filelink. Im Grunde nichts weiter als eine kleine Funktion, welche dem Anwender etwas Arbeit abnimmt!

Hängt der Anwender eine Datei an seine E-Mail an, welche einen einstellbaren Schwellwert überschreitet, schlägt Thunderbird diesem vor, den Anhang für den Anwender in einen dieser „Austauschservices“ zu laden. Stimmt der Anwender zu, schiebt Thunderbird die Datei hoch und verlinkt sie automatisch in den E-Mail Body. Dieses hält die E-Mai klein und der Empfänger kann selbst entscheiden, ob und wann er den „Anhang“ herunterladen möchte.

Aktuell bringt Thunderbird aus dem Karton leider nur die Verknüpfung zu den bekannten großen Anbietern wie z.B.: dopbox mit. Dort möchte man ja nicht unbedingt seine Daten ablegen. Für owncloud habe ich vor kurzem eine gut funktionierendes Thunderbird Plugin gefunden:

https://github.com/guillaumev/owncloud_for_filelink

Einfach herunterladen, installieren, zwei drei Kleinigkeiten in der eigenen Cloud einstellen und glücklich sein 🙂 Mit zwei/drei erklärenden Sätzen in der E-Mail versteht es zudem fast jeder Empfänger. Noch Fragen?

Ich experimentiere in der letzten Zeit etwas mehr mit PC-BSD herum und so langsam verdrängt es sogar seinen Vater FreeBSD von meinem Desktop….

Der angenehme Vorteil von PC-BSD ist, dass es bereits viele Kleinigkeiten für den Desktopeinsatz „fertig“ vorhält. Man muss nicht erste jede Kleinigkeit selbst konfigurieren (ich werde SO faul). Der Nachteil ist, man lernt nix mehr 🙁 Wie auch immer…

Ich wollte gerade eine CD brennen, starte mein xfburn und dieses erzählt mir es könne keinen Brenner finden oder die Berechtigungen würden nicht stimmen.

** (xfburn:12447): WARNING **: No drives were found! If this is in error, check the permissions

Nanu?!?! Als erstes wollte ich die Berechtigungen ausschließen:

$ pc-su xfburn
Passwort:** Message: Using elementar transcoder.

Brennen klappt… Also wirklich ein Problem mit den Berechtigungen. Dann schauen wir sie uns mal durch..

Der Brenner ist im Notebook das Device /dev/cd0 mal sehen…

$ ls -lisa /dev/cd0
105 0 crw-rw-rw-  1 root  operator  0x69 21 Jan 07:40 /dev/cd0

Sieht doch gut aus… Viele Anwendungen nutzen aber einen Link um auf das jeweilige Laufwerk zuzugreifen, auch wenn es der Brenner nicht tun sollte, denn… (dazu später)… mal schauen und gelesen haben stört aber nicht 🙂

$ ls -lisa /dev/cdrom
131 0 lrw-rw-rw-  1 root  wheel  3 21 Jan 07:43 /dev/cdrom -> cd0
$ ls -lisa /dev/dvd
132 0 lrw-rw-rw-  1 root  wheel  3 21 Jan 07:43 /dev/dvd -> cd0

Pass bei mir aber auch, sollte es nicht passen hilft bei Symlinks ein chmod -h 0666…. Nur würde es beim Problem mit dem Brenner nicht helfen! Warum? Nun ja, wer sich an „früher“ unter Linux erinnert, da musste man auch ein Modul laden, welches aus dem ATA Brenner einen SCSI Brenner für den Kernel macht. Funktioniert noch immer ähnlich, ist aber inzwischen im Linux Kernel verklappt. Unter BSD muss man noch immer dafür sorgen. Dafür müssen in der Datei /boot/loader.conf folgende Einträge erstellt werden:

atapicam_load="YES" 
hw.ata.atapi_dma="1"

Der erste Eintrag sorgt dafür, dass der ATA Brenner als „SCSI“ Laufwerk ~erkannt~ wird, der zweite aktiviert den DMA Zugriff auf ATA Laufwerke. Ich meine dass im Kernel vom PC-BSD bereits per Default DMA für ATA Geräte aktiviert ist, schadet aber nicht! Ach ja, in meiner PC-BSD loader.conf gab es den nötigen Eintrag bereits. Es war also schon richtig, denn noch ging es nicht 🙁

Macht nix, weiter suchen! Ist das Modul geladen, sollte mir camcontrol nun meine ATA Geräte auflisten können, inkl. deren SCSI ID und dem zugehörigen passthrue Device:

$ camcontrol devlist
<ST500LM000-1EJ162 DEM8>           at scbus0 target 0 lun 0 (ada0,pass0)
<TSSTcorp DVD+-RW SU-208CB D200>   at scbus1 target 0 lun 0 (cd0,pass1)
<AHCI SGPIO Enclosure 1.00 0001>   at scbus4 target 0 lun 0 (ses0,pass2)

Perfekt…

cd0 stimmt, habe ich bereits kontrolliert. pass1? Mal sehen:

$ ls -lisa /dev/pass1
76 0 crw-------  1 root  operator  0x4c Jan 21 07:40 /dev/pass1

Na schau mal einer an 😀 Zum Test setzte ich mal passende Rechte auf das Device und starte dann als User mein Brennprogramm.

$ chmod 0666 /dev/pass1

Geht… Dann soll es so bleiben! Nach einem Reboot wären meine vergebenen Rechte wieder weg. Damit diese bleiben muss ich meinen Wunsch in der Datei /dev/devfs.conf hinterlegen. Ein Blick in diese verrät mit, dass sich schon jemand Gedanken gemacht hat (pc-bsd halt…). So sind bereits passende Rechte für das Gerät /dev/pass0 gesetzt. Nur eben nicht für /dev/pass1. Es lässt sich also einfach der Eintrag von pass0 für pass1 kopieren:

/etc/devfs.conf
....
# Commonly used by many ports 
link    cd0     cdrom 
link    cd0     dvd 
....
# Allow all users to access CD's  
perm    /dev/acd0       0666 
perm    /dev/cd0        0666 
....
# Misc other devices 
own     /dev/lpt0       root:cups
perm    /dev/lpt0       0666
own     /dev/lpt1       root:cups
perm    /dev/lpt1       0666
perm    /dev/pass0      0666
perm    /dev/pass1      0666 
....

Nur ein Detail welches noch beim PC-BSD fehlt um es für den Benutzer beim Brennen noch einfacher zu machen. Wenn auch ein Detail, was Benutzer ohne FreeBSD Vorkentnisse ins Straucheln bringen könnte.

In diesem Sinne….

Ich habe ja vor kurzer Zeit etwas über die ZFS Datensicherung meines Notebook geschrieben und dass auf diesem ein FreeBSD 10.1 werkelt… Genauer:

kernel@errorlap:~ % freebsd-version 
10.1-RELEASE-p3

Nun sind inzwischen einige Fragen zur Konfiguration bei mir angekommen, inkl. der Bitte ein paar Sätze dazu zu schreiben. Also, ich schreibe 🙂

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme 😀

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann 😛 Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

Ich räume gerade etwas auf und da finde ich einen Merker für das IPv6 Buch von Jens Link…. Eigentlich etwas dass ich mir in den „Schrank“ stellen wollte. Leider scheint es noch immer nicht kaufbar 🙁 So als einfaches „Einsteigerbüchlein“ schien es mir perfekt. Schade… Werde es dann wohl mal aus meiner Merkliste löschen.

http://www.amazon.de/IPv6-Planung-Umstieg-Jens-Link/dp/3937514899

Komisch, oder?

So long…

Mal etwas ganz anderes…. Keine Ahnung was ihr so zwischen den Feiertagen macht, ich repariere kaputte Abwasserrohre. Mit Vorliebe hinter der Dusche!

Nein, Scherz! Zumindest zum Teil… Irgendwas machte seit kurzem hinter der Dusche meiner Kinder „Probleme“. Irgendwo in der Wand war etwas undicht. Zwischen den Feiertagen hatte ich Zeit, so zumindest die Einschätzung meiner Frau 😛

Also habe ich alles auf gestemmt und ganz zuletzt das Problem gefunden. Das Abwasserrohr vom Waschbecken war dort undicht. Getauscht und jetzt muss ich wohl eine neue Dusche bauen, TOP.

Es will nicht zufällig jemand helfen?

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„). 

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein 🙂 Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden 😀

So long….

Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.

Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.

Vorbereiten fürs Kompilieren:

$ cd /usr/src
$ apt-get install build-essential fakeroot
$ apt-get build-dep openssl

Herunterladen der aktuellen Version:

$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz

Auspacken des Archives und mit den Patchen „verknüpfen“:

$ dpkg-source -x openssl_1.0.1j-1.dsc

Ins neue Verzeichnis wechseln:

$ cd openssl-1.0.1j

Kompilieren und deb Pakete erstellen:

$ dpkg-buildpackage -us -uc -rfakeroot

Die neuen Pakete installieren:

$ cd ..
$ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb

Kontrolle der Version:

$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren 😀

So long…..

---

Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:

$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2
CONNECTED(00000003)
140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

---

U-P-D-A-T-E

Denkt an die Updates 😀

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015