We've noticed that JIRA datacenter will always listen on the web traffic port and additionally on 8005, 40001, and a "random" port (we've seen e.g. 44698, 42255, 54267).
What are these ports used for?
What is the range of the ports that might be the "randomly" chosen one?
8005 is used as the tomcat control port. This is the one that commands like stop-jira.sh use to attempt a graceful shutdown of the application server. This port is only opened on the loopback interface, so you needn't normally worry about it.
Most of the other ports you are asking about are associated with Java Remote Method Invocation, or RMI. This allows one JVM to request that another JVM run code on its behalf, but largely hides the networking layer from the consumer, so it looks to the caller like it is invoking the method on any other local object. Its use was a design decision made by the caching technology we chose to use for JIRA Data Center (JDC), which is called Ehcache.
1099, which you did not list, is a control port used for RMI communication. This is a registry service for RMI services, with a purpose vaguely like DNS.
40001, this is the default port that we suggest using for Ehcache to create its services on. Each individual cache gets a URL that refers to it and that client can send requests to in order to say things like "Value X was removed from my cache, so you should remove it too". You may configure this to a different port number if you wish. (See Installing JIRA Data Center: Cluster.properties file parameters for the relevant setting).
The "random" port has to do with RMI's default behaviour for handling incoming requests. Here is somebody explaining it better than I could. Specifically, this an RMI server socket used for handling individual requests, and we could create a custom RMIServerSocketFactory to modify the behaviour, but by default the port is left unspecified (0) meaning that a TCP ephemeral port is selected. This range is operating system-specific and usually tunable with a registry setting (Windows) or kernel parameter (UNIX/Linux). Of course, since this is a configuration parameter for the entire TCP/IP stack, this has system-wide implications, so it would be "nicer" if we added the extra supporting code necessary to be able to select the port range directly, instead.
The answer to both questions is "no". As documented in the installation instructions here:
and advised on a specific known security threat that results from allowing external access to RMI
you absolutely do need to secure access to the port yourself. The recommendation is that you ensure the security of the network itself, either by using firewalls or establishing a secure network tunnel (IPSec, etc.)
Note/edit: The "specific InvokerTransformer vulnerability" I referred to is only meant as an example of what can go wrong. We have done the corresponding update to Apache Collections in https://jira.atlassian.com/browse/JRA-47638
so that specific vulnerability is addressed, but the very nature of what RMI does and the fact that these method calls influence cached data means that the port should be secured, anyway.
thanks @Chris Fuller though i'm not sure i see the relevant text in https://confluence.atlassian.com/adminjiraserver071/installing-jira-data-center-802592197.html#InstallingJIRADataCenter-Security could you point it out please?
So the link I pasted is apparently only available to people with the rights to edit the page. I can see it, but you get redirected to what it published. So somebody added the security info, but never published it.
The unpublished section reads:
Ensure that only permit cluster nodes are allowed to connect to a JIRA Data Center instance's ehcache RMI port, which by default is port port 40001, through the use of a firewall and/or network segregation. Not restricting access to the ehcache RMI port could result in the compromise of a JIRA Data Center instance.
I'm not honestly certain why the changes weren't included in the public page. I'll follow up w/ our docs people to figure out what needs to be done to fix this.
That reaches the extent of my knowledge about RMI's internals, I'm afraid. However, I will say that Oracle's own RMI security recommendations suggest that they would not consider that communication to be intrinsically secure, either. It's better to be safe than sorry.
The docs have been updated to include the Security details provided by Chris. Apologies for the omission!
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot