Okay, das hilft dir aber nur bei Userland Rootkits. Du vergleichst also den Output von ps (ein Userland Tool) mit dem was der Kernel sag (/proc).
Nein, er sendet an jede mögliche PID 1-65535 ein Signal und schaut, ob er eine Antwort bekommt. Dann prüft er, ob es für Prozesse, die auf das Signal reagieren, passende proc-Informationen gibt. Ist dies nicht der Fall, ist der Prozess aus der Prozessliste ausgekoppelt und somit versteckt. Rootkits im Kernel-Space werden nicht als Prozesse umgesetzt. Sie laufen innerhalb eines Treiber/Modul-Kontext, sind also gänzlich anders anzugehen.
Speziell dieses Skript hat nur ein Problem... es zeigt auch versteckte Prozesse an, die garkeine sind und das vor allem auf Servern, auf denen Prozese laufen, die ständig neue Kindprozesse erzeugen und zerstören. Apache ist ein schönes Beispiel für einen solchen Prozess. Das liegt daran, dass das Skript nicht aus einem durchgehenden Prozess besteht, sondern aus verschiedenen Programm-Aufrufen. Beispiel:
Das Skript sendet an Prozess 1234 ein Signal mittels kill und "bekommt eine Antwort". Prozess 1234 ist ein Kindprozess, der gerade vom System aufgeräumt wird und auf seine Zerstörung wartet. Da der kill-Befehl abgearbeitet ist, kann der Kernel nun den Kindprozess zerstören, bevor das Skript die Infos aus /proc einlesen kann. Der Prozess 1234 wird also zerstört und dann bekommt das Skript wieder Rechenzeit vom Kernel zugeteilt, das nun mit ls und grep überprüft, ob es zu 1234 passende proc-Informationen gibt. Diese sind aber schon längst bei der Zerstörung des Kindprozesses entfernt worden, so dass das Skript einen vermeintlich versteckten Prozess anzeigt, der garkeiner ist.
Dieses Skript (das übrigens vom Debian-Projekt stammt, wenn ich mich recht entsinne), ist damit nur für Systeme geeignet, die keine Programme nutzen, von denen ständig neue Kindprozesse verwendet werden. Speziell auf mehr oder weniger stark frequentierten Webservern zeigt es dutzende bis hunderte von vermeintlichen versteckten Prozessen an. Tools wie chkrootkit sind da wesentlich besser geeignet um versteckte Prozesse zu finden.
Edit: Die information_schema ist eine Standard-DB von MySQL. Die provider ist vermutlich die Email-Datenbank von der Vorgänger-Version des Howtos
http://workaround.org/articles/ispmail-etch/index.html.de wo die DB noch 'provider' genannt wurde.
![[HaBo]](/styles/default/logoklein.png){kind=small}
