Friday, August 14, 2015

RDP over SSL

I have a few servers and desktops running on the cloud, some on Azure and some on AWS. I frequently need to RDP into these boxes. But it is not always possible if I am inside a firewall. Simple port redirection does not fool those firewalls. The SSL traffic is allowed almost in any organization. So, one of the best options is to tunnel the RDP inside the guise of SSL.

I found the following article very useful.

RDP SSL tunneling with stunnel

In fact, I recommend you proceed as outlined above in the article.

I've provided my comments as I use Windows on both ends (Server as well as client).

On the Server

1. Install stunnel
2. Provide necessary details to create the server-side certificate (stunnel.pem)
3. Make the changes to the configuration file as below:

; Debugging stuff (may be useful for troubleshooting)
debug = info
output = stunnel.log

; Microsoft CryptoAPI engine allows for authentication with private keys
; stored in the Windows certificate store
; Each section using this feature also needs the "engineId = capi" option
;engine = capi
; TLS front-end to a web server

[https]
accept  = 443
connect = 3389
cert = stunnel.pem

; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SChannel
; Microsoft implementations do not use TLS close-notify alert and thus they
; are vulnerable to truncation attacks
TIMEOUTclose = 0

On all the gateways / firewalls

1. Make sure that the traffic flows through and through on port 443 from client to server. Open necessary ports (or forward ports as necessary) along the way.

On the Client

