Kategorien-Archiv Blog

PHP Fatal error: Uncaught Error: Call to undefined function curl_init() kopano-webmeeting kaputt nach ucs 4.3-2 update

Warum auch immer, hat das Update von Kopano 4.2-5 zu 4.3-2 das php-curl Paket deinstalliert. Genaue Fehlermeldung war:

[Mon Nov 12 18:29:08.878397 2018] [:error] [pid 24048] [client client-ip:33460] PHP Fatal error: Uncaught Error: Call to undefined function curl_init() in /usr/share/kopano-webapp/plugins/spreedwebrtc/php/class.turnauth.php:42\nStack trace:\n#0 /usr/share/kopano-webapp/plugins/spreedwebrtc/php/module.spreedwebrtc.php(100): TurnAuthConnector->getTurnAuthData()\n#1 /usr/share/kopano-webapp/server/includes/core/class.jsonrequest.php(57): PluginSpreedwebrtcModule->execute()\n#2 /usr/share/kopano-webapp/kopano.php(139): JSONRequest->execute(‚{„zarafa“:{„plu…‘)\n#3 {main}\n thrown in /usr/share/kopano-webapp/plugins/spreedwebrtc/php/class.turnauth.php on line 42, referer: https://mail.kundendomain.de/webapp/

Lösung war apt-get install php-curl

Spam- und Virenfilterung 2018 mit Postfix, postscreen und amavis-milter – eine Übersicht

Heutiger Anspruch: MX-Server mit zuverlässigem und rechtssichierem Spam- und Virenfilter

Es gibt zu diesem Thema etliche Bücher, gefühlte 100.000 Howtos und annähernd eine Million Fragen bei Google dazu.

Was ich jedoch im Kern vermisse ist eine aktuelle Bestandsaufnahme, was denn sinnvoll ist um Ressourcen zu schonen, es den Spammern so schwer wie möglich zu machen und alle rechtlichen Anforderungen zu erfüllen.

Herausgekommen ist ein interner 2-Tage Workshop bei uns (cubewerk) um das Thema zu durchleuchten. Hier die Fakten:

Wer Mails einmal annimmt, muss sie zustellen
Der Benutzer möchte im Idealfall ein spam- und virenfreies Postfach
Der Admin möchte seine Serverlast schonen und ein Setup so einfach wie möglich
Teure Checks (CPU-Leistung) sind Inhaltsfilterkontrollen wie Spam- oder Virenprüfungen – diese sollen vermieden werden oder nur als letzte Option zum Einsatz kommen.

Als Basis dient uns Postfix mit postscreen. Postscreen ist eine Postfix-Erweiterung um es den Spammern besonders schwer zu machen. Konkret werden Missachtungen des SMTP-Protokolls bestraft und einlieferende Absender können sich eine positive Reputation aufbauen. Zusätzlich kommen Tricks zum Einsatz, welche z.B. spontan die Verbindung trennen, Einlieferer ausbremsen oder falsche Infos streuen, damit der Sender kurzzeitig verwirrt ist. Ein echter Absender versucht es einfach erneut. Der Spammer verliert hier längst die Geduld. Hierdurch lässt sich die Masse der Spam-Mails aus Botnetzen ausbremsen.

Da es viele Methoden gibt um eine E-Mail auf Ham oder Spam abzuklopfen, ist die richtige Reihenfolge entscheidend. Auch hier um eigene Rechenleistung zu schonen. Hier unser empfohlenes Setup: (Reihenfolge von oben nach unten). Jeder Check der scheitert, führt zur Terminierung der SMTP-Verbindung.

Postscreen mit genannten Checks / Tests

Prüfen der Absender-IPs gegen gängige Blacklists (spamhaus, zen usw.)
Prüfung ob Absender im MAIL FROM FQDN verwendet – kein <a> erlaubt sondern nur <a@b.de>
Prüfen ob Empfänger im RCPT TO gültigen FQDN darstellt – kein <stefan> erlaubt sondern nur <stefan@machine.tld>
Prüfen ob Absender im MAIL FROM eine Domain verwendet, die gültige DNS-Einträge besetzt (A,MX)
Prüfen ob Empfänger im RCPT TO gültige Domain verwendet, die gültige DNS-Einträge besitzt (A,MX)

Bis zu diesem Zeitpunkt hat der Absender noch keine Gelegenheit, überhaupt den Body also Mailinhalt zu übermitteln – konnte aber bereits aus vielerlei Gründen abgelehnt worden sein.

Jetzt erfolgt eine Prüfung, ob der Empfänger selbst, überhaupt lokal bzw. auf nachgelagerten Systemen existiert.

Hat es der Absender bis hier geschafft, kann darf er jetzt mit DATA den Body/Inhalt der E-Mail übermitteln. Keine Annahme – nur Übermittlung!

ACHTUNG: Auch bis hier hin, wurde die E-Mail nicht angenommen. Die Verbindung zwischen Sender->Empfänger besteht, die Mail wurde aber noch nicht angenommen.

Jetzt erfolgt eine interne Übergabe der Mail über das Milter-Protokoll an Amavis (amavis-milter).

Hier wird geprüft, ob die E-Mail selbst, nach üblichen Kriterien nach Spam aussieht oder ob ein Anhang virenversucht ist. Zur Erinnerung – der Absender wartet immer noch.

Kommt es hierbei zu Auffälligkeiten, wird die Verbindung erneut einfach terminiert und die E-Mail abgelehnt.

Final – wenn alle Schritte erfolgreich sind, wird dem Absender die Annahme mit einem 250-Statuscode quittiert und die E-Mail zugestellt.

Nachtrag: Milter / Proxies

Es wurde bewusst darauf verzichtet, in Postfix smtpd_proxy_filter zu verwenden. Dies vereinfacht das Setup nicht.

Postfix selbst kann über den amavis-milter einfach ein nachgelagertes Programm aufrufen, bekommt eine Info über den erfolgreichen Check und wertet diesen aus. SPAM/VIREN oder OK.

In setups mit smtpd_proxy_filter muss der nachgelagerte Proxy, die geprüften E-Mails weiterleiten oder zustellen. Dies ist nicht gewollt.

Quellen:

http://www.postfix.org/postconf.5.html#smtpd_milters
https://blog.sys4.de/amavisd-milter-howto-de.html
http://www.postfix.org/POSTSCREEN_README.html
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Antispam/Antispam-Strategien.pdf

pfsense OpenVPN-Benutzer feste IP-Adresse zuweisen

Man definiere einen VPN-Server und denke sich ein IPv4 Tunnel-Netzwerk aus. Hier 10.8.0.0/24

Man definiere Netzstruktur -> net30

Man lege fest pro Kunde (Match auf CN des Zertifikats) eine clientspezifische Überschreibung

und setze nur bei Erweiterte Einstellungen -> ifconfig-push 10.8.0.6 10.8.0.5

Jeweils eine /30-Netz.

10.8.0.6 10.8.0.5 (0.6 jeweils Client)

Das nächste also dann 10.8.0.10 10.8.0.9 usw.

Otrs Benachrichtigung trägt keinen Absender from: <>

Core::Sendmail

SendmailNotificationEnvelopeFrom::FallbackToEmailFrom x

muss gesetzt sein. Dann klappt es auch mit dem Agenten.

Update 25.09.18:

Laut Mail RFC kann man das dann schon so machen. Gedacht für auto-reply Mails und bounces um Loops zu vermeiden. Laut Standard muss das auch jeder Mailserver können.

Aus meiner Sicht sollte aber OTRS per Default, nicht mit null-Adresse verschicken.

postfix ignoriert Einträge in alias Datei

Heute hatten wir einen „lustigen“ Fehler. Neue Einträge in die Postfix-Alias Datei wurden nach einem postalias bzw. newaliases umgehend erkannt, aber ein spezieller Eintrag wurde ignoriert.

Postfix-Neustart und Ähnliches brachte keine Änderung.

Beim Restart fiel auf, dass Postfix ein Problem mit der verify_cache DB hatte.

Sep 13 16:42:34 mail01 postfix/verify[22858]: close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)

Ein setzen von address_verify_map = btree:$data_directory/verify_cache_new

in main.cf und neustart von Postfix, hat scheinbar die DB „bereinigt“. Ab dann war der neue alias auch greifbar.

Zum debugging ganz hilfreich:

postmap -vs btree:/var/lib/postfix/verify_cache

Zeigte in unserem Fall auch, dass hier ein völlig veralteter und fauler Eintrag war.