iFrame Attacke - Woran liegts?

Hallo Stephan, hartes Ding!!!

FTP ist so das unsicherste Verfahren welches es gibt. Passwörter werden klar über das Netz übertragen. Der Leitungsmonteur Deines Vertrauens braucht nur die Netzwerkkarten vor Deiner Haustür reparieren und schon ist könnte er Dein Partner sein.

Woher nahmst Du die Info "Abuse Department".
Wenn die logdateien für dein FTP vorhanden sind, kannst schauen wer wann sich mit welcher ip eingeloggt hat und was geändert wurde. (.ftpquota)
Ebenso die Apache Logs durchblättern. Das geht nur Zeile für Zeile.
Die Logs werden automatisiert vom Server angelegt. So kann der "normale" User die nicht löschen, einschliesslich Dir nicht. Sollten die Logs weg sein, waren die Rechte für die Logs nicht richtig gesetzt oder der Angriff kam von ganz oben.

Nehme mal an du hattest als Login Daten keine der Sorte
mutti
kekse

Ein Angriff auf ftp egal ob mit Password list oder Bruteforce hat mehrere Login-Versuche des Angreifers zur Folge.
Pass1 //geht nicht
Pass2 //geht nicht
Pass3 //geht nicht
Pass4 //geht nicht
...usw.
An dieser Stelle ist der Server gefragt:
6 Fehlversuche; also sperr ich mal die IP für 10 minuten.

Probiere das doch selbst einmal aus.

Wenn man gehäggt wurde: Die Domain statt auf das gehäggte auf einen anderen Webspace umleiten.
"wir machen gerade alles hübsch". So kommt keiner deiner Nutzer in den Genuss des iFrames.

Nichts löschen oder ändern!!!!!!
Analyse: Welche Datei wurde geändert(nach Datum) ist das mindeste
Dann, wie oben beschrieben loggs um das Datum auswerten.

Der schlimmste Fehler:: Löschen und neu bespielen. Da die Ursache nicht gefunden wurde, ist die Lücke immer noch vorhanden. So ist der Hägga dann auch einer Deiner Stammeditoren.

Hi Roman,

na dann war mein löschen ja wirklich eine schlecht Idee. Beim nächsten mal werde ich es so machen, wie von dir beschrieben. Das mit dem "Abuse Departement" entnahm ich im 1und1 Kunde- bzw. Adminbereich im Bereich FTP, wo man halt die FTP-Zugänge einrichtet. Diejenige, für die ich die Website gebastelt habe, hat auch eine E-Mail von 1und1 erhalten, dass sie die Seite erstmal vom Netz genommen haben, da Sie den Angriff nicht abwehren konnten. Der Support meinte wohl man solle Virenprogramme vorschalten - wie schalte ich denn vor eine Website ein Virenprgramm? - mit der Materie kenne ich mich ja nun gar nicht aus.

Gruß Stephan

Hallo Stephan,

Ich wüsste nicht, warum man ein Virenprogramm vorschalten sollte. Wenn es defacto keine Schreibrechte auf dem Server gibt, werden keine neuen Dateien gespeichert.
Für das E-Mailverzeichnis, ist das notwendig, da dateien geschrieben werden.

Nun stellt sich die Frage, ob der Kunde ein Vps hat und/oder welchen Umfang das Paket besitzt.

...man müsste es sehen. Die Antwort vom support war erste Sahne. Keiner weiss wie der Angriff erfolgte aber nen Virenwächter vorschalten.

Immer die Schreibrechte entfernen auch für die Ordner, das kenne ich von vielen Joomlainstallationen. Da wird die Bude aufgemacht um bequem neue Teile zu installieren aber das zumachen vergessen.

Die Schreibrechte hatte ich immer auf 644, so dass an sich nur root Schreibrechte hat und sonst nur Leserechte bestehen. Sollte man also auch die root-Rechte auch auf Lesezugriff beschränken?

Ach man mit Sicherheit beschäftigt man sich immer erst intensiv, wenn schon zu spät ist. Dabei war die Seite schon auf Platz 1 bei zwei relevanten Keyword-Kombinationen und ist jetzt natürlich gleich in den SERP gefallen...

Naja mal schaun...

Noch mal Danke für die Tipps Roman!

Gruß Stephan

Hallo Stephan, wenn du magst, kannst mir gern die FTP Logs samt Apache Access und Errorlog per mail senden.
Wenn es geht auch eine phpinfo.
Es würde mich auch interessieren ob man im Nachgang noch etwas sehen kann.

Hallo,
ich habe vorhin alles Andere stehen und liegen lassen, nachdem ich Stephan´s Thread gelesen habe. Mein Kurzbericht ist allerdings eher ein Sonderfall: Sicherheit bei Typo3 auf HostEurope erhöhen. Aber ich denke mir, dass diese kleine Zusammenstellung dem Einen oder Anderen trotzdem von Nutzen sein kann.

SSH-Zugang
Der SSH-Zugang ist am leichtesten zu konfigurieren: bei HE im KIS (Kunden-Informations-System) Menüpunkt "SSH-Zugang konfigurieren", neues Passwort eingeben.
In der kurzen Wartezeit habe ich meinen Putty umkonfiguriert: Button "SSH" wählen, Port 22 wird automatisch eingestellt. Das war´s.

Sicherer FTP-Zugang mit Filezilla
Im KIS von HE mit Menüpunkt "SSLv2-Protokoll" SSL aktivieren.
Im Filezilla wähle ich Reiter "Allgemein", dann Server-Typ "FTPES - FTP über explizites TLS/SSL".
Anmelden und sicherer sein.

HTTPS-Verbindung (SSL-Proxy) für Typo3-Backend
In die localconf.php einfügen:
// BackEnd SSL login for Typo3v4.x
$TYPO3_CONF_VARS[\'SYS\'][\'reverseProxyHeaderMultiValue\'] = \'first\';
$TYPO3_CONF_VARS[\'SYS\'][\'reverseProxyIP\'] = \'internal-proxy-ip\';
$TYPO3_CONF_VARS[\'SYS\'][\'reverseProxySSL\'] = \'internal-proxy-ip\';
$TYPO3_CONF_VARS[\'SYS\'][\'reverseProxyPrefix\'] = \'\';
$TYPO3_CONF_VARS[\'SYS\'][\'reverseProxyPrefixSSL\'] = \'/meine-domain.de\';
$TYPO3_CONF_VARS[\'BE\'][\'lockSSL\'] = 1;

Wobei ich die "internal-proxy-ip" von HE herausbekomme, indem ich ssl.webpack.de/meine-domain.de aufrufe und in der LOg-Datei nachsehe, von welcher IP der Aufruf kam.

Danach noch Kontrolle, ob die Rechte stimmen (typo3conf und Konfigurations-Dateien auf mindestens 755) und schon kann ich das Backend über ssl.webpack.de/meine-domain.de aufrufen.

Hallo Lutz,

Danke für deine Zusammenstellung - naiv wie ich war habe ich mich immer über das unverschlüsselte FTP-Protokoll zum Server verbunden.

FileZilla habe nun so eingestellt, dass ich über SFTP mich zum Webserver verbinde - hoffe damit haben ich ein wenig die Sicherheit erhöht :.

Gruß Stephan

Hier noch fix einen Link, in dem dem ein paar Kleinigkeiten beschrieben sind

www.heise.de/security/artikel/Grundsicherung-fuer-PHP-Software-270918.html

Ich sichere jeden Bearbeitungsbereich stets auch noch mit einer .htaccess, völlig unabhängig vom Login des Skripts selbst.
So ist ein Zugriff selbst bei Ausnutzung irgendeiner Softwarelücke nicht ohne weiteres möglich.

Da Roman mich auf die Idee brachte, doch mal die PHP-Einstellungen zu überprüfen und ich festgestellt hatte, dass register_globals, open_basedir und allow_url_open auf "On" waren, wollte ich denjenigen die bei 1und1 einen Webserver haben nur mal informieren, dass sie auch mal nachgucken sollten, ob da alles ordentlich gesetzt ist.

Dazu einfach eine info.php anlegen und aufrufen bzw. die bestehende info.php im Verzeichnis "logs" aufrufen (z.B. www.domain.de/logs/info.php). Wie mir bekannt ist, ist bei 1und1 die PHP Version standardmäßig auf 4.x eingestellt und die oben genannten Einstellungen sind auf "On".

Wenn man nun seine .htaccess um den Eintrag "AddType x-mapp-php5 .php" erweitert, dann wird auf dem Webserver die PHP Version 5.x verwendet und siehe da, alle "unsicheren" PHP-Einstellungen sind auf "Off".

Vielleicht hilft einem ja dieser kleine Tipp, damit nicht das gleiche passiert wie bei mir :

Gruß Stephan