Re: warum PnP Dienst über Netzwerk?

Denis Jedig wrote:

> On Sat, 20 Aug 2005 23:32:18 +0200 Frank Lindner wrote:
>
>>> 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. [...]
>>
>> Der Laptop greift über VPN zu, ob er im Haus ist oder nicht. Warum einen
>> Unterschied machen.
>
> Ich glaube, du hast das Prinzip falsch verstanden.

Das Prinzip lautet KeepItSimple.

Rechner werden nicht erst geprüft, wenn sie mal zufällig im Haus sind
sondern regelmäßig, wenn sie sich über VPN bei der Firma melden.
Es gibt durchaus Szenarien, wo man keinen Unterschied zu machen braucht, ob
der Rechner mal da ist.

>> OpenVPN geht auch über TCP 80 oder TCP 443 und damit in jedem Hotelzimmer
>> dieser Welt.
>
> Außer das Hotelzimmer hat einen Proxy, der NTLM-Authentifizierung will.


NTLM-Authentifizierung geht auch!

Du mußt natürlich auf TCP umstellen, im Prinzip ein anderes Startscript
wählen, z.B. mit TCP 443 zum host.

Es ist schon erheblich ob ein System es schafft mit hoher Wahrscheinlichkeit
eine Verbindung zum Host herzustellen um den Zugriff auf email und andere
Dokumente zu ermöglichen oder ob eine Verbindung eher zufällig ist.



>> Bin dich dann gegen man in the middle geschützt oder muß ich dafür ein
>> Zertifikat kaufen und einem Dritten für eine unternehmensinterne Löung
>> sinnlos vertrauen?
>
> Das "gewöhnliche" Vorgehen ist das Hinzufügen deiner CA zu der Liste der
> vertrauenswürdigen CAs - das funktioniert bei OpenVPN nicht anders.

Die Frage ist:
Kann ich mir mit bei MS-rdp selbst ein unternehmensinternes Zertifikat
ausstellen und bin gegen man in the middle gschützt oder muß ich dazu
zwangsweise und unnötigerweise ein Zertifikat bei Verisign und Konsorten
kaufen?


>> OpenVPN kan man gegen man in the middle konfigurieren
>
> Das braucht man gar nicht, das gibt SSL/TLS ganz von alleine her.

Frage siehe oben? Ist das wirklich so?


>>> Ich weiß. [...] 3389 [...] 445 [...] 1433 [...] 445
>>> [...] 1433 [...] 3389 [...] 3389 [...] 1433 [...] 445
>>
>> Wieviel Sicherheitslücken gab es bei 3389. Die jetzige und eine davor in
>> 2003.
>
> Mit Portnummern zu jonglieren ist absolut sinnfrei - die Angriffsfläche
> ist nicht von der Portnummer abhängig, noch nicht einmal von der Anzahl
> der auf einem System erreichbaren Ports. Gesetzmäßigkeiten vom Typ "mein
> Port 389 haut deinen Port 21 voll weg, ey" abzuleiten, ist eher unsinnig.
> Die statistischen Größen aus den Längsschnitten für die Sicherheit
> beziehen sich *immer* auf die Dienste *stets* über einen festgelegten
> Zeitraum und *nie* auf Faktoren wie Ports.

Der Port steht ja wohl für einen Dienst.


>> Wievel Schädlinge, bei den meisten wohl per email, hast Du in den letzten
>> 12 Monaten bekommen für Angriffe auf
>> Windows-FileServer (139,445) versus Samba Server von einem Windows
>> Client?
>
> Weiterer Aspekt - dass die Angriffsfläche auf 139 und 445 so groß zu sein
> scheint, hängt eben nicht damit zusammen, dass dies beides schwarze
> Pechzahlen sind, sondern vielmehr damit, dass MS-RPC diese benutzt. MS-RPC
> ist bekanntlich ein Multiplexer und stellt die Schnittstelle für zahllose
> Programmkomponenten bereit.

Das mag ein Grund sein, bloß was ändert das an der Bewertung?

> Das diese Programmkomponenten schon architektonisch bedingt nicht auf
> einem Host mit einem völlig anders funktionierenden OS als Windows laufen
> würden, und deshalb nicht auf einem Samba-Server vorhanden sind, bedeutet
> nicht, dass Windows prinzipiell unsicher ist. Es bedeutet schlicht, dass
> ein Windows-Server eine größere Angriffsfläche haben *kann*, weil er mehr
> Funktionalität bereitstellen *kann*.

mag sein, mich interessiert vor allem das Ergebnis.

potentielle Gefährdung durch einen XP-Client für eine Samba-Server mit smb
vs. MS-Filesever?

> Was sehr wohl eine Verfehlung ist, ist die Tatsache, dass man MS-RPC im
> Speziellen und Dienste im Allgemeinen nicht von einzelnen Interfaces
> zwangsentbinden kann und dass die Kontrolle über die über MS-RPC
> bereitgestellten Dienste mehr als dürftig ausfällt.

allerdings, schon der Notwendigkeit, daß auf irgendwelchen vorher nicht
bekannten Ports (für Dienste!) eingehende Verbindungen angenommen werden
müssen ist einfach Technik von vorgestern.



>> Dann schreib doch konkret was für Kriterien da geprüft werden sollen?
>
> Hat er. Du kannst Code auf dem Client ausführen (ja, mal wieder MS-RPC)
> und der Code auf dem Client liefert dir eine Ausgabe, die du mittels Code
> auf dem Server verarbeiten kannst und feststellen kannst, ob sie dir
> gefällt, oder nicht. Die konzeptionellen Probleme sind nicht zu übersehen,
> aber wer es braucht, wird sich darüber freuen.

MS nennt:
- Virenscanner mit aktuellen Signaturen
- Patchlevel
- Passwortschutz bei Bildschirmschoner


Er hat genannt Virenenscanner, woraufhin ich erwiderst habe, daß ein
Kriterium welches nur zu 20 bis 30% zuverlässig ist, ungeeignet als
Entscheidungsgrundlage ist.

An weiteren Kriterien wäre ich durchaus interessiert.

In diese Verfahren sollte man investieren und sich nicht die Frage stelle ob
ein Rechner, der drei Monate keine Patches gesehen hat, aber laufend am
Netz mit einem clickwütigen Benutzer war, nun an das LAN angeschlossen
werden kann oder nicht.

Als Hilfsmittel nimmt man dann einen unzuverlässigen Virenscanner und andere
Kriterien über die man nicht sprechen möchte.

Systematische Schwächen in der Konzeption und in der Umsetzung sollen durch
nachträgliche Prüfungen und Sensoren geheilt werden.
Das ist der falsche Weg.





.

Relevant Pages