Kategorie : Arbeit

Über Insider, spezielle Polizisten und KiPo

Hach, die letzten Tage war es hier ziemlich ruhig. Ich war sowohl mit Hardware-, Politik-,als auch den gerade aufgekommenen “Sperrt KiPo im Netz”-Recherchen beschäftigt.

Mein Standpunkt zum letzten Punkt ist klar. Ich vertrat und vertrete die Meinung, dass Sperren (Zensur) nichts bringen und man lieber korrekt, technisch versiert gegen die Betreiber, Verbreiter und Produzenten vorgeht.

Heute kam mitunter eine Meldung auf, dass “möglicherweise” ein “Polizist”, vor oder schon während dieser KiPo-Welle, KiPo als Thema ausnutzte, um andere zu erpressen. Sind halt alle integer und vetrauensfähig und über aller Zweifel erhaben … und diese sollen “unser” Internet filtern dürfen bzw. entscheiden, was gefiltert/zensiert wird?

Ebenso hat Scusi einen Insider-Bericht veröffentlicht – eine anonyme Mail eines Pädophilen der in einschlägigen Kreisen unterwegs ist – welche zwar thematisch und an einigen Stellen aussagekräftig völlig wider meinen Verstand und moralischen Vorstellungen geht, wenn es um die Aussagen der Freiwilligkeit der “Opfer”/Kinder geht, dennoch aber mitunter das Ausmaß des dahinterliegenden, teils kriminellen, Netzes, die angewendete Technik und andere Praktiken, sowohl auf deren, wie auf Seiten der “Wir wollen Kinder schützen”-Fraktion, aufzeigt. Dies mitunter sollte jedem zeigen, was von diesen “Filtern” aka Zensurmethoden, die bei uns angestrengt eingeführt werden sollen, zu halten ist.

Der Text ist sehr lang, also nicht erschrecken und ich empfehle es auch wirklich durchzulesen. Auf die Gesinnung des Schreiberlings und seine Ansichten, darüber,  wie gesagt, gehe ich nicht darauf ein. Ich vertrete diese nicht und distanziere mich davon ausdrücklich.  Es geht im Hintergrund um Botnetze, die Art und Weise, wie die Zahlungen vorgenommen und verschleiert werden, über die Wege der gesicherten Kommunikation der Käufer auf ihre “Ware”. Es geht um die Hintergründe, was KiPo ist, wie sie entstand, über “sexuelle Selbstbestimmung” und über Zukunftsaussichten. Ebenso, und das ist für mich erschreckend, geht es darum, welche Organisationen sich hinter den ganzen Organisationen verbirgt, die sich auserkoren haben, gegen den Missbrauch von Kindern zu agieren.

Es unterliegt mitunter der Informationsfreiheit auch zu wissen, wie und wieso solche Menschen “ticken”. Auch wenn sie in der Gesellschaft geächtet sind. Man kann nur über den Sachverhalt urteilen, wenn man beide Seiten der Medaille zu Wort kommen lässt.

Aufmerksam sollte man nicht nur die Fädenzieher betrachten, sondern auf der anderen Seite, wie die KiPo-Macher weiter vorgehen, um Filter und Zensur zu umgehen – ich lass dieses Zitat aus der Mail unkommentiert stehen, denn jeder nur etwas technisch versierte Mensch weiß, was das für “einfache” Vorgänge  und wie schwer diese überhaupt “filterbar” sind…

Es gibt kommerzielle Angebote wo man keine Kinderpornografie mehr kauft sondern sich eine solche virtuelle Workstation mietet auf der sich ein tolles Geschenk befindet voller Videos und Dateien… Die Verbindung kann ganz ruhig via Windows Remote Desktop oder VNC aufgebaut werden. Zwischen dem Computer des Kunden und des Servers laufen keine Dateien sondern lediglich Tastaturbefehle und Bildschirminhalte – meistens in verschluesselter Form und ohne die geringste Spur zu hinterlassen was man angesehen hat. Da der Bildschirm eines Computers zB. aus Russland auf dem PC in Deutschland angezeigt werden kann, entegeht der Kunde jeglicher Filterung, Zensur oder Ueberwachung durch den deutschen Staat. Tja, und dabei koennen die Vertreiber von Kinderpornos sogar seelenruhig virtuelle Computer verkaufen wozu Visa und Mastercard sicherlich nichts haben wird… Wenn sich dann der Kunde mit dem virtuellen Computer verbindet findet er eine nette Datei die nichts anders ist als ein TrueCrypt Container fuer den er auch das Passwort erhalten hat um es zu oeffnen. Den Container kann er auch seelenruhig auf seinen Computer nach Hause transferieren und da kein Mensch weiss was drin ist, bleibt er einfach nur einen Nutzer wie Millionen andere. Die Russen haben seit ca. 4 Jahren saemtliche Eventualitaeten durchgedacht und fuer Loesungsansaetze gesorgt. Bei denen wird das Geschaeft nicht ausgehen. Aber bei der deutschen Regierung verschwindet das Geld der Steuerzahler und die Wirtschaft fuer unsinnige und teure Systeme.
Falls Sie es immer noch nicht bemerkt haben: Technik ist nicht die Loesung zur Eindaemmung von Kinderpornographie. Keinen Filter, keine Zensur und keine Totalueberwachung kann daran etwas aendern.

Was wäre also die nächste logische Konsequenz? Verschlüsselung verbieten? Jeder der Truecrypt und/oder VPN nutzt ist ein KiPo-Freund?

Ich denke, die Debatte über KiPo ist lange nicht beendet, aber in meinen Augen schon längst bezüglich der gewollten Sperrung von Webseiten, denn spätestens dieses “Geschäftsgebahren” ist nicht auf den Fluss von Daten oder Sperren von Webseiten in der Technik verfolgbar, sondern nur durch Fahndung und Ermittlung mit fähigen Leuten. Denn wenn das stimmen sollte, was der Insider da ausplaudert, dann spielt das BKA und Co. locker Taschenbilliard und muss definitiv mit kreativen und fähigen Leuten und Know How ausgestattet werden, um die Täter aufzuspüren und zu fassen – sofern sie überhaupt die Täter dingfest und etwas gegen KiPo und diese mafiösen Strukturen machen wollen.

Problem durch die Zukunft

Mich ereilte vor Feierabend heut ein dringender Ruf eines Kunden (ältere Generation). Die Anmeldung an seiner Arbeitsstation, welche sich in einer Domäne befindet, war ihm nicht möglich. Über Fehlermeldungen schwieg der Kunde sich aus, dennoch sollte sich jemand unbedingt jetzt sofort und am besten schon vor 5 Minuten dem Problem annehmen.

Da eh fast Feierabend war (Elternzeit) fuhr ich auf dem Weg nach Hause bei dem Kunden vorbei, startete den Rechner und bekam nach versuchter Anmeldung die Meldung, dass auf Grund unterschiedlicher Zeiten zwischen dem Client und dem Server eine Anmeldung nicht möglich sei.

Ich schaute den Kunden an und fragte, ob er die Systemzeit des Rechners geändert hätte. Wie zu erwarten bekam ich die Antwort: “Selbstverständlich nicht!”. Ich startete den Rechner erneut und begab mich ins BIOS und dort zur Abteilung Datum/Uhrzeit und ich erblickte 18.06.2009!

Ich: “Arbeiten Sie gern in der Zukunft?”
Kunde: “Wieso?”

Ich: “Da die Zeit des Rechners auf in 4 Monaten gesetzt ist …” – speicherte die Konfiguration mit korrektem Datum ab und startete den Rechner neu.

Kunde: “Wie passiert denn das?”
Ich: “Was haben Sie denn beim letzten Mal getan?”

Kunde: “Ich habe Termine koordiniert – dazu klicke ich immer rechts unten auf die Uhrzeit und schaue nach, an welchem Wochentag der Termin stattfindet.”
Ich: “Und dann?”

Kunde: “Wenn der Termin bestätigt wird, trage ich ihn in den Kalender in Outlook und schließe danach das Fenster mit ‘OK’.”
Ich: “….”

Ich: “Und hatten Sie rein zufällig gestern einen Termin vereinbart für den 18.06.2009?” 
Kunde: “Ja, wieso?”

Ich: “Weil Sie damit die Systemzeit des Rechner geändert haben …”
Kunde: “…..”

Ich habe ihm dann noch schnell erklärt, wieso diese Art der Methode nicht sonderlich die Beste ist, um Termine abzustimmen und zeigte ihm, dass er auch ruhig den Kalender in Outlook nutzen könne, um herauszufinden, an welchem Tag welcher Wochentag ist. Zusätzlich bekommt er auch die Information, ob er an diesen Tag bereits Termine hat. Somit würde er auch nicht mehr versehentlich die Uhrzeit und das Datum des Rechners ändern.

Der Kunde war fassungslos – über sein unbedarftes Verhalten. Ich beruhigte ihn, da ja nichts passiert wäre. 

Kunde: “Sie sind aber deswegen extra zu uns gekommen … wegen so einen Fehler meinerseits …”
Ich: “Auch das ist mein Job – und wie Sie sehen, können wir auch einige Probleme durch die Zukunft lösen …” ;-)

Ich: “Übrigens – ich wünsche einen schönen Feierabend und selbstverständlich geht diese Runde aufs Haus – versteht sich von selbst …”

Hintergrund: Ursache des Problems liegt in den unterschiedlichen Datumseinstellungen des Servers und des Client innerhalb einer Domäne. Bei Versuch der Anmeldung des Clients am Server wird ein Kerberos Ticket erzeugt. Dies beinhaltet auch, dass ein Zeitunterschied zwischen beiden Systemen nicht mehr als 5 Minuten (laut Erinnerungsstand) betragen darf. Ist dies dennoch der Fall, dann ist das Ticket ungültig und der Nutzer (auch der Domänenadministrator) kann sich nicht anmelden.

Man kann nun sich als lokaler Admin anmelden und das Datum ändern – man kann aber auch, wenn man Zugriff auf das BIOS hat, das Datum im BIOS ändern. Danach sollte eine Anmeldung an der Domäne funktionieren. Wenn nicht, dann sollte man die Einstellung bezüglich Sommer-/Winterzeit beachten (herausnehmen, bzw. setzen). Mir ist es bisher zweimal untergekommen, dass einer der beiden Parteien (Server bzw. Client) den Haken gesetzt hatte, der andere nicht. Somit bestand trotz augenscheinlich gleicher Zeit und Datum eine einstündige Diskrepanz, welche ergo auch dahingehend führt, dass der Server die Anmeldung des Client verweigert.

 

Ade, AD und DNS! Oder etwa doch nicht?

Wenn es nach der gestrigen intensiven Google-Suche meinerseits geht, ist das gestern aufgetretene (berufliche) Problem bei einem Kunden mehr als selten. Informationen hierzu waren spärlich, wenn nicht sogar armseelig. Anscheinend taucht es niemals auf – obwohl es das tut. Was war passiert? Ich versuch es so ausführlich wie möglich, aber bedenkt – ich mach es aus dem Kopf, da ich die Fehlermeldungen nicht mehr vorliegen habe.

Die genauen Hintergründe sind mir selbst verborgen. Anfangs lag der Verdacht auf ein fehlerhaftes Update eines Antiviren-Programmes, welches ich aber nach erster Recherche beim Kunden vor Ort ausschließen konnte. Nach Start des Servers (hier ein MS 2003 Server Standard), war eine Anmeldung nicht möglich, da ein Fehler im Verzeichnisdienst (Active Directory) aufgetreten ist. Um es mit einfachen Worten zu sagen, die Active Directory Informationen waren im Anus.

