MySQL hat Tabelleneinträge verloren

[truenoir]

Moin :)

Ich hab heute morgen feststellen müssen, das sehr viele Tabellen in unterschiedlichen Datenbanken von MySQL auf meinem Server (einschließlich der Confixx-Datenbank!) plötzlich auf dem Stand von vor zwei Tagen sind, wobei es gestern jedoch noch normal war. Dank meines Sicherungsscripts, was die Zustände der letzten 3 Tage sichert, konnte ich die Datenbanken wiederherstellen.
Jetzt bleibt nur die Frage, wie konnte das passieren?
Könnte es ein Einbruch gewesen sein? In den Logs ist nichts weiter zu finden, ausser das ständig ein Connect auf dem FTP versucht wird (wechselne IPs) mit Benutzernamen wie "admin", "anonymous", "mail" etc.
Auch ist sonst scheinbar alles in Ordnung. Es laufen auch keine Prozesse, die mir unbekannt sind.
Benutzer Root hat selbst keine Login-Möglichkeit, da dem kein passwort gegeben wurde (root:*:...) und es gibts einen anderen root-Benutzer, der per su aufgerufen werden muß. Jedoch kann ich nirgends was finden, das dies passiert ist.
Legt MySQL selbst irgendwo ein Log ab?
Das einzige, was ich finden konnte, ist folgender Eintrag vom iptables -LOG:

Mar 3 10:18:45 p15091969 kernel: SQL: IN=eth0 OUT= MAC=00:e0:4c:39:0d:ec:00:60:08:f7:12:d8:08:00 SRC=217.33.115.228 DST=217.160.xxx.xxx LEN=40 TOS=0x00
Mar 3 10:18:45 p15091969 kernel: SQL: IN= OUT=eth0 SRC=217.160.xxx.xxx DST=217.33.115.228 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=3306 DP
Mar 3 10:18:46 p15091969 kernel: SQL: IN=eth0 OUT= MAC=00:e0:4c:39:0d:ec:00:60:08:f7:12:d8:08:00 SRC=217.33.115.228 DST=217.160.xxx.xxx LEN=40 TOS=0x00

[dea]

Hmm - Ich würd' anhand Deiner Schilderung auf einen Einbruch in die Datenbank schließen. Allerdings sind Deine Informationen recht spärlich, so dass es ein schwacher Verdacht bleibt. Merkwürdig ist beispielsweise, dass ein Eindringling lediglich einen Teil der Daten gelöscht hat - warum sollte er das tun? Warum nicht alle Daten löschen?

Was sagen denn die DB-Logs? (Loggt MySQL überhaupt? Geht das?) Was sagt Dein HIDS?

Hast Du eine komplexere Skript-Anwendung (CMS, Forum, Portal, o.ä.) "auf" einem Webserver? Das könnte das "Einfallstor" gewesen sein.

Die diversen Login-Versuche auf dem FTP sind imho leider als "normal" einzustufen. Als ich noch einen FTP-Server laufen hatte gab's diese Versuche mehrmals täglich :(

Das Konstrukt mit root der nicht kann und dem root in den man wechseln muss - Erklär' das doch mal bitte genauer.

[truenoir]

Auf einen Einbruch tippe ich bisher auch, nur ergibt dies für mich keinen Sinn außer das derjenige damit bekannt machen will, das er es geschafft hat...

Also direkt im /var/lib/mysql gibts ein par Dateien, die wie ein Log aussehen, sich aber seit Januar nicht geändert haben, also hier nutzlos sind.

Nen HIDS hab ich leider nicht. Mein Server ist zwar seit zwei Jahren im Netz, aber der ist noch so unbekannt und in keiner Suchmaschine zu finden. Ich gehe daher davon aus, das der selbst für Hacker zu uninteressant ist :)

Als Webseite läuft da nur ne Informations-Datenbank, die aber nur auf eine Datenbank in MySQL zugriff hat, nicht auf alle. Nen Forum oder Portal läuft da nicht. Sämtliche Skripts sind selbst geschrieben und nicht aus vorhandenen zurechtgeschnitten.

