MMPC = Mehr zum Thema Sicherheit Thursday, August 16, 2007 10:25 PM Toni Pohl Es gibt Themen, da können IT-Pros gar nicht gut genug informiert werden. Dazu gehört zweifelsohne das Thema Sicherheit. Oft wissen IT-Abteilungen erst nach Attacken, Hacks und Missbrauch, wie sie auf solche Vorfälle reagieren können und versuchen nachher, Löcher zu stopfen und ihre Infrastruktur sicherer zu machen. Genau diesem Thema nimmt sich Microsoft mit einem neuen Online-Werkzeug an: Microsoft Malware Protection Center (MMPC). Das MMPC ist ein Web-Portal, welches über "Threat Research and Response" (also Bedrohung, Analyse und Reaktion) informiert und es sich zum Ziel macht, die eigene IT vorher zu überprüfen, und Schwachstellen und Störungen zu minimieren. Das Portal zeigt die aktuellsten und häufigsten Bedrohungen in den verschiedenen Bereichen wie Desktop, E-Mail, Adware/Spyware. Ein durchsuchbares Lexikon liefert Informationen über Viren und Exploits. So bringt die Suche nach "pdf attachment" über das derzeit recht aktuelle Spaming mit PDF-Dateien 434 Ergebnisse und auch brauchbare Hinweise, wie die Schädlinge in den einzelnen Antivirus-Programmen heißen, beispielsweise: Win32/BagzWORM_BAGZ.GEN (Trend Micro) W32/Bagz.gen@MM (McAfee) W32.Bagz@mm (Symantec) Vom MMPC können auch die aktuellsten Updates (Latest Definition Updates) für Windows Defender und Microsoft Forefront Client Security downgeloadet werden. Im Tools-Bereich sind Programme verlinkt sowie Links zu Security-Blogs: Vom kostenlosen Windows Defender bis hin zum umfassenden Schutz mit Microsoft Forefront. Es können auch verdächtige oder infizierte Files (bis 10MB) an Microsoft zur Untersuchung gesendet werden - nun kann man Viren an Microsoft schicken! :-) Das Portal präsentiert sich zeitgemäß und funktionell. Ein Link führt direkt zum Microsoft Security Intelligence Report (der Report Juli bis Dezember 2006 ist übrigens wirklich interessant und hier ladbar). Unsere Kollegen vom Ready Blog Austria haben auch bereits Ende Juli in ihrem Beitrag über MMPC berichtet, aber man kann Security ja bekanntlich gar nicht oft genug an den Mann bringen! Tipp: Melden Sie sich gleich für den monatlichen Security Newsletter an! Der Newsletter enthält Security Bulletins, Update-Infos, Webcasts-Links und vieles mehr zum Thema Sicherheit. Den letzten Newsletter können Sie übrigens hier online ansehen. MMPC ist ein guter Start, sich intensiver mit dem Thema Sicherheit in Ihrer IT-Infrstruktur zu befassen und bietet dazu eine Fülle an Links und Informationen. Auf Ihre sichere IT! Beitrag von Toni Pohl Microsoft | Security | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
HowTo Script in PowerShell Wednesday, August 8, 2007 1:40 AM Toni Pohl Langsam wird die neue PowerShell immer populärer. Im Windows Server 2008 ist die PowerShell bereits in der Evaluation Version inkludiert. Für alle anderen Windows Betriebssysteme muss die PowerShell 1.0 heruntergeladen und installiert werden (Voraussetzung ist nur das Vorhandensein des .NET Framework 2.0). Seit Ende Jänner ist die finale Version verfügbar, nun gibt es seit dem 31. Juli für die Benutzer der MUI Versionen von Windows XP und Windows Server 2003 eine PowerShell Version für x86, x64 und Server IA64 hier zu laden. (Hinweis: Die MUI Language Packs laufen nur unter den MUI Versionen von Windows. Zuerst muss die englische Version der PowerShell 1.0 installiert werden und danach das Language Pack for Windows PowerShell 1.0.) Die PowerShell arbeitet vollständig objektorientiert. Wie bei anderen Shells gibt es eine Pipeline, in der Ergebnisse von Befehlen an andere Kommandos weitergegeben und weiterverarbeitet werden können. Für alle jene, die sich die PowerShell noch nicht angesehen haben und einmal selbst drauflosprobieren wollen hier eine Quick-Start-Anleitung für das schnelle Erfolgserlebnis. Nach dem Download erfolgt die Installation zügig: Der Aufruf der PowerShell erfolgt einfach über den Pearl-Button und Aufruf der PowerShell (C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe): Und schon geht´s los mit einfachen Kommandos: get-process Die PowerShell besitzt vielleicht den Charme der Eingabeaufforderung, bietet unter der Haube aber ein völlig neues Konzept der Administration von Windows-Rechnern und eine neue, zusätzliche Plattform der Automation. Beim Aufruf von Scripts lauert ein Stolperstein: Das gewohnte Ausführen von Scripts mit der Erweiterung .ps1 öffnet bei Ausführung das Script im Notepad und startet nicht (wie vielleicht von Windows Scripting Host gewohnt) das Script! Als Abhilfe hier nun die Schnellanleitung zum Handling und Testen eines einfachen Scripts in der PowerShell: Zuerst wird (außerhalb der PowerShell) ein neues Textfile mit Notepad mit einer Zeile (zur Anzeige der Betriebssystem-Version mit gwmi win32_operatingsystem) erstellt: Das File wird in C:\Script\test1.ps1 gespeichert. Nun, wie wechselt man (in der PowerShell) das Verzeichnis? cd C:\Scriptdir Microsoft hat übrigens auch Altbewährtes - Flashback! ;-) - aus einer anderen Welt übernommen: pwd, chdir, ls, ... Logisch erscheint, nun einfach das Script test1.ps1 aufzurufen... Das klappt aber so noch nicht. Warum? Die PowerShell verwendet eine "excution policy", welche verhindert, dass nicht signierte Scripts aufgerufen werden (versuchen Sie mal Get-ExecutionPolicy um anzusehen welche Policy eingestellt ist oder Get-Help About_Signing). Das bedeutet, wir stellen mal die Policy auf "RemoteSigned" ein: Set-ExecutionPolicy RemoteSigned Neuerlicher Aufruf von test1.ps1... es klappt noch immer nicht. Durch das Ändern der Policy ist es möglich, Scripts aufzurufen. Allerdings - obwohl wir uns im richtigen Verzeichnis befinden - behandelt die PowerShell Pfade anders als gewohnt. Das bedeutet, es muss immer der Pfad zum Script mit angegeben werden: C:\Script\test1.ps1 (oder kürzer mit ".\":) .\test1.ps1 Nun funktioniert der Aufruf! Wenn C:\Script im PATH vorhanden ist, kann die Pfadangabe entfallen. Um den aktuellen PATH auszugeben, verwenden Sie beispielsweise $env:path und zerlegen diesen mit Split(";") nach dem Trennzeichen ";" in einzelne Elemente:$a = $env:path; $a.Split(";") Hinweis: $-Zeichen definieren übrigens Variablen. D.h. $a wird der Environment-Variable zugewiesen und gibt im zweiten Teil die Variable aus. Nachdem es sich um .net Objekte handelt, sind deren Eigenschaften und Methoden (wie hier .Split verwendbar). Dies ist auch die Stärke der PowerShell, dass fast alle .net-Objekte verwendbar und "pipe-able" (weiterverwendbar) sind. Um dem PATH eigene Verzeichnisse hinzuzufügen verwenden Sie:$env:path = $env:path + ";c:\scripts" Achja noch ein Tipp: Bei Script-Aufrufen in Pfaden mit Leerzeichen muss der Pfad - wie gewohnt - in "C:\Mein Script\test1.ps1" eingefasst werden UND dieser "String" mit dem & - Zeichen als Call-Operator aufgerufen werden: & "C:\Mein Script\test1.ps1" Und wie kann man nun ein PowerShell-Script außerhalb der PowerShell aufrufen? Die Lösung ist einfach: Aufrufen der PowerShell mit dem Script (und der optionalen Anweisung -noexit, damit die PowerShell geöffnet bleibt): powershell.exe -noexit c:\script\test1.ps1 Das wars! Mit diesem Handwerkszeug steht die Basis zum Experimentieren mit PowerShell Scripts bereit und die Fülle an bereits verfügbaren Scripts kann getestet und angepasst werden. Das Windows PowerShell Owner's Manual liefert die ersten Informationen zur Verwendung der PowerShell, das Windows PowerShell 1.0 Documentation Pack eine Getting Started-Dokumentation. Zum Einstieg empfehle ich u.a. die Links Scripting with Windows PowerShell im Microsoft Script Center und das Blog des PowerShell Teams sowie den Download des Windows PowerShell Graphical Help File (PowerShell.chm). Es gibt auch bereits eine deutschsprachige community mit einem Angebot an News, Informationen, Blogs und Tutorials. In diesem Sinne wünsche ich viel Spaß beim Entdecken der Fähigkeiten der PowerShell und beim Scripten! Beitrag von Toni Pohl Developer | Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Zwei neue Tools: MSCD (CTP) und Network Monitor 3.1 Tuesday, July 31, 2007 7:51 PM Toni Pohl Sie wollen eine große Datei herunterladen und der Download bricht immer wieder ab? Abhilfe schafft der Microsoft Secure Content Downloader (MSCD) July 2007, welcher als Community Technology Preview (CTP) verfügbar ist. MSCD arbeitet im peer-to-peer Prinzip und lädt Teile des Downloads von anderen Clients und fehlende Teile vom zentralen Server. Damit wird eine wesentlich schnellere Downloadrate erreicht und MSCD kann unterbrochene Downloads fortsetzen. Die CTP ist allerdings nur für 4 Wochen lauffähig, es ist also damit zu rechnen, dass bald die finale Version verfügbar sein wird. Microsoft Network Monitor 3.1 (MN) ist ein Network Protocol Analyzer, welcher Netzwerk-Traffic mitprotokollieren und analysieren kann. Version 3.1 ist ein Update zur Version 3.0 und ersetzt die Versionen 2, ein Word Dokument beschreibt die Fixes. Microsoft Network Monitor 3.1 ist unter Windows Server 2003, Windows Server 2003 x64 Editions, Windows Vista, Windows XP und Windows XP 64-bit lauffähig. Einige Neuerungen der Version 3.1: Unterstützung von Wireless (802.11), RAS-Tracing, Filter mit rechter Maustaste, Update per WU, neue und schnellere Parser-Engines. Ein eigenes Technet-Blog informiert über weitere Fähigkeiten und How-To´s. Beitrag von Martina Grom Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Kill Task per Script Monday, June 18, 2007 10:00 AM Toni Pohl Für administrative Zwecke, zum Beispiel für automatisierte Backups, Scheduled Tasks o.ä. ist es manchmal erforderlich, bestimmte Applikationen per Script zu beenden. Letztlich hatte ich genau so eine Anforderung: Outlook sollte für das Backupen der OST-Datendatei geschlossen werden. Als Lösung wird ein simpler Aufruf von Windows Management Instrumentation (WMI) verwendet, welcher abfragt, ob ein Prozess mit einem bestimmten Namen läuft und diesen terminiert: ' killtask.vbs by TP' simple script for killing a proccess task.pgm = "Outlook.exe" set wmi = getobject("winmgmts:") sQuery = "select * from win32_process " &_ "where name='" & pgm & "'" set processes = wmi.execquery(sQuery) for each process in processes process.terminate next ' decomment for user info:' msgbox pgm & " closed.", vbinformation Öffnen Sie Notepad oder einen ähnlichen Texteditor, kopieren Sie das obige Script hinein, passen Sie den Applikationsnamen an (z.B. Outlook.exe) und speichern Sie das Script "killtask.vbs" ab. Dann einfach Outlook starten und mit Doppelklick ausprobieren! Hinweis: Wenn in der zu schließenden Applikation ungesicherte Dokumente geöffnet sind, sind diese durch das Beenden verloren! D.h. wenn Sie beispielsweise "Winword.exe" mit dem Script beenden und es ist ein neues oder geändertes Dokument offen, wird dieses ohne Sicherheitsabfrage geschlossen und der Inhalt ist verloren. Das war aber auch nicht Zweck dieses Scripts ;-). Interessierte finden in WMI als Bestandteil des Windows Betriebssystems eine riesige Spielwiese für allerlei brauchbare Automatisierungen. Viele interessante Scripts und Informationen finden sich u.a. im Script Center. PS: Ein ganz heißes Nachfolge-Thema für Scripting und Automatismen ist die Microsoft Powershell! Viel Spaß beim Scripten! Beitrag von Toni Pohl Developer | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr