Nutzung von Nitrokey Dongle als Sicherungsmaßnahme

  • Hat jemand Erfahrungen mit einer Installation zur Authentifizierung mit einem Werbung entfernt, siehe Forenregeln!? ?(


    Unter der Donglekey-Webseite https://www.dongleauth.info/ wird QNAP als kompatibel angezeigt. :qclub:


    Es gibt leider keine Anleitung und keine Erklärung wie das genau funktioniert. :/ Ein Dongle am QNAP und jeweils ein Dongle für jeden Nutzer? Könnte man damit vielleicht eine sichere Alternative zu VPN herstellen?

  • Könnte man damit vielleicht eine sichere Alternative zu VPN herstellen?

    Nein, da es sich hierbei lediglich um eine Sicherheitsmaßnahme für den Login handelt, ein Login aber für viele Angriffe gar nicht erforderlich ist.

  • Tiermutter schreibt's schon. Im Privatnutzerbereich halte ich den Dongle eher für Kontraproduktiv. Er verleitet dazu, den HTTP-Port nach außen frei zu geben und schafft dadurch eine größere Angriffsfläche (so ein Http-Server ist komplexer und hat eher mal eine Sicherheitslücke), und zu Hause ist er idR. überflüssig.


    Im Firmenbereich mit mehreren NAS und mehreren Administratoren, wo eher mal ein Passwort sich rumspricht, mag das hingegen eine sinnvolle Sache sein.


    Als sicher für den Zugriff von außen erachte ich

    - VPN

    - SSH (gute Passwörter oder ssh-Keys vorausgesetzt)


    Und wenn du dann bei VPN zusätzlich ein Passwort hast (im VPN-Client, also um die VPN-Verbindung zu öffnen) oder bei SSH ausschließlich über SSH-Keys mit Passphrase gehst, hast du automatisch eine Zwei-Faktor-Autorisierung. Ein Angreifer braucht dein Gerät, um das Zertifikat bzw. den Schlüssel zu haben, und er muss dein Passwort kennen.


    (Leider gibt es einige VPN-Clientprogramme, die kein Passwort verlangen, und Qnap macht es unnötig schwierig, den SSH-Zugang ausschließlich auf SSH-Keys umzustellen.)

  • Er verleitet dazu, den HTTP-Port nach außen frei zu geben

    Wozu? Man könnte doch für die Dienste nur HTTPS zulassen. Bei VPN sind doch auch Ports ins WAN offen? Wo ist da der Unterschied, ausser der Zugangsstufe der Passphrase, die vorher vom Server abgefragt wird?

    Die Probleme und Schwachstellen z.B. für HBS3, siehe https://www.qnap.com/en/security-advisory/QSA-21-13 liegen doch an der Authentifizierung oder an der zu offenen Kommunikation ohne SSL oder dergl.?

  • HTTPS bringt für die NAS Sicherheit gar nix, das ist ne Transportverschlüsselung (dann kann keiner das Passwort im Starbucks mit belauschen .. aber das wars dann auch)

  • Bei VPN sind doch auch Ports ins WAN offen?

    Nein.


    Wo ist da der Unterschied, ausser der Zugangsstufe der Passphrase, die vorher vom Server abgefragt wird?

    Bei VPN erreicht der Angreifer von außen nur das VPN-Gateway, nicht direkt das NAS.

    Vorteil 1: Geringere Angriffsfläche, da das VPN-Gateway nur diesen einen Dienst anbietet.

    Vorteil 2: Das VPN-Gateway ist (hoffentlich) als sicherheitsrelevantes System sorgfältiger gehärtet als das NAS.

    Vorteil 3: Wenn der Angreifer es auf das VPN-Gateway schafft, ist er noch nicht auf dem NAS. (Defense in Depth)

    Die Probleme und Schwachstellen z.B. für HBS3, siehe https://www.qnap.com/en/security-advisory/QSA-21-13 liegen doch an der Authentifizierung oder an der zu offenen Kommunikation ohne SSL oder dergl.?

    Es gibt höchst unterschiedliche Probleme und Schwachstellen, leider immer wieder auch solche, die einen Zugriff ohne Authentifizierung ermöglichen. Und SSL schützt dagegen exakt überhaupt nicht.

  • Login aber für viele Angriffe gar nicht erforderlich

    Ohne Netz und Verbindungsmöglichkeiten macht ein NAS doch keinen Sinn. Da kauft man besser eine USB-Festplatte ohne selbstständigen Prozessor.

  • Ohne Netz und Verbindungsmöglichkeiten macht ein NAS doch keinen Sinn.

    Richtig, aber ein NAS kann ja durchaus Konnektivität haben, es darf nur nicht direkt über das Internet erreichbar sein.

    In LAN ist doch immer alles möglich, wenn man Zugriff von Außen haben will, dann halt mit VPN.

  • Bei VPN sind doch auch Ports ins WAN offen? Wo ist da der Unterschied, ausser der Zugangsstufe der Passphrase, die vorher vom Server abgefragt wird?

    Dann schaue dir mal ISAKAMP an, das ist gut dokumentiert und wurde so entworfen, das es wenig Angriffsfläche bietet, im Gegensatz zu einem normalem Webserver, den man mal eben weg DoSen kann (was noch das harmloseste ist was ich mit anstellen kann).


    Dann vergleiche mal IKE mit z.B. Apache und schau da nach Angriffsmöglichkeiten.

    Schon stellst du keine QTS Dienste mehr ins WAN.

  • Wozu? Man könnte doch für die Dienste nur HTTPS zulassen.

    Die Verschlüsselung von https schützt gegen unbeteiligte Dritte. Der Angreifer ist aber kein Dritter, sondern ein Kommunikationspartner. Bei https kann dein Netzbetreiber nicht mitlesen, welche Passwörter der Angreifer durchprobiert. Der Angreifer ist aber in seinen Möglichkeiten nicht eingeschränkt. Daher bietet https hier keinen Schutz.

    (Stimmt nicht ganz. https schützt dagegen, dass dein Netzbetreiber, ein Geheimdienst oder ein anderer Man-in-the-Middle deinen Login mit Passwort mitschneidet und später mit dem ihm dann bekannten Passwort sich anmelden kann. Daher müssen Zugriffe mit Passwort, also das Login, immer über https erfolgen.)


    Bei VPN sind doch auch Ports ins WAN offen?

    Korrekt. (tgsbn liegt hier falsch.)


    Aber es gibt zwei Unterschiede:

    1. Der Port ist nur auf deinem Router offen, nicht aber auf deinem NAS mit all den wichtigen Daten.


    2. Solange der Angreifer nicht am VPN angemeldet ist, ist die einzige zur Verfügung stehende Funktion anmelden (und das mit einem Zertifikat o. Ä., also nicht erratbar). Die Funktion, die der VPN-Server zur Verfügung stellen muss, ist daher relativ simpel und leichter fehlerfrei zu implementieren und zu testen. Bei einem Web-Server gibt es hingegen, selbst wenn scheinbar nur eine Anmeldemaske angezeigt wird, wesentlich mehr, was ein Angreifer machen kann, ohne sich anmelden zu müssen. Alleine was über die URL oder manipulierte http-Header machbar ist ... da ist es wesentlich wahrscheinlicher, dass irgendwo doch ein Fehler drin ist.


    Neben VPN ist mMn. auch ssh sicher. Solange keine Anmeldung erfolgt ist, kann ein Angreifer nichts anderes machen als Passwörter durchzuprobieren. Aus Sicht des Codes ist das auch eine nur kleine Angriffsfläche. Allerdings ist es bei ssh leichter, die Sicherheit selbst zu ruinieren, z. B. durch nicht geänderte Standard-Adminpasswörter.

  • Was die

    Neben VPN ist mMn. auch ssh sicher. Solange keine Anmeldung erfolgt ist, kann ein Angreifer nichts anderes machen als Passwörter durchzuprobieren.


    Was viele Leute beim VPN der FritzBox vergessen ist, das es auch sichere Benutzernamen gibt und man den VPN User nicht Bernd oder Helga nennen muss. :)

  • Die Verschlüsselung von https schützt gegen unbeteiligte Dritte. Der Angreifer ist aber kein Dritter, sondern ein Kommunikationspartner.

    Sorry - ich verstehe nicht die Definition "Angreifer als Kommunikationspartner".

    Ein Angreifer soll doch kein Kommunikationspartner sein, weil unerwünscht und nicht vorgesehen.

    Ein Angreifer kann doch erst Kommunikationspartner sein, wenn der nicht vorgesehene Zugang über z.B. einen Benutzeraccount erreicht wurde? Anschliessend vielleicht egal, ob SSL-Verschlüsselung stattfindet. Der Angreifer hat da schon Zugang zum System.


    Schade - dass noch niemand die Funktion eines Hard-Keys ausprobiert hat.

    Was viele Leute beim VPN der FritzBox vergessen ist, das es auch sichere Benutzernamen gibt und man den VPN User nicht Bernd oder Helga nennen muss. :)


    Neben VPN ist mMn. auch ssh sicher. Solange keine Anmeldung erfolgt ist

    Die beiden Themen wären dann doch vermutlich auch gegessen.

  • HTTPs mit SSL ist eine Transportverschlüsselung.


    Nicht mehr.


    Bringt also nur was gegen unterwegs reinschauen und Daten mitlesen.

    Da kannst auch 8k Keys einsetzen, der Webservice dahinter bleibt angreifbar.

    Weil er halt viel mehr macht als z.B. ISAKAMP mit dem IPsec sich über IKE anmeldet.


    Das kann nur ganz wenige spezielle Funktionen und hat damit so gut wie 0 Angriffsfläche.


    Dein Webserver aber skriptet sich nen Scheiß zusammen wie ihm lustig implementiert wurde.

    Der hat also x Protokolle und 1 mil Funktionen im vergleich zu einem gehärtetem Dienst wie ISAKAMP.


    Das eine ist nen Bunkter mit Cam bei dem du den Ausweis vorzeigen musst um den Türsteher überhaupt erst hinter der Tür vor zu locken.


    Beim anderen hast du den Eingang von Karstadt, da rennt einfach so jeder rein und wenn das dann nicht der nette Kunde ist, nimmt dir der Typ den Laden mal eben auseinander.

  • Sorry - ich verstehe nicht die Definition "Angreifer als Kommunikationspartner".

    Ein Angreifer soll doch kein Kommunikationspartner sein, weil unerwünscht und nicht vorgesehen.

    Aus der Sicht des Netzwerkprotokolls http(s) sind dein NAS und der Angreifer Kommunikationspartner. Der Angreifer schickt über die HTML-Eingabefelder Name und Passwort, und dein NAS antwortet mit "Kein Zugriff". Für das Netzwerkprotokoll ist das eine gültige Kommunikation. Wenn du selbst dich dort anmeldest, sähe es im ersten Schritt gleich aus, nur die Antwort vom NAS wäre anders. Dass der Angreifer bösartig und unerwünscht ist., ist dem Netzwerkprotokoll egal. Mit https wird die Kommunikation gegen Einblicke Dritter geschützt, aber keiner der beiden "Partner" NAS und Angreifer wird eingeschränkt.


    Denk als Beispiel mal an die herkömmliche Post:

    http ist wie eine Postkarte. Der Briefträger kann mitlesen, was ihr schreibt.

    https ist wie ein Brief. Der Inhalt eurer Kommunikation bleibt dem Briefträger verborgen.

    Die Verwendung von Briefumschlägen hindert einen böswilligen Erpresser aber nicht daran, dir fingierte Drohschreiben zu schicken.

  • Beim anderen hast du den Eingang von Karstadt, da rennt einfach so jeder rein und wenn das dann nicht der nette Kunde ist, nimmt der Typ die den Laden mal eben auseinander.

    Beziehst du deine Aussage auf QNAP oder generell auf https-Zugriffe im Internet?

  • Generell auf Webservices im Internet, im LAN, wo auch immer.


    Nicht umsonst stellte man als Firma auf WAN Seite ne Webserver in eine DMZ und da ist dann keine AD Anbindung oder sonst was wichtiges dabei.

    Da kann er dann die Webseite mit deren Inhalten klauen.


    Systeme die in der internen Infrastruktur hängen, hängt man hinter ein Applikation Layer Gateway und lässt hier nur die Befehle zu, die man wirklich braucht um die Services zu fahren.

    Die Anmeldung läuft dann User + 2FA gegen das GW und dann holt sich das GW mit einem eigenem User das AD Token für den User und leitet die Anfrage, umgeschrieben für die interne Struktur inkl. AD Token weiter auf die internen Systeme.


    Jetzt Hand aufs Herz, wer hat so was für sein QTS Webserver im Heimnetz stehen?

  • Generell auf Webservices im Internet, im LAN, wo auch immer.

    Das stimmt doch so nicht.

    Seiten wie GMX, Amazon usw. werden ständig übernommen?


    Wenn man keine Ahnung hat von öffentlichen Webservern, sollte man sich zurückhalten.

    2 Mal editiert, zuletzt von frosch2 ()

  • Seiten wie GMX, Amazon usw. werden ständig übernommen?

    Nein, sie werden ständig angegriffen. Was die Unternehmen unternehmen, damit die Angriffe nicht immer gleich zur vollständigen Übernahme führen, hat Crazyhorse ja beschrieben. Wieviele Angriffe wie kurz vor diesem Ziel gestoppt werden ist Geschäftsgeheimnis.


    Sein Bild, dass da jeder reinrennt und ggf. auch mal den Laden auseinandernimmt, ist schon korrekt, siehe DDoS- und Screenscraping-Angriffe. Nur dass halt hinten zum Lager, zur Buchhaltung und zur Geschäftsleitung hin noch Türen kommen, durch die dann nicht mehr jeder reinrennen kann.

  • Der Angreifer schickt über die HTML-Eingabefelder Name und Passwort, und dein NAS antwortet mit "Kein Zugriff"

    In den Systemeinstellungen unter Konto- und IP-Zugriffsschutz und lassen sich diese Angriffe doch eigentlich unterbinden. QNAP rät mittlerweile die Dauer der IP-Sperre auf "immer" zu schalten.