nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Hardening existing Confluence for Internet deployment

David Sidwell

Hello all. I'm looking for advice to pass on to our (outsourced) IT support. We have a LAN Confluence working already, with Internal (private) pages as well as 1 or 2 new Spaces we wish the public to see. For assorted reasons, we are considering shfiting this whole Confluence deployment to (say) a DMZ and locking it down, so that only the 2 'customer' Spaces are viewable by "the public" - but internal people will still have the same access to the other Spaces.

Is there a Guide on preparing our Confluence for this change? I'm thinking of what used to be called "hardening" of apps in Ye Olde Days :-) Any ideas welcomed. Thanks

Accepted answers

Ryan Goodwin

Hi David,

One idea I know other customers have used is to have a private wiki (which you already do) where the spaces for another instance of confluence, (public with anonymous access) is used as a publish site for those spaces. The publish add-on can be used, or space export/import can be used also:

https://marketplace.atlassian.com/plugins/com.comalatech.publishing

The public wiki needs only an administrator, maybe a space admin or two, and then anonymous access for all your public users. This would keep the license count need to the 10 user seat not really adding a substancial cost ($10 which is donated straight to charity ).

Then there is no sensitive information in the public wiki, it can be placed in a DMZ area with no connections to your companies super-secret wiki and should be very easy to maintain with the add-on or using scheduled space export/import and some simple scripts.

Hope this helps!

All comments

JohnA_xb3t2l

Hi David,

I don't believe we have any documentation for this but one method would be to use a web server or proxy to limit access to certain parts of the wiki as a further hardenning against external threats from the DMZ. For example, I would have thought that you could use Apache to prevent users from hitting any parts of the wiki that you don't want them to be able to access but I'm sorry to say that my knowledge of Apache isn't sufficient to advise on the exact configurations to use but the access control options should point you in the right direction.

Confluence provides relatively few tools to protect itself against external threats, so I would strongly recommend that you implement the usual hardenning approaches using external components to mitigate the threat before it is able to access the application.

All the best,
John

Matthew J. Horn

Check permissions and make sure that edit for all users is off.

Ryan Goodwin

Hi David,

https://marketplace.atlassian.com/plugins/com.comalatech.publishing

Hope this helps!

David Sidwell

Thanks again everyone. It seems the requirments are changing and we are now looking at a subset of the pages and using Confluence on Demand. Watch this Space (see what I did there?)

I'm not across the Karma system fully, so apologies if I haven't done the right thing via you kind people.