blub

Sag mal Nils, soll ich mir jeden Beitrag vorher von dir genehmigen lassen? Was bildest du dir eigentlich ein? :shock: :shock: :shock: Jedesmal geht das so!

Zumindest Kapitel 7 und 8 sollte man sich ansehen. https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904

Wielange dauert denn der Bootprozess des physik. Servers? Von früher kenn ich es, dass solange/ sobald die NIC antwortet, der DNS auch Anmeldungen an dessen DC sendet. Dieser kann aber solange nicht antworten, bis das OS wieder komplett oben ist, bzw. erst wenn der Server komplett unten ist, schickt der DNS ihm auch nichts mehr.

wie machen es denn die anderen Bereiche der Hochschule? Active Directory ist kein Hexenwerk, aber allein auf weiter Flur, ohne Kollegen mit denen man sich austauschen kann, würde ich es nicht machen wollen. Und wenn, dann zumindest nicht lokal: https://goo.gl/vS1KhR

https://isc.sans.edu/mspatchdays.html?viewday=2017-03-14 https://krebsonsecurity.com/2017/03/adobe-microsoft-push-critical-security-fixes-10/#more-38549 bereits mit Exploit in der freien Wildbahn bitte keine Monate mit dem Patch warten. (ISC Rating: Patch Now)

Jo, der Punkt geht klar an Dich. Ich denke, dass zumindest bei den 30 DCs ein Changemanagement existiert, welches das Risiko anhand der vorhandenen Informationen sorgfältig einschätzt und nicht einfach Auge mal Pi über das wann entscheidet. Das Risiko besteht außerdem nicht darin,ob eine Re-Indizierung auf jedem DC erfolgt, sondern wielange diese jeweils dauert.

Meine Antwort ist: Ja, ich habe reproduzierbar -nicht nur einmalig- den oben beschriebenen, bei Microsoft bekannten, technisch nachvollziehbaren Effekt gehabt, so dass ich zu einem Schemaupdate außerhalb der Geschäftszeiten rate. Mehr will ich dazu nicht mehr schreiben, außer der To selbst hat noch Fragen.

https://technet.microsoft.com/en-us/library/cc756561(v=ws.10).aspx Vielleicht ist Wortwahl "neu aufgebaut und indiziert" in den Ohren eines Datenbank-Experten nicht korrekt. Jedenfalls den möglichen Effekt einer 95-100% igen länger dauernden Prozessorlast auf DCs (2008R2) kann ich dir aus eigener Erfahrung und mit Bestätigung durch Microsoft versichern. Eine Umgebung mit 30 DCs ist auch nicht mehr ganz klein.

Es wird die lokale AD Datenbank auf jedem DC neu aufgebaut und indiziert. d.h. bei großen ADs mit vielen Objekten bzw. schwächeren DCs können diese DCs mehrere Minuten bis zu ein paar Stunden durch diesen Neuaufbau zu 100% ausgelastet sein. Wenn das auf mehreren DCs unkontrolliert bzw. gleichzeitig passiert, meldet sich in dieser Zeit niemand mehr am AD an. Es gibt zwei Eventlogeinträge auf jedem DC, wenn die Neuinitialisierung der DB beginnt bzw. abgeschlossen ist. Also ja, wenn man sich unsicher ist, besser den Schemaupdate außerhalb der Geschäftszeiten ausführen oder das Update kontrolliert auf einem DC nach dem anderen durchführen lassen. Dafür gibt es Artikel bzw. Regkeys zum Steuern. Einfacher ist es aber, der Umgebung einfach ein paar Stunden Zeit nach dem Update einzuräumen. Dann hast du auch ein Gefühl für das nächste Mal.

Nur um mal ein Beispiel der Komlexität zu geben: Bei einem Bankprojekt haben wir wörtlich Monate benötigt, nur um heraus zu arbeiten, ob eine interne (Microsoft) PKI/ CA oder eine fremdgehostete CA besser geeignet war. Trotz vorhandenem sehr großem Banken-RZ-Verbund war letztlich für diese speziellen Anforderungen eine Verisign CA bei einem Drittanbieter die bessere Variante.

Überleg mal selbst: Wieviele Personentage haben dein Chef und Du für dieses Projekt beim Kunden veranschlagt und in euer Angebot geschrieben? Was ist euer Tagessatz und wieviele Tage erwartest du, dass dir Boardspezialisten für lau abnehmen? Dafür sind Foren aber nicht da. Tipps und Hinweise, die im Rahmen einer Forendiskussion üblich sind, hast du durchaus bekommen.

@smigi, wieiviele Euros werden etwa pro Jahr über diese 2000 Kassen abgewickelt? Wird auch mit Kreditkarten incl. PINs gearbeitet? Ich habe das Gefühl, dass jemand deinen Chef und Dich gehörig über den Tisch ziehen will und kostengünstig die Verantwortung für eine veraltete, mittlerweile ungenügend gesicherte Umgebung, abschieben will. So wie dein Chef es mit dir macht, so geht man doch nicht an ein derartiges Projekt ran! Apropos Nachteil eines Wildcardzeritifikats: Sobald eine deiner Kassen fällt, sind auch die übrigen 1999 gefallen. (*.meineKassen.at)

