Archive

Archive for the ‘RDP’ Category

Customer Guidance for the Dopplepaymer Ransomware

November 20th, 2019 No comments

Microsoft has been investigating recent attacks by malicious actors using the Dopplepaymer ransomware. There is misleading information circulating about Microsoft Teams, along with references to RDP (BlueKeep), as ways in which this malware spreads. Our security research teams have investigated and found no evidence to support these claims. In our investigations we found that the …

Customer Guidance for the Dopplepaymer Ransomware Read More »

The post Customer Guidance for the Dopplepaymer Ransomware appeared first on Microsoft Security Response Center.

Time for day 2 of briefings at BlueHat Seattle!

October 25th, 2019 No comments

We hope you enjoyed the first day of our BlueHat briefings and the Bytes of BlueHat reception in our glamping tent (complete with toasted marshmallows). Yesterday, we learned a lot about how XboxOne hardware security has advanced the state of hardware security elsewhere, we heard some surprising correlations between vuln severity, age, and time to …

Time for day 2 of briefings at BlueHat Seattle! Read More »

The post Time for day 2 of briefings at BlueHat Seattle! appeared first on Microsoft Security Response Center.

TMG 2010 – YOU CANNOT REMOTELY CONNECT TO TMG SERVER WHEN IT’S PUBLISHING RDP PROTOCOL

March 24th, 2014 No comments

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

clip_image002

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

clip_image003

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

clip_image005

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

clip_image006

clip_image007

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

  1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

  2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

clip_image009

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

clip_image010

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Publishing, RDP, TMG Tags:

TMG 2010 – YOU CANNOT REMOTELY CONNECT TO TMG SERVER WHEN IT’S PUBLISHING RDP PROTOCOL

March 24th, 2014 No comments

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

clip_image002

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

clip_image003

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

clip_image005

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

clip_image006

clip_image007

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

  1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

  2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

clip_image009

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

clip_image010

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Publishing, RDP, TMG Tags:

TMG 2010 – YOU CANNOT REMOTELY CONNECT TO TMG SERVER WHEN IT’S PUBLISHING RDP PROTOCOL

March 24th, 2014 No comments

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

clip_image002

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

clip_image003

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

clip_image005

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

clip_image006

clip_image007

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

  1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

  2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

clip_image009

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

clip_image010

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Publishing, RDP, TMG Tags: