Spam wird über meinen Server versendet

[Cr41s3]

Hallo zusammen,

Auf meinem Debian 7 Server habe ich aktuell das Problem, dass über den Server dutzend von E-Mails versendet werden.
Habe folgendes in den Logs (ca. tausende Male)

Dec  4 21:12:15 hostname postfix/error[4504]: 0DE6742273FC: to=<toro02468@yahoo.com.tw>, relay=none, delay=911, delays=910/0.04/0/0.05, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mx-tw.mail.gm0.yahoodns.net[203.188.197.111] while sending RCPT TO)

SSH ist mit SSH Keys gut abgesichert und es gibt nur mich als Nutzer und mein Key ist geschützt.
Ansonsten läuft über den Webserver eine .html Datei und eine Domain, die in jedem Verzeichnis mit .htaccess und Passwort geschützt wird.
Habe eigentlich auch keine Viren.
Habe mit rkhunter das System schon geprüft.

Hoffe ihr könnt mir helfen.

MfG-

 

[Daaron]

Du hast sicher ein Tool wie phpMyAdmin installiert, direkt aus den Paketquellen heraus... Leider werden diese Releases nicht gepflegt und sind Freiwild für leidlich motivierte Angreifer. Den Rest erledigt dann der PHP-Befehl mail().

Du solltest die Logs intensiver analysieren um herauszufinden, wie die Mails erzeugt wurden. Bis dahin: Postfix abschalten.

 

[Cr41s3]

Habe Webmin installiert.
Könnte es daran liegen?

PhpMyAdmin benutze ich nicht.

Edit: Webmin ist runter.

Edit2: An Webmin/Usermin lag es nicht

 

[IMars]

Mach mal einen open relay test, vielleicht ist einfach nur die Konfiguration falsch, etwa
http://www.mailradar.com/openrelay/

 

[Cr41s3]

Okey habe ein Open Relay gefunden.
Weiß nur leider nicht wie ich das schließe.

Hier mal der Output von

postconf -n

:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mailbox_size_limit = 0
mydestination = localhost
myhostname = domain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_sasl_authenticated, permit mynetworks, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/mailcert.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_use_tls = yes
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp

 

[Daaron]

smtpd_recipient_restrictions sieht mir etwas zu kompakt aus. Ich kann mich düster daran erinnern, dass unser Firmen-Mailserver da ne Elle mehr Einträge drin hat, die allerhand Mumpitz abweisen.
Außerdem vermisse ich "smtpd_sender_restrictions = reject_unknown_sender_domain"

Ansonsten: http://www.howtoforge.com/perfect-server-debian-wheezy-apache2-bind-dovecot-ispconfig-3-p3 Punkt 10.
Saslauth in der master.conf sollte das Schlüsselwort sein. Wer sich nich per SASL authentifiziert, der darf nix schicken.

 

[Cr41s3]

Habe beides ausprobiert, aber hat leider nicht geholfen.
Habe es auf jeden Fall mal nach diesem Tutorial eingerichtet
https://www.digitalocean.com/commun...r-using-postfix-dovecot-mysql-and-spamassasin
aber das Tutorial scheint nicht sicher zu sein(?)

MfG-

Nevermind.
Habe ausversehen permit mynetworks und nicht permit_mynetworks geschrieben

Danke euch trotzdem <3

 

[emeraldmine]

Allgemein iss auf Linux , für mich gesehen, gar nix sicher. Kommt doch jeder ran mit dem SuperUser, oder irre ich da komplett ? :O

 

[Cr41s3]

Und wie kommt "jeder" an den SuperUser?

Thema ist übrigens erledigt.

 

[Daaron]

Allgemein iss auf Linux , für mich gesehen, gar nix sicher. Kommt doch jeder ran mit dem SuperUser, oder irre ich da komplett ? :O

Ja, weil ja jeder Superuser-Privilegien ganz so nebenbei erlangt... Wenn du so argumentierst, dann ist Windows oder BSD genau so unsicher, denn iiiiiirgendwie könnte auch da jemand SU-Privilegien erlangen und das System umbuddeln.

 

[emeraldmine]

Letztens gings noch bei irgendeiner Version von Ubuntu 13.10 ? Da warens nur ein paar Tastendrücke ohne Passwort , da war man SU.

 

[Cr41s3]

Und wie kommt man so weit, dass man irgendwelche "Tastendrücke" auf dem Server ausführen kann?

 

[emeraldmine]

keinen Plan, aber war mir sicher NIEmals nimmer SSH zu aktivieren ,da darin eine RemoteSteuerung mit drin verbunden ist . Mehr hab ich daran nie kapiert. Und Server sind mir ein Graus.

 

[Daaron]

Letztens gings noch bei irgendeiner Version von Ubuntu 13.10 ? Da warens nur ein paar Tastendrücke ohne Passwort , da war man SU.

1.) das möchte ich arg bezweifeln
2.) 13.10 ist veraltet, sollte das Lücken haben, dann werden die auch nicht mehr gefixt
3.) Wie willst du bei einem Server "ein paar Tasten drücken", wenn du noch nicht einmal eine sehr unprivilegierte Verbindung herstellen kannst?
4.) Beweise her!

keinen Plan, aber war mir sicher NIEmals nimmer SSH zu aktivieren

SSH heißt nicht zum Spaß SECURE... SSH ist der einzig gangbare Weg, wenn du ein Unix-artiges System, auf das du keinen physischen Zugriff hast, administrieren willst.

Eine SSH-Verbindung ist sicher. Wenn du kein für den Rechner gültiges Passwort kennst, dann kannst du nur per Brute-Force raten. Läuft auf der Maschine dann ein Brute-Force-Schutz wie Fail2Ban, ist B/F keine Option mehr. Außerdem SOLLTE man SSH auf einen anderen Port legen und Login per Passwort abschalten und nur noch Login per Keyfile zulassen.

Aber warum hängst du dich überhaupt rein wie ein Tauchsieder, wenn du von Servern keinen Dunst hast?

 

[emeraldmine]

du dich überhaupt rein wie ein Tauchsieder

Hier kann man sich ja mal auf deutsch "unterhalten" : D , und nach wie vor hab ich Sch*** vor Linux.

Gastzugänge ausgeschlossen ? Mal anders gefragt kann man eine Userliste einsehen ? Natürlich NUR Offline , bitte.

 

[Daaron]

WENN du physischen Zugriff hast und WENN eine der gängigen Desktop-Umgebungen nebst Login-Bereich eingerichtet ist, dann hast du meist eine Liste der auf dem System verfügbaren User, genau wie im Windows.... und genau wie in Windows kann man auch das abschalten. Aber was nutzt dir diese Information? Wenn das Passwort nicht trivial ist und eine Anti-B/F-Lösung verwendet wird, dann ist es egal, ob der Login jetzt lokal oder über SSH oder sonstwas erfolgt.

Und nein, SSH erlaubt keine Gäste. Nur solche Trivial-Protokolle wie FTP erlauben anonyme Logins. SSH erzwingt die Existenz eines Accounts, auf die eine oder andere Form. Man könnte z.B. SASL Auth so konfigurieren, dass es eine MySQL-Datenbank als Accountliste verwendet. Und natürlich könnte man Kerberos verwenden.

 

[emeraldmine]

10 % hab ich davon verstanden, aber gut dass es keinen Gastaccount gibt.

 

[Daaron]

Na woran mangelt es denn? Wenn du ein Desktop-Linux installierst, dann verhält es sich nutzerfreundlich, so wie Windows. Du kannst im Login-Screen (lightdm, gnomedm,..) einfach auf einen User klicken und dann das Passwort des Users eingeben. Du erfährst also den Usernamen... der bringt dir nur eben nix.
Wenn du hingegen eine Desktop-lose Umgebung hast (z.B. n Mediaserver oder Router zuhause oder ein riesiges Killer-Teil in einem Rechenzentrum) oder dein Desktop so konfiguriert ist, dass du Usernamen und Passwort explizit eingeben musst, dann gibts keine hübsche Liste zum Abschreiben. Entweder du KENNST den Usernamen (und das Passwort), oder du sitzt auf ewig in der Tinte.

Was SASL Auth und Kerberos sind, das darfst du gern selbst nachlesen. Besonders Kerberos ist eine sehr tolle Technologie. ABER: Das ist alles nix für USER, sondern für ADMINS.

 

[emeraldmine]

ok,dann bin ich bis hier her sehr zufrieden und danke Dir auch vielmals.