/
Firewall configuration

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

IP

AWS Region

Status

52.57.22.128
18.193.165.109

Europe (Frankfurt) (eu-central-1)

active

3.221.157.128
3.224.118.59

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.