Question:
Our Company network is subject to restrictions and we can no longer access Rebrandly, how should we configure firewalls to allow reaching Rebrandly?
Answer:
Rebrandly is composed of multiple network components, each with a corresponding Fully-Qualified Domain Name and/or an IP address identifying it.
Your branded domains can be identified by the IPv4 address of the Rebrandly clusters for redirection: in order to navigate your branded links, the IP ranges and/or FQDN to whitelist are:
IP range | FQDN | Description |
52.72.49.79/32 |
redirect.unicast.rebrandly.network.
|
Branded Links redirection (default setting) |
76.223.20.46/32
13.248.148.104/32
|
redirect.anycast.rebrandly.network.
|
Branded Links redirection (advanced setting) |
dynamic IP |
redirect.system.rebrandly.network.
|
IPs serving rebrand.ly links |
dynamic IP |
rebrandly.com. |
IPs serving Rebrandly SaaS dashboard, browser extensions, apps and APIs |
dynamic IP |
proxies.rebrandlydomain.com. |
Preferred DNS name for proxy solutions (e.g. CloudFlare) |
dynamic IP |
rebrandlydomain.com. |
Former DNS name for redirection of 3rd level domains |
We recommend the Sys admin consider the two major Rebrandly services:
- Redirection of branded links: whitelisting branded links by IP ranges in the table will allow Rebrandly links to redirect in your network
- Link Management: whitelisting by IP is not possible for Rebrandly SaaS services such as the API, the globally distributed Dashboard, and the OAuth servers. We recommend whitelisting by FQDN (if the application firewall supports this). Employees administering the Rebrandly account should be made able to access rebrandly.com and its subdomains (HTTPS-only).
About rebrand.ly links (i.e. unbranded links), we recommend your company policy prevents employees from using this domain at all, and rather rely on Branded Domains only. This is implicitly enforced when you use a Workspace with Branded Domains only shared in it.
Comments
0 comments
Please sign in to leave a comment.