ubuntuusers.de

hallo,

ich habe nen Strato Vserver, auf dem u.a. Roundcube und dovecot läuft. Immer öfter bekomme ich die Fehlermeldung "Verbindung zum Speicherserver fehlgeschlagen", wenn ich mich mit Webmail anmelden will. Immerhin kommt ne Fehlermeldung, bei Thunderbird kommt nur "passwort falsch" 😉

Ausgaben an der Console bei netstat -tnlp | grep dovecot ergibt:

 netstat -tnlp | grep dovecot
tcp        0      0 0.0.0.0:4190            0.0.0.0:*               LISTEN      24607/dovecot
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      24607/dovecot
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN      24607/dovecot
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      24607/dovecot
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      24607/dovecot
tcp6       0      0 :::4190                 :::*                    LISTEN      24607/dovecot
tcp6       0      0 :::993                  :::*                    LISTEN      24607/dovecot
tcp6       0      0 :::995                  :::*                    LISTEN      24607/dovecot
tcp6       0      0 :::110                  :::*                    LISTEN      24607/dovecot
tcp6       0      0 :::143                  :::*                    LISTEN      24607/dovecot

scheint also o.k. zu sein

netstat -tnlp | grep :143 ergibt:

tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      24607/dovecot
tcp6       0      0 :::143                  :::*                    LISTEN      24607/dovecot

Im mail.err allerdings steht:

Mar  8 05:34:55 h2728344 dovecot: imap-login: Error: fd_send(imap, 8) failed: Broken pipe
Mar  8 05:37:01 h2728344 /usr/lib/plesk-9.0/psa-pc-remote[24656]: Message aborted.

im mail.log steht:

Mar  8 05:37:30 h2728344 dovecot: imap-login: Disconnected: Too many invalid commands (no auth attempts in 14 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, session=<wnzPO99mbs9/AAAB>
Mar  8 05:38:21 h2728344 postfix/smtpd[9856]: connect from unknown[51.254.246.42]
Mar  8 05:38:21 h2728344 plesk_saslauthd[9864]: listen=6, status=5, dbpath='/plesk/passwd.db', keypath='/plesk/passwd_db_key', chroot=1, unprivileged=1
Mar  8 05:38:21 h2728344 plesk_saslauthd[9864]: privileges set to (108:114) (effective 108:114)
Mar  8 05:38:21 h2728344 plesk_saslauthd[9864]: No such user 'MEI@stratoserver.net' in mail authorization database
Mar  8 05:38:21 h2728344 plesk_saslauthd[9864]: failed mail authenticatication attempt for user 'MEI@stratoserver.net' (password len=4)
Mar  8 05:38:21 h2728344 postfix/smtpd[9856]: warning: unknown[51.254.246.42]: SASL LOGIN authentication failed: authentication failure

Kann es sein, dass irgendjemand versucht, ein Passwort für eine nicht existierende Mail zu hacken und dovecot dann irgendwann die Versuche unterbricht und deshalb der Fehler kommt ??

Danke fürs lesen 😉

gruss miller aus khaolak

Hallo,

ich habe jetzt für etliche Pakete ein Update via Plesk gemacht, der Fehler scheint jezt weg zu sein.

Ich scheute mich, die Updates einzuspielen, da ich bei einem früheren Update ein Problem mit PHP hatte und der Vermieter des Servers nur mit den Schultern gezuckt hat:

"Das ist leider Ihr Problem, da Software"

Deshalb bin ich nach dem Spruch 'Never touch a running System' vorgegangen.

Nun musste es aber sein und es hat sich gelohnt 😉

gruss

miller

Leider ist es heute wieder aufgetreten, trotz Update ☹

Hat ev. jemand ne Idee ??

Das Problem scheint im dovecot zu liegen:

Mar 12 08:03:16 h2728344 dovecot: master: Warning: service(imap): process_limit (15) reached, client connections are being dropped
Mar 12 08:03:16 h2728344 dovecot: imap-login: Error: fd_send(imap, 19) failed: Broken pipe

Anscheinend versuchen zu viele User, einen Login zu bewerkstelligen. Da ich der einzige User bin, sind es Leute, die versuchen einen Mailaccount von mir zu hacken. Zum Glück bisher vergeblich.

Ich habe folgendes in der conf Datei von dovecot geändert:

service imap-login {
service_count = 1
process_limit = 100
}

Ich hoffe, der Fehler (der ja eigentlich keiner ist) ist nun weg.

Ob es sinnvoll ist (theoretisch können jetzt mehr gleichzeitig versuchen, sich in meine Mailadressen einzuloggen), kann ich nicht beurteilen.

Gibt es eine Möglichkeit, einzelne IP Adressen zu sperren ??

gruss miller

millerkhaolak schrieb:

Gibt es eine Möglichkeit, einzelne IP Adressen zu sperren ??

Meinst Du mit dovecot oder mit iptables? Von wo (... evtl. immer die gleiche IP-Adresse?) bzw. mit welchem Betriebssystem greifst Du auf den Server zu?

hi lubux 😉

ich habe im mail.log unterschiedliche ip-adresse drin, die jeweils mehrere Login Versuche mit unterschiedlichen Passwort-Längen unternehmen. Also vermutlich bruteforce oder wörterbuch versuche.

Ich habe jetzt dagegen Fail2Ban unter Plesk installiert, das soll wohl solche Fehlversuche erkennen und nach dreimaligem falschen eingeben vom PW diese IP für 10 Minuten sperren.

Mal sehen, wie sich das auswirkt 😉

Danke, dass Du Dich mir 'armen Linux-Würstchen' angenommen hast 😉

lg (z.Zt. aus BKK) miller

p.s.: Die Vortäuschung meines geografischen Standortes mit Openvpn ist zwar einfacher zu aktivieren (habe mir zwar ein Prog geschrieben, welches in die Registry den Proxy einträgt, aber trotzdem umständlicher), aber langsamer als mit meinem Squid Proxy. Habe sogar Speed Optimierungen vorgenommen, das VPN kann aber Squid nicht toppen ☹

millerkhaolak schrieb:

Ich habe jetzt dagegen Fail2Ban ...

Mal sehen, wie sich das auswirkt 😉

Für (meine) Server auf die nur ich zugreife, wende (zusätzlich) ich einen "Trick" (... hat weniger Einträge in den log-Dateien zur Folge) an, der gegen solche TCP-login-Versuche "hilft". Das geht aber nur mit Clients, auf denen man das ecn-Bit setzen kann. Wenn der Zugriff (aus dem Internet) von einem Client/IP-Adresse ohne gesetztes ecn-Bit kommt, ist keine Verbindung zum lauschenden Port (oder Ports) des Servers möglich. Z. B.:

iptables -I INPUT 1 -i <Input-Interface> -p tcp --tcp-flags SYN SYN -m multiport --dports 0:20000 -m ecn ! --ecn-tcp-cwr -m state --state INVALID,NEW -j DROP

Es sind ganz wenige "Angreifer", die für den Zugang (1. Verbindung mit dem syn-Flag) das ecn-Bit gesetzt haben. Diese Versuche (mit gesetztem) ecn-Bit, kann man z. B. mit tcpdump sniffen:

tcpdump -vvveni <Input-Interface> 'tcp[13] & 0xc0 != 0' and 'tcp[tcpflags] & (tcp-syn) != 0'

Testen kannst Du die iptables-Regel bzw. das sniffen mit tcpdump, mit z. B. nping (oder gleichwertig):

- mit ecn-Bit:

nping -c 3 --tcp --flags syn,ecn,cwr --delay 1s -g 3456 -p <lauschender-Port> <IP-Adresse>

-ohne ecn-Bit:

nping -c 3 --tcp --flags syn --delay 1s -g 3456 -p <lauschender-Port> <IP-Adresse>

Im geeigneten System (Server, Client) kann man das ecn-Bit, mit (hier für Linux):

net.ipv4.tcp_ecn = 1

setzen.

Das ECN Bit kann ich auf einem Windows System nicht setzen..zumindest nicht mit "net.ipv4.tcp_ecn = 1" , kennt Windows nicht. Ich habe nur Windows Clients 😉 (außer meinem Android Phone)

Ich habe aber festgestellt, dass diese eine IP Adresse, die sehr,sehr oft im Log auftaucht, einen Squid Proxy auf Port 80 zu laufen hat. Wenn ich diese IP Adresse mit iptables sperren würde, dann müssten doch diese Versuche wegfallen, oder ?

Ich bin mir unsicher, ob Fail2Ban das richtige ist. Habe mittels Webmail 3 mal ein PW absichtlich falsch eingegeben, bekomme dann beim 4. mal zwar die Meldung "Zu viele Versuche", aber eine Sperrung der IP Adresse taucht im Logfile von Fail2Ban nicht auf 😢

millerkhaolak schrieb:

Das ECN Bit kann ich auf einem Windows System nicht setzen..

Schade, ... dass es noch OS's gibt, bei denen man das ecn-Bit nicht setzen kann.

'https://tools.ietf.org/html/rfc3168#section-6.1.1.1'

Ich habe aber festgestellt, dass diese eine IP Adresse, die sehr,sehr oft im Log auftaucht, einen Squid Proxy auf Port 80 zu laufen hat. Wenn ich diese IP Adresse mit iptables sperren würde, dann müssten doch diese Versuche wegfallen, oder ?

Ja, ... kannst ja mal schauen mit welchen Flags der 1. Verbindungsversuch von dieser IP-Adresse statt findet:

tcpdump -c 20 -vvveni <Input-Interface> host <IP-Adresse>

Ich würde sagen: flags DF *grins was immer das bedeutet *ohje

tcpdump -c 20 -vvveni venet0 host 46.148.27.6
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:34:28.675017  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 26643, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.65276 > 81.169.156.XXX.XXX: Flags [F.], cksum 0xa9df (correct), seq 2829218827, ack 1566790585, win 255, length 0
11:34:28.675299 Out ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 4972, offset 0, flags [DF], proto TCP (6), length 40)
    81.169.156.XXX.XXX > 46.148.27.6.65276: Flags [F.], cksum 0xaa6a (correct), seq 1, ack 1, win 115, length 0
11:34:28.694138  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 26660, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.65276 > 81.169.156.XXX.XXX: Flags [.], cksum 0xa9de (correct), seq 1, ack 2, win 255, length 0
11:37:17.925659  In ethertype IPv4 (0x0800), length 68: (tos 0x2,ECT(0), ttl 120, id 10241, offset 0, flags [DF], proto TCP (6), length 52)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [SEW], cksum 0x72b4 (correct), seq 4177715258, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:37:17.925722 Out ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [S.E], cksum 0xee82 (correct), seq 1624902335, ack 4177715259, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
11:37:17.944271  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 10253, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [.], cksum 0x679d (correct), seq 1, ack 1, win 256, length 0
11:37:17.946312 Out ethertype IPv4 (0x0800), length 110: (tos 0x2,ECT(0), ttl 64, id 2867, offset 0, flags [DF], proto TCP (6), length 94)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [P.], cksum 0x3865 (incorrect -> 0x54cc), seq 1:55, ack 1, win 115, length 54: SMTP, length: 54
        220 h2728344.stratoserver.net ESMTP Postfix (Ubuntu)
11:37:18.017683  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 10286, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [.], cksum 0x6767 (correct), seq 1, ack 55, win 256, length 0
11:37:18.312645  In ethertype IPv4 (0x0800), length 85: (tos 0x2,ECT(0), ttl 120, id 10397, offset 0, flags [DF], proto TCP (6), length 69)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [P.], cksum 0x457f (correct), seq 1:30, ack 55, win 256, length 29: SMTP, length: 29
        EHLO win-e73f2aa0c2n.domain
11:37:18.312673 Out ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 2868, offset 0, flags [DF], proto TCP (6), length 40)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [.], cksum 0x67d7 (correct), seq 55, ack 30, win 115, length 0
11:37:18.312874 Out ethertype IPv4 (0x0800), length 237: (tos 0x2,ECT(0), ttl 64, id 2869, offset 0, flags [DF], proto TCP (6), length 221)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [P.], cksum 0x38e4 (incorrect -> 0xbd75), seq 55:236, ack 30, win 115, length 181: SMTP, length: 181
        250-h2728344.stratoserver.net
        250-PIPELINING
        250-SIZE 102400000
        250-ETRN
        250-STARTTLS
        250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
        250-ENHANCEDSTATUSCODES
        250-8BITMIME
        250 DSN
11:37:18.417793  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 10424, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [.], cksum 0x6696 (correct), seq 30, ack 236, win 255, length 0
11:37:19.976661  In ethertype IPv4 (0x0800), length 68: (tos 0x2,ECT(0), ttl 120, id 10503, offset 0, flags [DF], proto TCP (6), length 52)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [P.], cksum 0x0af9 (correct), seq 30:42, ack 236, win 255, length 12: SMTP, length: 12
        AUTH LOGIN
11:37:19.976772 Out ethertype IPv4 (0x0800), length 74: (tos 0x2,ECT(0), ttl 64, id 2870, offset 0, flags [DF], proto TCP (6), length 58)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [P.], cksum 0x3841 (incorrect -> 0xfd76), seq 236:254, ack 42, win 115, length 18: SMTP, length: 18
        334 VXNlcm5hbWU6
11:37:20.205986  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 10665, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [.], cksum 0x6678 (correct), seq 42, ack 254, win 255, length 0
11:37:21.188991  In ethertype IPv4 (0x0800), length 66: (tos 0x2,ECT(0), ttl 120, id 10880, offset 0, flags [DF], proto TCP (6), length 50)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [P.], cksum 0xf1f4 (correct), seq 42:52, ack 254, win 255, length 10: SMTP, length: 10
        cGUtYnU=
11:37:21.189087 Out ethertype IPv4 (0x0800), length 74: (tos 0x2,ECT(0), ttl 64, id 2871, offset 0, flags [DF], proto TCP (6), length 58)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [P.], cksum 0x3841 (incorrect -> 0xda73), seq 254:272, ack 52, win 115, length 18: SMTP, length: 18
        334 UGFzc3dvcmQ6
11:37:21.208668  In ethertype IPv4 (0x0800), length 70: (tos 0x2,ECT(0), ttl 120, id 10947, offset 0, flags [DF], proto TCP (6), length 54)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [P.], cksum 0x5e04 (correct), seq 52:66, ack 272, win 255, length 14: SMTP, length: 14
        aW5mbzIwMDk=
11:37:21.218212 Out ethertype IPv4 (0x0800), length 120: (tos 0x2,ECT(0), ttl 64, id 2872, offset 0, flags [DF], proto TCP (6), length 104)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [P.], cksum 0x386f (incorrect -> 0x4a99), seq 272:336, ack 66, win 115, length 64: SMTP, length: 64
        535 5.7.8 Error: authentication failed: authentication failure
11:37:21.314499  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 120, id 10969, offset 0, flags [DF], proto TCP (6), length 40)
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [.], cksum 0x660e (correct), seq 66, ack 336, win 255, length 0
20 packets captured
20 packets received by filter
0 packets dropped by kernel

millerkhaolak schrieb:

tcpdump -c 20 -vvveni venet0 host 46.148.27.6
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
    46.148.27.6.51760 > 81.169.156.XXX.XXX: Flags [SEW], cksum 0x72b4 (correct), seq 4177715258, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:37:17.925722 Out ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    81.169.156.XXX.XXX > 46.148.27.6.51760: Flags [S.E], cksum 0xee82 (correct), seq 1624902335, ack 4177715259, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

OK, dann versuch mal mit folgender iptables-Regel:

iptables -I INPUT 1 -i <Input-Interface> -p tcp -s 46.148.27.6 --tcp-flags SYN SYN -m state --state INVALID,NEW -j DROP

und weiter mit tcpdump sniffen.

EDIT:

Wenn Du mehrere source-IP-Adressen hast, die Du sperren willst, kannst Du auch ipset (mit iptables) benutzen:

apt-cache show ipset

Danke, mache ich...muss erstmal Futtern gehen, bevor es hier in BKK dunkel wird 😉

Melde mich dann (tcpdump muss ich beobachten).

millerkhaolak schrieb:

... (tcpdump muss ich beobachten).

Poste von deinem Server auch die Ausgaben von:

sysctl net.ipv4.tcp_ecn net.ipv4.tcp_ecn_fallback

EDIT:

Betr. ipset z. B.:

ipset create drop_list_1 hash:ip family inet
ipset add drop_list_1 <IP-Adresse>
iptables -I INPUT 1 -i <Input-Interface> -m set --match-set drop_list_1 src -j DROP
ipset list drop_list_1

Nach dem hinzufügen von neuen IP-Adressen muss die zuständige iptables-Regel gelöscht werden und neu gesetzt werden. Achtung betr. der Persistenz der iptables-Regeln.

also: Fail2Ban scheint zu funzen. Innerhalb meiner Essenspause wurden von Fail2Ban 17 mal IP Adressen jeweils für 10 Minuten gesperrt. Hat auch recidive erkannt, aber nicht oft genug, so dass keine IP ne Langzeitsperre bekam.

Ich habe mich für ipset entschieden, halte ich für mächtiger und für meine Zwecke besser passend. (ev. täusche ich mich ja auch)

Hab es mit apt get installiert. Beim anlegen einer Regel mit

sudo ipset create drop_list_1 hash:ip family inet

bekomme ich nen Fehler:

ipset v6.29: Cannot open session to kernel.

dabei ist es gleich, ob mit oder ohne sudo. Auch ein Reboot des Servers hat nicht geholfen.

Dass ipset irgendwie mit dem Kernel zusammen arbeitet, habe ich gelesen. Ev. läßt Strato Kernel Erweiterungen ja nicht zu *grübel

sysctl net.ipv4.tcp_ecn net.ipv4.tcp_ecn_fallback
net.ipv4.tcp_ecn = 2
sysctl: cannot stat /proc/sys/net/ipv4/tcp_ecn_fallback: No such file or directory

Das klappt auch nicht ☹

werde jetzt erstmal mit tcpdump beobachten...mal sehen, ob was kommt bezüglich dieser IP