Das mit dem FTP hab ich mir schon fast gedacht...

Das Konstrukt mit root der nicht kann und dem root in den man wechseln muss - Erklär' das doch mal bitte genauer.

Na den User root hab ich in der Shadow das Passwort geklaut und auf "root:*:....." gesetzt, so das ein Login unmöglich ist.
Dafür hab ich einen anderen User mit UID 0 angelegt, zu dem dann per SU gewechselt werden kann. Ein direkter Login per SSH/FTP etc. ist nicht möglich. Und "root" selbst kann sich gar nicht einloggen.
Ich dachte mir, das machts ein wenig schwerer bei einem direktem Angriff.

Desweiteren läuft nen Script im Hintergrund, was /var/log/messages beobachtet und sobald sich der SU dort einträgt, mir ne Mail schickt. Eine solche hab ich jedoch auch nicht bekommen...

[dea]

Auf einen Einbruch tippe ich bisher auch, nur ergibt dies für mich keinen Sinn außer das derjenige damit bekannt machen will, das er es geschafft hat...

Also direkt im /var/lib/mysql gibts ein par Dateien, die wie ein Log aussehen, sich aber seit Januar nicht geändert haben, also hier nutzlos sind.

Nen HIDS hab ich leider nicht. Mein Server ist zwar seit zwei Jahren im Netz, aber der ist noch so unbekannt und in keiner Suchmaschine zu finden. Ich gehe daher davon aus, das der selbst für Hacker zu uninteressant ist :)

Wenn es tatsächlich ein Angriff war, ist der Sinn und Zweck tatsächlich nicht augenscheinlich ...

Ich würde an Deiner Stelle, wenn es denn mit MySQL geht, das Logging aktivieren. So ließen sich zumindest zukünftig derartigen Phänomenen leichter auf die Spur kommen.

Gleiches gilt für ein HIDS. Ein Muss in meinen Augen, schließlich sind die rooties ohne externen Schutz im Netz (und dass der interne Schutz auch nicht das gelbe vom Ei ist zeigt sich ja leider immer wieder). So ließe sich zumindest auf Dateiebene feststellen, ob Veränderungen stattgefunden haben. Ich kann aus technologischer Sicht samhain (http://la-samhna.de) sehr empfehlen, in Bezug auf Untertsützung durch andere Anwender eher tripwire.

Allerdings würde ich, unter der Annahme dass es sich tatsächlich um einen Angriff handelte, vor der Installation eines HIDS bzw. vor dem Aufbau der Signatur-DB den Server neu aufsetzen. Du kannst nicht sicher sein, ob nicht eventuell Systemdate(ie)n vom Angreifer manipuliert wurden ...

Als Webseite läuft da nur ne Informations-Datenbank, die aber nur auf eine Datenbank in MySQL zugriff hat, nicht auf alle. Nen Forum oder Portal läuft da nicht. Sämtliche Skripts sind selbst geschrieben und nicht aus vorhandenen zurechtgeschnitten.

Selber schreiben ist auch kein Garant für Fehlerfreiheit ;) Und gerade SQL-Injections können so supereinfach sein, dass die Kiddies von solchen Anwendungen geradezu magisch angezogen werden :(

Das Konstrukt mit root der nicht kann und dem root in den man wechseln muss - Erklär' das doch mal bitte genauer.

Na den User root hab ich in der Shadow das Passwort geklaut und auf "root:*:....." gesetzt, so das ein Login unmöglich ist.
Dafür hab ich einen anderen User mit UID 0 angelegt, zu dem dann per SU gewechselt werden kann. Ein direkter Login per SSH/FTP etc. ist nicht möglich. Und "root" selbst kann sich gar nicht einloggen.
Ich dachte mir, das machts ein wenig schwerer bei einem direktem Angriff.

Desweiteren läuft nen Script im Hintergrund, was /var/log/messages beobachtet und sobald sich der SU dort einträgt, mir ne Mail schickt. Eine solche hab ich jedoch auch nicht bekommen...

Hmm - also die dadurch erzeugte "Sicherheit" trügt in meinen Augen. Zum einen ist der "versteckte" root nur schlechte obscurity, denn der "echte" root wird weiterhin durch die UID 0 identifiziert. Außerdem veranstalten die meisten Exploits gar kein "su", da sie schlichtweg eine Shell unter der ID des angegriffenen Prozesses starten - und wenn der Prozess in irgendeiner Form privilegiert ist merkst Du rein garnix. Auch wenn der angegriffene Prozess unprivilegiert ist hilft es Dir nicht, da die lokalen Exploits in der Regel genauso arbeiten ...

[truenoir]

Also ich hab jetzt mal alle wichtige Dateien (/etc /bin/sbin etc.) mit meinem Backup verglichen und CRC32-mäßig sind diese identisch. Das einzige was sich wirklich geändert hat, sind die SQL-Datenbanken und natürlich so alle Logfile, in denen aber nichts zu finden ist....

Desweiteren hab ich inzwischen auch das SQL-Logging aktiviert, was aber, dank Confixx, schnell sehr groß wird....

Gleiches gilt für ein HIDS. Ein Muss in meinen Augen, schließlich sind die rooties ohne externen Schutz im Netz

Werd ich mir mal angucken :)

