Debian 4 Etch USB Ports deaktivieren

MaDoo

New Member
Hallo,
ich möchte gerne auf meinem dedicated Server die USB Ports im OS deaktivieren, so dass Debian überhaupt nicht auf USB Geräte reagiert und sie auch nicht mounted sowie ausführt. Hat da jemand mal nen Tipp für mich wie ich das mache?
 
WTF?! Ich habe geschrieben, dass ich einen dedicated Server habe, der IWO im RZ steht, da kann ich nicht einfach mal so hinfahren und dort am BIOS rumspielen ;-) Muss schon ne Lösung für OS sein.
Kann man iwie den USB Prozess beenden oder die treiber rausschmeissen?
 
Als Hardcore-Lösung könntest Du /lib/modules/`uname -r`/kernel/drivers/usb/host/*-hcd.ko löschen oder zumindest in ein anders Verzeichnis verschieben, das nicht unterhalb der /lib/modules-Hierarchie liegt (nach dem nächsten Kernelupdate sind sie allerdings wieder da...).

Andererseits stelle ich mir die Frage, wozu? Zum einen werden im RZ nicht einfach irgendwelche USB-Geräte eingesteckt, zum anderen ist das Einzige, das normalerweise beim Einstecken geschieht, dass der Treiber automatisch geladen wird. Gestartet wird dabei nichts automatisch.
Falls irgendwelche Debian-spezifischen Automounter-Scripte ablaufen, solltest Du bei denen die Konfiguration entsprechend anpassen.
 
WTF?! Ich habe geschrieben, dass ich einen dedicated Server habe, der IWO im RZ steht, da kann ich nicht einfach mal so hinfahren und dort am BIOS rumspielen ;-) Muss schon ne Lösung für OS sein.
Und? Es gibt ne ganze Reihe an Hostern die Remote-Management-Lösungen anbieten. ;) DRAC, eRIC etc. sind hier die richtigen Begriffe, damit kannst du auch im BIOS rumpfuschen. ;) Und da du nicht gesagt hast, dass du keinen Zugriff aufs BIOS hast, war absehbar, dass solche Antworten kommen. :D
 
Öh wtf? Aktiviert Debian die USB-Anschlüsse, wenn kein Passwort gesetzt is?! :eek: Fänd ich mal extrem schräg! :D

Nein. Aber da es ja sicher darum geht, dass kein unbefugter Zugriff auf die Kiste stattfindet, sollen die deaktivierten USB Port ja nicht einfach so wieder aktiviert werden, oder?
 
Nein. Aber da es ja sicher darum geht, dass kein unbefugter Zugriff auf die Kiste stattfindet, sollen die deaktivierten USB Port ja nicht einfach so wieder aktiviert werden, oder?
Wo steht bei ihm was von unbefugt? :eek:

Wenn man die Ports wieder aktiviert werden sollen, dann müsste derjenige ja sicher den Server rebooten und das würde man recht schnell merken. ;) Generell kommt ja auch niemand in nen RZ, wenn er kein Mitarbeiter ist, von daher würde ich diesen Grund von vornherein mal ausschließen. ;)
Wenn doch jemand reinkommt hat er eh physikalischen Zugriff auf die Kiste, ob USB dann an oder aus is, dürfte relativ wurscht sein. :D
 
Wenn man davor steht braucht man auch kein USB mehr da tuts der richtige Bootparameter schon ^^
 
Okay... Habe die Hardcore Variante angewandt und die Daeien /lib/modules/`uname -r`/kernel/drivers/usb/host/*-hcd.ko entfenrt. muss ich rebooten?
Gibts noch andere Varianten? Am liebsten hätte ich so ein Programm, was den kompletten Server runterfährt bzw ieinen Befhel ausführt, sobald IWAS angeschlossen wird. (USB, CD, kA).
 
Und was bringt dir das? Wenn jemand vor deinem Server steht schaltet er den wieder ein und fügt ein paar Bootparameter in Grub oder Lilo ein und hat direkt ne root shell ;)
 
Gibts noch andere Varianten? Am liebsten hätte ich so ein Programm, was den kompletten Server runterfährt bzw ieinen Befhel ausführt, sobald IWAS angeschlossen wird. (USB, CD, kA).

Verwegene Idee: die USB-Devices im Hotplugger nicht deaktivieren, sondern mit einem Script ein "shutdown -h" ausführen.
Dann brauchst Du aber zumindestens die Kernel-Module für das Host-Interface und den Root-Hub, sonst kriegst Du das Anstecken gar nicht mit.
 
Wenn jemand vor deinem Server steht schaltet er den wieder ein und fügt ein paar Bootparameter in Grub oder Lilo ein und hat direkt ne root shell ;)

Der Bootmanager läßt sich per Paßwort schützen.

Mit etwas Mut schafft man das auch im BIOS.
/dev/nvram auslesen, auf einem bauähnlichen Board editieren (es geht nur um die Checksummen) und zurückspielen.

Und falls dann nix mehr geht, schonmal ein unschuldiges Gesicht üben und den Satz "Ich hab nix gemacht" :D:D:D
 
Vielleicht sollte er nen Boot Passwort setzen :D Achso das kann er ja ohne Remoteconsole garnet eingeben naja Pech ;)
 
Darf man mal fragen, wofür der ganze Aufwand eigentlich gut sein soll?

Wenn dass ne Zugriffsparanoia is, dann würd ich die festplatten noch mit treucrypt verschlüsseln, ansonsten hat das ganze nur wenig Sinn. Dürfte aber ohne Remote Management dann auch schwer werden davon zu booten, so ohne Passworteingabe. Läuft also doch darauf hinaus, dass es keinen Sinn hat. :D
 
Ein Bootpasswort dürfte auch niemanden abhalten, wenn er physischen Zugang zum Server hat. ;)
Ob er nun ein Bootloader auf USB Stick mitbringt, ein Live System bootet oder die Platten rauszieht und woanders mountet macht dann auch keinen Unterschied mehr. ;)

Ich hab aber das Gefühl unserem MaDoo geht es weniger um das booten als solches, sondern viel eher um das Vernichten von Daten in einer Ram Disk. ;)
 
Derartige Anforderungen sind gar nicht soweit hergeholt, das gibt es z.B. im buchhalterischen oder im medizinischen Bereich.

Natürlich muß der Server erstmal ein Rumpfsystem (ohne Mandanten- bzw. Patientendatenbank) booten, bis ein Berechtigter das System manuell entsperrt.

Ich empfehle die Lektüre der einschlägigen Datenschutzgesetze, soetwas ist z.B. für Arztpraxen Auflage.

Und sooo oft bootet ein Server ja auch nicht ungeplant mitten in der Nacht...
 
Dann stellt man den Server aber nicht in ein RZ in dem man nicht mal Zugriff auf eine Remoteconsole hat.
 
CentY said:
Und was bringt dir das?


Der Gedanke, dass ein Shutdown etwas bringt, ist in soweit sinnvoll, als dass man ja seine Festplatten mit Truecrypt o.ä. verschlüsselt haben kann. Die werden dann auto-dismounted und keiner kann sie mehr lesen.
 
Kann er ja eben nicht haben, da er die Kiste dann nicht mehr booten kann. Da er ja KEINE Remoteconsole hat.
 
Back
Top