DSGVO, HTTP-Status, Unauthorized Post2Host

[TS]

Hello,

wenn ich einen Post2Host ermöglichen will, benötige ich auf dem Zielhost einen Responder. Der Post wird über HTTPs und einen Key abgesichert.

Wenn nun unberechtigte Posts eintreffen, mit welchem Status sollte man antworten? Ich schwanke zwischen 500 und 404, mit starker Tendenz zu 404. Man will ja möglichst wenig offenlegen.

Für die Sicherheit werden Fehlzugriffe nun aber logged und durch Fail2Ban ausgewertet. Sind die Intruder ermittelbar, wird nach ca. 4x6 Versuchen abgemahnt bzw. Anzeige erstattet. Da ja im Normalbetrieb nur ein 404 gesendet wird, ist üblicherweise auch kein Hinweis auf die Dateschutzbestimmungen und das Logging laut DSGVO vorhanden.

| Sollte man die Amtwortseite für 404 entsprechend ergänzen und was sollte dann in den Hinweisen drinstehen? |

Glück Auf
Tom vom Berg

[pl]

Hello,

| Sollte man die Amtwortseite für 404 entsprechend ergänzen und was sollte dann in den Hinweisen drinstehen? |

Einen Angreifer interessiert das nicht im Geringsten was da steht 😉

Wenn es jemanden interessiert, dann ist es Deine Anwendung die bei einem bestimmten Status einen Fehler bekommt und den dazugehörigen Text entsprechend eskaliert: per Mail, SMS oder Logdatei. Status 404 würde ich jedoch nicht dafür nehmen weil ein Not Found bei der eigenen Fehlersuche irreführend ist. MFG

Tipp: Für die Fehlercodes eignet sich ein custom Responseheader!

[TS]

Hello,

| Sollte man die Amtwortseite für 404 entsprechend ergänzen und was sollte dann in den Hinweisen drinstehen? |

Einen Angreifer interessiert das nicht im Geringsten was da steht 😉

Doch, dessen Anwalt intetessiert das in einem eventuellen Verfahren ganz brennend, wenn Beweise widerrechtlich erhoben wurden. Dann bin ich nämlich plötzlich der Angeklagte

Wenn es jemanden interessiert, dann ist es Deine Anwendung die bei einem bestimmten Status einen Fehler bekommt und den dazugehörigen Text entsprechend eskaliert: per Mail, SMS oder Logdatei. Status 404 würde ich jedoch nicht dafür nehmen weil ein Not Found bei der eigenen Fehlersuche irreführend ist.

Darüber sollte man schon noch nachdenken. Allerdings stehen mir im Fehlerfalle ja auch die Logs des Zielservers zur Verfügung.

Ich sollte aber auf jeden Fall die Suchmaschinen bitten, diesen ggf. zufällig aufgeschnappten Link nicht zu indexieren.

Glück Auf
Tom vom Berg

[pl]

Darüber sollte man schon noch nachdenken. Allerdings stehen mif im Fehlerfalle ja auch did Logs des Zielservers zur Verfügung.

Deine Anwendung die mit dem Server kommuniziert läuft lokal, da wird der Fehler festgestellt und da würde ich auch lokal loggen. Kann ja auch sein daß der Server weg ist und die Logs gar nicht zugänglich sind. MFG

[TS]

Hello,

Darüber sollte man schon noch nachdenken. Allerdings stehen mif im Fehlerfalle ja auch did Logs des Zielservers zur Verfügung.

Deine Anwendung die mit dem Server kommuniziert läuft lokal, da wird der Fehler festgestellt und da würde ich auch lokal loggen. Kann ja auch sein daß der Server weg ist und die Logs gar nicht zugänglich sind.

Wenn der Zielserver weg ist, bekomme ich kein Socket und damit ein Timeout. Das wird selbstverständlich bei der Quelle logged.

Glück Auf
Tom vom Berg

[pl]

Hello,

Darüber sollte man schon noch nachdenken. Allerdings stehen mif im Fehlerfalle ja auch did Logs des Zielservers zur Verfügung.

Deine Anwendung die mit dem Server kommuniziert läuft lokal, da wird der Fehler festgestellt und da würde ich auch lokal loggen. Kann ja auch sein daß der Server weg ist und die Logs gar nicht zugänglich sind.

Wenn der Zielserver weg ist, bekomme ich kein Socket und damit ein Timeout. Das wird selbstverständlich bei der Quelle logged.

Sehr gut. Es kann aber auch sein, daß es vorher, also als die Verbindung noch bestand, bereits Fehler gab die lokal geloggt wurden. So hast Du schon was in der Hand bevor Du Dir den Server vorknöpfst. MFG

Es ist ja auch die Frage, ob derjenige der am Client sitzt auch Zugriff auf die Logfiles am Server hat. Denn das ist derjenige der als Erster die Hand hebt.

[lup]

Für die Sicherheit werden Fehlzugriffe nun aber logged und durch Fail2Ban ausgewertet. Sind die Intruder ermittelbar, wird nach ca. 4x6 Versuchen abgemahnt bzw. Anzeige erstattet.

Einen Angreifer interessiert das nicht im Geringsten was da steht 😉

Doch, dessen Anwalt intetessiert das in einem eventuellen Verfahren ganz brennend, wenn Beweise widerrechtlich erhoben wurden. Dann bin ich nämlich plötzlich der Angeklagte

Ach, wie bedauerlich, wo du doch so friedliebend bist…

Es ist nicht verboten, an verschlossene Türen im öffentlichen Raum zu klopfen. So lange mit der Klopferei nichts beschädigt wird, sehe ich jedenfalls keine rechtliche Handhabe und habe bei dir eher das Gefühl, dass du es aus zu hinterfragenden Gelüsten gezielt darauf anlegst, irgendwelche armseligen Trottel vor Gericht zu zerren.

Getreu dem Motto "Was kümmert's die Deutsche Eiche, wenn ein Schwein sich an ihr schubbert", sollten solcherlei Angreiferlein, Script-Kiddies, die es tatsächlich wagten, sage und schreibe 24 HTTP-Requests abzusetzen, automatisiert mittels iptables im Orkus landen – und gut ist.

Abmahnung. Nee, wirklich…

[Rolf B]

Hallo lup,

Es ist nicht verboten, an verschlossene Türen im öffentlichen Raum zu klopfen.

Wunderbar. Du hast messerscharf zwischen wichtigem und unwichtigem differenziert, und das wichtige ignoriert.

Wenn an einer Türe "Zutritt nur für Befugte" steht und irgendwer vier Tage lang sechsmal pro Tag anklopft, wird das "Hau ab!" irgendwann deutlich lauter. Aus dem Anklopfen wird dann nämlich Besitzstörung. Soviel zu deinem Vergleichsbild.

dass du es aus zu hinterfragenden Gelüsten gezielt darauf anlegst, irgendwelche armseligen Trottel vor Gericht zu zerren.

Diese "armseligen Trottel" stören den Betrieb von Toms Technik. Weißt Du was Tom da tut? Weißt Du, welche Typen ihm weshalb in seine Responder hineingrätschen? Weißt Du, welche Betriebsgefährdung davon ausgeht? Vermutlich nicht. Ich auch nicht. Ob Toms Reaktion fragwürdig ist, können wir überhaupt nicht beurteilen und sollten ihm deshalb auch nichts unterstellen.

Abmahnung. Nee, wirklich…

Wenn sein Betrieb gefährdet wird: doch, genau so.

automatisiert mittels iptables im Orkus landen

Die Frage war doch genau diese: Wie macht man das juristisch so wasserdicht, dass man nicht angreifbar ist.

Rolf

[TS]

Hello,

das fällt unter die Vorschriften des § 202a,b,c StGB und wird bestraft.
In der Vergangenheit hat dies schon mehrfach zur Strafverfolgung und Verurteilung geführt.

Der Unterschied ist: Damals gab es die DSGVO noch nicht. Wir haben fertige Industriesysteme benutzt. Heute bauen und programmieren wir die Systeme selber.
Ich beschäftige mich daher damit, weil ich über meinen Aufgabenbereich hinaus gerne verstehe, was die Kollegen da treiben.

Und vielen Dank für den Hinweis auf iptables. Wir benutzen nft.

Glück Auf
Tom vom Berg

[Der Martin]

Moin,

wenn ich einen Post2Host ermöglichen will, benötige ich auf dem Zielhost einen Responder. Der Post wird über HTTPs und einen Key abgesichert.

Wenn nun unberechtigte Posts eintreffen, mit welchem Status sollte man antworten? Ich schwanke zwischen 500 und 404, mit starker Tendenz zu 404. Man will ja möglichst wenig offenlegen.

öhm, ich wäre jetzt spontan auf 403 Forbidden gesprungen. Die beiden von dir genannten passen von der Semantik her nicht so recht zur Situation.
404 Not Found? Okay, um Suchmaschinen abzuwimmeln. Aber die Aussage stimmt nicht so wirklich, da wurde ja doch etwas gefunden.
500 Server Error? So wie ein Schild mit der Aufschrift "Heute wegen Todesfall geschlossen" an der Ladentür? Mich würde das animieren, den Zugriff irgendwann später nochmal zu probieren.

Für die Sicherheit werden Fehlzugriffe nun aber logged und durch Fail2Ban ausgewertet. Sind die Intruder ermittelbar, wird nach ca. 4x6 Versuchen abgemahnt bzw. Anzeige erstattet.

Wie denn das? Wie kriegst du als Otto Normalverbraucher raus, wer das war?

Da ja im Normalbetrieb nur ein 404 gesendet wird, ist üblicherweise auch kein Hinweis auf die Dateschutzbestimmungen und das Logging laut DSGVO vorhanden.

Richtig, bei anderen Fehlermeldungen in der Regel auch nicht. Aber dass Fehler im Protokoll eines Webservers gespeichert werden, würde ich als "allgemein bekannt" und "üblich" einschätzen. Und was wird geloggt, was auch nur im Entferntesten unter die DSGVO fallen könnte? Die IP-Adresse des Clients. Und aus der bekommst du meines Wissens als Normalsterblicher ohne die Unterstützung durch Polizei und/oder Staatsanwaltschaft allenfalls den Zugangsprovider des anfragenden Clients raus.

| Sollte man die Amtwortseite für 404 entsprechend ergänzen und was sollte dann in den Hinweisen drinstehen? |

Meine Meinung: Nein, wozu?

Schönen Sonntag noch,
 Martin

[TS]

Hello,

ok, 404 wäre der berühmte "false 404".
Es geht nicht um Suchmascinen, sondern um fremde Post-Quellen.

Allerdings muss ich gestehen, wer 24 Mal hintereinamder eine URL per Post mit 403 als Status-Response aufruft, macht sich ja noch verdächtiger, als jemand der "nur" Status 404 als Antwort erhält.

Da die Requests der fremden Quell-IP anschließend ohnehin bis auf Weiteres dropped werden und an das übergeornete System zur weiteren Überwachung gegeben werden, kann man sich wohl auch 403 als Antwort erlauben ;-)

Das entbindet aber mMn nicht von der Informationspflicht nach DSGVO. Oder?

Glück Auf
Tom vom Berg

[pl]

Das entbindet aber mMn nicht von der Informationspflicht nach DSGVO. Oder?

Natürlich nicht. Die VO schlägt zu wenn personenbezogene Daten erhoben und verarbeitet werden. Was bei der Nutzung Deines Webservices möglicherweise der Fall sein wird. Darauf sollte Deine Information ausgerichtet sein. MFG

[Der Martin]

Hallo,

Natürlich nicht. Die VO schlägt zu wenn personenbezogene Daten erhoben und verarbeitet werden. Was bei der Nutzung Deines Webservices möglicherweise der Fall sein wird.

ja, aber nicht, wenn der Request abgewiesen wird.

So long,
 Martin

[Rolf B]

Hallo Martin,

das Thema ist knifflig. Wie immer, wenn Juristen am Werk waren.

Es gibt das EuGH-Urteil vom 19.10.2016, Az. C-582/14, wonach IP-Adressen personenbezogen sind, wenn der Seitenbetreiber „über "rechtliche Mittel" verfügt, die ihm die Bestimmung der hinter der IP-Adresse stehenden Person grundsätzlich ermöglichen“. Ganz egal, ob er es de facto auch tut oder nicht.

Andererseits erlaubt das Telemediengesetz die Speicherung von personenbezogenen Daten, wie der IP, nur für die Dauer des Seitenbesuchs. Bei einer Abweisung ist der Besuch mit Senden des Error-Codes zu Ende.

Hier steht noch, dass §100 TKG (Telekommunikationsgesetz) erlaubt, Daten zur Abwehr von Störungen sieben Tage aufzubewahren. D.h. ob man einen Bann länger als 7 Tage aufrecht erhalten darf, wäre für mich zweifelhaft.

Disclaimer: Der gesunde Menschenverstand endet, sobald ein Anwalt ins Spiel kommt. Deshalb sollte man bei juristischen Fragen einen Anwalt hinzuziehen. Der weiß, wie seine Kameraden denken.

Rolf

[Der Martin]

Hallo,

das Thema ist knifflig. Wie immer, wenn Juristen am Werk waren.

;-)

Es gibt das EuGH-Urteil vom 19.10.2016, Az. C-582/14, wonach IP-Adressen personenbezogen sind, wenn der Seitenbetreiber „über "rechtliche Mittel" verfügt, die ihm die Bestimmung der hinter der IP-Adresse stehenden Person grundsätzlich ermöglichen“. Ganz egal, ob er es de facto auch tut oder nicht.

Ja, Juristen!

Die Wenn-Klausel dieses Satzes ist in sich nichtig. Denn der Seitenbetreiber verfügt immer über rechtliche Mittel, die IP-Adresse der Person^[1] zuzuordnen, nämlich über eine Klage (weswegen auch immer) und damit das Hinzuziehen von Ermittlungsorganen. Also ist dieser Nebensatz äquivalent zu if (TRUE).
So dämlich schätze ich aber nicht einmal Juristen ein, also gehe ich davon aus, dass die eigentlich etwas anderes gemeint haben. Nur was??

Disclaimer: Der gesunde Menschenverstand endet, sobald ein Anwalt ins Spiel kommt.

Das würde ich so mit unterschreiben.

Ciao,
 Martin

---

1. Genaugenommen nicht dem Seiten-Besucher, sondern nur dem Anschlussinhaber. ↩︎

[Rolf B]

Hallo Martin,

if (TRUE) ... Nur was??

Genau an der Stelle habe ich mir auch am kahlen Kopf gekratzt. Ich habe das Urteil nicht gelesen, nur die verlinkte Seite. Ich denke, es geht darum, ob man im Stande ist, ohne richterliche Anordnung die IP einem Menschen zuzuordnen.

Schlüsselwort ist aber wieder "ich denke". Siehe oben...

Rolf

[Der Martin]

Hallo Rolf,

if (TRUE) ... Nur was??

Genau an der Stelle habe ich mir auch am kahlen Kopf gekratzt. Ich habe das Urteil nicht gelesen, nur die verlinkte Seite.

ja, ich auch.

Ich denke, es geht darum, ob man im Stande ist, ohne richterliche Anordnung die IP einem Menschen zuzuordnen.

Siehste, so würde ich die Aussage auch eher interpretieren.
Dann wäre ich aber plötzlich bei if (FALSE), und es wäre immer noch unsinnig, die Bedingung überhaupt zu formulieren.

Schlüsselwort ist aber wieder "ich denke". Siehe oben...

"Ich denke, also bin ich ... hier falsch."

Mann, wenn ich noch an die endlosen Diskussionen um den "CSS-Kopierschutz" bei DVDs denke. Kopien von Bild- und Tonträgern für rein private Zwecke anzufertigen, ist erlaubt, aber nicht das Umgehen eines "technisch wirksamen Kopierschutzes".
Nur wie wirksam ist ein Kopierschutz, den man nicht einmal bemerkt? Auf einem Linux-PC genügt es nämlich, einfach eine allgemein anerkannte und millionenfach verbreitete Software zu installieren (wenn sie nicht im Basispaket der Distro eh schon enthalten ist). Schon ist die libdvdcss systemweit verfügbar, und andere Programme wie etwa Brasero benutzen sie ganz selbstverständlich mit - ohne dass ich als Nutzer überhaupt etwas davon ahne.

Kopfschüttelnde Grüße,
 Martin

[Camping_RIDER]

Aloha ;)

Ich denke, es geht darum, ob man im Stande ist, ohne richterliche Anordnung die IP einem Menschen zuzuordnen.

Siehste, so würde ich die Aussage auch eher interpretieren.
Dann wäre ich aber plötzlich bei if (FALSE), und es wäre immer noch unsinnig, die Bedingung überhaupt zu formulieren.

Nene, du vergisst da einen Fall. Zum Beispiel könnte es ja gleichzeitig im Rahmen dieses Webservices auch Nutzerkonten geben oder könnten anderweitig noch weitere Daten erhoben werden, die dann eine Zuordnung der IP zu weiteren persönlichen Daten ermöglichen.

Es ist also nicht if (FALSE), sondern eher if (weitereDatenErhoben)…

Grüße,

RIDER

[TS]

Hello,

Ich denke, es geht darum, ob man im Stande ist, ohne richterliche Anordnung die IP einem Menschen zuzuordnen.

Siehste, so würde ich die Aussage auch eher interpretieren.
Dann wäre ich aber plötzlich bei if (FALSE), und es wäre immer noch unsinnig, die Bedingung überhaupt zu formulieren.

Nene, du vergisst da einen Fall. Zum Beispiel könnte es ja gleichzeitig im Rahmen dieses Webservices auch Nutzerkonten geben oder könnten anderweitig noch weitere Daten erhoben werden, die dann eine Zuordnung der IP zu weiteren persönlichen Daten ermöglichen.

Es ist also nicht if (FALSE), sondern eher if (weitereDatenErhoben)…

Das ist möglich. In diesem Fall könnte Webservice W1 eine IP mit persönlichen Daten verknüpfen und wenn der Knabe/die Baut dann später, im selben Gültigkeitsfenster der IP einen anderen Webservice (W2) bsucht, und W2 mit W1 Daten austauscht, dann würde genau das passieren, was unterbunden werden soll.

Wir haben hier allerdings auch schon Tausendfach im Archiv stehen, dass eine IP kein geeignetes Mittel ist, um einen User zu identifizieren. Und auch das stimmt unter normalen Umständen. Die Identifikation ist nicht nachhaltig.

Das Gesetz nimmg allerdings keind Rücksicht auf did Randbedingungen...

Glück Auf
Tom vom Berg

[TS]

Hello,

if (TRUE) ... Nur was??

Genau an der Stelle habe ich mir auch am kahlen Kopf gekratzt. Ich habe das Urteil nicht gelesen, nur die verlinkte Seite. Ich denke, es geht darum, ob man im Stande ist, ohne richterliche Anordnung die IP einem Menschen zuzuordnen.

Da werden wir jetzt mal ganz spitzfindig und sagen, solange der Typ den Chip nicht unter der Haut (fest am/im Körper) trägt, kann man die IP bestenfalls irgendwelchen Geräten zuordnen. Vielleicht hat da ja jemand fünf bis zehn Jahre vorausgedacht?

Man weiß ja nicht, was die AfD so vor hat, wenn sie im September Sachsen übernimmt...

Glück Auf
Tom vom Berg

[pl]

Man weiß ja nicht, was die AfD so vor hat, wenn sie im September Sachsen übernimmt…

Auch nichts Anderes als das was diejenigen unternommen haben die bisher Sachsen übernommen haben. MFG

[TS]

Hello,

Man weiß ja nicht, was die AfD so vor hat, wenn sie im September Sachsen übernimmt…

Auch nichts Anderes als das was diejenigen unternommen haben die bisher Sachsen übernommen haben.

Ach Du meinst "das Äußerste aus den Betrieben herausholen"?

Glück Auf
Tom vom Berg

[pl]

Hallo,

Natürlich nicht. Die VO schlägt zu wenn personenbezogene Daten erhoben und verarbeitet werden. Was bei der Nutzung Deines Webservices möglicherweise der Fall sein wird.

ja, aber nicht, wenn der Request abgewiesen wird.

Anmeldedaten sind auch personenbezogene Daten. Beim Loggen jeder Anmeldung wird die DSGVO also fällig. Auch wenn die Anmeldung fehlschlägt, stehen die Daten ja im Log. MFG

[Der Martin]

Hi,

Natürlich nicht. Die VO schlägt zu wenn personenbezogene Daten erhoben und verarbeitet werden. Was bei der Nutzung Deines Webservices möglicherweise der Fall sein wird.

ja, aber nicht, wenn der Request abgewiesen wird.

Anmeldedaten sind auch personenbezogene Daten. Beim Loggen jeder Anmeldung wird die DSGVO also fällig. Auch wenn die Anmeldung fehlschlägt, stehen die Daten ja im Log. MFG

na sicher. Aber von einer Anmeldung war ja hier keine Rede.
Hier ging es um störende Requests von nicht autorisierten Clients.

Ciao,
 Martin

[pl]

Hi,

Natürlich nicht. Die VO schlägt zu wenn personenbezogene Daten erhoben und verarbeitet werden. Was bei der Nutzung Deines Webservices möglicherweise der Fall sein wird.

ja, aber nicht, wenn der Request abgewiesen wird.

Anmeldedaten sind auch personenbezogene Daten. Beim Loggen jeder Anmeldung wird die DSGVO also fällig. Auch wenn die Anmeldung fehlschlägt, stehen die Daten ja im Log. MFG

na sicher. Aber von einer Anmeldung war ja hier keine Rede.
Hier ging es um störende Requests von nicht autorisierten Clients.

Genau. Auch wenn ein Request nicht autorisiert ist, enthält er ja personenbezogene Daten.

MFG

[1unitedpower]

wenn ich einen Post2Host ermöglichen will, benötige ich auf dem Zielhost einen Responder.

Hätte ich deinen letzten Thread zum Thema nicht mehr in Erinnerung, wüsste ich mit dem Begriff Post2Host nichts anzufangen. Du willst eine Post-Anfrage programmatisch an einen Web-Service schicken.

Der Post wird über HTTPs und einen Key abgesichert.

Kannst du „Key“ präzisieren? Welches Authentifizierungs-Verfahren nutzt du? Digest Authentication? Public Key? JSON Web Token?

Wenn nun unberechtigte Posts eintreffen, mit welchem Status sollte man antworten?

401 Unauthorized wäre auch eine Möglichkeit.

[TS]

Hello,

401 scheidet aus, da es explizit zur Authentifizierung auffordern würde.

Es wird ein Token (32 Zeichen, 64 Möglichkeiten pro Digit) mitgesendet. Da das Ganze per https stattfindet, müsste damit relative Sicherheit gegeben sein. Und wenn jemand es per bruteforce versuchen sollte, soll er ja per iptables bzw. nft geblockt werden.

Außerdem wird das Postparametermuster verglichen, was sicher nur "Security by Obscurity" ist; aber es schadet nicht.

BTW: Ich hatte deinen Tipp mit der Lib übrigens weitergegeben und nun spielen die Kollegen die ganze Zeit damit, anstatt die wesentlichen Dinge fertg zu machen :-O

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

BTW: Ich hatte deinen Tipp mit der Lib übrigens weitergegeben und nun spielen die Kollegen die ganze Zeit damit, anstatt die wesentlichen Dinge fertg zu machen :-O

Oder das, was die Kollegen da tun, sieht nur für dich von außen nach Spielerei aus und ist eigentlich ein wichtiger Teil der Inbetriebnahme, der nachher zu einer wesentlich besseren Implementierung führt und daher auch zu den wesentlichen Dingen gehört.

Eine Frage des Standpunkts. Außer deine Kollegen sind inkompetent, was aber auch wieder von außen schwer zu beurteilen ist und anfällig für Fehlurteile ist.

Grüße,

RIDER

[1unitedpower]

401 scheidet aus, da es explizit zur Authentifizierung auffordern würde.

Und welches potenzielle Problem siehst du damit verbunden?

Es wird ein Token (32 Zeichen, 64 Möglichkeiten pro Digit) mitgesendet. Da das Ganze per https stattfindet, müsste damit relative Sicherheit gegeben sein.

Ja, HTTPS ist schonmal gut, um die Vertraulichkeit des Tokens abzusichern. Wie überträgst du das Token denn? Als Custom-Header, als Teil des Message-Bodys oder als Querystring-Parameter? Letzteres solltest du vermeiden, denn dann ist der Token kompromitiert sobald er einmal im Referrer-Header an einen fremden Server übertragen wird.

Aber wieso überhaupt etwas eigenes? Konzeptionell ist dein Verfahren ähnlich zu Basic Auth, wieso nicht direkt ein existierendes Verfahren nehmen? Hat den Vorteil, dass man die Sicherheitsmerkmale direkt nachschlagen kann, anstatt den Programmcode interpretieren zu müssen. Außerdem gibt es für gängige Verfahren bereits erprobte Implementierungen.

Außerdem wird das Postparametermuster verglichen, was sicher nur "Security by Obscurity" ist; aber es schadet nicht.

Input-Validierung muss ja sowieso stattfinden.

BTW: Ich hatte deinen Tipp mit der Lib übrigens weitergegeben und nun spielen die Kollegen die ganze Zeit damit, anstatt die wesentlichen Dinge fertg zu machen :-O

Schön zu hören :) Spielen ist ein Geniestreich der Evolution, damit wir Freude am Lernen haben.

[TS]

Hello,

401 scheidet aus, da es explizit zur Authentifizierung auffordern würde.

Und welches potenzielle Problem siehst du damit verbunden?

Es würde mMn zu einem zusätzlichen Roundturn auffordern. Aber es bleibt nun bei 403. Das hat das alte System auch verwendet.

Es wird ein Token (32 Zeichen, 64 Möglichkeiten pro Digit) mitgesendet. Da das Ganze per https stattfindet, müsste damit relative Sicherheit gegeben sein.

Ja, HTTPS ist schonmal gut, um die Vertraulichkeit des Tokens abzusichern. Wie überträgst du das Token denn? Als Custom-Header, als Teil des Message-Bodys oder als Querystring-Parameter? Letzteres solltest du vermeiden, denn dann ist der Token kompromitiert sobald er einmal im Referrer-Header an einen fremden Server übertragen wird.

Guter Hinweis!
Das Token wird als Post-Parameter im Messagebody übertragen. Ob da nun mit multipart/form-data oder urlencoded Data gearbeitet wird, steht noch auf dem Arbeitszettel.

Aber wieso überhaupt etwas eigenes? Konzeptionell ist dein Verfahren ähnlich zu Basic Auth, wieso nicht direkt ein existierendes Verfahren nehmen? Hat den Vorteil, dass man die Sicherheitsmerkmale direkt nachschlagen kann, anstatt den Programmcode interpretieren zu müssen. Außerdem gibt es für gängige Verfahren bereits erprobte Implementierungen.

Es sitzt noch ein Protokoll dazwischen. Das muss wieder eingehalten werden. Die Tokens werden immer wieder ausgetauscht. Sie sind ja in den Sendegeräten gespeichert. Und die sind zeitweise unbeaufsichtigt. Da steckt die Schwachstelle im System. Wenn sich jemand so ein Gerät krallt, kann er mit dem Token noch einige Minuten lang Unsinn treiben.

Außerdem wird das Postparametermuster verglichen, was sicher nur "Security by Obscurity" ist; aber es schadet nicht.

Input-Validierung muss ja sowieso stattfinden.

BTW: Ich hatte deinen Tipp mit der Lib übrigens weitergegeben und nun spielen die Kollegen die ganze Zeit damit, anstatt die wesentlichen Dinge fertg zu machen :-O

Schön zu hören :) Spielen ist ein Geniestreich der Evolution, damit wir Freude am Lernen haben.

Naja, da interessiert wohl am Meisten die Möglichkeit des Streamens. Die scheidet aber für unsere Anwendungsfälle in 90% sowieso aus. Es gibt bei den Sendestellen meistens nur LLN statt Highspeed-WWW (Langsames Land Netz), sprich DSL über alte POTS-Leitungen oder G3. Und wenn G5 mal kommt, wird das zu teuer sein.

Ich wär ja auch neugierig, hab aber eine Terminvorgabe für das Grobkonzept.

Glück Auf
Tom vom Berg

[1unitedpower]

401 scheidet aus, da es explizit zur Authentifizierung auffordern würde.

Und welches potenzielle Problem siehst du damit verbunden?

Es würde mMn zu einem zusätzlichen Roundturn auffordern.

Nein, der Webserver teilt nur mit: Hey, du bist nicht authentifiziert. Wenn du diese Aktion ausführen willst, sage mir wer du bist, dafür brauche ich die folgenden Daten…

Aber es bleibt nun bei 403. Das hat das alte System auch verwendet.

„Haben wir schon früher so gemacht“ ist ein schlechter Ratgeber. Andererseits ist 403 auch passend man muss sich nicht in Kleinigkeiten verlieren. Haken wir das Thema also ab.

Aber wieso überhaupt etwas eigenes? Konzeptionell ist dein Verfahren ähnlich zu Basic Auth, wieso nicht direkt ein existierendes Verfahren nehmen? Hat den Vorteil, dass man die Sicherheitsmerkmale direkt nachschlagen kann, anstatt den Programmcode interpretieren zu müssen. Außerdem gibt es für gängige Verfahren bereits erprobte Implementierungen.

Es sitzt noch ein Protokoll dazwischen. Das muss wieder eingehalten werden.

Vaider Punkt.

Die Tokens werden immer wieder ausgetauscht. Sie sind ja in den Sendegeräten gespeichert. Und die sind zeitweise unbeaufsichtigt. Da steckt die Schwachstelle im System. Wenn sich jemand so ein Gerät krallt, kann er mit dem Token noch einige Minuten lang Unsinn treiben.

Klingt als hättest du die Schwachstelle richtig erkannt, aber willst im Moment nichts dagegen tun. Für die Zukungt: Public Key oder JSON Web Token sind geeignetere Authentifizierungsverfahren für euren Anwendungsfall.

BTW: Ich hatte deinen Tipp mit der Lib übrigens weitergegeben und nun spielen die Kollegen die ganze Zeit damit, anstatt die wesentlichen Dinge fertg zu machen :-O

Schön zu hören :) Spielen ist ein Geniestreich der Evolution, damit wir Freude am Lernen haben.

Naja, da interessiert wohl am Meisten die Möglichkeit des Streamens. Die scheidet aber für unsere Anwendungsfälle in 90% sowieso aus. Es gibt bei den Sendestellen meistens nur LLN statt Highspeed-WWW (Langsames Land Netz), sprich DSL über alte POTS-Leitungen oder G3. Und wenn G5 mal kommt, wird das zu teuer sein.

Du missverstehst glaube ich den Begriff Streaming in diesem Kontext. Im allgemeinen Sprachgebrauch verknüpft man mit Streaming hauptsächlich das Hören von Musik oder das Ansehen von Filmen ohne sie vorher in Gänze heruntergeladen zu haben. In diesem technischen Kontext meint man damit aber ganz allgemein Informationen bei ihrem Eintreffen zu verarbeiten ohne bereits alle notwendigen Daten zur Verfügung zu haben. Das ist dann sinnvoll, wenn man nicht alle Daten in den Hauptspeicher laden möchte, sondern sie stückweise verarbeiten möchte. Gerade bei instabilen Netzwerk-Verbindungen kann man das auch nutzen, um einen unterbrochenen Download wieder fortzusetzen, ohne von vorne zu beginnen.

Ich wär ja auch neugierig, hab aber eine Terminvorgabe für das Grobkonzept.

Das Dilemma kenn ich. Mach deinen Mitarbeitern ein Angebot. Mach ihnen bspw. eine Zusage, dass Sie eine Schulung zum Thema bekommen oder dass ihr auf eine Konferenz fahrt, wo das Thema besprochen wird. Aber zunächst hat das laufende Projekt Priorität und Weiterbildungsmaßnahmen müssen warten. Das hält die Motivation hoch und nutzt eurer Firma auch mittelfristig, weil das Team neue Kompetenzen erwirbt.

[TS]

Hello,

Klingt als hättest du die Schwachstelle richtig erkannt, aber willst im Moment nichts dagegen tun. Für die Zukungt: Public Key oder JSON Web Token sind geeignetere Authentifizierungsverfahren für euren Anwendungsfall.

Ich kann jetzt nicht erkennen, was ein Public Key daran verbessern könnte. Wo soll der gespeichert werden?

Irgendwo muss die Zugangsberechtigung ja gespeichert werden. Es geht hier nicht um die Transportsicherung. Die wird ja demnächst per HTTPS vorgenommen. Wir brauchen im Prinzip noch ein zusätzliches Merkmal, das sich ändert, wenn jemand das Gerät klaut und zuhause damit postet. Vermutlich wird er/sie es eher zerlegen...

