Posts by Mutschas

Hallo,

ich habe da mal eine Frage. Ich habe das OpenDKIM Plugin installiert. Wenn ich nun über das Panel für einen Kunden OpenDKIM aktivieren möchte, dann sieht das Ergebnis wie folgt aus:

Wie ihr sehen könnt, steht in der Spalte wirklich nur "mail._domainkey". Ist das so korrekt? Ich dachte da müsste eigentlich "mail._domainkey.hierstehtdiedomaindeskunden.de" stehen?

Wenn ich via Konsole prüfe...

erhalte ich:

Warum "No key"?

Habe ich etwas übersehen?

Das Panel sagt ja "OK".

Danke.

Ich habe das Hack-Tool mal selbst getestet. Mit dem dort enthaltenem Terminal kommt man maximal bist /var/www/virtual/domain aber nicht nicht bis /var/www/virtual auch nicht /var/www auch nicht /var und auch nicht /.

Nochmal Glück gehabt

Ach so hast du das gemeint. Alle schädlichen Dateien unter/var/www/virtual/domain.tld/htdoc sind bereits entfernt.
Ich habe mir auch schon Dateien mit Änderungstimestamp aus /etc/ und andere /var Ordner auflisten lassen. Sehe aber keine Änderungen in den Konfig-Files usw.
Nur die schädlichen php-Dateien die bereits entfernt wurden.

Login-Daten des Users wurden natürlich geändert.

Also wenn ich Nuxwin richtig verstanden habe, dann kann man unter Debian nicht alles sehen.
Vielleicht wurde auch gar nichts auf shell-Ebene gemacht.
Ich habe das nur erwähnt, weil das verlinkte Tool die Möglichkeit bietet.
Ein Logfile für shell_exec gibt es ja nicht?

Und zur Neuinstallation: Warum muss ich ein Dump erstellen und wieder einspielen. Reicht es nicht, wenn ich die MySQL-Dateien einfach sichere und später wieder an die selbe Stelle kopiere?

Quote from Bulli

Wobei das in deinem Fall eigentlich keinen Sinn macht, da du alle Zugangsdaten, Dateien etc. dann wieder 1:1 auf dem "neuen" Server hast und somit auch die schädlichen Dateien.

Aber wie denn dann?

Hallo,

ich nutze aktuell noch imscp 1.2.17. Ich würde gerne auch die neue Version updaten.

