FQDN based IP Sets in DFW rules

Using PowerNSX to create FQDN populated IP Sets

NSX for vSphere does not have the ability to create FQDN based rules. Traditionally, a FQDN based rule will use the management planes registered DNS server to perform a lookup against a domain name. This will then return the IP address associated with web page and update an address set. Traditional firewalls such as SRX or ASA have this ability. Thanks to PowerNSX, NSX for vSphere does now as well!

Using the FQDN tool

Lets try on a very common website that most people have visited before.

PS /> ./fqdn-ipset.ps1 -domainname facebook.com

Adding new IPv4 addresses to IPS-facebook.com-v4
Adding new IPv6 addresses to IPS-facebook.com-v6
Tidying IPv4 entries
Tidying IPv6 entries

Alright! Two successfully created IP Sets for Facebook. It includes both IPv4 and IPv6 addresses.

PS /> get-nsxipset IPS-facebook.com-v4

objectId           : ipset-24
objectTypeName     : IPSet
vsmUuid            : 4201B045-B1F9-457F-E621-B54038A6AFA5
nodeId             : 4b749a6a-bc41-431b-bf24-cf9e54dcb452
revision           : 13
type               : type
name               : IPS-facebook.com-v4
description        :
scope              : scope
clientHandle       :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
value              : 

So there is a single IP address in the value property. Great! To prove that it is the current DNS entry lets run the resolution manually.

PS /Users/aburke/Documents/git/nsx-scripts/FQDN-IPset-update> [System.Net.Dns]::GetHostAddressesAsync($domainname).result

AddressFamily      : InterNetwork
ScopeId            :
IsIPv6Multicast    : False
IsIPv6LinkLocal    : False
IsIPv6SiteLocal    : False
IsIPv6Teredo       : False
IsIPv4MappedToIPv6 : False
IPAddressToString  :

AddressFamily      : InterNetworkV6
ScopeId            : 0
IsIPv6Multicast    : False
IsIPv6LinkLocal    : False
IsIPv6SiteLocal    : False
IsIPv6Teredo       : False
IsIPv4MappedToIPv6 : False
IPAddressToString  : 2a03:2880:f126:83:face:b00c::25de 

Great! There is a single entry for IPv4 and IPv6.

Running it again and cleanup

The script is built to handle existing IP Sets. It is also built to remove IP Addresses that are no longer being resolved. Lets run it again to see the behaviour of the script if something already exists.

PS /> ./fqdn-ipset.ps1 -domainname facebook.com

Attempting to add 2 IPv4 address(es) to IPS-facebook.com-v4

WARNING: Value is already a member of the IPSet IPS-facebook.com-v4

Attempting to add 1 IPv6 address(es) to IPS-facebook.com-v6

WARNING: Value 2a03:2880:f126:83:face:b00c::25de is already a member of the IPSet IPS-facebook.com-v6

Tidying IPv4 entries
Tidying IPv6 entries

This example shows a WARNING. This is some smarts built into PowerNSX by Dale and Nick. It will identify if an IP address already exists. If it does and you attempt to add it then PowerNSX will pass a warning to the console. It’s an example of building some smarts over the top of the API.

It will then remove old or stale IP Addresses from the IPv4 and IPv6 IP Sets. This is done by comparing updated IP’s to existing IP’s. Lets have a look at the dataplane to confirm.

