Veraltet: StartSSL/StartCom wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. Für kostenlose Zertifikate nimmt man heute Let’s Encrypt.
StartCom ist ein Unternehmen, das Software herstellt und als Zertifizierungsstelle digitale Zertifikate ausstellt. Seit Februar 2005 ist das Unternehmen als Zertifizierungsstelle tätig. Das bekannteste Produkt ist das kostenlose Class 1 X.509 SSL-Zertifikat „StartSSL Free“, das sowohl für Webserver (SSL/TLS) als auch für die E-Mail-Verschlüsselung (S/MIME) eingesetzt werden kann. Außerdem werden Class 2 Zertifikate und Extended-Validation-SSL-Zertifikate ausgestellt, für die eine kostenpflichtige Validierung Voraussetzung ist. StartCom-Zertifikate werden von allen modernen Browsern akzeptiert: Mozilla Firefox unterstützt sie schon ab Version 2.0, Opera seit Juli 2010, Apple Mac OS X ab Version 10.5 (Leopard) und Microsoft Windows seit September 2009; Apple Safari, Internet Explorer und Google Chrome greifen auf den Zertifikatspeicher des Betriebssystems zurück.
Das kostenlose Class1 Zertifikat stellt nur sicher das der angegebene Domainname existiert und anscheinend dem Halter des StartCom Accounts gehört. Aus diesem Grund findet sich natürlich auch nur der Domainname im Zertifikat. Wer seinen Namen auch noch im Zertifikat hinterlegen möchte kann dieses denn noch auf einem kostenlosen Weg schaffen. Ähnlich CAcert setzt StartCom auf das Prinzip des Web of Trust (wot). Es gibt bei StartCom ehrenamtliche Notare. Jeder Inhaber eines StartCom Accounts kann sich von diesen verifizieren lassen. Dazu findet sich im Webinterface des eigenen Accounts auf der Seite unter StartSSL WoT ==> WoT Netzwerk der Punkt Notarsucher. Hier findet sich über die Eingabe des eigenen Wohnortes oder halt der nächsten größeren Stadt schnell ein solcher Notar.
Wurde man von mindestens zwei dieser Notare bestätigt, kann man seinen Namen mit ins Zertifikat aufnehmen.
Eine solche Bestätigung findet immer über ein persönliches Treffen mit dem Notar statt. Bei diesem Treffen prüft der Notar anhand von zwei amtlichen Lichtbildausweisen ob der Name im Account mit dem auf den Ausweisen identisch ist.
Da die Root-Zertifikate dieser Zertifizierungsstelle bereits in den meisten großen Browsern und Betriebssystemen enthalten sind, kommt es bei diesen Zertifikaten (anders als bei z.B. CAcert.org) nicht zu „Fehlermeldunge“ bzw. Warnmeldungen im Zusammenhang mit den Zertifikaten. Vor allem dieser Umstand und natürlich da es kostenneutral ist, würde ich StartCom x.509 Zertifikate als einen optimalen Einstieg in diesen Themenbereich nennen können. Wer am Ende mehr will, wie eine Class 2 Zertifizierung oder bis hin zum Class 3 Zertifikat für Unternehmen, kann dieses schnell und günstig weiterführen. Wem das Class 1 Zertifikat ausreicht, dem stehen direkt nach der erfolgreichen Anmeldung schon fast alle Möglichkeiten der E-Mail Signatur / Verschlüsselung sowie SSL/TLS Verschlüsselte Serververbindungen offen.
Ich selbst bin bei StartSSL Notar und wie bei GPG / PGP oder CAcert.org bestätige ich auch hier gerne Identitäten auf Anfrage.
Ich bin nur sehr selten an einem Ort, an welchem ich keine Internetverbindung nutzen kann. Noch seltener würde ich genau dann eine Internetverbindung benötigen. Wenn es dann aber so ist, dann benötige ich sie wirklich!
Nun komme ich in der letzten Zeit immer mal wieder an diese Stelle und ärgere mich. Oft ist zwar ein Kollege oder Bekannter in der Nähe, mit so einem feinen Android Mobiltelefon, nur hilft mir dieses beim Arbeiten auf einer SSH-Shell weniger. Ja, es geht aber wirkliches Arbeiten geht nicht… Zudem bin ich ein Mensch der seinen Windowmanager benutzt, sprich viele offene Fenster. Auf so einem kleinen Mobilding ist mir mehr als eine kurze E-Mail oder etwas Google klicker klacker einfach zu aufwändig.
Das Handy also als Modem mit dem Rechner verbinden? So selten wie ich es im Moment benötige, mich direkt 1 Jahr an einen 20€/Monat Tarif meines Anbieters zu binden? Ne, so geht das nicht….
Vor kurzem war ich nun im Blödmarkt unterwegs. Da lagen in der Grabbelkiste so 15 Euronen O2 Prepaid USB-Sticks.
Dem etwas überforderten Fachberater für die Dinger konnte ich mit etwas Mühe die Information entlocken, dass ich über dieses Angebot „echtes“ Internet erhalte. Damit ist gemeint, dass ich SSH-Sessions auf beliebigen Ports öffnen kann und auch mein IPv6 Tunnelbroker funktionieren sollte. ….Nebenbei, habt ihr im Blödmarkt mal gefragt ob ihr über was auch immer eine Verbindung zu einen IPv6 Tunnelbroker aufbauen könnt? Macht mal, ist lustig.
HTTP / SMTP / IMAP mit und ohne SSL/TLS alles kein Problem!
Mit der 5 Tage x 3,50€ = 17,50€ Sollte einem Test nichts im Wege stehen. Keine Grundgebühr oder sonstige laufenden Kosten… Ich brauche es nicht, ich zahle es nicht. Wenn ich also feststelle das ich es doch oft und gut nutze, so dass sich einer der Knebelverträge des Anbieters meines Vertrauens lohnen würde, dann kann ich das Teil wegwerfen und mich bewusst knebeln lassen. Anderweitig habe ich eine tolle Lösung für den Notfall!
Beim Kauf habe ich jetzt nicht darauf geachtet ob das Teil nun unter bzw. mit meinem Linux (Gentoo) zusammenarbeitet. Den Fachberater im Blödmarkt wollte ich es nun nicht noch fragen, er schien jetzt schon von mir genervt zu sein!
Hey, gut wie ich bin, bekomme ich das Teil schon zum rennen (Boar ist diese Selbstüberschätzung nicht wiederlich?)!
Da meine Frau etwas von: „Rausgeworfenes Geld…. Überflüssiges Spielzeug… und du sitzt eh viel zu viel vor dem Computer!“ murmelte…. _MUSS_ das Teil einfach Laufen.
Tut es nur so ~out of the box~ nicht! Dass hat man nun also davon, man kauft im Blödmarkt halt nichts. Vor allem nicht ohne Verstand, oder gerade deswegen? Wie auch immer, so haben ich es ans Laufen bekommen!
Ich habe hier also den O2 Surfstick MF190 von der Firma ZTE.
Stecke ich diesen einfach in mein System ein und schaue mir an was der Kernel dazu sagt, sehe ich folgendes:
$ dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 3
usb 2-1: New USB device found, idVendor=19d2, idProduct=0083
usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 2-1: Product: ZTE WCDMA Technologies MSM
usb 2-1: Manufacturer: ZTE,Incorporated
usb 2-1: SerialNumber: P671A2TMED010000
scsi7 : usb-storage 2-1:1.0
scsi 7:0:0:0: CD-ROM ZTE USB SCSI CD-ROM 2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 7:0:0:0: Attached scsi CD-ROM sr1
sr 7:0:0:0: Attached scsi generic sg2 type 5
Der Stick wird also als USB-CDROM Laufwerk (hier liegt die Software für die Windows User) und USB-Festplatte (sofern eine MicroSD-Karte eingelegt ist, wäre es diese) erkannt.
Mal schauen was ein lsusb sagt:
$ lsusb
Bus 002 Device 004: ID 19d2:0083 ONDA Communication S.p.A
19d2 steht für den Hersteller und 0083 für das Gerät selbst. Google sagt 0083 ist der Stick aber im Modus (ich nenne es mal) Datenlaufwerk. Ich will aber Modem 🙂 Hierzu sagt Google man muss ein paar bestimmte Kommandos schicken und schon wechselt der USB-Stick seinen Modus. Findige Leute haben sich da schon einen Kopf zu gemacht und das Programm: usb_modeswitch geschrieben. Also soll emerge mal loslegen:
$ emerge usb_modeswitch
Solange er rechnet könnte ich meinen Kernel ja schon mal davon überzeugen das Gerät zu „ignorieren“. Dazu füge ich in die Datei: /usr/src/linux/drivers/usb/storage/unusual_devs.h folgende Zeilen ein:
Damit Geräte dieser Art überhaupt funktionieren können (und ich nach der Änderung in unusual_devs.h ja eh neu kompilieren muss) sollte die Kernelkonfiguration wie folgt angepasst werden:
Device Drivers ->
USB support --->
<M> OHCI HCD support (If not use Intel or VIA chipset)
<M> UHCI HCD (most Intel and VIA) support (If use Intel or VIA chipset)
<M> USB Serial Converter support --->
[*] USB Generic Serial Driver
<M> USB driver for GSM and CDMA modems
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
Inzwischen ist usb_modeswitch fertig. Für meinen Stick muss ich leider noch etwas Handarbeit leisten. Denn in der Datei /lib/udev/rules.d/40-usb_modeswitch.rules müssen noch folgende Zeilen hinzugefügt werden:
Damit die neue Regel zur Anwendung kommen noch schnell ein:
$ udevadm control --reload-rules
Jetzt sollte es beim Einstecken vom Stick schon anders aussehen….
$ dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 4
usb 2-1: New USB device found, idVendor=19d2, idProduct=0117
usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 2-1: Product: ZTE WCDMA Technologies MSM
usb 2-1: Manufacturer: ZTE,Incorporated
usb 2-1: SerialNumber: P671A2TMED010000
usb-storage 2-1:1.0: device ignored
usb-storage 2-1:1.1: device ignored
usb-storage 2-1:1.2: device ignored
usb-storage 2-1:1.3: device ignored
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
option 2-1:1.0: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
option 2-1:1.1: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
option 2-1:1.2: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
Wohooo ein GSM Modem. Was sagt lsusb?
$ lsusb
Bus 002 Device 004: ID 19d2:0117 ONDA Communication S.p.A.
OK, der Stick wird nun also als Modem erkannt, die Datenlaufwerke werden ignoriert und ich könnte mich ja mal um eine Interneteinwahl kümmern, oder? Nötig ist dafür ppp und (weil es so schön einfach ist) wvdial. Emerge muss das wieder für mich erledigen:
$ emerge ppp wvdial
Nach kurzer Zeit ist er fertig. Nun lege ich mal das ppp Device an:
$ mknod /dev/ppp c 108 0
*umschau* ich habe ja so ein paar Tests hinter mir und Scripte können da knallhart sein. Wenn man denen sagt: „Probiere mal bis geht…“ Dann tun die das auch wenn sie 100 mal die falsche PIN eingeben. Man kann lange suchen bis man darauf kommt die PUK einzugeben. SEHR lange. Ich habe also die PIN-Eingabe abgeschaltet!
wvdial ist schnell konfiguriert. Meine Konfiguration für O2 schaut so aus:
Stecke ich nun meinen (mit abgeschalteter PIN-Eingabe) Surfstick ins Notebook beginnt er rot zu leuchten. Ist der Stick betriebsbereit und hat Netz beginnt er grün zu leuchten 🙂 Einfach, oder?
Die Einwahl funktioniert nun recht einfach mit wvdial:
$ wvdial o2
--> WvDial: Internet dialer version 1.61
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
OK
--> Sending: AT+ZOPRT=5
AT+ZOPRT=5
OK
--> Sending: AT+CGDCONT=1,"IP","pinternet.interkom.de"
AT+CGDCONT=1,"IP","pinternet.interkom.de"
OK
--> Modem initialized.
--> Sending: ATD*99#
--> Waiting for carrier.
ATD*99#
CONNECT 7200000
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Tue Mar 8 20:35:06 2011
--> Pid of pppd: 22068
--> Using interface ppp0
--> local IP address 10.151.95.132
--> remote IP address 10.64.64.64
--> primary DNS address 193.189.244.225
--> secondary DNS address 193.189.244.206
Nun sollte man auch schon online sein. Ein kurzer Blick auf die Interfacekonfiguration zeigt:
Jabber, offiziell XMPP, ist ein offenes Messaging-Protokoll. Kein zentraler Betreiber, kein Vendor Lock-in, kein Unternehmen das die Nutzungsbedingungen diktiert. Jeder kann einen eigenen Server betreiben, und die Server sprechen untereinander. Wie E-Mail, nur für Messaging.
Warum ein eigener Server
Bei kommerziellen Messengern gibt man mit der Nutzung Rechte an seinen Inhalten ab. Die AGBs von AIM, ICQ, MSN und Co. erlaubten dem Betreiber die Verwertung aller Inhalte die über den Dienst liefen. Die Dienste gibt es größtenteils nicht mehr, aber das Muster ist geblieben. Ein eigener Server bedeutet: Eigene Regeln, eigene Daten, eigene Entscheidung welche Module aktiv sind.
Die Vorteile von XMPP: Open Source, Verschlüsselung per TLS, kein Single Point of Failure, und eine riesige Auswahl an Clients für jede Plattform.
Openfire
Nach Tests mit jabberd, ejabberd und Openfire bin ich bei Openfire hängengeblieben. Für einen kleinen Server mit Familie und Freunden bringt Openfire alles mit: Weboberfläche zur Administration, Plugin-System, IPv6-Support und einfache Installation unter Debian. Für einen großen öffentlichen Server würde ich anders entscheiden, aber für meinen Zweck passt es.
Um zu zeigen wie flexibel XMPP ist: Mein Siemens Gigaset C470IP hat ein Mobilteil C47H mit eingebautem Messenger. Das Telefon verbindet sich mit dem Jabber-Server und kann Nachrichten empfangen und verschicken. Ohne App, ohne Smartphone, direkt auf dem DECT-Telefon.
Der Jabber Messenger des Gigaset C47H ist online und mit dem Server verbunden.
Am Gigaset C47H ist eine neue Jabber-Nachricht angekommen.
Die Nachricht wird am Mobilteil gelesen. Antworten funktioniert genauso.
Ohne Quota wachsen IMAP-Postfächer bis die Platte voll ist. Dovecot bringt ein Quota-Plugin mit, das die Postfachgröße begrenzt und den Benutzer warnt bevor es eng wird. Bei vollem Postfach kann Dovecot eingehende Mails mit einem temporären Fehler abweisen, statt sie sofort zu bouncen. So hat der Benutzer Zeit aufzuräumen.
Plugin aktivieren
In conf.d/20-imap.conf und conf.d/20-lmtp.conf (oder 15-lda.conf) das Quota-Plugin laden:
imap_quota sorgt dafür dass Mailclients die Quota-Information per IMAP abfragen können (GETQUOTA/GETQUOTAROOT). Die meisten Clients zeigen dann einen Fortschrittsbalken.
count ist das empfohlene Backend ab Dovecot 2.2+. Es speichert die Quotadaten in der Index-Datei und muss nicht jedes Mal alle Mails auf der Platte zählen. Das alte dirsize-Backend funktioniert zwar noch, wird aber bei großen Postfächern langsam. quota_rule = *:storage=512M setzt die Standardgröße für alle Postfächer auf 512 MB.
Quota Warnings
Dovecot kann bei bestimmten Schwellenwerten ein Script aufrufen, das eine Warnung verschickt:
Die doppelten Prozentzeichen (%%) sind nötig weil Dovecot % als Variablen-Prefix interpretiert. Das Script /usr/local/bin/quota-warning.sh bekommt den Schwellenwert und die E-Mail-Adresse als Parameter:
#!/bin/sh
PERCENT=$1
USER=$2
echo "Ihr Postfach $USER ist zu $PERCENT% belegt.
Bitte loeschen oder archivieren Sie aeltere E-Mails." | \
mail -s "Postfach $USER: $PERCENT% belegt" "$USER"
Individuelle Quotas per SQL
Wenn nicht jeder Benutzer die gleiche Postfachgröße bekommen soll, lässt sich die Quota per SQL-Abfrage pro Benutzer setzen. In der dovecot-sql.conf.ext:
user_query = SELECT \
home, uid, gid, \
CONCAT('*:storage=', quota_mb, 'M') AS quota_rule \
FROM virtual_users \
WHERE email = '%u'
Die Tabelle virtual_users braucht dafür ein Feld quota_mb. Dovecot übernimmt den Wert aus dem SQL-Ergebnis und überschreibt damit die Standardregel aus der Config. Benutzer ohne Eintrag bekommen weiterhin die 512 MB aus quota_rule.
Verhalten bei vollem Postfach
Standardmäßig gibt Dovecot bei vollem Postfach einen permanenten Fehler zurück und Postfix bounced die Mail. Mit der folgenden Einstellung wird stattdessen ein temporärer Fehler gesendet (4xx), damit Postfix die Mail in der Queue behält und es später nochmal versucht:
plugin {
quota_exceeded_message = Quota exceeded, please try again later.
}
# In der LDA/LMTP Config:
quota_full_tempfail = yes
So hat der Empfänger Zeit sein Postfach aufzuräumen, ohne dass Mails verloren gehen. Fragen? Einfach melden.
Postfix kann schon beim SMTP-Dialog prüfen, ob die Angaben des einliefernden Servers plausibel sind. Stimmt der HELO-Hostname nicht, existiert die Absenderdomain nicht im DNS, oder passt der Reverse-DNS nicht zur IP? Dann ist die E-Mail mit hoher Wahrscheinlichkeit Spam. Diese Prüfungen kosten fast nichts und filtern einen erheblichen Teil des Mülls, bevor die Nachricht überhaupt angenommen wird.
Warum das funktioniert
Ordentlich konfigurierte Mailserver melden sich mit ihrem FQDN, und der Reverse-DNS-Eintrag passt dazu. Gekaperte Rechner eines Botnetzes melden sich dagegen mit dem Hostnamen, den der Besitzer irgendwann eingegeben hat. Im besten Fall „Peters-PC“, im schlechtesten Fall gar nichts. Selbst wenn der FQDN stimmt, wird der Botnetzbetreiber kaum beim ISP einen passenden Reverse-DNS setzen lassen. Bei dynamischen IPs von DSL-Anschlüssen ist der Hostname meist nicht einmal in einem gültigen Format.
Das können wir uns zunutze machen. Wer sich nicht korrekt anmeldet, bekommt einen 5xx-Reject. Der Vorteil: Postfix beendet die Verbindung sofort und gibt Ressourcen frei. Fällt ein legitimer Absender durch diese Prüfung, hat dessen Admin nicht sauber gearbeitet. Die Fehlermeldung im Reject sagt ihm genau, was falsch ist.
smtpd_helo_required erzwingt ein HELO/EHLO von jedem Client. smtpd_delay_reject verschiebt die Ablehnung bis nach dem RCPT TO, weil manche SMTP-Clients (vor allem von Microsoft) sonst Probleme bekommen.
Die Restrictions im Detail
Die eigentlichen Prüfungen kommen in smtpd_recipient_restrictions. Hier die einzelnen Regeln und was sie tun:
reject_non_fqdn_sender — Absenderadresse ist kein FQDN. reject_non_fqdn_recipient — Empfängeradresse ist kein FQDN. reject_non_fqdn_hostname — Clientname ist kein FQDN. reject_non_fqdn_helo_hostname — HELO-Hostname ist kein FQDN. reject_invalid_hostname — Clientname hat kein gültiges Format. reject_invalid_helo_hostname — HELO-Hostname hat kein gültiges Format. reject_unknown_recipient_domain — Empfängerdomain hat keinen A- oder MX-Record. reject_unknown_sender_domain — Absenderdomain hat keinen A- oder MX-Record. reject_unknown_client_hostname — IP und Hostname des Clients passen nicht zusammen. reject_unknown_helo_hostname — HELO-Hostname hat keinen A- oder MX-Record. reject_unlisted_recipient — Empfänger nicht in der Liste gültiger Adressen. reject_unauth_destination — Domain ist weder lokal noch als Relay konfiguriert.
Die Reihenfolge ist wichtig. Postfix arbeitet die Regeln von oben nach unten ab, und die erste passende greift. permit_mynetworks und permit_sasl_authenticated stehen deshalb ganz oben, damit eigene Benutzer und vertrauenswürdige Netze nicht gefiltert werden. check_recipient_access erlaubt das Whitelisting bestimmter Empfänger (etwa postmaster@ und abuse@). Dann kommen die Blocklisten, danach die HELO- und DNS-Prüfungen.
Ein Reject im Log
So sieht ein typischer Reject aus, wenn ein Bot sich mit einem ungültigen HELO meldet:
Jun 7 17:50:35 smtp postfix/smtpd[22037]: NOQUEUE: reject: RCPT from
unknown[94.52.112.110]: 504 5.5.2 <userpc>: Helo command rejected:
need fully-qualified hostname;
from=<MackenzieSaranzak@redvanilla.com>
to=<empfaenger@domain.de>
proto=ESMTP helo=<userpc>
Der Client „userpc“ hat keinen FQDN im HELO geliefert. Postfix lehnt mit 504 ab, die Verbindung ist sofort beendet. Kein Inhalt übertragen, keine Ressourcen verbraucht.
Wie effektiv ist das?
Allein die HELO- und DNS-Prüfungen filtern 30 bis 55 Prozent des Spams. Zusammen mit den RBLs kommt man auf über 90 Prozent, bevor rspamd überhaupt etwas zu tun bekommt. Das spart Rechenzeit und macht den Content-Filter deutlich entlastet.
Wer noch weiter gehen will: Mit eigenen DNS-Blocklisten lassen sich wiederkehrende Absender und Domains gezielt sperren.
Greylisting ist ein einfacher Trick gegen Spam: Beim ersten Zustellversuch lehnt der Mailserver die Mail mit einem temporären Fehler ab (4xx). Ein regulärer Mailserver versucht es nach ein paar Minuten erneut und die Mail wird zugestellt. Spam-Botnets dagegen arbeiten nach dem „fire and forget“ Prinzip. Die probieren es kein zweites Mal, weil sie in der Zeit lieber den nächsten Empfänger anschreiben. Damit lassen sich 80 bis 90 Prozent der Botnet-Zustellungen abfangen, ohne eine einzige Mail filtern zu müssen.
Wie es funktioniert
Postgrey speichert bei jedem Zustellversuch ein Triplet aus Absender-Adresse, Empfänger-Adresse und Client-IP. Beim ersten Versuch wird die Mail abgelehnt. Kommt derselbe Server nach Ablauf der Wartezeit (Standard: 5 Minuten) nochmal, wird die Mail durchgelassen. Bekannte Triplets werden 35 Tage gespeichert, danach lernt Postgrey den sendenden Server automatisch und lässt ihn ohne Verzögerung durch (Auto-Whitelist).
Nach der Installation lauscht Postgrey auf 127.0.0.1:10023 (Debian) bzw. 127.0.0.1:10030 (FreeBSD, je nach Config). Prüfen mit ss -tlnp | grep postgrey oder sockstat -4l | grep postgrey.
Postfix-Integration
In der main.cf den Postgrey-Check in die smtpd_recipient_restrictions einfügen, nach den Authentifizierungs-Checks und vor den RBL-Checks:
Greylisting verzögert die erste Mail von jedem neuen Absender um einige Minuten. Für zeitkritische Mails (Passwort-Resets, Zwei-Faktor-Codes) kann das ein Problem sein. Postgrey führt deshalb eine Whitelist mit bekannten großen Providern (/etc/postgrey/whitelist_clients), die nie verzögert werden.
Inzwischen setzt auch rspamd Greylisting um, als Teil seines Score-basierten Ansatzes. Dort wird nur gegreylistet wenn der Spam-Score in einem Graubereich liegt. Mails die eindeutig Spam oder eindeutig sauber sind, werden sofort abgelehnt oder zugestellt. Fragen? Einfach melden.
Realtime Blackhole Lists (RBL) bzw. DNS-based Blackhole Lists (DNSBL) sind eine der ältesten und effektivsten Methoden gegen Spam. Das Prinzip ist simpel: Der sendende Server wird gegen eine Liste bekannter Spam-Quellen geprüft, noch bevor die Mail angenommen wird. Steht die IP auf der Liste, wird die Verbindung sofort abgelehnt. Der Server muss die Mail gar nicht erst annehmen, filtern oder speichern.
Vorteile und Nachteile
Der große Vorteil: Die Abweisung passiert auf SMTP-Ebene, bevor Ressourcen verschwendet werden. Bei hohem Mailaufkommen macht das einen spürbaren Unterschied. 80 bis 90 Prozent des Spam-Verkehrs lassen sich so schon beim Verbindungsaufbau abfangen.
Der Nachteil: Man verlässt sich auf Dritte. Wer auf einer RBL landet, kommt nicht immer schnell wieder runter. Und wenn ein RBL-Betreiber seinen Dienst einstellt, kann das zu Problemen führen (dazu weiter unten mehr). RBLs ersetzen keinen Content-Filter, sie ergänzen ihn.
Postfix konfigurieren
Die RBL-Abfragen werden in smtpd_recipient_restrictions in der main.cf eingetragen. Zwei Typen:
reject_rbl_client
Prüft die IP-Adresse des sendenden Servers gegen die Liste
reject_rhsbl_sender
Prüft die Domain des Absenders (rechte Seite der Adresse) gegen die Liste
zen.spamhaus.org ist die wichtigste Liste. Sie fasst mehrere Spamhaus-Listen zusammen (SBL, XBL, PBL) und deckt bekannte Spammer, Exploits und dynamische IP-Bereiche ab. bl.spamcop.net reagiert schnell auf aktuelle Spam-Wellen. ix.dnsbl.manitu.net (NiX Spam) ist eine deutsche Liste die besonders gut bei deutschsprachigem Spam funktioniert.
Die Reihenfolge ist wichtig: permit_mynetworks und permit_sasl_authenticated müssen vor den RBL-Checks stehen, damit eigene Benutzer und authentifizierte Verbindungen nicht gegen die Listen geprüft werden.
Tote RBL-Server erkennen
Stellt ein RBL-Betreiber seinen Dienst ein, werden DNS-Anfragen entweder nicht beantwortet oder liefern für jede IP einen Treffer zurück. Beides ist schlecht. Im ersten Fall laufen die Anfragen in Timeouts und bremsen alle DNS-Auflösungen aus. Im zweiten Fall wird plötzlich jede eingehende Mail abgewiesen.
Im Postfix-Log (/var/log/mail.log) erkennt man das an Timeout-Warnungen oder an plötzlich massenhaften Ablehnungen. Die Lösung: Tote Listen sofort aus der Config entfernen. Es lohnt sich, die RBL-Listen alle paar Monate zu prüfen. Bekannte Leichen aus der Vergangenheit: dnsbl.njabl.org (2013 abgeschaltet), rhsbl.ahbl.org (2015 abgeschaltet), dnsbl.sorbs.net (mehrfach instabil).
RBL-Ablehnungsmeldung anpassen
Standardmäßig schickt Postfix eine generische Fehlermeldung. Mit default_rbl_reply lässt sich eine aussagekräftigere Antwort konfigurieren, die dem Admin des sendenden Servers hilft:
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}
RBL und rspamd
Wer rspamd einsetzt, kann RBL-Checks auch dort konfigurieren statt in Postfix. rspamd fragt die Listen asynchron ab und verrechnet das Ergebnis mit dem Gesamtscore der Mail. Das ist flexibler als die harte Ablehnung in Postfix: Eine IP auf einer einzelnen Liste führt nicht sofort zur Ablehnung, sondern erhöht den Spam-Score. Erst wenn mehrere Indikatoren zusammenkommen, wird die Mail abgewiesen.
Beide Ansätze lassen sich auch kombinieren: Die wichtigsten Listen (Spamhaus) direkt in Postfix für die sofortige Ablehnung, weitere Listen in rspamd für die feinere Bewertung.
RBLs sind ein Baustein im Gesamtsystem. Zusammen mit SPF, DKIM und DMARC decken sie verschiedene Angriffsvektoren ab. Fragen? Einfach melden.
Sender Policy Framework (früher Sender Permitted From), kurz SPF, ist eine Technik, die das Fälschen des Absenders einer E-Mail auf SMTP-Ebene erschweren soll.
Klingt komplex ist es aber nicht…
Es gibt eine simplen SPF-Generator, welcher einem einen fertigen Eintrag für seinen DNS-Server erstellt.
Möchte man seine SPF Konfiguration testen gibt einem folgende Webseite viele Möglichkeiten: http://www.kitterman.com/
Der SPF-Record könnte für meine Zone wie folgendes Beispiel aussehen:
kernel-error.de. IN TXT „v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all“
Bei Fragen oder Problemen, helfe ich natürlich gerne weiter!
Funktionsweise
Dazu wird in der DNS-Zone einer Domäne ein sog. Resource Record vom Typ TXT oder SPF mit Informationen darüber hinterlegt, welche Computer E-Mails für diese Domäne versenden dürfen. Anhand dieser Informationen soll nach RFC 4408 der Empfangs-Server dann sowohl die „MAIL FROM“-Identität als auch die „HELO“-Identität des Senders nachprüfen. Absenderangaben im E-Mail-Header werden nicht überprüft.
Im DNS-Eintrag einer Domäne sind bislang schon normale MX-Einträge vorhanden, die SMTP-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an
Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können schicken soll, sieht er im MX-Record von example.org nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von example.org, sieht er im SPF-Record von example.org nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden. Mit dieser Technik lässt sich die Fälschung von Absenderadressen effektiv verhindern.
SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von Spam und zur Erschwerung von Phishing beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.
SPF muss nur vom Empfängersystem unterstützt werden – am SMTP-Protokoll der Mailübertragung ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.
DKIM (DomainKeys Identified Mail, RFC 6376) signiert ausgehende E-Mails kryptografisch. Der empfangende Mailserver prüft die Signatur über einen DNS-Record. Stimmt sie nicht, ist die Mail manipuliert oder stammt nicht vom angegebenen Absender. DKIM ist neben SPF und DMARC einer der drei Bausteine moderner E-Mail-Authentifizierung.
Wie DKIM funktioniert
Der sendende Mailserver berechnet einen Hash über definierte Header-Felder und den Body der E-Mail, verschlüsselt diesen Hash mit seinem privaten Schlüssel und hängt das Ergebnis als DKIM-Signature-Header an die Mail. Der empfangende Server holt den öffentlichen Schlüssel per DNS-Abfrage (selektor._domainkey.domain.de), entschlüsselt die Signatur und vergleicht den Hash. Stimmt er überein, ist die Mail authentisch und unverändert.
DKIM-Schlüssel erstellen
RSA mit 2048 Bit ist der Standard. 1024 Bit gilt seit Jahren als zu schwach, nicht mehr verwenden. Ed25519-Schlüssel sind kompakter und schneller, werden aber noch nicht von allen Empfängern unterstützt. Wer auf Nummer sicher gehen will, signiert mit beiden (Dual Signing).
Der Selektor (hier 2026) ist frei wählbar. Gängige Konvention: Jahr oder Monat als Selektor, das erleichtert die Key-Rotation.
DNS-Record veröffentlichen
Der öffentliche Schlüssel wird als TXT-Record im DNS veröffentlicht. Der Recordname folgt dem Schema selektor._domainkey.domain.de:
2026._domainkey.kernel-error.de. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...langer-Base64-String...IDAQAB"
Den Base64-String aus der .pub-Datei nehmen, ohne Header/Footer-Zeilen und Zeilenumbrüche, alles in eine Zeile. Bei BIND-Zonefiles auf die 255-Zeichen-Grenze pro TXT-String achten. Längere Schlüssel müssen in mehrere Strings aufgeteilt werden (BIND macht das automatisch, wenn man den Record in Anführungszeichen setzt).
rspamd als DKIM-Signer konfigurieren
rspamd bringt DKIM-Signing und -Verification von Haus aus mit, kein zusätzliches Paket nötig. Die DKIM-Signing-Dokumentation beschreibt alle Optionen. Für eine einfache Konfiguration mit einem Schlüssel pro Domain:
Nach einem service rspamd reload signiert rspamd alle ausgehenden Mails. Die Verification eingehender Mails ist standardmäßig aktiv. Das DKIM-Modul läuft automatisch und fließt in den rspamd-Score ein. Wer rspamd auch für automatisches Spam/Ham-Lernen nutzt, hat damit eine Lösung für beides.
Alternative: opendkim
Wer kein rspamd einsetzt, kann opendkim als Milter in Postfix einbinden. Die Konfiguration ist etwas aufwändiger (eigener Daemon, Socket, Milter-Einbindung in main.cf), funktioniert aber zuverlässig. Die Schlüsselerstellung und DNS-Konfiguration sind identisch.
Den einfachsten Funktionstest macht man, indem man eine Mail an eine Adresse bei Gmail oder Outlook schickt und dort die Header prüft. Im Header der empfangenen Mail steht dann:
dkim=pass bedeutet: Signatur gültig, Schlüssel im DNS gefunden, Hash stimmt überein.
Key-Rotation
DKIM-Schlüssel sollten regelmäßig getauscht werden. Einmal pro Jahr ist ein guter Rhythmus. Der Ablauf:
Neuen Schlüssel mit neuem Selektor erstellen (z.B. 2027)
Neuen DNS-Record veröffentlichen
rspamd auf den neuen Selektor umstellen
Alten DNS-Record noch 30 Tage stehen lassen (für Mails die noch in Queues liegen)
Alten Record löschen
Durch die Selektoren können alter und neuer Schlüssel parallel im DNS existieren. Empfänger prüfen immer den Selektor aus dem DKIM-Signature-Header, es gibt keine Unterbrechung.
DKIM allein reicht nicht
DKIM beweist nur, dass eine Mail von einem bestimmten Schlüssel signiert wurde, nicht dass der Absender im From:-Header berechtigt ist, diese Domain zu nutzen. Dafür braucht es die anderen Bausteine:
SPF — definiert per DNS, welche IP-Adressen für eine Domain Mails versenden dürfen
DMARC — verknüpft SPF und DKIM mit einer Policy: Was soll der Empfänger tun, wenn beides fehlschlägt?
DANE/TLSA — sichert den Transportweg per DNSSEC ab
Dieses soll eine kleine Beschreibung über die Gründe, die eigentliche Installation und Einrichtung meines privaten SambaServers werden. Also kein HowTo!
Sollte jemand Fragen oder Anregungen haben, freue ich mich natürlich über jede E-Mail. Solltest du Fragen stellen achte bitte darauf deine Frage so genau wie irgend mäglich zu stellen. Beschreibe kurz dein Problem, haue mich nicht mit log und configs zu und habe etwas Geduld. Ich bekomme nicht nur eine E-Mail am Tag. Darum werde ich ganz sicher nur auf unfreundliche und ungenaue Fragen antworten. KEINER hat ein Recht drauf von mir Support zu bekommen!!
Nun, die Situation bei mir schaut ca. so aus: Meine Familie, der Nachbar und ich selbst sitzen zusammen im Netzwerk. Zu dem kommt immer mal wieder Besuch zu uns. Da wir auch etwas mehr Platz als der normale Durchschnitt haben, finden auch oft irgendwelche LANs usw. bei uns stat. Zu dem hängt noch eine Firma und ein geschlossenes WLAN mit drin.
Wenn man mehr als nur einen Rechner hat kommt es schnell vor, dass man bestimmte Daten nicht nur an einem Rechner braucht. Aus diesem Grund habe ich mir hier einen FileServer aufgestellt und alle möglichen Daten dort abgelegt. Jetzt stellt sich die Frage wie von einem anderen Rechner an diesen herankommen? Da ich selbst nur LinuxSysteme nutze (der FileServer ist also auch Linux basiert) mache ich das ganze über ssh/scp oder halt über NFS. Jetzt sind aber noch mehr Menschen in meinem Netzwerk. Diese wollen nun auch ihre Daten dort ablege. Zum Einen, weil dort mehr Platz ist als auf ihrem Rechner und zum Anderen weil dort täglich eine Datensicherung gefahren wird. Die Rechte für einen NFSShare sind schnell angelegt… bringt nur leider nichts, wenn es WindowsUser sind, welche auf die Shares zugreifen wollen. Microsoft Systeme managen so etwas fast immer über das SMB Protokoll.
Server Message Block (kurz SMB) ist ein Protokoll für Datei, Druck und andere Serverdienste im Netzwerk unter Microsoft WindowsBetriebssystemen. Es ist der Kern der Netzwerkdienste von Microsofts LANManager, der WindowsProduktfamilie, sowie des LANServers von IBM.
Samba ist eine freie SoftwareSuite, die das Server Message Block Protokoll (SMB) für UnixSysteme verfügbar macht. Dieses Protokoll wird manchmal als CIFS (Common Internet File System), LanManager oder NetBIOSProtokoll bezeichnet.
Samba ist damit in der Lage, Funktionen eines WindowsServer zu übernehmen. Es gilt als stabiler und performanter als die WindowsAlternative und ist, da zudem noch frei verfügbar, auch bei vielen Firmen und Organisationen sehr angesehen.
Würde sagen: Ich mach es mit Samba 🙂
Samba wird recht übersichtlich in einer einfachen Konfigurationsdatei konfiguriert. Diese liegt normalerweise im Ordner /etc/samba und nennt sich smb.conf.
Ich liste erst mal meine hier auf und erläutere dann weiter unten die wichtigsten Einträge!
######### /etc/samba/smb.conf # Anfang #########
[global]
#
#Servername / Domain / usw.
netbios name = kernelerror
server string = HAUPT_Server
#
#Arbeitsgruppe
workgroup = servers
#
#Passwoerter gleichzeitig aedern und Sicherheits..
unix password sync = yes
passwd program = /usr/bin/passwd %U
passwd chat = *password* %n\n *password* %n\n *successfull*
min password length = 2
admin users = kernel
force directory mode = 0750
directory mask = 0750
force create mode = 0750
create mask = 0750
encrypt passwords = Yes
update encrypted = Yes
map to guest = Bad User
host allow 192.168.0. 127.
#
#Server und PDC einstellungen
domain master = Yes
name resolve order = dns host bcast wins
nt acl support = Yes
nt pipe support = Yes
nt smb support = Yes
wins support = Yes
wins proxy = Yes
name resolve order = dns host bcast wins
logon path = \\%L\profiles\%U
time server = Yes
socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
keepalive = 120
preferred master = Yes
logon script = %U.bat
domain logons = Yes
os level = 65
logon drive = u:
logon home = \\%L\Profiles\%U
# NT RUMMEL
add user script = /usr/bin/useradd d /dev/null g machines c 'Machine Account' s /bin/false M %u
add user script = /usr/bin/useradd s /bin/false %u
username map = /etc/samba/smbusers
#
# Logs
max log size = 250
log file = /var/log/samba/samba.log.%m
debug level = 3
log level = 1
syslog = 0
#
# Speed
read raw = Yes
write raw = Yes
stat cache = Yes
stat cache size = 50
shared mem size = 5242880
#
# sonstiges
interfaces = 192.168.0.10/24
printing = cups
printcap name = CUPS
load printers = yes
#
# Lange Dateinamen und Umlaute
protocol = NT1
default case = lower
mangle case = no
mangled names = yes
case sensitive = no
preserve case = yes
short preserve case = yes
[netlogon]
comment = Logon Scripts
path = /home/netlogon
browseable = no
[homes]
comment = Heimatverzeichnis
writeable = Yes
browseable = No
[system]
comment = Server
path = /
writeable = yes
browseable = no
read only = no
valid users = kernel
write list = kernel
read list = kernel
[pool]
create mask = 0755
directory mask =0755
comment = Der Pool
path = /home/pool
writeable = yes
browseable = no
read only = no
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mode = 0700
browseable = No
writeable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
create mask = 0664
directory mask = 0775
######### /etc/samba/smb.conf # Ende #########
Wie man sehen kann ist die Konfigurationsdatei in mehrere Bereiche aufgeteilt. Ein Berich beginnt immer mit:
[bereichname]
Der Bereich „global“ sollte immer vorhanden sein. Einstellungen die man nicht vorgibt werden vom SambaDeamon mit den Standardwerten gefahren. Im Bereich „global“ werden nun alle Einstellungen gesetzt die für den SambaServer selbst gelten. Die ersten beiden Punkte lasse ich aus, da sie sich selbst erklären sollten.
Interessant wird es meiner Meinung nach hier: unix password sync = yes passwd program = /usr/bin/passwd %U passwd chat = *password* %n\n *password* %n\n *successfull* min password length = 2
Hiermit gebe ich dem SambaServer vor, dass die Benutzer welche auf der Unix bzw. Linuxebene angelegt werden auch gleichzeitig im SambaServer angelegt werden. Natürlich mit dem gleichen Passwort, welches aber nicht kürzer als zwei Zeichen lang sein darf. Zu dem können User auf NTBasierten Systemen ihr Passwort von diesen aus selbst ändern, sofern es ihnen erlaubt ist versteht sich. Die User können natürlich mit ihrem Passwort auch auf der Konsole angelegt werden. Man muss aber darauf achten, dass der Username schon auf der Unixebene existiert. Sie müssen nicht zwingend die gleichen Kennwörter unter Unix/Linux und Samba haben. Angelegt wird ein User mit:
smbpasswd -a username [als root auf der Konsole]
Sollte der User schon unter Samba existieren wird sein Eintrag mit einfach nur aktualisiert.
admin users = kernel
Dieser Eintrag gibt den Benutzer an, welcher nach seiner Anmeldung auf den Shares, mit den Rechten des Unix Users Root Dateien und Ordner anlegt / liest / bearbeiten. Hier sollte man vorsichtig sein. Dieser User hat wirklich die gleichen Rechte wie der ROOTUser!!
map to guest = Bad User
Ist dies so angegeben, können nur User auf den Server zugreifen, welche sich auch anmelden. Ein User kann sich am System anmelden, muss aber keinen Zugriff auf einen Share haben.
#Server und PDC einstellungen
Ab diesem Eintrag wird dem SambaServer gesagt das er als PDC für die oben angegebene Domain arbeiten soll. Die einzelnen Punkte haben schöne passende Namen, daher sollte man sie auch so verstehen können. Gibt es Fragen? ==> einfach mailen! Hat man NTBasierte Systeme, welche sich auch am PDC anmelden sollten, muss man einen Computeraccount für den jeweiligen Rechner anlegen. Das ist viel Arbeit pro Rechner. Da NTSysteme das aber selbst können, sollten sie doch die Arbeit für uns machen, oder? Daher müssen wir noch folgendes eintragen:
Können dem Samba Server etwas einheizen. Sie können den Server um 50% schneller laufen lassen. Die Hardware sollte aber mitspielen, sonst verliert man Daten.
Zum Drucken unter Linux nutze ich seit einiger Zeit CUPS. Um Windows jetzt auch den Zugriff auf diese Drucker zu gewähren muss ich Samba angeben, dass ich CUPS zur Druckerverwaltung nutze. Dieses mache ich mit diesem Eintrag:
Wenn man den SambaServer als PDC betreibt möchte man natürlich auch für Windows die Loginscripte nutzen. Damit einfach und schnell die Uhrzeit abgeglichen wird oder Laufwerke und Drucker beim Anmelden eingebunden werden. Dazu muss ein neuer Bereich mit dem Namen „netlogon“ angelegt werden. Das Ganze schaut dann wie folgt aus.
Der Text hinter comment wird als kleine Beschreibung bei den Shares angezeigt. path gibt den Unixpfad zum Ordner an, welcher „freigegeben“ werden soll. Ist browseable auf no gesetzt wird die Freigabe nicht in der Netzwerkumgebung usw. angezeigt.
Ich habe hier folgendes aufgenommen um es zu beschreiben. Man sollte das aber nicht machen! [system] comment = Server path = / writeable = yes browseable = no read only = no valid users = kernel write list = kernel read list = kernel
Hier wurde der Bereich system angelegt. Vielleicht sollte ich an dieser Stelle sagen, dass der Bereichsname auch gleichzeitig der Name des Shares ist. Hier taucht der Schalter writeable und read only auf. Die Schalter machen von der Logik her das gleiche. Ich setzte immer beide um sicher zu gehen das auch wirklich das passiert was ich will. Sie verhindern oder erlauben das Schreiben auf Shares. Der Punkt valid users gibt an, welche user überhaupt das Recht haben auf diesen Share zuzugreifen. write list bestimmt die User die auf dem Share schreiben oder verändern dürfen. read list erlaubt oder verbietet halt das lesen.
Folgende Einträge geben an, mit welchen UnixBerechtigungen Daten auf den Shares geschrieben werden sollen. Unter Daten fallen auch Ordner.
force directory mode = 0750 directory mask = 0750 force create mode = 0750 create mask = 0750
Ich glaube mit diesen Angaben hat jeder nun schon einen kleinen überblick über dass, was mit dem SambaServer möglich ist und wie ich es hier eingesetzt habe.