Frage 1) Geht das direkt von 1.2.17 oder muss ich schrittweise updaten?
Frage 2) ich überlege, vorher den Server komplett neu aufzusetzen. Letztens wurde einem Kunden sein FTP-Login erraten und ein Hacker hat dann seltsame php-Dateien hochgeladen (insbesondere das hier http://code.google.com/p/b374k-shell). Der Kunde hatte wegen einem Skript Zugriff auf's php-Befehl "shell_exec". Jetzt weiß ich nicht, ob der Hacker dann auch evtl. mehr als nur auf seinem Webspace was getan hat. Oder bin ich hier zu paranoid und der Hacker hätte auf Grund von nicht vorhandenen Rechten äh nichts anstellen können? Angenommen ihr empfehlt mir, den Server neu aufzusetzen, wie müsste man hier bei imscp vorgehen um alles nach der Neuinstallation wieder so zu haben, wie's aktuell ist - natürlich inkl. Kundendateien usw.

PS: Debian Jessie

Danke.

Ich dachte eigentlich auch, dass es weniger etwas mit i-mscp zu tun hat, darum habe ich es ins Off-Topic geschrieben, aber so schnell kann man sich täuschen.

Danke dir dafür. Also wird das auch nicht von i-mscp benötigt? Dann werde ich es entfernen.

Auf die Schnelle habe ich den Port einfach geblockt, aber ist das eine Dauerlösung?

Hallo zusammen,

ich habe vom BSI eine Mail erhalten, dass ich angeblich einen offenen mDNS-Server habe. Verstehe jedoch nicht, wieso, weshalb & warum. Bind9 ist nicht installiert und sonst habe ich auch keinen alternativen DNS-Server auf meinem Root laufen.

Das ist die Mail. Vielleicht kann mir ja jemand helfen, was zu tun ist:

Quote from BSI

Sehr geehrte Damen und Herren,

Multicast DNS (mDNS) dient der Auflsung von Hostnamen zu IP-Adressen
in lokalen Netzwerken, welche nicht ber einen DNS-Server verfgen.
Implementierungen von mDNS sind z.B. Apple 'Bonjour' oder 'Avahi' bzw.
'nss-mdns' unter Linux/BSD. mDNS verwendet Port 5353/udp [1].

Neben der Preisgabe von Informationen ber das System/Netzwerk knnen
offen aus dem Internet erreichbare mDNS-Dienste fr DDoS-Reflection/
Amplification-Angriffe gegen Dritte missbraucht werden [2][3].

Im Rahmen des Shadowserver 'Open mDNS Scanning Projects' werden Systeme
identifiziert, welche mDNS-Anfragen aus dem Internet beantworten und
dadurch fr DDoS-Angriffe missbraucht werden knnen, sofern keine anderen
Gegenmanahmen implementiert wurden.

CERT-Bund erhlt von Shadowserver die Testergebnisse fr IP-Adressen in
Deutschland, um betroffene Systembetreiber benachrichtigen zu knnen.
Weitere Informationen zu den von Shadowserver durchgefhrten Tests
finden Sie unter [4].

Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in Ihrem
Netzbereich. Der Zeitstempel gibt an, wann das System geprft wurde
und mDNS-Anfragen aus dem Internet beantwortet hat.

Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur
Absicherung der mDNS-Dienste auf den betroffenen Systemen zu ergreifen
bzw. Ihre Kunden entsprechend zu informieren.

Falls Sie krzlich bereits Gegenmanahmen getroffen haben und diese
Benachrichtigung erneut erhalten, beachten Sie bitten den angegebenen
Zeitstempel. Wurde die Gegenmanahme erfolgreich umgesetzt, sollten
Sie keine Benachrichtigung mit einem Zeitstempel nach der Umsetzung
mehr erhalten.

Referenzen:

[1] Wikipedia: Multicast DNS
<https://en.wikipedia.org/wiki/Multicast_DNS>
[2] US-CERT: UDP-based Amplification Attacks
<https://www.us-cert.gov/ncas/alerts/TA14-017A>
[3] US-CERT: Multicast DNS (mDNS) implementations may respond to
unicast queries originating outside the local link
<http://www.kb.cert.org/vuls/id/550620>
[4] Shadowserver: Open mDNS Scanning Project
<https://mdns.shadowserver.org/>

Diese E-Mail ist mittels PGP digital signiert. Informationen zu dem
verwendeten Schlssel finden Sie auf unserer Webseite unter:
<https://www.cert-bund.de/reports-sig>

Bitte beachten Sie:
Dies ist eine automatisch generierte Nachricht.
An die Absenderadresse kann nicht geantwortet werden.
Bei Rckfragen wenden Sie sich bitte an unter Beibehaltung der
Ticketnummer im Betreff an <[email protected]>.

======================================================================

Betroffene Systeme in Ihrem Netzbereich:

Format: ASN | IP address | Timestamp (UTC) | Workstation info
24940 | 111.111.111.111 | 2016-09-17 08:03:53 | huhu [00:11:22:33:44:55]._workstation._tcp.local.

Mit freundlichen Gren / Kind regards
Team CERT-Bund

Bundesamt fr Sicherheit in der Informationstechnik (BSI)
Federal Office for Information Security
Referat CK22 - CERT-Bund
Godesberger Allee 185-189, D-53175 Bonn, Germany

Display More

Danke.

Letzteres Problem mit sasl2 konnte ich jetzt wohl auch beheben. Die Pakete "db-util db5.3-util sasl2-bin" haben gefehlt. Wurden damals bei "libsasl2-2 libsasl2-modules" wohl nicht mit installiert. Jetzt gibt es auch den Ordnern /usr/lib/sasl2.