Abseits vom technischen Aspekt: Dein Chef und du betretet offenbar den Bereich Zahlungsverkehr mit seinen ganzen juristischen Besonderheiten und Regelungen, auch für eine PKI. Seid ihr euch dessen bewusst? Ein aktuelles, vergleichbares Beispiel aus den USA mit 3300 Kassen zeigt, welcher Schaden entstehen kann. https://krebsonsecurity.com/2017/02/fast-food-chain-arbys-acknowledges-breach/ Es gibt leider viele böse ITler draußen, die nur auf ähnliche Gelegenheiten warten!

Lies dir doch bitte den Blog mal durch! Der S4uSelf Mechanismus führt dazu, dass Userkonten und Maschinenkonten ihren LastLogonTimeStamp updaten, obwohl niemand die Konten benutzt bw. die zugehörigen User bzw. Maschinen schon längst nicht mehr existieren. d.h. ein uralt, seit ewigen Zeiten, unbenutzter, und sogar disabled Account bekommt trotzdem einen aktuellen Zeitstempel durch das System. das hat mit Genauigkeit überhaupt nichts zu tun! Man kann bei der Verwendung des LLTS durch Laien davon ausgehen, dass irgendwann die Panik aufkommt, weil ein disabled Useraccount oder Maschinenaccount einen aktuellen Zeitstempel hat. (siehe das zitierte Praxisbeispiel). Deswegen "Finger Weg von dieser Property", die hat keine zuverlässige Aussagekraft. Der Blog ist nicht ganz einfach zu verstehen, aber der Sachverhalt ist detalliert beschrieben. Das hat nichts, aber auch gar nichts mit "den meisten Szenarien" ode "unpassender Kritik" zu tun, sondern mit Kerberos Mechanismen. Den Blog lesen und verstehen muss man! (zumindest das bereits zitierte Summary am Ende)

zwei Gründe aus dem oben verlinkten Blog: In welchen Szenarien trifft denn S4uSelf zu und wann nicht?

Finger weg vom LastLogonTimeStamp Theoretisch: https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/ Praktisch http://www.mcseboard.de/topic/205328-aktualisierung-lastlogontimestamp-problemk%C3%BCndigung/

Weil "SaveAs()" eine Workbook-Methode ist https://msdn.microsoft.com/de-de/library/microsoft.office.tools.excel.workbook_methods.aspx @To: gibt es eine Fehlermeldung?

vielleicht hat er irgendwo eine Zip-Bombe liegen, die immer wieder aufs Neue zündet. http://www.theprohack.com/2009/03/create-zip-bomb-zip-of-death.html läuft ein 7z/ winzip Prozess?

Ich hatte aus reiner Neugier gefragt, da ich die Software nicht kenne. Ich zweifel keinesfalls an, dass hier keine Fehler gemacht werden bzw. etwas nicht rechtens sei! (jetzt stimmt hoffe ich auch die Grammatik :D )

Sind diese Daten dann VS-Nfd? Ist Secure Island dafür zertifiziert?

"vertraulich" klassifizierte Daten dieser Art werden bei uns mit "Sophos Lancrypt" zusätzlich verschlüsselt. Man kommt dann nur noch mit dem Lancrypt-Passwort ran. Man darf aber nicht nur die Software installieren und dann vergessen, sondern muss sich um regelmäßige PW-changes, regelmäßige Software-Updates etc. kümmern. Reine AD-Berechtigungen reichen nur für "intern" klassifizierte Daten. Ab "streng vertraulich" wird's interessant :cool: :cool: Überlege dir vielleicht nicht nur ein Konzept für "data at rest", sondern auch für "data in motion". z.B. auf vertrauliche, streng vertrauliche Daten darf nicht von WindowsXP oder von mobilen Geräten zugegriffen werden, etc.

Wenn nur ich davon ausgehen würde, wäre es vielleicht "totaler Humbug". Nur wenn mit die angesehendsten Sicherheitsexperten weltweit (CSC/ SANS, etc.) eine "significant likelihood of having their computer systems compromised " sehen, wenn bekannte Sicherheitslücken nicht geschlossen werden, würde ich etwas leiser treten! Und "significant likelhood" bezieht sich nur auf aktuelle, aber ungepatchte Systeme, nicht einmal auf EOL-Systeme wie Windows2003, die man schon lange nicht mehr patchen kann (Ich geh nicht davon aus, dass der TO das dafür notwendige Geld regelmäßig an MS überweist). Was ist die Steigerung von "significant likelhood"? 99 bis 100% da fällt mir kein Gegenargument mehr ein.

Kennst du die CIS-Controls? Das sind die 20 goldenen Standard-Regeln für eine sichere IT. Geschrieben von Security-Experten aus der weltweiten IT-Community. Die Top 5 findest du hier: https://www.cisecurity.org/critical-controls.cfm oder komplett: https://www.cisecurity.org/critical-controls/Library.cfm unter CSC 4: Wie hoch der To oder sonst jemand die Restwahrscheinlichkeit einschätzt, bei einem seit Jahren ungepatchten 2003-Server nicht compomised zu sein, bleibt selbstverständlich jedem selbst überlassen. Ich bleibe bei meinen fast 100% :) Man kann sich in einem solchen Fall auch einen hochbezahlten CSM-Spezialisten https://www.sans.org/reading-room/whitepapers/analyst/continuous-monitoring-is-needed-35030 holen, der sich die Umgebung vor dem Update ansieht. Für CSM gibt's geile und sogar kostenlose Werkzeuge! z.B. sguil http://bammv.github.io/sguil/index.html

Schlag doch mal Begriffe wie SMB1.0 oder "End of Life" nach. Dann schaust du vielleicht mal ab und an Nachrichten.

aus den ersten drei Sätzen: