Beiträge von xtcfol

Hallo kasimodo,

danke für Deinen ausführlichen Post. Ich denke, daß der Upload der /etc/config/apache/extra/httpd-ssl-vhosts-user.conf sich mit Deinem Check erübrigt hat.

Betreffend der RC4 Sicherheitslücke hatte ich mehrfach den Helpdesk angeschrieben - Beharrlichkeit führt offensichtlich zum Ziel, wenn auch alle anderen Nutzer mitmachen.

Danke für Deine Expertise und den Hinweis auf den 'letzten Punkt', der dann wohl auch ein A+ auf SSLlabs erzeugen würde. Mit dem A bin ich schon einmal zufrieden (ist allemal besser als das 'B') und hoffe, die Qnap-Jungs bleiben weiter an der Sache dran.

Viele Grüße
xtcfol

Hallo noch einmal kasimodo,

Hast Du Deinen letzten Hinweis bereits an den Qnap Helpdesk gemeldet?

Zitat von kasimodo

Aber das folgende fehlt immer noch in der httpd-ssl-vhosts-user.conf! 8-(

Code

LoadModule headers_module /mnt/ext/opt/apache/modules/mod_headers.so
Header always set Strict-Transport-Security "max-age=15768000"

Man könnte doch ggfs. durch mehrere Nutzer den Hinweis an den Helpdesk senden, daß wir diese Änderung wünschen.
Was meinst Du?

Viele Grüße
xtcfol

Ich habe das Problem nun für mich lösen können (auf allen vier Qnaps laufen nun alle vier SSL Zertifikate einwandfrei, egal, ob Global Sign oder Alpha SSL):

1. Vorhandene Zertifikate unter Systemsteuerung -> Sicherheit -> Zertifikat und privater Schlüssel herunterladen (nur zur Sicherheit, das ist das Zertifikat und der private Schlüssel und das Zwischenzertifikat)

2. Das aktuelle Firmware-Update 4.2.3 vom 13.02.2017 einspielen, welches den Fix für folgendes Problem enthält:
Fixed an issue where intermediate SSL certificates could not be validated when Virtual Host was enabled.

3. Unter Systemsteuerung -> Sicherheit -> Zertifikat und privater Schlüssel auf 'Standardzertifikat und privater Schlüssel' klicken, sodaß das Standardzertifikat wieder installiert wird

4. Anschließend die drei zuvor gesicherten Dateien wieder hochladen (Zertifikat, Private Key und Zwischenzertifikat)

5. Dann unter Anwendungen -> Webserver den 'Sichern Anschluß aktivieren' und den Port von 8081 wieder auf 443 zurücksetzen

6. Dann unter Anwendungen -> Webserver -> Virueller Host den Host erneut aktivieren, da er zuvor automatisch deaktiviert wurde

7. Zur Sicherheit https://ssl-trust.com/SSL-Zertifikate/check aufrufen und das SSL Zertifikat testen. Es wird nun grün angezeigt: Das Zertifikat der Domain ist vertrauenswürdig.

8. Dann noch einen vollständigen Test auf https://www.ssllabs.com/ssltest/analyze.html durchführen und sich über das 'A' freuen.

9. Nun geht wieder alles!

Ich habe ebenfalls das Problem, daß auf drei unterschiedlichen Qnap 453 jeweils ein eigenständiges gekauftes SSL-Zertifikat läuft, welches vom aktuellen FF an zwei von fünf Rechnern nicht erkannt wird.

Daran hat sich leider auch nichts nach der Installation des Updates 4.32 vom 13.02.2017 geändert, welches folgendes Problem lösen sollte:
Fixed an issue where intermediate SSL certificates could not be validated when Virtual Host was enabled.


Merkwürdig finde ich, daß an drei Rechnern bei Zugriff auf die Webseiten keinerlei Fehlermeldungen erscheinen und bei zwei Rechnern FF sendet 'die Verbindung ist nicht sicher'. Alle FF haben dengleichen aktuellen Stand.

Ein SSL Test mit https://www.ssllabs.com/ssltest/analyze.html zeigt ebenfalls an, das die Zwischenzertifikate fehlen. Ich habe alle Zertifikate neu ausstellen lassen und erneut auf den Qnaps installiert. Dieselben Zertifikate (5 Jahres Zertifikate) liefen zuvor auf einem Mietserver einwandfrei.

Ist irgendeine Problemlösung in Aussicht? Offensichtlich hat das aktuelle Update das Problem nicht behoben.

Danke für eine Rückmeldung.

Das würde mich auch interessieren - insbesondere, wann das Firmware-Upgrade mit PHP 5.6 ausgerollt wird.

Beim derzeitigen PHP 5.5 gibt es Umlaut-Probleme und Funktionsstörungen in auf dem System gehosteten Blogs und Shops, die erst mit PHP 5.6 korrigiert werden (div. Qnaps als Webserver im Einsatz).

Viele Grüße
Xtcfol

Hallo Forum,

vielen Dank - insbesondere an nadstefan für diese Tips, mit denen ich mein (ähnlich gelagertes) Problem lösen konnte.

Ich habe es hier beschrieben:
http://forum.qnapclub.de/viewt…&t=38917&p=221299#p221299

Viele Grüße
xtcfol

Hallo Forum,

dank dieses Beitrages habe ich mein Problem vollständig lösen konnen. Vielen Dank an nadstefan für den wichtigen Hinweis.
http://forum.qnapclub.de/viewt…=209736&hilit=443#p209736

Es ist eben nicht ausreichend, die unter meinem Punkt 5 genannte Nas-Konfiguration nur auszuschalten. Man muß den Port tatsächlich zuvor umbelegen (z.B. - wie von nadstefan vorgeschlagen - auf 444). Danach habe ich diesen 'falschen' Port deaktiviert.

Mein Ziel war es, folgendes abzubilden - die nachfolgen Domains sollen auf eine einzelne sichere Seite umgeleitet werden:
1. http://domain.de
2. http://www.domain.de
3. https://www.domain.de

-> Umleitung auf https://domain.de

Meine Konfiguration:
LAN-1 vom Qnap im lokalen Netz
LAN-2 vom QNAP an statischer IP

Zunächst unter:

Zitat

Systemeinstellungen -> Netzwerk -> Servicebindung Ethernet 2

nur den Webserver freigegeben. Somit ist der Qnap aus dem Web nicht ganz so angreifbar. Unter Ethernet 1 (das ist das lokale Netz) sind alle Dienste aktiviert (das lokale Netz hat keine Verbindung aus dem Web, ist also nicht über Forwarding Router-Einstellungen aus dem Web erreichbar).

Dann unter:

Zitat

Systemeinstellungen -> Allgemeine Einstellungen -> Systemadministration

den 'Sicheren Anschluss (HTTPS) aktivieren' zunächst von 443 auf 444 geändert und im zweiten Schritt diesen 'falschen' Port abgeschaltet.

Dann unter:

Zitat

Anwendungen -> Webserver -> Webserver

den 'Sicheren Anschluss (HTTPS) aktivieren' von 8081 auf 443 umgestellt und aktiviert.

Dann unter:

Zitat

Anwendungen -> Webserver -> Virtueller Host

vier virtuelle Hosts angelegt und zwar:

1. domain.de (HTTP, Port 80)2. www.domain.de (HTTP, Port 80)3. domain.de (HTTPS, Port 443)4. www.domain.de (HTTPS, Port 443)

Alle vier virtuelle Hosts verweisen auf denselben Ordner: domainname

Anschließend (zur Vermeidung von Duplicate Content und zur einfachen Bedienung im Browser unabhängig von der Eingabe) folgenden Code in der .htaccess angelegt:

RewriteEngine OnRewriteCond %{HTTP_HOST} ^www.domain.de$RewriteRule ^(.*)$ https://domain.de/$1 [r=301,L]RewriteCond %{SERVER_PORT}   !^443$RewriteRule  (.*)  https://domain.de/$1  [R=301,L]

Diese Regeln bewirken, daß unabhängig von der Browsereingabe:

1. domain.de2. www.domain.de3. https://www.domain.de

die Umleitung auf https://domain.de erfolgt. Das war mein Ziel.

Möglicherweise kann man den Code in der .htacces noch vereinfachen - aber zunächst funktioniert nun alles, wie gewünscht.

Ich hoffe, meine Hinweise helfen anderen bei identischer Problemstellung und danke nochmals für den Tip von nadstefan, der mir den richtigen Weg aufgezeigt hat.

Viele Grüße
xtcfol

EDIT:
Dieser kürzere Code in der .htacces scheint ebenfalls die gewünschten Umleitungen auszuführen:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Hallo Forum,

Ausgangslage: Qnap 453 mini, statische IP, virtueller Host, Alpha SSL Zertifikat installiert, 10 Domains, davon soll eine unter https:// erreichbar sein, die anderen per http://

Problem: Aufruf der Domain mit https:// geht auf die Admin-Anmeldung, nicht auf die index.html der Webpräsenz

Vorgehen:

1. Alpha-SSL installiert, mit DNS-Tools getestet - wird erfolgreich erkannt
2. Die 9 Domains mit http:// einwandfrei erreichbar
3. Die Domain, für die https:// gewünscht wird, ist nicht erereichbar, statt dessen kommt die Admin-Seite
4. Im virtuellen Host diese Domain auf HTTPS konfiguriert und Port 443 eingetragen. Dieser wird nicht angenommen. Akzeptiert wird 8081
5. In den 'Allgemeinen Einstellungen -> Systemadministration' HTTPS deaktiviert (ich will nicht die Admin-Seite, sondern die Domain per https:// erreichen)
6. Dann in der Webserver-Konfiguration Port 443 für HTTPS gesetzt -> wird automatisch auf 8081 gesetzt
7. In der Webserver-Konfiguration wieder HTTPS deaktiviert und nur im virtuellen Host https aktiviert (nur 8081 wird akzeptiert).
8. Zum Test: Die geplante https:// Domain zurück auf http:// und Port 80 konfiguriert zeigt die index.html korrekt an

Egal welche Konstellation ich für https:// verwende: Die Domain mit https:// ruft immer den Admin auf. Gegentest: Eine andere im virtuellen Host angelegte Domain (als http:// konfiguriert) und mit mit https:// aufgerufen gibt die korrekte Fehlermeldung im Browser, daß das Zertifikat für eine andere Domain ausgestellt ist.

Es scheint somit alles richtig zu laufen - nur wo muß ich ansetzen, daß die Domain unter https:// aufgerufen wird und nicht die Admin-Seite erscheint?

Bin für jeden Tip dankbar. Alle hier im Forum gefundenen Lösungsansätze haben das Problem nicht lösen können (oder ich habe etwas übersehen).

Danke für hilfreiche Anregungen ...

Viele Grüße
Xtfol

Hallo,

auch ich hatte mit diesem Problem zu kämpfen, welches erstmalig vorgestern aufgetreten ist. Ich verwende drei Qnaps (TS-421 mit 4 HDD als Raid-5, TS-421 mit 2 HDD mirrored, TS 419 II mit 4 HDD als Raid-5) und aktueller Firmware 4.2.0

Die Qnaps verwende ich bereits seit mehreren Jahren - bisher gab es kein Problem mit dem Filecheck.

Nun brachten zwei Qnaps genau das hier beschrieben Problem. Da alle Geräte nahezu identisch konfiguriert sind, suchte ich nach Unterschieden. Zwei Qnap hatten die Surveillance Sattion App installiert - und genau diese Qnap machten Probleme beim Filecheck.

Nach der Deinstallation der Surveillance Software und Reboot funktioniert auch (wieder) der Filecheck.

Möglicherweise ein Zusammenspiel der aktuellen FW und der aktuellen Surveillance Software.

Zuvor habe ich auf den Raid-5 Qnap mit Putty über die Konsole den Filecheck ausgeführt und mich an o.a. Beschreibung orientiert.

Hier meine Vorgehensweise:

1. Putty starten, anmelden mit 'admin' und 'admin' (dein Login und PW)

2. Dienste stoppen mit:

/etc/init.d/services.sh stop && /etc/init.d/opentftp.sh stop && /etc/init.d/Qthttpd.sh stop

3. Mount aufheben

umount /dev/md0

Vermutlich wird nun in Putty angezeigt:

umount: /share/MD0_DATA: device is busyumount: /share/MD0_DATA: device is busy

4. Prüfen, welche Prozesse das Device /md0 momentan benutzen

lsof +f -- /dev/md0

5. Die angezeigte Liste enthält alle laufenden Prozesse die wir mit Hilfe der PID Nummer KILLen müssen
wenn z.B. die PID '9924' ist:

kill 9924

und anschließend mit 'lsof +f -- /dev/md0' erneut prüfen (siehe Punkt 4)
Wenn die Liste nicht mehr erscheint, dann weiter mit dem nächsten Schritt

6. erneut Mount aufheben

umount /dev/md0

7. nun Filesystem Check durchführen (das dauert länger: Pass 1 bis 5, evtl. Fehler werden nach Abschluß gemeldet)

e2fsck -f -v -C 0 /dev/md0

8. Filesystem wieder mounten

mount -t ext4 /dev/md0 /share/MD0_DATA

9. Neu starten

reboot

-------

Weiterhin habe ich bei meinen Tests herausgefunden, daß der Watchdog Daemon (wdd) für die Blockierung des Unmount-Prozesses verantwortlich war. Es war stets dieser Dienst, den ich per 'kill' stoppen mußte:

/share/MD0_DATA/.nvr_root_target/.nvr_root/usr/bin/wdd

Vielleicht helfen diese Hinweise - ich habe das Thema auch noch hier beschrieben:
http://forum.qnap.com/viewtopi…t=111944&p=515105#p515105

Viele Grüße und viel Erfolg
Harald