Da missverstehst du mich aber. Das ein Log nicht sauber bleibt ist mir klar, ich bin immerhin seit über 20 Jahren in der IT tätig.
Dass ich meinen Kunden dann aber eine andere Software empfehlen würde wenn eine ständig Mist baut ist wieder ein anderes Thema.
Von M$ red ich mal nicht, denn wer einen eigenen Mailserver auf Basis von OpenSource betreibt und dann mit Outlook oder ähnlichem darauf zugreift, um seine E-Mails doch wieder nach Redmond zu syncen.. naja lassen wir das
Iitsaw
- 2 days ago
- Joined Jul 22, 2021
- 5 discussions
- 17 posts
- 2 best answers
- Post posted... wait what? You got the answer! You got likes! Starter
Ja den User zu blocken ist immer ein Problem.
Wobei dieser ja doch meistens beim zweiten Versuch eine ID mitliefert. Zumindest hab ich das bei einem Thunderbird im Log gesehen.
Wenn BlueMail wirklich mehrfach versucht ohne Auth das Autodiscover abzuklappern würde ich mir überlegen ob die Software richtig funktioniert.Und ja, das ganze mit einer Firewall nochmals abzusichern klingt durchaus plausibel, dann kann ich aber auch die bekannten IPs einfach bei meinem RZ-Betreiber in die FW eintragen, ist zwar immer wieder ein händischer Prozess, aber so viele kommen bei mir zum Glück zur Zeit nicht an
Na ein Webcrawler eher nicht, die IP hab ich mal gegengecheckt, die taucht doch auf einer bruteforce-Liste auf.
Dass wir ein gewisses Grundrauschen haben ist klar, die Frage hier geht ja eher in die Richtung in welchem Log das liegt und ob dieses nicht durch den Netfilter / fail2ban zu prüfen wäre / ist.In dem von dir verlinkten Beitrag hatte ich ja auch schon geantwortet und die abuseipdb bringt eben auch nur etwas wenn der Netfilter dann auch die Zugriffe auf die Autodiscover blockt. Wenn dies nicht passiert bringt auch das sperren von IPs nichts.
Hallo zusammen,
da ich auch immer mal wieder solche Einträge im Autodiscover Log habe
wollte ich doch einmal nachfragen ob Autodiscover im Netfilter mit überprüft wird.Wenn nein, macht es nicht Sinn das auch mit aufzunehmen? Es sind ja, wenn man das ganze genau Betrachtet, Angriffe auf die Serverinfrastuktur.
Danke für euren Input.
Achja.. und zum “Logs clean halten”:
Ich würde eher versuchen die Logs in ein SIEM zu holen und dann dort auich wirklich die Auswertungen zu betreiben.
Denn man kann davon ausgehen dass eben nicht nur der Mailserver so stark besucht wird, sondern bene auhc die Wordpress-, Joomla-, Nextcloud- oder weitere Instanzen.
Dann macht es durchaus Sinn wenn man sehen kann ob die Angreifer gezielt vorgehen oder es eben nur Grundrauschen ist.@MaxPain Das ganze IST noch Grundrauschen, die Botnetze kommen mal mehr mal weniger stark durch.
Auch Versuche aus den üblichen Ländern kommen immer mal wieder in Wellen auf.
GeoBlocking kann ich auf meinem Server, der auch von weiteren genutzt wird, auch nicht einsetzen.
Gelegentlich blocke ich bei der Firewall des RZ-Betreibers mal einige IPs wenn es zu viel werden sollte.Das ganze sind eben Bruteforce Versuche um in die Mailbox zu kommen, solange, wie @mlcwuser bereits schrieb, die Passwörter nicht einfach zu erraten sind, sehe ich da keine größere Gefahr.
Jeder Mailserver ist mal dran.
Ganzjahresgriller
Oha du sperrst gleich ein ganzes /24er aus.
Deine Bannzeit ist höher als die maximale Bannzeit oder fehlt da eine oder mehrer Stellen bei der maximalen?Bei mir versuchen Sie es im Moment immer nur einmal, anscheinend lernen die Botbetreiber dazu
Das sieht mir aber nach einem typischen Grundrauschen aus. In meinem Netfilter-Log seh ich nur noch Warnungen seit ich meine Fail2Ban-Parameter so gesetzt habe:
Bannzeit in Sekunden: 86400 Maximale Bannzeit in Sekunden: 604800 Bannzeit erhöht sich mit jedem Bann Max. Versuche: 5 Wiederholungen im Zeitraum von (s): 600 Netzbereich für IPv4-Banns (8-32): / 32 Netzbereich für IPv6-Banns (8-128) : / 128
Und ja, ich sperre einfach gleich mal für 24 Stunden und bis zu 7 Tagen. False-Positives kann ich ja jederzeit händisch herausnehmen.
Aber gewöhnt euch daran, es wird nicht weniger, so lästig das ist.
- Edited
Hallo zusammen,
ich habe gestern meinen Mailserver auf die aktuelle Debian gehoben und dabei scheint wohl irgendwie der Wurm hineingekommen zu sein.
Docker startet die Kuh nicht mehr und ich bin jetzt doch etwas ratlos.
Hier mal die Ausgabe vom Update-Script:Detecting if your IP is listed on Spamhaus Bad ASN List... Check completed! Your IP is clean Checking internet connection... OK Detecting which build your mailcow runs on... You are receiving stable updates (master). To change that run the update.sh Script one time with the --nightly parameter to switch to nightly builds. Checking for newer update script... Updated 0 paths from ebbae122 Are you sure you want to update mailcow: dockerized? All containers will be stopped. [y/N] y Native IPv6 implementation available. This will enable experimental features in the Docker daemon and configure Docker to do the IPv6 NATing instead of ipv6nat-mailcow. !!! This step is recommended !!! mailcow will try to roll back the changes if starting Docker fails after modifying the daemon.json configuration file. Should we try to enable the native IPv6 implementation in Docker now (recommended)? [y/N] y Warning: You seem to have modified the /etc/docker/daemon.json configuration by yourself and not fully/correctly activated the native IPv6 NAT implementation. You will need to merge your existing configuration manually or fix/delete the existing daemon.json configuration before trying the update process again. Please merge the following content and restart the Docker daemon: {"ipv6":true,"fixed-cidr-v6":"fd00:dead:beef:c0::/80","experimental":true,"ip6tables":true} Validating docker-compose stack configuration... Checking for conflicting bridges... Saving diff to update_diffs/diff_before_update_2023-09-08-00-09-54... Prefetching images... 1.17: Pulling from mailcow/unbound Digest: sha256:e18456e3b91d542124229b6e089f02ea2c94a006c5d7eed9874d28a3577f6aa9 Status: Image is up to date for mailcow/unbound:1.17 docker.io/mailcow/unbound:1.17 10.5: Pulling from library/mariadb Digest: sha256:e16184ec37826ccdc2ea104211196623177232bfb166f60048832ea5e75975f4 Status: Image is up to date for mariadb:10.5 docker.io/library/mariadb:10.5 7-alpine: Pulling from library/redis Digest: sha256:ef3296cb1b3a7eb40f2a992a398777a1c0b5b21df44f1a5bef84067f772daf54 Status: Image is up to date for redis:7-alpine docker.io/library/redis:7-alpine 1.61: Pulling from mailcow/clamd Digest: sha256:215b554a25deaeec750a175e73fa4636ec52e77c000da29dde00953c31fd20f4 Status: Image is up to date for mailcow/clamd:1.61 docker.io/mailcow/clamd:1.61 1.92: Pulling from mailcow/rspamd Digest: sha256:92e3274dbf02fdfc74c5b6209f4fc0c74f6fee04211b2fca53188c30ad846ded Status: Image is up to date for mailcow/rspamd:1.92 docker.io/mailcow/rspamd:1.92 1.84: Pulling from mailcow/phpfpm Digest: sha256:967163dd2815cb738f4676beaa02c55f2614f3c087456511aa4b234706598e07 Status: Image is up to date for mailcow/phpfpm:1.84 docker.io/mailcow/phpfpm:1.84 1.118: Pulling from mailcow/sogo Digest: sha256:297fd2f6dbac34e5bcd3afc0e2c8919ceb967bfa56ba21d8d5c9b4d9fd08884d Status: Image is up to date for mailcow/sogo:1.118 docker.io/mailcow/sogo:1.118 1.24: Pulling from mailcow/dovecot Digest: sha256:9cca8bc552b02c06ac9d972d3683c3029ca4ddada884fefac12c93400fc77dce Status: Image is up to date for mailcow/dovecot:1.24 docker.io/mailcow/dovecot:1.24 1.71: Pulling from mailcow/postfix Digest: sha256:c6f883187f893cb9d98a253bb164698cf3aef8fd239cda50927081a1c24c6112 Status: Image is up to date for mailcow/postfix:1.71 docker.io/mailcow/postfix:1.71 alpine: Pulling from library/memcached Digest: sha256:6849b4e9ffa403adcb394b5874c0a392c2727dd87d74999c4b300bdc1bd37f22 Status: Image is up to date for memcached:alpine docker.io/library/memcached:alpine mainline-alpine: Pulling from library/nginx Digest: sha256:16164a43b5faec40adb521e98272edc528e74f31c1352719132b8f7e53418d70 Status: Image is up to date for nginx:mainline-alpine docker.io/library/nginx:mainline-alpine 1.84: Pulling from mailcow/acme Digest: sha256:75c7a4526fa81f50541debf78b288cf650d32cc41089c8c35b28c5379ff81e0d Status: Image is up to date for mailcow/acme:1.84 docker.io/mailcow/acme:1.84 1.52: Pulling from mailcow/netfilter Digest: sha256:2bb9ee45e6e95e86ddb290fa77117cc33b140f75d1cc37fa230108b75e714d33 Status: Image is up to date for mailcow/netfilter:1.52 docker.io/mailcow/netfilter:1.52 1.97: Pulling from mailcow/watchdog Digest: sha256:3e766c2c2171eab9de924164f19dc077a8fa5c7190ac66b945a63b7e58e5b018 Status: Image is up to date for mailcow/watchdog:1.97 docker.io/mailcow/watchdog:1.97 2.05: Pulling from mailcow/dockerapi Digest: sha256:3f638ff36987fc8831bc226cd32f6ca22497323eff8353564b09ce21997fe8b4 Status: Image is up to date for mailcow/dockerapi:2.05 docker.io/mailcow/dockerapi:2.05 1.8.1: Pulling from mailcow/solr Digest: sha256:c36a3fda39d51016b3e59253fb4ceb497ab11ee4f62c8e6460f8a425137bb763 Status: Image is up to date for mailcow/solr:1.8.1 docker.io/mailcow/solr:1.8.1 1.11: Pulling from mailcow/olefy Digest: sha256:006ca6ff012f393cee87facadb480278317a839c7546b2ba94b94afdbb1f3ff7 Status: Image is up to date for mailcow/olefy:1.11 docker.io/mailcow/olefy:1.11 latest: Pulling from mcuadros/ofelia Digest: sha256:21082a58c3d0d5d5b8615ac7d1ac5d039074728735879c76baf876c4358cbc3e Status: Image is up to date for mcuadros/ofelia:latest docker.io/mcuadros/ofelia:latest Using default tag: latest latest: Pulling from robbertkl/ipv6nat Digest: sha256:0cf4971efbe9df3c39f6b11666bece782891856598c6d3649e900afc88f76c00 Status: Image is up to date for robbertkl/ipv6nat:latest docker.io/robbertkl/ipv6nat:latest Stopping mailcow... [+] Running 1/1 ⠿ Network mailcowdockerized_mailcow-network Removed 0.3s Checking for remaining containers... Committing current status... Fetching updated code from remote... Merging local with remote code (recursive, strategy: "theirs", options: "patience"... Already up to date. Fetching new images, if any... [+] Running 19/19 ⠿ ipv6nat-mailcow Pulled 1.0s ⠿ netfilter-mailcow Pulled 1.0s ⠿ memcached-mailcow Pulled 1.0s ⠿ nginx-mailcow Pulled 1.0s ⠿ solr-mailcow Pulled 1.0s ⠿ acme-mailcow Pulled 1.0s ⠿ dovecot-mailcow Pulled 0.9s ⠿ dockerapi-mailcow Pulled 1.0s ⠿ ofelia-mailcow Pulled 1.0s ⠿ redis-mailcow Pulled 1.0s ⠿ unbound-mailcow Pulled 0.9s ⠿ olefy-mailcow Pulled 0.9s ⠿ sogo-mailcow Pulled 0.9s ⠿ rspamd-mailcow Pulled 1.0s ⠿ watchdog-mailcow Pulled 1.0s ⠿ clamd-mailcow Pulled 1.0s ⠿ postfix-mailcow Pulled 1.0s ⠿ php-fpm-mailcow Pulled 1.0s ⠿ mysql-mailcow Pulled 1.0s Checking IPv6 settings... Starting mailcow... [+] Running 1/1 ⠿ Network mailcowdockerized_mailcow-network Created 0.1s ⠋ Container mailcowdockerized-memcached-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-watchdog-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-unbound-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-redis-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-dockerapi-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-olefy-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-sogo-mailcow-1 Creating 0.0s ⠋ Container mailcowdockerized-solr-mailcow-1 Creating 0.0s Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/370b4b3fbbaa7f9ab5d4f0f1498a6afb571e014f948110c75309fb3ab719a824/merged: invalid argument
Hier die Docker info:
Client: Docker Engine - Community Version: 24.0.6 Context: default Debug Mode: false Plugins: compose: Docker Compose (Docker Inc.) Version: v2.21.0 Path: /usr/libexec/docker/cli-plugins/docker-compose scan: Docker Scan (Docker Inc.) Version: v0.23.0 Path: /usr/libexec/docker/cli-plugins/docker-scan Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 25 Server Version: 24.0.6 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: false Native Overlay Diff: true userxattr: false Logging Driver: json-file Cgroup Driver: systemd Cgroup Version: 2 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: io.containerd.runc.v2 runc Default Runtime: runc Init Binary: docker-init containerd version: 8165feabfdfe38c65b599c4993d227328c231fca runc version: v1.1.8-0-g82f18fe init version: de40ad0 Security Options: seccomp Profile: builtin selinux cgroupns Kernel Version: 6.1.0-11-amd64 Operating System: Debian GNU/Linux 12 (bookworm) OSType: linux Architecture: x86_64 CPUs: 12 Total Memory: 62.66GiB Name: mail ID: SJFV:AWEY:QACZ:Q5IE:PL3Z:BQWT:PWDG:VJOW:CACS:3TP4:GY2C:SQQA Docker Root Dir: /var/lib/docker Debug Mode: false Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false
Ich hoffe jemand von euch kann mir hier den passenden Tip mitgeben
Hallo zusammen,
beim erstellen eines Temines in SoGo ist es nicht möglich einen anderen als den persönlichen Kalender auszuwählen.
Siehe
SoGo Bugtracker undAls Workarround kann man natürlich den Termin im eigenen Kalender erstellen und dann bearbeiten, da kann man ja wieder alle auswählen, siehe Mailinglist.
Eventuell eine Lösung hier vorhanden?
Danke schon und vielel Grüße
Nach dem Update eben sieht das ganze sehr gut aus.
Sollten noch Fehler auftauchen meld ich mich hier wieder :-)Danke für die schnelle Behebung
"An unknown error occured: TypeError Object\n(\n [message:protected] => Twig\\Environment::render(): Argument #2 ($context) must be of type array, null given, called in \/web\/inc\/footer.inc.php on line 45\n [string:Error:private] => \n [code:protected] => 0\n [file:protected] => \/web\/inc\/lib\/vendor\/twig\/twig\/src\/Environment.php\n [line:protected] => 275\n [trace:Error:private] => Array\n (\n [0] => Array\n (\n [file] => \/web\/inc\/footer.inc.php\n [line] => 45\n [function] => render\n [class] => Twig\\Environment\n [type] => ->\n [args] => Array\n (\n [0] => \n [1] => \n )\n\n )\n\n [1] => Array\n (\n [file] => \/web\/qhandler.php\n [line] => 108\n [args] => Array\n (\n [0] => \/web\/inc\/footer.inc.php\n )\n\n [function] => require_once\n )\n\n )\n\n [previous:Error:private] => \n)\n"
Seit einem Update am gestrigen 21.10.2021 wirft das Log den oben angezeigten Fehler und der qhandler zeigt keinerlei Daten mehr um welche SPAM es sich handelt. Das kein Stylesheet gezogen wird kann man noch verkraften.
Hat jemand einen Tip für mich?
Hello,
Have a look at the configurations on Android and possibly also on Windows Mail.
If you go via ActiveSync, the time can be set.
I, for example, never synchronise more than one month to my smartphone.I hope I have been able to help you a little.
Best regards
Hello,
I am really very sorry for you, but how do you think that the few details you gave in your opening post could give you any help?
No one but you knows your system and the configuration involved.
From your opening post, all you really read is:
- mailcow with Docker
- Reverse Proxy Apache
- Ubuntu 18.04
If it was already running, what did you change?
Anyone running a server on the net should at least be able to provide meaningful data to narrow down their problem. Otherwise, I would say goodbye to your own server, because that could quickly backfire.
Best regards
Translated with www.DeepL.com/Translator (free version)
- Edited
Hallo zusammen,
erstmal vielen Dank für das relativ umfangreiche und doch geniale Produkt. Auch wenn ich persönlich eigentlich eine andere Virtualisierungslösung bevorzuge, komm ich mit Docker doch auch zurecht
Kurzer Umriss zur Situation:
In einer KVM läuft die Mailcow mit drei Domains zum testen. Eine Umstellung des Hostnamens und diverse Tests (DKIM, SPF usw) hat die Kuh auch schon bestanden.Jetzt kam ich auf die Idee doch das UI etwas zu anzupassen und das hat soweit auch ganz gut geklappt, bis ich meinte der Footer könne etwas HTML vertragen.
Leider hat er das JavaScript zwar bei der Eingabe akzeptiert, aber seit dem komme ich auch nicht mehr auf das Webinterface
Deshalb die Frage:
Gibt es eine Datei / einen Datenbankeintrag in der genau das, was ich dort in das Feld Footer unter #customize eingetragen habe, steht damit ich dies löschen kann?
Ich würde ungern die Kuh nochmal neu aufsetzen, wenn ich das vermeiden kann.Vielen Dank schon mal vorab für die Hilfe.
Beste GrüßeMarkus