Mailserver: Zugriffe auf China und nun hat mich google nicht mehr gern :(

Jump to last post
I

I-lk

Neu angemeldet
Registriert
1 Juli 2014
Beiträge
5
Hallo Allerseits

Hoffe bin hier richtig, hab mich auch überlegt es bei den Unixsystemen einzustellen, glaub aber hier passte besser. Sonst bitte verschieben, danke @mods :)

Ist übrigens ein Zweitaccount, da ich hier möglicherweise Realdaten zugänglich mache.

Ich hab seit einiger Zeit zu für Familienzwecke einen Mailserver (CentOS) mit
You do not have permission to view link please Anmelden or Registrieren
laufen. Soweit so gut. Eigener Mail, und Groupwareserver, prima Sache, volle Kontrolle über die Daten etc.

Nun hab ich seit einiger Zeit allerdings erschreckend viele "merkwürde" Zugriffsversuche von chinesischen IP Adressen. Hat mir eigentlich weniger sorgen gemacht, Passwörter sind sicher gewählt, etc.

Naja, so sieht das /var/log/secure die ganze Zeit aus:
[src=text]
Jul 1 16:37:25 kolab sshd[13684]: Invalid user cvsadmin from 221.208.245.226
Jul 1 16:37:25 kolab sshd[13685]: input_userauth_request: invalid user cvsadmin
Jul 1 16:37:25 kolab sshd[13684]: pam_unix(sshd:auth): check pass; user unknown
Jul 1 16:37:25 kolab sshd[13684]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.208.245.226
Jul 1 16:37:25 kolab sshd[13684]: pam_succeed_if(sshd:auth): error retrieving information about user cvsadmin
Jul 1 16:37:27 kolab sshd[13684]: Failed password for invalid user cvsadmin from 221.208.245.226 port 44160 ssh2
Jul 1 16:37:27 kolab sshd[13685]: Received disconnect from 221.208.245.226: 11: Bye Bye
Jul 1 16:37:30 kolab sshd[13686]: Invalid user yuji from 221.208.245.226
Jul 1 16:37:30 kolab sshd[13687]: input_userauth_request: invalid user yuji
Jul 1 16:37:30 kolab sshd[13686]: pam_unix(sshd:auth): check pass; user unknown
Jul 1 16:37:30 kolab sshd[13686]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.208.245.226
Jul 1 16:37:30 kolab sshd[13686]: pam_succeed_if(sshd:auth): error retrieving information about user yuji
Jul 1 16:37:31 kolab sshd[13686]: Failed password for invalid user yuji from 221.208.245.226 port 45300 ssh2
Jul 1 16:37:32 kolab sshd[13687]: Received disconnect from 221.208.245.226: 11: Bye Bye
Jul 1 16:37:34 kolab sshd[13688]: Invalid user periodic from 221.208.245.226
Jul 1 16:37:34 kolab sshd[13689]: input_userauth_request: invalid user periodic
Jul 1 16:37:34 kolab sshd[13688]: pam_unix(sshd:auth): check pass; user unknown
Jul 1 16:37:34 kolab sshd[13688]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.208.245.226
Jul 1 16:37:34 kolab sshd[13688]: pam_succeed_if(sshd:auth): error retrieving information about user periodic
Jul 1 16:37:36 kolab sshd[13688]: Failed password for invalid user periodic from 221.208.245.226 port 46489 ssh2
Jul 1 16:37:36 kolab sshd[13689]: Received disconnect from 221.208.245.226: 11: Bye Bye
Jul 1 16:37:38 kolab sshd[13695]: Invalid user tsumura from 221.208.245.226
Jul 1 16:37:38 kolab sshd[13696]: input_userauth_request: invalid user tsumura
Jul 1 16:37:38 kolab sshd[13695]: pam_unix(sshd:auth): check pass; user unknown
Jul 1 16:37:38 kolab sshd[13695]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.208.245.226
Jul 1 16:37:38 kolab sshd[13695]: pam_succeed_if(sshd:auth): error retrieving information about user tsumura
Jul 1 16:37:40 kolab sshd[13695]: Failed password for invalid user tsumura from 221.208.245.226 port 47409 ssh2
Jul 1 16:37:41 kolab sshd[13696]: Received disconnect from 221.208.245.226: 11: Bye Bye
Jul 1 16:37:46 kolab sshd[13697]: Invalid user plex from 221.208.245.226
Jul 1 16:37:46 kolab sshd[13698]: input_userauth_request: invalid user plex
Jul 1 16:37:46 kolab sshd[13697]: pam_unix(sshd:auth): check pass; user unknown
Jul 1 16:37:46 kolab sshd[13697]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.208.245.226
Jul 1 16:37:46 kolab sshd[13697]: pam_succeed_if(sshd:auth): error retrieving information about user plex
Jul 1 16:37:47 kolab sshd[13697]: Failed password for invalid user plex from 221.208.245.226 port 48391 ssh2
Jul 1 16:37:47 kolab sshd[13698]: Received disconnect from 221.208.245.226: 11: Bye Bye

[/src]


Naja, hatte dann am Freitag glaub kurz ein kleines Problem mit MySQL (lief irgendwie nicht mehr, reboot, /var/lib/mysql/mysql.sock verschoben, und konnte das Ding wieder starten).

Seit gestern nimmt jedoch google kein Mails mehr von mir entgegen, und das macht mir traurig. :(
Ich mag zwar google nicht trotzdem würd ich gerne an gmail Adressen Mails schreiben können.

Nur,
You do not have permission to view link please Anmelden or Registrieren
zeigt mir an das ich auf keiner Blacklist bin.

PTR ist gesetzt, seit gestern jetzt auch ein SPF in der DNS Zonefile.

Nach wie vor mag mich google nicht:

(von mir zensiert)
[src=text]<geheimeadresse@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]
said: 550-5.7.1 [2a01:4f8:d12:281::2 12] Our system has detected that
this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of
spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit
550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131
for 550 5.7.1 more information. r8si12283553wix.70 - gsmtp (in reply to end
of DATA command)
Reporting-MTA: dns; kolab.meinedomain.com
X-Postfix-Queue-ID: F1D5B43638E
X-Postfix-Sender: rfc822; main.name@meinedomain.com
Arrival-Date: Tue, 1 Jul 2014 00:18:23 +0200 (CEST)

Final-Recipient: rfc822; geheimeadresse@gmail.com
Original-Recipient: rfc822;geheimeadresse@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [2a01:4f8:d12:281::2 12] Our system has
detected that this 550-5.7.1 message is likely unsolicited mail. To reduce
the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked.
Please visit 550-5.7.1
http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550
5.7.1 more information. r8si12283553wix.70 - gsmtp[/src]


Kann es sein das mein Server doch als Spamschleuder missbraucht wird? In den logfiles find ich nichts was darauf hindeutet, aber was ist da die beste Lösung da sicher zu gehen? Müsst ich dann nicht auch auf den Blacklists auftauchen?

Und, falls dem nicht so ist, wie krieg ich google dazu mich wieder gern zu haben? Bzw. wie finde ich raus was ich getan hab?

Kann hier auch gerne domain und IP posten, oder glaubt jemand da spräche was dagegen?

Vielen Dank!

Mfg

I-lk
 
Kannst ja mal Deinen Rechner prüfen:

You do not have permission to view link please Anmelden or Registrieren


Mit finger kannst du sehen, wer eingeloggt ist.

Von Mail-Servern hab ich keine Ahnung, hab bei mir nicht mal sendmail & Co. installiert. Aber sollte es da nicht auch ein Logfile geben, wann welche Mail abgeschickt wurde?

Zu den Einbruchsversuchen per SSH:
Das ist normal. Ich hatte bei mir auch den SSH-Port auf meinen Rechner durch die Fritzbox durchgeschleift. Hat man das Logfile mit tail laufen lassen, sah das manchmal aus wie bei der Matrix. Da scannen irgendwelche Rechner einfach das Internet ab. Und wenn sie einen offenen Port 22 finden, dann wird das Wörterbuch drauf losgelassen.

Zuerst hatte ich dagegen
You do not have permission to view link please Anmelden or Registrieren
im Einsatz. Fail2Ban macht übrigens das Gleiche. Aber als ich dann aufgrund des Umstiegs auf Systemd Syslog runtergeschmissen hab, funktionierten die Ban-Skripte nicht mehr. Mittlerweile hab ich den SSH-Port von außen einfach geändert. D.h. in der Fritzbox lass ich Port 222 (extern) auf 22 (intern) forwarden. Seitdem ist Ruhe im Karton. Soviel Arbeit machen sich die Angreifer dann doch nicht.

