Folgender Fall: Aus Sicherheitsgründen soll der zugelassene IP-Bereich für den Zugriff auf einen Webserver per RDP mit der Windows-Firewall eingeschränkt werden. Das Problem ist, dass nur die wenigsten Internet-Nutzer über eine eigene feste IP zu Hause verfügen.
Die Lösung: Einrichten einer dynamischen Internet-Adresse per DynDNS und eine automatische Aktualisierung des Eintrags in der Firewall mit einem Batch-Skript, das dann per Cronjob regelmäßig ausgeführt wird. Glücklicherweise werden damit auch nur Windows-Bordmittel benötigt (neben der DynDNS-Adresse). Auch wenn ich hier keine detaillierte Sicherheitsanalyse anbieten kann, bin ich doch überzeugt, dass dieser Ansatz pragmatisch ist und eine höhere Sicherheit gewährleistet als die Unterlassung einer IP-Bereichs-Einschränkung.
Das folgende Skript sieht die Einbindung einer einzelnen festen IP-Adresse vor, für den Fall, dass ein Zugriffsberechtigter über eine solche verfügt. Falls dies nicht der Fall ist, lässt sich dies leicht wieder entfernen.
@echo off
REM --------------- KONFIGURATION ---------------
SET DynAddr=your-name.dyndns.org
SET StaticIP=123.123.123.123
REM ------------- ENDE KONFIGURATION ------------
echo Skript zur Aufloesung der IP der DynDNS-
echo Adresse und Eintragung in die Firewall
echo.
FOR /F "tokens=3 delims= " %%A IN ('nslookup %DynAddr%
↳ ^| findstr "[0-9].[0-9].[0-9].[0-9]"') DO SET
↳ ResolvedIP=%%A
echo IP: %ResolvedIP%
netsh advfirewall firewall set rule name="Remotedesktop
↳ (TCP eingehend)" new remoteip=%StaticIP%/32,
↳ %ResolvedIP%/32
Der Knackpunkt ist das Herumexperimentieren mit dem netsh-Befehl – für mich persönlich war allerdings der lästige Teil die Sache mit der for-Schleife, die an sich nur einen Substring extrahiert. Workarounds, die man erst lange suchen muss, wenn man sonst keine Batch-Skripte schreibt…
Wenn ein Fehler enthalten ist, bitte schreibt mir – ich benutze die paar Zeilen schließlich selbst auch ;-)
Hier nochmal die Datei zum Download: DynDNS_FW_Rewrite.bat [539.00B]
(45 mal heruntergeladen)
ASP.NET ist für mich Neuland. Geschäftlich habe ich mich lange mit der Programmierung unter “Classic” ASP beschäftigt, Skriptsprache JScript, und wer sich damit auskennt, wird verstehen, warum ich sehr begeistert von ASP.NET bin ;-)
Es kostete mich dennoch etwas Einarbeitungszeit, erfolgreich einen Web-Service unter Verwendung einer von diesem Service bereitgestellten WSDL-Datei mit ASP.NET (Skriptsprache C#) unter dem Microsoft-Webserver IIS anzusprechen und nutzen zu können.
Daher dieses kleine Tutorial. Ich werde kurz erklären:
- Was man zum Ansprechen eines Web-Services unter ASP.NET benötigt
- Wie man zum Webservice passende Proxyklassen erzeugt und kompiliert
- Wie man mittels der neu erstellen Proxyklassen auf den Web-Service zugreift
Voraussetzungen
Benötigt werden
- das Microsoft .NET Framework
- das “Microsoft Windows SDK for Windows 7 and .NET Framework” in der zum Framework passenden Version
- ein beliebiger Quelltexteditor
Proxyklassen
Proxyklassen erleichtern den Zugriff auf den Web-Service, indem sie eine objektorientierte Schnittstelle bieten. Praktischerweise gibt es im oben angeführten SDK ein Programm “wsdl.exe”, das diese automatisch generieren kann! Das Took liegt im Bin-Verzeichnis des SDKs, also beispielsweise “C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\wsdl.exe”. Eine genauere Übersicht über die Möglichkeiten von wsdl.exe und das Erstellen von Proxyklassen findet sich im OpenBook von Galileo Press zu ASP.NET.
Ein Beispielaufruf des Tools ist
wsdl /l:cs /n:myWebServiceConsumer /o:proxyklasse.cs http://www.domain.tl/webservice.asmx?WSDL,
wobei /l:cs besagt, dass die Zielsprache C# sein soll. Ebenso denkbar ist z.B. /l:vb für VB.NET; ich finde VB (Visual Basic) aber sehr hässlich ;-). Der Name für die Proxyklasse, unter dem sie später verwendet wird, ist als myWebServiceConsumer angegeben und kann beliebig variiert werden – man sollte ihn sich nur merken. Das Hauptargument ist die URL zur WSDL-Beschreibung des Web-Services.
Das Ergebnis dieses Aufrufes ist die Datei “proxyklasse.cs”, deren Namen unabhängig vom angegebenen Namen (Namespace) der Proxyklasse über den Parameter /o angegeben werden kann.
Nun muss die Proxyklasse nur noch kompiliert werden. Dazu liefert das .NET-Framework den C#-Compiler csc, der bei mir unter “C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe” liegt. Ein möglicher Aufruf ist
csc /t:library /out:myWebServiceConsumer.dll /r:System.dll
/r:System.Xml.dll /r:System.Web.Services.dll proxyklasse.cs
Das Ergebnis ist die DLL-Datei myWebServiceConsumer.dll: Unsere fertig kompilierte Proxyklasse, die wir im nächsten Schritt direkt einbinden können.
Einbindung
Benutzt werden kann die im letzten Schritt erstellte Proxyklasse, indem sie in den bin-Ordner der IIS-Site kopiert wird, in der sie verwendet werden soll. Der Ordner “bin” muss gegebenenfalls neu erstellt werden. Bei einer Standardkonfiguration der Site werden die dort enthaltenen Bibliotheken automatisch geladen. Ich empfehle, die Site über den IIS-Manager neu zu starten, um sicherzugehen, dass die Proxyklasse auch geladen wird.
Die Klasse kann nun in einer aspx-Datei, in der sie benötigt wird, mit der Direktive
<%@ Import Namespace="myWebServiceConsumer" %>
eingebunden werden. Danach kann man objektorientiert auf den Web-Service zugreifen; besitzt dieser bspw. eine Klasse StringPrinter mit der Methode printSomeString(), kann einfach eine neue Instanz angelegt und auf die Methode zugegriffen werden:
StringPrinter sp = new StringPrinter(); sp.printSomeString();
Auskunft darüber, welche Klassen und Methoden der Web-Service und damit die Proxyklasse zur Verfügung stellt, erhält man entweder über die Dokumentation des Web-Services, über den Inhalt der WSDL-Datei (diese liegt im XML-Format vor und kann mit einem Browser gelesen werden) oder über den Quelltext der Proxyklasse selbst, also über die Datei “proxyklasse.cs”.
Fußnoten
Die Idee, das Internet und eine speziell angepasste Software zum Ausführen einer Umfrage im Rahmen z.B. einer Bachelor-Arbeit zu nutzen, ist äußerst reizvoll und interessant. Man
- senkt die Hemmschwelle der Teilnahme an einer Umfrage durch das Wegfallen einer örtlichen Bindung
- vereinfacht die Organisation
- hat die Möglichkeit, die Auswertung der Ergebnisse automatisiert und daher wesentlich performanter zu gestalten.
Das Erstellen einer solchen Umfrage-Software war eines meiner letzten Projekte. Die Umfrage behandelt das Themengebiet “Interkulturelle Kompetenz” und wurde im Rahmen einer Bachelor-Arbeit erstellt. In Zusammenarbeit mit einem anderen Informatik-Studenten der TU Darmstadt wurde ein Java-Applet entworfen, welches den Umfragevorgang sowie die abschließende Datenübertragung komplett automatisiert – die Daten werden im CSV-Format abgelegt, wodurch sie von jedem üblichen Tabellenkalkulationsprogramm verarbeitet werden können.
Programmiertechnisch war eines der Hauptprobleme die Synchronisationsarbeit, die durch die Nutzung von Swing als Oberflächentechnologie betrieben werden musste; ein leidiges Problem. Ein heißer Tipp für Leute, die mit Swing arbeiten möchten und Synchronisationsprobleme haben: Beim Klick auf einen Button einfach einen neuen Thread starten und in diesem mittels SwingUtilities.invokeLater() auf die graphische Oberfläche zugreifen. Eigentlich ganz einfach – und ich hoffe ich habe das letzte Mal Probleme damit gehabt ;-).
Interessieren Sie sich für speziell angepasste Umfragesoftware? Schreiben Sie mir!
