'root or not root' per wget und HTTP

Hallo,

mal wieder eine aeusserst spartanische Umgebung: auf der einen Seite habe ich einen recht einfach Webserver, der eigentlich nur HTTP kann, aber ich koennte ihn noch etwas aufbohren, wozu ich aber grundsaetzlich zu faul bin; auf der anderen Seite ein Standard GNU wget. Mehr nicht, das ist alles, was ich zum Datenaustausch hab, kein HTTPS, keinen sicheren Uebertragungskanal, kein gpg. Und jetzt muss ich auf der einen Seite sicherstellen, dass der, der das wget auf der anderen Seite bedient, wirklich root ist und nicht irgendein dahergelaufener User, der gut im URLs raten ist.

Wie immer gilt: weniger ist mehr. Ich muesste auf der anderen Seite etwas tun, was nur root kann und ich auf der anderen Seite tracken kann. Sehr elegant waere z.B. ein src port

Hallo Frank,

Hat da jemand eine huebsche Idee?

Huebsch? Nein, aber vielleicht ein Denkanstoss:

Du koenntest in irgendeinem Webformular irgendwelche kryptischen Codes + die IP-Adresse, von wo das wget aufgerufen wird, eingeben, worauf eine bestimmte Zeit lang die Uebertragung Deiner Geheimdaten fuer diese IP freigeschalten wird.

Nicht hundertprozentig sicher, aber wer vermutet in einem Anmeldeformular fuer einen Newsletter schon einen Geheimzugang?

HTH,
Puersti

Du koenntest in irgendeinem Webformular irgendwelche
kryptischen Codes + die IP-Adresse, von wo das wget aufgerufen
wird, eingeben, worauf eine bestimmte Zeit lang die
Uebertragung Deiner Geheimdaten fuer diese IP freigeschalten
wird.

Ich kann nicht vorhersehen, wann die Abfrage kommt.

Gruss vom Frank.

Wie immer gilt: weniger ist mehr. Ich muesste auf der anderen
Seite etwas tun, was nur root kann und ich auf der anderen
Seite tracken kann. Sehr elegant waere z.B. ein src port

Wie immer gilt: weniger ist mehr. Ich muesste auf der anderen
Seite etwas tun, was nur root kann und ich auf der anderen
Seite tracken kann. Sehr elegant waere z.B. ein src port

Hallo Frank,

Du koenntest in irgendeinem Webformular irgendwelche
kryptischen Codes + die IP-Adresse, von wo das wget aufgerufen
wird, eingeben, worauf eine bestimmte Zeit lang die
Uebertragung Deiner Geheimdaten fuer diese IP freigeschalten
wird.

Ich kann nicht vorhersehen, wann die Abfrage kommt.

??? Du wirst doch wissen, ob Du in den naechsten 10 Minuten was runterladen willst, oder? Irgendwie stehe ich gerade auf dem Schlauch…

Puersti

Wenn du wie du erwähnt hast den Webserver modifizieren kannst,
könntest du ein einfaches Challege/Response-Verfahren oder
eine Art TAN-Liste implementieren, zB als Erweiterung vom HTTP
Auth-Mechanismus. Dabei braucht der zugreifende Benutzer aber
auf jede Fall irgendeinen geheimen Datenfetzen,

… kein geheimer Uebertragungskanal…

Wenn du weisst, dass niemand die Verbindung abhören kann,

Die Verbindung ist sicher: abhoeren koennen i.A. nur roots.

Wenn nur Leute abhören können, die sowieso genug Schaden anrichten können, dann kannst du den Kanal auch gleich als sicher betrachten.

dann könntest du als „Cookie“ von Seite des benutzers einen
Referrer schicken (das kann wget von Haus aus), und den vom
Webserver als zusätzliches Passwort verwenden lassen.

Allerdings ist selbst die Art, _wie_ das wget auf der anderen
Seite aufgerufen wird schon bekannt (weil es einfach auch vom
server kommt). Wie gesagt: kein sicherer Uebertragungskanal.

Das ist dann endgültig doof. Dann kannst du nur noch nach IP-Adresse filtern und beten. HTTP gibt in der Hinsicht einfach nichts her.

Mehr fällt mir aber auch nicht ein. Wenn du Spass haben willst
kannst du ja in den Referrer einen kleinen kryptographischen
Gag einbauen, wie zB den MD5 von einem festen String plus dem
aktuellen Tag im Jahr (könnte halt um Mitternacht rum
schiefgehen), und das dann auf dem Server verifizieren. MD5
ist nicht das große Monster was die Implementierung angeht.

Ja, aber das waere dann wirklich ein Gag, weil eben auch
Nutzer MD5 sums berechnen koennen.

Aber die kennen eben nicht einen ggf. geheimen String, der zB in einer Textdatei in ~root mit Modus 0600 liegt, und können nach dem was du sagst auch nicht einfach mal den Referrer abfangen. Insofern wäre schon ein einfaches, unverschlüsseltes Secret im Referrer-Header hinreichend sicher.

Hi,

Ich kann nicht vorhersehen, wann die Abfrage kommt.

??? Du wirst doch wissen, ob Du in den naechsten 10 Minuten
was runterladen willst, oder?

Ich? Nein, user tut das. Den kenn ich doch nicht.

Irgendwie stehe ich gerade auf dem Schlauch…

Weiss nicht.

Gruss vom Frank.

Wenn du weisst, dass niemand die Verbindung abhören kann,

Die Verbindung ist sicher: abhoeren koennen i.A. nur roots.

Wenn nur Leute abhören können, die sowieso genug Schaden
anrichten können, dann kannst du den Kanal auch gleich als
sicher betrachten.

Eigentlich schon, aber saemtliche Informationen, um den Kanal zu etablieren, sollen per HTTP rausgereicht werden.

