SOLVED Nextcloud and OnlyOffice; Who can access the Document Server

[dnilgreb]

On my primary NAS, I have a Nextcloud jail I´ve had running for years. Yesterday, I finally got OnlyOffice up and running, with a Document Server set up on my Backup NAS, with its own dns, certificates and all. Works great, and I´m happy..
One question: The document server is on a public DNS, so I guess anyone can browse to it. Which means, I guess, that anyone could use it without my knowledge?
How can I protect it? Do I need to? Can I set it to only accept traffic from my Nextcloud instance somehow? Or should I just leave it open? Don´t feel too good about that...

It´s running on an Ubuntu VM, in a docker container. The web server is nginx.

Excuse the rookie level of this question, I just don´t know how else to put it....

 

[KevDog]

Hi @dnilgreb

What's funny is I didn't even think about this issue when setting up my own nextcloud/onlyoffice combination. I have nextcloud actually running within a FreeNAS jail and the OnlyOffice running on an Ubuntu VM (within FreeNAS) in a docker container.

I first did a search about OnlyOffice security and only came across this post: https://api.onlyoffice.com/editors/security. It mentioned a jwt token (more on this below). The remainder of the of the onlyoffice setting interface within nextcloud doesn't really have any additional settings short of the "Secret Key) option -- which honestly I thought was really really weird. I was looking for something like OpenSSL client/server certs but didn't see how this could be implemented.

So just defaulting backing the jwt Secret Key option. I'm assuming your using a docker-compose.yml file to configure your only office document server. Within my compose I have the following:

environment:
- TZ
- ONLYOFFICE_HTTPS_HSTS_ENABLED=false
- JWT_ENABLED=true
- JWT_SECRET=<secret token>
- JWT_HEADER=Authorization