Im Verzeichnisdienstwiederherstellungsmodus war es mir nicht möglich die ntds.dit-Datei (welche die AD-Informationen beinhaltet) mit den üblichen Tools, wie ntdsutil oder esentutl zu reparieren. Ich hatte an dieser Stelle fast aufgegeben, da eine aktuelle Sicherung nicht vorhanden war. Der Server pfiff eh schon auf dem letzten Loch und die Datensicherung war genauso zuverlässig und glaubwürdig, wie Backsteine in der Luft schweben können.

Die Betonung lag hier auf “aktuelle” Sicherung. Ich hatte noch Zugriff auf eine Sicherung von 2006. Also relativ zeitnah möchte ich anmerken. Aus dieser holte ich im Modus Verzeichnisdienstwiederherstellung die ntds.dit und überschrieb die Originale (nach händischer Sicherung) im Ordner C:\WINDOWS\NTDS. Die Prüfungsmechanismen mittels ntdsutil verliefen fehlerfrei und ich startete den Server durch. Ich konnte mich daraufhin anmelden aber das nächste Problem folgte – der DNS Server. Es handelte sich um eine AD mit integriertem DNS und die rückgesicherte ntds.dit war einfach viel zu alt, sodass der DNS Server dies nicht akzeptierte. Ich konnte den DNS Server nicht konfigurieren oder eine neue Zone erstellen – beides wurde mit einer Meldung in der Art “konnte nicht in Active Directory (null) schreiben”. Ebenso war es mir nicht möglich, mit den mir verständlichen Mitteln den DNS Server zu deinstallieren und blanko zu installieren. Es schlug jeder Eingriff fehl.

Somit konnten auch die Clients keine Namensauflösung mehr machen, geschweige denn sich an der Domäne anmelden. Intern, wie auch extern war der Zugriff auf DNS-Namen nicht möglich. Ein Glück, dass der Kunde mittels HTTP-Proxy surfte. Zumindest war der Server via \\IP-Adresse erreichbar. Eine Konstellation, die dem Kunden “erst einmal ausreichte”. Ich versprach mich darum zu kümmern, denn völlig mich einer Neuinstallation hingeben lag mir fern. Ich recherchierte gestern über 5 Stunden zu Hause und stieß auf den für mich letzten besaglichen Strohhalm.

Heute beim Kunden angekommen, habe ich das auch gleich umgesetzt, Daumen gedrückt, weggesehen und … es lief! Einzig allein die wenigen Arbeitsstationen musste ich aus der “alten” Domäne austreten und in die “neue” Domäne eintreten lassen und alles funktionierte, wie es sollte. Und für alle die, die ungeduldig warten, was ich getan habe, hier eine “Kurzanleitung” am Hauptserver (DC+DNS).

  1. Deinstallation des DNS-Servers (Systemsteuerung->Software->Windowskomponenten hinzufügen/entfernen)
  2. Löschen (vorher sicherheitshalber sichern) der Dateien netlogon.dns und netlogon.dnb (hier unter C:\WINDOWS\SYSTEM32\CONFIG)
  3. Löschen (vorher sichern) des kompletten Ordners DNS (unter C:\WINDOWS\SYSTEM32)
  4. wenn noch nicht vorhanden, die Support Tools von M$ installieren
  5. CMD starten und folgenden Befehl eingeben (vom Support Tools Installationspfad aus): netdom resetpwd /server:SERVERNAME /userd:SERVERNAME\Administrator /passwordd:*
  6. es wird nun nach dem Kennwort gefragt: hier kann einfach das alte Administratorkennwort eingegeben werden
  7. DNS Server installieren (Systemsteuerung->Software->Windowskomponenten hinzufügen/entfernen)
  8. Sicherstellen, dass die oben entfernten Dateien und Ordner wieder erzeugt wurden
  9. CMD starten und netdiag /fix ausführen
  • Restarbeiten (Aus- & Eintritt der Client-PCs in die Domäne)
  • Feierabend machen

