Das mit der IP-Sperre ist ein bekanntes Problem.
Windows versucht bei jeder passenden oder unpassenden Gelegenheit sich bei allem möglichem ungefragt anzumelden und löst damit gerne mal eine Sperre aus.
Das kriegt man ihm auch nicht abgewöhnt.
IP-Sperren wegen zu häufiger Anmeldefehler an SMB-Freigaben sind deshalb (leider) nicht sinnvoll.
Ist in 4.5.1.1465 build 20201024 laut Release Notes behoben.
Dasselbe hier auf der TS-228A.
Ich habe mit Hybrid Backup Sync angefangen von meiner 8TB auf die zweite 8TB die Sicherung anzulegen, was erstmal so geht!
Du hast also zwei interne 8TB-Platten und hast die als separate Volumes eingerichtet, um die zweite als HBS-Sicherungsziel für die erste zu benutzen? Das halte ich nicht für sinnvoll.
Ich würde stattdessen empfehlen, die beiden Platten im RAID1 (Spiegelung) zu betreiben.
Damit hast du nach dem Aufsetzen keine weitere Arbeit mehr und bist gegen einfache Festplattenausfälle geschützt.
Mehr bringt dir ein Backup auf eine interne Platte auch nicht, es ist nur unbequemer.
Gegen einfache Fehlbedienungen (versehentliches Löschen u.ä.) empfiehlt sich zusätzlich die (bei QNAP leider recht primitive) Snapshot-Funktion.
Für ein echtes Backup brauchst du externe Medien, die (außer während des Backupvorgangs selbst) physisch vom NAS getrennt und möglichst auch räumlich getrennt aufbewahrt sind.
Am einfachsten mindestens 3 reihum verwendete externe USB-Festplatten, alternativ ein Cloud-Dienst oder ein zweites NAS.
Das schützt gegen die häufigsten weiteren Schadensereignisse: Fehlbedienung, Hardwaredefekte des NAS selbst, Blitzschlag, Feuer, Wasser, Diebstahl, Malware-Befall ...
Hier nochmal die Kommandos:
#cat /etc/config/uLinux.conf | more | grep "Reset Password Switch"
Ahem. Sorry, aber dem geübten Shell-Benutzer graust es bei diesem Anblick.
Das | more ist da definitiv zu viel. Das more-Kommando dient dazu, bei der Textausgabe nach jeder Seite zu stoppen und auf einen Tastendruck zu warten. Das will man hier nicht. (more ist zum Glück so schlau, zu merken, wenn seine Ausgabe umgeleitet wird, und tut dann einfach gar nichts. Deshalb funktioniert es trotzdem.) Und das cat am Anfang ist ein klassischer Fall von "useless use of cat".
Die saubere Version dieser Kommandozeile lautet schlicht:
grep "Reset Password Switch" /etc/config/uLinux.conf"195.206.xxx.xxx" ist ein öffentliches Netz .. also NAS is definitiv in freier Wildbahn und ist mitunter schon infiziert.
Wobei das Auftreten der Meldung "Added to IP block list" eher gegen eine Infektion spricht. Wenn das NAS erfolgreich infiziert wurde, kommt die Meldung nicht. 
1. "Added IP address "195.206.xxx.xxx" to IP block list."
Heißt das evtl. dass da jemand versucht sich in mein NAS einzuhacken? Zu der genannte IP-Adresse jedenfalls habe ich nichts gefunden.
Das heißt, dass Dein NAS aus dem Internet erreichbar ist und deshalb die ständigen Portscans und Angriffsversuche, die auf alle Internetadressen laufend einprasseln, damit eben auch an Deinem NAS ankommen. Die konkreten Adressen, von denen die Angriffe kommen, sind völlig irrelevant, das sind eh nur gehackte IoT-Geräte und sonstige schlecht administrierte Systeme sowie Wegwerf-VMs bei irgendwelchen Clouddienstleistern.
2. "Das System-Standard-Gateway "Adapter 1" und alle Adapter konnten nach dem Überprüfen der NCSI nicht mit dem Internet verbunden werden."
Das scheint nur ein immer wieder mal auftauchender und vorübergehender Fehler zu sein, ich habe keinerlei Funktionseinschränkungen bemerkt. Aber was heißt das nun, und kann ich das ignorieren oder was ist zu tun?
Schalte NCSI ab. Wenn Du nicht mehrere alternative Internet-Zugänge hast, bringt die Funktion nichts und stört nur - z.B. durch solche Meldungen.
3. Was habt ihr für Erfahrungen mit den ständigen Firmwareupdates? Kommen m.E. doch sehr häufig, habe mir jedoch schon einmal damit meine Konfiguration zerschossen und bin daher jedesmal sehr skeptisch. Updaten oder besser nicht?
Grundsätzlich: Ein paar Tage bis Wochen (je nach Sicherheitsbedürfnis) hier mitlesen, was andere für Erfahrungen mit dem Update berichten. Wenn nichts ungelöstes (mehr) dabei ist, was Dich betrifft, updaten.
Wenn Du aber allen Empfehlungen zum Trotz weiterhin Dein NAS aus dem Internet erreichbar hältst: Sofort updaten! Immer! Jedes bekannt gewordene Sicherheitsleck wird sofort in massenhaften Scans ausgenutzt, und es ist nur eine Frage der Zeit, bis das bei Dir ankommt.
Auf meinem TS-228A habe ich für jeden Benutzer einen Home-Ordner unterhalb der Freigabe homes, wo nur der betreffende Benutzer Zugriff hat.
Daneben gibt es noch ein paar Freigaben mit allgemeinen Berechtigungen, z.B. das Software-Depot, wo alle lesen dürfen, aber nur ich schreiben darf.
Nun ergibt sich die Notwendigkeit, dass ein Benutzer Zugriff auf einen einzelnen Unterordner unterhalb des Home-Ordners eines anderen Benutzers benötigt.
Nach ersten erfolglosen Versuchen, die Zugriffsrechte so einzustellen, dass er da per \\nas\home\andererbenutzer\pfad\zum\unterordner drankommt, kam ich auf die Idee, diesen Unterordner einfach nochmal als eigene Freigabe \\nas\unterordner zu konfigurieren.
Leider funktioniert das nicht.
Der Benutzer sieht die Freigabe zwar, aber beim Versuch darauf zuzugreifen erhält er eine Windows-Fehlermeldung, er habe nicht ausreichende Berechtigungen.
Ich habe sowohl in der QTS-Oberfläche als auch im Windows-Dateiexplorer unter der Benutzerkennung des Besitzers dem anderen Benutzer volle Rechte erteilt und diese auch auf Unterordner und Dateien anwenden lassen.
Trotzdem behauptet Windows standhaft, dieser hätte keine ausreichenden Berechtigungen und solle sich an den Administrator (also mich:-/) wenden.
Mache ich etwas falsch oder funktioniert so etwas grundsätzlich nicht?
Was ist die Alternative?
Muss ich jeden Ordner, der eine besondere Kombination von Zugriffsberechtigten bekommen soll, als separate Freigabe einrichten?
Wenn ja, wie verfrachte ich am geschicktesten einen vorhandenen Unterordner in eine eigene Freigabe - möglichst ohne den gesamten Inhalt zu kopieren?
Im ersten Szenario läuft der Datenverkehr komplett über die pfsense.
Das muss er auch, sonst könnte sie ihn nicht kontrollieren.
Für volle 10 GBit Durchsatz muss die pfsense also in jedes der VLANs mit je 10 GBit angebunden sein.
Als router-on-a-stick mit 1x10GBit dot1q trunk wären noch 10 GBit halfduplex oder 5 GBit fullduplex drin, je nachdem, wie asymmetrisch Dein Traffic ist.
Wenn der Switch L3, also Routing macht, könnte er die VLANs auch direkt verbinden.
Dann ist die Firewall aber außen vor.
Allenfalls kann der Switch selbst, wenn er ACLs unterstützt, ein bisschen stateless packetfiltering machen.
Bei mehr als zwei VLANs sind auch Kombinationen denkbar, z.B. zwei High-Traffic-VLANs direkt im L3-Switch gekoppelt und ein DMZ-VLAN per externer Firewall abgeschottet.
Muss man überlegen, ob man die Komplexität will und braucht.
802.3ad muss der Switch nur erfüllen dafür ist managed keine Vorraussetzung
Man muss die Link Aggregation Group konfigurieren können, sprich irgendeine Form von Management muss es geben.
Siehe z.B. TL-SG105E 5-Port-Gigabit-Unmanaged Pro Switch unter Spezifikationen dort steht Static Link Aggregation
Die "Easy Smart" Switches von TPLink sind nicht unmanaged, selbst wenn sie so heißen.
Auf der von dir verlinkten Seite ist sogar ausdrücklich von "Zentralem Management" die Rede.
Was auch geht falls die Switches es unterstützen, Portbündelung.
Ist bei unmanaged Switches leider keine Option.
Müsste bei -t nicht ntfs als Parameter mitgegeben werden?
Das wäre der Wert für den Fall, dass eine NTFS-formatierte Platte als Block Device direkt am Linux-System angeschlossen ist.
Oder smb?
Nein, cifs ist schon richtig. mount verwendet da noch den veralteten Namen. Sieht man auch an der Fehlermeldung: es ruft korrekt das Helper-Kommando mount.cifs auf, nur wirft das dann errno 13 = "permission denied" aus. Warum es das tut, hinterlässt es üblicherweise im Syslog.
Und was ist mit der Verwaltung? Irgendwo muss das System ja nachsehen wo die aktuellen Versionen liegen.
Das muss es auch, wenn gar keine Snapshots vorhanden sind.
Wie gesagt: wenn die Struktur vernünftig aufgebaut ist, dauert das Nachsehen nach der aktuellen Version nicht länger, nur weil mehr andere Versionen da sind.
Um die Ursache des Problems einzugrenzen empfiehlt sich ein Blick ins Syslog. Dort hinterlässt mount in der Regel nähere Informationen darüber, warum es die Operation nicht ausführen konnte.
Spontan vermisse ich in der zitierten Kommandozeile die Angabe eines Passworts.
Mir würde es aber erhebliche Zweifel bereiten, denn warum sollte das Backupsystem nicht auch befallen werden, wenn entsprechende Daten schon dahin übertragen werden?
Ein großer Vorteil von NASen ist, dass sie wesentlich besser zwischen Programmen und Daten trennen als ein normaler PC oder auch ein Windows-Server.
Will sagen: selbst wenn man eine Datei mit Schadsoftware auf dem NAS speichert, wird dadurch das NAS nicht von der Schadsoftware befallen.
Erst wenn jemand eine Sicherheitslücke findet und ausnutzt, die das NAS dazu bringt, etwas von den Daten, die es eigentlich nur speichern soll, spezifikationswidrig als Programm auszuführen, wird es gefährlich.
Tatsächlich erfolgen Angriffe auf NAS in der Regel nicht durch Ablegen irgendwelcher präparierter Dateien auf Freigaben, sondern über Sicherheitslücken in Netzwerkdiensten.
Darfst du auch, aber wenn eine Datei dann aus 257 Teilen besteht, wird es beim lesen schon mal doof.
Also Sprich du liest erst die Org Datei und dann die nachfolgenden 256 änderungen, wenn es hart auf hart kommt.
Das ist dann aber eine sch-, äh, subobtimale Implementierung.
Bei vernünftigen Snapshot-Implementierungen hat man die aktuelle Version am Stück und die Deltas zu den vorhergehenden Versionen dahinter.
Performance kostet dann nur das Schreiben auf seit Erstellung des Snapshots nicht modifizierte Blöcke (Copy on Write) und der Zugriff auf ältere Versionen.
Wenn du neu machst, dann ziehe ein oder zwei Leerroher ein und lege de Grundlage für die Optin OM4+, dann kannst du später auch mal 25G aufwärts fahren.
Wenn man neu baut, ist das einfach. Kompliziert sind immer die Altbestände. Zieh mal in einen 70er-Jahre-Bau ein oder zwei Leerrohre ein ...
Gibt also doch eine Limitierung der Snapshots.
Hängt aber wohl auch noch von der eingesetzten Firmware ab. Je älter desto weniger. Habe im Internet auch noch ein paar ältere Angaben dazu gefunden.
Das sind die offiziellen Limits, die QTS selbst durchsetzt. Das heißt, man kann einfach nicht mehr anlegen. Wenn man es versucht, sagt einem QTS klipp und klar: maximale Anzahl Snapshots erreicht.
Der Beitrag weiter oben klingt aber so, dass schon vor Erreichen dieses Limits Probleme zu erwarten sind. Das ist dann doch überraschend. Wenn schon ein Limit definiert ist, würde ich erwarten, dass man das auch ausschöpfen darf.
So wie ich den TE aber verstehe, könnte der an beiden Seiten direkt einen passenden Switch anschliesen und jegliche Dose oder PatchPanel vermeiden.
Ich hoffe für ihn, dass die Enden des aufwendig verlegten Kabels auf Cat5e-Dosen aufgelegt sind.
Sonst ist von dem Cat5e nach 15 Jahren wahrscheinlich nur noch Cat4¾ übrig.
Kann ich irgendwie einstellen, dass eine IP automatisch nach zB 4 Fehlversuchen für immer gesperrt wird.
IP-Adressen dauerhaft sperren bringt exakt gar nichts.
Kein ernsthafter Angreifer ist so dumm, eigene IP-Adressen für Angriffe zu nutzen.
Das kommt immer über wechselnde Adressen fremder gehackter Systeme.
Sperrst du eine, geht's von der nächsten weiter.
Wenn es um wirkliche Sicherheit geht, ist eine Sperre für 5 Minuten genauso gut wie eine "ewige" Sperre. (Ein hinreichend langes und zufälliges Passwort vorausgesetzt.)
Wenn es um das Genervtsein durch die Meldungen geht, gibt es nur die Alternative: Abschalten.
Wie gesagt: was im Internet erreichbar ist, wird auch angegriffen.
Auch SSH hatte schon so einige Lücken und es werden auch noch welche folgen.
Denn da steckt SSL hinter was lange als absolut sicher galt bis dann Tag x kam.
Das kann ich so nicht stehen lassen.
Erstens steckt nicht SSL hinter SSH. SSH und SSL sind zwei völlig unterschiedliche Protokolle. Bestimmte Implementierungen dieser beiden Protokolle benutzen (wie fast alles in der Softwarewelt) teilweise die gleichen Komponenten, und wenn ausgerechnet in einer solchen Komponente ein sicherheitsrelevanter Fehler steckt, ist das natürlich blöd. Aber weder ist damit gesagt, dass sich der Fehler in beiden Implementierungen in gleicher Weise als Sicherheitslücke niederschlägt. Noch hat jede Sicherheitslücke von SSL auch eine Sicherheitslücke von SSH zur Folge oder umgekehrt.
Zweitens hat kein vernünftiger Mensch SSL jemals für absolut sicher gehalten. Ganz im Gegenteil: von Anfang an wurden Angriffsszenarien diskutiert, ja sogar (die Älteren unter uns erinnern sich) absichtlich die Sicherheit für Anwender außerhalb der USA eingeschränkt, immer wieder neue Verschlüsselungs- und Hash-Algorithmen eingeführt, Schlüssellängen diskutiert und Empfehlungen angepasst. Es ging nie um absolute Sicherheit, immer nur darum, den Aufwand für den potentiellen Angreifer hoch genug zu treiben, dass ein erfolgreicher Angriff unwahrscheinlich oder für den Angreifer unwirtschaftlich wird.
Und drittens gab es keinen Tag x. Bei beiden Protokollen und bei allen ihren Implementierungen wurden und werden laufend Fehler und Sicherheitslücken gesucht, gefunden und behoben. Mal größere, mal kleinere. Mal solche, die den Einsatz komplett infrage stellen und mal solche, wo Ottilie Normaluser sagt "so what". (Wenn sie Englisch kann.) Ab und zu schrie die Presse dann "Super-GAU" und der Fachmann schüttelte den Kopf. Aber "Tag x", vorher sicher, nachher unsicher? Nö.
