Beiträge von Anthracite

Auf "immer" würde ich die Sperre nicht setzen. Gelegentlich sperrt man sich selbst auch aus.

Die IP-Sperre ist ein durchaus sinnvoller Schutz und sollte immer aktiv sein, wenn Dienste das NAS direkt ins Internet gestellt werden. Sie verhindert, dass ein Angreifer mal so eben alle Passwörter aus seiner Datenbank durchprobieren kann. Aber die IP-Sperre ist kein Allheilmittel und kann nicht alle Angriffe verhindern!

Die Angriffstaktik gegen eine IP-Sperre besteht darin, von vielen verschiedenen Rechner aus Loginversuche zu unternehmen oder zumindest einen großen Bereich von IPs zu kontrollieren. Wenn der Angreifer 10.000 Rechner hat, kann er schon pro NAS 50.000 oder mehr Passwörter durchprobieren, ohne dass die IP-Sperre zuschlägt, und macht er das für alle NAS, die er im Internet findet, wird er bestimmt einige funktionierende Zugangsdaten erhalten. Aber ein solches Botnetz muss der Angreifer erst einmal unter Kontrolle bringen oder im Darknet mieten. Sein Angriff wird durch die IP-Sperre also erheblich erschwert.

Dann gibt es noch Angriffe, gegen die die IP-Sperre völlig wirkungslos ist, nämlich über Sicherheitslücken oder in HBS (unfreiwillig?) einprogrammierte Hintertüren. Da nützt eine IP-Sperre gar nichts, da der erste Einbruchsversuch bereits erfolgreich ist.

Die gerade massenhaft genutzte QLocker-Ransomware ist so ein Fall, gegen den die IP-Sperre wirkungslos war. Dort wurden wohl fest einprogrammierte Zugangsdaten in HBS (möglicherweise eingefügt für Tests und dann vergessen) verwendet.

Der Finder zickt beim Kopieren größerer Datenmengen gerne mal herum.

Im Terminal mit cp -Rp Quelle Ziel kopieren, dann sieht man eher, an welcher Datei es liegt. cp -Rpv gibt notfalls zusätzliche Informationen.

Wenn es tatsächlich Rechteprobleme sind, kann man die Rechte korrigieren (z. B. mit chmod) oder man setzt ein sudo vor den cp-Befehl. Oft ist es aber auch nur ein Dateiname, den der Mac nicht mag, manchmal machen Umlaute Probleme.

Ich hatte hier mal den Fall, dass mit Gigabit alles funktionierte, mit 10GbE hingegen ging ein Ping, aber alle anspruchsvolleren Dienste wie Netzwerkfreigaben gingen nicht. Als ich dann testweise Rechner und NAS direkt verbunden hatte, ging plötzlich alles auch mit 10GbE. Ursache war in meinem Falle eine Inkompatibilität zwischen 10GbE-Thunderbolt-Adapter und Switch. Ein Austausch des Switches gegen einen Switch eines anderen Herstellers hat das Problem dann gelöst.

Ein Ping ist halt nicht sonderlich anspruchsvoll.

Daher wäre mein Vorgehen:

Ausprobieren, ob andere anspruchsvollere Protokolle für SMB-Freigaben, ssh oder ftp funktionieren.

Wenn ja, dann ist es ein Softwareproblem. NFS hat seine Eigenarten in der Konfiguration. Eine Firewall o. Ä. kann natürlich auch die Ursache sein.

Wenn nein, dann testweise

- Rechner und NAS direkt verbinden

- andere Kabel

- andere Transceiver

- IP-Adresse im 192er Subnetz

Eine Firewall kann auch Schuld sein.

Wenn Windows auf den PCs zum Einsatz kommt, dort mal testweise die Firewall komplett deaktivieren.

Hat der Switch Firewall-Funktionen?

OK, einverstanden

Zitat von FSC830

Ich finde die Aussage von QNAP spannend!

Nochmals in Kürze:

1. Verschlüsselte Daten sichern (nach extern)

2. Verschlüsselte Daten löschen

3. Daten mit Photorec wiederherstellen

Ergebnis: unverschlüsselte Daten!??? So einfach sollte es sein?

Alles anzeigen

Das kann funktionieren.

Hintergrund ist, dass das zur Verschlüsselung verwendete Programm 7z die Datei beim Verschlüsseln nicht überschreibt, sondern es legt eine neue Datei an, welche die verschlüsselten Daten bekommt, und danach wird die alte unverschlüsselte Datei gelöscht. Damit liegen die unverschlüsselten Daten in Form einer gelöschten Datei weiterhin auf der Festplatte/SSD.