Du kannst nicht sicher sein, ob nicht eventuell Systemdate(ie)n vom Angreifer manipuliert wurden ...

Also ich geh mal davon aus, das nichts verändert wurde, da die wichtigen Dateien identisch sind und ind den Benutzerverzeichnissen die gleiche Anzahl von Dateien mit identischem Platzverbrauch weiterhin vorhanden sind. Wenn da ein Script wäre, müsste es zufällig genau so groß sein wie ein ehemaliges anderes Script.
Sicherheitshalber hab ich den Server mal neu gestartet, da zumindest die Bootscripts nicht verändert wurden. Daher sollte doch nun auch kein anderes Script mehr laufen, oder? (Cron hab ich kontrolliert)

Selber schreiben ist auch kein Garant für Fehlerfreiheit ;) Und gerade SQL-Injections können so supereinfach sein, dass die Kiddies von solchen Anwendungen geradezu magisch angezogen werden :(

Allerdings haben meine Benutzer in den Scripten nur Select/Insert/update/delete-Rechte und sonst keine. Alles andere wird per mysql direkt gemacht.

Bzgl. dem root Account hatte ich das hauptsächlich gemacht, um direkte Angriffsversuche zum scheitern zu bringen und auch, weil per FTP immer versucht wurde, sich in den root einzuloggen.

[arnee]

Sicherheitshalber hab ich den Server mal neu gestartet, da zumindest die Bootscripts nicht verändert wurden. Daher sollte doch nun auch kein anderes Script mehr laufen, oder? (Cron hab ich kontrolliert)

Wenn du die Checksummen deiner System-Binaries mit einem Backup vergleich hast und es zu keinen Differenzen kommt, mag das so gehen. Generell trügt der Schein und das sehr! Für Rootkits ist es ein leichtes, Prozesse, Dateien, etc. zu verstecken, so dass du als normaler root gar nicht mitbekommst, dass dort noch mehr drauf ist, als das du eigentlich siehst.

[darkspirit]

Gleiches gilt für ein HIDS. Ein Muss in meinen Augen, schließlich sind die rooties ohne externen Schutz im Netz (und dass der interne Schutz auch nicht das gelbe vom Ei ist zeigt sich ja leider immer wieder). So ließe sich zumindest auf Dateiebene feststellen, ob Veränderungen stattgefunden haben. Ich kann aus technologischer Sicht samhain (http://la-samhna.de) sehr empfehlen, in Bezug auf Untertsützung durch andere Anwender eher tripwire.

Das Problem ist bei einem Rootie nur, dass du AFAIK die Datenbank des IDS nicht wirklich sicher unterbringen kannst, da du keine Möglichkeit hast, sie auf ein in jeder Weise read-only gemountetes Medium zu schreiben..

[arnee]

Das Problem ist bei einem Rootie nur, dass du AFAIK die Datenbank des IDS nicht wirklich sicher unterbringen kannst, da du keine Möglichkeit hast, sie auf ein in jeder Weise read-only gemountetes Medium zu schreiben..

Ã?h, scp + Brennen @ home ? :)

[dea]

Wie Du siehst, sind der Phantasie keine Grenzen gesetzt ;)

