RPC-Verbindung ohne Firewalls gefiltert

2168
Micah Røckstår Henning

Ich habe eine Arbeitsstation ( PC1), die nicht über RPC (TCP / 135) mit einem Domänencontroller kommunizieren kann.

C:\PortQryV2> portqry.exe -n 192.168.1.1 -p tcp -o 135  Querying target system called:  192.168.1.1  Attempting to resolve IP address to a name...  IP address resolved to dc.domain.local  querying...  TCP port 135 <epmap service>: FILTERED

Wenn Sie denselben Befehl auf einer anderen Arbeitsstation ( PC2) im selben Subnetz und im selben VLAN ausführen, LISTENINGwerden alle RPC-Endpunkte des Servers angezeigt.

C:\>netsh int ipv4 show dynamicport tcp  Protocol tcp Dynamic Port Range --------------------------------- Start Port : 49152 Number of Ports : 16384

Der dynamische Portbereich ist für beide PC1und derselbe PC2.

Beide PC1und PC2führen Windows 7 Enterprise SP1 aus.

Die McAfee Host Intrusion Prevention (HIPS) -Software wurde auf installiert PC1, wurde jedoch während des Fehlerbehebungsprozesses entfernt. Es bleibt auf installiert PC2. Sowohl PC1und PC2verwendet die gleiche HIPS Politik.

Die Windows-Firewall ist zurzeit deaktiviert PC1.

C:\>netsh advfirewall show allprofiles  Domain Profile Settings: ---------------------------------------------------------------------- State OFF Firewall Policy AllowInbound,AllowOutbound LocalFirewallRules N/A (GPO-store only) LocalConSecRules N/A (GPO-store only) InboundUserNotification Enable RemoteManagement Disable UnicastResponseToMulticast Enable  Logging: LogAllowedConnections Disable LogDroppedConnections Disable FileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log MaxFileSize 4096   Private Profile Settings: ---------------------------------------------------------------------- State OFF Firewall Policy AllowInbound,AllowOutbound LocalFirewallRules N/A (GPO-store only) LocalConSecRules N/A (GPO-store only) InboundUserNotification Enable RemoteManagement Disable UnicastResponseToMulticast Enable  Logging: LogAllowedConnections Disable LogDroppedConnections Disable FileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log MaxFileSize 4096   Public Profile Settings: ---------------------------------------------------------------------- State OFF Firewall Policy AllowInbound,AllowOutbound LocalFirewallRules N/A (GPO-store only) LocalConSecRules N/A (GPO-store only) InboundUserNotification Enable RemoteManagement Disable UnicastResponseToMulticast Enable  Logging: LogAllowedConnections Disable LogDroppedConnections Disable FileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log MaxFileSize 4096  Ok.

Ich habe die RPC-Verbindung von portqry.exeWireshark erfasst und festgestellt, dass die TCP SYNDPU gesendet wurde, aber ACKniemals empfangen wurde. Das TCP SYN wurde noch zweimal gesendet und in Wireshark als angezeigt [TCP Retransmission]. Später habe ich die gleiche RPC-Kommunikation mit Wireshark auf dem Domänencontroller erfasst. Ich sah die Ankunft TCP SYN, sah aber keine SYN ACKAntwort. Es ist, als würde der Domänencontroller nur diesen Computer an diesem Port willkürlich ignorieren. Beachten Sie, dass die Abfrage von Kerberos (UDP / 88) einwandfrei funktioniert PC1.

Ich habe auch versucht, den TCP / IP-Stack wieder aufzubauen PC1, ohne Erfolg.

Irgendwelche Ideen, was diese Kommunikation verhindern könnte?

1
Wireshark auf der anderen Maschine sieht die Verbindung eingehend? Optichip vor 9 Jahren 0
Ich kann Winpcap nicht auf dem Domänencontroller installieren, da wir uns in einer geschützten Umgebung befinden. Es würde eine Weile dauern, bis die erforderlichen Genehmigungen vorliegen. Micah Røckstår Henning vor 9 Jahren 0
kannst du mit dem telnet telnet? Verbindet es sich? Optichip vor 9 Jahren 0
"telnet 192.168.1.1 135" schlägt auf "PC1" fehl, ist jedoch auf "PC2" erfolgreich. Micah Røckstår Henning vor 9 Jahren 0
Sie haben dort dann ein paar Blockierungen. PC1 ist dein Problem. Können Sie eine Firewall-Regel erstellen, um den Eingang von PC2-Port 135 zuzulassen? Optichip vor 9 Jahren 0
Die Windows-Firewall ist deaktiviert. Ich habe jedoch versucht, es zu aktivieren, und eine Regel erstellt, mit der TCP / 135 ohne Erfolg zugelassen wird. Ich habe auch versucht, die Windows-Firewall auf die Standardwerte zurückzusetzen, auch ohne Erfolg. Micah Røckstår Henning vor 9 Jahren 0
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/20490/discussion-between-optichip-and-micah-rockstar-henning). Optichip vor 9 Jahren 0

1 Antwort auf die Frage

1
Micah Røckstår Henning

Nach einer langen Problembehandlung konnte ich feststellen, dass eine Windows-Firewall-Regel aktiviert war, die nur Verbindungen von PC1vorne zulässt TCP/135und TCP/1027ob die Verbindung sicher ist. In der Windows-Firewall mit erweiterter Sicherheit -> Eingehende Regeln habe ich auf die Eigenschaften der verdächtigen Regeln eingegangen. Klicken Sie auf der Registerkarte Allgemein unter Aktion auf Verbindung zulassen, wenn sie sicher ist . Lassen Sie auf dem Bildschirm Anpassen die Verbindung zulassen, wenn sie authentifiziert ist und die Integrität geschützt ist . Die Beschreibung für diesen Artikel lautet wie folgt:

Allow only connections that are both authenticated and integrity-protected  by using IPsec. Compatible with Windows Vista and later.

enter image description here

Irgendwie wurde diese Regel durch eine Gruppenrichtlinie für die Domäne festgelegt. Wahrscheinlich hat ein Administrator diese Regel erstellt. Es ist jedoch möglich, dass die Software, für PC1die diese Kommunikation erforderlich ist, die Regel erstellt hat, wenn sie mit einem Domänenadministratorkonto installiert wurde.

Verwandte Probleme