This is an old revision of the document!
Table of Contents
Infoblox Firewall Rules
NIOS Firewall Rules
Here.
Documentation Page
To access the Documentation Page you must allow the following domains
- docs.infoblox.com
- media-us.dg.refined.site
- static-us.dg.refined.site
BloxConnect
- 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
- CSP Connected GM (active node) (i.e. with Join token)
- CSP Connected GMC (i.e. with Join token)
- CSP Connected Member (i.e. with Join token)
- GM with connectivity to CSP
- GMC with connectivity to CSP
- Member with connectivity to CSP
Rules for Data Connector
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)
Asset Insights
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)
Rules for Endpoint
Documented here and here (best practice).
Infoblox Threat Defense
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::1002620:129:6000::100
BloxOne Endpoint also uses 52.119.41.53.
Infoblox geo-based Anycast IPs for POPs:
| Region | IPv4 Address | Secondary IPv4 Address | Hostname |
|---|---|---|---|
| California (USA) | 52.119.41.51 | 103.80.6.51 | us-west-1-geo.threatdefense.infoblox.com |
| Virginia (USA) | 52.119.41.52 | 103.80.6.52 | us-east-1-geo.threatdefense.infoblox.com |
| London (England) | 52.119.41.53 | 103.80.6.53 | eu-west-2-geo.threatdefense.infoblox.com |
| Frankfurt (Germany) | 52.119.41.54 | 103.80.6.54 | eu-central-1-geo.threatdefense.infoblox.com |
| Mumbai (India) | 52.119.41.55 | 103.80.6.55 | ap-south-1-geo.threatdefense.infoblox.com |
| Tokyo (Japan) | 52.119.41.56 | 103.80.6.56 | ap-northeast-1-geo.threatdefense.infoblox.com |
| Singapore | 52.119.41.57 | 103.80.6.57 | ap-southeast-1-geo.threatdefense.infoblox.com |
| Toronto (Canada) | 52.119.41.58 | 103.80.6.58 | ca-central-1-geo.threatdefense.infoblox.com |
| Sydney (Australia) | 52.119.41.59 | 103.80.6.59 | ap-southeast-2-geo.threatdefense.infoblox.com |
| San Paulo (Brazil) | 52.119.41.60 | 103.80.6.60 | sa-east-1-geo.threatdefense.infoblox.com |
| Bahrain (UAE) | 52.119.41.61 | 103.80.6.61 | me-south-1-geo.threatdefense.infoblox.com |
| Johannesburg (South Africa) | 52.119.41.62 | 103.80.6.62 | af-south-1-geo.threatdefense.infoblox.com |
| Ohio (USA) | 52.119.41.63 | 103.80.6.63 | us-east-2-geo.threatdefense.infoblox.com |
| Hyderabad (India) | 52.119.41.64 | 103.80.6.64 | ap-south-2-geo.threatdefense.infoblox.com |
| Hong Kong | 52.119.41.65 | 103.80.6.65 | ap-east-1-geo.threatdefense.infoblox.com |
| Region | Exit IPv4 Address | Exit IPv4 Address | Hostname 1 | Hostname 2 |
|---|---|---|---|---|
| California (USA) | 50.18.3.254 | 52.52.152.211 | ca1.threatdefense.infoblox.com | ca2.threatdefense.infoblox.com |
| Virginia (USA) | 3.221.42.234 | 3.210.133.138 | prd1.threatdefense.infoblox.com | prd2.threatdefense.infoblox.com |
| London (England) | 3.9.234.55 3.11.119.74 | 13.42.84.27 | ld1.threatdefense.infoblox.com | ld2.threatdefense.infoblox.com |
| Frankfurt (Germany) | 18.158.253.104 | 18.156.59.212 | fk1.threatdefense.infoblox.com | fk2.threatdefense.infoblox.com |
| Mumbai (India) | 65.0.152.93 | 3.7.67.223 | mb1.threatdefense.infoblox.com | |
| Tokyo (Japan) | 13.230.205.59 | n/a | jp1.threatdefense.infoblox.com | |
| Singapore | 54.179.114.1 | n/a | sg1.threatdefense.infoblox.com | |
| Toronto (Canada) | 3.96.72.179 | n/a | to1.threatdefense.infoblox.com | |
| Sydney (Australia) | 3.104.250.224 | n/a | sy1.threatdefense.infoblox.com | |
| San Paulo (Brazil) | 54.94.69.164 | n/a | sp1.threatdefense.infoblox.com | |
| Bahrain (UAE) | 15.184.140.118 | n/a | br1.threatdefense.infoblox.com | |
| Johannesburg (South Africa) | 13.245.50.242 | n/a | ec2-13-245-50-242.af-south-1.compute.amazonaws.com | |
| Ohio (USA) | 3.143.123.31 | n/a | ec2-3-143-123-31.us-east-2.compute.amazonaws.com | |
| Hyderabad (India) | 65.2.108.69 | 65.1.29.110 | mb1.threatdefense.infoblox.com | |
| Hong Kong | 18.166.181.249 | ec2-18-166-181-249.ap-east-1.compute.amazonaws.com |
Hyderabad also has:
- 65.0.152.93
- 3.7.67.223
- 13.203.91.21
- 98.130.91.165
- 18.60.104.39
You can get this list above by retrieving all records for threatdefense.bloxone.infoblox.com.
Threat Defense Notes
“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.comwill return52.119.41.100and103.80.6.100geo.threatdefense.infoblox.comwill return the Geographically nearest POP to the resolver making the query.
Asset Insights
API calls to public cloud come from 3.221.42.234.
NIOS-X Firewall Rules
IP Allow List
Public IP List
NIOS-X To Internet
- 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
- Application Management - Handles various services running on NIOS-X itself
To DHCP Partner
Active member of a Advanced Active/Passive HA pair talks to the passive member on tcp-847. Application is grpc and it uses HTTP/2.
Both members of an DHCP HA pair talk to each other on udp-647.
Changing NIOX-X Server IP
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
NIOS Firewall Rules
Grid Management
| Purpose | Source | Destination | Port/Protocol/Application | Notes |
|---|---|---|---|---|
| Grid Key Exchange | NIOS Member | NIOS GM/GMC | udp-2114/infoblox-grid | BIDIRECTIONAL |
| Grid VPN | NIOS Member | NIOS GM/GMC | udp-1194/infoblox-grid | BIDIRECTIONAL |
| Grid Accesss | Sys Admin Machines | NIOS GM/GMC | tcp-443 | Web UI Access |
| Grid Accesss | Automation Source | NIOS GM/GMC | tcp-443 | API Access |
| DNS Resolution | NIOS Member | DNS Server | tcp-53/udp-53/dns | Probably needed on GM/GMC. Might not be needed on other members if they don't need to resolve DNS. e.g. might be needed if systems are using FQDN for connecting to external services such as NTP, authentication, syslog, email, DFP, etc |
| NTP | Non-GM/GMC NIOS Member | NTP Server | udp-123/ntp | Probably only needed on GM/GMC. Other members probably syncing time over Grid connection |
| Reporting | Any NIOS Member | Reporting NIOS Member | tcp-9997 | Sending reporting data to Reporting server |
| Syslog | Any NIOS Member | Syslog server | udp-514/syslog | Sending syslog data |
| SNMP Trap | Any NIOS Member | SNMP Server | tcp-162/udp-162/snmp-trap | Sending SNMP Traps |
| SNMP Probe | SNMP Server | Any NIOS Member | tcp-161/udp-161/snmp | Sending SNMP Probes |
| Any NIOS Member | SMTP Server | tcp-25/smtp | Sending email alerts | |
| Ping | Anything? | Any NIOS Member | ICMP echo/ping | Allow anything/somthing to ping NIOS |
| SSH | Anything? | Any NIOS Member | tcp-22/ssh | Allow anything/something to SSH to NIOS |
| SCP | NIOS GM/GMC | SCP Backup server | tcp-22/ssh | Allow for SCP backup (can be FTP if absolutely necessary) |
Grid Services
| Purpose | Source | Destination | Port/Protocol/Application | Notes |
|---|---|---|---|---|
| DNS Query | Any client | NIOS DNS Members | udp-53/tcp-53/dns | Clients querying NIOS for DNS |
| DNS Recursion | NIOS DNS Members | Anything on the Internet | udp-53/tcp-53/dns | NIOS using root hints to recurse public DNS |
| DNS Forwarding | NIOS DNS Members | Target DNS servers | udp-53/tcp-53/dns | Target global forwarder or conditional forwarder or primary server for zone transfer |
| DNS Query | Any client | NIOS NTP Members | udp-123/dns | Clients querying NIOS for NTP |
| DHCP Query | Any client | NIOS NTP Members | udp-67/udp-68/tcp-67/tcp-68/dhcp | Clients querying NIOS for DHCP |
| DHCP Failover | NIOS Member in FO | NIOS Member in FO | tcp-647 |
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)
