Infoblox Firewall Rules

Here.

To access the Documentation Page you must allow the following domains

• docs.infoblox.com
• media-us.dg.refined.site
• static-us.dg.refined.site

• DST FQDN - grpc.csp.infoblox.com
• DST Port - 443
• SRC Port - 26749
• Protocol - TCP
• Only runs if BloxConnect is enabled.
• Once an appliance is elected to send data, it will not try to elect other members until and unless data sending is failed with previous elected node
• If the appliance that was sending data to BloxConnect fails to send data (can't connect) then all members of a Grid will test connectivity once every 24 hours
• When BloxConnect is disabled, data is synced to all members every 8 hours.

Election Logic

1. CSP Connected GM (active node) (i.e. with Join token)
2. CSP Connected GMC (i.e. with Join token)
3. CSP Connected Member (i.e. with Join token)
4. GM with connectivity to CSP
5. GMC with connectivity to CSP
6. Member with connectivity to CSP

When you have the Infoblox Cloud Data Connector (in cloud) “as a service” sending directly cloud-to-cloud to Sentinel/Splunk/etc using HTTPS, then the traffic will come from the following IP that you may need to put in an allowlist in Sentinel/Splunk.

• 3.221.42.234 (prd1.threatdefense.infoblox.com)

When configuring public cloud to allow access from Infoblox Portal to your public Cloud API for discovery, you may need to add the following IP to an allow list.

• 3.221.42.234 (prd1.threatdefense.infoblox.com)

Documented here and here (best practice).

In some cases, firewalls will block any attempt to resolving DNS other than through DFP running on Infoblox. This can create a chicken-egg situation where NIOS needs to connect to Infoblox to get resolution but can't because it can't resolve *.infoblox.com. This is why the DFP has its own setting for DNS resolver to use and why NIOS/NIOS-X should be permitted access to the Infoblox Anycast IP addresses (see below) on udp-53 and tcp-53.

• threatdefense.bloxone.infoblox.com (IPv4 DNS Anycast addresses - Details)
  • 52.119.41.100 (better services. Based on AWS Anycast/GSLB)
  • 103.80.6.100 (better services. Based on AWS Anycast/GSLB)
  • 52.119.40.100 (works well but isn't quite as good as the IP addresses above)
  • 103.80.5.100 (works well but isn't quite as good as the IP addresses above)
  • 52.119.41.120 (for NIOS-X Local On-Prem Resolution feature. infobloxtd.com)
  • 103.80.6.120 (for NIOS-X Local On-Prem Resolution feature. infobloxtd.com)
  • +any of the Geo specific ones above (see below).
  • 52.119.41.200 (DoH IP)
  • 103.80.6.200 (DoH IP)

IPv6 DNS Anycast addresses:

• 2400:4840::100
• 2620:129:6000::100

BloxOne Endpoint also uses 52.119.41.53.

Infoblox geo-based Anycast IPs for POPs:

“52.119.40.100 and 103.80.5.100” are both in the same BGP advertisement. Infoblox AS395363 52.119.40.0/24 and 103.80.5.0/24 (Owned by Infoblox)

“52.119.41.100 and 103.80.6.100” are both in the same BGP advertisement. Amazon AS16509 52.119.41.0/24 and 103.80.6.0/24 (Owned by Infoblox)

The 52.x.x.x addresses are registered in California.

The 103.x.x.x addresses are registered in Japan.

PTR record for each address above is threatdefense.bloxone.infoblox.com

Details of POP on this page.

Global Map of POPs.

Status of POP (and other Infoblox services) on this page.

• threatdefense.infoblox.com will return 52.119.41.100 and 103.80.6.100
• geo.threatdefense.infoblox.com will return the Geographically nearest POP to the resolver making the query.

API calls to public cloud come from 3.221.42.234.

• Infoblox IP Allowlist
• Infoblox FQDN Allowlist
• Infoblox URL Allowlist

• tcp-53 to recursive DNS server
• udp-53 to recursive DNS server
• udp-123 to NTP server
• tcp-443 to the following FQDN's
  • app.noa.infoblox.com/ (DFP - Application Management)
  • cp.noa.infoblox.com/ (DFP - Platform Managment)
  • csp.infoblox.com/ (Cloud Services Portal)
  • dns.bloxone.infoblox.com/
  • grpc.csp.infoblox.com/ (same as cp.noa.infoblox.com)
  • 52.119.40.100/ (BloxOne Threat Defense Cloud DNS server / threatdefense.bloxone.infoblox.com)
  • 103.80.5.100/ (BloxOne Threat Defense Cloud DNS server / threatdefense.bloxone.infoblox.com)
  • tide.infoblox.com (TIDE)
• tcp-443 to smartproxy.b1tdc.infoblox.com if you want to give clients access to the web category block page.

I have also seen NIOS-X virtual servers resolving the following which I think come from the underlying OS

• ntp3.wirehive.net
• motd.ubuntu.com

FYI:

• Platform Management - Handles communication between NIOS-X and Infoblox Portal. Runs underlying OS and Kubernetes - that is all. Not aware of applications.
• Application Management - Handles various services running on NIOS-X itself. This is the system that reaches out to Infoblox Portal to download updated application images.

Active member of a Advanced Active/Passive HA pair talks to the passive member on tcp-847. Two traffic flows (GRPC and HTTP) run to this port.

Both members of an DHCP HA pair talk to each other on udp-647 (heartbeat).

tcp-647 for Kea HA (also used in hub-spoke Kea HA)

When the IP address of a NIOS-X virtual server is changed, for a while after the change the internal docker image will try to access certain ports of the device using the old IP. Therefore you may see, in your network traffic logs, traffic from the new IP to the old IP on the following ports.

• tcp-9100
• tcp-17172
• tcp-17173
• tcp-17174
• tcp-28888
• udp-1953

Also, you need to remember access

• from GM/GMC to authentication server
• from a designated member to Microsoft servers for DNS and/or DHCP syncing (MSRPC).
• from a designated member to VMware/OpenShift/AWS/Azure/GCP for vDiscovery.
• from a designated member to any network for ping/snmp/nmap-scan for Discovery (Network Insight).
• from any/all DNS members to SCP server for query/response logging via SCP.
• from any/all DNS member to backend servers for DTC monitoring as required (icmp, tcp-80, tcp-443, snmp, etc)

Left to itself with no special config, NIOS will connect on tcp-443 to

• csp.infoblox.com
  • 18.209.243.220
  • 18.233.189.178
  • 18.235.149.1
• grpc.csp.infoblox.com / cp.app.noa.infoblox.com
  • 3.209.116.255
  • 3.210.226.54
  • 3.212.42.44

When DFP is enabled on NIOS, it also connects to

• app.noa.infoblox.com
  • 3.214.29.106
  • 3.214.194.152
  • 3.213.214.20

And obviously it will need access to the Threat Defense Anycast IP addresses (see above):

NIOS will resolve the IP address of the above domains by querying 52.119.40.100 which is a DNS server run by Infoblox and it is authoritative for *.infoblox.com. It is also Infoblox Threat Defense cloud resolving IP if you add your public IP to the list of external networks. This is true even if the NIOS Grid it configured to resolve DNS via other nameservers (e.g. the DNS servers of the Grid itself).

Grid Members need to access each other on the following ports (that function as both destination port and the source port)

• udp-2114 (Grid Key exchange) (Palo App-ID = infoblox-grid)
• udp-1194 (Grid VPN) (Palo App-ID = infoblox-grid)

Grid members talk to the reporting server (if there is one) on TCP-9997. If MGMT port is enabled on a node, then the node will use that port to communicate with the reporting server (if there is one).

For RPZ feeds being used with Infoblox Threat Defense threat feeds, the Infoblox Grid Secondaries will access the two RPZ IP addresses on tcp-53 and udp-53. If you have nominated a Grid Member as “Lead Secondary”, it will download the RPZ and the other members will download from the Lead Secondary on tcp-53. Note that the Lead Secondary will initiate a session to udp-53 to the other secondary members for notification packets.

• ns1-rpz.csp.infoblox.com 54.69.93.185 (US West)
• ns2-rpz.csp.infoblox.com 52.2.30.79 (US East)
• US West Notification Server 44.224.71.15 (Allow access from this IP to UDP-53 on NIOS. Use DNAT if needed)
• US East Notification Server 3.221.42.234 (Allow access from this IP to UDP-53 on NIOS. Use DNAT if needed)
• EU 1 52.57.3.126
• EU 2 18.159.153.132
• EU Notification server 52.58.79.200 (traffic from this IP to your DNS RPZ server)