Ebenfalls sinnvoll ist, in der sshd_conf mit AllowUsers explizit anzugeben, welcher User sich überhaupt mit ssh einloggen darf.
 
Schau mal, was mxtoolbox zu deinem Mailserver sagt.
Außerdem könntest du eine Testmail an den Mail-tester senden.

Beide Tools sind hier verlinkt: Online Tools ...
 
  • Thread Starter Thread Starter
  • #4
@musv
Danke, werd mir das chrootkit mal anschauen. Danke!

@accC
mxtoolbox hab ich schon mal drüberlaufen lassen. Alles grün und `OK`. Keine blacklist, nix.

Auch der Mail-tester gibt mir 9/10 Punkten.
Der einzige Abzug:
Ihre Nachricht ist nicht durch DKIM signiert

Werd mir das mal anschauen und nachholen. Danke für die Links!
Kann aber doch nicht sein das google nur deswegen alle Mails von mir ablehnt?

MfG

I-lk
 
Also wäre dein Server grob fehlerhaft konfiguriert, dann wäre es durchaus möglich, dass google Mails von deinem Server ignoriert.
Da das aber scheinbar nicht der Fall ist, musst du weiter schauen, wo das Problem liegen könnte.

Werden die Mails prinzipiell nicht angenommen vom Mailserver oder nimmt dieser die Mails zwar an, klassifiziert sie dann allerdings als Spam?
Bist du sicher, dass die Postfächer, die du erreichen möchtest, wirklich existieren? Etwa existiert@gmail.com und nicht etwa diese-adresse-existiert-nicht@gmail.com?

Was steht denn in den Logeinträgen deines Mailservers?
 
  • Thread Starter Thread Starter
  • #6
Ja, also google hat ja auch eben schon Monatelang E-Mails von mir angenommen!

Und ja, die Zieladressen existieren wirklich. Ist auch scheinbar bei allen google E-Mails das gleiche.
Sonst kann ich über die Zieladresse auch Mails empfangen.

Scheinbar lehnt google schon prinzipiell alles was von meinem SMTP Server kommt direkt ab. Entsprechend schickt mir mein SMTP Server direkt nachdem ich die Mail abgeschickt hab ne Fehlermeldung:

[src=text]This is the mail system at host kolab.*meinedomain*.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<*meinegoogleadresse*@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]
said: 550-5.7.1 [2a01:4f8:d12:281::2 12] Our system has detected that
this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of
spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit
550-5.7.1
You do not have permission to view link please Anmelden or Registrieren

for 550 5.7.1 more information. hk10si33400379wjb.147 - gsmtp (in reply to
end of DATA command)
Reporting-MTA: dns; kolab.*meinedomain*
X-Postfix-Queue-ID: 274924363A1
X-Postfix-Sender: rfc822; *meinname*@*meinedomain*
Arrival-Date: Thu, 3 Jul 2014 00:30:47 +0200 (CEST)

Final-Recipient: rfc822; *meinegoogleadresse*@gmail.com
Original-Recipient: rfc822;*meinegoogleadresse*@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [2a01:4f8:d12:281::2 12] Our system has
detected that this 550-5.7.1 message is likely unsolicited mail. To reduce
the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked.
Please visit 550-5.7.1
You do not have permission to view link please Anmelden or Registrieren
for 550
5.7.1 more information. hk10si33400379wjb.147 - gsmtp

Von: *MeinMailName* <*meinname*@*meinedomain*>
Betreff: Hallo *meinegoogleadresse*
Datum: 3. Juli 2014 00:30:48 MESZ
An: zeponta@gmail.com


noch mal eine mail zum testen![/src]

Und hier das serverlog:
[src=text]Jul 3 00:30:44 kolab postfix/submission/smtpd[28287]: connect from *ip.mein.internetprovider.com[*xx.xx.xx.xx*]
Jul 3 00:30:45 kolab postfix/submission/smtpd[28287]: D1D0143638F: client=*ip.mein.internetprovider.com[*xx.xx.xx.xx*], sasl_method=PLAIN, sasl_username=*meinname*
Jul 3 00:30:46 kolab postfix/cleanup[28346]: D1D0143638F: message-id=<0BD529C2-4651-4D83-8B89-F8022BA845F3@*meinedomain.com*>
Jul 3 00:30:46 kolab postfix/qmgr[1489]: D1D0143638F: from=<*meinname*@*meinedomain.com*>, size=398, nrcpt=1 (queue active)
Jul 3 00:30:47 kolab postfix/smtpd[28350]: connect from localhost[127.0.0.1]
Jul 3 00:30:47 kolab postfix/smtpd[28350]: 274924363A1: client=*ip.mein.internetprovider.com[*xx.xx.xx.xx*]
Jul 3 00:30:47 kolab postfix/cleanup[28351]: 274924363A1: message-id=<0BD529C2-4651-4D83-8B89-F8022BA845F3@*meinedomain.com*>
Jul 3 00:30:47 kolab postfix/qmgr[1489]: 274924363A1: from=<*meinname*@*meinedomain.com*>, size=443, nrcpt=1 (queue active)
Jul 3 00:30:47 kolab postfix/smtpd[28350]: disconnect from localhost[127.0.0.1]
Jul 3 00:30:47 kolab amavis[24053]: (24053-16) Passed CLEAN {RelayedOpenRelay}, [80.219.158.251]:32788 <*meinname*@*meinedomain.com*> -> <*zieladresse*@gmail.com>, Message-ID: <0BD529C2-4651-4D83-8B89-F8022BA845F3@*meinedomain.com*>, mail_id: LevGOV1mwlGC, Hits: -1.902, size: 398, queued_as: 274924363A1, 1051 ms
Jul 3 00:30:47 kolab postfix/smtp[28347]: D1D0143638F: to=<*zieladresse*@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.6, delays=0.52/0.01/0/1, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 274924363A1)
Jul 3 00:30:47 kolab postfix/qmgr[1489]: D1D0143638F: removed
Jul 3 00:30:47 kolab postfix/smtp[28352]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Jul 3 00:30:48 kolab postfix/smtp[28352]: 274924363A1: to=<*zieladresse*@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]:25, delay=1, delays=0.01/0.02/0.19/0.79, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b] said: 550-5.7.1 [2a01:4f8:d12:281::2 12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1
You do not have permission to view link please Anmelden or Registrieren
for 550 5.7.1 more information. hk10si33400379wjb.147 - gsmtp (in reply to end of DATA command))
Jul 3 00:30:48 kolab postfix/cleanup[28355]: 2C0324363A2: message-id=<20140702223048.2C0324363A2@kolab.*meinedomain.com*>
Jul 3 00:30:48 kolab postfix/qmgr[1489]: 2C0324363A2: from=<>, size=3270, nrcpt=1 (queue active)
Jul 3 00:30:48 kolab postfix/bounce[28353]: 274924363A1: sender non-delivery notification: 2C0324363A2
Jul 3 00:30:48 kolab postfix/qmgr[1489]: 274924363A1: removed
Jul 3 00:30:48 kolab lmtpunix[28217]: ptload(): bad response from ptloader server: identifier not found
Jul 3 00:30:48 kolab lmtpunix[28217]: ptload failed for lukas^kohler@*meinedomain.com*
Jul 3 00:30:48 kolab lmtpunix[28217]: Delivered: <20140702223048.2C0324363A2@kolab.*meinedomain.com*> to mailbox: *meinedomain.com*!user.lukas^kohler
[/src]


apple (iCloud) nimmt auch z.B. mails problemlos an!
 
Google wird sicherlich nicht die Serveradministration für den TS übernehmen.

Kann es sein, dass irgendetwas mit deinen Zertifikaten nicht stimmt?
Verwendest du ein selbst signiertes Zertifikat? Ist es auf die korrekte Domain ausgeschrieben? Ist es (noch) gültig? Hast du nur ein Snakeoil-Zertifikat erstellt? Hast du deine eigene CA erstellt?
 
  • Thread Starter Thread Starter
  • #9
Hm, das könnte es sein.
Ist alles via Kolab Setup erstellt. Dachte auch eig. brauchts die Zertifikate ja auch nur für die TLS Verbindung zwischen den Clients und dem Server, nicht zwischen den Servern?

Was wäre denn da die Empfehlung? Reicht eine eigene CA? Zumindest das HTTPS Zertifikat ist definitiv noch nicht abgelaufen.

Kennst du da vlt. gute Lektüre?

Danke auf jeden Fall schonmal!
 
