6
Fehlender Internetverbindung verlangsamt UAC
Hallöchen zusammen,
nachdem ich nach Online-Recherche nix dazu gefunden habe, wollte ich mal hier nachhorchen, ob ihr mir weiterhelfen könnt.
Im Prinzip ist das Problem einfach beschrieben (steht auch schon im Titel).
UAC ist per GPO aktiviert.
Nach einem Netzumbau in verschiedene Tiers, aus denen die meisten Server keinen Zugriff mehr aufs Internet bekommen, ist folgendes Problem aufgetreten:
Wenn ein Gerät keinen Internetzugriff hat, verzögert sich bei der UAC (z.B. beim "Als Administrator ausführen" oder beim Konfigurieren der Netzwerkeinstellungen) die Dauer, bis das Fenster auch mal angezeigt wird. Gebe ich den Zugriff aufs WAN wieder frei öffnet sich das Fenster nahezu direkt.
Was ist denn da bitte los? Windows kann doch nicht für jeden UAC-Aufruf nach Hause telefonieren wollen.
Danke schonmal für eure Antworten!
Viele Grüße
Ketanest
nachdem ich nach Online-Recherche nix dazu gefunden habe, wollte ich mal hier nachhorchen, ob ihr mir weiterhelfen könnt.
Im Prinzip ist das Problem einfach beschrieben (steht auch schon im Titel).
UAC ist per GPO aktiviert.
Nach einem Netzumbau in verschiedene Tiers, aus denen die meisten Server keinen Zugriff mehr aufs Internet bekommen, ist folgendes Problem aufgetreten:
Wenn ein Gerät keinen Internetzugriff hat, verzögert sich bei der UAC (z.B. beim "Als Administrator ausführen" oder beim Konfigurieren der Netzwerkeinstellungen) die Dauer, bis das Fenster auch mal angezeigt wird. Gebe ich den Zugriff aufs WAN wieder frei öffnet sich das Fenster nahezu direkt.
Was ist denn da bitte los? Windows kann doch nicht für jeden UAC-Aufruf nach Hause telefonieren wollen.
Danke schonmal für eure Antworten!
Viele Grüße
Ketanest
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 9431747007
Url: https://administrator.de/contentid/9431747007
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
6 Kommentare
Neuester Kommentar
Moin Moin,
Windows möchte dafür "nach Hause telefonieren".
Solche Probleme habe ich meist "quick and dirty" gelöst, in dem ich mir auf den Servern einen lokalen User mit Adminrechten angelegt habe.
Windows möchte dafür "nach Hause telefonieren".
Solche Probleme habe ich meist "quick and dirty" gelöst, in dem ich mir auf den Servern einen lokalen User mit Adminrechten angelegt habe.
Hast du die Firewall auf "drop" gestellt? Dann wartet Windows, ob eine Antwort kommt, bis zu einem gewissen Timeout.
Versuchs mal mit: deny
Dann bekommt Windows "sofort" eine Antwort von der Firewall.
Versuchs mal mit: deny
Dann bekommt Windows "sofort" eine Antwort von der Firewall.
Danke schonmal für die Antworten!
Als Info noch (hatte ich vergessen): Die Server laufen auf Windows Server 2022, 2019 und 2016, die Clients auf Win 10 und 11, passiert überall gleich.
Weiß jemand warum? Außer jetzt "Überwachung weil wirs geil finden und Daten sammeln wollen".
Das passiert leider genauso auch mit einem lokaler Admin-User.
Die default deny Regel der Firewall (OPNsense) steht meines Wissens nach auf Drop, ja. Mit einer Reject-Regel ist es zumindest ein wenig verkürzt, man muss aber immer noch etwas warten. Sollte aber doch eigentlich auch nicht Sinn der Sache sein, defaultmäßig zu rejecten statt zu droppen, oder?
Sollte es keine andere Möglichkeit geben und da wir mit der Tiering-Struktur jetzt n Haufen Netze haben werd ichs wohl dann mit einer Last-Matching Floating Rule machen.
Grüße
Ketanest
Als Info noch (hatte ich vergessen): Die Server laufen auf Windows Server 2022, 2019 und 2016, die Clients auf Win 10 und 11, passiert überall gleich.
Weiß jemand warum? Außer jetzt "Überwachung weil wirs geil finden und Daten sammeln wollen".
Solche Probleme habe ich meist "quick and dirty" gelöst, in dem ich mir auf den Servern einen lokalen User mit Adminrechten angelegt habe.
Das passiert leider genauso auch mit einem lokaler Admin-User.
Zitat von @NordicMike:
Hast du die Firewall auf "drop" gestellt? Dann wartet Windows, ob eine Antwort kommt, bis zu einem gewissen Timeout.
Versuchs mal mit: deny
Dann bekommt Windows "sofort" eine Antwort von der Firewall.
Hast du die Firewall auf "drop" gestellt? Dann wartet Windows, ob eine Antwort kommt, bis zu einem gewissen Timeout.
Versuchs mal mit: deny
Dann bekommt Windows "sofort" eine Antwort von der Firewall.
Die default deny Regel der Firewall (OPNsense) steht meines Wissens nach auf Drop, ja. Mit einer Reject-Regel ist es zumindest ein wenig verkürzt, man muss aber immer noch etwas warten. Sollte aber doch eigentlich auch nicht Sinn der Sache sein, defaultmäßig zu rejecten statt zu droppen, oder?
Sollte es keine andere Möglichkeit geben und da wir mit der Tiering-Struktur jetzt n Haufen Netze haben werd ichs wohl dann mit einer Last-Matching Floating Rule machen.
Grüße
Ketanest
Sollte aber doch eigentlich auch nicht Sinn der Sache sein, defaultmäßig zu rejecten statt zu droppen, oder?
Der Sinn des Drops ist einem Angreifer nicht zu zeigen, dass das Ziel überhaupt existiert. Er schießt ins leere und bekommt keine Antwort. Bei einem Reject weiss er dann, dass da was ist und er kann weiter bohren.Der Drop macht auch Sinn und du kannst es auch auf Drop lassen. Nur bei den Microsoft IPs gibt es diesem Angreifer nicht, der sowas wissen will, also kannst du noch über der Default Drop Regel noch eine weitere Reject Regel nur für die Microsoft IPs machen.
Mit der Frage nach warum ein OS nach Hause telefoniert kämpfst du vermutlich gegen Windmühlen. Das macht mittlerweile jedes OS. Vermutlich sucht es automatisch eine MDM oder Azure Online Erlaubnis. Quasi als Zero-Config.
Der Sinn des Drops ist einem Angreifer nicht zu zeigen, dass das Ziel überhaupt existiert. Er schießt ins leere und bekommt keine Antwort. Bei einem Reject weiss er dann, dass da was ist und er kann weiter bohren.
Ja das stimmt auch wieder. Ist mir bei meinen Überlegungen auch gekommen, dann soll doch der Server wissen, dass er nicht darf. Mein Server is ja kein Angreifer haha (bestenfalls jedenfalls).Der Drop macht auch Sinn und du kannst es auch auf Drop lassen. Nur bei den Microsoft IPs gibt es diesem Angreifer nicht, der sowas wissen will, also kannst du noch über der Default Drop Regel noch eine weitere Reject Regel nur für die Microsoft IPs machen.
Es gibt auf Github n Projekt, dass automatisch über alle möglichen Wege IP-Ranges zusammenbastelt in txt-Files, die man super mit der OPN verarbeiten kann. Das werd ich wohl für die MS-IPs nutzen.Mit der Frage nach warum ein OS nach Hause telefoniert kämpfst du vermutlich gegen Windmühlen. Das macht mittlerweile jedes OS. Vermutlich sucht es automatisch eine MDM oder Azure Online Erlaubnis. Quasi als Zero-Config.
Ja das hab ich mir auch schon gedacht... leider.Naja gut, dann vielen Dank für die Antworten, ich denk, jetzt hab ich einen gangbaren Weg!
Ketanest
Moin,
Liebe Grüße
Erik
Zitat von @NordicMike:
Genau anders herum wird ein Schuh draus. Ein Zitat von Lutz Donnerhacke:Sollte aber doch eigentlich auch nicht Sinn der Sache sein, defaultmäßig zu rejecten statt zu droppen, oder?
Der Sinn des Drops ist einem Angreifer nicht zu zeigen, dass das Ziel überhaupt existiert. Er schießt ins leere und bekommt keine Antwort. Bei einem Reject weiss er dann, dass da was ist und er kann weiter bohren.Ist REJECT oder DENY sinnvoller?
Als REJECT bezeichnet man die aktive Ablehnung einer Verbindungsanfrage mit einem ICMP Paket vom Inhalt "Der Admin hat's verboten" oder "Dienst nicht verfügbar".
Als DENY bezeichnet man das kommentarlose Wegwerfen der Verbindungsanfrage. Damit läuft der Anfragende in einen Timeout.
Admins, die sich über Script Kiddies ärgern, glauben oft, diese durch DENY aufhalten zu können. Dies ist jedoch falsch. Es ist problemlos möglich, viele tausend Scans gleichzeitig zu starten und so auf alle Timeout gleichzeitig zu warten. Ein Scanner wird so nicht gebremst. Andererseits bremst man mit DENY alle legitimen Nutzer und Server massiv aus. Das betrifft insbesondere die ident Anfragen.
Ident dient dazu, dem Admin eines ordentlich gepflegten Systems eine Hilfestellung bei der Identifizierung seiner, sich daneben benehmenden Nutzer zu geben. DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen Servern nicht mehr aufgezeichnet werden. Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst, nimm DENY.
Sieh das Ganze doch so, wie in einer offenen Beziehung:
Es ist besser seinem Partner direkt zu sagen, daß man über ein bestimmtes Thema nicht sprechen möchte (REJECT): Der Partner weiß sofort, was Sache ist und und kann dann ohne Zeitverzögerung seine Entscheidung darüber treffen, ob er die Beziehung fortsetzen möchte oder nicht.
Geht man auf ein Thema allerdings gar nicht ein (DENY) und stellt die Ohren auf Durchzug, kostet das a) einem selber Zeit dem Geschwafel des Partners zuzuhören und b) dem Partner ebenfalls Zeit; er möchte nämlich ein für ihn wichtiges Thema/Problem loswerden, und hätte das dann ja wohl besser woanders getan.
Ein anderes Beispiel aus dem Leben:
Du gehst durch die Einkaufstraße deiner Stadt, und irgendein "Penner" quatscht dich an, und will 'nen Euro. Hier könnte man sagen "Ach ne, habe selbst kein Geld" (REJECT) oder einfach die fortgesetzte Bettelei ertragen.
http://altlasten.lutz.donnerhacke.de/mitarb/lutz/usenet/Firewall.html#D ...Als REJECT bezeichnet man die aktive Ablehnung einer Verbindungsanfrage mit einem ICMP Paket vom Inhalt "Der Admin hat's verboten" oder "Dienst nicht verfügbar".
Als DENY bezeichnet man das kommentarlose Wegwerfen der Verbindungsanfrage. Damit läuft der Anfragende in einen Timeout.
Admins, die sich über Script Kiddies ärgern, glauben oft, diese durch DENY aufhalten zu können. Dies ist jedoch falsch. Es ist problemlos möglich, viele tausend Scans gleichzeitig zu starten und so auf alle Timeout gleichzeitig zu warten. Ein Scanner wird so nicht gebremst. Andererseits bremst man mit DENY alle legitimen Nutzer und Server massiv aus. Das betrifft insbesondere die ident Anfragen.
Ident dient dazu, dem Admin eines ordentlich gepflegten Systems eine Hilfestellung bei der Identifizierung seiner, sich daneben benehmenden Nutzer zu geben. DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen Servern nicht mehr aufgezeichnet werden. Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst, nimm DENY.
Sieh das Ganze doch so, wie in einer offenen Beziehung:
Es ist besser seinem Partner direkt zu sagen, daß man über ein bestimmtes Thema nicht sprechen möchte (REJECT): Der Partner weiß sofort, was Sache ist und und kann dann ohne Zeitverzögerung seine Entscheidung darüber treffen, ob er die Beziehung fortsetzen möchte oder nicht.
Geht man auf ein Thema allerdings gar nicht ein (DENY) und stellt die Ohren auf Durchzug, kostet das a) einem selber Zeit dem Geschwafel des Partners zuzuhören und b) dem Partner ebenfalls Zeit; er möchte nämlich ein für ihn wichtiges Thema/Problem loswerden, und hätte das dann ja wohl besser woanders getan.
Ein anderes Beispiel aus dem Leben:
Du gehst durch die Einkaufstraße deiner Stadt, und irgendein "Penner" quatscht dich an, und will 'nen Euro. Hier könnte man sagen "Ach ne, habe selbst kein Geld" (REJECT) oder einfach die fortgesetzte Bettelei ertragen.
Liebe Grüße
Erik