dann könntest du als „Cookie“ von Seite des benutzers einen
Referrer schicken (das kann wget von Haus aus), und den vom
Webserver als zusätzliches Passwort verwenden lassen.

Allerdings ist selbst die Art, _wie_ das wget auf der anderen
Seite aufgerufen wird schon bekannt (weil es einfach auch vom
server kommt). Wie gesagt: kein sicherer Uebertragungskanal.

Das ist dann endgültig doof. Dann kannst du nur noch nach
IP-Adresse filtern und beten.

Das nutzt mir nichts, weil jeder Doedel mit der IP# ankommen kann.

HTTP gibt in der Hinsicht einfach nichts her.

Mist.

Ja, aber das waere dann wirklich ein Gag, weil eben auch
Nutzer MD5 sums berechnen koennen.

Aber die kennen eben nicht einen ggf. geheimen String, der zB
in einer Textdatei in ~root mit Modus 0600 liegt, und können
nach dem was du sagst auch nicht einfach mal den Referrer
abfangen.

Wie kommt die denn da hin? Es gibt keinen gesicherten Uebertragungskanal.

Vielleicht hilft es, wenn ich das etwas konkreter mache: eine Menge Rechner bootet per PXE aus dem Netz vom Server ein (abgesehen von Script-Zeugs) nicht veraenderbares und mehr oder minder doofes Standard-Linux (immerhin mit wget, ansonsten aber eher mehr doof). Der Server bietet dementsprechend die Dienste DHCP und TFTP an (deren Authentifizierungsmechanismen aber auch eher beschraenkt sind). Fuer alles weitere gebe ich noch HTTP raus (weil’s mit NFS ja langweilig waere). Dabei werden aber auch Informationen rausgereicht, die nur ein root auf der anderen Maschine kennen darf, kein Nutzer. Und das muss ich sicherstellen.

Das macht’s jetzt ganz einfach, oder?

Gruss vom Frank.

Hallo,

für gewöhnlich macht man sowas über eine Authentifizierung. Primitiv z.B. per Login mit Passwort. Sowas lässt sich auch per HTTP übertragen. Ich verstehe immer noch nicht, worum es eigentlich geht und kann Deinen Ausführungen kaum einen Sinn entlocken.

Gruß

Fritze

Hallo,

Hi,

für gewöhnlich macht man sowas über eine Authentifizierung.
Primitiv z.B. per Login mit Passwort.

Aber ich krieg weder Login noch Passwort zum Rechner.

Ich verstehe immer noch nicht, worum es eigentlich geht und kann
Deinen Ausführungen kaum einen Sinn entlocken.

Was verstehst Du nicht? Rechner booten aus dem Netz (IP# per DHCP, eindeutige Abbildung HWaddr -> IP#, weiter per TFTP, AFAIK keine Authentifizierung im Protokoll), ist er hochgefahren, koennen sich dort Nutzer per unix login anmelden. root (und nur dieser) darf weitere Daten mittels wget per HTTP vom Server holen. Dazu hat er nur HTTP (und auch TFTP) und was ein root sonst so hat. Der Rechner ist ansonsten blitzblank, er hat nicht mal ein OS installiert, selbst von Festplatten auszugehen waere nahezu vermessen.

Gruss vom Frank.

Hi,

Ich kann nicht vorhersehen, wann die Abfrage kommt.

??? Du wirst doch wissen, ob Du in den naechsten 10 Minuten
was runterladen willst, oder?

Ich? Nein, user tut das. Den kenn ich doch nicht.

Also erstens willst Du doch gerade erfahren, ob der User „root“ ist. Das ist der Sinn der Aktion. Und zweitens ist der Zeitpunkt, an dem „root“ seine Anfrage startet, beliebig. Lediglich der Zeitraum der Übertragung wäre dann nach dem Vorschlag auf + 10 Minuten begrenzt. Es läuft aber immer aufs gleiche hinaus: eine Authentifizeirung per wie auch immer geartetem Passwort.

Aber grundsätzlich ist die von Dir geschilderte Umgebung für das von Dir gewünschte ungeeignet. Ohne kryptografische Funktionen ist keine sichere Übertragung von Authentifizierungsdaten möglich. Und ohne eine Abfrage dieser Daten kann keine sichere Authentifizierung erfolgen. So einfach ist das.

Gruß

Fritze

Hallo,

für gewöhnlich macht man sowas über eine Authentifizierung.
Primitiv z.B. per Login mit Passwort.

Aber ich krieg weder Login noch Passwort zum Rechner.

Du sollst auch nicht Login oder Passwort zum Rechner haben, sondern einen entsprechenden Mechanismus mit eigenem Passwort auf dem Server implementieren. Ohne einen solchen Authentifizierungsmechanismus wirst Du nicht weiterkommen.

Dabei ist es vollkommen unerheblich, auf welche Art und Weise die Clients ihre IP Adresse beziehen, ob das irgendwelche ultra-thin-clients auf „Franx“-Basis, spartanische HTTP Implementierung auf einem 5 Pfennig Mikrocontroller oder sonstwas ist.

Was verstehst Du nicht? Rechner booten aus dem Netz (IP# per
DHCP, eindeutige Abbildung HWaddr -> IP#, weiter per TFTP,
AFAIK keine Authentifizierung im Protokoll), ist er
hochgefahren, koennen sich dort Nutzer per unix login
anmelden. root (und nur dieser) darf weitere Daten mittels
wget per HTTP vom Server holen.

Ja, dann ist doch alles bestens. Nur root darf, also ist der Drops gelutscht.

Wobei ich mich frage, wie zwischen „root“ und anderen usern unterschieden und getrennt wird, so ganz ohne OS.

Gruß

Fritze