Mindestens durch die alte ntds.dit Datei, wenn nicht durch einen Fehler in der DNS Konfiguration oder anderen Ursachen, wurde das Kerberos-Passwort des Administrators zurückgesetzt. Mittels netdom wird dieses “aufgefrischt” und dann sollten in dieser Hinsicht diese Probleme beseitigt sein.

Hoffe es hilft Einem – dem Kunden für sein Geschäft und mir für das “Wissen” auf jeden Fall.

Genaue Fehlerbeschreibung

Zum Glück hatte ich heute nichts Wichtiges vorgenommen, denn ansonsten hätte der Kunde !heute! alt ausgesehen. Um 19.00 Uhr bimmelt mein Telefon, während wir uns gemütlich eine Folge Babylon 5 ansehen. Ein Angestellter des Hotels lässt verlauten, dass ein Rechner, der mitunter wichtig ist (wie alle Rechner), ständig die Netzwerkverbindung trennt und wieder aktiviert und somit ein Arbeiten im Netz, sprich mit über das Netz laufende Betriebsanwendungen, nicht möglich ist. Somit sind die Buchungen, Bestellungen, Reservierungen usw. – sprich der gesamte Hotelablauf nicht möglich.

Auf meine Frage, ob es nur diesen Rechner betrifft, erhalte ich ein definitives “JA”. Das schränkte für mich das Problemfeld auf den Rechner ein – ergo Kabel oder Netzwerkkarte. Ich rückte also von zu Hause in die Firma raus, um Netzwerkkarten und Werkzeug zu holen und hottete dann zum Kunden. Dort angekommen wollte ich gerade mich ans Werk machen, begutachtete schon das Problem (welches sich ohne Vorführeffekt auch mal zeige), als ich noch einmal sicherheitshalber nachfragte, ob das Problem wirklich nur an diesem Rechner auftritt.

Natürlich erhielt ich dann die Aussage, dass sich das Problem auch auf andere Rechner ausgeweitet hätte. Dieses Problembild ist natürlich vollkommen anders und schließt als Erstes ein Problem mit einer Netzwerkkarte eines Rechners aus – Murphy schlägt nicht ohne Weiteres so schlimm zu. Es ging daraufhin in den Keller, denn mir schwante schon Übles. Ich begutachtete die Switche eine Weile und an einem Port fiel mir auf, dass dieser alle paar Minuten komplett dunkel wurde, bis er darauf wieder mit voller Last kommunizierte. Wenige Augenblicke später war die LED des Ports wieder aus und so weiter und so fort.

Ich verfolgte das Kabel, welches auch prompt ins Nirvana verschwand. Die Kabeldokumentation war schlichtweg nicht existent und ich hatte schon den Switch in Verdacht. Ich spielte das Ganze gedanklich, als auch verbal durch und der Angestellte meinte darauf hin, dass oben unter dem Tisch nachträglich auch so ein Switch angeschlossen wurde.

Also wieder hoch und quer durch das Hotel gestiefelt und den “neuen” Switch dort unter die Lupe genommen und siehe da: dieser meinte alle paar Minuten einen Reset durchzuführen, welcher dazu führte, dass die Rechner ihre Verbindung zum Netzwerk verlierten. Klasse Sache! Er war übermäßig heiß und das Problembild und die Begleiterscheinungen passten wie die Faust aufs Auge.

Auf ins Auto, zurück in die Firma und einen passenden Switch gesucht und in Windeseile wieder zurück, angeschlossen und alles funktioniert wieder. Fertig war ich dort kurz vor 22.00 Uhr. Die Hin- und Herfahrten und das “falsche” Suchen des Problems forderten ihre Zeit. Aber wäre die später zugetragene Info, dass alle Rechner in einem Bereich davon betroffen sind, früher gekommen, hätte ich schon vorher einen passenden Switch mitgebracht. Das hätte knappe 50 Minuten Zeit einsparen können. Interessant war dann zu erfahren, dass sie schon knappe 2 Wochen das Problem hatten. Nur kristallisierte sich es in Form von Programmaussetzern, temporären Datenfehlern oder allgemeinen Problemen bei Netzwerkzugriffen.

