Server-Hardware: EIDE-Pin 23 unterbrechen?

[Bio]

Sup!

<prolog>
Gestern habe ich irgendwie meine httpd.conf geschrottet. Das heisst, ich denke, dass ich sie geschrottet habe. Es koennte natuerlich auch sein, dass ein sehr bloeder Hacker die ganzen "allow override all" an allen moeglichen Stellen der httpd.conf verteilt hat. Ich denke allerdings eher, dass es das "nette" SuSE_Config gewesen ist, das wohl nicht so ganz mit meiner Konfiguration klargekommen ist, als ich das SSL-Modul irgendwie nachtraeglich aktivieren wollte (was irgendwie nicht ganz trivial war...).
</prolog>

Wie auch immer, ich habe jetzt ganz doll Angst bekommen, und dachte, ich koennte doch eigentlich die gesamten Systemprogramme auf eine Platte packen, und /var und /home auf einer andere Platte mounten.
Die System-Platte würde ich dann einfach  mit einem speziell modifizierten EIDE-Kabel anschliessen, bei dem einfach der Pin 23 für IOW abschaltbar wäre - jeglicher Hackerangriff bei deaktiviertem Pin 23 wäre dann ziemlich lächerlich, weil ein Reboot jeden denkbaren Schaden rückgängig machen würde, und jeder Versuch, irgendwelche Root-Kits zu installieren, fulminant fehlschlagen sollte. Okay, im laufenden System könnte man evtl. sonstwas anstellen, aber das wäre ja nur halb so schlimm.

Tja, ist das wirklich so eine gute Idee, oder geht das nicht? Wie kann man einen EIDE-Pin unterbrechen - reicht "nicht reinstecken" oder kann man den PIN auf GND ziehen... und vor allem, gibt es irgendeine trickige Schaltung, mit der man das eleganter machen könnte als mit einem Schalter? Ich bin mir nicht sicher, ob "Schalter" bei neueren DMA-Verfahren wirklich tragbar wären, wer weiss, was aus dem Signal wird, wenn man einfach einen Schalter in die Leitungsbahn einbaut.

Tja... irgendwelche Kommunikationselektroniker unter uns, die mir einen ultimativen Tipp geben können?

Gruesse,

Bio

[Henryk Plötz]

Moin

Ich bin eher gegen solche hardwaremäßigen Lösungen. Was spricht denn bitteschön gegen ein read-only mounten? a) müsste der böse Hacker root sein um das zu ändern (naja, er könnte ja dein KDE manipulieren *eg*), und dann wär eh alles zu spät und b) könnte er das Ding doch sowieso nicht unmounten um es wieder read-write zu mounten, wenn die Platte noch benutzt wird, er müsste also zunächst mal das System runterfahren.

--
Henryk Plötz
Grüße aus Berlin

[Bio]

Moin

Ich bin eher gegen solche hardwaremäßigen Lösungen. Was spricht denn bitteschön gegen ein read-only mounten? a) müsste der böse Hacker root sein um das zu ändern (naja, er könnte ja dein KDE manipulieren *eg*)

Na, wenn der Hacker erstmal drin ist, dann wird er wohl auch irgendwie root werden...

und dann wär eh alles zu spät und b) könnte er das Ding doch sowieso nicht unmounten um es wieder read-write zu mounten, wenn die Platte noch benutzt wird, er müsste also zunächst mal das System runterfahren.

Bist Du sicher, daß er nicht ein komplettes System auf der nicht-geschützten Platte aufspielen, chroot machen, die original-Root-Partition unmounten, dann das device neu anlegen und neu mounten könnte? So Hardware-Lösungen sind viel endgültiger, und ich möchte was endgültiges, weil ich einfach keinen Bock habe, jeden Tag neue sendmail-Patches einzuspielen etc. ;-)

Gruesse,

Bio

[Christian Kruse]

Hoi,

b) könnte er das Ding doch sowieso nicht unmounten um es wieder
read-write zu mounten, wenn die Platte noch benutzt wird, er müsste
also zunächst mal das System runterfahren.

Das ist Quatsch. Natuerlich kann er das Device als root im
Read-Write-Modus remounten. Stichwort: mount -u, mount -aF (oder so
aehnlich)

Gruesse,
 CK

[Henryk Plötz]

Moin

Das ist Quatsch. Natuerlich kann er das Device als root im
Read-Write-Modus remounten. Stichwort: mount -u, mount -aF (oder so
aehnlich)

Hmm, hast natürlich Recht. Du meintest wohl mount -o remount,rw ?

PS: Mein mount kennt kein -u und -aF ist dafür da alle Einträge in fstab (mit den dort angegebenen Optionen, also gegebenenfall -o ro) parallel zu mounten.

--
Henryk Plötz
Grüße aus Berlin

[Christian Kruse]

Hoi,

Das ist Quatsch. Natuerlich kann er das Device als root im
Read-Write-Modus remounten. Stichwort: mount -u, mount -aF (oder so
aehnlich)

Hmm, hast natürlich Recht. Du meintest wohl mount -o remount,rw ?

Keine Ahnung, wie das bei Linux heisst ;-) Kann also durchaus sein,
dass es da so heisst.

PS: Mein mount kennt kein -u und -aF ist dafür da alle Einträge in
fstab (mit den dort angegebenen Optionen, also gegebenenfall -o ro)
parallel zu mounten.

Ich kenn nur das FreeBSD-Mount auswendig. Bei Linux muss ich immer in
die Manpage schauen.

Gruesse,
 CK

[Martin]

Tag Bio,

deine Software-Kenntnisse in allen Ehren, aber bei der Hardware hast du scheinbar noch Defizite.

Die System-Platte würde ich dann einfach  mit einem speziell modifizierten EIDE-Kabel anschliessen, bei dem einfach der Pin 23 für IOW abschaltbar wäre - jeglicher Hackerangriff bei deaktiviertem Pin 23 wäre dann ziemlich lächerlich, weil ein Reboot jeden denkbaren Schaden rückgängig machen würde, und jeder Versuch, irgendwelche Root-Kits zu installieren, fulminant fehlschlagen sollte. Okay, im laufenden System könnte man evtl. sonstwas anstellen, aber das wäre ja nur halb so schlimm.

Was noch viel schlimmer ist: Die Platte wäre nicht nur schreibgeschützt, sondern auch lesegeschützt *g*. Weil die IOW-Leitung nämlich nicht mit Schreibzugriffen auf das Medium gleichzusetzen ist, sondern allgemein mit dem "Schreiben zum Controller". Jede Übergabe eines Befehls an das (E)IDE-Gerät ist - hardwaremäßig gesehen - zunächst ein Schreibzugriff.
Das wäre also ein Satz mit X.
Aber tröste dich: Die Idee hatte ich vor vielen Jahren, als DOS noch "state of the art" war, auch schon, und ich hab's ganz naiv probiert und erst hinterher nachgedacht.

Bleibt also nur eine Softwarelösung, und das heißt wohl, in den Tiefen des zuständigen Treibers rumzufummeln. Für Windows hätte ich sowas wohl auch gern...

Gruß,

Martin

[Bio]

Sup!

Bleibt also nur eine Softwarelösung, und das heißt wohl, in den Tiefen des zuständigen Treibers rumzufummeln. Für Windows hätte ich sowas wohl auch gern...

Das könnte man natürlich machen, zumindest die nicht ganz engagierten Hacker könnte das evtl. aufhalten. Ich werd' mal schauen - prinzipiell ist es nicht sehr schwer, so einen Treiber lahmzulegen - ein undokumentierter IOCTL-Aufruf, und die Platte könnte nicht mehr beschrieben werden... da muß der Hacker erstmal drauf kommen (Mounten mit "immutable" etc. gibt es schon, aber das kann man auch immer wieder ausschalten - ein Treiber, der standardmaessig "nur lesen" eingestellt hat und nur per IOCTL wieder schreiben kann, ist nicht so standard...)

Na, mal sehen...

Gruesse,

Bio

[Martin]

Sup, Super, am Supsten!??

Na, mal sehen...

Viel Erfolg dabei (nein, das war jetzt nicht ironisch gemeint). Wenn du eine Lösung findest, die sinngemäß auch auf Windoof anwendbar ist, würde sie mich auch brennend interessieren. Ich hab's eben nicht so mit den Betriebssystemen mit X, bin eher bekennender Windows-Insider (und MEIN Windows 98 läuft seit Ewigkeiten stabil).
Für DOS hatte ich damals wirklich den Write-Protect-Driver realisiert, aber an richtige Win32-Treiber habe ich mich bis jetzt noch nicht rangetraut. Schön wäre natürlich ein Filesystem-Treiber, der einen Schreibschutz auf Verzeichnisebene realisieren würde...

Ciao,

Martin

[Bio]

Sup!

Wenn M$ seine Treiber dokumentieren und evtl. den Quellcode rausgeben würde, wäre das sicher kein Problem - aber wenn man den Treiber "hackt", macht man sich dann nicht evtl. strafbar etc.?

Gruesse,

Bio

[Martin]

Wenn M$ seine Treiber dokumentieren und evtl. den Quellcode rausgeben würde...

Und was träumst du *nachts* ?  <SCNR>

aber wenn man den Treiber "hackt", macht man sich dann nicht evtl. strafbar etc.?

Who cares? Solange ich das auf meinem eigenen Rechner mache, das Ergebnis nicht veröffentliche und keiner davon weiß?

Grüße aus dem Schwobaländle,

Martin

[Carsten]

Hallo Bio!

Die System-Platte würde ich dann einfach  mit einem speziell modifizierten EIDE-Kabel anschliessen, bei dem einfach der Pin 23 für IOW abschaltbar wäre

Tja, dann kann dein System _nichts_ mehr an die Platte senden - auch keine Befehle zum lesen.

Ohne (nichttriviale) 'mitlesende' Elektronik, die das Signal nur fallweise unterbricht, ist da nix zu machen.

Gruss,
 Carsten

[Bio]

Sup!

Tja, dann kann dein System _nichts_ mehr an die Platte senden - auch keine Befehle zum lesen.

Tja - da bräuchte man dann ein paar sehr sehr schnelle Logikbausteine - und was der Treiber macht, wenn er nicht mehr lesen kann, wäre evtl. auch nicht das, was man gern hätte.

Aber wenn ich mal zuviel Geld habe, dann bastele ich sowas, wäre doch praktisch, wenn es das gäbe ;-)

Gruesse,

Bio

[Michael Schröpl]

Hi Bio,

Es koennte natuerlich auch sein, dass ein sehr bloeder Hacker die
ganzen "allow override all" an allen moeglichen Stellen der httpd.conf
verteilt hat.

Was ist daran "schlimm"?
Wer außer Dir legt auf Deiner Maschine denn .htaccess-Dateien an?
(Nein, es ist natürlich weder schön noch performant ...)

Ich denke allerdings eher, dass es das "nette" SuSE_Config
gewesen ist, das wohl nicht so ganz mit meiner Konfiguration
klargekommen ist, als ich das SSL-Modul irgendwie nachtraeglich
aktivieren wollte (was irgendwie nicht ganz trivial war...).

Ähem, der Herr Ritter betreiben also Apache-Konfiguration auf Frontpage-
Niveau? Naja, dann herrliches Beinkleid ...

Viele Grüße
      Michael

[Bio]

Sup!

Ähem, der Herr Ritter betreiben also Apache-Konfiguration auf Frontpage-
Niveau? Naja, dann herrliches Beinkleid ...

Ah - welch' übler Anwurf!

Ich bezweifle zwar, daß "Apache-Konfiguration auf Frontpage-Niveau" denkbar ist, aber ich muss einräumen, daß die Methode von SuSE zur Apache-Konfiguration... verbesserungswuerdig erscheint und daß ich keine besonders großartigen Kenntnisse in Apache-Konfiguration habe.

Was die allow_override all Dingens angeht, so wundert es mich zumindest, wer, wenn nicht ich, die dahin gemacht haben soll... es sei denn, irgendein SuSE Script läuft im Fall von veränderten httpd.conf's Amok ;-)

Gruesse,

Bio

[Michael Schröpl]

Hi Bio,

Ich bezweifle zwar, daß "Apache-Konfiguration auf Frontpage-Niveau"
denkbar ist

aber klar doch. Es gibt alles, was ein krankes Hirn sich vorstellen kann.

Ich habe vor längerer Zeit mal irgendwo im Web ein GUI zur Apache-
Konfiguration gesehen und testinstalliert.
Das Ding könnte vielleicht ein Viertel dessen, was mit Apache möglich ist.
Und das Schlimmste: Es löscht alle Kommentare aus der httpd.conf, weil in
seiner Klicki-Bunti-Denkweise für so etwas kein Platz in den Datenstrukturen
war ...

Viele Grüße
      Michael

[Bio]

Sup!

Jetzt weiss ich es ;-)

Also: Wenn die Adress-Bits 0,1 und 2 auf high liegen (33,35,36)
und der Command-Code E8, CA,CB,32,33,C5,E9,30,31 oder 3C kommt, dann muss dieser geblockt werden ;-)

Die dafür benötigten Logikbausteine muessen in unter 7.5 Nanosekunden schalten, wenn man ein Ultra-ATA 133 Device voraussetzt - bei dem alten 33 MHz Controller sind imerhin 30 Nanosekunden Schaltzeit drin... Woher kriege ich ICs mit Nanosekunden Schaltzeit ;-)

Fragt sich nur, was die Harddisk macht, wenn nach dem weggefilterten Signal Daten ankommen und das Device keine Ahnung hat, was es damit machen soll ;-)

Gruesse,

Bio

[Carsten]

Hallo Bio!

[...] Woher kriege ich ICs mit Nanosekunden Schaltzeit ;-)

Kein Problem:

http://www.latticesemi.com/products/cpld/ispMACH4A/ispMACH4A5/index.cfm
Entwicklungssoftware dazu gibts für 3Monate zum Testen, Programmier-Hardware besteht aus ein oder zwei Standard TTL-Chips am Printer-Port.

Die Kommandoübertragung findet afaik noch nicht einmal mit dem ULTRA-DMA Speed statt, selbige mit Hilfe eines entsprechend programmierten Chips zu sabotieren sollte klappen, vermutlich wäre es sogar möglich das so anzulegen das selbst die Windows-Treiber nicht dabei abstürzen oder hängenbleiben.

Dafür dürfte das Anbringen überhaupt irgendwelcher Chipeingänge oder schlimmer noch eines (Zwischen)Steckverbinders im Kabel für die bis aufs letzte ausgequetsche Signalübertragung das Ende bedeuten.

Gruss,
 Carsten

[Bio]

Sup!

http://www.latticesemi.com/products/cpld/ispMACH4A/ispMACH4A5/index.cfm
Entwicklungssoftware dazu gibts für 3Monate zum Testen, Programmier-Hardware besteht aus ein oder zwei Standard TTL-Chips am Printer-Port.

Och, kein Problem, in der Uni gibt's 'ne Vollversion ;-)

Die Kommandoübertragung findet afaik noch nicht einmal mit dem ULTRA-DMA Speed statt, selbige mit Hilfe eines entsprechend programmierten Chips zu sabotieren sollte klappen, vermutlich wäre es sogar möglich das so anzulegen das selbst die Windows-Treiber nicht dabei abstürzen oder hängenbleiben.

Dafür dürfte das Anbringen überhaupt irgendwelcher Chipeingänge oder schlimmer noch eines (Zwischen)Steckverbinders im Kabel für die bis aufs letzte ausgequetsche Signalübertragung das Ende bedeuten.

*murmel* Aktiver Treiberbaustein *murmel* Kabelmaximallänge auf 2 cm verkürzen *murmel* Übertragung auf DMA 33 runtersetzen *murmel*

Also, die Festplatte, auf der die Systemprogramme liegen, muss eh' nicht mit DMA 100 laufen, denke ich ;-)

Trotzdem scheint mir die Realisierung dieses Projektes im Moment unrealistisch...

Gruesse,

Bio

[Henryk Plötz]

Moin

Tja... irgendwelche Kommunikationselektroniker unter uns, die mir einen ultimativen Tipp geben können?

Wie wäre es mit Plan B) Brenn dir die Partition auf CD-R und steck sie in ein CD-Laufwerk. Wenn $BÖSER_HACKER das CD-Laufwerk zum Brenner umfunktionieren kann, dann ist er gut :)

--
Henryk Plötz
Grüße aus Berlin

[Bio]

Sup!

Tja... irgendwelche Kommunikationselektroniker unter uns, die mir einen ultimativen Tipp geben können?

Wie wäre es mit Plan B) Brenn dir die Partition auf CD-R und steck sie in ein CD-Laufwerk. Wenn $BÖSER_HACKER das CD-Laufwerk zum Brenner umfunktionieren kann, dann ist er gut :)

Tja, wenn "sehr-altes-CD-Rom-Laufwerk" meine CD-RWs lesen kann und alle wichtigen Programme und Config-Dateien und der Kernel auf eine CD-RW passen, dann werde ich das evtl. machen - aber so mit Hardware-Dingens wäre es noch viel viel schöner gewesen. Du weisst doch, alle genialen Ideen entstehen aus Faulheit ;-)

Gruesse,

Bio