Nun, und Photorec ist genau dazu gemacht, gelöschte Dateien wieder herzustellen.

Das Ganze funktioniert natürlich nur, wenn das NAS noch nicht so viel an neuen Daten auf die Platte geschrieben hat, dass der Platz, den die alten Dateien belegt hatten, erneut verwendet wird.

Das heißt, mit dem Verfahren wird man höchstwahrscheinlich nicht alle Daten wieder herstellen können, aber die Chance ist gut, dass ein paar Dateien wieder gefunden werden.

Aus diesem Grunde empfiehlt Qnap auch, die verschlüsselten Daten vorher extern zu sichern. Wenn Photorec nur geringe Erfolge bringt, kann man sich immer noch entschließen, die Erpresser zu bezahlen. Außerdem ist Qnap aus der Haftung raus, falls es nicht funktioniert.

Ich denke, wenn kein Backup der Daten vorhanden ist, dann ist das Vorgehen einen Versuch wert.

Zitat von binam

Neben dem Problem der Treibersuche haben solche Serverkarten auch einen hohen Stromverbrauch und 2 Ports braucht der Heimanwender eher selten.

Die genannte HP ist baugleich zur von Qnap empfohlenen Emulex OCE11102. Ich nehme nicht an, dass die vom Stromverbrauch deutlich höher liegt als die von dir genannte Mellanox.

Zwei SFP+ Ports am PC oder NAS sind allerdings in der Tat kein "Must have". Ein Port reicht.

Zitat von NaStrada

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.

Zitat von smashedup

Eigentlich müsste ich dann nur den SFP+ NICs an PC und NAS eine IP in einem anderen IP-Bereich, als dem restlichen Netzwerk geben, oder?

Es müsste eigentlich schon reichen, eine IP-Adresse aus dem gleichen IP-Bereich zu vergeben, die im sonstigen Netzwerk aber nicht verwendet wird (sowohl auf dem PC als auch im NAS, d. h. du brauchst zwei IPs). Du sprichst das NAS - z. B. beim Mount von Netzlaufwerken - dann über die spezielle IP an.

Es kann sein, dass woanders noch etwas konfiguriert werden muss. Da kann ich dir aber nicht weiterhelfen, da ich einen Mac habe, und der ist anders zu konfigurieren.

Zitat von smashedup

Falls jemand Erfahrungen mit den Billigkarten hat, lasst es mich gerne wissen!

Mit Billigkarten aus China, nein, da habe ich keine Erfahrungen, aber mit einer gebrauchten HP NC552SFP FC Dual-Port 10GbE SFP+ (hat mich 34 Euro gekostet). Die funktioniert sehr gut, aber ich habe sie im NAS im Einsatz. Irgendwer im Forum hat sie wohl auch im PC. Wichtig bei den Gebrauchten ist, dass es einen Treiber gibt - es ist alte Rechenzentrumshardware, wo man manchmal eher Treiber für Unix und Linux findet.

Das geht, aber dann kommst du von PC1 aus weder an das Internet (so der Router auch am Switch hängt) noch an den PC2. Ein NAS ist erstmal kein Switch.

Angeblich kann man im NAS einen virtuellen Switch so konfigurieren, dass das NAS die Switch-Funktion übernehmen kann. Das habe ich noch nicht ausprobiert, und es scheint mir auch nicht sinnvoll, da zum einen das NAS nicht die Spezialhardware eines Switches besitzt und die CPU mit dem Weiterleiten von Daten belasten müsste, und da zum anderen die Ausfallzeiten beim NAS höher sind als beim echten Switch.

Eine weitere Möglichkeit ist, den PC zusätzlich über Gigabit-LAN (sofern er noch eine zweite Netzwerkbuchse hat) direkt mit dem Switch zu verbinden. Dann musst du dich im PC um das Routing kümmern, dass aller Netzverkehr zum NAS über die 10GbE-Strecke (also über sfp+) läuft. Wenn das zweite Kabel nicht stört, spricht nichts dagegen.

Die einfachste und beste Möglichkeit ist, du kaufst dir einen Switch mit genug sfp+ Ports, an den der PC1 und das NAS und demnächst auch der PC2 verbunden werden. Den Mikrotik CRS305-1G-4S+IN gibt es ab etwa 120 Euro, er hat vier sfp+ Ports, und an den einen Gigabit-Port schließt du deinen alten Switch für die langsamen Geräte an.

Das kannst du leicht in der Shell/Terminal auf dem Mac oder dem Qnap NAS machen, z. B.:

Tipp: bevor du die Dateien mit rm löschst, setz erst einmal nur den Find-Befehl ab, damit du siehst, welche Dateien gelöscht würden:

Ausnahme:

Die Ressource-Forks, die der Mac auf Nicht-Apple-Dateisystemen anlegt, und die mit ._ im Namen anfangen, kriegst du nur auf dem NAS gelöscht, da der Mac sie verbirgt. (Dies ist für den Fall, dass du die Ressource-Forks löschen willst, die eigentliche Datei aber behalten.)

Zitat von NaStrada

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.)

Zitat von NaStrada

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.

Bist du als Admin angemeldet bzw. nutzt du sudo?

Wenn nicht, erhältst du genau den oben stehenden Fehler.

Zitat von frankyjones

Gibt es dazu einen Lösungsansatz, dass ich 2 PCI-Karten zusammen mit den beiden M.2-SSDs "friedlich" nutzen kann?

Ich hatte das Problem damals nicht weiter verfolgt, da ich bei der Karte, die ich testweise eingesetzt hatte, ohnehin große Zweifel hatte, sie nutzen zu können.

Zitat von frankyjones

Das TS-677 hat sich bei jeder HW-Änderung "zickig" gezeigt, sei es nur das Hinzufügen einer zweiten M.2-SSD.

Einerseits dauert der erste Boot-Vorgang seeehr lange, andererseits wird die Hardware nach dem kompletten Boot-Vorgang überhaupt nicht erkannt (obwohl physisch alles korrekt angeschlossen ist). Ein Runterfahren und erneutes Hochfahren hat das Problem dann gelöst, erst dann wurden beide M.2 wieder erkannt.

Ich habe die TS-877, und da kann ich die Zickigkeit bzgl. Hardware so nicht bestätigen. Lange Bootzeit, ja, aber die M2-SSDs werden immer erkannt, auch ohne Extra-Reboots. Ich habe die SSDs aber auch nicht als Cache, sondern als eigenes Volume.

Hast du eine Einsteckkarte in deinem NAS? Die kann nämlich dazu führen, dass die M2-SSDs nicht erkannt werden. (Ich hatte einmal eine nicht geeignete Karte eingebaut, die dazu führte, dass die SSds nicht gefunden wurden. Nach entfernen der Karte war alles wieder einwandfrei.)

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.)

Hast du mal in der Konsole (unter Dienstprogramme) nachgeschaut, ob da Meldungen auflaufen, während er hängt?

Ansonsten:

AFP ist eine Altlast. Die Zukunft gehört SMB, auch bei Apple. Ich würde daher den Zugriff auf SMB umstellen, und wenn dein Problem damit nicht mehr auftritt, die Sache als erledigt ansehen.

Außerdem ist SMB schneller (ich habe eine Reihe von Messungen dazu gemacht, allerdings mit High Sierra).

Hast du schon einmal versucht, die Platte einmal rauszunehmen und wieder reinzustecken (falls Kontaktproblem oder Platte sitzt nicht richtig)?

Ansonsten: In ein USB-Gehäuse tun und an einen Linux-PC stecken. Ist aber kompliziert, weil sich auf der Platte zusätzlich ein System-Volume befindet.

Hast du auch an der richtigen Stelle nachgeschaut?

Speicherpool bzw. statisches EInzelvolume anklicken, dann oben rechts auf "Verwalten", in dem aufgehenden Dialog unten rechts auf "Verwalten", und dort gibt es den Punkt "Datenträger hinzufügen" (der bei mir natürlich ausgegraut ist, da ich keinen freien Datenträger habe, aber bei dir sollte es den geben).

Edit: Dolbymans Bemerkung zu QuTS gilt natürlich. Ich habe qts hier im Einsatz.

Deine Festplatte kann ich dort nicht sehen. Schlecht. Da müsste u. A. irgendwas wie CE_CACHEDEV1_DATA stehen.

Wird die Festplatte überhaupt noch erkannt? Wenn du dich im Browser in qts anmeldest und unter Speicher/Snapshots -> Datenträger nachschaust, siehst du sie da noch?

Kennst du dich ein wenig mit der Unix Shell aus?

Log dich per ssh ein und schau nach, was unter /share zu finden ist.