In diesem Sinne – ein schönes und “arbeitsfreies” Wochenende!

Auflösung: Langsamer Datei-Transfer

Was hab ich mich gestern nicht geärgert, als mehrfach, auf Grund des Reparaturvorganges, welcher im Übrigen erfolgreich verlaufen ist, der Exchange Store hin- und herkopiert wurde und dieser Kopiervorgang jeglichen Wert von Zeit und Raum sprengte. Mich ließ dieses “Problem” nicht sonderlich gut schlafen, vor allem weil mich das doch innerlich ziemlich gewurmt hatte und ich versuchte heute herauszufinden, ob der Server anfängt in die digitalen Abgründe zu wandern, oder aber noch viel schlimmer – ob das Ganze normal ist.

Im Zuge dessen habe ich als Erstes das Ganze Verhalten an unseren eigenen Servern nachgespielt. Dazu nahm ich eine Systemsicherung in Größe von 19GB und kopierte diese auf unterschiedliche Ziele – auf ein UNC-Pfad, USB-Platte und ein physikalisch getrenntes Plattensystem. Bei all diesen Vorgängen konnte ich eines beobachten: nach 2GB übertragenen Daten sauste die Transferrate massiv in den Keller, um wenige Sekunden später wieder auf fast volle Leistung zu steigen. Das Erscheinungsbild war also ähnlich, nur nicht mit derart langen “Blockaden”, wie beim Servereinsatz gestern.

Selbst auf dem Kundenserver habe ich das Ganze heute noch einmal laufen lassen. Nein, nicht den Reparaturprozess – ich bin doch nicht verrückt. Zur Verwunderung verliefen diese “Blockaden” relativ kurz. Es schien nahezu ähnlich schnell (schnell ist hier dehnbar), wie bei unserem Firmenserver. Was passiert hier also? Weiter lesen …

Erfahrungsbericht: Exchange Server 2003 Fehler

exchange-447e.jpg Fehler im System mag keiner. Wenn ein Programm abstürzt ist es zwar ärgerlich, aber im großen Teil sind keine Daten betroffen. Anders verhält es sich mit einem Fehler beim Exchange Server 2003 von Microsoft. Bei einem Kunden wird seit den Feiertagen der Fehler 447 (Event ID 447 in ESE) in nicht ganz sporadischen – ich würde sagen im Millisekundentakt – Schritten ins Ereignisprotokoll geworfen. Dieses ist seitdem auf eine beachtliche Größe gewachsen voll von 447er Einträgen. Lustig anzusehen, wenn es lustig wäre.

Im Exchange Store hat sich irgendwo in den Datenobjekten mindestens ein Fehler versteckt und den galt es operativ, am Besten ohne Zange, Skalpell und Schlüpfer zu entfernen. Microsoft macht es sich an dieser Stelle sehr leicht und empfiehlt eine Datensicherung vor dem ersten Fehlereintrag einzuspielen. Ganz großes Kino an dieser Stelle, denn das erste Auftreten des Ereignisses war vor den großen Feiertagen, genannt Weihnachten. Ergo wären alle eingegangenen und versendeten Mails futsch. Das ist natürlich nicht im Sinne und Interesse des Kunden, welcher uns auch prompt mit der Reparatur beauftragte. Lieber 10 Mails weg, als 100 oder gar 1000.

Der Fehler 447 verursachte nämlich eine verzögerte oder gar keine Zustellung von externen Mails in den Exchange Store. Diese blieben in der Empfangswarteschlange einfach stecken und frohlockten mit der Meldung “Verzögerte Zustellung”. Genau das Richtige zu Weihnachten. Wenns klemmt bei der Post, dann verzögert sich das auch bei denen.

Weiter lesen …