
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
Die Ausführung des gleichen Befehls auf einer anderen Arbeitsstation ( PC2
) im selben Subnetz und VLAN wird LISTENING
zusammen mit allen RPC-Endpunkten des Servers angezeigt.
C:\>netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384
PC1
Der dynamische Portbereich ist auf und gleich PC2
.
PC1
Auf beiden PC2
läuft Windows 7 Enterprise SP1.
Die McAfee Host Intrusion Prevention (HIPS)-Software war zuvor auf installiert, PC1
wurde aber während der Fehlerbehebung entfernt. Sie ist weiterhin auf installiert PC2
. Beide PC1
verwendeten PC2
dieselbe HIPS-Richtlinie.
Die Windows-Firewall ist derzeit auf 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 mit portqry.exe
Wireshark aufgezeichnet und festgestellt, dass die TCP SYN
DPU gesendet, aber nie ACK
empfangen wurde. Die TCP SYN wurde noch zweimal gesendet und in Wireshark als angezeigt [TCP Retransmission]
. Später habe ich dieselbe RPC-Kommunikation auf dem Domänencontroller mit Wireshark aufgezeichnet. Ich habe den Eingang gesehen, TCP SYN
aber keine SYN ACK
Antwort. Es ist, als würde der Domänencontroller nur diesen Computer auf nur diesem Port willkürlich ignorieren. Beachten Sie, dass die Abfrage von Kerberos (UDP/88) von aus problemlos funktioniert PC1
.
Ich habe auch versucht, den TCP/IP-Stack neu aufzubauen PC1
, jedoch ohne Erfolg.
Irgendwelche Ideen, was diese Kommunikation verhindern könnte?
Antwort1
Nach einer Menge Fehlerbehebung konnte ich feststellen, dass eine Windows-Firewall-Regel aktiviert war, die nur Verbindungen von PC1
über zulässt TCP/135
und TCP/1027
wenn die Verbindung sicher ist. InWindows-Firewall mit erweiterter Sicherheit->Eingehende Regelnging ich in die Eigenschaften der verdächtigen Regel. Auf der Registerkarte Allgemein unter Aktion,Erlauben Sie die Verbindung, wenn sie sicher istwurde ausgewählt. Auf dem Bildschirm AnpassenErlauben Sie die Verbindung, wenn sie authentifiziert und integritätsgeschützt istwurde hervorgehoben. Die Beschreibung für diesen Eintrag lautet wie folgt:
Allow only connections that are both authenticated and integrity-protected
by using IPsec. Compatible with Windows Vista and later.
Diese Regel wurde irgendwie über eine Gruppenrichtlinie in der Domäne erstellt. Höchstwahrscheinlich hat ein Administrator diese Regel erstellt. Es ist jedoch möglich, dass die verwendete Software, PC1
die diese Kommunikation erfordert, die Regel erstellt haben könnte, wenn sie mit einem Domänenadministratorkonto installiert wurde.