Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add warning about docker iptables behaviour #24

Open
wants to merge 2 commits into
base: next
Choose a base branch
from

Conversation

tnaegele
Copy link

@tnaegele tnaegele commented Mar 2, 2024

Docker creates by default iptables rules at startup which expose the elabftw container to the public. This also overwrites rules set with packages such as ufw (installed for instance by default on Ubuntu server). While this is not an elabftw specific behaviour or a bug it might take unexperienced users by surprise and create security issues.
Hence add a warning to the elabftw docs and link to the relevant page of the docker manual.

@NicolasCARPi
Copy link
Contributor

@tnaegele
Copy link
Author

tnaegele commented Mar 3, 2024

Hi Nicolas,
It's your call but I think the default behaviour of docker drilling through existing firewalls is to users who are new to the docker universe really non-obvious. I have witnessed it multiple times now with colleagues who set up restrictive firewall rules but didn't realise that they accidentally exposed their elabftw installations to the world. It think it might be good to include some form of warning / note similar to the one in this PR to the docs were it is more prominent than a note in the dev section of the compose file. What do you think?

@NicolasCARPi
Copy link
Contributor

I'm not against adding such a warning, but I'd suggest re-wording it. Keep in mind that this documentation must be understandable by a beginner.

iptables rules

They don't know what is iptables.

behind a firewall.

"behind a dedicated firewall" or "external" maybe, just to make it clear we're talking about something else than the FW of the VM.

Consider manually creating some rules on the DOCKER-USER chain if you want to restrict access

Nope, that is way too confusing and too advanced for the doc. If you don't know what is iptables, the "DOCKER-USER chain" is incomprehensible linguo, too.

What we want is make sure users understand that there is a risk that their service will be exposed to the world. So the wording could be changed to:

Warning: your eLabFTW instance will be exposed to the whole world if you simply expose the port, as Docker will punch through your firewall, unless you use '127.0.0.1:443' instead of just the port '443', in the "ports:" section of the configuration file.

This way the "solution" is the same in doc and config file, and we don't ask users to fiddle with iptables chains.

We might even add another warning in the post install doc, with a full section describing this issue, that they'll want to test if their instance is available from another network.

The main issue is that the public for these docs are:

  • complete linux noobs
  • amateurs linux admins
  • pro IT staff but docker noobs
  • pro IT staff but linux noobs (windows staff basically)
  • linux gurus

So we must balance the level of information given, especially on the main install page, it should not be overwhelming. So in fact, I suggest this instead:

  • on install doc: add warning: "If you do not want your eLabFTW instance to be accessible to the whole world (recommended), make sure to read this section". And it links to that section in sysadmin doc about this moby bug and what can be done to fix it, with the link you added + github issue, and we can take the time to explain precisely what could happen, with pictures and all why not.

@tnaegele
Copy link
Author

tnaegele commented Mar 5, 2024

Sounds like a good plan. Do you think it would make sense to change the port allocation in the default compose file to '127.0.0.1:443' such that the users have to actively modify it to expose their installation?
Anyway, do you want me to draft the documentation text in this PR or do you want to take over from here?

@NicolasCARPi
Copy link
Contributor

Do you think it would make sense to change the port allocation in the default compose

Maybe as an example (commented out), but the default must stay the "works out of the box" configuration.

do you want me to draft the documentation

Yes.

@NicolasCARPi
Copy link
Contributor

@tnaegele still interested in finishing up this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants