Hallo zusammen, seit längerem habe ich bereits einen eigenen root server für Nextcloud, Mail und co gemietet. Zur Weihnachtszeit beschäftige ich mich immer wieder gerne mit kleinen Arduino Projekten. Nachdem ich leztes Semester einen Cloud Computing Kurs in der Uni hatte kam jetzt die Idee, eine kleine Serveranwendung zu schreiben, die die Daten meiner kleinen ESP Wetterstation speichert, auswertet und als Graph ausgibt. Also der ESP soll alle X Minuten T emperatur, Luftfeuchtigkeit und Luftdruck an den Server schicken. Hab schon einiges an Erfahrung was programmieren angeht, aber vor einer Anwendung die ans Internet angeschlossen ist hab ich doch noch Respekt. Gibt es da Best Practices, Guides oder Stichworte in die ich mich einlesen kann? Vielen Dank schonmal :)
Du hast schon mal vergessen das OS deines root-servers zu nennen ... ist die Geschichte womöglich nur Ausgedachtes bbb - buzzword bullshit bingo?!
1) Verwende TLS 2) Nimm ne normale rest Schnittstelle für die Daten, und lasse den ESP einen Token zur Authentifizierung mitsenden. Musst du dann halt dort jeweils hinterlegen. Ein token pro client. Du kannst den auch automatisch generieren und an den Client weitergeben lassen, und dann danach Freischalten, und/oder zeugs wie OAuth machen. Eigentlich ja auch egal, wie es geht. Huptsache, die Verbindung ist verschlüsselt, die Anfragen Authentifiziert & Authorisiert, und du kannst beim Verlust eines Geräts diesem die Rechte entziehen.
Programmierer schrieb: > Also der ESP > soll alle X Minuten T > emperatur, Luftfeuchtigkeit und Luftdruck an den Server schicken. MQTT über TLS. Da brauchts sonst keine Klimmzüge.
:
Bearbeitet durch User
Programmierer schrieb: > seit längerem habe ich bereits einen eigenen root server für Nextcloud, > Mail und co gemietet. Zur Weihnachtszeit beschäftige ich mich immer > wieder gerne mit kleinen Arduino Projekten. Nachdem ich leztes Semester > einen Cloud Computing Kurs in der Uni hatte kam jetzt die Idee, eine > kleine Serveranwendung zu schreiben, die die Daten meiner kleinen ESP > Wetterstation speichert, auswertet und als Graph ausgibt. Also der ESP > soll alle X Minuten T > emperatur, Luftfeuchtigkeit und Luftdruck an den Server schicken. > > Hab schon einiges an Erfahrung was programmieren angeht, aber vor einer > Anwendung die ans Internet angeschlossen ist hab ich doch noch Respekt. > Gibt es da Best Practices, Guides oder Stichworte in die ich mich > einlesen kann? Dieses Dokument [1] vom Open Web Application Security Project (OWASP) ist schonmal ein guter Anfang, und darüber hinaus hält die Webseite des OWASP ein wahres Füllhorn mit Dokumentationen und Werkzeugen vor. Ansonsten sind das BSI, beispielsweise [2], und OpenSCAP [3] zum Einstieg lesenswert. So bekommst Du eine erste Idee, worauf Du achten und in welchen Bereichen Du Deine Kenntnisse erweitern solltest. Darüber hinaus ist es sicherlich sinnvoll, die Betriebsumgebung Deiner Software zu härten. Das beginnt mit den Zugriffsrechten für Dateien und Verzeichnisse, Benutzer, Gruppen und Rechte, geht über die Konfiguration des Paketfilter-Firewall und eine verschlüsselte Kommunikation bis hin zu speziellen Sicherheitstechnologien, unter Linux beispielsweise AppArmor, Capabilities und Seccomp. Darüber umfassend auszuführen könnte aber wohl sowohl den zeitlichen Rahmen, wie womöglich auch die Speicherkapazitäten dieses Forums sprengen... ;-) [1] https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf [2] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs_2021/06_APP_Anwendungen/APP_3_2_Webserver_Edition_2021.html [3] https://www.open-scap.org/
Warum für umsonst arbeiten schrieb: > Du hast schon mal vergessen das OS deines root-servers zu nennen > ... > > ist die Geschichte womöglich nur Ausgedachtes bbb - buzzword bullshit > bingo?! Wollte keinen Roman schreiben. Tut mir Leid dass ich das vergessen habe. Auf dem Server läuft Debian. Da ich mich mit Java am besten Auskenne wollte ich die Applikation darin schreiben, auch wenn ich weiß, dass Java dafür nicht die beste wahl wäre.
Ein T. schrieb: > Programmierer schrieb: >> seit längerem habe ich bereits einen eigenen root server für Nextcloud, >> Mail und co gemietet. Zur Weihnachtszeit beschäftige ich mich immer >> wieder gerne mit kleinen Arduino Projekten. Nachdem ich leztes Semester >> einen Cloud Computing Kurs in der Uni hatte kam jetzt die Idee, eine >> kleine Serveranwendung zu schreiben, die die Daten meiner kleinen ESP >> Wetterstation speichert, auswertet und als Graph ausgibt. Also der ESP >> soll alle X Minuten T >> emperatur, Luftfeuchtigkeit und Luftdruck an den Server schicken. >> > ... Danke schonmal für deine Antwort. Das werde ich mir mal genauer anschauen. Das Linux habe ich schon weitesgehend gehärtet. Zugriff per ssh nur mit key und kein direkter root login, log2ban, Firewall etc sind schon eingerichtet. :)
🐧 DPA 🐧 schrieb: > 1) Verwende TLS > 2) Nimm ne normale rest Schnittstelle für die Daten, und lasse den ESP > einen Token zur Authentifizierung mitsenden. Musst du dann halt dort > jeweils hinterlegen. Ein token pro client. Du kannst den auch > automatisch generieren und an den Client weitergeben lassen, und dann > danach Freischalten, und/oder zeugs wie OAuth machen. Eigentlich ja auch > egal, wie es geht. Huptsache, die Verbindung ist verschlüsselt, die > Anfragen Authentifiziert & Authorisiert, und du kannst beim Verlust > eines Geräts diesem die Rechte entziehen. Also so ne Art Whitelist?
Ja, so ungefähr. Eine Zugriffsliste halt. Sowas gibt es eigetlich überall: * Bei Twitter: https://www.macobserver.com/tips/quick-tip/deauthorize-twitter-apps-account/ * Bei Github: https://res.cloudinary.com/practicaldev/image/fetch/s--xeu-HzGe--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4kpoxhb7tbqv8rus5k5b.png * Bei Google: https://www.lireo.com/how-to-remove-third-party-app-permissions-from-your-google-account/
Programmierer schrieb: > Wollte keinen Roman schreiben. Tut mir Leid dass ich das vergessen habe. > Auf dem Server läuft Debian. Das ist schick, dann kannst Du gleich auch mal auf die Linux-Features Capabilities, Seccomp und AppArmor schauen, das bringt Debian alles schon mit. Wenn Du Deine Software in Docker- oder Podman-Containern betreiben möchtest, ist docker-slim sicherlich auch einen Blick wert. > Da ich mich mit Java am besten Auskenne wollte ich die Applikation darin > schreiben, auch wenn ich weiß, dass Java dafür nicht die beste wahl > wäre. Java ist genauso gut oder schlecht wie jede andere Sprache. Wichtig ist, daß Du jede(!) Eingabe validierst und plausibilisierst. Und wenn Du die Daten in einer SQL-Datenbank speichern willst, solltest Du dringend auch das Thema SQL-Injektion im Auge behalten. TLS ist übrigens ein interessantes Thema für die Authentifizierung von Benutzern und deren Autorisierung für bestimmte Ressourcen.
Also wenn du es wirklich von der Pike auf lernen willst, ist Secure Engineering von Ross Anderson das Buch, dass du lesen solltest. Aber das sind mehr als 1000 Seiten, die erstmal durchgearbeitet werden wollen.
'The S in Iot stands for security', den Spruch mag ich :) Warum soll MQTT mit TLS nicht reichen? Das bekommt man doch hin das die Anmeldung mit Zertifikat erfolgt?
J. S. schrieb: > 'The S in Iot stands for security', den Spruch mag ich :) > Warum soll MQTT mit TLS nicht reichen? Das bekommt man doch hin das die > Anmeldung mit Zertifikat erfolgt? Weil MQTT die Daten weder "speichert", noch "auswertet", und schon gar nicht "als Graph ausgibt", und daran ändert auch TLS leider wenig. :-( Für jene Dinge, die unser TO laut Eingangsbeitrag mit seinen Daten tun möchte, kommt er also kaum darum herum, Software zu benutzen, die seine Daten a) vom MQTT liest und sie b) in irgendeinen Datenspeicher einträgt (mithin irgendwas, das Append-Only-Logdaten speichern, und idealerweise housekeepen oder konfigurierbar verdichten kann). Außerdem wird er wohl etwas brauchen, das c) seine Daten aus dem Datenspeicher liest und sie, womöglich verdichtet, in einen oder mehrere Graphen umwandelt und diese mithilfe einer Webseite zugänglich macht. Wo ist in diesem Szenario der Benefit für den Anwendungsfall des TO?
Er hat eh schon nexcloud & co auf dem Server, ein bischen IoT-Spielerei macht das nicht viel schlimmer. MQTT mit TLS+Passwort zum Entgegennehmen der Daten von den IoT-Devices, und dann stöpselt man sich z.B. mit node-red, influxdb, grafana & co ein Frontend dafür zusammen. Die lässt man alle nicht direkt ans Internet, sondern bastelt sich da (nginx, apache, caddy, ...) einen Reverse-Proxy davor, der TLS drübermacht und Zugriffe nur von bekannten/authentifizierten Endgeräten erlaubt. fail2ban dazu und fertig. Es geht nur um Daten einer Wetterstation... Schlimmstenfalls knackt jemand das MQTT-Passwort und kann mitlesen, ob's grad regnet...
Ein T. schrieb: > Weil MQTT die Daten weder "speichert", noch "auswertet", und schon gar > nicht "als Graph ausgibt", das sollte klar sein, und Ernst hat es gerade auch beantwortet. Es geht ja nur um einen sicheren Weg der reinen Daten in den Server und das diese Tür nicht als Einfallstor für andere Bösewichte dient.
Εrnst B. schrieb: > Es geht nur um Daten einer Wetterstation... Schlimmstenfalls knackt > jemand das MQTT-Passwort und kann mitlesen, ob's grad regnet... Oder er schickt manipulierte Messwerte, die eine Schwachstelle im Backend (SQL Injection, Buffer Overflow...) ausnutzen. Siehe auch: https://xkcd.com/327/
Hmmm schrieb: > Oder er schickt manipulierte Messwerte, die eine Schwachstelle im > Backend (SQL Injection, Buffer Overflow...) ausnutzen. Deswegen hab node-red und influxdb empfohlen. Bei node-red muss man sich schon einigermaßen anstrengen, um da "aus Versehen" eine SQL-Injection-Lücke hinzubekommen. Und wenn man dann mit viel Aufwand einen entsprechenden Fehler eingebaut hat, hängt der Angreifer am Influxdb, was nur sehr begrenzte Möglichkeiten hat, diesen auszunutzen. Das scheitert meist direkt daran, dass sich "Bobby Tables" nicht in einen Float umwandeln lässt. Und das alles wie gesagt erst, nachdem jemand das MQTT-Passwort rausgefunden hat...
Εrnst B. schrieb: > MQTT mit TLS+Passwort zum Entgegennehmen der Daten von den IoT-Devices, Vermutlich übersehe ich etwas, aber inwieweit erhöht das die Sicherheit? Wenn "Robert'); DROP TABLE wetter;" in der Payload steht, wird der MQTT-Broker das doch speichern und glücklich an jeden Client weitergeben, der dieses Topic abonniert hat. So wird mit MQTT nur eine weitere Komponente eingebaut, die nichts zur Sicherheit beiträgt und die Angriffsoberfläche stattdessen sogar noch vergrößert. Mir ist auch nicht ganz klar, warum da TLS und ein Paßwort verwendet werden soll. Was spricht gegen die Authentifizierung über TLS, wie sie handelsübliche Web- und Web Application Server (Apache, Nginx, Tomcat, Wildfly, WebSphere) und auch zumindest Mosquitto bieten? Bestimmt habe ich etwas übersehen, bitte seid so lieb und erhellt mich.
Ein T. schrieb: > Vermutlich übersehe ich etwas, aber inwieweit erhöht das die Sicherheit? Natürlich wird man sich am Broker noch extra authentifizieren müssen. Das ist bei MQTT aber alles ungesichert und plain text. Darum läuft das über TLS. Damit ist sowohl die Anmeldung an den Broker gesichert als auch die Daten selbst gegen mitlesen. Es spricht auch nichts dagegen sich nur über TLS zu authentifizieren, wenn der Broker das kann.
:
Bearbeitet durch User
Angehängte Dateien:
-
nodered.png
9,5 KB
Ein T. schrieb: > Bestimmt habe ich etwas übersehen, bitte seid so lieb und erhellt mich. Der Angreifer muss das Passwort für den MQTT-Server haben, erster Fail. Aber denkbar, wenn er die Wetterstation abbaut, und den µC da drinnen auslesen kann. Dann kann der Angreifer sein "Robert'); DROP TABLE wetter;" dort publishen. Wenn der Consumer in 1990er-Jahre PHP geschrieben ist, und das per String-Concat in eine SQL-Query einsetzt, ja, dann ist das ausnutzbar. Wenn der Consumer in nodered zusammengeklickt ist, per Drag'n'Drop eine Verbindung zwischen MQTT-Topic-Quelle zu Influx-Datenfeld-Ziel gezeichnet, dann passiert nichts weiter. Das Influx-Target escaped die Parameter richtig, d.H. da wird kein ausführbares SQL-Kommando draus. Und die Influx-DB wird den Wert auch nicht speichern, weil die Tabelle für Wetterdaten sinnigerweise wohl float-Felder für Temperatur/Luftfeuchte usw. verwendet, d.H. die "bösen" Daten kommen dann auch nicht weiter an Grafana&co. Wie schon geschrieben, da muss man sich schon sehr anstrengen um einen ausnutzbaren Fehler reinzubekommen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Ein T. schrieb: >> Vermutlich übersehe ich etwas, aber inwieweit erhöht das die Sicherheit? > > Natürlich wird man sich am Broker noch extra authentifizieren müssen. > Das ist bei MQTT aber alles ungesichert und plain text. Darum läuft das > über TLS. Damit ist sowohl die Anmeldung an den Broker gesichert als > auch die Daten selbst gegen mitlesen. > Es spricht auch nichts dagegen sich nur über TLS zu authentifizieren, > wenn der Broker das kann. Okay, das verstehe ich, aber es ändert leider nichts an meiner Frage, inwieweit das die Sicherheit erhöhen würde. HTTP läßt sich problemlos über TLS absichern, das kennen wir unter dem Namen HTTPS. Ich bin mir beinah sicher, daß man über HTTP und über HTTPS auch Daten übertragen kann, und ich glaube, das habe ich sogar schonmal gemacht. Außerdem sind moderne HTTPS-Server fähig, ihre Dienste komplett über TLS zu schützen und für den Zugriff auf bestimmte Ressourcen (URLs) sogar verifizierte Client-Zertifikate vorauszusetzen. Die Clients, die Daten einliefern wollen, würden sich in meinem Szenario also mit ihrem Zertifikat authentifizieren und wären dank dieser Authentifzierung für Zugriffe auf jene Endpunkte autorisiert, die das Schreiben von Daten zulassen. Alle anderen Endpunkte können auf Wunsch mit verifizierten oder nichtverifizierten Browserzertifikaten und / oder üblichen Credentials, mithin: Benutzername und Paßwort gesichert werden. Alle diese Fähigkeiten bringen moderne Webserver wie Apache, nginx, aber auch Web Application Server wie Tomcat und Wildfly bereits mit. Mit ist unklar, was eine weitere nach außen exponierte Software nutzen soll -- außer die externe Angriffsoberfläche zu vergrößern, die Aufwände für Installation, Pflege, Wartung und Monitoring zu erhöhen die Sicherheit dadurch letztlich zu verringern. Also was wäre der tiefere Sinn, was ist der Nutzen, was verstehe ich nicht, was übersehe ich?
Ein T. schrieb: > Also was wäre der tiefere Sinn, was ist > der Nutzen, was verstehe ich nicht, was übersehe ich? die IoT-Geschichten verwenden gerne ESP8266. Die sind in ihren TLS-Möglichkeiten etwas eingeschränkt... Einfach ein Passwort statt Client-Zertifikat ist da die pragmatische, einfache Lösung. Für den Zugriff per Webrowser auf die UI/Dashboard/Graphen usw. authorisiert per Client-Zertifikat: Schöne Lösung, wenn's nur der eigene Computer ist. Ansonsten artet das in einem endlosen Support-Alptraum aus, die Diskussion hatten wir hier erst neulich, da ging's darum, warum ELSTER das nicht verwendet.
:
Bearbeitet durch User
z.B. hier ist beschrieben wie der ESP32 per HTTPS in InfluxDB schreiben kann: https://medium.com/@teebr/iot-with-an-esp32-influxdb-and-grafana-54abc9575fb2 Da InfluxDB https versteht ist der Umweg über MQTT nicht unbedingt nötig.
imonbln schrieb: > Also wenn du es wirklich von der Pike auf lernen willst, ist > Secure Engineering von Ross Anderson das Buch, dass du lesen solltest. > Aber das sind mehr als 1000 Seiten, die erstmal durchgearbeitet werden > wollen. Tatsächlich hab ich sogar eine Vorlesung mit Namen Security Engineering besucht und fand sie auch Recht interessant. Das hat die Paranoia aber nur bestärkt was alles schief gehen kann und vieles wie Buffetoverflows oder SQL Injections was ich da gelernt hab, sollte bei meiner Anwendung nicht auftreten. Hab an ein einfaches Format a la "TIMESTAMP;TEMPERATURE;HUMDITY;PRESSURE" gedacht, also nur integers/floats. Meine Hauptsorge wäre also wie mehrmals angesprochen der offene Port von meinem Server wo die Daten reingeschaufelt werden. :)
Εrnst B. schrieb: > Der Angreifer muss das Passwort für den MQTT-Server haben, erster Fail. ... oder der MQTT-Broker hat womöglich einen Fehler. Wie gesagt: die externe Angriffsoberfläche wächst um 50%, und zwar ohne irgendeine Notwendigkeit. Denn die Funktion des MQTT-Brokers -- nämlich eine verschlüsselte und entweder über Paßwort oder das Client-Zertifikat authentifizierte und autorisierte Übertragung von Daten -- kann der Web- oder Web Application Server ganz genauso bereitstellen. Und ein solcher Web- oder Web Application Server wird ohnehin zwingend benötigt, um die Graphen des TO abrufen zu können. Nüchtern betrachtet hat ein MQTT-Broker also keinen Nutzen, der sich nicht auch mit anderen, und zwar ohnehin zwingend benötigten Komponenten für den Anwendungsfall des TO abbilden läßt. Anstatt einen praktischen Mehrwert zu bieten, vergrößert ein MQTT-Broker die Angriffsoberfläche und außerdem die Aufwände für Depoyment, Betrieb und Lifecycle-Management. Mich beschleicht langsam der (bislang allerdings noch vage) Verdacht, daß ich es wieder einmal mit einem Reflex zu tun habe. Das kenne ich schon vom Thema Datenspeicherung, wo immer und in jedem Fall und Anwendungsfall ein paar kluge Menschen auftreten und erklären, für sowas müsse man natürlich unbedingt eine SQL-Datenbank (oder SQLite) benutzen. Für Datenübertragung scheinen ähnlich kluge Menschen gerne MQTT zu empfehlen. > Dann kann der Angreifer sein > "Robert'); DROP TABLE wetter;" > dort publishen. > > Wenn der Consumer in 1990er-Jahre PHP geschrieben ist, und das per > String-Concat in eine SQL-Query einsetzt, ja, dann ist das ausnutzbar. Soweit ich weiß, kann man auch in anderen Sprachen Strings zusammenfügen, für solchen Mist braucht man kein PHP. > Wenn der Consumer in nodered zusammengeklickt ist, per Drag'n'Drop eine > Verbindung zwischen MQTT-Topic-Quelle zu Influx-Datenfeld-Ziel > gezeichnet, dann passiert nichts weiter. Außer der MQTT-Broker hat einen kritischen Sicherheitsfehler. > Das Influx-Target escaped die Parameter richtig, d.H. da wird kein > ausführbares SQL-Kommando draus. Die Influx-Entwickler selbst mahnen, man solle "parametrized Flux queries" benutzen, um Injection-Angriffe zu verhindern. Daraus schließe ich, daß derartige Angriffsvektoren auch bei InfluxDB existieren. Ich kenne diese Software aber nur vom Hörensagen, da ich für InfluxDBs Anwendungsfälle lieber die PostgreSQL-Erweiterung TimescaleDB einsetze. > Wie schon geschrieben, da muss man sich schon sehr anstrengen um einen > ausnutzbaren Fehler reinzubekommen. Ich habe den TO hier so verstanden, daß er keine vorgefertigte Software installieren, sondern selbst eine schreiben will. Zwar ist Grafana eine feine Sache, aber wohl nicht ganz das, wonach der TO gefragt hat.
Εrnst B. schrieb: > Ein T. schrieb: >> Also was wäre der tiefere Sinn, was ist >> der Nutzen, was verstehe ich nicht, was übersehe ich? > > die IoT-Geschichten verwenden gerne ESP8266. Die sind in ihren > TLS-Möglichkeiten etwas eingeschränkt... Meines Wissens gibt es da auch den ESP32, der etwas leistungsfähiger ist als der ältere ESP8266. Wenn ich in die Dokumentation des Herstellers Expressif und die Website von WolfSSL schaue, finde ich TLS-Bibliotheken für ESP32 und im Netz auch einen Link, so eine TLS-Implementierung auf einem ESP8266 gezeigt wird. Auf Github gibt es auch ein Repository, das eine SSH-Implementierung für den ESP32 anbietet. Es scheint zu gehen -- wobei SSH natürlich den Vorteil hätte, daß es ohnehin vorhanden ist. Wenn TLS auf diesen kleinen Plattformen nicht gehen würde, dann würde das aber natürlich auch das MQTT-Protokoll betreffen. Dann müßte man sich für die Verschlüsselung seitens der Wetterstation in jedem Fall etwas anderes überlegen -- vielleicht eine symmetrische Verschlüsselung, deren Schlüssel nur den beiden Kommunikationspartnern bekannt ist. > Einfach ein Passwort statt Client-Zertifikat ist da die pragmatische, > einfache Lösung. Klar, das kann man machen, daran will ich mich gar nicht aufhängen. Aber wenn die oben erwähntten Libraries funktionieren, dann wären Zertifikate natürlich die eleganteste und sicherste Lösung für den oder die ESPs. > Für den Zugriff per Webrowser auf die UI/Dashboard/Graphen usw. > authorisiert per Client-Zertifikat: > Schöne Lösung, wenn's nur der eigene Computer ist. > > Ansonsten artet das in einem endlosen Support-Alptraum aus, die > Diskussion hatten wir hier erst neulich, da ging's darum, warum ELSTER > das nicht verwendet. Das sehe ich genauso, schließlich ist man nicht immer am eigenen Rechner und möchte möglicherweise auch anderen mal einen Zugang gewähren. Wobei eigene Zertifikate natürlich den charmanten Vorteil hätten, daß man sie auch wieder entziehen könnte.
Programmierer schrieb: > Tatsächlich hab ich sogar eine Vorlesung mit Namen Security Engineering > besucht und fand sie auch Recht interessant. Das hat die Paranoia aber > nur bestärkt was alles schief gehen kann und vieles wie Buffetoverflows > oder SQL Injections was ich da gelernt hab, sollte bei meiner Anwendung > nicht auftreten. Dann mußt Du die dabei erlernten Techniken, die ebendies verhindern sollen, konsequent und durchgängig benutzen. > Hab an ein einfaches Format a la > > "TIMESTAMP;TEMPERATURE;HUMDITY;PRESSURE" > > gedacht, also nur integers/floats. Also für mich sieht das nach CSV-Format aus. Das heißt natürlich, daß Deine Webapplikation in eine CSV-Datei schreiben muß. Sowas ist leider auch immer ein potentielles Einfallstor, und ich an Deiner Stelle würde mir Gedanken über weitere Verteidigungslinien wie AppArmor, Seccomp, Credentials und die anderen Möglichkeiten machen, die Linux bietet -- Stichworte: mount --bind mit den Optionen noexec, nodev und nosuid. Diese Verteidigungslinien kommen zum Tragen, wenn die Sicherheit eines Deiner Programme mal versagt. > Meine Hauptsorge wäre also wie mehrmals angesprochen der offene Port von > meinem Server wo die Daten reingeschaufelt werden. :) Der offene Port ist keine Gefahr, die lauert in dem Prozeß, der den Port geöffnet hat -- genauer: der die darauf ankommenen Daten verarbeitet. ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.