WebServer-Sicherheitsfragen

[Lerry]

Hallo, falls ich hier falsch bin und in die Sicherheitsabteilung gehöre, bitte verschieben.

Ich habe mir einen Webserver aufgesetzt, um meine Daten via Owncloud von außen zugänglich zu machen. Diesbezüglich habe ich jedoch einige Fragen im Bezug auf den Sicherheitsaspekt.

Daten:
Der Server soll von außen über folgende Ports erreichbar sein
-Port 80 (SSH)
-Port 443 (Owncloud, HTTPS)

Auf dem Server wurde ein LAMP-Server mit Owncloud Installiert. Bezüglich der Sicherheit wurden folgende Vorkehrungen getroffen:
-ssh: kein root login und nur über schlüsselpaare einloggbar
-fail2ban (für owncloud und ssh, auch wenn nur schlüsselpaare erlaubt sind)
-ufw (nur 80 und 443 nach außen offen)
-apache mod_evasive (gg. eventuelle DDOS attacken und brute-force)
-gegen spoofing in /etc/host.conf folgendes eingetragen

Code: Alles auswählen

order bind,hosts
nospoof on

-chkrootkit installiert
-rkhunter installiert
-tiger installiert

Falls weitere Systemangaben fehlen reiche ich diese gerne nach. War mir nicht sicher welche alle nötig sind.


Zu den Fragen:
1) Habe ich eine wichtige Einstellung/ ein wichtiges Sicherheitspaket vergessen was auf gar keinen Fall fehlen sollte?

2) Muss ich chkrootkit, rkhunter oder tiger speziell konfigurieren? Ich habe sie bis jetzt nur installiert und lasse sie ab und an eine überprüfung starten. Und kann mir jemand Literatur für tiger empfehlen, damit ich lerne die warnungen zu lesen, damit nicht der Windows effekt auftritt und ich die Warnungen alle ignoriere.

3) Welche Log-Files muss ich im Auge behalten? Bis jetzt überprüfe ich:

Code: Alles auswählen

	-/var/log/mod-evasive log-file
	-/var/www/owncloud/data/owncloud.log 
	-fail2ban log
	-/var/log/apache2/access.log
	-/var/log/messages

Und schaue da nach Fehlgeschlagenen einlog-Versuchen und ufw-Blocks. Welche weiteren logs sind wichtig? Was/Worauf ist bei den logs zu beachten?

4) Ich habe in letzter Zeit in der /var/log/apache2/access.log Datei vermehrt, wahrscheinlich böswillige Anfragen entdeckt.

Code: Alles auswählen

xxx.xx.xxx.xxx - - [03/Jun/2014:08:42:23 +0200] "GET /cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26 allcfgconv -C voip -c -o - ../../../../../var/flash/voip.cfg%26 HTTP/1.1" 404 531 "-" "Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
xxx.xx.xxx.xxx - - [03/Jun/2014:12:37:35 +0200] "GET /phpTest/zologize/axa.php HTTP/1.1" 404 505 "-" "-"
xxx.xx.xxx.xxx - - [03/Jun/2014:12:37:36 +0200] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 509 "-" "-"
xxx.xx.xxx.xxx - - [03/Jun/2014:12:37:37 +0200] "GET /pma/scripts/setup.php HTTP/1.1" 404 502 "-" "-"
xxx.xx.xxx.xxx - - [03/Jun/2014:12:37:38 +0200] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 506 "-" "-"

Kann mir jemand erklären was diese genau bedeuten,was die Absicht dahinter ist und was man bei Erfolgt damit erreichen kann. Oder kann mir jemand sagen, nach welcher Literatur ich suchen muss, um das zu lernen? Hierzu auch noch die Frage, wie ich solche Anfragen verhindere und nur noch Owncloud über den Server erreichbar ist, oder auch hierzu Literaturhinweise.

5.) Ist es möglich mit einem Skript zeitlich begrenzt bestimmte IPs mit ufw zu erlauben (damit überhaupt nur noch meine Anfrgen durchkommen), oder ist das Sicherheitstechnisch nicht zu empfehlen?