Ein Blick in's Manual hätte übrigens auch geholfen ...

[darkspirit]

Ã?h, scp + Brennen @ home ? :)

Dass das ein möglicher Weg für eine read-only-Sicherung der Database ist, ist mir auch klar, aber das geht bei einem Rootserver schwerlich.. Es würde mich wundern, wenn 1&1 dir deine Datenbank-CD in den Rootie schieben würde :)

[dea]

Ã?h, scp + Brennen @ home ? :)

Dass das ein möglicher Weg für eine read-only-Sicherung der Database ist, ist mir auch klar, aber das geht bei einem Rootserver schwerlich.. Es würde mich wundern, wenn 1&1 dir deine Datenbank-CD in den Rootie schieben würde :)

Ã?h, CD-Lw @ home + scp ? :)

[jubilee]

Hmmm ....
Wäre es nicht sicherer den Datenbankserver nicht ins Netz horchen zu lassen .
Also mit skip networking den Port 3306 dichtmachen.
Oder bist Du darauf angewiesen die Datenbank auch von ausserhalb
(also nicht nur local) anzusprechen ?
MfG
jubilee

[darkspirit]

Ã?h, CD-Lw @ home + scp ? :)

Ok, aber wenn das System kompromittiert wurde, kannst du auch diesem Weg nicht vertrauen.. was wäre, wenn der Angreifer den SSHD ausgetauscht hat?

Aber ok, ich seh schon, dass ich mir hier nur weiter in den Fuß schießen kann.. /me EOD :)

[truenoir]

Für Rootkits ist es ein leichtes, Prozesse, Dateien, etc. zu verstecken, so dass du als normaler root gar nicht mitbekommst, dass dort noch mehr drauf ist, als das du eigentlich siehst.

Ist das dann auch noch so, wenn ich im Rescue-Modus boote? Denn in diesem Modus hab ich auch keine weiteren "neuen" oder geänderten Dateien gefunden. Auch wurde bis jetzt keine weitere Ã?nderung an der MySQL vorgenommen, also ist seit gestern noch alles normal.

Wäre es nicht sicherer den Datenbankserver nicht ins Netz horchen zu lassen .
Also mit skip networking den Port 3306 dichtmachen.
Oder bist Du darauf angewiesen die Datenbank auch von ausserhalb
(also nicht nur local) anzusprechen ?

Leider bin ich darauf angewiesen, diese von aussen nutzen zu müssen, da bei mir @home Windows-Anwendungen laufen, die die Datenbanken mit Infos versorgen müssen. Es wäre zwar denkbar, die Daten über ein HTTP-Protokoll auf den Apache zu schieben und diesen dann das speichern zu lassen, allerdings ist dieser weg umständlich zu realisieren.
Evtl. sollte ich via iptables dann nur T-Online-IPs auf 3306 zulassen, was aber auch ziemlich viele sind...

[dea]

Für Rootkits ist es ein leichtes, Prozesse, Dateien, etc. zu verstecken, so dass du als normaler root gar nicht mitbekommst, dass dort noch mehr drauf ist, als das du eigentlich siehst.

Ist das dann auch noch so, wenn ich im Rescue-Modus boote? Denn in diesem Modus hab ich auch keine weiteren "neuen" oder geänderten Dateien gefunden. Auch wurde bis jetzt keine weitere Ã?nderung an der MySQL vorgenommen, also ist seit gestern noch alles normal.

Wäre dem so, dann hätte das Rescue-System eigentlich keine Berechtigung mehr ;) Da (zumindest bei 1&1) in eine RAMDisk gebootet wird, zudem noch von einem anderen FS, sollte man das Rescue-System eigentlich als "sicher" resp. "integer" ansehen dürfen.

Wäre es nicht sicherer den Datenbankserver nicht ins Netz horchen zu lassen .

Leider bin ich darauf angewiesen, diese von aussen nutzen zu müssen, da bei mir @home Windows-Anwendungen laufen, die die Datenbanken mit Infos versorgen müssen. Es wäre zwar denkbar, die Daten über ein HTTP-Protokoll auf den Apache zu schieben und diesen dann das speichern zu lassen, allerdings ist dieser weg umständlich zu realisieren.
Evtl. sollte ich via iptables dann nur T-Online-IPs auf 3306 zulassen, was aber auch ziemlich viele sind...

Hmm - Wenn Du keinen kontinuierlichen Datenstrom benötigst, ginge vll. ein Transprotverfahren via Input-Datei (XML, csv, was auch immer) und GPG-Verschlüsselung?

Bsp.: Du schreibst die Daten auf der WS @ home in eine normale Textdatei, das Format müsste dabei für die DB verständlich sein oder Du musst die Datei auf dem Server halt aufbereiten, und verschlüsselst die Datei anschließend mit GPG. Dann schiebst Du die veschlüssselte Datei per SNTP, S/FTP, usw. auf den Server. Entschlüsseln und in die Datenbank einlesen, fertig. Das ganze ließe sich auch wunderbar als Batch-Job automatisieren und Du hättest den "lästigen" Listener der DB nicht mehr am Hals.

[captaincrunch]

Einfachere Variante: kleines OpenVPN. ;)

[arnee]

Oder noch eine andere Idee: Du übergibst deine Home-IP an ein Script auf dem Webserver, das daraufhin den Port 3306 für deine IP öffnet oder aber 3306 immer offen ist und von deiner IP dann Connects akzeptiert werden.

[wirsing]

Und noch eine: in der my.cnf mittels bind-address=127.0.0.1 den MySQL-Server nur auf localhost horchen lassen und dann mit SSH Port Forwarding zugreifen. (Putty kann das auch)

[dea]

Bleibt bitte beim Topic!

So wie es aussieht, scheint der Angriff - so es denn nun wirklich einer war - nicht "weit" vorgedrungen zu sein. Du (OP) meinst jedenfalls erkennen zu können, dass keine Datei (mit ausnahme jener mit variablen Inhalten) verändert wurde. Das ist ja schonmal eine wichtige Erkenntnis :)

Bleibt aber immer noch die Frage, was eigentlich genau passiert ist und vor allem wie es passierte - um spätere Wiederholungen ausschließen zu können.

Da relevante Logs fehlen resp. nicht aussagekräftig sind möchte ich noch einmal die übliche Vorgehensweise empfehlen:

- Richte externes Logging ein (man syslog.con, man syslogd, man syslog-ng, ... je nachdem, was installiert ist). Das ist nich kompliziert aber dafür hoch wirksam und hat schon bei der Aufklärung so manchen "Falles" helfen können. Da als externer Logserver keine High-End Büchse benötigt wird, kannst Du Dir ruhigen Gewissens einen beliebigen "VServer" für kleines Geld mieten (meist so ab 5â?¬/Monat), das genügt.

- Für die SQL-Logs und alles, was nicht "syslog sprechen" kann nimm logrotate zum wegschreiben. Die Manpages dazu sind zwar knapp aber sehr informativ. Ich weiß jetzt nicht, wie's bei MySQL aussieht, aber wenn das Logformat stimmt, ließen sich diese Logs auch für ein Replay nutzen. Wenn nicht, dann helfen sie heffentlich zumindest bei der Ursachenforschung ;)

- Für den Datentransfer suchst Du Dir besser eines der reichlich angebotenen Konzepte aus. Generell werden Listener auf zugänglichen Interfaces als ganz schlechte Wahl betrachtet, egal, ob es sich dabei um Oracle, MySQL, PostgreSQL o.ä. handelt. Hier ist letztendlich das RDBMS selber "dran schuld", da die verfügbaren Authentisierungsmechanismen häufig nur unzulänglich (im Sinne von Sicherheit) implementiert sind. Allgemeine Praxis ist es, ein wie auch immer geartetes Gateway dazwischen zu setzen - in Deinem Fall halt der Transportmechanismus Deiner Wahl (SSH, File, was auch immer). Dieses Gateway sollte so weit wie irgend möglich abgesichert werden.

Sodele, ich hoffe, ein wenig Interessantes beigesteuert haben zu können.

[truenoir]

Hmm - Wenn Du keinen kontinuierlichen Datenstrom benötigst, ginge vll. ein Transprotverfahren via Input-Datei (XML, csv, was auch immer) und GPG-Verschlüsselung?

Hmm, allerdings ist kann das Programm, das ich verwende nur direkt mit einem SQL-Server Verbindung aufnehmen. Eine Export-Funktion oder ähnliches existiert da leider nicht.

- Richte externes Logging ein (man syslog.con, man syslogd, man syslog-ng, ... je nachdem, was installiert ist).

Damit werde ich mich wohl mal befassen :)

- Für die SQL-Logs und alles, was nicht "syslog sprechen" kann nimm logrotate zum wegschreiben. Die Manpages dazu sind zwar knapp aber sehr informativ. Ich weiß jetzt nicht, wie's bei MySQL aussieht, aber wenn das Logformat stimmt, ließen sich diese Logs auch für ein Replay nutzen. Wenn nicht, dann helfen sie heffentlich zumindest bei der Ursachenforschung ;)

Also die MySQL-Logs die ich inzwischen aktiviert habe, listen jede einzelne query auf, so dass zumindest alles verfolgt werden kann :)

- Für den Datentransfer suchst Du Dir besser eines der reichlich angebotenen Konzepte aus. Generell werden Listener auf zugänglichen Interfaces als ganz schlechte Wahl betrachtet, egal, ob es sich dabei um Oracle, MySQL, PostgreSQL o.ä. handelt.

Dies ist leider wie gesagt wegen der Beschränkungen im Programm nicht möglich. Allerdings hörte sich ArneE's Vorschlag ganz gut an:

Du übergibst deine Home-IP an ein Script auf dem Webserver, das daraufhin den Port 3306 für deine IP öffnet

[captaincrunch]

Allerdings hörte sich ArneE's Vorschlag ganz gut an:

Ã?hm...wieso, wenn's viel einfacher und sicherer (Stichwort Kryptographie) per VPN geht? Na ja, du machst das schon.

[dea]

Allerdings hörte sich ArneE's Vorschlag ganz gut an:

Ã?hm...wieso, wenn's viel einfacher und sicherer (Stichwort Kryptographie) per VPN geht? Na ja, du machst das schon.

Aäähm - auch wenn ich da jetzt nicht den Zusammenhang erkennen kann - TrueNoir, wenn Deine Anwendung zwingend den "online"-Zugriff benötigt (und Du daran nichts ändern kannst ;) ) dann würde ich Dir einen einfachen SSH-Tunnel an's Herz legen. Das entspräche am ehesten wirsing's Vorschlag und Anleitungen dazu sollten eigentlich zu Hauf im Netz liegen. :)

[truenoir]

Aäähm - auch wenn ich da jetzt nicht den Zusammenhang erkennen kann - TrueNoir, wenn Deine Anwendung zwingend den "online"-Zugriff benötigt (und Du daran nichts ändern kannst ;) ) dann würde ich Dir einen einfachen SSH-Tunnel an's Herz legen.

Na dann werd ich einfach mal gucken, ob ich da was gescheites finde :)
Bis jetzt ist übrigens nichts weiter passiert (zumindest nichts, was ich bemerkt hätte).

[dea]

Na dann werd ich einfach mal gucken, ob ich da was gescheites finde :)

Such' mal nach "SSH Tunnel Linux" oder "SSH reverse Tunnel Linux". Vielleicht gibt's ja unter http://tldp.org auch ein HOTO dazu. Müsstest Dir nur noch aussuchen, ob ein "foorward" oder "reverse" Tunnel für Deine Situation die passende Lösung darstellt.

Bis jetzt ist übrigens nichts weiter passiert (zumindest nichts, was ich bemerkt hätte).

Das fiese daran ist das fiese darin ;) Weil man nichts "merkt" heist's ja lang' noch nicht, dass nichts passiert (ist) ...