Beiträge von nitram70

Auf ein neues!

Ich stelle fest, dass 90% aller "ausporobierenden" Logins aus immer jeweils einem /24 Subnetz erfolgen, die IPs rotieren über bis zu 10 Adressen. Das Netz zu blocken ist dann eher eine leichte Übung, einfach /24 dahinter und gut.

Aber wie könnte man realisieren, dass diese überhaupt als zusammenhängend erkannt und zu einem "Angriff" gebündelt von fail2ban gezählt werden?

Hallo,

Kunde beschwert sich, dass er keine Mails mit 30MB Anhang versenden kann. Ich versuche es parallel ihm abzugewöhnen aber prinzipiell würde mich interessieren, ob es hier ein Limit gibt und wenn ja, wie kann man es verstellen?

Die Erzeugung des 2048 Bit Schlüssels hat bei mir gute 15 Minuten gedauert.

Wie lange dauert dann der 4096 Bit Schlüssel und muss der jede Nacht neu erstellt werden?

Das hat geholfen, vielen Dank!

Ja, offenbar haben meine Installationen eine alte Version des Scripts, die letzten 4 Zeilen sehen so aus (die 2048 ist meine Änderung):

openssl dhparam -2 -out /var/qmail/control/dh1024.new 2048 &&
chmod 600 /var/qmail/control/dh1024.new &&
chown qmaild:qmail /var/qmail/control/dh1024.new &&
mv -f /var/qmail/control/dh1024.new /var/qmail/control/dh1024.pem

Die Frage ist, wie wäre ich an das neue gekommen, ausser über manuellen Download?

Soweit ich weiss, ändert die PD-Admin Updateroutine nichts an den qmail Ordnern.

Ich habe die Vermutung, dass es an den Ciphers liegt.
Der raru verwendet Cipher in use: TLS_AES_256_GCM_SHA384
Der bfnet verwendet Cipher in use: DHE-RSA-AES256-GCM-SHA384
RSA ist wohl nicht mehr zu empfehlen.

Gabs hier eine Lösung? Ich hab dasselbe Problem, allerdings beim Versuch an meine beiden PD-Admin Server Mails zuzustellen:

