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
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.
That would be great, maybe you use some of them by yourself.
I didn't name the plugins directly by Atlassian.
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:
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:
18.104.22.168.in-addr.arpa. 3576 IN PTR ftp.uni-stuttgart.de.
22.214.171.124.in-addr.arpa. 3600 IN PTR science-vs14.science.uu.nl.
126.96.36.199.in-addr.arpa. 14400 IN PTR ftp.upjs.sk.
188.8.131.52.in-addr.arpa. 300 IN PTR mirror.sax.uk.as61049.net.
184.108.40.206.in-addr.arpa. 86400 IN PTR SunSITE.icm.edu.pl.
220.127.116.11.in-addr.arpa. 86377 IN PTR host-213-157-205-216.customer.co.ge.
18.104.22.168.in-addr.arpa. 86378 IN PTR mirrors.neterra.net.
22.214.171.124.in-addr.arpa. 14400 IN PTR inf2.uniri.hr.
126.96.36.199.in-addr.arpa. 3600 IN PTR mirror.nucleus.be.
188.8.131.52.in-addr.arpa. 28 IN PTR mail.thefrown.net.
252.45.83.5.in-addr.arpa. 21579 IN PTR mirrors.nxthost.com.
184.108.40.206.in-addr.arpa. 10800 IN PTR mirror.denit.net.
220.127.116.11.in-addr.arpa. 3580 IN PTR mirror.proserve.nl.
18.104.22.168.in-addr.arpa. 14400 IN PTR hosted-by.spango.com.
22.214.171.124.in-addr.arpa. 1781 IN PTR mirror.inode.at.
126.96.36.199.in-addr.arpa. 86382 IN PTR mirror.daniel-jost.net.
188.8.131.52.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.
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.
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:
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.
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:
That in conjunction with the JIRA configuration for the proxy should give you a reliable, secure setup:
Good luck with the setup!
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=184.108.40.206 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?
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.
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.
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?
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.
Hi Atlassian community, My name is Max and I work on the product integration team at Atlassian. I am pleased to announce the early access program for the Jira Cloud add-in for Outlook. This add-in...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events