Ich weiß dass wahrscheinlich vieles/alles im Internet schon oft durchgekaut wurde, ich verliere jedoch langsam den Überblick und bitte deshalb eine erfahrene Community um Hilfe. Falls die Fragen zu banal/einfach sind auch hinweise auf andere Threads gerne gesehen.


Vielen Dank im Vorraus
Lerry

[wanne]

Habe ich eine wichtige Einstellung/ ein wichtiges Sicherheitspaket vergessen was auf gar keinen Fall fehlen sollte?

Zuerstmal grundsätzlich ist für Sicherhet erstmal viel wichtiger was man nicht macht als was man macht. Du machst deinen Rechner garantiert nicht sicherer dadurch, dass du nochmal 10.000 Pakte installierst. Prinzipiell ist jede Zeile Code, eine die einen Fehler enthalten kann. Gerade deswegen halte ICH auch nicht so besonders viel von tools, die Angriffe abfangen, die so oder so in's leere laufen würden. Entsprechend zu 4.: Das ganz gewöhnliche Hintergrundrauschen. Da versucht einer Ton von irgend einer anfälligen Webcam abzufangen und der rest ist die klassische Suche nach einem unkonfigurierten phpMyAdmin um da dann das defautl-passwort zu benutzen. Da du höchstwarscheinlich beides nicht hast – einfach ignorieren.
Mr. Miyagi sagt: „beste Abwehr von Schlag: – Nicht da sein.“ oder so ähnlich. (Karate Kid)

Was das wichtigste ist, ist, dass du dein PHP aktuell hälltst. Und das heißt eben nicht einmal im Monat nach updates gucken sondern täglich. Ansonsten kenne ich mit owncloud nicht so gut aus aber bei solchen dingern gibt's ganz gerne mal konfigurationsoberflächen. Wenn man die überhaupt bestehen lässt würde ich empfehlen die nur lokal erreichbar zu machen. Da setzen die meisten sachen an. (Wie du in deinen Logs ja schon gesehen hast.) Dann sollten Datenbanken nicht direkt von ausen erreichbar sein und starke passwörter verwendet werden.
Alles selbstverständlcihkeiten aber wenn du dir defacement wettbewerbe statistiken oder mal guckst wie die clients in den Botnetzen die dich da angreifenanguckst dann sind da Mindestens 90% eben genau wegen solchen primitiven Sachen gehackt worden.
Guck dir einfach mal die Server hinter den IPs an, die du da ausgeix hast. Ich wette da gibt öffentlich zugängliche phpmyadmin oberflächen oder mysql datenbanken und veraltetes PHP.

[Lerry]

Vielen Dank für die Antwort.

Wegen dem nicht da sein: wenn ich mit ufw eine bestimmte IP durchlasse und alle anderen sperre, bin ich dann nach Außen sichtbar für die geblockten IPs (mit portscan o.ä.)?

Und gibt es ne Möglichkeit, nur bestimmte Ordner im /var/www zugänglich zu machen und nicht das komplette Verzeichniss? Also Anfragen die nicht nach owncloud gehen ins leere laufen lassen?

[irgendwas]

Statt ein neues Thema aufzumachen, häng ich mich mal mit dran..

Ich hab meinen Webserver zwar noch nicht zu 100% online (bisher nur OpenVPN), aber dennoch ein paar Fragen.

Auf dem Server soll WordPress, Owncloud, OpenVPN, phpmyadmin und pyload laufen. (Nginx)
Bisher eingerichtet ist:
- SSH mit geändertem Port, Anmeldung nur Benutzer1 (kein root) und mit Key+Passphrase
- Fail2Ban (eingerichtet für WordPressLogin, Owncloud und SSH)
- für alle "Webinstallationen" (WordPress, Owncloud, phpmyadmin) TCP/IP mit getrennten "php5-fpm Pools" mit unterschiedlichen Ports und Benutzer+Gruppen
- ufw für nur die benötigten Ports
- MySQL nur für "localhost" und meinen RaspberryPi zugänglich
- starke Passwörter für alle Benutzer, auch z.B. rsync (>16 Stellen mit Sonderzeichen)
- SSL-Zertifikate mit TLS und entsprechenden SSL-Ciphern (Note ssllabs.com: A+)
von anderen Paketen hab ich bisher abgesehn, weil wie "wanne" schon sagte