Das kommt darauf an, ob dein Server die Mails auch verschlüsselt versendet. Wenn nur die Verbindung zwischen Client und deinem Server verschlüsselt ist, dann ist das mit den Zertifikaten weniger problematisch, da du sie ja "manuell akzeptieren" kannst. Wenn dein Server (MTA) Mails dann aber über eine verschlüsselte (SMTP) Leitung zu einem anderen Server transportieren möchte, dann müssen die Zertifikate zumindest bis zu einem gewissen Punkt gültig sein, sonst werden sie vom Drittserver eben nicht akzeptiert und eine Übertragung ist dann nicht möglich. Ob dann automatisch zu einer unverschlüsselten Verbindung zurück gegriffen wird, hängt wohl mit den Einstellungen zusammen..

Bei mir übernimmt Postfix den Job und ich habe mich mehr oder weniger an die Anleitung unter
You do not have permission to view link please Anmelden or Registrieren
bzw. die von
You do not have permission to view link please Anmelden or Registrieren
gehalten.
Von Kolab habe ich bisher nur gehört, angeschaut habe ich es mir noch nicht.
 
  • Thread Starter Thread Starter
  • #11
Sooo, habe rausgefunden!

Scheinbar hat irgendwas dazu geführt das google und mein Server nun via IPv6 kommunizieren. Und ich hatte das natürlich noch nicht wirklich vernünftig eingerichtet.

Die Lösung war einfach beim SPF auch auf die IPv6 einzutragen, und einen reverse DNS eintrat für die IPv6 Adresse anzulegen. Nun tuts wieder. :-)

Danke für die Hilfe!

MfG

I-lk
 
Ich wuerde dir auch zu einem Programm wie fail2ban, oder aehnlichem, raten um die SSH Angriffe in den Griff zu kriegen. Das ist schnell installiert und laeuft quasi out-of-the-box schon mit brauchbaren Einstellungen - dazu kannst du es z.B. sehr leicht konfigurieren, dass eine IP nach 3 Fehlversuchen fuer 24 Stunden gesperrt wird.

Das macht Sinn, da ja seine eigene Kiste nicht unbedingt dauerhaft mit 1000000 unnuetzen SSH anfragen bombardiert werden muss.

Die meisten Angriffe zielen, nach meiner Erfahrung, sowieso auf den root Account ab - ein simples deaktivieren des root Zugangs via SSH ist da die halbe Miete.

Ein Umstellen des SSH Ports (egal ob jetzt extern oder intern) halte, ich persoenlich fuer suboptimal, einfach aus dem Grund da viele Firmenfirewalls in der Regel die nicht Standard-Ports gesperrt haben (sollten). In dem Fall kommst du, unter Umstaenden, nicht auf deinem Server mehr drauf (z.B. beim Internet-Cafe oder Hotel WLAN).
 
_____ schrieb:
Ein Umstellen des SSH Ports (egal ob jetzt extern oder intern) halte, ich persoenlich fuer suboptimal, einfach aus dem Grund da viele Firmenfirewalls in der Regel die nicht Standard-Ports gesperrt haben (sollten). In dem Fall kommst du, unter Umstaenden, nicht auf deinem Server mehr drauf (z.B. beim Internet-Cafe oder Hotel WLAN).
Zum Vergrößern anklicken....

Bei vielen Firewalls hat man allerdings auch das Problem, dass nicht benötigte Standardports gesperrt sind. Über Port 22 geht hier z. B. offiziell nichts.
 
Wenn das der Fall ist, dann hilft einem auch ein simples Umstellen auf einen unbekannten Port wenig.

Da der Port 22, der Standardport ist, ist die Wahrscheinlichkeit das er, meiner Meinung nach, in meinem Beispielszenario, offen ist am hoechsten.

Natuerlich ist das nur eine Vermutung, wissen kann man das nicht da es von Fall zu Fall anders ist - aber hier gehe ich nach der Wahrscheinlichkeit. Ist dem nicht so muss man sich vor-Ort Gedanken machen.
 
Wenn auf dem Server kein Webserver laufen soll, welcher Inhalte per HTTPS ausliefert, und man aus restriktiven Netzwerken auf den Server zugreifen muss, würde sich Port 443 als Alternative anbieten. Das führt einerseits dazu, dass der Spam im Syslog aufgrund der unsinnigen Wordlist-Angriffe reduziert wird, andererseits ist dieser Port in den seltensten Fällen gefiltert und die meisten HTTP-(Zwangs-)Proxies lassen CONNECT-Requests auf Port 443 zu. Und hat man einmal eine SSH-Verbindung, lassen sich darüber natürlich auch beliebige andere Verbindungen verschlüsselt tunneln ...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben