Vielen Dank erst mal für Deine Infos. Eine Info von mir ist glaube ich nicht ganz rübergekommen. Der Server steht nicht in einem lokalen Netzwerk, sondern er ist ein richtiger Webserver und steht direkt beim Provider.
Zitat:
Zitat:
1. Hat jemand eine Ahnung, was da genau passiert ist?
Ich denke das jemand deinen
SQL Server entdeckt hat und versucht Zugriff zu bekommen (bzw. das der
SQL-Slammer deinen Server zur Verbreitung nutzen möchte). Schau doch mal mit netstat -a drauf, wer alles eine Verbindung auf Port 1433 herzustellen möchte und ob du die Remote-Hosts kennst ...
Dann kannst du einen Sniffer auf der
SQL-Server-Maschine installieren und mal schauen, wer genau wieviel Traffic auf dem
SQL-Server verursacht. Nachdem du die notwendigen Infos hast kannst du entsprechend reagieren.
Das hab ich mir auch schon so gedacht
Zitat:
Zitat:
2. Gibt es eine einfache Lösung, trotzdem mit einer Client-Anwendung auf den Server zuzugreifen?
Ich greife mal deinen Punkt 4 teilweise mit auf ...
Wenn du nur aus dem LAN auf den
SQL-Server zugreifst, warum ist der Port 1433 dann aus dem Internet erreichbar ?
Konfiguriere deine Firewall so, das dein Server auf Port 1433 von extern nicht erreichbar ist. Falls externe Clients auf dem
SQL-Server arbeiten müssen, dann lass den
SQL-Server wenigstens auf einem anderen Port laufen, so das nicht jeder problemlos weis, das da ein ungeschützter
SQL-Server im Internet hängt. Das ersetzt keine Firewall und kein VPN, aber als erster Schritt es das (als Alternative zu Netzwerkkalel raus) OK.
So weit ich es in Erinnerung habe, hat der Provider keine Firewalls vor den Servern. Ich werde den
TCP/
IP Zugriff erst mal rausnehmen und mir überlegen, ob ich das mit der Client-Anwendung so mache.
Zitat:
Zitat:
3. Macht es eventuell Sinn das ganze über einen anderen Port zu machen?
Wenn der
SQL-Server über das Internet erreichbar sein soll, ohne VPN und ohne das eine Firewall unbekannte externe
IP Adressen blockt, dann ist ein anderer Port schon sinnvoll. Bei einem Portscan kann ein potenzieller Hacker sehen das etwas z.B. an Port 11433 hängt, er weis aber nicht das es ein
SQL-Server ist. Um eine
SQL-Verbindung herstellen zu können, muss er über "CliConfg" erstmal einen Alias mit dem entsprechenden Port einrichten, sonst wird ihn der
SQL-Server nie antworten ...
Angemessene komplexe Kennwörter sind in diesem Fall dennoch wichtig.
Wie gesagt, muss ich mir noch überlegen, ob ich von extern direkt zugreife. Komplexe Kennwörter mache ich immer.
Zitat:
Zitat:
4. Gibt es eine Möglichkeit, das der
SQL-Server nur auf
localhost hört (eventuell in Netzwerkprotokolle von
SQL den
TCP/
IP entfernen)
Konfiguriere deine Firewall so, das dein Server auf dem externen Interface nur bekannten und vertrauten Hosts antwortet.
Falls der
SQL-Server nicht direkt über das Internet erreichbat sein soll, dann blocke alle Anfragen von Extern an den Port 1433 (richtiger... lass sie garnicht erst zu).
Das wird nicht möglich sein, da der Gedanke hinter dieser Sache war, dass Kunden die Client-Anwendung bekommen um einige Daten zu pflegen. Die werden mit Sicherheit wohl eine dynamische
IP-Adresse haben.
Zitat:
Zitat:
5. Sollte man die Win2003 Firewall aktivieren (kann man danach mit Remotedesktop dann noch drauf) und alle nicht benötigten Ports sperren
Pfff . Verstehe ich das jetzt richtig... ? Du hast einen Server der direkt und völlig ungeschützt im Internet hängt ?
Selbst die Remote Desktop Verbindung sollte nur vertrauten Remotehosts erlaubt sein. Dienste die nur von Intern genutzt werden, dürfen von extern nie erreichbar sein.
Optmialer Weise gehört dein Server hinter eine ordentliche Firewall oder zumindest hinter NAT.
Remote-Clients sollten nur über ein VPN und/oder Sicherheitszertifikate Zugriff auf interne Ressourcen bekommen.
Da es ein Webserver ist, der direkt im Internet ist, muss ich ja irgendwie Zugriff bekommen. Ich denke, dass ich die Remote-Desktopverbindung auch an einen anderen Port hänge um auch dort sicher zu sein, dass es etwas schwieriger ist das zu finden. Leider kann man keine eingehende VPN-Verbindung in Windows einrichten.
In Bezug auf den
SQL Server habe ich wohl schon etwas fahrlässig gehandelt, bzw. habe mir auf andere verlassen. Bevor ich die Installation gemacht habe, habe ich mich schon erkundigt, auch hier im Forum und da waren einige Beiträge über direkten
SQL Server Zugriff auf einem Web-Server. Dass ich jedoch solche Probleme mit Traffic bekomme, hätte ich nicht gedacht, wobei ich bis jetzt noch keine Idee habe, wie jemacht sich am
SQL anmelden kann, da ich überall komplexe kennwörter vergeben habe.
Macht es jetzt Sinn, die Windows-Firewall noch zu aktivieren?
Danke
Sven