Scott Hanselman Podcast Episode 719

I recently listened to and really enjoyed this podcast episode from Scott Hansleman: “Myself. Its not weird at all

In it, he touches on such a wide range of concepts: discipline and consistency, doing what you love, “Yes, and” instead of “no” as a redirect. He talks about deliberate practice, imposter syndrome, mindfulness, commitment to what is important, and making time.

Some choice quotes that really resonated with me:

  • “Most people live their lives accepting the defaults. If you are deliberate about installing something, you hit custom.”
    • Curiosity has been a major component to my learning, both professionally and personally. I see an “advanced” window on an installer wizard, and I can’t help but click it just to find out what’s hidden there. I feel the same way outside of work too – be curious about why I think the way I think, believe what I believe; be curious about how things work in a physical sense and a conceptual sense.
  • “By simply being mindful, you cannot stop but improving”
    • This thought gives me encouragement that even small intentional actions can have a positive impact. Even if I’m not feeling particularly capable, even if I’m not crushing a project or task, even if I haven’t been dedicated to deep learning, I can still be on an upward trend by being aware, considerate, and mindful of my actions and those around me.
  • “Yes there are a thousand little things where someone can make me question who I am, and am I good; but then I go back and look at what I do, and what I have made and say “no, I did that and I’m going to give myself credit”.”
    • Often times for me, this is as much giving myself permission to be proud of what I have accomplished and reflect on it a little bit, rather than discount my efforts for a variety of reasons that my mind is surely able to conjure up.
  • “Why do I feel like an imposter talking to this person? The reason is because of the road not taken; This person did something I did not do, and I’m intimidated because they stuck with it when I did not.”
    • I frequently question and doubt some of my decisions, particularly when I see people have success on alternate paths. I need to remind myself that their success in no way invalidates my path – if I am confident in who I am and what I do, I can celebrate their success rather than wonder what could have been.

Highly recommended listen.

Job I want to have

I was looking through my Google Drive recently, doing some cleanup and pruning. I came across a document I had created in June 2016, called “Job I want to have”.

I don’t remember creating this document at all. It’s contents are a job posting for an “Infrastructure Technology Analyst”, without any kind of reference to the original company.

Here’s a snippet of what it looked like:

In June 2016 I was feeling stagnant; lack of motivation, lack of direction. I looked at this posting and thought that it was a huge stretch, and that it may be so difficult to actually achieve enough skill to be able to fill a position like this.

Now I’m reflecting on this, and realize that I have this job – I do all of these things right now, and it didn’t take a monumental effort. It wasn’t hours and hours of study time, or money for certifications and courses. I’m not saying I didn’t have to work hard to learn, or that it was random chance that put me here. It was certainly time spent learning, but by doing; by embracing the challenges as I faced them and learning how to solve them with the focus of a goal in mind.

What it really required was for me to step outside of where I was comfortable, embrace the fear of uncertainty, and try. Try something new and something different; try a chance that the grass could actually be greener.

I’m glad I came across this because I needed a refresh in my mind of what my goal was and understanding that I have achieved it. I needed a reminder that the core of what I’m doing now is still fun and drives me to have the kind of career I want to have.

Perhaps its nearing time to set my sights on something a little scary again.

Azure NSG discovery

During deployment of some resources with an Azure virtual network which has subnets with network security groups (NSG) applied, I made a new discovery that I didn’t previously know. It makes sense in the context of how Azure applies NSG rules, but it doesn’t align with a traditional understanding of firewall ACLs across a subnet.

Communication within subnet

If you apply a Deny rule that has a lower priority than the default 65000 “Allow Vnet inbound”, it will also deny resources within that subnet from communicating with each other.

I discovered this while applying a “Deny inbound” rule in order to restrict lateral movement between subnets, not intending to restrict traffic within a subnet.

For example, I have a “management” subnet, with an NSG applied. Inside this subnet is an AD domain controller, and a member server. I apply a Deny rule for any source, after my “allow incoming” rules have been applied to let other subnets talk to this domain controller.

Now I find that my domain controller cannot reach my member server, despite it residing within the same subnet.

While I do not want to allow service tag “VirtualNetwork” incoming access (again, to restrict lateral movement), I do want “everything inside this subnet can talk to everything inside this subnet”. As such I had to create a specific rule for this behavior.

Azure IaaS Deny outbound considerations

As a general practice, outbound Internet access should be denied except for approved destinations. This is referenced in NIST 800-41 as a “deny by default” posture.

Achieving this within Azure Infrastructure as a Service in a practical and economical way without breaking a large amount of services is quite difficult at the moment.

