# problem mit reiserfs (denke ich) <--rootkit (solved)

## gruenschnabel

hallo zusammen

vielleicht könnt ihr mir helfen

wollte heute(remote) auf einer unserer kisten php mit einem zusätzlichen flag (ctype) neukompilieren

aber der kompiler stoppte mit einer fehlermeldung das ein anderes flag im apache2 (kann mich nicht mehr genau erinnern welches) gesetzt werden müsste

danch hing die konsole...also strgC um den Vorgang abzubrechen

daraufhin erhielt ich speicherzugriffsfehler

nach einem gang in den serverraum und einem neustert(von der konsole aus ging dies nicht mehr) reagierte auch die direkte konsole am rechner nicht mehr

bei allem was ich versuchte nur speicherzugriffsfehler -rm -f....

nichmal das killen von prozessen ging

mir blieb also nur ein kaltstart...und ach du schreck die kiste kommt nicht mehr hoch

die module lädt er anscheinend noch (ist ein genkernel) aber danach bei allen sachen die er starten soll speicherzugriffsfehler -rm-f 

und er meint das dateisystem sei readonly

naja booten von livecd....die daten sind alle noch drauf...mounten auch kein problem und zugriff auch nicht

also fsck -f /dev/hda3

er checkt alles...o transactions replayed und keine weiteren fehler gefunden

aber nach einem neustart der gleiche salat

hat einer von euch eine idee woran das liegen könnte?

ich denke ja das reiserfs sich verschluckt hat

danke schonmal im vorrausLast edited by gruenschnabel on Thu May 03, 2007 6:50 am; edited 1 time in total

----------

## mv

 *gruenschnabel wrote:*   

> ich denke ja das reiserfs sich verschluckt hat

 

Nach der Fehlerbeschreibung halte ich das nicht für wahrscheinlich.

Speicherzugriffsfehler heißt i.d.R. RAM oder CPU defekt; meistens ein thermisches Problem. Möglicherweise ist ein Lüfter ausgefallen, da hat man genau solche Symptome.

----------

## gruenschnabel

anfangs hatte ich auch darauf getippt

CPU kann man glaube ich ausschliessen...da von der livecd ja alles tadellos funktioniert

Hitze....auch diese würde sich von der livecd bemerkbar machen aber ich hatte den rechner sogar ne halbe stunde aus und danach sollte er abgekühlt sein...die lüfter laufen alle und im serverschrank sind keine 20grad

speicher...memtest hat nach 20min testen jedenfalls nichts angezeigt

ich tippe wirklich auf einen fehler im dateisystem weil in den fehlermeldungen imm von nur readonly die rede ist....irgendwie wird die partition nicht richtig gemounted(nur readonly) und dann spinnt das ganze system

wenn ich sie allerdings händisch in der liveumgebung mounte passt alles

wie kann ich reiserfs beibringen NICHT readonly beim booten zu mounten?

wenn ich mir nur die mounts anzeigen lasse sacht er sch (rw) aber ansonsten immer "Das Dateisystem ist nur lesbar" anfangen tut er damit wenn er ein rcscript aufruft (leider ist der buffer nicht gross genug um nach dem booten bis an diesen punkt zurückzuscrollen)

aber vorher kommt die meldung mounting root ohne einen fehler

ich versteh das nicht

----------

## gruenschnabel

hat keiner ne idee?

so der output vom ckfs....checking journal  0 transactions replayed....checking internal tree comparing bitmaps...checking semantic tree...no corruptions found....reiserfschk finished 

also wenn ich in der live-umgebung bin scheint alles zu stimmen...warum will er beim booten nicht sauber mounten?

----------

## Anarcho

Also wenn dermassen viele Programme defekt sind kann es eigentlich nur an der glibc liegen. Hast du vielleicht diese in letzter Zeit neu kompiliert? Eventuell mit agressiven CFLAGS?

Kannst du denn dmesg noch aufrufen? Vielleicht lässt sich da was finden.

----------

## mv

 *gruenschnabel wrote:*   

> also wenn ich in der live-umgebung bin scheint alles zu stimmen...

 

Wenn Du von der live-Umgebung die Partition rw mounten kannst, dann ist das Filesystem mit Sicherheit noch in Ordnung.

Deine Problembeschreibung ist mehr als unklar: Zuerst sprachst Du von ständigen Speicherzugriffsfehlern, jetzt erzählst Du, das Problem sei nur, dass er nicht auf die Platte schreiben kann. Was denn nun?

Wenn ein Speicherzugriffsfehler in dem rc-Script kommt, das das root Filesystem mit rw remounted, ist das Dateisystem freilich nicht beschreibbar. Was ist nach einem manuellen 

```
mount -o remount,rw /
```

?

----------

## mv

 *Anarcho wrote:*   

> Also wenn dermassen viele Programme defekt sind kann es eigentlich nur an der glibc liegen.

 

Nein, wenn er vom live-System auf die Platte chroot'en kann und dort dann keine Probleme hat, liegt es nicht an glibc. Höchstens am Kernel, aber wie sollte sich da plötzlich etwas verändern?

----------

## gruenschnabel

also der schreibzugriff ging nut aus der live-umgebung

nachchroot nicht mehr

was mich ein rootkit vermuten lies....dies hat sich auch bestätigt

ich habe den server jetzt weitestgehenst gesäubert denke ich und er läuft auch wieder und ist online

allerdings gibt mir die geschichte schon zu denken....irgendwer muss es über exploits über den apache geschafft habe das system zu hacken

kennt einer von euch ein wirklich gutes tutorial "so mache ich meine gentoo-distrie sicher" ?

mir wäre sehr geholfen damit

danke

----------

## Marlo

 *gruenschnabel wrote:*   

> 
> 
> was mich ein rootkit vermuten lies....dies hat sich auch bestätigt

 

Wie? Welche Tests, welche Resultate?

 *gruenschnabel wrote:*   

> 
> 
> ich habe den server jetzt weitestgehenst gesäubert denke ich und er läuft auch wieder und ist online

 

Wie gesäubert, mit was? Was und wie wurde danach neu installiert, kompiliert?

 *gruenschnabel wrote:*   

> 
> 
> ... mir wäre sehr geholfen damit
> 
> 

 

Uns auch, wenn du uns genauer aufklären würdest.

Grüße

Ma

----------

## gruenschnabel

hmmm

also wie gesagt kam mir das alles seltsam vor

(da von der livecd wirklich alles lief)

