JIRA and Confluence server connecting to foreign hosts in internet

[Matthias Longerich]

Dear all,

we are operating 2 server, JIRA and Confluence, which don't have any outbound firewall rules established on a firewall.

The analytics option is disabled an each server.

The statement from the Atlassian Support is ,that server installations do not call home or anywhere else.

We have installed a few plugins.

A sniff by wireshark showed us, that there are outbound TCP connects to Halliburton and Du Pont server.

Does anyone have clue, what is initiating outbound connections from our server?

We appriciate any hints and advises how to stop those connections.

In the meanwhile we will stop unwanted outbound traffic by a firewall.

Thanks and cheers

Matthias

[Eduard M · Accepted solution]

Hello Matthias,

Sounds like some plugin is calling home and it's an undesirable behaviour. To know which, as administrator first enable firewall logging for outbound requests, disable all the plugins and then capture any event from the logs while re-enabling each plugin individually. OTOH if you are only concerned with your security you can just leave the firewall to block outbound as the Atlassian software does not make those requests.

[Matthias Longerich]

Thanks Eduard, do you know any source, which plugins may have such behavior?

[Eduard M]

No idea, I would like to know this myself! If you have a short list of candidates I could try to observe this behaviour. 

[Matthias Longerich]

That would be great, maybe you use some of them by yourself.

JIRA:

• Epic Sum Up - Light
• ICS Issue Calendar Sync for JIRA
• JIRA Timesheet Report and Gadets Plugin
• JIRA Vote for Comments
• Mobile for JIRA
• Stateoscope
• timereports

Confluence:

• BPNM Modeler
• DMN Modeler
• Gliffy
• Multivote
• Remind me Later
• Tableenhancer

I didn't name the plugins directly by Atlassian.

[Eduard M]

OK, I observed the behaviour and can confirm there are at least a dozen addresses that aren't Atlassian's, when running those add-ons. Among them there are some AWS addresses which may be part of the list described here as cloud services:

https://confluence.atlassian.com/cloud/atlassian-cloud-ip-ranges-and-domains-744721662.html

Unfortunately I don't have a firewall complex enough to specify the AWS domains to allow (such as marketplace lookups). 

It's likely that the other addresses which are not AWS are related to the add-ons as they were mostly FTP mirrors:

112.8.69.129.in-addr.arpa. 3576 IN PTR ftp.uni-stuttgart.de.
189.31.211.131.in-addr.arpa. 3600 IN PTR science-vs14.science.uu.nl.
70.16.197.158.in-addr.arpa. 14400 IN PTR ftp.upjs.sk.
3.53.20.185.in-addr.arpa. 300 IN PTR mirror.sax.uk.as61049.net.
2.28.219.193.in-addr.arpa. 86400 IN PTR SunSITE.icm.edu.pl.
216.205.157.213.in-addr.arpa. 86377 IN PTR host-213-157-205-216.customer.co.ge.
131.223.13.31.in-addr.arpa. 86378 IN PTR mirrors.neterra.net.
151.204.147.31.in-addr.arpa. 14400 IN PTR inf2.uniri.hr.
85.177.193.31.in-addr.arpa. 3600 IN PTR mirror.nucleus.be.
210.222.229.54.in-addr.arpa. 28 IN PTR mail.thefrown.net.
252.45.83.5.in-addr.arpa. 21579 IN PTR mirrors.nxthost.com.
106.174.148.62.in-addr.arpa. 10800 IN PTR mirror.denit.net.
198.224.84.80.in-addr.arpa. 3580 IN PTR mirror.proserve.nl.
65.147.98.83.in-addr.arpa. 14400 IN PTR hosted-by.spango.com.
228.34.116.84.in-addr.arpa. 1781 IN PTR mirror.inode.at.
102.52.198.88.in-addr.arpa. 86382 IN PTR mirror.daniel-jost.net.
209.89.211.95.in-addr.arpa. 86382 IN PTR mirrors.supportex.net.

This was only done in Jira, I didn't have time to check similarly in Confluence.

[Matthias Longerich]

Thanks for the info and your effort.

We definitely will put a restrictive firewall in front of our server to control outgoing traffic.

The Link you provided is good for using Atlassian Cloud products. Do we need to white-list all of the addresses and domains also for the server implementation?

Such a ruleset would be great to have.

[Eduard M]

The list for Cloud is not really needed for server implementation. Please review the following link to ensure marketplace connectivity or to turn off the marketplace in your installation:

https://confluence.atlassian.com/upm/problems-connecting-to-the-atlassian-marketplace-273875718.html

[Matthias Longerich]

Thanks for the hint.

So we will try to black everything accept 443 and the marketplace...

If you have a ruleset in the meanwhile, we appriciate.

Once we're done, we will share our experience here.

[Eduard M]

Hello Matthias,

The firewall rules will depend on the implementation. I was using a firewalld process built around iptables to do simple firewalling but that limited me to using IP addresses for filtering. Since iptables works on level 2 (packet headers) it's not easy to adapt it to use hostnames. Here you can see what iptables via firewalld look like for protecting outbound access:

firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -m state --state ESTABLISHED,RELATED -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --dport 8080 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --sport 8080 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --dport 8090 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --sport 8090 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --dport 22 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp --dport 53 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -p udp --dport 53 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter INPUT 2 -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 2 -d 127.0.0.1 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 3 -j LOG --log-prefix "LOG_AND_DROP: "
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 4 -j DROP 

It's fairly ugly and hard to maintain for a production environment, and it doesn't include the marketplace IP's. Those are not easy to maintain as hardcoded IP addresses because they are cloud services which will use multiple IP's and can change dynamically.

A better architecture would be to set up a forward proxy which blocks all websites and allows outbound requests to only these ones:

https://marketplace.atlassian.com
https://marketplace-cdn.atlassian.com

 That in conjunction with the JIRA configuration for the proxy should give you a reliable, secure setup:

https://confluence.atlassian.com/jirakb/how-to-configure-an-outbound-http-and-https-proxy-for-jira-applications-247857187.html

Good luck with the setup!

[Matthias Longerich]

Thanks for your advise. We will do our best ;-)

[Matthias Longerich]

Hi Eduard,

I've got one more question regarding the firewall, we are building. It seems, that saving comments, need a connection, which is not Atlassian, but 1e100.net, which is a google machine:

Nov 25 10:26:25 xxxx kernel: [108880.580219] [UFW BLOCK] IN= OUT=ens3 src=192.168.xxx.xxx DST=172.217.21.10 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23291 DF PROTO=TCP SPT=37454 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0
yyyyyy@xxxx:~/ufw$ host 172.217.xx.yy
10.21.217.172.in-addr.arpa domain name pointer muc11s13-in-f10.1e100.net.
10.21.217.172.in-addr.arpa domain name pointer fra07s29-in-f10.1e100.net.
10.21.217.172.in-addr.arpa domain name pointer muc11s13-in-f10.1e100.net.
10.21.217.172.in-addr.arpa domain name pointer fra07s29-in-f10.1e100.net.

 May you explain this behavior?

What is it good for?

Thanks.

[Eduard M]

The subnet seems to be associated with googleapis.l.google.com and other google webservices (oauth, etc). I don't know of any reason for this other than possibly pulling updates on AJAX scripts served by the application. It's probably best to leave it blocking in firewall unless you see a specific need to open it (if you were using oauth to authenticate via google servers). If I find out more about that target I'll update here.

[Matthias Longerich]

We can't leave it blocked, because then there are no comments possible in JIRA.

Once we enable the rule for Blocking, we can't save any new comment. At least for some users.

I were able to save comments, but couldn't like or dislike comments. A colleague couldn't save anything and the server logged a communication error after 2 mins or so. During this time, JIRA tried to connect to the google address.

Confluence seems to work fine with the FW enabled.

[Eduard M]

That's unexpected, in fact I cannot duplicate the behaviour. It's certainly not a common occurrence because there are many Jira instances running fine without internet connectivity. Are you using any HTML editor other than the standard one? Do you know which addons are influencing comment functionalities, if any?

[Matthias Longerich]

We identified the plugin :-)

The "mobile for JIRA" causes the behavior.

Once the plugin is activated, and the firewall active, no comments can be saved.

If we disable the plugin, everything is fine. Even all mobile users can use JIRA ;-)
We will now leave the plugin disabled, until someone gets a problem.

So, maybe you like to add the info to your knowledge base.

[Eduard M]

Hello Matthias,

Glad you could locate the root cause and workaround for this issue. I've opened a suggestion request for documentation:

https://jira.atlassian.com/browse/JRASERVER-66406

Have a great day!

[Matthias Longerich]

Thanks again for your support.

Have a great week!