nullcheck
Goto Top

Webserver völlig autark möglich?

Hallo zusammen,

ich habe eine völlig autarke Webanwendung (eigenes Framework mit PHP,JS, SQL), ua. zur Auswertung von Maschinen/Sensor Daten und deren Visualisierung, sowie entsprechende Signale zurück an das Gerät als Steuerbefehl.
Alle Daten(!) von und zum server sind ausschliesslich Rohdaten, die durch eigene Funktionen wieder den ursprünglichen Zweck erfüllen.

Meine vorstellung ist dazu ein autarker Webserver (Ubuntu mit Plesk ohne Schnickschnack Tools von Drittanbietern) der tatsächlich nur über die Ports 443 (https), 22 (SFTP), 587 (SMTPS) zugäglich ist.

Da stellen sich mir folgende Fragen:
Ist das realistisch oder wie kann das erreicht werden?
Ist eine PHP-Installation mit Maria-DB tatsächlich autark?
Wie sicher ist Plesk ohne Zusatz-tools von Drittanbietern?

Wäre prima hier konstruktive Kritik/Inputs zu erhalten face-smile
Vielen Dank.

Content-Key: 5373033593

Url: https://administrator.de/contentid/5373033593

Printed on: May 27, 2024 at 16:05 o'clock

Member: Avoton
Avoton Apr 07, 2024 at 12:23:49 (UTC)
Goto Top
Moin,

Was genau meinst du denn mit "autark"?

Gruß,
Avoton
Member: Penny.Cilin
Penny.Cilin Apr 07, 2024 at 12:27:51 (UTC)
Goto Top
Gude,

ein Netzwerk / Webserver nur im internen Netz. Quasi ein Intranet. So würde ich es verstehen.

Gruss Penny.
Member: wiesi200
wiesi200 Apr 07, 2024 at 12:29:27 (UTC)
Goto Top
Hallo,

ich verstehe das mit Autark auch nicht, aber man beim Webserver auch auf Plesk verzichten. Und Ubuntu währ jetzt auch nicht Grad meiner ersten Wahl wenn ich so wenig wie möglich "Bloatware" haben will.
Member: radiogugu
radiogugu Apr 07, 2024 at 12:32:13 (UTC)
Goto Top
Mahlzeit.

Ein separates Netzwerk (VLAN) auf der Firewall / dem Router und Switches einrichten.
Anschließend die gewünschten Ports mit entsprechendem Regelwerk versehen und nur Zugriff darauf und auf den Webserver für gewünschte Clients / Maschinen erlauben.

Damit ist das Teil vom übrigen Netzwerk abgeschottet.

Das sollte schnell zum Fliegen gebracht werden können.

Gruß
Marc
Member: Frank
Frank Apr 07, 2024 updated at 18:02:39 (UTC)
Goto Top
Dann schau dir https://frankenphp.dev/ an ­čśÄ

PHP Webseite ganz ohne Webserver.
Member: DivideByZero
DivideByZero Apr 07, 2024 at 15:08:15 (UTC)
Goto Top
ich habe eine völlig autarke Webanwendung (eigenes Framework mit PHP,JS, SQL)
Meine vorstellung ist dazu ein autarker Webserver (Ubuntu mit Plesk ohne Schnickschnack Tools von Drittanbietern) der tatsächlich nur über die Ports 443 (https), 22 (SFTP), 587 (SMTPS) zugäglich ist.

Ein Webserver kann mit Ports 22 und 587 nichts anfangen. Also es soll vermutlich deutlich mehr sein, als nur ein Webserver, vermutlich eben auch SSH und Mailserver. Aber selbst das geht natürlich problemlos.

Jeder Webserver oder Mailserver ist autark und arbeitet vor sich hin. Macht halt nur keinen Sinn, wenn dann niemand darauf zugreifen kann, daher der Anschluss an die weite Welt.

Nur, wie auch bei den anderen, die Frage, was Du mit autark meinst: Autark ohne Verbindung ins LAN oder Internet? Dann geht natürlich kein Mailverkehr, aber sonst ist das problemlos möglich, solange die eingesetzten Serverdienste nicht nach Hause telefonieren müssen (Lizenzabfragen oä).

Gruß

DivideByZero
Member: maretz
maretz Apr 07, 2024 at 15:50:07 (UTC)
Goto Top
Wie "autark" darf es denn sein? Generell kannst du den Server natürlich völlig dichtnageln -> selbst Port 80/443 brauchst du nicht, dann setzt du eben via Port 22 nen SSH-Tunnel (oder direkt nur via VPN) davor. Ob du dann https oder plain http machst ist dir überlassen - weil bei https brauchst du ja irgendwie wieder nen Zertifikat...

