Turn off IP logging
-
@nichu42 Ah ok. So, from the page, "Therefore, it makes sense to either completely deactivate this logging and only activate it if necessary (error analysis) or to delete the log files as soon as possible" . FWIW, the logs are removed in 14 days - https://docs.cloudron.io/system/#logs . If that fits your definition of "as soon as possible"
-
Just to be clear (there’s sooo much confusion out there about the GDPR): There‘s no requirement to turn off IP logging or any fixed limit how long to keep such logs. The cited article is one, rather extreme position.
As a service-provider (Mastodon instance) you have a „legitimate interest“ to keep such logs for the necessary time for debugging, identifying spam, fraud, hate speech and the likes. „Necessary“ depends on your setup and risk profile. One can even be required to keep logs for a while to effectively address such issues if they surface regularly.
https://www.termsfeed.com/blog/gdpr-log-data/ gives a good overview on the basics. -
@girish I am helping a small group of exiled human rights activists here in the EU and would like to provide them with a Matrix/Synapse server on my Cloudron for their internal communications.
They work specifically on human rights abuses in their home country, which is an authoritarian regime outside the EU with a track record of attempting to identify exile activsts and punishing their families in the authoritarian country for their activities.
The activists are concerned that if the authoritarian regime gained access to the server, the stored IP addresses could be used to identify them.
Maybe this is all too hot for Cloudron to handle, but for this risk profile it would be really nice if I could disable IP logging, so that the activists could use the server without information that could lead back to their real world identities being stored there.
-
@tomw
There is always the option of extra "security" measures like using a VPN for hiding your IP.
And there are VPN providers which do not even need an account or identification for the payment.
e.g. https://mullvad.net/en where you could send a letter with X money and the generated account ID to pay in advance. (or pay via. Crypto).Generally speaking, the described concern is more about education on OPSEC.
There are great people at https://www.ccc.de/en/ who would help you to regard all of these topics. -
@tomw I think for absolute anonymous communication the product has to be built from the ground up with this in mind. Logs are just one place where the IP is logged. Many apps also store IP and login related information in the databases, caches (in fact, cloudron itself does this to track previous login attempts). I think that use case is best served using other products.
@BrutalBirdie even with a VPN, if you have access to the server, you can change the frontend and backend of the app in creative ways. Maybe the frontend sends some browser fingerprint, the backend can be changed to dump raw password etc. Anything is possible if you have access to the server. I doubt such a product exists though.
-
Perhaps it's time to consider running the apps they use on Tails OS https://tails.net or use it to front the Cloudron system.
-
@girish I hear what you're saying. At the same time, given that all requests to the various apps pass through nginx (if we just consider apps running on port 80/443 for now), isn't there an opportunity here to obfuscate the IP addresses with a fairly simple nginx config change?
VPN is certainly a good idea for these users too.
-
A huge +1 to what @girish said: you and your friends need to think about what it means to secure yourself against a hostile nation-state.
(You might just strike the word "hostile," and leave "nation-state" unadorned.)
https://antigravitymagazine.com/feature/digital-security-for-activists/
and other similar articles (look for authoritative sources in this space where possible -- those seem "OK" but are only a start) are going to help you game out just how paranoid you need to be. And in this case, "paranoid" means "what do we have to do to keep people out of jail and, possibly, alive?" It is a level of paranoia I do not
typicallyever operate at, and I suspect, neither do you. (That's not a slam... just that most of us don't operate there on a day-to-day basis.)For a lighter (but still not really wrong) take, James Mickens is always a potential inspiration:
https://www.usenix.org/system/files/1401_08-12_mickens.pdf
Although it is a light-hearted take, Mickens is getting at just how complex cybersecurity is. You're exploring a space where the consequences of failure/poor choices are going to cost your friends dearly. This is more than just a "simple nginx config change" that you need to make in order to create a secure communications space for people who might be targeted by their home country's internal police/intelligence forces. You need to think about your threat vectors front-to-back, as this is about more than just the tech. It's operational security from the start to end.
Or: XKCD's comic "Security" now applies:
If your solution is susceptible to someone being beaten with a wrench to yield enough secrets and access to unlock all of the comms and, in doing so, expose everyone else in the comms ring, you're doing it wrong.
-
@jadudm so let me get this straight...because switching off IP address logging is not sufficient to protect against a determined nation-state actor, we're just going to leave it switched on?
Earlier on, @girish asked why one would want to turn off IP logging. I have given a very good reason.
Let's turn the question around: what business do I have logging the IP addresses of human rights activists on my server? Why do I need to collect this information?
-
@tomw said in Turn off IP logging:
isn't there an opportunity here to obfuscate the IP addresses with a fairly simple nginx config change?
You can try adjusting the logs at
/etc/nginx/nginx.confper https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ and see if it suits your needs. Currently, the nginx log file is overwritten on a Cloudron update. But it's a start to not log the IPs altogether. The apps also learn about the client IPs from X-Forwarded-* headers in/etc/nginx/application/*.But as mentioned, we haven't tested this from a security point of view at the platform level. Let us know what you find
-
Given the context, it's probably also worth noting that it's currently technically not really possible for Matrix to fully implement GDPR's Right of Erasure. See https://matrix.org/legal/privacy-notice/
That doesn't mean it isn't GDPR compliant, it is because they've made the technical limitations clear in that link above.
-
@tomw Apologies; I wasn't trying to suggest you shouldn't do this. I was only trying to emphasize that there is an entire system/chain that leads to your server.
You might have:
- The nation-state working in tandem with local (or, are they state-owned?) ISPs to implement man-in-the-middle cert attacks, so that attempts to securely connect to your server are actually plain-text.
- The nation state, working with ISPs to compromise/log all traffic through DNS servers.
- ...
https://www.cisa.gov/news-events/alerts/2015/04/30/securing-end-end-communications
is an article that speaks to some of the kinds of things that you might have to do to begin securing end-to-end communications.
Ultimately, I really don't know. I'm just suggesting---YMMV, etc.---that this sounds like something with high stakes.
I wish you and your colleagues all the best of luck.
PS. https://www.cjr.org/tow_center_reports/guide_to_securedrop.php looks interesting as well. Again, it doesn't apply directly to your case, but speaks to the broad spectrum of design considerations that go into architecting and delivering secure systems, where "systems" means "a combination of technology and people."
