Firewall configuration
This guide should help to understand the requirements by the app to connect a self-hosted Data Center instance with the Microsoft 365 cloud.
We provide a list of static IP addresses that can be used to allow access to an internal Jira or Confluence instance - or be used with the Atlassian Cloud IP allow-listing feature.
We also recommend to look into mTls
Jira / Confluence Data Center
By default, all connections to your Jira Server or Data Center system will come from these IPs.
You might not need to whitelist all of them, in case you are certain of the region that will be used.
Only port 443 is used, if not specified otherwise in your Jira base url.
List of Domains
We have multiple domains for different purposes:
*.atlassianconnect.yasoon.com
*.app.yasoon.com
office.yasoon.com
*.yasoon.io (in case of user generated content)
List of static IPs
At the moment, our only static IP / egress proxy is located in Frankfurt. We are working on setting up regional data residency & compute resources. You will be able to choose which region to use then.
IP | AWS Region | Status |
|---|---|---|
52.57.22.128 | Europe (Frankfurt) (eu-central-1) | ACTIVE |
3.221.157.128 | US East (N. Virginia) (us-east-1) | SOON |
US West (Oregon) (us-west-2) | SOON | |
Asia Pacific (Sydney) (ap-southeast-2) | SOON | |
Asia Pacific (Tokyo) (ap-northeast-1) | SOON | |
Canada (Central) (ca-central-1) | SOON | |
Europe (Ireland) (eu-west-1) | SOON | |
Europe (London) (eu-west-2) | SOON | |
South America (São Paulo) (sa-east-1) | SOON |
mTLS
We understand it is a sensitive decision to grant access to your Jira instance for our services. That’s why our infrastructure supports mTLS for additional security. mTLS is enabled by default, if you import our root certificate in your mTLS terminating infrastructure (e.g. firewall, IDS or similar).
-----BEGIN CERTIFICATE-----
MIID0jCCArqgAwIBAgIQJcLdLwesdTYJKcKZ9tFU9zANBgkqhkiG9w0BAQsFADCB
gjELMAkGA1UEBhMCREUxFDASBgNVBAoMC1lhc29vbiBHbWJoMRQwEgYDVQQLDAtF
bmdpbmVlcmluZzEbMBkGA1UECAwSQmFkZW4tV3VlcnR0ZW1iZXJnMRcwFQYDVQQD
DA55YXNvb24gUm9vdCBDQTERMA8GA1UEBwwITWFubmhlaW0wHhcNMjMxMDE2MTEz
MTMyWhcNMzMxMDE2MTIzMTE3WjCBgjELMAkGA1UEBhMCREUxFDASBgNVBAoMC1lh
c29vbiBHbWJoMRQwEgYDVQQLDAtFbmdpbmVlcmluZzEbMBkGA1UECAwSQmFkZW4t
V3VlcnR0ZW1iZXJnMRcwFQYDVQQDDA55YXNvb24gUm9vdCBDQTERMA8GA1UEBwwI
TWFubmhlaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKUAnNWDyf
p5fysxyad8/78pLuydlJNUGMtK9xEMT/TGbqvY6zk1QBxWwr58BJ7L09qgaPh0ma
0Yo3B5VbUOvFF/hBzRVAgQQ+t1iNzJqoKb8XTpWNnSqHAyTwnzsXPluZ3v+tPoxo
ptIT+5HqMC/ZziSXD5znORCgwFQBnmouB8Bx2nSi+aI5NSvrtPsOoSoLZWcHx38o
4fOyuhvN24UrDwYN/ODayZ355osuib+cxszx2euqR0mJu44sTPiQK79UJ84dhPM1
buaZ0+I/jQgBVyg3JRNGkuexRkSaJij7N6YMkIDluhcuwNyT9boiGxruIrwOm0lE
sTkp5LdHaD3ZAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLos
Zar8B4lWnCvRjmXmRkwHpPEMMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsF
AAOCAQEAUI12i8nkTDsq69oud+TzY7Zbvu9HhcK8WuutlZueemeYEWQvk1AnhMMa
LekKez3sPOt1aiZ367fHNgh4p7PWGUC6tp7/T+JvhjadauBjtbvNeqLNva33OaSN
Ox7XRYEdFOab9/2OHRhbaeCKlr2VIUUQ5rrsIpRZbjOSHwkdp9tnRspByupXiL8d
oM8idHq7fhfwK/KHFtFRsRFwwJ2AHd67OeDllPMGkFRgLr3H1Bsr7ZPrX3qK64lg
e6G9yEQbb5KsiTUU9mCSi30k+lOsFEWgeFLahk7xUww8CBOJKVEa0r4POKrAjgdb
W+LUxvjgjfM0x+g1cA80j51cGAxZUA==
-----END CERTIFICATE-----
Please note, our service will not send a request with this exact certificate, but an intermediate certificate (valid for one week, each) that has been signed with this root certificate. This is recommended security practice by our provider, AWS.
mTLS prevents various kinds of attacks, including:
On-path attacks: On-path attackers place themselves between a client and a server and intercept or modify communications between the two. When mTLS is used, on-path attackers cannot authenticate to either the client or the server, making this attack almost impossible to carry out.
Spoofing attacks: Attackers can attempt to "spoof" (imitate) a web server to a user, or vice versa. Spoofing attacks are far more difficult when both sides have to authenticate with TLS certificates.
Credential stuffing: Attackers use leaked sets of credentials from a data breach to try to log in as a legitimate user. Without a legitimately issued TLS certificate, credential stuffing attacks cannot be successful against organizations that use mTLS.
Brute force attacks: Typically carried out with bots, a brute force attack is when an attacker uses rapid trial and error to guess a user's password. mTLS ensures that a password is not enough to gain access to an organization's network.
Phishing attacks: The goal of a phishing attack is often to steal user credentials, then use those credentials to compromise a network or an application. Even if a user falls for such an attack, the attacker still needs a TLS certificate and a corresponding private key in order to use those credentials.
Malicious API requests: When used for API security, mTLS ensures that API requests come from legitimate, authenticated users only. This stops attackers from sending malicious API requests that aim to exploit a vulnerability or subvert the way the API is supposed to function.