Is there a way to restrict the coolwsd process of the built-in collabora server to localhost? I’m running NC 32.0.2 on Debian 12. ss -tulpn gives the following line:
tcp LISTEN 0 64 *:9983 *:* users:((“coolwsd”,pid=xyz,fd=16))
So it seems that coolwsd also listens on the public web interface. I think this isn’t recommended on a production system - how to change this?
listening on public interface is the only way it works. please familiarise yourself with the WOPI protocol e.g. read references in Collabora integration guide
hmm - ok, I see that Collabora should be accessible from outside. But this doesn’t necessarily mean to expose the service itself to the unrestricted public, for example using a reverse proxy. Wouldn’t it be better to expose just the proxy and hide the proxied services?
yes but localhost is only accessible local.. as you didn’t share the required support template nobody can tell you what is wrong with your setup
For such an abstract issue, there’s obviously no need for the support template. I didn’t ask for help with a “wrong setupt” but for hints how to secure the built-in CODE server. And yes, i know that localhost is only accessible local - that’s perfectly fine if the reverse proxy sits on the same machine and makes local services publicly available without exposing them directly to the whole internet. That’s a common use case for reverse proxying.
I’m sorry if you already aware how to setup the system right you likely don’t need any help from this community.. otherwise please follow the rules.
I use Collabora as a Docker container, so I’m not sure where the configuration file is located for non-Docker installations. But setting net.listen to localhost should do the trick 
It is possible for a coolwsd server to bind to localhost only, which makes sense, when it is used behind a reverse proxy. The corresponding setting is
net.listen.
https://sdk.collaboraonline.com/docs/installation/Configuration.html#network-settings
Thanks a lot! Sadly, it seems that the built-in CODE server doesn’t use those config settings (at least, there’s no coolwsd.xml anywhere in the file system). It seems that using docker is the only way to put the CODE server behind a reverse proxy, and the “built-in” server shouldn’t be used in productive environment.
There is a feature request, but I think it is very unlikely that it will be implemented, as a separate Collabora installation is also recommended there:
https://github.com/CollaboraOnline/richdocumentscode/issues/209
I can also recommend switching to a separate installation of Collabora anyway, because the non-build-in versions usually perform better. For example with Docker.
This is also what Nextcloud recommends:
Built-in CODE server: This is the default option which works out of the box in most scenarios, however for improved performance it is highly recommended to switch to a dedicated Collabora Online installation using one of the other options.
https://docs.nextcloud.com/server/stable/admin_manual/office/installation.html
(I also find the way the built-in Collabora version works a little dirty. I find it very uncommon that PHP is used to download and execute a binary on the host system. Depending on the PHP setup, for example in shared hosting, this may not be permitted at all.)
This does not address the underlying issue. However, to mitigate the problem, you could install a firewall on the host, such as UFW, and only allow the ports required for Nextcloud to work (e.g. 80/443).
By the way, if you host your server behind NAT (e.g. at home or in the office) and have only forwarded ports 80 and 443, then only these ports will be accessible from the internet. Nevertheless, the firewall could still be useful for preventing access to other ports from the LAN side.
EDIT: If you need to administer your server remotely, remember to allow port 22 for SSH as well, so you don’t end up locking yourself out. 