blub

Hallo, In der beschriebenen Konstellation kannst du zu fast 100% davon ausgehen, dass du Schadsoftware auf dem Server hast, die genauso sicher früher oder später aktiv sein wird, bzw. schon längst ist. Je nach dem wieviel dir bzw. deinem Chef die Umgebung Wert ist, würde ich bei der jetzigen Gelegenheit über einen kompletten Neubeginn und ein anderes Design nachdenken. blub

Hallo wuurian, Als Entscheidungshilfe pro und contra -um Anregungen dazu dürfte es dir ja hauptsächlich ankommen- für einen Windows Trust:. Pro; - Wenn sich die Betreiber beider Domänen vertrauen, vielleicht sogar dieselben Administratoren haben - wenn beide Domäne dasselbe Sicherheitslevel haben (z.B. Passwortrichtlinien, Lockout-Policies, etc.) - wenn beide Domäneverantwortlichen (sprich die Finanzierer der Domänen, nicht die Administratoren) zustimmen spricht m.E. nichts gegen einen Trust. Ein Trust ist kein Hexenwerk, aber muss sauber dokumentiert sein. Je nachdem wie weit die Domänen voneinander getrennt sind und welche Werte dahinter stecken, kann man sich überlegen, ob und wie man die Zusammenarbeit der Domänen und den Datenaustausch vertraglich regelt. Google beispielsweise nach "TCA - Third Party Connection agreement", "IA - Interoperability Agreement" "ISA - Interoperability Security Agreement" "MOA - Memorandum of understanding". auf Deutsch hab ich die Titel jetzt leider nicht da. Contra: - andere Lösungen haben keinen so großen organisatorischen und technischen Impact, wie ein Domänen-Trust - aus einem Trust werden schnell zwei, drei,.., viele Trusts, weil es eben so schön einfach ist. Dann kann es zu Chaos kommen. - schau dir bitte den zweiten Link in meinem obigen Post an, da sind die technischen Impacts beschrieben - die Notwendigkeit bestehender Trust sollte regelmäßig organisatorisch überprüft werden. Dass du dir bei Arbeiten an der Infrastruktur als Administrator bei Bedarf Unterstützung holst, bzw. dich vorher ausreichend schlau machst, davon gehe selbstverständlich aus. Systemhäuser werden dir vermutlich die Lösung mit dem höchsten Stundenaufwand ans Herz legen. Ich würde zumindest nach deiner Beschreibung der Aufgabe versuchen, eine einfachere Alternative als einen Domänen-Trust zu finden. blub

Jungs, ich lass euch antworten, so wie ihr wollt und ihr lasst mich antworten, so wie ich meine, dass es dem To hilft. Danke für Euer Verständnis!

Einen Trust zwischen 2 Domänen technisch einzurichten ist total easy. https://technet.microsoft.com/en-us/library/cc816837(v=ws.10).aspx Dafür brauchst du sicher keine externe Unterstützung. Viel kaputt kann man auch nicht. Wenn der Trust nicht funktioniert, dann löschst du einfach alles und fängst von vorne an. Aber betrachte die Security! Trust bedeutet vollständiges Vertrauen. Fällt die andere Domäne, oder ist euch ein Admin aus der anderen Domäne plötzlich nicht mehr wohlgesonnen, dann habt ihr ein Problem, ebenso umgekehrt. https://technet.microsoft.com/en-us/library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff1 Daher: wenn sich der Trust vermeiden lässt, dann vermeide ihn. Webserver etc. asl Alternative wurden schon genannt. blub

http://www.oldenbourg-klick.de/zeitschriften/grundschulunterricht-deutsch/2013-1/aussagesaetze-fragesaetze-ausrufesaetze (sorry, dass sich dieser Link nicht auf den eigentlichen Topic bezieht)

Hallo Chris, eine "System.NullReferenceException" würde ich als Fehler im Code der Cobra-software ansehen. Prüfe nochmal, ob alle im Handbuch genannten Installationsvoraussetzungen erfüllt sind: z.b. - Betriebssystemversion (z.B. Windows Server 2012R2) - Sprache (Deutsch, English) - .Net Framework Version (z.B. 4.0 oder höher) see: https://support.microsoft.com/de-de/kb/318785 - evtl. Office Version (z.B. min Office 2010) - VIsual Studio Tools für Office Runtime sind evtl. erforderlich see: https://msdn.microsoft.com/de-de/library/ms178739.aspx - Installation für alle, oder nur für den angemeldeten Benutzer ist unterstützt Wenn alles passt, dann versuche einen Deal mit dem Hersteller: Wenn der Supporter cobra auf deinem System installieren kann, dann zahlst du den vorher festgelegten Preis. Falls dies nicht gelingt, bzw. z.B. erst ein Update der Installationssourcen erforderlich ist, dann zahlst du nichts. Dieses Vorgehen ist nicht unüblich. Auf einem Server würde ich dem RemoteSupport nur Zuschauer-Rechte geben, klicken und ausführen tust du selbst. blub

https://www.us-cert.gov/sites/default/files/publications/JAR_16-20296.pdf Ob die Russen wirklich so böse und die Amerikaner immer die Guten sind, kann dieses Paper auch nicht wirklich belastbar belegen. Aber inhaltlich gut und lesenswert ist der Artikel ab Seite 6 "Recommended Mitigations", besonders wenn man die Security-Maßnahmen in seinem eigenen Unternehmen mal hinterfragen möchte, m.E. auf jeden Fall.

Hi, PKI bzw. das Brian Komar Buch als Einstieg? Ich kann mir nicht vorstellen, dass das sinnvoll ist bzw. dir -nur mit EndanwenderErfahrung- zum jetzigen Zeitpunkt dich weiter bringt. PKI in der Tiefe würde ich an deiner Stelle ein oder zwei Jahre nach hinten schieben. Powershell könnte gut für dich passen. Da hast du schon nach kurzer Zeit Erfolgserlebnisse, die du wahrscheinlich auch in dein Team einbringen kannst. Einen kompletten MCSA-Kurs for free (neben vielen weiteren Kursen) findest du z.B. hier. https://www.cybrary.it/course/mcsa/ (Prüfung muss ja nicht sein!) blub

Wichtig ist der Wert, der mit den einzelnen Passwörtern geschützt wird. Bei hochwertigen Assets sollte man die Passwörter regelmäßig in kürzeren Abständen ändern, als bei vielleicht weniger wichtigen Assets. Aber geändert werden sollten Passwörter regelmäßig. Das hat absolut nichts mit Lust oder Unlust des Administrators zu tun, genauso wenig ob ein Administrator Lust oder Unlust hat seine Systeme zu patchen, etc. Bei ganz wichtigen Passwörtern, z.B. "Built-In DomainAdministrator", "das zentrale KeepassPasswort" würde ich kein Drittherstellertool ranlassen.

Bei den Passwörtern hört sich dein Prozess nicht gut an. Alle Passwörter (mit ganz wenigen Ausnahmen) sollten immer alle 30 bis 90 Tage geändert werden. Beim Weggang eines Kollegen fällt dieser Zyklus halt mal kürzer aus.

https://www.bundesnetzagentur.de/DE/Service-Funktionen/ElektronischeVertrauensdienste/QES/WelcheAufgabenhatdieBundesnetzagentur/AufsichtundAkkreditierungvonAnbietern/ZertifizierungsDiensteAnbietr_node.html Früher konnte man sich ein qualifiziertes Zertifikat bei seiner Sparkasse holen, aber der DSV zieht sich lt. der Seite offenbar aus dem Geschäft zurück.

Den richtigen Dienstleister zu finden und zu steuern, ist keine zu unterschätzende Aufgabe. Die Kollegen machen gerne nur das, worauf sie gerade Bock haben und die Stunden für den eigentlichen Scope sind schnell aufgebraucht.

Mich hat heute ein indischer Prinz angeschrieben, dass er mir unbedingt 40 Mio Dollar überweisen möchte. Sobald ich das Geld habe, werde ich leider nur noch wenig Zeit für die IT bzw. das Board haben! Wetten! :)

Wenn du in dieser Richtung tätig werden willst, dann besorg dir -nachdem du die ersten Wochen hinter dich gebracht hast- die ISO 27015 für ein paar Euro. In kritischen Umgebungen muss man sich an Standards wie z.B. die ISO 27000-er Serie halten und sollte nicht versuchen, das Rad neu zu erfinden. z.B. http://blog.fc-heidelberg.de/2014/01/23/der-neue-it-sicherheitsstandard-iso-27015-fuer-kreditinstitute/ "etwas gesetzeskonformer" sollte nicht das Ziel sein, sondern die vollständige Erfüllung der "Legal Compliance" blub