1. Install Cygwin which comes with stunnel and socat
2. Create the certificate (again follow the instructions from the original article as I'll not repeat it here)
3. Make the changes to the configuration file as below:

; debug = 7
;foreground = yes
output = /etc/stunnel/tunnel.log

cert = /etc/stunnel/stunnel.pem
options = NO_SSLv2

[rdp]
client = yes
accept = 127.0.0.1:3399
connect = 127.0.0.1:81

4. On the Cygwin shell, run stunnel
5. And then run socat as follows:

socat -d -d TCP-LISTEN:81,reuseaddr,fork PROXY:<FQDN OF YOUR CORPORATE PROXY SERVER>:<FQDN OF YOUR REMOTE SERVER>:443,resolve,proxyport=<YOUR CORPORATE PROXY PORT>,proxyauth=<YOUR CORPORATE USERNAME>:<YOUR CORPORATE PASSWORD>

Traffic Flow

Here is the traffic flow:

1. You RDP to 127.0.0.1:3399
2. Your client stunnel which is listening at port 3389 encapsulates the RDP traffic in SSL and forwards to port 81 on the client
3. Your client socat which is listening at port 81 forwards the traffic to port 443 on the remote server while authenticating to the corporate proxy using your corporate username and password
4. Traffic flows through all the hops that you have between the client and server
5. Traffic lands on port 443 on the remote server where the server stunnel is listening at port 443
6. The server decapsulates the RDP traffic and forwards it to port 3389 on the server
 
Believe me, it works and there is no delay. I've tested it myself and can vouch for it. In fact, I am blogging this post from my desktop on Azure while behind a thick firewall. Happy RDPing.

Friday, June 26, 2015

Git and Visual Studio

It has been a while since I last blogged. Things were crazy at the work place for a while. For all these years my preferred IDE has been Microsoft's Visual Studio and with that I was enduring Visual SourceSafe initially. I had brief interaction with SourceGear Vault which came as a welcome releif. The arrival of TFS changed the ALM (Application Lifecycle Management) landscape a lot and till today remains my preferred sourcecode control system.

I have been hearing about distributed source control systems a lot lately. And when the opprutunity came, I tried to fit that with my IDE. In this blog, I am going to outline the steps involved.

When it comes to Git, there are a ton of options. TFS itself can act as a Git hub. Visual Stusio 2013 comes equipped with a Git client. I am not that fortunate. I still have Visual Studio 2012 Premium with Update 4. So the first step for me was to install the client. There are a few options available here. The most popular ones are:

1. Visual Studio Tools for Git (https://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c)
2. Git Source Control Provider (https://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c)

I chose the first one as that product has been the base for client tools that constitutes the native client of VS 2013. So here we go:

STEPS

1. Download and install "Visual Studio Tools for Git" from https://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c

NOTE: For some reason, this install didn't ask for priviledged access (UAC prompt for administrative access) on my workstation during the install and failed throwing a rather odd error that the minimum version required was "Visual Studio 2012 Update 2". I already had Update 4. After scratching my head for a while, I opened administrative command prompt and ran the MSI file as below:

msiexec /i "<Full Path of the Downloaded MSI File>"

The above step installed the client tool as intended.

2. Go to Tools --> Options --> Source Control and change the source control plug-in to "Microsoft Git Provider".

3. Open Visual Studio and open "Team Explorer" (View --> Team Explorer)

4. Click on "Install 3rd-party Git command prompt tools". This action would let you download and run msysgitVS.exe eventually installing Git GUI and Git Bash on you local workstation.

5. Open Git GUI (Start --> Git GUI) and then Help --> Show SSH Key. You should have "No keys found."

6. Click on "Generate Key".

7. Provide a passphrase. You would be requiring this passphrase at every commit and push phase, so provide one that you can easily remeber.

8. Once the key is generated, click "Copy to Clipboard" to copy the public part of the key and send it to your Git administrators to give you access to the repositories you need.

9. While you are waiting for the access, perform the following steps to setup your local environment.

10. Try to determine where the keys are stored locally on your computer. The easiest way is to open Git Bash (Start --> Git Bash) and then run the following commands:

cd
pwd

The first command takes to your home directory and the second provides the fullpath of the current directory. If you see /h it's H:, if you see /C/Users/xyz, it's C:\Users\xyz and so on and so forth.

11. Navigate to the folder above. You should see a .ssh folder (if you don't see the folder, then change your view option in explorer to show hidden files and folders). Locate id_rsa (which is the whole key) and id_rsa.pub (which is the public part of the key).

12. Determine your username. On the Git Bash, you should see the command prompt is in the format of xyz@abc where"xyz" is your username and "abc" is your machine name.

13. Open Visual Studio, go to Team Explorer (View --> Team Explorer) and then Settings --> Git Settings. Provide your user name (noted on the above step), email address and a default repository location and click "Update". I normally provide C:\git\repositories.

14. Once your Git administrators provide you acces, they will also provide a URL to connect to your assigned repository. The URL may be SSH or HTTPS based.

If it's HTTPS, you can directly connect to it by the steps below:

14.1.1. Click on Connect (View --> Team Explorer --> Connect)

14.1.2 Clone your repository to local by clicking on Clone under Local Git Repositories. Provide the URL in the format of https://github.com/abc/abc.git and the local path in the format of C:\git\repositories\abc where abc is the name of the repository.

14.1.3. You should now be able to perform commit/push/sync operations from Visual Studio directly.

If the URL is SSH, then additional steps are involved between the interaction of Git repository with Visual Studio. Also the push and sync actions cannot be performed from Visual Studio. In case of SSH, perform the following steps.

14.2.1 On Windows Explorer, create the path to store your local repository, e.g. C:\git\repositories\abc where abc is the name of the repository.

14.2.2 Open Git Bash (Start --> Git Bash) and navigate to your local folder.

cd /C/git/repositories/abc

14.2.3 Clone the repository by providing SSH URL in the format of ssh://git@github.com/abc.

git clone ssh://git@github.com/abc

14.2.4 On Visual Studio, click on Connect (View --> Team Explorer --> Connect).

14.2.5 Add the local repository. E.g. C:\git\repositories\abc

15. On the step above, you got connected to your Git repository and downloaded the latest version of the source code. Now it's time to perform the normal source control operations. If your repository is empty, you can start creating your solutions and projects underneith your local repository (e.g. C:\git\repositories\abc) the normal way. There is no "Add to Source Control" step as everything is tracked as you make changes. If your repository is not empy, then you can immediately start working on existing solutions and projects the normal way.

16. Unlike other source control systems, Git is distributed. So you have three areas:

a) Your local work area where your changes are tracked automatically e.g. C:\git\repositories\abc

b) Your local version control repository which is typically at C:\git\repositories\abc\.git

c) Your central version control repository which is typically at github.com or other servers

The steps involved are "commit" which commits changes from your local work area to your local version control repository and "push" which pushes those changes from your local version control repository to your central version control repository.

If the URL was in HTTPS format, you can commit and push from Visual Studio:

16.1.1 Right click on your solution, project or file and click on "Commit". Provide a comment. You now have option to "Commit" and then "Push" and then Sync as three steps or simply "Commit and Push" or "Commit and Sync" as a one step operation.

If the URL was in SSH format, you can only commit from Visual Studio. You will not be able to "Push" or "Sync" from Visual Studio as those steps would fail.

16.2.1 Right click on your solution, project or file and click on "Commit". Provide a comment and click on "Commit" only.

16.2.2 Open Git Bash (Start --> Git Bash) and navigate to your local folder.

cd /C/git/repositories/abc

16.2.3 In order to "push", provide the following command:

git push origin master

16.2.4 In order to "pull", provide the following command:
git pull ssh://git@github.com/abc