[edit]
Mir fällt bisher nur gps ein. Wird das Gerät verschleppt, verfällt der aktuelle Zgangskey sofort. Nur gps ist auch nicht überall stabil.

[edit-2]
Wenn man merkt, dass gefälschte Daten gekommen sind, wird der Key selbstverständlich auch deaktiviert und das Gerät überprüft. Das ist dann vermutlich nicht mehr da, wohin es gehört.

Glück Auf
Tom vom Berg

[1unitedpower]

Ich kann jetzt nicht erkennen, was ein Public Key daran verbessern könnte. Wo soll der gespeichert werden?

Der Public-Key wird auf der empfangenden Seite hinterlegt, der dazugehörige Private-Key wird auf der sendenden Seite hinterlegt. Zusätzlich wird der Private-Key mit einem Passwort gesichert. Wenn dann ein Sende-Gerät gestohlen wird, hat der Dieb zwar den Private-Key, aber er kenntdas Passwort nicht und kann also nicht unberechtigt an den Server senden. Den Public-Key sollte man dann auf der Empfansseite trotzdem blockieren.

[TS]

Hello,

Ich kann jetzt nicht erkennen, was ein Public Key daran verbessern könnte. Wo soll der gespeichert werden?

Der Public-Key wird auf der empfangenden Seite hinterlegt, der dazugehörige Private-Key wird auf der sendenden Seite hinterlegt. Zusätzlich wird der Private-Key mit einem Passwort gesichert. Wenn dann ein Sende-Gerät gestohlen wird, hat der Dieb zwar den Private-Key, aber er kenntdas Passwort nicht und kann also nicht unberechtigt an den Server senden. Den Public-Key sollte man dann auf der Empfansseite trotzdem blockieren.

Ich hab's befürchtet. Wie kommt denn der Sender an das Passwort für den private Key?
Das läuft noch nicht rund :-O

Glück Auf
Tom vom Berg

[1unitedpower]

Wie kommt denn der Sender an das Passwort für den private Key?

Durch eine sichere Eingabeaufforderung für Passworte. Im Falle einer UNIX-Shell geschieht das dadurch, dass das Echo abgeschaltet wird. So landet das Passwort nicht in der Shell-Historie. Das machen bspw. auch ssh und mysql so.

[TS]

Hello,

Wie kommt denn der Sender an das Passwort für den private Key?

Durch eine sichere Eingabeaufforderung für Passworte. Im Falle einer UNIX-Shell geschieht das dadurch, dass das Echo abgeschaltet wird. So landet das Passwort nicht in der Shell-Historie. Das machen bspw. auch ssh und mysql so.

Die Geräte laufen aber ohne Benutzereingriff. Nach einem Stromausfall müssen sie automatisch wieder hochfahren. Da kann niemand ein Passwort eingeben.

Das zweite mögliche Problem ist Unterbrechung der Internetverbindung.

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

Die Tokens werden immer wieder ausgetauscht. Sie sind ja in den Sendegeräten gespeichert. Und die sind zeitweise unbeaufsichtigt. Da steckt die Schwachstelle im System. Wenn sich jemand so ein Gerät krallt, kann er mit dem Token noch einige Minuten lang Unsinn treiben.

So weit, so richtig. Nun, wenn es denn eben zu den absolut notwendigen Features gehört, dass sich die Geräte völlig ohne äußeres Zutun wieder selbst einwählen können, wie du schriebst, dann setzt dieses Feature eben auch voraus, dass an der Stelle keine weiteren Sicherheitsmaßnahmen in der Software selbst vorgesehen werden können; es würde mich sehr überraschen, wenn da jemand noch mit einer Idee zu einer technischen Umsetzung um die Ecke käme, die nicht auch das genannte Feature beschneidet.

Wenn also feststeht, dass hier keine weiteren Sicherheitsmaßnahmen getroffen werden können, da dieses wichtige Feature sonst technisch unmöglich wird, dann besteht die Alternative halt darin, diese Sicherheitsmaßnahmen auf einer anderen Ebene vorzusehen - zum Beispiel, indem die Geräte hardwareseitig vor Mitnahme^[1] oder Fremdeingriff^[2] geschützt werden.

Wie diese Maßnahmen konkret aussehen könnten ist aufgrund der Informationslage schwer zu sagen.

Grüße,

RIDER

---

1. zum Beispiel via Vorhängeschloss ↩︎

2. zum Beispiel dank fehlendem Eingabegerät, wenn unbeaufsichtigt ↩︎

[TS]

Hello,

Die Tokens werden immer wieder ausgetauscht. Sie sind ja in den Sendegeräten gespeichert. Und die sind zeitweise unbeaufsichtigt. Da steckt die Schwachstelle im System. Wenn sich jemand so ein Gerät krallt, kann er mit dem Token noch einige Minuten lang Unsinn treiben.

So weit, so richtig. Nun, wenn es denn eben zu den absolut notwendigen Features gehört, dass sich die Geräte völlig ohne äußeres Zutun wieder selbst einwählen können, wie du schriebst, dann setzt dieses Feature eben auch voraus, dass an der Stelle keine weiteren Sicherheitsmaßnahmen in der Software selbst vorgesehen werden können; es würde mich sehr überraschen, wenn da jemand noch mit einer Idee zu einer technischen Umsetzung um die Ecke käme, die nicht auch das genannte Feature beschneidet.

Wenn also feststeht, dass hier keine weiteren Sicherheitsmaßnahmen getroffen werden können, da dieses wichtige Feature sonst technisch unmöglich wird, dann besteht die Alternative halt darin, diese Sicherheitsmaßnahmen auf einer anderen Ebene vorzusehen - zum Beispiel, indem die Geräte hardwareseitig vor Mitnahme^[1] oder Fremdeingriff^[2] geschützt werden.