Zuerstmal grundsätzlich ist für Sicherhet erstmal viel wichtiger was man nicht macht als was man macht. Du machst deinen Rechner garantiert nicht sicherer dadurch, dass du nochmal 10.000 Pakte installierst. Prinzipiell ist jede Zeile Code, eine die einen Fehler enthalten kann. Gerade deswegen halte ICH auch nicht so besonders viel von tools, die Angriffe abfangen, die so oder so in's leere laufen würden.

Owncloud reagiert auf einem hohen 5-Stelligen Port, OpenVPN auf Standard und WordPress soll später auf 443 laufen.

Vielleicht habt ihr noch Tipps oder empfehlenswerte Webseiten, um die Sicherheit zu erhöhen?

Danke im voraus,
Daniel

EDIT: Die php.ini hab ich auch bearbeitet, bin aber grad unterwegs und reich sie gerne nach

[Dimejo]

Die größte Schwachstelle dürfte bei Dir die verwendete PHP-Software sein. Also am besten die Nachrichten der Hersteller abbonieren, um immer am Laufenden bezüglich Updates zu sein. Gut wäre es auch, wenn Du Deine PHP-Pools an die verwendete Software anpasst (open_basedir, disable_functions etc.).

[irgendwas]

Alles klar, danke für den Tipp

[uname]

Eine recht gute zusätzliche und vor allem unabhängig von PHP einzusetzende Sicherheitsfunktion ist "htaccess" [1], die man zur Absicherung von Administrationsbereichen einsetzen sollte. Da ich Owncloud nicht nutze weiß ich jedoch nicht ob es dafür sinnvoll ist.

[1] https://de.wikipedia.org/wiki/.htaccess

[irgendwas]

.htaccess kenn ich bereits und hab ich vorher auch sehr gerne genutzt (auf dem Server läuft aktuell Nginx).., wobei ich das für WordPress noch integrieren möchte. Für Owncloud wäre es auch eine Option, wobei ich nicht weiß wie das mit den WebDAV Clients aussieht..

Ich probiers aus und berichte dann

[irgendwas]

Ich meld mich wieder zurück mit ein paar weiteren Fragen

Ich hab nun soweit alles eingerichtet. Auf dem Server läuft zum einen Owncloud (hoher 5-Stelliger Port) und eine reine HTML-Webseite (mit WordPress lokal erstellt und dann nur den statischen HTML Code hochgeladen - denke das ist bei den unregelmäßigen Aktualisierungen am sinnvollsten).

1. Mit ssllabs.com erhalte ich ein A+, wobei mich das hier noch stört:

Code: Alles auswählen

TLS_RSA_WITH_AES_128_CBC_SHA  No FS

[/s]
-> Erledigt (https://mozilla.github.io/server-side-t ... generator/)

Code: Alles auswählen

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

2. Bei securityheaders.io erhalte ich für die Owncloud Instanz ein A, aber Public-Key-Pins rot markiert.

3. Die Webseite erreicht bei securityheaders.io allerdings nur ein F
(wegen Content-Security-Policy , Public-Key-Pins , X-Frame-Options , X-XSS-Protection , X-Content-Type-Options)

In wieweit ist wäre z.B. der dritte Punkt gefährlich? Mein Bauchgefühl sagt mir, dass das für einen reinen HTML-Code nicht relevant ist, weil kein PHP eingesetzt wird.

/EDIT: Da das ein letsencrypt Zertifikat ist, stell ich mir die Sache mit dem Public-Key-Pins schwierig vor, weil das Zertifikat regelmäßig erneuert wird..

/EDIT2: Für alle, die es interessiert:
Diese Zeilen funktionieren bei mir in /etc/nginx/sites-available/default zwischen server { und }

Code: Alles auswählen

  add_header X-Frame-Options SAMEORIGIN;
  add_header X-Content-Type-Options nosniff;
  add_header X-XSS-Protection "1; mode=block";
  add_header Content-Security-Policy [...] ;
  

[Dimejo]

3. Die Webseite erreicht bei securityheaders.io allerdings nur ein F
(wegen Content-Security-Policy , Public-Key-Pins , X-Frame-Options , X-XSS-Protection , X-Content-Type-Options)

In wieweit ist wäre z.B. der dritte Punkt gefährlich? Mein Bauchgefühl sagt mir, dass das für einen reinen HTML-Code nicht relevant ist, weil kein PHP eingesetzt wird.

Grundsätzlich gilt natürlich: "Desto sicherer, desto besser!" Aber bei einer kleinen und privaten Seite zahlt sich meiner Meinung nach der Aufwand nicht aus.

Bei Public Key Pinning wäre ich übrigens vorsichtig. Erstes kann man damit viel falsch machen, und sich und andere für längere Zeit von der Seite aussperren (vor allem wenn man kein zweites Zertifikat gepinnt hat). Zweitens ist es nur eine halbe Lösung, weil es voraussetzt, dass man die "richtige Seite" schon einmal besucht hat. Die bessere (aber auch komplexere) Lösung ist hier DANE.

/EDIT: Da das ein letsencrypt Zertifikat ist, stell ich mir die Sache mit dem Public-Key-Pins schwierig vor, weil das Zertifikat regelmäßig erneuert wird..

Du kannst auch die CA pinnen.

[uname]

Auf https://www.ssllabs.com/ssltest kannst du mal dein SSL-Zertifikat testen lassen. Auch könntest du SSL-Client-Zertifikate verwenden.

Die Wordpress-Daten nur statisch hochzuladen war eine gute Idee.
Wenn die Seite nicht zu anspruchsvoll ist gibt es sehr gute Alternativen zu Wordpress. Auch gibt es CMS oder Blogs ohne Datenbanken wie z.B. http://www.cmsimple.org .

[irgendwas]

Bei Public Key Pinning wäre ich übrigens vorsichtig. Erstes kann man damit viel falsch machen, und sich und andere für längere Zeit von der Seite aussperren (vor allem wenn man kein zweites Zertifikat gepinnt hat). Zweitens ist es nur eine halbe Lösung, weil es voraussetzt, dass man die "richtige Seite" schon einmal besucht hat. Die bessere (aber auch komplexere) Lösung ist hier DANE.

DANE hört sich gut an, aber ich muss mich dazu noch etwas einlesen, bis ich das umsetzen kann.. Komplexer ist es ^^

Auf https://www.ssllabs.com/ssltest kannst du mal dein SSL-Zertifikat testen lassen

Das hab ich schon gemacht und bekomm für die Webseite und die Owncloud Instanz ein A+ (wobei ich für Owncloud strengere SSL-Cipher verwende und z.B. nur TLS 1.2 anbiete)

Wenn die Seite nicht zu anspruchsvoll ist gibt es sehr gute Alternativen zu Wordpress. Auch gibt es CMS oder Blogs ohne Datenbanken wie z.B. http://www.cmsimple.org .

Danke für den Tipp Ich nutze (immer noch) WordPress nur, weil ich zu beginn wesentlich mehr Artikel veröffentlicht hab und die Seite nun mehr oder weniger archivieren wollte. Aber CMSimple behalt ich mir mal für vielleicht zukünftige Projekte im Hinterkopf

[irgendwas]

Hmm...okay, also so ganz versteh ich das Einrichten von DANE noch nicht..

Auf dieser Seite (https://de.ssl-tools.net/tlsa-generator) kann man einen TLSA Eintrag generieren, der ja anscheinend für DANE benötigt wird


dadurch erhalte ich dann z.B.:

Code: Alles auswählen

_443._tcp.meinedomain.de. IN TLSA 3 1 1 ****************************************************************

..aber was mach ich dann damit?! Kommt das in die /etc/nginx/sites-available/default?

[wanne]

Auf dieser Seite (https://de.ssl-tools.net/tlsa-generator) kann man einen TLSA Eintrag generieren, der ja anscheinend für DANE benötigt wird

Edit: hash-slinger macht das gleiche. mit dem Kommando tlsa.

..aber was mach ich dann damit?! Kommt das in die /etc/nginx/sites-available/default?

Das muss in deinen DNS-Server. (Der hoffentlich DNSSEC kann.) Der liefert die aus.
Allerdings ist das ganze im Moment leider recht sinnlos.
Der DANE support für Chrome/Chromium wurde zwar geschrieben aber nicht integriert, weil Google keine Staatliche PKI will: http://sockpuppet.org/blog/2015/01/15/against-dnssec/
Und das wird auch so bleiben: https://bugs.chromium.org/p/chromium/is ... =50874#c22
Mozialla hat ja gerade seine eigene CA hochgezogen und da arbeiten die auch nicht wirklich dran, die Überflüssig zu machen:
https://bugzilla.mozilla.org/show_bug.cgi?id=672600
https://bugzilla.mozilla.org/show_bug.cgi?id=672239
Obwohl auch für den Firefox Code existiert, wird das vermutlich auch da keinen DANE Support geben.
Und wenn die beiden größten Browser nicht mitmachen ist der Kreis derer, die von dem Sicherheitszuwachs profitieren doch ziemlich gering.

In wieweit ist wäre z.B. der dritte Punkt gefährlich? Mein Bauchgefühl sagt mir, dass das für einen reinen HTML-Code nicht relevant ist, weil kein PHP eingesetzt wird.

Verstehe zuerst mal nicht, was du mit dem dritten Punkt meinst. Aber für Wordpress musst du doch PHP am laufen haben.

/EDIT: Da das ein letsencrypt Zertifikat ist, stell ich mir die Sache mit dem Public-Key-Pins schwierig vor, weil das Zertifikat regelmäßig erneuert wird..

Das Zertifikat schon. Darin aber nur die Signatur. Den Key selbst erzeugst du selbst (openssl genrsa). => Er kann jedes mal der gleiche sein.
Deswegen auch das komplizierte Verfahren dass man zuerst den Key aus dem Zertifikat extrahiert und dann den Hash auszurechnen statt den einfach über das ganze Zertifikat zu jagen.
Im Konkreten für Letzencrypt: Du musst deinen ACME-Client dazu bekommen, dass er den alten Key weiterverwendet (openssl csr auf die alte Key Datei statt jedes mal erneut openssl genrsa auszuführen.)
Für letsencrypt.sh gibt es die Option PRIVATE_KEY_RENEW="no". Und ist glaube ich sogar default.

[irgendwas]

Danke für deine ausführliche Antwort

Das muss in deinen DNS-Server. (Der hoffentlich DNSSEC kann.) Der liefert die aus.
Allerdings ist das ganze im Moment leider recht sinnlos.

Okay, dann hat sich das Thema für mich schon erledigt, weil ich keinen eigenen DNS-Server betreibe..

Verstehe zuerst mal nicht, was du mit dem dritten Punkt meinst. Aber für Wordpress musst du doch PHP am laufen haben.

Ja, aber die WordPress Installation läuft bei mir am Windows PC, dort erstelle ich dann die Beiträge (wenn mal wieder welche dazu kommen), durch Plugins wird der gesamte Blog als reiner HTML-Code "exportiert", den ich dann händisch auf den Server lade. Alle PHP Befehle werden dann zu reinem HTML-Code. z.B. wird aus

Code: Alles auswählen

<?php bloginfo('url'); ?>

direkt zu

Code: Alles auswählen

http://meinblog.de

Funktioniert aber halt nur, wenn kein Kontaktformular o.ä. eingebunden ist. Die Methode ist eigentlich perfekt dafür geeeignet, wenn die Seite "archiviert" werden soll oder selten neue Beiträge dazu kommen..

Das Zertifikat schon. Darin aber nur die Signatur. Den Key selbst erzeugst du selbst (openssl genrsa). => Er kann jedes mal der gleiche sein.

Wäre das "sicherheitstechnisch" nicht leichtsinnig immer den gleichen privaten Schlüssel zu benutzen?

[wanne]

Okay, dann hat sich das Thema für mich schon erledigt, weil ich keinen eigenen DNS-Server betreibe..

Nicht unbedingt: Wenn du z.B. deine Domain bei OVH hast, kannst du da den TLSA Record ins Webinterface eintragen und der DNS-Server liefert den aus. Machen aber nicht so viele Anbieter.

Funktioniert aber halt nur, wenn kein Kontaktformular o.ä. eingebunden ist. Die Methode ist eigentlich perfekt dafür geeeignet, wenn die Seite "archiviert" werden soll oder selten neue Beiträge dazu kommen..

Ah Wordpress als Static Website Generator nette Idee. Gefällt mir. Werde ich vielleicht mal weiterempfehlen.

Wäre das "sicherheitstechnisch" nicht leichtsinnig immer den gleichen privaten Schlüssel zu benutzen?

Geschmackssache: Auf der einen Seite ist er halt weiter gültig, wenn er kopiert wurde. Auf der anderen Seite: Wenn du keine Sicherheitslücke gefunden hast ist es relativ unwahrscheinlich, dass jemand der mal reinkam nicht mehr reinkommt und sich den neuen auch holen könnte. Eigentlich ist es halt eh zu spät, wenn das Kind mal in den Brunnen gefallen ist...
Dafür gibt es eben die Möglichkeit des Pinnigs und auch diverse Plugins, die darauf hinweisen wenn sich der Key ändert. Wenn seltener Schlüssel erzeugt werden, ist die Gefahr auch kleiner schwache zu erzeugen (z.B. weil Debian den Zufallsgeneartor rauspatched ) Dazu sinkt der Administrationsaufwand Seltenere Wechsel können seltener Probleme verursachen.
Ich glaube Im Moment geht der Trend gerade ganz deutlich zu längeren Laufzeiten für Keys, Passwörter und dhparms (Da sogar öffentliche die nochmal extra geprüft wurden.). Vor allem auch weil der Häufige Wechsel dazu verführt hat schlampiger zu sein. Mehr auf Performance/Einen bequemen Ablauf zu optimieren.
Stattdessen tauscht man aus, wenn wirklich Lücken bekannt werden. (Nach Heartbleed haben alle natürlich ausgetauscht.)
Aber am Ende ist es eben Geschmackssache.

[irgendwas]

Nicht unbedingt: Wenn du z.B. deine Domain bei OVH hast, kannst du da den TLSA Record ins Webinterface eintragen und der DNS-Server liefert den aus. Machen aber nicht so viele Anbieter.

Interessant, ich bin z.Z. bei Strato, aber nach Ende der Vertragslaufzeit werd ich dann eh wechseln.

Aber am Ende ist es eben Geschmackssache.

Okay, dann werd ich mir das mal im Lauf der Woche ansehen..

Noch was anderes, nachdem mein Mainboard am Wochenende das zeitliche gesegnet hat, bin ich auf Virtualisierung umgestiegen. Gibt es dazu etwas, was man beachten sollte? Als Betriebssystem läuft Openmediavault (hab's schon seit längerem im Einsatz, aber bisher nur lokal) und in phpvirtualbox hab ich das "alte" System mit Clonezilla eingespielt. Bisher läuft alles, aber bezüglich der Sicherheit hab ich noch bedenken.. Im Internet hab ich bisher auch nichts aussagekräftiges gefunden, außer das eben phpvirtualbox eine Schwachstelle darstellen könnte. Openmediavault ist von außen nicht erreichbar, sondern nur Debian in phpvirtualbox. Von daher sollte es ja eigentlich "passen", oder? Das übliche (starke und unterschiedliche Kennwörter, etc) hab ich berücksichtigt.

Edit: Sind für den SSH Key 2048 bit genug oder sollte man lieber 4096 verwenden?

[wanne]

Edit: Sind für den SSH Key 2048 bit genug oder sollte man lieber 4096 verwenden?

Im Monet gibt es aller Wahrscheinlichkeit Niemand der 2048 bit Faktorisieren kann. Nichtmal wenn er alle Rechner der Welt hätte. Aber bei SSH tun 4096 ja nicht weh. Und die Zeiten ändern sich vielleicht und gerade bei RSA kommen ja mehr oder weniger alle paar Monate bessere Algorithmen zum knacken raus und der Quantencomputer steht vor der Tür. Ich denk mir ne 4 statt ne 2 schreiben macht mir absolut gar nichts auch wenn der Sicherheitsgewinn wohl eher homeopatisch ist.

[uname]

Edit: Sind für den SSH Key 2048 bit genug oder sollte man lieber 4096 verwenden?

Ich denke auch, dass das reicht. SSH-Schlüssel werden wohl nicht geknackt. Wahrscheinlich werden eher auf Malware-verseuchten Windows-Admin-PCs die SSH-Passwörter mitgelesen oder die privaten SSH-Keys geklaut. Gleiches gab es ja auch schon bei FTP-Zugangsdaten. Da spielt es dann kaum eine Rolle ob etwas verschlüsselt übertragen wird oder nicht. Den Admin-PC von Windows auf Linux umzustellen wäre wohl somit eine weit bessere Idee als längere SSH-Schlüssel.

[ThorstenS]

Den Admin-PC von Windows auf Linux umzustellen wäre wohl somit eine weit bessere Idee als längere SSH-Schlüssel.

hö? Ist das nicht sowieso Standard bei uns Linuxadmins?

[uname]

Privat nutzen bestimmt viele Admins auch Linux-Desktops. Aber es gibt bestimmt Firmen die Linux-Server von Windows-Desktops verwalten (man will ja die Rechnung in Word schreiben). Wobei man könnte in dem Fall immerhin noch z.B. otpw-bin mit Suggests-libpam-otpw (Schlüssel natürlich sicher berechnet ) verwenden oder sonst ein Zwei-Faktor-Verfahren verwenden. Den administrativen Zugriff auf interne IP-Adressen einzuschränken ist im übrigen nicht zielführend, da die Malware auch diesen Weg nutzen würde. Gleiches gilt für SSH-Schlüssel (privater Schlüssel auf Desktop-Rechner) oder eine mögliche Passphrase (Keylogger). Obwohl alles vielleicht auch sehr theoretisch.

[irgendwas]

Ich muss den alten Thread wieder aus dem Keller holen, weil meine Frage einfach dazu passt

In meiner VM läuft WordPress und Owncloud/Nextcloud parallel. Beide Instanzen verwenden:
- unterschiedliche Ports
- unterschiedliche php5fpm sockets/user mit unterschiedlichen Eintragungen in open_basedir
- die Verzeichnisse für Owncloud und WordPress gehören auch unterschiedlichen Benutzern

Meine Frage ist nun, ob es sinnvoll ist, Owncloud und WordPress zu trennen und in separaten VMs laufen zu lassen. Abgesehen davon frag ich mich, welche VM dann regelmäßig das LetsEncrypt Zertifikat beantragen soll.

Bin ich zu paranoid und übertreibe? Vor allem steht die Frage im Raum, ob der Zugriff auf Owncloud-Dateien ausgeschlossen werden kann/unwahrscheinlich ist, bei Kompromittierung von WordPress? (oder auch anders herum)

Danke im voraus

[DeletedUserReAsG]

Voll virtualisierte Maschinen nur für verschiedene vHosts halte ich persönlich für übertrieben – aber wenn die Ressourcen da sind, spricht auch nichts weiter dagegen, abgesehen vielleicht vom zusätzlichen Wartungsaufwand. Was LE angeht: das hängt etwas davon ab, wie du die Zertifikate holst. Soweit mir bekannt, sind die Ports unerheblich. Ich hole meine Zertifikate explizit und manuell mit dem certbot, der läuft in einem eigenen Container. Wichtig ist bei der Methode, dass der die betreffende Domain bedienen und sich an Port 443 binden kann. Wie das mit dem automatischen Mechanismen funktioniert, weiß ich allerdings nicht.