Re: warum PnP Dienst über Netzwerk?

Frank Lindner schrieb:

Nichts anderes habe ich gesagt. Ich würde sogar noch weiter gehen und
Rechner ohne aktuellen Patchlevel nicht in das Netz lassen.


Du hast es für übertrieben gehalten einen lange nicht gepachten Rechner, der
in Betrieb war, neu zu formatieren.

Ja. Das eine schließt das andere doch nicht aus. Rechner, die längere Zeit nicht gepached wurden, müssten zuerst mal auf aktuellen Patchlevel gehoben werden. Virenschutz genauso. Dann kann man, wenn man will, noch verlangen, dass ein Vollscan durchgeführt wird und danach darüber nachdenken, den Client in das Netz zu lassen. Das ist doch um Längen besser als die jetzige Praxis, beliebige Clients direkt im LAN zu erlauben.

Die Lösung ist übrigens, den RDP-Port mit TLS abzusichern. Geht seit
Windows Server 2003 SP1. Dann gehen die Angriffe erst, wenn eine
SSL-Verbindung erfolgreich aufgebaut werden konnte. Diese setzt
Zertifikate voraus und das ist schonmal ziemlich sicher.

zu spät 

Wieso?

Geht das auch durch jeden Proxy?

Nein. RDP over HTTPS ist schon eine Weile im Gespräch - es ist aber noch nicht klar, wann es wo implementieret wird.

Kann ich mir auch selbst Zertifikate ausstellen? 

Ja klar.

OpenVPN kann das alles schon länger und ist universeller.

Aber es erfordert a) eine Installation und Konfiguration am Client und b) vergleichst Du hier Äpfel mit Birnen. Mit OpenVPN ist der Client im Netz - RDP mit SSL schützt das Protokoll an sich gegen MTM-Angriffe. Das sind unterschiedliche Angriffsvektoren.

Es war 3389 gegen 445, nicht 1433, den 1433 halte ich auch für anfällig.

Ich weiß. Du hattest 3389 gegen 445 verglichen, ich mit 1433 gegen 445 gekontert. Darauf bist Du aber nicht eingegangen. Wenn Du mir jetzt noch erklärst, wieso 1433 anfälliger als 3389 Deiner Meinung nach ist, wären wir ein Stück weiter. Meine Aussage war, dass Deine "Wahrscheinlichkeiten" sinnfrei sind. Bei 3389 kann genauso auch eine Lücke wie bei 1433 oder 445 gefunden werden.

1433 nicht im LAN offen haben und ein Einfallstor anbieten. Das ist die
Maßnahme.


Aha. Aber 3389 bietest Du an. Was ist da der Sicherheitsgewinn?

nur noch ein offenen Port 3389 zu den Clients hin zu haben.

Siehe oben: Was gewnnst Du, wennn Du 3389 anstelle von 1433 anbietest? Im RDP-Protokoll kann genauso eine Lücke nicht ausgeschlossen werden, wie beim SQL-Server.

Und wem die Gefahr zu groß ist nimmt noch einen Linux Client für den
RemoteZugriff.

Ich rede die ganze Zeit von Servern und lasse die Clients aussen vor. Wir gehen davon aus, dass die Clients verseucht sein können. Wieso schützt dann die 3389-TS-Lösung die Server mehr? Die Logik verstehe ich nicht.

So kann man sich eine sicherer Umgebung herstellen und trotzdem Windows
Programme benutzen.

Das eine schließt das andere nicht aus. Du kannst eine sichere Umgebung herstellen *und* Windows benutzen.

Lösungen sind immer individuell. Ich behaupte nicht eine Pauschallösung zu
haben.

Das klang vorhin aber anders. Zitat: "Da hilft nur ein Update oder ein Samba Server.", etc.

Ich vertraue der OpenSource von OpenVPN und OpenSSL mehr als der Firma
Microsoft. Das ist aber auch eine Entscheidung.

Also sind wir bei Vertrauen. Damit können wir die Diskussion dann auch beenden. Wenn Du grundsätzlich Microsoft mißtraust und allem , was Open vorneranstellt, vertraust, dann brauchen wir, völlig wertneutral gesehen, nicht weiter über Konzepte diskutieren.

Sei konkret, was sind denn die Kriterien die MS sich da ausgedacht hat. ich
erinnere mich noch an Passwordschutz für Bildschirmschoner.

Lies den Link. Es ist ein Framework, in das sich nahezu beliebige Tests einbauen lassen und das anderen zur Nutzung offen steht. Nur weil es unter Linux nichts vergleichbares gibt, muß nicht alles andere schlecht sein.

Ich hatte doch geschrieben, ein V-Scanner ist ein nichtverläßliches Vehikel
was mitbenutzt wird, wo man sich aber nicht darauf verlassen.
Es dient bei email ähnlich dem Spamfilter zur Entlastung des Postfachs des
Empfängers, nicht aber um sicherzustellen, daß der Empfänger keinen
schädlingsverseuchten emails bekommt. Dazu ist ein Virenscanner nicht
geeignet, siehe Aufstellung. Die Erkennungsrate ist einfach zu schlecht.
Auf einem SambaFile Server dient das scannen auch dazu zu verhindern, daß
sich Schädlinge in den Datenbeständen einnisten, es kann aber nicht die
Schädlingsfreiheit garantieren.

Ich habe auch nicht von "garantieren" gesprochen. Aber bei positivem Ergebnis eines Virenscanners den Rechner nicht in das Netz zu lassen, halte ich für besser, als nichts zu tun. Über Deine VPN-Lösung kann auch ein verseuchter Rechner sich in das Netzwerk einklinken, selbst wenn ein Virenscanner den Virus erkennen würde.

Wenigstens ist Samba OpenSource und unterliegt damit einer ganz anderen
Qualitätskontrolle als closed Source.


Woher weißt Du, wie bei closed source Qualitätskontrolle stattfindet?

Wie läßt sich "Given enough eyeballs, all bugs are shallow" mit den Fragen nach a) Qualität der Augen und b) der wirklichen Anzahl der Programmierer vereinbaren? Es nützt nichts, wenn tausende sich den Sourcecode ansehen, aber von sicherem Code keine Ahnung haben und die wahre Anzahl von aktiven Programmieren eines Opensource-Projekts wird gern überschätzt.

Samba ist neben Apache eines der beliebtesten Projekte, deswegen mag es da Vorteile haben. Trotz der von Dir behaupteten besseren Qualitätskontrolle gibt es aber in den Opensource-Projekten Sicherheitsprobleme, die ja eigentlich gar nicht auftreten dürften. Teilweise auch in sehr altem Code.

Meiner Meinung nach werden mit wachsender Verbreitung Systeme interessanter für einen Angriff. Je interessanter, desto mehr Aufwand wird betrieben, Lücken zu finden und diese auch auszunutzen.

Aber das ist auch eine andere Diskussion. Um den Thread vielleicht abzuschliessen, können wir ja festhalten, dass wie immer viele Wege nach Rom führen und niemand die absolute Wahrheit oder 100%ige Sicherheit gepachtet hat.

--
..:Daniel Melanchthon:.
Technologieberater - Exchange Server
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no rights.
.

Relevant Pages

  • Re: suche Empfehlung =?ISO-8859-15?Q?f=FCr?= Zeitserver
    ... bekommen (solange du immer die selben NTP-Servern befragst), ... Server kann auch so eine "Mini-Appliance" verwendet werden, ... der sich aus dem Netz synchronisiert, und nicht jeden einzelnen Rechner ...
    (de.comp.os.unix.linux.hardware)
  • Re: Rechner im Netzwerk
    ... > habe eben einen Rechner im Netz eingerichtet. ... Laufwerke auf Server sind da. ... mit dem Gateway - er oder was _ist_ denn das Gateway? ...
    (microsoft.public.de.german.win98.allgemein)
  • Geht VPN auf diese Weise???
    ... Jetzt soll ein weiterer externer Rechner hinzukommen, ... Resultate zur Folge Netz A nach Netz B krieg ich hin. ... Und Netz C krieg ich in keiner Richtung verbunden. ... Wenn ich allerdings 'Nen Rechner aus Netz A mit dem Server aus Netz B ...
    (microsoft.public.de.german.windowsxp.networking)
  • PPTP Server Routingprobleme
    ... Hinter einem Gateway habe ich im internen Netzwerk einen ... SSH-Tunneln jeden Rechner ansprechen kann. ... Leider habe ich zu meinem Fall, keine entsprechenden Dokumente im Netz ... In der Firewall sind nur Port 1723 und GRE auf den PPTP Server direkt ...
    (alt.os.linux.suse)
  • Re: WPA unsicher?
    ... Gestern Nacht habe ich dann bemerkt, dass am Router ein 4. ... Rechner via WLAN an meinen ... IP-Adresse zu geben und dann noch auf meine Kosten ins Netz zu gehen und ... WPA mit Preshared Secrets ist Angreifbar, ...
    (de.comp.security.misc)
Loading