Hallo, einige haben sicher in c't 8/05 den Artikel über die ATA Festplatten Sicherung gelesen. Da ich leider einen Computer mit "dummen" Bios habe, möchte ich den c't hdparm in ein init Skript aufnehmen, um den Festplatten das freeze command zu schicken. Welches init Skript ist dafür am geeignetsten? Detlef
Detlef Grittner schrieb:
einige haben sicher in c't 8/05 den Artikel über die ATA Festplatten Sicherung gelesen.
Nö, die hab ich mir noch nicht gekauft..
Da ich leider einen Computer mit "dummen" Bios habe, möchte ich den c't hdparm in ein init Skript aufnehmen, um den Festplatten das freeze command zu schicken.
Ich weiß ja nicht genau, was dieser Freeze-Command soll, aber es wird wohl etwas wie hdparm -S<zahl> oder -y oder -Y sein, oder?
Welches init Skript ist dafür am geeignetsten?
Aus dem Wort init-Script schließe ich, dass du es beim booten ausführen willst? Also wahrscheinlich ist /etc/init.d/boot.local das, was du suchst. Du kannst auch einfach ein kleines Script S99 oder so in /etc/init.d/rc5.d anlegen... Wenn es eher um eine Einstellung von wegen DMA und so geht, würde ich raten, es in die /etc/sysconfig/ide einzutragen. hdparm-Einstellungen kann man mit der Option -k1 fixen, was aber evtl zu Problemen führen kann, wenn man mal eine Einstellung versemmelt.. Da würde ich noch eher etwas in die /etc/hdparm.conf eintragen ;-) Gruß Sören
on 06.04.2005 21:58 Sören Wengerowsky wrote:
Detlef Grittner schrieb:
einige haben sicher in c't 8/05 den Artikel über die ATA Festplatten Sicherung gelesen.
Nö, die hab ich mir noch nicht gekauft..
Brauchst du in dem Fall auch nicht, der Artikel ist bei heise online für die Ausgabe 8/05 zu lesen.
Ich weiß ja nicht genau, was dieser Freeze-Command soll, aber es wird wohl etwas wie hdparm -S<zahl> oder -y oder -Y sein, oder?
Ja genau, es ist ein neuer Parameter -F. Damit wird das Setzen von User- und Masterpasswort auf ATA Platten gesperrt. Da mein BIOS das nicht macht, könnte sonst irgendein böses Programm ein Zufallspasswort setzen und ich kann von der Platte beim nächsten Booten nichts mehr lesen.
Welches init Skript ist dafür am geeignetsten?
Aus dem Wort init-Script schließe ich, dass du es beim booten ausführen willst?
Ja unbedingt, so früh wie nur irgend möglich.
Also wahrscheinlich ist /etc/init.d/boot.local das, was du suchst. Du kannst auch einfach ein kleines Script S99 oder so in /etc/init.d/rc5.d anlegen...
Wenn es eher um eine Einstellung von wegen DMA und so geht, würde ich raten, es in die /etc/sysconfig/ide einzutragen.
Okay, aber wann ist der frühest mögliche Zeitpunkt ein Kommando mit hdparm abzusetzen?
hdparm-Einstellungen kann man mit der Option -k1 fixen, was aber evtl zu Problemen führen kann, wenn man mal eine Einstellung versemmelt.. Da würde ich noch eher etwas in die /etc/hdparm.conf eintragen ;-)
Wo finde ich etwas über das Format und den Inhalt dieser Datei. Auf meiner SuSE 9.2 finde ich sie nicht.
Gruß Sören
Gruß, Detlef
Detlef Grittner schrieb:
Brauchst du in dem Fall auch nicht, der Artikel ist bei heise online für die Ausgabe 8/05 zu lesen.
Ah.. Danke. Ich habe mir mal http://www.heise.de/ct/05/08/172/ und http://www.heise.de/ct/ftp/projekte/atasecurity/ durchgelesen. Das scheint ja echt ne bedeutsame Lücke zu sein. Danke für den Tipp.
Okay, aber wann ist der frühest mögliche Zeitpunkt ein Kommando mit hdparm abzusetzen?
Sag das doch ;). Das ist die initrd, aber das wurde ja schon gesagt.
hdparm-Einstellungen kann man mit der Option -k1 fixen, was aber evtl zu Problemen führen kann, wenn man mal eine Einstellung versemmelt.. Da würde ich noch eher etwas in die /etc/hdparm.conf eintragen ;-)
Wo finde ich etwas über das Format und den Inhalt dieser Datei. Auf meiner SuSE 9.2 finde ich sie nicht.
Die Datei benutzt man eigentlich sowieso eher bei anderen Distris.. Ich habe mal einfach meine hdparm-Optionen da hineingeschrieben, und es hatte funktioniert. Also in diesem Fall müsste eine Datei # hdparm.conf -F /dev/platte ausreichen. Das mit der initrd ist aber schon das Beste. Leider verwende ich keine. Und wegen dem einen Befehl mache ich auch keine... Ich habe jetzt die inittab genommen. Gruß Sören
Detlef Grittner
Da mein BIOS das nicht macht, könnte sonst irgendein böses Programm ein Zufallspasswort setzen und ich kann von der Platte beim nächsten Booten nichts mehr lesen.
Ich verstehe die Hysterie nicht. Irgendein böses Programm kann dir auch deine Platte oder zumindest wichtige Teile derselben mit Nullen vollschreiben, und nun? Ausserdem, wo soll denn das böse Programm herkommen? Wie kommt dieses Programm an Root-Rechte, damit es den ATA-Befehl abschicken kann? Wie willst du dich dagegen schützen, dass besagtes böses Programm nicht einfach erst einmal einen Reset der Platte durchführt, was dann die Verriegelung der Platte aufhebt? Ich finde, dass hier doch ein wenig zu viel Panik verbreitet wird. Philipp
Philipp Thomas schrieb: [..]
Wie willst du dich dagegen schützen, dass besagtes böses Programm nicht einfach erst einmal einen Reset der Platte durchführt, was dann die Verriegelung der Platte aufhebt?
Ich habe das so verstanden, als wäre dazu das Master-PW nötig, wenn man die Sicherheitsstufe Maximum gewählt hat: http://www.heise.de/ct/05/08/172/ ======= Bei „Maximum“ kommt man nur noch mit dem User-Passwort an die Daten heran. Wenn es verloren geht, kann der Administrator mit dem Master-Passwort die Platte nur noch unter Verlust aller Daten entsperren. Dazu dient das Kommando Security Erase: Es überschreibt alle Sektoren mit Nullen und gibt erst dann die Platte frei. =======
Ich finde, dass hier doch ein wenig zu viel Panik verbreitet wird.
Letzendlich ist es schon übertrieben, da ein derartig bösartiges Programm auch rm -rf / oder so ausführen könnte, wenn es root-rechte hat... Aber so eine Potenzielle Sicherheitslücke offen zu lassen, widerstrebt einem doch, oder? Gruß Sören
on 08.04.2005 01:25 Philipp Thomas wrote:
Ich verstehe die Hysterie nicht. Irgendein böses Programm kann dir auch deine Platte oder zumindest wichtige Teile derselben mit Nullen vollschreiben, und nun? Ausserdem, wo soll denn das böse Programm herkommen? Wie kommt dieses Programm an Root-Rechte, damit es den ATA-Befehl abschicken kann? Wie willst du dich dagegen schützen, dass besagtes böses Programm nicht einfach erst einmal einen Reset der Platte durchführt, was dann die Verriegelung der Platte aufhebt?
Soviele Fragen ;-)! Ich verweise einfach mal auf meinen Post http://lists.suse.com/archive/suse-linux/2005-Apr/0481.html Kurz gesagt, das Geniale an der Lücke ist, dass die Daten NICHT verloren gehen. Den für eine wirkungsvolle Sabotage und Erpressung nötigen Exploit mit einem COMRESET rein in Assembler zu schreiben, erscheint mir nicht ganz so trivial. Ohne die Resetsache ist das schon viel einfacher. Wie kommt das Programm an Rootrechte? Ein anderer Exploit oder ein vergiftetes rpm bzw. Sourcecode mit Trojaner. Mein Problem ist, dass ich dann die Platte ganz wegschmeißen kann, anstatt nur mein System neu aufzuspielen. Detlef
On Wednesday 06 April 2005 21:33, Detlef Grittner wrote:
Welches init Skript ist dafür am geeignetsten?
Am besten wohl linuxrc im initrd. Such mal in der Liste. Irgendwann im Herbst habe ich einen längeren Beitrag zum initrd geschrieben. Da findest Du alles nötige. Zweitbeste Lösung wäre /etc/inittab. Da aber Rootkits oft /sbin/init patchen, solltest Du etwas nehmen, das vor dem Mounten des Root-FS läuft. Torsten
Hallo, Torsten Foertsch wrote:
On Wednesday 06 April 2005 21:33, Detlef Grittner wrote:
Welches init Skript ist dafür am geeignetsten?
Am besten wohl linuxrc im initrd. Such mal in der Liste. Irgendwann im Herbst habe ich einen längeren Beitrag zum initrd geschrieben. Da findest Du alles nötige.
Hervorragende Idee! Da wär' ich auch gerne drauf gekommen. Geht natürlich nur, wenn man mit iniutrd bootet, aber welches aktuelle SuSE tut das nicht?
Zweitbeste Lösung wäre /etc/inittab. Da aber Rootkits oft /sbin/init patchen, solltest Du etwas nehmen, das vor dem Mounten des Root-FS läuft.
Äh. Ich hab' zwar noch nie ein Rootkit seziert, aber werden die nicht gut daran tun, die inittab korrekt auszuwerten? Arno
Torsten
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
On Wednesday 06 April 2005 22:33, Arno Lehmann wrote:
Äh. Ich hab' zwar noch nie ein Rootkit seziert
Ich hatte mal das Vergnügen einen gehackten Rechner auseinander zu nehmen. Damals lief dort ein 2.2.16 oder sowas. Der Hacker hatte so ca. 6 unterschiedliche Tools installiert, davon eins zum Mitschneiden der Tastatureingaben und eben SuckIT oder so, der sich an /sbin/init klebt. Konkret, er benennt /sbin/init nach /sbin/init.X11 oder so um und installiert ein Programm, dass der Rootkit startet und dann /sbin/init.X11 ausführt. Letztlich ist es mir gelungen, den Gutsten zu finden, mit E-mail, Name, Hausanschrift und Telefon. Daher besser initrd. Torsten
Ich habe deinen Beitrag auf http://lists.suse.com/archive/suse-linux/2005-Feb/2956.html gefunden. Das hat auf Anhieb funktioniert, das hdparm -F script da einzubauen. Danke Dir! Jetzt habe ich ein eigentlich total unwichtiges Detail: Nachdem ich den geänderten initrd nach boot kopiert habe, erscheint nicht mehr der grafische Novell/Suse Screen, sondern der normale Linux Text Screen beim Booten. Wieso ist das passiert und kann man da wieder den grafischen Schnickschnack aktivieren? Detlef
Hallöle, Detlef Grittner wrote:
Hallo,
einige haben sicher in c't 8/05 den Artikel über die ATA Festplatten Sicherung gelesen. Da ich leider einen Computer mit "dummen" Bios habe, möchte ich den c't hdparm in ein init Skript aufnehmen, um den Festplatten das freeze command zu schicken.
Welches init Skript ist dafür am geeignetsten?
Da sehe ich zwei sinnvolle Möglichkeiten. Vorweg: Sowas sollte man in _kein_ existierendes Script aufnehmen, das evtl. bei einer Aktualisierung verändert wird. Daher Möglichkeit 1: boot.local o.ä. Wird bei SuSE direkt nach den lebenswichtigen Komponenen und vor den Runlevel-Scripts ausgeführt. Bei SuSE 9.2, vermutlich auch anderen Versionen: /etc/init.d/README enthält einige nützliche Hinweise... Arno
Detlef
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
On Wednesday 06 April 2005 21:33, Detlef Grittner wrote: Hallo,
einige haben sicher in c't 8/05 den Artikel über die ATA Festplatten Sicherung gelesen. Da ich leider einen Computer mit "dummen" Bios habe, möchte ich den c't hdparm in ein init Skript aufnehmen, um den Festplatten das freeze command zu schicken.
Ah, das ist doch die von der c't gepatchte hdparm Version? Hast du dir die schon genauer angeschaut? Sperrt dir nur die Passwortvergabe oder kann man damit auch selbst eins setzen? Gruß Malte
Hallo, man kann damit nur das Setzen von Passwörtern sperren, d.h. freeze aktivieren. Ist auch sinnvoll, wenn das Bios die ATA Security nicht kennt, sonst kann man beim Booten das Userpasswort ja nicht eingeben. Detlef
On Wednesday 06 April 2005 23:43, Detlef Grittner wrote:
man kann damit nur das Setzen von Passwörtern sperren, d.h. freeze aktivieren.
Okay, danke für die Info. Dann ist das gepatchte hdparm sinnlos... Im Heise Forum hat jemand, der die ATA Specs wohl gut kennt beschrieben, wie man trotz freeze immer noch ein KW setzen könnte... Fazit: nur selbst ein KW setzen hilft. Hoffentlich kommt das noch in hdparm. S.: http://www.heise.de/security/news/foren/go.shtml?read=1&msg_id=7727143&forum_id=76371 Gruß Malte
on 07.04.2005 00:49 Malte Gell wrote:
..... Okay, danke für die Info. Dann ist das gepatchte hdparm sinnlos... Im Heise Forum hat jemand, der die ATA Specs wohl gut kennt beschrieben, wie man trotz freeze immer noch ein KW setzen könnte... Fazit: nur selbst ein KW setzen hilft. Hoffentlich kommt das noch in hdparm.
... Gruß Malte
Also, ganz so trivial ist es nicht einen COMRESET an die SATA Platte abzusetzen und anschließend auch noch ein Passwort zu setzen. Ganz zu schweigen ein bestimmtes Passwort zu setzen, dass nicht so leicht im Code zu finden ist und welches der Cracker kennt. Richtig Spass macht die Sabotage doch nur, wenn man anschließend eine betroffene Firma erpressen kann. Kollateralschäden bei ein paar Privatanwendern in Kauf genommen. Gegen das Crackerfußvolk dagegen sollte man wohl doch wenigstens dieses hdparm verwenden. Detlef
participants (6)
-
Arno Lehmann -
Detlef Grittner -
Malte Gell -
Philipp Thomas -
Sören Wengerowsky -
Torsten Foertsch