Introducing SDNSecurityToolkit

This post has been republished via RSS; it originally appeared at: Networking Blog articles.

Thanks to William Conlon for authoring today's post!

 

Every software producer has faced this challenge at some point: balancing flexibility with security. The most basic requirement of quality in any piece of software is that it will not expose the user to attackers, but in some cases the features of the software require us to allow the user to make mistakes that might expose vulnerabilities. In the world of operating systems, for example, we must balance letting our users configure their system how they want with protecting them to our best ability. To accomplish this we provide our users with tools to scan their system and alert them when we find something we know to be malicious or where a best practice is not being followed.

 

In the world of Software Defined Networking, even with a completely secure platform there is always the possibility that a customer will misconfigure a rule and expose their system. Our SDN team for Windows Server 2019 recognizes this. While there is no way that we can ensure that an SLB rule will never be misconfigured, we know how complicated SDN deployments can be and want to empower our users with tools to protect themselves. After all, deployments may reach thousands of VIPs, load balancing rules, and inbound and outbound NATs, all of which may be changing dynamically from day to day. With more of the world migrating to cloud, we can expect users to run into complex problems if we do not provide them with effective tools for visualizing the ways that they are exposing their system to the outside world.

 

To this end, we have created a new tool for analyzing your public VIPs. It is a simple PowerShell module called SDNSecurityToolkit, now available on the Microsoft SDN GitHub. After loading the module you will be able to use the Invoke-SDNVipScan cmdlet. To use this cmdlet, you only need to supply the connection URI for your existing SDN deployment and the path to an Nmap executable. The tool returns an object containing all its findings and you may also specify a path for it to output a basic HTML report or to save this information as a JSON object.

 

The tool runs in three stages, by running with the -verbose flag you can see these occurring in real time. The samples below have slightly different coloring for demonstration purposes. First, the tool queries across all existing load balancers for public VIPs and gathers information about what rules are making use of those VIPs:

 

tojens_6-1585692453108.png

 

To provide deeper insight, the tool then scans the exposed ports for these VIPs with Nmap to look at what might be listening on the other side. This is to acknowledge the multiple layers of security that may be in play, for instance a deployment may intentionally leave certain routes open on the load balancer side while securing VMs on the backend with firewall rules or other means:

 

tojens_7-1585692482855.png

 

Finally, the tool does a quick scan of your entire public address space as it is configured in your logical network lists with the Network Controller. If it finds an open address there, it cross references against your load balancer rules and alerts you if this address is not registered and should not be exposed. In the end, it provides a full report of exposed public IP addresses matched with rules and ports and whether said ports appear as open or filtered during the Nmap scan.

 

tojens_8-1585692504516.png

 

You can find a more technical description of how to set the flags and run this tool in its README, along with instructions on installing the Nmap dependency. We hope that by providing this we will give our users an edge when it comes to maintaining secure SDN deployments. We look forward to creating more tools for securing SDN deployments within this module, including an ACL scanner, which will help WS19 admins validate isolation between tenant SDN networks.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.