RPC-соединение, отфильтрованное без брандмауэров

Question

У меня есть рабочая станция (PC1), которая не может общаться с контроллером домена через RPC (TCP/135).

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

Выполнение той же команды на другой рабочей станции (PC2) в той же подсети и VLAN показывает LISTENING вместе со всеми конечными точками RPC сервера.

C:\>netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

Динамический диапазон портов одинаков как для PC1 и для PC2 .

И PC1 и PC2 работают под управлением Windows 7 Enterprise SP1.

Программное обеспечение McAfee Host Intrusion Prevention (HIPS) раньше устанавливалось на PC1 но было удалено в процессе устранения неполадок. Он остается установленным на PC2 . И PC1 и PC2 использовали одну и ту же политику HIPS.

Брандмауэр Windows в настоящее время отключен на 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.

Я перехватил RPC-соединение из portqry.exe с помощью Wireshark и обнаружил, что TCP SYN DPU был отправлен, но ACK никогда не получался . TCP SYN был отправлен еще два раза, и в Wireshark отображается как [TCP Retransmission] . Позже я перехватил ту же связь RPC на контроллере домена с помощью Wireshark. Я видел входящий TCP SYN но не получил ответа SYN ACK . Как будто контроллер домена произвольно игнорирует только этот компьютер только на этом порту. Обратите внимание, что запросы к Kerberos (UDP/88) отлично работают с PC1 .

Я также попытался восстановить стек TCP/IP на PC1 , но безрезультатно.

Есть идеи, что может помешать этому общению?

Answer 1

После большого количества устранения неполадок я смог определить, что было включено правило брандмауэра Windows, которое разрешало бы соединения с PC1 через TCP/135 и TCP/1027 если соединение безопасное. В Брандмауэре Windows в режиме повышенной безопасности -> Входящие правила я вошел в свойства подозрительного правила. На вкладке «Общие» в разделе «Действие» выберите « Разрешить подключение», если оно было безопасным . На экране «Настройка» выделите Разрешить соединение, если оно аутентифицировано и защищено . Описание этого элемента выглядит следующим образом:

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

Каким-то образом это правило было установлено через групповую политику в домене. Скорее всего, администратор создал это правило; однако возможно, что программное обеспечение, используемое на PC1 , для которого требуется это соединение, могло создать правило, если оно было установлено с использованием учетной записи администратора домена.