Dein PHP / MySQL / Apache kann natürlich auch auf dem Server laufen, ist sogar bei kleineren Umgebungen der normale Standard. Ich würde allerdings auf Plesk dann auch verzichten - das ding is in 5 min per Hand auch ohne eingerichtet und Plesk ist nur eine zusätzliche mögliche Schwachstelle...
Member: commodity
commodity Apr 07, 2024 updated at 18:35:12 (UTC)
Goto Top
autarker Webserver (Ubuntu mit Plesk ohne Schnickschnack Tools von Drittanbietern) der tatsächlich nur über die Ports 443 (https), 22 (SFTP), 587 (SMTPS) zugäglich ist.
Blech oder VM mit Debian o.ä., Dienste drauf, die Du brauchst (Web, Mail, SSH), autarker geht es nicht. Container geht sicher auch.

Jeder Server ist "autark" - bis Du ihn mit anderen verbindest face-wink OK, eine VM ist natürlich nicht ganz autark i.e.S., die braucht schon ihren Host. Ebenso ein Container. Die Maschine ist dennoch isoliert. Der Terminus autark ist in der Tat schwierig zu interpretieren.
Ich trenne bei Servern grundsätzlich nach Funktion und ich denke, da bin ich nicht allein face-wink

Viele Grüße, commodity
Member: tech-flare
tech-flare Apr 07, 2024 at 20:49:07 (UTC)
Goto Top
Zitat von @Nullcheck:

Hallo zusammen,
Hallo

ich habe eine völlig autarke Webanwendung (eigenes Framework mit PHP,JS, SQL), ua. zur Auswertung von Maschinen/Sensor Daten und deren Visualisierung, sowie entsprechende Signale zurück an das Gerät als Steuerbefehl.
Alle Daten(!) von und zum server sind ausschliesslich Rohdaten, die durch eigene Funktionen wieder den ursprünglichen Zweck erfüllen.

Meine vorstellung ist dazu ein autarker Webserver (Ubuntu mit Plesk ohne Schnickschnack Tools von Drittanbietern) der tatsächlich nur über die Ports 443 (https), 22 (SFTP), 587 (SMTPS) zugäglich ist.
Das widerspricht sich, wenn du Plesk einsetzt.


Da stellen sich mir folgende Fragen:
Ist das realistisch oder wie kann das erreicht werden?
Ist eine PHP-Installation mit Maria-DB tatsächlich autark?
Wenn du intern meinst und ggf. ohne Internet nach der Instalaltion --> Ja

Wie sicher ist Plesk ohne Zusatz-tools von Drittanbietern?
Wozu Plesk für Apache, PHP und MySQL?

Gruß
Member: Nullcheck
Nullcheck Apr 07, 2024 updated at 21:51:01 (UTC)
Goto Top
Hallo,

Danke für euer Feedback.
Mit Autark meine ich ohne irgendwelche "versteckte" Kommunikation mit anderen servern, ausgenommen die ich über meine Anwendung steuere.

Das Plesk diesen Vorstellungen wiederspricht ist mir bewusst, daher meine Frage zur Sicherheit von Plesk (ohne der möglichen Zusatz Funktionen) aus eurer Sicht.

Plesk, weil ich bin recht fit in der Anwendungsentwicklung. Meine Kenntnisse in der Serveradministration jedoch nicht wirklich ausreichend ohne eine solche Unterstützung. Die Funktion Fail2Ban spricht me für Plesk, wäre also ein kalkuliertes Risiko, Plesk zu verwenden.

(Nachtrag: Es ist ein RootServer mit unterschiedlichen Domains und Webprojekten.)

Wenn ich die bisherigen Antworten zusammenfasse, habe ich mit meiner konstelation lediglich die Schwachstellen Ubuntu und Plesk. Korrekt?
Die Ports für FTP & HTTP, haben ausschlisslich Zugriff auf das zugewiesene Verzeichnis mit Unterverzeichnissen, oder?
(Sämtliche Abfragen bzw. Code Injection werden schon als $_SERVER - Variable "neutralisiert").

Insgesamt geht es mir um eine höchstmögliche Datensicherheit, wofür ich unbekannte Schnittstellen von vornherein absichern bzw. deaktivieren kann.

Vielen Dank und Gruß
Member: Avoton
Avoton Apr 08, 2024 at 05:26:52 (UTC)
Goto Top
Moin,

Das
Es ist ein RootServer

Und das

Meine Kenntnisse in der Serveradministration jedoch nicht wirklich ausreichend

Widersprechen sich aber sehr.

Wenn du den Rootserver direkt im Netz hängen hast ohne dass du genau weißt was du tust, ist deine Anwendung ganz schnell das kleinste Problem...

Gruß,
Avoton
Member: SlainteMhath
SlainteMhath Apr 08, 2024 at 06:29:13 (UTC)
Goto Top
Moin,

das was @Avoton geschrieben hat, plus

Die Ports für FTP & HTTP,
Wenn du nach den Protokollen fragst, bist du datensicherheits/-schutz technisch schon raus!

... haben ausschlisslich Zugriff auf das zugewiesene Verzeichnis mit Unterverzeichnissen, oder?
Sofern du die Dienste korrekte konfiguriert hast, die Verzeichnisberechtigungen korrekt sind und die Dienste und dein PHP Code keine Fehler oder Schwachstellen beinhalten: Ja, wahrscheinlich.

lg,
Slainte
Member: Nullcheck
Nullcheck Apr 08, 2024 at 11:24:12 (UTC)
Goto Top
@Avoton, SlainteMhath
Nun, nur weil ich seit Jahren 4 Rootserver betreibe und in Anbetracht so macher "Nerds", ziehe ich es vor meine Kenntnisse als nicht wirklich ausrreichend für eine Bezeichnung wie Systemadministrator, zu bezeichnen...
Und... bitte alles lesen.... (Ports/Protokolle)

Meine Fragen beziehen sich auf allgemeine Ansichten und Dokumentationen, doch ist es in der Praxis tatsächlich so?
Member: commodity
commodity Apr 08, 2024 at 13:28:22 (UTC)
Goto Top
Insgesamt geht es mir um eine höchstmögliche Datensicherheit,
für geschulte Administratoren ein Witz, bei dieser Prämisse Ubuntu und Plesk einzusetzen. Aber es gibt auch Leute, die das mit dem IIS machen würden - da bist Du doch schon bedeutend weiter face-smile

Das, was die Kollegen vorstehend schreiben, ist völlig korrekt. Eitelkeiten bitte mal kurz ablegen. Nur weil Du ein paar Erfahrungen im Serverbetrieb hast, heißt das nicht, dass Du das (auch nur einigermaßen) sicher umsetzen kannst. Du verstehts ja von den administrativen Grundlagen wenig bis nichts, sonst wäre Plesk wohl kein Thema. Fail2ban z.B. ist auch keine Funktion von Plesk sondern kannst Du auf jedem Linux-Server installieren. Anpassen musst Du es ohnehin, da genügt die Plesk-UI ganz sicher nicht.

Wenn das ein wichtiges Projekt ist, holt man sich Adminstratoren ins Boot (oder lernt selbst ein paar Jahre). Wenn das eine eher exotische Eigenentwicklung ist, braucht man für den Pilotbetrieb nicht
höchstmögliche Datensicherheit,
(was immer das ist) und wird sie auch nicht gewährleisten können, indem man das in einem Forum abklärt. Da können sich die Kollegen hier im Forum noch so viel Mühe geben (was viele tun). Du bist ja scheinbar nicht mal vom Plesk wegzubekommen.

Damit was Positives bleibt: Natürlich kannst Du mit dem Angebot eines jeden Hosters einen einigermaßen sicheren Server betreiben. Da sind Ubuntu und Plesk ja oft im Team. Das ist dann aber sicher nicht höchstmögliche Sicherheit und natürlich hängt es auch davon ab, wie Du es einrichtest. Man muss halt Vorsichtig sein, mit solch anspruchsvollen Formulierungen - und in den Ansprüchen realistisch bleiben.

Viele Grüße, commodity
Member: Nullcheck
Nullcheck Apr 08, 2024 at 19:51:08 (UTC)
Goto Top
da bist Du doch schon bedeutend weiter face-smile

Asche auf mein Haupt face-wink

Es ist mir schon bewusst das die Anmerkungen völlig korrekt sind.
Doch müsste man dann nicht generell von Root-Server Abstand nehmen wenn man die nicht 24h adminstrativ selbst betreuen kann?* Oder Server-Housing mit Administrtiven Dienstleistungen durch das Rechenzentrum in Anspruch nimmt?

Was genau ist denn an Plesk auszusetzen, wo sind denn genau die schwachstellen?

