Protecting Azure VM from unwanted attempted access with ACLs

For about the past two weeks, I’ve been noticing that my server has been running a little slow. It’s a tiny server and I was just chalking it up to that – small server = not great response, no biggie right? Yesterday however, My server was down for good, which actually turned out be unrelated… but what I found was a little unsettling. While I was looking through my servers Event Viewer I noticed a lot of failed log ins going to MSSQL… and I mean, 4-5 a minute failed log ins… for over a week. Needless to say, somebody was trying to get access to the data in my SQL via some sort of Brute-Force or Dictionary attack.

Here what Event Viewer looked like (x10000)


There were tons of different IPs being used to attempt these log ins,,, — the list goes on

this means someone’s also spoofing their IP address like anyone trying this sort of thing would. The one in the above image for example is supposedly from the city of Nanjin in Jangsu, China… another one identified as being from California. You can easily find out where an IP address is located by using free services like, however, it doesn’t mean much when your attacking is spoofing their IP address to throw you off the trail.

This could have been easily avoided had I taken the necessary preventative measures. Azure’s VM management allows for the easy control of an ACL over each VM you may have. ACL, if you don’t already know, stands for Access Control List. What it does, is exactly like what it sounds like it does, it’s a list that controls access to your machine. This is done by permitting and/or denying selected ranges of IP addresses.

When you choose a VM from from your list of Azure items, you’re brought that VM’s dashboard.


The third item on the row of tabs for your VM are your endpoints which are used for connecting to that VM via Remote Desktop, PowerShell, and SQL. Each endpoint is allowed to have to have it’s own ACL in order to provide access from whomever may need that resource and deny everyone else that shouldn’t have access. When you choose one of the endpoints, in the footer menu of the page, the option for ‘MANAGE ACL’ will appear.


Once MANAGE ACL has been selected, a window will appear


This is where you’ll actually provide the permitted IP ranges as well as the denied IP ranges. ACLs work top to bottom, if you deny an address up top, then permit it lower down, that address will be denied. If you do the opposite and permit an address up top then deny that address lower down the list, that address will be permitted. The remote subnet requires a CIRDR address which uses a {ipAddress}/{subnetBits} notation – you may need to do some research on this to permit or deny the correct ranges of addresses. The best way to ensure that no one but you want to permit access to the endpoint is allowed in is by putting the permitted address in then on the bottom of the list, enter the CIDR address — this will deny everyone who was not approved before this point. Any address afterwards will not be permitted.


Addresses beginning in 192.168 area addresses reserved for interfaces that aren’t actually connected to the internet – so this address isn’t actually viable. You can use here as well to discover what your actual Public IP address is. Once your ACL list is finished, click the checkbox on the bottom and Azure will set the rest up for you in a matter of seconds.

Angular: Basic Custom Directives using template and templateUrl

Custom directives in AngularJS allow to create your own element or attribute tags in order to accomplish specific goals you may have. As a general rule, custom element directives should be used to manipulate the view in some sort of fashion while custom attribute directives should be used to bolster or enhance a current element (such as a validation attribute in a login/registration form).

In order to create a directive the directive() function needs to be called on an Angular module. This is done simply like so:


 .module('app', [])
 .controller('mainController', function(){
 .directive('myDirective', function(){
         template: "This is my directive"

This is a basic directive that will simply display the defined template. The way the directive is currently configured, it can be used either as an element or an attribute because we have restricted it’s use as just an element or just an attribute.

in the HTML, using the directive as either attribute or element will create the same results.


One thing to notice in the way that the directive is being used is that the naming convention in the HTML is different from how it was defined in the directive function. Camel-Casing the directive name in the js file translates into either using dashes ( – ) and/or semicolons ( : ) between the words in the HTML. So the directive could have been written <my:directive> or if the name was longer, like thisIsMyDirective, it could have been something like <this:is-my:directive>… it would all rendered the same. It’s also no case-sensitive in the HTML.

Now if we wanted to restrict the use of the directive into only being an element, we could simply add the restrict keyword to the directives return object like so:

 .directive('myDirective', function(){
         restrict: 'E',
         template: "This is my directive"

Doing so would make the use of the directive attribute do nothing, and the image from above would no longer display the second ‘This is my directive’ in the HTML… In order to restrict the use of the directive to an attribute, ‘A’ would be used instead of ‘E’ and the reverse would be done in the HTML, the first ‘This is my directive’ would no longer show and the second would.

When using custom directives as elements, using the template keyword can become cumbersome because you may very well end up with this huge block of HTML code in your JS file… and no one wants that. The best thing to do, would be use to the templateUrl keyword and inject in a template of an external HTML page. I’ve created an external file called myDirectiveTemplate.html with the following code:

<div class="col-lg-4">
 <div class="panel panel-success">
   <div class="panel-heading">
     <p>Some Stuff here</p>
    <div class="panel-body">
      <p>Some stuff there</p>

This HTML file can now be used with the directive and injected in via templateUrl like so:


Now, we can expand the use of the directive as it is by improving upon the template in which it’s injecting. For Example: let’s say we wanted to change the header and content of the panels by using expressions and using a controller to control the data.

If we utilize our controller to hold an array of objects, we can use ng-repeat to create multiple panels with very minimal code having to be used in the view that’s actually using the directive.

The controller would look something like this:

 .controller('mainController', function(){
 var vm = this;
 vm.panels = [
     Heading: "Panel1",
     Body: "The body of Panel1"
     Heading: "Panel2",
     Body: "The body of Panel2"
     Heading: "Panel3",
     Body: "The body of Panel3"

Then the template is updated to use expressions like so:

<div class="col-lg-4">
 <div class="panel panel-success">
   <div class="panel-heading">
   <div class="panel-body">

Finally the view itself is updated with the ng-repeat in order to run through each object in the panels array:


This is a pretty decent improvement over something that would look like this instead:


AngularJS: $routeParams in a SPA

In Angular, there’s a service called $routeParams which takes a combination of the $location services search() and path() methods and allows the URI of the current $location to be picked apart and used as variables. The $routeParams service is dependent on the ngRoute module. My explanation isn’t that grand, but check it out in action below!

To start off using the $routeParams, you’ll first need to inject ‘ngRoute’ into the app’s main module.

var app = angular.module(‘app’, [‘ngRoute’]);

Next, the routes need to be configure to use the route parameters. This us done using the  ‘:’ syntax in the $routeProvider’s first parameter, the route. This will define the route parameter.

 $routeProvider.when('/dire', { templateUrl: 'partials/directory.html' });

$routeProvider.when('/dire/:user', { templateUrl: 'partials/userDetails.html' });

The first route will take users to a list of users ( I originally wanted it to be ‘/directory’… but for some reason the routes didn’t show… so I changed it to ‘/dire’ for short… don’t judge me). The second route makes use of the ‘:’ syntax which allows the route to vary and also be pulled out using $routeParams[“user”] in the controller which can be used to define a variable or passed into an $http request.

Next, a simple controller for each page that is being routed to. Each controller gets $location injected into it, but $routeParams only gets injected into the userDetailsController. ( Don’t mind the $http being injected into the directoryController… I forgot to remove that ).


The directoryController contains a simple array of users and a function for changing the $location which passes in the selected user as the parameter for the route. The userDetailsController takes defines $scope.user to equal the ‘user’ $routeParam (remember the ‘/dire/:user’ route? this is how we make use of the :user part).

To bring everything together, a couple simple views are in order. The page that will display the ‘directory’ ( or ‘dire’ in this case >.> ) will just display buttons with each users name. Ng-Click will allow the use of the chooseName function, it passes in the user’s first name.

<div ng-controller="directoryController" style="padding-right:10px;">
<label>Choose a person from the list below</label>
<button class="btn btn-info btn-block" ng-repeat="user in users" ng-click="chooseName(user.firstName)">{{user.firstName}}</button>

The second view uses an expression to display the route’s parameter.

<div ng-controller="userDetailsController">
<label>The Route Parameter</label>

Here’s what the final results look like:



Now, this was a very crude example of using $routeParams BUT it should (if I was clear in explaining how it works…) help to start seeing different ways you can use it to you own benefit as it’s a very useful tool.

VSO: Requesting feedback, using the feedback tool, and viewing feedback

Visual Studio Online provides a feature for requesting feedback on an application from your stakeholder users. You can provide a description of what it is you’d like feedback and could include steps on how to use the feature. The stakeholders in turn are able to provide feedback through text, videos and screen shots.

You can request feedback from any of your users, but it’s more marketed as a way for stakeholders to get a look at the app and of course… provide feedback.

Creating a stakeholder user

Creating a user as a stakeholder is just as simple as creating any user on VSO. Clicking the Users tab will display all current users and allow a new one be created with a stakeholder license.


Requesting Feedback

In order to see the request feedback link, you have be inside one of your team projects.


Clicking on one will open up the project view and at the bottom of the page will be the request feedback link


Using this feature requires either an Advanced license or an MSDN license to use, if you don’t have them and try, you’ll see this:


If you do have one, you’ll see:


The first requirement is to choose one or more stakeholders / other users. Whoever you want to help provide feedback, add them to the list.

The second option to tell stakeholders how to access the application. There are three radials for Web Application, Remote Machine, and Client Application. The Web Application allows  you to provide a URL/URI. The Remove Machine option allows you to enter the name of a Remote Machine. Finally,  the Client Application option allows you to enter the local path the application. The larger text box allows you to provide instructions on how to launch the application in which you listed.


Most likely, if you’re actually going to be sending this to a stakeholder, you’re message and URL/URI will be a tad bid different.

The final requirement is a description of the areas of focus you’d like feedback on. You can attach up to 5 areas of focus.


Once done with all the information, you can either do a quick preview of what the email will look like when sent, or you can just go ahead and send it.

Giving Feedback

Once the feedback request has been sent, it’ll pop up in the selected stakeholders e-mails like so:


If the stakeholder has never provided feedback before through the feedback tool, they must install the tool.


Running the install tool displays the usual Visual Studio style install window.


Once installed, follow the URL from the e-mail and it’ll open up the feedback client


Clicking next then provides a nice reply form for the stakeholder to be able to record their feedback via audio/video, provide screen shots, attach any extra files, and a comment box with some simple text manipulation.


Clicking next will display the submit page which provides a ‘Thank You’ for providing feedback and shows that the feedback is saved to VSO.


The option to submit the feedback and close the tool is at the bottom. Once clicked, the feedback is submitted and the tool closes.

Viewing the feedback

The feedback can be viewed in the project’s backlog in which the feedback request was initiated from. I’m assuming the iteration that gets chosen for the feedback work item is whatever the current is set as.


AngularJS: Controllers and the difference between ‘$scope’ and ‘this’

Something that I was confused on here for a little while was what the difference between using $scope.myVariable or $scope.myFunction and using this.myVariable or this.myFunction. I hadn’t seen it clearly stated anywhere when and where to use which. I was accustomed to just using ‘this’ from the tutorials I was following on CodeSchool. This morning I was playing around with my web app and it finally donned on me what was going on, so here’s what I have so far.

Update: This might help as well

Using $scope

There is HELLUVA lot more going on with scopes than what I'm about to present here. I would AB-SO-LUTELY recommend checking out the AngularJS Docs for what's really going on behind the scenes. I'm literally just going to show the difference in how they're used.

In essence, $scope is like a container in which an application’s view can use data from the controller.

When using $scope, $scope must be passed into the controllers function as a parameter.


With the $scope now passed in, it can be used within the controller. This example uses $scope to create  a function that will initiate a $http request which should return my IP address.


Then, comes the binding to the view. The ng-controller directive when using $scope doesn’t require adding an alias for the controller. Also, the directives don’t require the alias of the controller in order to reference a function in an ng-click or when an expression is displaying data.


The results will look like this:




Clicking ‘Get IP Address’ returns my correct IP address in to myIP, displays an alert with my IP address and successfully updates it on my page. The reason this works is because behind the scenes there is a $watch services associated with $scope which allows the view to be updated when the $scope’s myIP is updated.

Using ‘this’ instead of $scope

So now I’ll attempt to recreate the above using the this keyword instead. You’ll see at the end how the two aren’t exactly the same and how the outcome differentiates.

Here’s the controller again:


This time, the $scope isn’t passed in as a parameter to the function. The view now needs to be updated so that there’s an alias for the controller and the function and myIP variable must now be prefixed with the controller’s alias.


If we check out the resulting view it will look the same as before. But, when ‘Get IP Address’ is clicked this time. The Alert appears with the correct data, but the views representation of myIP isn’t updated. Which is due to the fact that there’s nothing ‘watching’ for the change, which $scope does naturally.



And as stated – the resulting controller.myIP isn’t updated after the request, so it still says ” What IP? ”


AngularJS: Creating a factory and returning data in a SPA.

Providers (I’ve seen many people just refer to Providers as Services, Angular docs use Providers, so that’s what I’m using >.< ) in Angular provide a way to fetch and persist data inside your web application. There are a couple different variations of providers which from what I can tell, and the large number of equally confused individual on the web, they’re all pretty much the same. There are providers, factories, values, and services, the one that you use is pretty much up to you depending on your need. The reply by Jonathon Palumbo on StackOverflow does a pretty good representation of what all of them look like as well clarifications like that fact that factories and services actually use providers ‘under the hood’. Again, a little confusing. Whatever.

I’m going to go over creating a factory which will fetch some data for me and then return it so that I can use that data in a controller to display on my web page.

So say I want to retrieve a list of users and display them to my page. This is where the factory comes in, it will retrieve the data for us. Then, the controller will bind the data. Finally, a web page will display the data.

Creating a Factory

Creation of a basic factory is easy. First, create a module to contain the factory.


The module is named app and the ngRoute module is passed in (if you want more information on ngRoute, checkout my last blog post). Now that we have a module, we can create the factory with .factory(‘factoryName’, function(){});


The first parameter is the name of the factory, the second is a function which will return data. The name of this factory is userRepository and what I want to do with it is return a list of users. To do so, a function needs to be added to the return in order to retrieve the list of users.


The return statement now contains a function called getAllUsers which returns an array of static users. The factory is now complete and this data can be bound in a controller to a view. This can be done by creating a controller and passing in or injecting the userRepository factory which will then make use of the getAllusers function.

Passing the Factory to a Controller


The first param is the controllers name, userController and the second is function which takes in the $scope service and the userRepository factory so that we can use it. Then, inside the function, $scope.users gets defined as the return data from UserRepository.getAllUsers(); – and that’s all we need for the controller.

Now, the reason I put ‘in a SPA’ is just because of how i’m going to associate the controller to my web page, which happens to just be a partial page in a Single Page Application (SPA). Associating a controller to a page in a SPA is super easy because in the $routeProvider.when method, you can use the controller: param to pass in the controller name

Adding the controller to the (partial)web page


In red is the .when for the page that I’ll be using the controller with and in green is the actual use of the controller: parameter.

Displaying the factory’s data

The only thing left to do is to display the data in users.html, a simple  ng-repeat will display all entries in the array provided by the factory in getAllUsers().


The result

When the web app loads up and the users page is visited, it’ll look like this:


AngularJS: Single Page Applications with $route

Single Page Applications can easily be created and maintained when using AngularJS. Single page applications are achieved by injecting HTML into the main page (index.html) using the ng-view directive and some routing. The routes will point to partial HTML pages that will be injected into index.html.

Getting Started

Using routing with Angular requires having the angular-route.js or angular-route.min.js files and a reference to one of them inside index.html. They can easily be acquired via NuGet, the AngularJS package includes all the scripts you could ever possibly need for Angular. I’ve also included a reference to an app.js file which will contain the module and route configurations.


The Body

Setting up the body of index.html is extremely easy because it just acts as a skeleton to the partial pages that will be injected in to it.


The body element contains the ng-app directive which has a value that indicates the module name I will use in app.js will be “app”. Within the nav element is a list of links to the partial pages. The href properties’ values use the #/ syntax which refers to the /partials/ directory and is how angular identifies the routes. The #/ syntax is then followed by the name of the page (don’t put the .html extension). Inside the div container is the ng-view directive which tells the page that this is where you want the partials injected into.


The following is an example of a partial page that can be injected into index.html. The solution explorer on the right side contains all the partials listed from the nav element in index.html.


Creating the Routes

The syntax for creating routes in Angular is very simple. A module will need to be created and ‘ngRoute’ will be need be passed into the second parameter – which is an array that takes controllers, services, and factories that the module depends on. After creating the module, the module’s .config property needs to be configured with the routes. The first parameter .config takes $routeProvider and the second parameter takes a function which will also accept $routeProvider as a parameter. Inside the function contain a list of routes. The routes follow the syntax of

$routeProvider.when(‘/pageName(like the links on index.html w/o the #)’,{ templateUrl: ‘partals/pageName.html’});

There is also an option$routeProvider property .otherwhise which allows you to redirect the user to a certain page in the event of something like a link not yet implemented. The syntax is:

$routeProvider.otherwise({ redirectsTo: ‘/pageName’ });

Here is app.js in it’s entirety.


The final product of all of this will create singe web page which will be able to quickly inject in different partial HTML pages.

The Header and Nav bar remain static on the page, when a link is selected the $routeProvider identifies the correct partial page and the HTML gets injected into the div element that contained the ng-view directive.



var about = JsonConvert.DeserializeObject <Collection<DevStuff>> (;