If Outbound Internet is fully denied, some of the commonly used services of Azure will cease to work:

  • Azure Backup
  • Log Analytics
  • Azure State Configuration (DSC)
  • Azure Update Management
  • Azure Security Center
  • Windows Update

Some of these are not as difficult to solve – Service Tags on NSG rules can allow Azure services where they have been defined by Microsoft. As of Ignite 2018 in late September, there are new service tags covering entire regions, or all of Azure (“AzureCloud”). This means you can allow most of those services above to function and still deny general Internet outbound.

Additional Service Tags for Windows Update, or custom definitions are supposed to be coming in the future, but this doesn’t fully resolve the problem.

What if your application has a GIS component, and it needs to reach * What if your users have a legitimate reason to access a particular website? It isn’t good enough to just resolve that IP address one time and add it to an NSG.

What is really needed is a method to allow access to a fully qualified domain name (FQDN), particularly with wildcard support.

Here are some possible solutions:

Implement a 3rd Party network virtualization appliance (NVA)

This is the most common response that I see recommended to the outbound problem. Unfortunately, it is really expensive, and overkill if you’re only address this one particular problem. One has to consider high availability of the resources, as well as management of them since you’re just adding more IaaS into your environment, which is what we’re all trying to get away from when we’re using the cloud isn’t it?

Some vendors may not support wildcard FQDN in it’s ACLs (Barracuda CloudGen last I checked), which means you can’t support things like Windows Update where no published IP list exists.

If the implementation is anything like SonicWALL’s method, it will have difficulty being reliable – this relies upon the SonicWALL using the same DNS server as the client (calling it ‘sanctioned’) which may or may not be true in your Azure environment with the use of Azure DNS or external providers.

Implement Azure Firewall

Azure Firewall is new on the scene and released to General Availability as of late September 2018. It supports the use of FQDN references in application rules, and while I haven’t personally tested it, the example deployment template is shown to allow an outbound rule to *

Confusingly, their documentation states that FQDN tags can’t be custom created, but I believe this just references groups of FQDN, not individual items.

Azure Firewall solves the problem of deploying more IaaS, and it’s natively highly available. However it again isn’t cheap, at $1.25/hour USD it is a high price to pay for just this one feature.

Wait until FQDN support exists in an NSG rule

It has been noted on the Microsoft feedback site that NSG rules containing FQDN is a roadmap item, but since this hasn’t received the “Planned” designation yet, I expect it is very far down the roadmap; particularly considering this feature is available in the Azure Firewall.

Build something custom – Azure Function or runbook which resolves DNS and adds it to your NSG

I’ve toyed with the idea of building a custom Azure Function or Automation runbook which can resolve a record and add it to an NSG. I’ll have a post on the Function side of this coming soon that describes how it would work, and the limitations that made me discard the idea.

Realistically, this isn’t a long-term viable solution as it doesn’t solve the wildcard problem.

Utilize an outbound transparent proxy server

This method involves trusting some other source to proxy your outbound traffic and depending on that source, gives a large amount of flexibility to achieve the outbound denial without breaking your services.

This could be an IaaS resource running Squid or WinGate (a product I’m currently testing for this purpose), or it could be an external 3rd party service like zScaler which specializes in access control of this nature.

To make this work, your proxy must be able to be identified by some kind of static IP to allow it through the NSG, but after that the whitelisting could happen within the proxy service itself.

I see this as the most viable method of solving the problem until either FQDN support exists for NSG, or Azure Firewall pricing comes down with competition from 3rd party vendors.

Azure Support Plan discovery

I learned some things about Azure Support Plans recently.

A co-worker was tasked with adding an Azure Support Plan to a new subscription that was being created. So they went to, clicked “Help and Support”, and then from the drop-down selected the new subscription ID.

Then they clicked Change Plan and added a Standard support plan. Upon investigation, this appeared to add a support plan to ALL subscriptions, which was scary. We don’t want to be charged 10x$100USD per month!

Working through a support case with Microsoft, I learned the following about support plans that cleared things up.

A support plan is tied to an Azure Account – the account that subscriptions are created under. The support plan is effectively its own subscription, not tied to individual subscriptions themselves. However, you won’t see it displayed this way in

It’s not until you log into that you see it itemized by itself and are able to view billing history for the support plan.

So if I have 10 subscriptions, and they are all created under one Azure Account (you can see this on the “Properties” page of your Subscriptions blade), then only a single support plan is needed.

This also clarifies why Microsoft’s instructions on removing a support plan describe to “Go to the portal, and click ‘cancel subscription'”.

When I thought that this was a per-subscription basis, that made me afraid we’d cancel our actual subscription. Knowing now that this is it’s own subscription, that text makes a lot more sense.