[[email protected]:~] vsipioctl getrules -f nic-5454921-eth0-vmware-sfw.2
ruleset domain-c26 {
  # Filter rules
  rule 1012 at 1 inout protocol tcp from addrset ip-securitygroup-26 to addrset dst1012 port 443 accept;
  rule 1012 at 2 inout protocol tcp from addrset ip-securitygroup-26 to addrset dst1012 port 80 accept;
  rule 1003 at 3 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1003 at 4 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1002 at 5 inout protocol udp from any to any port 68 accept;
  rule 1002 at 6 inout protocol udp from any to any port 67 accept;
  rule 1001 at 7 inout protocol any from any to any accept;

Now lets have a look at the container on the dataplane which represents the destination addresses.

[[email protected]:~] vsipioctl getaddrsets -f nic-5454921-eth0-vmware-sfw.2
addrset dst1012 {
ip 2a03:2880:f126:83:face:b00c:0:25de,

It’s working and populated with the IPv4 and IPv6 addresses from the previous examples.

Using it in a rule

So now there is a dynamically updated pair of IPsets for IPv4 and IPv6 addresses, what about a rule? Here is an example rule.

Screenshot 2017 07 13 21 45 53

This will allow Virtual Machines associated with the source Security Group access to the destination IP addresses on HTTP/HTTPs.

Keeping it up to date

Name resolution is performed by the local host the script is run on. It will talk to the DNS server it has been assigned. This could be run on a dedicated virtual machine or container. The script can be run as a cron job or scheduled task at an interval of every 5 minutes to ensure resolution is current and up to date. If that is the case the user would need to define a connection to NSX Manager and start a powershell session as well!

This is what the interaction would look like with a ‘script-server’ running the tool.


It would need to talk to the DNS server and NSX Manager. This topoogy is to provide an idea of what connectivity may look like.

The code

The code for this script is found on my GitHub here


It is most likely than an enterprise would use this for internally hosted workloads. These may be virtual IPs for applications or internal hosted services. The frequency of this tool along with the speed of updates is dependant on the rate of changes for addresses.

Juniper Backdoors and vendor stone throwing

By now many in the network and security field will have heard about the announcement from Juniper. Juniper’s commentary about an internal code review identifying malicious code on their ScreenOS platform sparked a marked increase of hype on the Twittersphere. Everywhere ranging from the US Senate down to the local security administrator people have been commenting.

Anything from “Who put it there?”, “Why did they put it there?” and “How did it not get noticed?” have been asked. Was it China or the NSA? Do we know who? No we do not. Should we speculate? No we should not. Will we find out the truth? Not unless it is a controlled media statement. To be honest these things are currently above my pay grade and will stay that way.

So as a network administrator who used to manage (and has upgraded some old ones from my last work places) what should you do?

Lets review what is known to the public

  • Juniper revealed they noticed additional and unauthorised code in the ScreenOS source. This has been in it since 2012.
    • ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20
  • VPN traffic passing through the device can be decrypted and subsequently inspected
  • System access can be gained via any named account active on the device with the password <<< %s(un=’%s’) = %u

Instead of running around like a headless chook calling for blood there are some course of action to take:

  1. Is this firewall internet facing or have internet access? If not, plan and validate the risk profile. Plan to update the version. See 2 and 3.
  2. Juniper have released updated versions of the ScreenOS software. Update as soon as possible.
  3. IDS or SNORT rules to protect against any login by a system account which will generate the idea alert.
# Signatures to detect successful abuse of the Juniper backdoor password over telnet.
# Additionally a signature for detecting world reachable ScreenOS devices over SSH.

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Flowbit - Juniper ScreenOS telnet (noalert)"; flow:established,to_client; content:"Remote Management Console|0d0a|"; offset:0; depth:27; flowbits:set,fox.juniper.screenos; flowbits:noalert; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; sid:21001729; rev:2;)
alert tcp any any -> $HOME_NET 23 (msg:"FOX-SRT - Backdoor - Juniper ScreenOS telnet backdoor password attempt"; flow:established,to_server; flowbits:isset,fox.juniper.screenos; flowbits:set,fox.juniper.screenos.password; content:"|3c3c3c20257328756e3d2725732729203d202575|"; offset:0; fast_pattern; classtype:attempted-admin; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; sid:21001730; rev:2;)
alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Backdoor - Juniper ScreenOS successful logon"; flow:established,to_client; flowbits:isset,fox.juniper.screenos.password; content:"-> "; isdataat:!1,relative; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; classtype:successful-admin; sid:21001731; rev:1;)
alert tcp $HOME_NET 22 -> $EXTERNAL_NET any (msg:"FOX-SRT - Policy - Juniper ScreenOS SSH world reachable"; flow:to_client,established; content:"SSH-2.0-NetScreen"; offset:0; depth:17; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; priority:1; sid:21001728; rev:1;)


Does this put a nail in the coffin of the Security business unit of Juniper? Probably not. What isn’t kosha is the fact that vendors are out for blood and throwing stones. I work for a software company. Network companies are evolving into software companies. I put this tweet out the other day

Now more than ever we should be vigilant. We should work to better ourselves. United we stand and together we fall.

For some more reading this Wired article provides a great summary.