Feb 21 09:22:30 raru sendmail[10652]: 01L8MUXm010652: from=root, size=215, class=0, nrcpts=1, msgid=<202002210822.01L8MUXm010652@raru.bpaserver.net>, relay=root@localhost
Feb 21 09:22:30 raru sendmail[10652]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Feb 21 09:22:30 raru sendmail[10653]: STARTTLS=server, relay=localhost.localdomain [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Feb 21 09:22:30 raru sendmail[10653]: 01L8MU6L010653: from=<root@raru.bpaserver.net>, size=467, class=0, nrcpts=1, msgid=<202002210822.01L8MUXm010652@raru.bpaserver.net>, proto=ESMTPS, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Feb 21 09:22:30 raru sendmail[10652]: 01L8MUXm010652: to=martin@wohnbusse.eu, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30215, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (01L8MU6L010653 Message accepted for delivery)
Feb 21 09:22:30 raru sendmail[10655]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1
Feb 21 09:22:30 raru sendmail[10655]: ruleset=tls_server, arg1=SOFTWARE, relay=wohnbusse.eu, reject=403 4.7.0 TLS handshake failed.
Feb 21 09:22:30 raru sendmail[10655]: 01L8MU6L010653: to=<martin@wohnbusse.eu>, ctladdr=<root@raru.bpaserver.net> (0/0), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=120467, relay=wohnbusse.eu. [89.238.66.137], dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed.
Feb 21 09:23:25 raru dovecot[2152]: pop3-login: Aborted login (no auth attempts in 0 secs): user=<>, rip=149.13.77.123, lip=149.13.77.72, session=<lnJAvBGfpJOVDU17>

Sowohl PD-Admin als auch Debian auf den beiden Maschinen ist leider ziemlich veraltet.

Gruß,

Martin

Zitat von monderka

Zusätzlich muss noch simcontrol angepasst werden

Das hatte ich gelesen, aber nicht, dass es zwingend erforderlich ist. Was muss bei "domain.com" eingesetzt werden?

Ich hoffe nicht, dass je ein Eintrag für alle Domains die auf dem Server liegen und Mails empfangen sollen, nötig ist.

Ich habe mich heute mal daran versucht, weil Spam von der TLD .icu massiv zugenommen haben.
Dazu habe ich die Datei /usr/local/pd-admin2/etc/mail/spamassassin/blacklist.cf erstellt und zwei Beispieleinträge erzeugt:

blacklist_from *@*.*.icu
blacklist_from *@*.icu

Mittels /usr/local/pd-admin2/bin/spamassassin -D --lint sieht man, dass die Datei eingelesen wird.

Dann spamd durchgestartet und per telnet von einem anderen Server eine Testnachricht geschickt. Das erzeugt im Logfile leider nur Einträge mit dem Merkmal Message tagged as spam by SpamAssassin und Spam mail safed to quarantine maildir.

Was hab ich da wohl falsch gemacht?

Danke, das hats gebracht. Was man wissen muss ist, dass man dann den action Befehl etwas anpassen muss.

Folgende zwei Zeilen, vorher und nachher.

action = iptables[name=smtpSd-Banned, port=587, protocol=tcp]
action = iptables-multiport[name=smtpSd-Banned, port="25,465,587", protocol=tcp]

Vielen Dank!

Guten morgen,

ich bastele mal wieder mit fail2ban und versuche, "ungültige" smtp Loginversuche zu unterbinden.
Dazu habe ich eine Regel aus dem ersten Beitrag dieses Threads angepasst:

pdqmail-smtp.conf

failregex = User [a-zA-Z0-9@._-]+: smtp-auth login failed from <HOST> \(no such user\)
            User [a-zA-Z0-9@._-]+: smtp-auth login failed from <HOST> \(wrong password: \w.+, \w.+\)$
            User [a-zA-Z0-9@._-]+: login failure from <HOST>$

jail.conf

[pdqmail-smtpSd]
enabled = true
port    = 587 
filter  = pdqmail-smtp
action  = iptables[name=smtpSd-Banned, port=587, protocol=tcp]
logpath = /var/log/syslog
findtime  = 600 
maxretry = 3 
bantime = 10800

Das funktioniert soweit prima, die IPs werden geblockt. Die Loginversuche hören aber nicht auf, im Logfile häufen sich die Einträge in der Art:

WARNING [pdqmail-smtpSd] 45.13.39.53 already banned

iptables Ausgabe für die oben genannte IP:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-smtpSd-Banned  tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:587

Chain fail2ban-smtpSd-Banned (1 references)
target     prot opt source               destination         
DROP       all  --  45.13.39.53          0.0.0.0/0 

Was hab ich da falsch gemacht? Stimmen "port" und "protocol"?

Ich hab nichts anderes behauptet.

Ich weiss nur nicht ob der Parameter so korrekt gesetzt ist...

Moin zusammen,

ich hinke mit dem SE Update ein wenig hinterher, installiert ist 3-0.312, aktuell ist 333.

Betriebssystem ist (leider noch) Debian Wheezy. Auch da muss ich dran aber eins nach dem anderen.

Mit dem Update möchte ich zunächst auf mysql 5.5 aktualisieren. Der Grund sind ein paar sehr etablierte aber auch sehr alte Webforen, die noch auf WBB 3.1 laufen, die können maximal mit mysql 5.5 und die neuste Version kann nicht mit mysql 5.1

Wie aktualisiere ich mysql? Ist ./se-update.sh -s 4 richtig?

Weiss jemand von Problemen mit dem WBB und mysql 5.5?
Ansonsten laufen auf dem Rechner nur Wordpress Seiten.

Viele Grüße,

Martin

Ich hab das Zertifikat von einer Webseite herunter geladen, per FTP wieder hoch (für das Shellscript) und dann verarbeiten lassen.

Vermutlich ist da irgendwo was schief gelaufen, meinem FTP Client CyberDuck hab ich evtl. vergessen auf ASCII zu stellen...

Ich hab das Problem gefunden, der Server hat TLS Verbindungen abgelehnt weil das Zertifikat nicht gefunden wurde und somit hat Gmail sich geweigert, sich zu verbinden.

Beim Blick in die Datei /var/qmail/control/servercert.pem hat sich gezeigt, dass zwischen dem Cert und dem Cacert ein Umbruch fehlte, so das

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

in einer Zeile stand. Das hat qmail-smtpd gereicht, das Zertifikat als ungültig anzusehen.
Nun gehts wieder, ein Test-Telnet auf Port 25 bestätigt TLS, was es vorher nicht tat, und die erste GMail Mail kam gerade schon rein.

Was bleibt ist die Frage, warum der Umbruch fehlte. Ich habe es mit dem dc-ssl-install.sh Shellscript nicht reproduziert bekommen, selbst wenn ich in der Zertifikatdatei direkt nach dem Trenner alles lösche.

Vielen Dank für eure Hilfe, Sumeragi und Michael!

Viele Grüße,

Martin

So ein Zertifikat hab ich, darüber läuft ja alles was unterhalb des servernamens aufzurufen ist, roundcube, phpMyAdmin und natürlich pdadmin.

Wenn ich das installiere drehen aber alle Kunden-Outlooks ab und ich hänge für den Rest des Tages am Telefon.

Ich glaube ich muss nochmal in den Mail Logs recherchieren, wann die letzte Gmail Mail rein gekommen ist.
iptables ist nun erstmal leer, ganz nebenbei steigt direkt mächtig die Serverlast an. Die Sperrliste war aber auch echt lang...

Danke.

Iich werde mal fail2ban für ein paar Stunden abschalten. Was anderes fällt mir gerade nicht ein...

zB. auch bf-net.de

schepers@bf-net.de landet direkt bei mir.

hostname: bfnet.bpaserver.net

MX und somit auch email-ssl-hostname: mail.bf-net.de

Achja, da läuft noch Wheezy, das sollte Google aber eigentlich nicht interessieren.

Es ist tatsächlich so, dass ich in den Logs überhaupt nichts sehe. Allerdings muss ich mit der IPv6 Sache zurückrudern, das war ein anderer Server, da hab ich was durcheinander gebracht. Der betroffene Server hat kein IPv6, der MX Hostname ist ein A Record und verweist auf die Server-IP.

Allerdings ist der Hostname des Servers (vom Provider vergeben) ein anderer als der eMail-SSL-Hostname, den wir an die Kunden rausgeben,

Der Server meldet sich mit seinem Hostnamen im SMTP Dialog.
Auch das lief aber vorher schon viele Monate problemlos.

Macht es Sinn hier mal ein paar records zu posten oder andere Zusammenhänge darzustellen?

Danke für deine Antwort,

Zitat von Sumeragi

Ansonsten muss man sich einmal die Mail genauer anschauen, die von Google abgelehnt wird.

es ist ja so dass keine Mails von Gmail HEREIN kommen. Dabei haben verschiedene Absender an verschiedene Empfänger auf demselben Server dieselben Probleme. Es ist also kein domainbezogenes Problem

Mailausgang von dem betroffenen Server AN Gmail klappt problemlos.

Viele Grüße,

Martin