da ich wusste das seit 2 tagen keine files (ausser im /home/* und vielleicht logs) geändert worden sein konnten hab ich erst

mal nach frisch geänderten dateien gesucht (find /bin -mtime 0)

und siehe da in /bin 15 files gefunden

(daher die ganzen fehler sobald er versucht hat irgendeine datei zu menutzen beim booten(z.b. rm))

also alle korrupten dateien gelöscht und mit denen der livecd ersetzt

danach nochmals das backup mit dem aktuellen stand verglichen obe noch andere daten verändert wurden

(aber schien nichts weiter gemacht worden zu sein)

danach chkrootkit neu kompiliert und suchen lassen leider nix gefunden

danach wie im tut beschrieben glsa-check durchlaufen lassen und alle änderungen vorgenommen

ich denke das sie über ein exploit über drupal reingekommen sind

(wir testen drupal gerade da es ein komplett accessible cms ist...aber leider nicht sicher)

die frage ist jetzt ob das system wirklich sauber ist

wer kann mir noch ein paar tipps/tools nennen mit denen ich den rechner

checken kann und solche dinge in zukunft vermeiden kann?

es wäre wirklich hilfreich 

lg,

----------

## firefly

an deiner stelle würde ich das System komplett neu aufsetzten, eventuell auch nur das backup zurückspielen (vorrausgesetzt das backup ist nicht schon korrupiert).

Denn du kannst dir leider nie sicher sein, ob nicht doch noch irgentwo ein weitere "Schädling" sich eingenisstet hat.

----------

## gruenschnabel

das backup enthällt eigentlcu nur daten und keine systemfiles

aber das system nau aufsetzen werde ich am WE sicher

trotsdem würde ich ja gerne die Lücke ausfindig machen...ansonsten setzt ich das system neu auf und verbringe in 2 wochen wieder eine nacht im serverraum da die lücke wieder da ist (ich meine das koppupierte system was noch nicht alt(einige monate) und ausser dem kernel alles immer auf dem neusten stand)

es muss doch eine möglichkeit geben nach solchen rootkits cronmässig zu scannen

(chkrootkit hat NICHTS gefunden(nicht virher und nicht nachher))

lg,

----------

## firefly

es muss sich ja nicht umbedingt um ein rootkit handeln, es kann auch sein, das jemand einfach über eine lücke in einem der laufenden services, einfach die Programme der coreutils (rm und co) überschrieben hat. 

Das würde zumindestens teilweise die speicherzugriffsfehler erklären.

----------

## gruenschnabel

 *firefly wrote:*   

> es muss sich ja nicht umbedingt um ein rootkit handeln, es kann auch sein, das jemand einfach über eine lücke in einem der laufenden services, einfach die Programme der coreutils (rm und co) überschrieben hat. 
> 
> Das würde zumindestens teilweise die speicherzugriffsfehler erklären.

 

Welche Lücke in welchen Service meinst du?

----------

## firefly

 *gruenschnabel wrote:*   

>  *firefly wrote:*   es muss sich ja nicht umbedingt um ein rootkit handeln, es kann auch sein, das jemand einfach über eine lücke in einem der laufenden services, einfach die Programme der coreutils (rm und co) überschrieben hat. 
> 
> Das würde zumindestens teilweise die speicherzugriffsfehler erklären. 
> 
> Welche Lücke in welchen Service meinst du?

 

Keine Ahnung, es ist nur eine Vermutung

----------

## hoschi

Sicher doch die Daten vom korrupten System und zieh es dann komplett neu hoch. Dann hast du wieder ein sauberes System und kannst dir in ruhe das korrumpierte System anschauen  :Smile: 

----------

## gimpel

 *gruenschnabel wrote:*   

> kennt einer von euch ein wirklich gutes tutorial "so mache ich meine gentoo-distrie sicher" ?
> 
> mir wäre sehr geholfen damit
> 
> danke

 

Guggst du hier: http://www.gentoo.org/proj/en/hardened/

----------

## Anarcho

 *mv wrote:*   

>  *Anarcho wrote:*   Also wenn dermassen viele Programme defekt sind kann es eigentlich nur an der glibc liegen. 
> 
> Nein, wenn er vom live-System auf die Platte chroot'en kann und dort dann keine Probleme hat, liegt es nicht an glibc. Höchstens am Kernel, aber wie sollte sich da plötzlich etwas verändern?

 

Nun, er hatte aber kein chroot vorher durchgeführt und wie er später schrieb ging es nach einem chroot auch nicht.

Daher hätte es durchaus auch an einer Lib liegen können.

----------

## Fauli

 *gruenschnabel wrote:*   

> ich denke das sie über ein exploit über drupal reingekommen sind

 

Das bedeutet dann aber auch, dass im Kernel noch eine Lücke ist, über die man als lokal angemeldeter Benutzer root-Rechte bekommen kann.

Oder das root-Passwort ist zu simpel.

----------

## Marlo

 *Anarcho wrote:*   

> 
> 
> Nun, er hatte aber kein chroot vorher durchgeführt und wie er später schrieb ging es nach einem chroot auch nicht.
> 
> Daher hätte es durchaus auch an einer Lib liegen können.

 

ich bin mit deiner Meinung bei dir Anarcho,

Es gibt weder im Linux noch in Drupal, Apache eine Sicherheitslücke, die das beschriebene Verhalten zeigt. Selbst wenn er das System voll auf 0777 fährt.  :Razz: 

Davon abgesehen wäre eine derart GROßE Sicherheitslücke, also ein WURM schleicht sich von Drupal über Apache/Tomcat(?), mit neinem zwischenzeitlichen "chown Angreifer:Angreifer /Home/registrierter/homeuser" in das /bin um dort "15 files" mit einem anderen Timestamp zu versehen? Tja, was er als "/Home/registrierter/homeuser" in /bin gar nicht kann, er müßte root sein. Der WURM müßte also mit root spielen können?

Danach löscht er seine Aktivitäten mit einem "chown root:root" und geht in die ewigen Jagdgründe ein. Ohne eine Spur zu hinterlassen?

NE,ne Mädels, so nich? Schaut doch mal rein ins /bin, was sieht man den da?

```

Verzeichnisse von Befehlen/Anwendungen die ALLEN Usern zugänglich sind:

    /bin/, /usr/bin/, /usr/local/bin/, /usr/X11R6/bin/, ..., /var/lib/

    /opt/Anwendung/...

```

Wer kann mir von euch jetzt erklären, warum ein geänderter Timestamp in /bin ein

 *Quote:*   

> daraufhin erhielt ich speicherzugriffsfehler 

  erzeugen sollte?

Also was soll der Zirkus?

Update your current toolchains und gut isses.

Grüße

MaLast edited by Marlo on Fri May 04, 2007 5:21 pm; edited 1 time in total

----------

## energyman76b

 *gruenschnabel wrote:*   

> anfangs hatte ich auch darauf getippt
> 
> CPU kann man glaube ich ausschliessen...da von der livecd ja alles tadellos funktioniert
> 
> Hitze....auch diese würde sich von der livecd bemerkbar machen aber ich hatte den rechner sogar ne halbe stunde aus und danach sollte er abgekühlt sein...die lüfter laufen alle und im serverschrank sind keine 20grad
> ...

 

Während des boots wird die root-Partition erstmal nur readonly gemounted. Das ist normal und hat NICHTS mit fs-Fehlern zu tun. Erst später werden die Partitionen rw gemounted. Und wenn init nicht anläuft, dann hast du halt nur readonly Partitionen.

Ich tippe auf: kernel. Du hast beim Kernelbacken was vergessen. Übrigens - warum genkernel?

EDIT: ich sollte alles lesen *seufz*

aber wenn du ein rootkit drauf hattest, gibt es wirklich nur einen Weg: Neuinstallation. Denn man kann nie wissen, was der Mensch noch so alles verbrochen hat.

----------