Interessant finde ich immer die Anmerkungen zu den "unsicheren" Tools zur Serveradministration und wenn man genau hinschaut, haben genau diese Administrtratoren im HTML Public Verzeichnis, Workframes wie Wordpress etc am start... WEIL: Kundenwunsch oder der IT'ler zu wenig Kenntnisse in HTML/PHP, eg. hat.
So etwas ist zum Beispiel für mich ein NoGo.

Ich denke so haben viele Systeme Ihre "heimlichen" administrativen Schwachstellen, die es gilt so gut wie möglich "abzudichten".
Bei mir ist es in dem Fall halt die durchaus übliche Konstellation Ubuntu/Plesk, was ich bestmöglich absichern möchten und deshalb diese Anfrage hier gestartet habe.
Vielen Dank für die bisherige konstruktiver Kritik, doch brauchbare Lösungsansätzen von den Profis wäre auch nicht schlecht face-wink

Viele Grüsse "Nullcheck". Wie der Name schon sagt... face-wink
Member: commodity
commodity Apr 08, 2024 at 21:01:04 (UTC)
Goto Top
Was genau ist denn an Plesk auszusetzen, wo sind denn genau die schwachstellen?
Alter Finne! Du bist Entwickler. Plesk ist Software. Du solltest wissen, wie man Schwachstellen von Software recherchiert. (Das Finden ist noch ein ganz anderes Thema).
https://www.cvedetails.com/vulnerability-list/vendor_id-1049/Plesk.html
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=plesk

Der Punkt ist, dass man in sicheren Umgebungen nur Dienste einsetzt, die zwingend für den Betrieb der Software benötigt werden und/oder der Sicherheit dienen. Selbst die Administration wird dann eingeschränkt. Einen sicherheitsrelevanten Server würde ich zB nicht einmal per SSH ins Netz hängen, sondern ein VPN vorschalten. Und ich bin nur ein kleiner Quereinsteiger-Admin mit ein paar Minikunden.

doch brauchbare Lösungsansätzen von den Profis wäre auch nicht schlecht
Mal richtig lesen wäre auch nicht schlecht face-wink
Leseschwäche ist ja immer ein Thema in der IT. Insbesondere die, bei der nur gelesen wird, was man gern lesen wollte. Konkret (und sehr konstruktiv) vorgeschlagen wurde (hier nochmals zur Kenntnis):

  • Auf Plesk verzichten
  • Auf Ubuntu verzichten
  • mindestens Debian einzusetzen
  • Fail2ban selbständig einzusetzen
  • Dienste zu beschränken
  • Ports zu beschränken
  • Verzeichnisberechtigungen zu beschränken
  • Code härten
  • https://frankenphp.dev/ anzusehen
  • Nicht FTP und HTTP einzusetzen - beides überholte und längst ersetzte Protokolle
  • Kenntnisse und Erfahrungen zu erwerben - eine leider häufig unterschätzte Maßnahme - der Weg hier ins Forum ist ein erster guter Schritt - es gibt auch etliche weitere
  • Administrator hinzuziehen

Und weil Du oben konkret fragst: Ja, ein verantwortlicher Administrator beachtet in der Praxis diese Punkte - soweit sie technischer Natur sind (also den Code härten würde ich nicht. Das muss der machen, der ihn geschrieben hat face-wink). In maximal sicheren Umgebungen kommt noch einiges hinzu, z.B. administratives Berechtigungsmanagement, interne Sicherheit, externe physische Sicherheit, Backupmanagement, etablierte Prozesse/Unternehmenspolicies, Dokumentationsprozesse, Monitoring, Audits, Pentests fallen mir dazu spontan ein.

Ich finde es wirklich super, wenn Du eine relevante Software entwickelst (die hoffentlich Open Source ist, damit sie sicher bleibt/noch sicherer wird - Vorsicht vor Jia Tan!). Bleib dabei und setze das um. Für den administrativen Teil muss da aber noch vieles wachsen. Wenn Du die Ressourcen dafür nicht hast: Schaffe Dir ein Team. Ohne geht es ohnehin nicht, wenn man was von Relevanz macht. Wenn Ihr dann die Prozesse geplant habt, werden Deine Fragen auch konkreter und hier beantwortbarer als die Ausgangsfrage des Threads.

