Jump to content

mcdaniels

Premium Member
  • Gesamte Inhalte

    1.840
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von mcdaniels

  1. Nachsatz: Hab jetzt rein interessehalber nochmals eine 64GB Samsung SSD verbaut (schon etwas älter). Hiermit erhöht sich die Datenrate NAS -> PC auf 400MB/SEC. Die Datenrate von PC -> NAS ist wiederum etwas schlechter. Um die 200MB/SEC.

     

    Ich muss aber dazu sagen, dass ich mir nicht die Mühe gemacht habe, die genauen Specs der alten SSD nachzuschlagen.

     

    Unterm Strich bin ich nun der Meinung, dass dieses NAS durchaus für den gehobenen "Heimanwender" ausreicht. Ob eine derartige Investition (NAS, Switch, NIC - 10GBIT) dafür steht, lasse ich allerdings im Raum stehen.

     

    Danke für euren Support!

    vor 4 Stunden schrieb Nobbyaushb:

    Ich komme bei uns mit Single-10G auf Transferraten von 755MB/s bis 977MB/s - beweisbar mit einem 8,8GB großen ISO :-)

    ...aber mit Sicherheit nicht mit einem derartigen NAS System, sondern mit "etwas Gescheitem" ;-)

  2. vor 3 Minuten schrieb XP-Fan:

    Hi,

     

    also von den WD NAS HDD kannst du nicht mehr erwarten.

     

    Als einzelne Platte hast du für die WD30ERFX Host to/from buffer: 145MB/s

     

    Wenn man jetzt theoretisch sagt beim RAID 0 verdoppelt sich der Speed so sind die 300MB doch schon am Maximum.

     

    Wenn du mehr haben willst müsstest du schon z.B. die Samsung Evo 850/860 500 GB mit SATA Interface einsetzen, dann wären in Theorie

    die 1000MB / Sec im RAID 0 möglich sofern dann auch die restliche Hardware den Durchsatz mitmacht.

     

    Denk aber dran, wenn du zuviel Daten auf das NAS schaufelst wird das Teil immer schwerer ! :D

     

    Hey! :-)

     

    Ja ich hatte es zuvor auch mit einer SSD versucht. Es war aber offenbar generell dieses Network Traffic Tool....

     

    JA, ich muss den Tisch verstärken, wenn ich viele Daten drauf schaufel... *lach*

     

    @DocData: Naja jetzt ist es zumindest besser wie zuvor!

  3. vor 3 Minuten schrieb Nobbyaushb:

    Vielleicht kann der in dem NAS verbaute Controller nicht mehr...

    Das wäre dann ja eigentlich eine Mogelpackung a la carte und eine Frechheit. Was mir gerade vorhin aufgefallen ist, ist, dass die CPU Load auf dem NAS beim kopieren von NAS -> PC auf 100% ansteigt. (allerdings offenbar "nur" ein Kern).

     

    Beim Kopieren von PC auf die NAS bleibt die CPU recht "cool".

     

    Ein Wahnsinn, wenn die Hardware rund um den 10gbit Controller zu klein dimensioniert wäre. Allerdings würde das den Preis erklären!

     

  4. Schönen Nachmittag!

    ich baue mir @Home testhalber gerade ein 10Gbit Netzwerk auf. Hierbei setze ich auf ein 10Gbit NAS (Asustor), Asusswitch (XGU-2008) und eine Intel X550-T2, 10Gb-Ethernet-Netzwerkkarte.

    Verkabelung CAT5e,

    Kabellängen max. 1,5 Meter.

     

    In der NAS sind 2 WD-RED 3TB HD verbaut, die (testhalber) im Raid0-Mode laufen.

     

    Kopiere ich nun vom PC (Samsung SSD) auf das NAS eine größere Datei (2GB), dann erhalte ich nur Datenübertragungsraten von 130MB/sec. Hab schon ein wenig mit den Settings der NIC s) experimentiert. Dennoch bleibt der Transferspeed immer gleich (schlecht).

     

    Ein Kopiervorgang vom NAS hin zum PC ist noch viel langsamer: 34 Mb/sec.

     

    Der Link wird am PC/NAS mit 10Gbit erkannt. Würden die Kabel das Problem sein, dann wäre der Link wohl nicht mit 10Gbit online.

     

    Ich denke dass der Raid 0 Verbund schon eine etwas bessere Leistung bringen sollte? Bin etwas überrascht, dass die Performance so derart mies ist.

     

    Teste nachher noch mit einer single SSD.

     

    EDIT: SSD verbaut,

    Kabel auf CAT6 getauscht.

    Speed exakt gleich "langsam"....

     

     

  5. vor 3 Minuten schrieb NorbertFe:

    Ja und Weltfrieden sollte ebenfalls herrschen und Milch und Honig fließen.

    das hast du gut erkannt :-P (ich meinte natürlich im Optimalfall).

     

    vor 3 Minuten schrieb NorbertFe:

    Die die sowas als "Ausrede" verwenden haben auch vorher schon nicht gepatcht. Auch wenn die Qualitätsprüfung bei MS in letzter Zeit eher suboptimal arbeitet, läßt sich vieles eben mit einem vernünftigen Patchmanagement regeln.

    kenne ich genug!

     

    vor 3 Minuten schrieb NorbertFe:

    Naja wenn man manche "Unternehmensnetzwerke" kennt, dann wundert einen das wenig bis gar nicht.

    Die meisten Netzwerke sind ganz sicher nicht "perfekt" aufgebaut. Manche eben zwangsläufig nicht...

     

    U.a. deshalb ist ja div. Schadsoftware so erfolgreich.

  6. Am 25.12.2018 um 20:58 schrieb RolfW:

    Das Problem ist nur, dass die Chefs durchweg kein Ohr dafür haben. Selbst wenn man DSGVO sagt...

    Absolut korrekt!

     

    Am 25.12.2018 um 20:58 schrieb RolfW:

    Ich denke, dass man sich auch intern (Domäne) absichern sollte. Nur das ist dann ein großes Fass. 

    Das andere ist, wie findet man heraus, ob das AD kompromittiert ist... und wenn, nisten die sich dann gezielt ein und lauschen sehr lange mit, um möglichst an viele Daten zu kommen. Die Zeit zu zerstören ist vorbei...

    Ja und nein, denke ich. Es kommt ganz darauf an, was dieses "Ding" nachlädt. Wie man so liest, kann die nachgeladene Software individuell sein. Für eine Domäne vermutlich ein Supergau?

     

    Dies bestätigen Artikel, in denen es heißt: "In mehreren dem BSI bekannten Fällen hatte die Infektion große Produktionsausfälle zur Folge, sodass ganze Unternehmensnetzwerke neu aufgebaut werden mussten."

     

    Uns ist allen klar, dass es keinen 100% Schutz gibt. Panik ist natürlich auch fehl am Platze. Ich für meinen Teil setze aber -im Rahmen meiner Möglichkeiten- alle Hebel in Bewegung, um möglichst gut geschützt zu sein.

     

    Betreffend Windowsupdates,  sehe ich da auch ein Problem. Aufgrund diverser Vorkommnisse mit fehlerhaften Updates seitens MS, sind viele Admins beim Einspielen von Updates sehr vorsichtig geworden. Will heißen, sie spielen die Updates nicht zeitnah ein, sondern warten mal ab. Dass dies zu einem Boomerang werden kann, versteht sich.

     

    Es sollte also gar nicht erst soweit kommen, dass ein Script / Schadcode etc. die Möglichkeit bekommt, eine Sicherheitslücke auszunutzen.

  7. Ist es aber nicht im Interesse des “Firmennetzwerkes“ gewisse Sicherheitsmechanismen zu aktivieren? 

     

    Wenn ich da u.a. an die DSGVO denke, muss man dem Anwender, sofern man Firmengeräte zur Verfügung stellt, entsprechend abgesicherte Geräte zur Verfügung stellen.  Security by design.

     

    Im Zeiten wie diesen eher wenig angenehm, wenn du quasi nicht reagieren darfst.

  8. All das von euch Erwähnte kenn ich sehr gut. ;) 

     

    @magheinz habt ihr incoming / outgoing ssl deep inspection aktiv, was den Traffic angeht? 

    Scannt ihr den Datenstrom in das bzw. aus dem Internet. Fortigate zB macht das ganz gut. (DNS Blacklists, Antivirus etc).

     

    Bei mir wurde auf diesem Wege mehrfach verhindert, dass die Schadsoftware nachgeladen wurde, nachdem ein User auf einen Link geklickt bzw. ein Makro aktiviert hat.

     

    Wie bei dir, fehlt aber jegliches Bewusstsein für die Gefahr, die von derartigen Bedrohungen ausgeht. Selbst wenn man es 100x erwähnt.

     

     

  9. @multikulti

    an sich will ich hier nicht explizit auf "meinen" Stand der Dinge eingehen, sondern vlt. eine generelle Diskussion anstoßen. Meine bisherigen Sicherheitsvorkehrungen konnten uns Gott sei Dank bislang vor einem GAU bewahren.

     

    Ja genau, das wäre zum Beispiel eine Frage: Wie will man einen sauberen Stand identifizieren?

    Wird vorhandene Antivirussoftware einen Befall identifizieren?

    und und und...

     

    Hat es schon mal jemanden von euch hier erwischt... gibt es Erfahrungen?

  10. Hallo zusammen,

    angesichts der Entwicklung von immer gefährlicheren Trojanern, die mittlerweile auf zig hochtechnisierte Mittel zur "Systempenetration" setzen, wollte ich hier mal eine Diskussion starten, wie das bei euch (auch im Firmenumfeld) gehandhabt  wird. Wundert mich etwas, dass es hier noch keine Diskussion darüber gibt. ;-) (vielleicht habe ich sie aber auch einfach bislang nicht gefunden / nicht gut genug gesucht)

     

    Aktuell ist der Hauptangriffsvektor das altbekannte Email. Entweder mit Anhang, oder mit einem Link. Das ist ja an sich überhaupt nichts Neues mehr. Was mich (fast) schockiert ist, wie ausgekocht die Ganoven mittlerweile sind. "Belauschen" von Opfern,  analysieren des Emailverkehrs, analysieren wer mit wem kommuniziert. Darauf aufsetzend dann exakt auf die "Zielperson" zugeschnittene Emails, in perfektem Deutsch und mit Inhalten die den tatsächlichen laufenden Geschäften des Betriebes entsprechen. Was alle gemeinsam haben: Die Hartnäckigkeit. Irgendwann klickt ein User den Link an, oder öffnet einen Anhang / aktiviert das Makro etc.. Das Schlimme dabei ist, dass viele der User dann ja mal nichts sagen...

     

    Unsicherheitsfaktor: Benutzer

    Das war schon immer so und wird auch weiterhin so sein.

    Somit kann man logischerweise nur versuchen proaktiv gegen diese Bedrohungen vorzugehen.

     

    Ich denke hier an:

    Benutzerschulungen, Benutzer fortlaufend informieren.

    Systeme immer auf dem aktuellen Stand halten.

    Virenscanner aktuell halten.

    Scan des incoming und outgoing Traffic. Unbedingt SSL-Inspektion (SSL Deep Inspection) des Traffic. Bei nicht vorhanden sein eines SSL Scans, reißt man meines Erachtens ein gravierendes "Loch" auf.

    Blocken von div. Inhalten, die per Mail kommen / User dürfen so gut wie nichts herunterladen. (schon gar keine ausführbaren Dateien und Scripts).

    Nie mit Adminrechten / oder gar Domainadminrechten auf einer Workstation arbeiten.

    Makrosicherheit so hoch wie möglich einstellen. Bestenfalls Makros abdrehen (geht aber nicht immer).

     

    Was machen wenn der Trojaner bereits aktiviert wurde

    Hier bin ich mir, angesichts der letzten Informationen, nicht mehr sicher. Dass der PC, von dem die Verseuchung ausging, von Netz genommen wird, ist klar. Damit ist es aber bei Weitem noch nicht getan.

    Man liest, dass zb der Emotet-Trojaner zuerst mal im Hintergrund wartet und versucht, möglichst viel über das System zu "lernen". Hierbei zielt er u.a. darauf ab, Domänenadminrechte zu erhalten und quasi die Domäne zu "übernehmen".

     

    Was heißt das für den Admin? -> Bei Infektion -> Am Besten die Domäne neu aufziehen? Sofern eine Infektion stattgefunden hat, kann man sich ja nie mehr sicher sein, dass alles mit rechten Dingen zugeht.

     

    Wie seht ihr das bzw. was ist eure Meinung dazu?

     

     

     

  11. Hallo Leute,

    demoten werd ich ihn vorerst wohl nicht, nachdem alles andere ohne Probleme läuft. Trotzdem passts mir nicht, dass es nicht ganz rund läuft :-)

    Der DC1 macht auch noch WSUS und hat ein paar andere Services inne.

     

    Die 999 Tage MaxOfflineTimeInDays sind zwar sehr hoch angesetzt, haben aber damit wohl nix zutun? Sollte man das besser wieder runtersetzen, oder ist das irrelevant?

  12. Hi Norbert,

    danke für den Link.  Da würde ggf. das hier passen: https://support.microsoft.com/en-us/help/2996883/dfsr-stops-replication-after-an-unexpected-shutdown-in-a-windows-8-1-o   ist aber für Server 2012 R2 (nicht für  2012).

     

    Folgendes kann ich an Informationen noch beisteuern: Die lange Phase in der die 2 DCs keine funktionierende DFS Replikation hatten, wurde dadurch verursacht, dass der DC1 immer wieder abgestürzt / neu gestartet ist. Daraufhin hat dann die Replikation nicht mehr funktioniert. Event ID: 4012. Der replizierte Ordner war zu lange offline (384 Tage). (Meldung auf DC1).

     

    Es wurde -wie weiter oben erwähnt- die MaxOfflineTimeInDays auf den Wert 999 erhöht.

     

    Nachdem es gestern normal funktioniert hat. Habe ich aktuell diesen Status:

     

    DC1: File im Sysvol erstellt -> repliziert nicht auf DC2

    DC2: File im Sysvol erstellt -> repliziert auf DC1

    DC1: File im Sysvol gelöscht -> wird nicht auf DC2 gelöscht

    DC2: File im Sysvol gelöscht -> wird auf DC1 gelöscht

     

    D.h. das Problem besteht von DC1 -> DC2

     

    Ein Restart des Dienstes DFS-Replikation auf DC1 reicht aus, um die Replikation DC1->DC2 wieder in Gang zu setzen.

     

    Die Frage, die sich mir stellt, ist, was man aufgrund der Historie des Problems jetzt bestenfalls machen könnte.

     

    Danke nochmals.

     

×
×
  • Neu erstellen...