Bloxone Threat Defence Deployments

[#1]

Hello Guys,

We Want to ask about the Bloxone Threat Defence Deployments scenarios as it's not clear to us if we will go for the cloud scenario/on-premiss.. will it be installed on a vm or integrated with the DDI appliance.. because the admin guide just show us the configurations we didn't find any starting point for the on-premiss vm etc..

thanks for the support.

[#2 · Accepted solution]

Hi,

there are 2 kind of deployments:

1. By Using B1TD Threat Defense RPZ feeds. means that you onprem nios will be configured as slave RPZ member, and the data feed will be pulled from the B1TD cloud.

2. By Using B1TD Cloud. at this option you also have 2 sub option to do:

    a. on Prem DFP using separate Virtual Appliance, it could be installed from docker or from VMware OVA template that given by Infoblox. (all can be download from the csp portal0

    b. on prem DFP using onprem NIOS. in this option you are going to enable the DFP on the NIOS level.

For the configuration detail, please refer to the deployment guide.

Thanks

[#3]

This confused the hell out of me when trying to set up our pilot environment 'in my spare time', so I just wanted to clarify a bit for anyone else looking at your answer. (I've got a training budget, but no time to actually take the training, yet.) I worked off the online admin guide, mostly, since I couldn't quickly find a video or deployment guide that explained the parts that were throwing me off.

There really seems to be 3 deployment options, even though there are just two choices about where recursive queries are answered. (Or, I guess, 4 deployment options, but I may be missing some of the finer points due to terminology.)

1. Answer recursive queries yourself with an on-prem DNS firewall using physical or virtual NIOS appliances (so, one or two options, depending on if you consider those the same or different)

2. Forward recursive queries to Infoblox's cloud using a virtual DNS forwarding proxy appliance (haven't quite figured out where this is deployed, yet, as we're using Trinzic appliances in our data centers. From the instructions on Tokens, it appears the image can be loaded onto a hypervisor or a bare metals appliance from Infoblox, so maybe this is actually two different options, as well.)

3. Forward recursive queries to Infoblox's cloud using on-prem NIOS appliances (not well covered in the documentation)

I was finally able to get everything set up and working, after playing around a bit. Definitely could have been easier, though.

[#4]

Thanks a lot really !

[#5]

You're most welcome. I came here looking for the same info, so I understand the frustration.

We've actually gone live with our deployment and I've discovered a few new points that might help. Primarily, that BloxOne Threat Defense is a suite of offerings and the portion that is the Cloud-based DNS firewall SaaS (Software as a Service) is often shortened to just B1TD.

A DNS firewall is the core of this service and is offered as a SaaS (B1TD Cloud) or as a license to be applied to member(s) of your grid (on-prem), whether they are virtual machines or physical appliances. It essentially blocks or redirects users from reaching malicious sites.

There is a NIOS DNS firewall and the rules are configured within the grid, using RPZ (Response Policy Zones), and the threat intelligence feeds are 'imported' so that the processing is done 'on-prem.' I think this is what the Infoblox guys are thinking of when they make the distinction of Cloud vs On-Prem, in terms of 'Threat Defense'. (The two deployment options mentioned by @aralvidra02)

B1TD Cloud puts the DNS firewall part within the Infoblox controlled environment, and there are three ways (that I know of) how to get the DNS traffic to them:

1. Global forwarding of recursive queries to them with allowed networks defined in the CSP (assuming a source filter on a view type of thing)

2. A Windows or Mac agent that is downloaded and installed on the clients you want protected

3. DFP or DNS Forwarding Proxy, which is essentially a transparent proxy for DNS and can point to either the cloud or another customer-controlled DNS. I'm pretty sure the virtual machines and bare-metal appliances that act as only proxies are what Infoblox means by 'On-Prem Hosts' but a DNS server running NIOS can also be configured as a DNS proxy on top of other DNS services. And it can be physical or virtual, as well. (The two Cloud sub-options)

If you use purpose built proxies, either virtual or physical, the configuration is controlled in the CSP, which is the web-based interface for B1TD Cloud. These are the VM images referenced in the deployment guide and the physical units use the tokens referenced there.

If you use appliances running the NIOS software, either virtual or physical, you'll configure part of it in the Grid Master and part of it in the CSP. (Unless, perhaps you also have DDI in the Cloud?) What was confusing to me is that both the proxy-only hosts and the NIOS hosts are managed in the same section, but have different options available to them. Only part of the instructions apply to appliances that are licensed with NIOS, and it's not clear what those are.

Hope that didn't muddy the waters further...

[#6]

Hi Laura,

you got it right

the only thing which needs to be corrected is "The DNS firewall license is ADP (Advanced DNS Protection)"

ADP is protection of DNS server itself, against DNS software exploits, DoS, DDoS etc. - it's not related to DNS firewall functionality and it's not included in BloxOne Threat Defense (or B1TD). This functionality is most often used to protect external authoritative DNS servers, since they directly face Internet. Other typical use case for ADP is a DNS resolver of internet service provider (one of typical targets of DoS attacks often). 

On the other hand DNS firewall functionality is what B1TD is doing - it's all about protection of users and data with the help of DNS resolver (blocking malicious domains, detection of data exfiltration over DNS, C2 over DNS etc.).

ps. there's a 3rd way of pushing DNS queries towards B1TD cloud - you can install BloxOne Threat Defense agent on Windows or MacOS for roaming users. The agent will take over DNS queries from such computer, add some information such as username, OS version, MAC (so later infected computers can be identified in security reports), encrypt query and send it to B1TD cloud for processing. 

--

Piotr

[#7]

Thanks, Piotr!

I totally forgot about the agents; I'll add that to the other post. I'll also correct the part about the ADP and do some more reading. Unfortunately, the information is scattered about in many different places and the descriptions on the public website are more marketing than technical. Toss in a few name changes, to spice things up... lol

[#8]

Here is another way to consider how Threat Defense Deployment works:

Threat Defense is tiered (as a product) in a 'local basic (RPZ ONLY)', local mid tier (RPZ ONLY with more feeds), cloud mid tier(Cloud/DFP only) and hybrid top tier(Local RPZ and Cloud/DFP) product. 

From an architecture perspective, the solution provides the best information when the end client is doing DNS queries directly to an infoblox interface (be it the on machine client, DNS Forwarding Proxy on a Blox One On Prem host (the software you download from csp), DNS Forwarding Proxy on NIOS or a local Response Policy Zone running on each NIOS resolver.). 

If none of those are an option, the final edge access is to have whatever local resolver you have forward DNS queries directly to the cloud. You can give remote public IPs access via the 'network' option in the CSP interface. 

So, count em up, you have an edge DFP (PC/Mac/Droid/IOS), a stand alone DFP on a VM, a side car DFP that can run on NIOS, local RPZ, or a direct connection to the cloud. 

DFPs are all managed and controlled via the cloud, because that's where the policy controll and enforcement live. If you are running a DFP on NIOS, recognize that is running in a docker container and communicating back up to CSP for config and software updates, so NIOS is only the host for the DFP software. 

Local RPZs are secondary servers to the RPZ primary located in CSP, or locally authoritative (as a locally managed block/pass list)  Since the enforcement point for RPZ is on the local bind server, it makes sense that the managment and control of -that- feature must be on the local infoblox grid.   

Architectually, it is up to the designed to either push for a 'every client must recurse to infoblox DFP' or set expectations that tracking end points that run afoul of security policies will require additional work to discover. For example, in a MS DNS system, if all recursion comes through a MS DNS server, and is then sent on to either an on-prem DFP, NIOS RPZ, or just forwarded to CSP, the offending IP will -always- be the MS DNS server, not the client. 

I'll point out there are things that can be done in the cloud that can -not- be done on local systems, and in most designs I do, the local RPZ setup is designed as a fail over in case a location becomes isolated from infoblox's cloud, but not the internet. 

To sum up: your edge visibility requirments should dictate how you deploy DNS security. For most enterprise deployments, the 'easy'. button is to configure policy in the cloud system, and use DNS Forwarding proxies everywhere, with RPZs as a backup.