Re: warum PnP Dienst über Netzwerk?

Daniel Melanchthon [MSFT] wrote:

> Frank Lindner schrieb:
>
>> Das ist Ansichtssache. Ich halte das Vergessen des einspielen von Patches
>> für eine grobe Fahrlässigkeit. Es kann zeitnah gemacht werden. Der
>> Aufwand ob jetzt oder später ist der gleiche. Das Risiko einer Infektion
>> wird drastisch reduziert, siehe aktuelle Schädlingslage.
>
> 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.

>> Die Gefährdung geht im wesentlichen von Clients aus. Der Server wird sich
>> nicht selbst infizieren.
>
> Genau. Nur wenn Du die Clients nicht verwaltest, sondern "Wegwef-Clients"
> einsetzt, dann ist die Gefahr nicht gebannt.

Das ist noch ein anderes Konzept, das würde jetzt aber zu weit führen.

> 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

Geht das auch durch jeden Proxy? Kann ich mir auch selbst Zertifikate
ausstellen?

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


>> Slammer war im Ergebnis nur ein Problem, wenn man vergessen hatte Patches
>> einzuspielen.
>
> Das ist mit Zotob heute genauso der Fall. Die Frage nach "Suche nach
> Fehlern bei 1433 vs. 445 und Du siehst den Unterschied in der potentiellen
> Gefahr" ist damit aber nicht beantwortet.

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

>> Mögliche Konsequenz Umstellung auf TS, Bindung der SQL Ports an TS.
>
> Wie bindet man denn SQL-Ports an den TS? Da ist mir unklar, wie Du das
> meinst.

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

>> TS und
>> SQL nur noch über Port 3389 ereichbar. xls-Sheets nur noch auf TS mit
>> Zugriff auf SQL-Danbank.
>
> Aha. Und das schüzt wovor?

nur noch ein offenen Port 3389 zu den Clients hin zu haben.
Und wem die Gefahr zu groß ist nimmt noch einen Linux Client für den
RemoteZugriff.
So kann man sich eine sicherer Umgebung herstellen und trotzdem Windows
Programme benutzen.

> Du baust hier eine singulare Lösung, die nur
> für ein Subset der heutigen Anforderungen funktioniert.

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

> Was machst Du mit
> nicht terminalservertauglichen Applikationen?

Das umgedrehte: Windows Rechner ohne email und Daten und per remote dazu auf
einen Linux Rechner oder Linux-TerminalServer arbeiten lassen-


Man kann sich sehr sichere Lösungen bauen, wenn man denn will.

Man mußt nicht nur hoffen, daß MS immer rechtzeitig Patches rausbringt.


>> Das nächste Mal wird MS es vielleicht nicht schaffen Patches rechtzeitig
>> zur Verfügung zu stellen.
>
> Das nächste Mal gibt es vielleicht einen Angriff gegen Samba? Wer weiß das
> schon? Erinnerst Du Dich noch an die phpBB-Wellen, mit denen reihenweise
> Webserver gehijacked wurden? Erinnerst Du Dich noch an die
> Drupal-Schwachstelle, über die die Marketingseite vom Mozilla-Team
> angegriffen wurde?

klar, man muß immer am Ball bleiben.

> Die Lösung heißt imho nicht, Produkt A gegen Produkt B auszutauschen. Wenn
> Produkt B einen bestimmten Verbreitungsgrad erreicht hat, wird es
> interessant und die Sicherheitslücken fangen auch dort an (siehe Firefox,
> siehe phpBB, siehe Linuxkernel, etc.)

Bis dahin hat man einen Vorteil.

> Meines Erachtens ist Netzseparierung der nächste Schritt, um die
> Bedrohungslage zu minimieren. Du hast mit VPN für alle ja auch den
> gleichen Ansatz gewählt - da sind wir thematisch ja beieinander. Ich würde
> halt nicht OpenVPN im LAN einsetzen, sondern eher 802.1X. Das geht heute
> schon betriebssystemübergreifend. Besonders relevante Server werden mit
> IPSec geschützt, das geht vollkommen transparent, ohne dass der User etwas
> machen muß. Netzwerkquarantäne kann heute schon zur Absicherung von RAS-
> und VPN-Clients benutzt werden. NAP mit IPSec dehnt das ganze
> policybasierend auf das LAN aus.

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


> Das heißt, alle Rechner weltweit sind virenverseucht und wir wissen es nur
> einfach nicht, weil die Virenscanner nichts finden. Richtig?

Man kann einen Rechner nicht mit einem Virenscanner die Virenfreiheit
bescheinigen. Mehr habe ich dazu nicht gesagt.

>> Die Maßnahmen müssen
>> vorher geleistet werden und daraus ergibt sich die Einschätzung ob sicher
>> oder unsicher. Das kann man nachträglich nicht mehr auf Sicherheit
>> prüfen.
>
> Ich sag ja gar nicht, dass man sich *nur* auf die Virenscanner verlassen
> soll. Ich sage, dass das ein Kriterium einer Policy unter vielen sein
> kann, die den Netzwerkzugriff regelt.

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


> Aber trotzdem empfiehlst Du pauschal, den Fileserver mit Samba zu
> ersetzen...

Nein, nicht pauschal.



>> Das Warum ist doch egal, Fakt ist, funktioniert nicht zuverlässig.
>
> Den Satz mußt Du Dir mal auf der Zunge zergehen lassen. Es ist also egal,
> wie der Test gemacht wird und warum er in Deinem Szenario fehlschlägt.
> Schuld ist auf jeden Fall der AV-Anbieter?

Genau, es interessiert mich nicht warum Symantec die Eicar Signatur nicht
findet. Das email, bzw. der Anhang war auch nichts exotisches.
Getestet wurde ein Virenscanner auf einem email-Server. Zur Kontrolle wurden
die Testemails an virustotal geschickt.

>> Schau Dir dazu den geposten Test an und lese Werbung dieser Produkte.
>> Beachte auch die Gesetzeslage bzgl. Produkteigenschaften.
>>
>> Bewerten tue ich V-Scanner in der Anwendung als sehr unzuverlässig.
>
> Und was heisst das jetzt? Lieber keine Kontrolle als eine, die nicht
> 100%ig ist? Mir ist eine Quarantäne lieber, die die bekannten Viren
> draussen hält.

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.


>> Andere Softwarehersteller haben seriöse Produktbeschreibungen. Man muß
>> sich an seinen Aussagen messen lassen.
>
> Was Du in diesem Zusammenhang damit meinst, ist mir unklar.

Dann lese Dir Werbung von V-Scanner durch was dort bezüglich der
Produkteigenschaften ausgesagt wird.



>>>Finde ich auch (ohne Sarkasmus). Und das ganze wird als NAP in Longhorn
>>>Server weitergeführt: http://www.microsoft.com/nap
>>
>> Mich interessiert nur was verfügbar ist und was bei anderen längere Zeit
>> funktioniert. beta Test sollen die anderen machen.
>
> Netzwerkquarantäne ist schon verfügbar. 802.1x auch. Und wenn Du keinen
> Beta-Test magst, dann dürftest Du ja auch kein Samba einsetzen 8-)
>
> OK. Das letzte war nicht wirklich ernst gemeint. Dir noch ein schönes
> Wochenende!

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




.

Loading