Oder spring einfach ins kalte Wasser. Es gibt andere, die sich deutlich weniger für (vielleicht) relevantere Daten einsetzen - jedenfalls haben die offenbar hier nicht gefragt:
Microsoft habe sich eine »Kaskade vermeidbarer Fehler« geleistet, die die Folge einer unzureichenden Sicherheitskultur seien.
https://www.spiegel.de/netzwelt/netzpolitik/microsoft-regierungskommissi ...
Allerdings hat MS wahrscheinlich auch mehr Budget für die daraus folgenden Haftungsstreitigkeiten face-smile

Viele Grüße und good luck, commodity
Member: Nullcheck
Nullcheck Apr 09, 2024 at 00:30:14 (UTC)
Goto Top
@commodity
Vielen Dank für deine wertvolle Zeit und deine Ausführung.

Über die ersten vier Punkte und den letzten werde ich mir nun tatsächlich mal Gedanken machen, auch wenn Plesk sich in der Vergangeheit recht müht auf dem Markt Bestand zu haben.
Die restlichen Punkte sind selbstverständlich seit jeher umgesetzt.

Viele Grüße face-smile
Member: maretz
maretz Apr 09, 2024 at 02:01:55 (UTC)
Goto Top
Fangen wir doch mal einfach an - du solltest als SW-Entwickler doch schonmal die Grundregel gehört haben das jede (nicht-triviale) Software fehler hat, oder? Dabei spielt es gar keine Rolle ob du die als Einzelkämpfer baust - oder da Konzerne mit 100.000 Leuten hinterstehen. Warum glaubst du also das Plesk davon ausgenommen ist? Nur das du damit eine potenzielle Angriffsfläche direkt mal ins Web stellst, gute Idee, oder?

Dann ist immer noch die Frage - wer soll am Ende denn auf deinen Webserver zugreifen dürfen? Denn davon hängt ja ab wie sicher man den bauen kann und will. Wenn es sich um eine überschaubare Gruppe zB. handelt würde ich eben den Zugriff nur per SSH (und dann entsprechende SSH-Tunnel) erlauben. Alternativ per VPN wenns zB von Firmen benötigt wird (dann geht nen Site-2-Site und fertig). Denn grade hier gilt eben: Jeder Dienst der im Internet gar nicht erreichbar ist bedeutet auch automatisch das dieser Dienst nicht so häufig angegriffen wird. FTP würde ich dabei mal eben direkt mit durch SCP (Windows zB. WinSCP als Client) ersetzen - schon kann ich mir das zusätzliche Protokoll direkt komplett einsparen UND habe die Übertragung gleich noch gesichert (und noch einige andere nette Seiteneffekte dazu). Bei SSH noch root-Login abschalten und am besten auch noch password-auth deaktivieren (dann solltest du nur einen Weg haben falls dein Key mal verloren geht - zB. via Konsole), dann ist SSH schon recht sicher.

Ob du jetzt am Ende Ubuntu, Debian oder eines der anderen 100.000 Distri-Pakete nimmst halte ich dagegen erstmal für sekundär. Die Distri an sich macht nicht die Sicherheit aus, das macht eher die Person davor. Wenn ich bei nem Debian einfach nur alles raufballere ist das nicht besser oder schlechter als wenn ich das bei ubuntu mache. Am Ende muss eh die Person davor dafür sorgen das die Systeme auch abgesichert und gepflegt werden. Solange die Distri also noch gepflegt wird ist das _für mich_ eher eine Geschmacksfrage.
Member: Nullcheck
Nullcheck Apr 09, 2024 at 09:34:13 (UTC)
Goto Top
@maretz
Danke für deinen Ansatz zu SSH.
SSH nutze ich der regel nicht und habe es nur in einer einzigen Konstellation für den Notfall offen.

Mein persönliches Fazit womit ich das Thema hier für mich auch erstmal abschliessen möchte:

Debian soll tatsächlich stabiler sein, benötigt jedoch entsprechende (tiefgehende) Erfahrung um es auch tatsächlich sicher zu machen und stabil zu halten.
Ubuntu ist komfortabler, hat jedoch wohl einige Pakete die nicht wirklich sauber/sicher sein können.
Wen es intersiert und die wohl seit Jahren schwelende Endlosdiskusion Debian vs. Ubuntu verolgen möchte, finde via Goggele Lesetstoff für mindestens 10 Jahre face-wink

Schlussendlich ist wohl immer die persönliche (und zeitliche) Ansichtssache und wie tief man sich mit der Server-Administratur auseinander setzen möchte, entscheidend.
Analog der Einsatz von Plesk, was man wohl als kalkuliertes Risiko bezeichnen könnte, jedoch auch entsprechend sichern kann.

Ich Danke allen für Schreibern für Ihre konstruktive Kritik und Inputs.