Jump to content

blub

Expert Member
  • Gesamte Inhalte

    7.598
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von blub

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

  2. Hi,

     

    heute habe ich gleich bei 2 Kunden Diskussionen gehabt, dass das Schema nicht während des normalen Betriebes erweitert / hoch gehoben werden darf.

    Im Normalfall führe ich die Änderungen durch und erwarte keine Probleme (Exchange Admin)

     

    Also einmal die Frage in die Runde:

     

    Habt ihr in den letzten 5 Jahren Probleme gehabt, wenn ihr ein AD mittels Exchange oder Skype / Lync Setup erweitert habt oder von 2003 auf 2008 (2012) gehoben habt?

    Mir persönlich sind da schon lange keine mehr untergekommen.

     

    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.

  3. https://technet.microsoft.com/en-us/library/cc756561(v=ws.10).aspx

     

    Schema operations include the following:Updating the schema cache

    • Updating the schema index
    • Implementing schema modifications
    • Maintaining schema integrity

     

    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.

  4. Kunden sind einmal klein, 3 DCs, einmal größer (>30DCs)

     

    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. 

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

  6. Ja, ich muss mich bei euch entschuldigen.

    Meine Erwahrtungshaltung war vielleicht etwas zu hoch.

     

    Aber wozu gibt es Foren?

     

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

    • Like 1
  7. @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)

  8.  

    Ca. 2 Tsd Kassen in ganz Österreich. Kassen sollen eine gesicherte Verbindung aufbauen und keinen Tunnel über diverse Hardware bis jetzt.

    Shops werden in der Zentrale ausgerollt und würdendas Zertifikat schon vorinstalliert bekommen. Dieses würde sich auf einer extra Platine mit extra Schutz befinden.

    Aufgestellt und eingeschaltet können sich diese gleich mit der Zentralle verbinden.

     

     

    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!

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

     

     

    Dafür reicht die Genauigkeit in praktisch allen Fällen aus.

    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)

  10. zwei Gründe aus dem oben verlinkten Blog:

     

    Summary

    LastLogonTimeStamp might not always be updated by an actual Logon. S4u2Self requests for access checks can update the attribute

     

     

    Moin,nein. Deine Vorbehalte sind nachvollziehbar, aber für die meisten Szenarien gar nicht zutreffend - unter anderem für das hier diskutierte.

     

    In welchen Szenarien trifft denn S4uSelf zu und wann nicht?

  11.  

    Woher hast Du die Methode '*.SaveAs()'?

    $excel = new-object -comobject excel.application
    $excel | Get-Member | Where-Object -FilterScript {$_.MemberType -eq 'Method' -and $_.Name -like 'save*'}
    

    ... bei mir gibt es die gar nicht.

     

     

    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?

  12. Das Ganze ist nicht mein "Baby", aber ich gehe stark davon aus das dies alles rechtens ist denn hier kann man sich keinen Fehler erlauben(!) - Zudem haben wir hier eine Armada von Rechtsanwaelten, Regulatoren etc. die den ganzen langen Tag sich um nichts anderes kuemmern, ...

    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   )

  13. "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.

  14. Entschuldigung, aber allein deswegen davon auszugehen, dass die Kiste versucht ist, ist totaler Humbug. Tut mir leid.

    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%      

     

     nur weil ein hohes Risiko besteht, ist doch noch kein Schaden eingetreten.

     da fällt mir kein Gegenargument mehr ein.

  15. 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:

     

     

    Organizations that do not scan for vulnerabilities and proactively address discovered flaws face a significant likelihood of having their computer systems compromised. Defenders face particular challenges in scaling remediation across an entire enterprise, and prioritizing actions with conflicting priorities, and sometimes-uncertain side effects. 

     

    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

×
×
  • Neu erstellen...