Postfix aus nicht vertrauenswürdigen Quellen

[helsch]

...

[eggy]

Das Szenario mit dem falschen DNS sollte kein Problem sein, das Paket das durch das Update installiert werden soll, hätte dann die falsche Signatur, sollte daher mit Fehlerausgabe ignoriert werden.

Wahrscheinlicher ist, dass sich jemand durch irgendnen anderen Fehler (z.B. in Webmin) nen root-Zugang verschafft hat.

[helsch]

...

[DeletedUserReAsG]

Du weißt, dass Mirrors genutzt werden, die auch in Polen stehen können? Interessanter wären die Prüfsummen/Hashes des Paketes und der Vergleich dieser mit den auf p.d.o Angegebenen.

[helsch]

...

[DeletedUserReAsG]

Das Progamm sagte dir doch, dass etwas mit der Quelle nicht stimmt? Das Prüfen wäre eine Möglichkeit zu schauen, was genau nicht stimmt. Sorry – hatte es so verstanden, als würde es darum gehen.

[r4pt0r]

Wurde evtl die Adresse des/der Updateserver in der /etc/hosts auf eine andere IP gemappt?

Wichtig wäre auch den Angriffsvektor zu finden bevor ein neuer (identisch konfigurierter) Server ans Netz geht. user/auth-logs prüfen!
Insbesondere (unnötige) webinterfaces für die Systemkonfiguration/-verwaltung sind hier typische Kandidaten, ebenso wie CMS/Bloggingsysteme (Wordpress!!!).

[Lord_Carlos]

/etc/apt/ <-- Gibt es da viellleicht noch ein unterordner mit mehr listen ueber der normalen sources.list hinaus?

[Paddie]

/etc/apt/ <-- Gibt es da viellleicht noch ein unterordner mit mehr listen ueber der normalen sources.list hinaus?

Hi,

/etc/apt/sources.list.d/ wäre da die nächste Anlaufstelle! Ansonsten ist mir nichts bekannt.

Gruß

Paddie

[helsch]

...

[r4pt0r]

Was anderes: Wieso eigentlich nur port 25? Man sollte eigentlich möglichst alle SMTP-Verbindungen auf SMTPS (587) zu ziehen und die Verbindungen per TLS sichern... (IIRC war submission in postfix aus wheezy noch etwas "verkorkst" implementiert - ein weiterer grund das System schnellstmöglich auf einen aktuellen Stand zu bringen!!)
Auch "smtpd_recipient_restrictions = permit_mynetworks" sollte man nach möglichkeit vermeiden - wie sieht die mynetworks-whitelist aus? Wenn das gesamte LAN drin ist und Postfix verbindungen von der Fritzbox per NAT mit lokaler Adresse zugeschanzt bekommt hast du ein offenes relay gebaut - da kann Postfix nix dafür und modifizierte Pakete gabs dann auch nicht...

Wenn du dir sicher bist dass es "modifizierte" Pakete waren (aus dem apt-cache holen und checksummen mit frisch heruntergeladenen gleicher Version vergleichen), dann stell uns/anderen diese Pakete zur Verfügung. Ein postfix mit backdoor in freier Wildbahn ist definitiv für _viele_ interessant!!

Ansonsten:
Auch wenn webmin & co es "eigentlich" nicht sein können - prüfe alle Dienste! Ursprung kann auch im lokalen Netz gewesen sein! Win 7+ Clients im Netz? Deren dämlicher teredo ipv6-Tunnel hebelt jedes edge-firewalling/filtering aus!

Auch das firewalling und routing des virt-host genau unter die Lupe nehmen (wobei virtualbox da sowieso ziemlich ungeeignet für saubere regeln und serverbetrieb ist, da es sich direkt ans 'eth'-device hängt). Welches Host-OS läuft überhaupt? Hier alles "sauber"?

<paranoia-mode>
Der Fritzbox würde ich persönlich keinen Meter trauen - meine hängt ausschließlich für Telefonie in ner eigenen Zone am Gateway und was da so alles an der Firewall nach aussen geblockt wird hat nix mit VoIP am Hut.
Speziell die (in praktisch allen consumer-routern und erst recht auf Providerseite...) miserablen/ungesicherten SOAP-Implementierungen sind Angriffsvektoren erster Klasse und wunderbar automatisiert ausnutzbar.
</paranoia-mode>

[Blackbox]

Ich denke ja, die sind über Webmin (wenn du sowas schon freiwillig einsetzen willst, sollte es auch ausschließlich auf localhost lauschen) in dein System eingebrochen.
Das ist die verbreiteste Einbruchsmethode in den letzten 3 Jahren.

Ob nun confixx, Paraells Panel, webmin, phpmyadmin oder ISPConfig, alle boten Sicherheitslücken in den vergangenen Jahren, über die massenhaft Systeme übernommen wurden.

[helsch]

...

[weshalb]

Er kann auch aus deiner Netzwerkumgebung gekommen sein.

[helsch]

...

[helsch]

...

[weshalb]

Mir fallen da noch ganz andere Sachen ein. Beispielsweise: was wäre, wenn einer deiner Rechner, mit denen du den Server administrierst, kompromittiert ist und der sich somit durchhangelt?

Edit

Hatte deine Antwort zu spät gelesen. Trotzdem: Durchgehangelt ist durchgehangelt und mittels Skript läßt sich sowas auch zu einem anderen Zeitpunkt starten.

Zu der Zeit war der Server der einzige der noch aktive war.

Du schreibst, dass der Server in einer virtuellen Maschine lief. Also war da ja auch noch was anderes aktiv.

[helsch]

...

[weshalb]

Frage ist und bleibt, wie ist er hineingekommen?

Und das möchtest du jetzt in einer "isolierten" Umgebung testen?

[eggy]

Und stell Dir mal die Frage, wofür Du webmin und co brauchst, wenn auf der Kiste nur eine Anwendung - der Mailserver- laufen soll.

[helsch]

...

[helsch]

...

[DeletedUserReAsG]

Für die virtuellen Domainen mit mehr als 100 eMail Adressen.
Editierst du dafür immer noch die x.conf per vi?

Genau dafür kann man Postfix nativ an SQL anbinden (z.B. via postfix-mysql).

Fail2ban schreibt Protokolle und bei mehreren hunderten von Einträgen unter den IPtables ist Webmin ein gutes Werkzeug.

Andere bauen sich einfache Scripte und Regeln. Ohne Software, die einerseits tief ins System eingreift und andererseits ’ne weite Angriffsfläche bietet. Webmin war in der Vergangenheit nicht der unwahrscheinlichste Weg, die Kontrolle über sein System zu verlieren. Was zugegebenermaßen in vielen Fällen nicht an Webmin selbst lag, sondern an seiner Konfiguration.

[TRex]

Was mich dringend interessieren würde, wäre alles um das alte postfix-Paket. Also APT-Konfiguration, Version des alten Pakets, die Datei in /var/cache/apt/archives/, Prüfsummen, dpkg.log (da steht dann auch drin, wann die alte Version installiert wurde) und vergleichbare Logs (ich weiß nicht aus dem Stehgreif, ob die URL irgendwo geloggt wird)

Die Infos wären wohl notwendig, um folgende Fragen zu beantworten:
- was für eine Postfix-Version lief da?
- war die Postfix-Version eine offizielle, die irgendwann mal in den debian-Repos war?
- aus welchem Repo kam sie?
- falls Version und Repo korrekt, wie ist die Prüfsumme des Pakets?
- falls Version oder Repo nicht korrekt, wie kam das Paket auf das System?
- wann wurde es installiert? Schon lange vor dem Angriff oder eher kurz davor?

Auch interessant wäre die auth.log - wann hast du dich angemeldet und von wo? Passen alle Logins zeitlich und von der IP her auch zu deinem Provider? Wenn es webmin war, müsste es ein Eintrag von www-data zu root zu finden sein. Auch hier zeitliche Korrelationen suchen - tägliches Upgrade, manuelle Aktionen vs. irgendwann um 2:31 morgens.

Natürlich könnten alle Logs gefälscht sein, aber das heißt nicht, dass sie es auch sind.

[eggy]

Für stupide Wiederholungen nutz ich in der Regel Scripte, meist bietet sich da awk an.

Ich hab halt etwas Bauchweh ner Webanwendung Vollzugriff aufs System zu geben, besonders wenn diese Anwendung regelmässig mit "aktuelle Version mal wieder für Remote Code Ausführung anfällig" Schlagzeilen schreibt.