Kannst du mal mit LDP die Bindung versuchen https://technet.microsoft.com/de-de/library/cc754970(v=ws.11).aspx Dann siehst du schonmal, ob die Infrastruktur funktioniert, oder es an der Syntax liegt. PHP kenne ich leider nicht besonders gut.

Deine Beschreibung ist nicht untypisch für Malware. Zumindest dieser Punkt erleichtert es Malware von PC zu PC über zu springen, da Malware lokale PWs auslesen kann, vor allem im Admin-Kontext. Daher hilft es nichts nur einzelne PCs neu zu installieren. Schutzmaßnahmen wie aktuelle Patches, verschiedene und starke Adminpasswörter, Virenschutz, etc. helfen nur, wenn sie vor der Malwareattacke eingeführt werden, nicht hinterher. Profilprobleme kommen schon mal vor, aber sind selten. Probleme mit Patches kommen vor, diese sind dann aber innerhalb von Stunden im Netz bekannt. Da wärst du bestimmt nicht der einzige hier im Board mit diesem Verhalten! Mein Vorschlag: - ändert in der Domäne als Erstes eure AdminPWs, dann die Useraccounts - trennt strengstens die Accounts für die Domain Administration und die Client Administration. Nur für wenige Aufgaben braucht man wirklich "domain administrator" Rechte - gebt jedem Client ein anderes AdministratorPW. Reduziert die Mitglieder in der lokalen Administratorgruppe soweit wie möglich Selbst wenn sich letztlich ein anderer Grund herausstellt, diese Maßnahmen sind immer sinnvoll! blub

- sind die Rechner stets aktuell gepatcht? - sind die User nicht in den Gruppe der lokalen Administratoren? - haben die lokalen Administrator-Kennungen auf jeder Maschine unterschiedliche PWs? - auf den Win7-Maschine melden sich nicht mit ihrer DomainAdmin-Kennung lokal an (auch nicht mit RDP)? Irgendwo ein Nein?

Klassifiziere die Daten, bzw. lasse sie von den Datenownern classifizieren. 1. Confidential 2. Private 3. Sensitive 4. Public 1. - Daten würde ich nicht in die Cloud stecken. 2,3. - Daten. kommt u.a. darauf an, wie sehr ihr dem Cloudanbieter vertraut. Azure ist Microsoft, da kann man wohl vertrauen. 4. -Daten, dafür ist die Cloud ideal Ein DC besitzt bekanntlich sämtliche Passwörter von Usern und Computern, also mindestens "Private" Aber oft/ meist ist der finanzielle Aspekt wichtiger, als die die Security. Dann siegt die Cloud von 1. bis 4.

z.b. verschiedene PolicySets @Nils: "Operating-System" bzw. "Operating-System-Version" https://msdn.microsoft.com/en-us/library/ms680987(v=vs.85).aspx

gschwend schwäbisch

Bevor der Schreibvorgang erfolgt, baust du sowas in dein Script ein if ($now - file.lastmodifieddate) > 10mins write2logfile "$now waren es mehr als 10 Minuten" end if

hast du einen Client (idealerweise Win10) in der Domäne, auf dem du die AD-Verwaltungstools installieren kannst? AD-Administration direkt am DC ist sowieso suboptimal, auch wenn es natürlich funktionieren muss.

Ich hätte ja in das Dokument geschrieben: "Drücken Sie jaaa nicht auf den roten Button! Auf gar keinen Fall! Auch wenn Ihre IT Sie dazu auffordern sollte!"

Dahinter steckt eine wachstums- und gewinnorientierte, durchorganisierte Mafia. - Einer ist der Pate - Einer schreibt den MalwareCode. Der Programmierer heute scheint derselbe zu sein, von dem auch der Code zu früheren Ransom-Angriffen stammt. - Einer guckt die Opfer aus und erstellt das Anschreiben - Einer kümmert sich um den Zahlungseingang etc. Beim nächsten Mal werden die Angriffe wieder besser sein. "Lessons learnt".

Ich bin nicht in dem Thema bei uns drinnen. Es kommen aber auch viele Bewerbermails mit Links auf DropBox etc. an, wo dann wiederum die verseuchten Files liegen und auf Download und Ausführung warten.