Wie diese Maßnahmen konkret aussehen könnten ist aufgrund der Informationslage schwer zu sagen.

Genau das ist z. Zt. die Option bei den Industriegeräten. Die haben eine "harte Büchse" (auch nur stärkeres Plastik) drum herum. Leider nutzen sie nicht alle Möglichkeiten der Datenaufnahme und sind mächtig teuer geworden. Und sie verwenden nur HTTP, was mir gegen den Strich geht, weil die Empfängerseite dadurch zu leicht kompromittiert werden kann.

Da wir das Projekt im Wesentlichen ehrenamtlich bzw. für kleines Geld betreuen, können wir uns auch nur bedingt die Into-the-Depth-Profis leisten. Wenn die Geräte eventuell serienmäßig werden, sieht das schon anders aus. Dann kann vielleicht der Eine oder die Andere auch mal ein Seminar besuchen...

Jedenfalls habe ich entdeckt, dass das GPS-Modul schon für 10€ zu bekommen ist. Vielleicht fällt mir etwas ein, wie man das nutzen könnte, trotz Berücksichtigung von Reboot und temporärer Satellitenabschattung (kein GPS vorhanden).

Man könnte vielleicht noch einen Bewegungssensor (Gyroskop, Richtungssensor) einbauen. Das sind quasi elektromechanische Maßnahmen. Wäre gleichzeitig ein Life-Diebstahlsmelder :-) Bin ich auch eben erst drauf gekommen.

Ab dem Event werden die Daten markiert und der Key bekommt eine andere Berechtigung...
So könnte es gehen. Müssen wir nur mal messen, was das für die Energiebilanz bedeutet. Ich glaube, GPS benötigt am meisten von den Extrasensoren.

Vielen Dank jedenfalls schonmal für alle Anregungen und Tipps.

Glück Auf
Tom vom Berg

---

1. zum Beispiel via Vorhängeschloss ↩︎

2. zum Beispiel dank fehlendem Eingabegerät, wenn unbeaufsichtigt ↩︎

[Camping_RIDER]

Aloha ;)

Jedenfalls habe ich entdeckt, dass das GPS-Modul schon für 10€ zu bekommen ist. Vielleicht fällt mir etwas ein, wie man das nutzen könnte, trotz Berücksichtigung von Reboot und temporärer Satellitenabschattung (kein GPS vorhanden).

Man könnte vielleicht noch einen Bewegungssensor (Gyroskop, Richtungssensor) einbauen. Das sind quasi elektromechanische Maßnahmen. Wäre gleichzeitig ein Life-Diebstahlsmelder :-) Bin ich auch eben erst drauf gekommen.

Ja, das hört sich doch nach zwei guten Möglichkeiten an, etwa diese Ebene hatte ich für ein zusätzliches Sicherheitsmerkmal im Kopf.

Was mir noch einfiel: wenn die Geräte mit WLan arbeiten könnte man vielleicht auch die SSID des WLan mitübertragen um eine „Mitnahme“ festzustellen. Ob das so machbar ist, keine Ahnung, ist nur ein Gedanke.

Tatsächlich muss dieses zusätzliche Sicherheitsmerkmal ja auch gar nicht unknackbar sein - es muss einen potenziellen Angreifer ja nur so viel Zeit kosten, bis der sowieso verwendete Token nicht mehr gültig ist.

Eine ganz plumpe Möglichkeit, die mir da einfällt: Den Token clientseitig zusätzlich mit der (gerundeten) GPS-Position oder eben der aktuellen WLan-SSID verschlüsseln und auf dem Server mit dem für dieses Gerät erwarteten Position / SSID entschlüsseln. Ist zwar für einen Angreifer potenziell nachvollziehbar und umgehbar, aber halt nicht innerhalb kürzester Zeit.

Mag sein ich übersehe dabei was.

Grüße,

RIDER

[TS]

Hello,

es dürfte immer nur der Zeitvorsprung sein, der ausgewertet werden muss. Da muss man dann aber genau unterscheiden, ob es ein ungefährlicher temporärer Systemausfall sein kann oder eine provozierte Unterbrechung, die für Böses genutzt werden kann.

Die Daten selbst sind nicht unbedingt geheim, nur wenn man gefälschte Daten untergeschoben bekommt, wäre das ggf. fatal.

Glück Auf
Tom vom Berg

[m.]

Mahlzeit,

bin zwar kein Jurist, aber wenn jemand unberechtigt Daten an den Server schickt, hat er IMHO kein Anrecht auf Datenschutz.

[TS]

Hello,

bin zwar kein Jurist, aber wenn jemand unberechtigt Daten an den Server schickt, hat er IMHO kein Anrecht auf Datenschutz.

Das wäre zwar wünschenswert, aber faktisch wird ja meistens logged, bevor der Missbrauch mittels Logging festgestellt werden kann.

Wenn die Gesetze so klar wären, dass man nicht immer erst drei Juristen für die Auslegung brauchen würde, wären sie vermutlich nicht von Juristen gemacht. Und diese antworten dir dann erfahrungsgemäß auch nur "es kommt darauf an".

Glück Auf
Tom vom Berg

[pl]

aber faktisch wird ja meistens logged, bevor der Missbrauch mittels Logging festgestellt werden kann.

Selbstverständlich haben auch Einbrecher das Recht auf den Schutz ihrer Privatsphäre! Vor dem Gesetz sind schließlich alle gleich (bis auf die die gleicher sind).

MFG