Where <secret token> is a string or password like: foo, foopass, 38$*$(#()#(#FJ, etc. Whatever the value of this string, I entered it into the nextcloud OnlyOffice settings under the field labeled "Secret Key". If you need to make these changed make sure you restart your docker onlyoffice container to pick up the changes.

So in a nutshell, your OnlyOffice is only protected via a password, doesn't seem to be anything else.

 

[dnilgreb]

Hi @dnilgreb

What's funny is I didn't even think about this issue when setting up my own nextcloud/onlyoffice combination. I have nextcloud actually running within a FreeNAS jail and the OnlyOffice running on an Ubuntu VM (within FreeNAS) in a docker container.

I first did a search about OnlyOffice security and only came across this post: https://api.onlyoffice.com/editors/security. It mentioned a jwt token (more on this below). The remainder of the of the onlyoffice setting interface within nextcloud doesn't really have any additional settings short of the "Secret Key) option -- which honestly I thought was really really weird. I was looking for something like OpenSSL client/server certs but didn't see how this could be implemented.

So just defaulting backing the jwt Secret Key option. I'm assuming your using a docker-compose.yml file to configure your only office document server. Within my compose I have the following:

environment:
- TZ
- ONLYOFFICE_HTTPS_HSTS_ENABLED=false
- JWT_ENABLED=true
- JWT_SECRET=<secret token>
- JWT_HEADER=Authorization

Where <secret token> is a string or password like: foo, foopass, 38$*$(#()#(#FJ, etc. Whatever the value of this string, I entered it into the nextcloud OnlyOffice settings under the field labeled "Secret Key". If you need to make these changed make sure you restart your docker onlyoffice container to pick up the changes.

So in a nutshell, your OnlyOffice is only protected via a password, doesn't seem to be anything else.

Hi,

Thanks. That was really interesting. Added the same lines, with a secret with 20+ characters, all a-z, A-Z, 0-9. I then ran docker compose again. Now NC can´t connect without the secret key, which is correct. But it can´t connect with the key either. I see the key gets populated into the file:

Code:

/etc/onlyoffice/documentserver/local.json

Does it need to be entered somewhere else as well? Or do I need to do something else?

 

[KevDog]

@dnilgreb
Can you post your compose file or section for the openoffice server?

 

[Heracles]

Hey @dnilgreb,

I noticed that when I first installed my OnlyOffice Document Server. To protect it better, I enforced SSL Client authentication in the HAProxy instance I have in front of it. Should an access be from the Nextcloud Server, from my internal network or my VPN, HAProxy will let one reach the document server without any other requirement. Should one comes from outside and directly over TLS, HAProxy will not let him in without a client certificate signed by my own private CA.

That way, it is impossible to reach and attack the document server from Internet. It is also 100% transparent for the Only Office Document server itself, as well as for Nextcloud and other apps that does not support client certificates but are used from inside my extended network (local or VPN).

 

[dnilgreb]

I think I solved it. I noticed that i local.json, the key was in format:

Code:

<mysecretkey>

So, in Nextcloud Settings \ ONLYOFFICE \ Secret key field, I changed from

Code:

mysecretkey

to

Code:

<mysecretkey>

Now it works.

The Onlyoffice welcome page still seems to be accessible from the Internet (SSL cert in place). Does that matter? Nobody should be able to use it now right? Anything else I should worry about?

 

[Patrick M. Hausen]

The Onlyoffice welcome page still seems to be accessible from the Internet (SSL cert in place). Does that matter? Nobody should be able to use it now right? Anything else I should worry about?

Nothing to worry according to my knowledge. The OnlyOffice application must be publicly accessible if your Nextcloud is. There will be a session from every user's browser to the OnlyOffice container! This is why you need a complex shared secret for NextCloud and OO.

 

[KevDog]

Hey @dnilgreb,

I noticed that when I first installed my OnlyOffice Document Server. To protect it better, I enforced SSL Client authentication in the HAProxy instance I have in front of it. Should an access be from the Nextcloud Server, from my internal network or my VPN, HAProxy will let one reach the document server without any other requirement. Should one comes from outside and directly over TLS, HAProxy will not let him in without a client certificate signed by my own private CA.

That way, it is impossible to reach and attack the document server from Internet. It is also 100% transparent for the Only Office Document server itself, as well as for Nextcloud and other apps that does not support client certificates but are used from inside my extended network (local or VPN).

When doing Client certs, I take that you imported your client certs into your browser?? Why I'm asking is that Nextcloud to my knowledge doesn't pass client SSL certs to the OpenOffice Backend. I have an nginx reverse proxy in front my OnlyOffice container which passes http to the container.

 

[Heracles]

Hey @KevDog,

Indeed, I had to inject my client cert in my browser. And you are right that Nextcloud itself does not offer you to control that certificate nor can it use one to connect to another server like OnlyOffice.

Everything SSL-related here is handled by HAProxy :
Client certificate or not, everyone connect to HAProxy and handshake SSL with that one.
HAProxy asks for a client cert and if you present one, it will evaluate it.
Once the handshaking is over, HAProxy evaluate the access as requested by the client.
Is a cert required for that service ? Is a cert required from that IP ? Did the client presented a valid one ? At the end, if you are allowed, HAProxy will relay the request to the proper backend. If you are not allowed, HAProxy will reply to you with an HTTP 503 (Access Denied).

Because everything is handled by the frontend, neither Nextcloud nor OnlyOffice are aware of it. They know there is an SSL proxy in front of them and that they most send HTTPS URLs, but they do not process any SSL directly. As such, one way or two way SSL, they do not care.

 

[Basil Hendroff]

By using a combination of split DNS and a DNS challenge for obtaining certs, you can avoid exposing the OO server to the internet. The principle is as follows:

Using split DNS, you have internal DNS records for the OO and NC server. This makes both servers accessible on the local network. You have a public DNS record for the NC server only. This allows you to locate the NC server from the internet. As there's no record of the OO server on the external DNS, it won't be found directly. however, it is still indirectly available through NC.

Secondly, use a DNS challenge, rather than an HTTP challenge, to obtain a cert. A DNS challenge doesn't require any open ports, and the server requesting a certificate does not need to be externally accessible.

 

[KevDog]

Hey @KevDog,

Indeed, I had to inject my client cert in my browser. And you are right that Nextcloud itself does not offer you to control that certificate nor can it use one to connect to another server like OnlyOffice.

Everything SSL-related here is handled by HAProxy :
Client certificate or not, everyone connect to HAProxy and handshake SSL with that one.
HAProxy asks for a client cert and if you present one, it will evaluate it.
Once the handshaking is over, HAProxy evaluate the access as requested by the client.
Is a cert required for that service ? Is a cert required from that IP ? Did the client presented a valid one ? At the end, if you are allowed, HAProxy will relay the request to the proper backend. If you are not allowed, HAProxy will reply to you with an HTTP 503 (Access Denied).

Because everything is handled by the frontend, neither Nextcloud nor OnlyOffice are aware of it. They know there is an SSL proxy in front of them and that they most send HTTPS URLs, but they do not process any SSL directly. As such, one way or two way SSL, they do not care.

Thanks for explanation. I started down the client cert path for a short bit about a year ago but honestly just found it easier to use a VPN to access the internal Nextcloud server. I remember some vague issues with difficulties importing these certs into the Apple Keychain and I believe Firefox browser might use its own keystore. All in all it just became kind of a pain. I've implemented client certification validation on HAProxy, nginx and traefik. They all seem to work the same.

 

[Heracles]

I've implemented client certification validation on HAProxy, nginx and traefik. They all seem to work the same.

Indeed, they all implement the same standard. Kind of normal for them to have the same requirements

You are also right that there are many different key stores here and there and that you may need to inject your certificate in a few of them.

Still, there are cases where VPNs are not possible and are blocked by the network you are connected to. It may be your workspace, an hotel, a public space, etc. This is why I use both : VPN is configured on my mobile devices for ease and greater protection. For other devices like my corporate laptop, I injected a dedicated certificate in that one and connect my cloud safely from it, even from inside the corporate network.

 

[Patrick M. Hausen]

By using a combination of split DNS and a DNS challenge for obtaining certs, you can avoid exposing the OO server to the internet.

You sure that will work? Not in principle, of course - the split DNS stuff and using DNS instead of HTTP challenge is all fine.
But the point of Nextcloud and OO is to connect to Nextcloud over the public Internet (and hope users are using a trusted frontend, only ...) and being able to use "Office style" things in the browser.
At least in my installation here the browser opens a dozen of connections directly to the OO server, so it seems it must be accessible.

No?

Kind regards,
Patrick

 

[Basil Hendroff]

You sure that will work?

You're right! I stand corrected. I just checked. I do have public DNS records (and shared secret keys) for both Collabora and OnlyOffice.