Hey everyone, in the European Union, a new law will be applied starting of May 28th, 2018. It's a relative to the GDPR, the "General Data Protection Resolution", and harshly restricts the collection of data. To be on the safe side, I would like to completely disable logging on apache, so that no log files are written at all. However with 20 different sites on my ISPConfig, I refuse to believe that I have to edit 20 different vhost entries. Is there a more "General" solution to this? Thank you in advance Kind Regards Sascha Schroeder
Apache Access Log: Comment out the CustomLog line in the apache ispconfig.conf file and restart apache. Error log: Comment out the error log line in the vhost master template file in /us/local/ispconfig/server/conf/ and use Tools > Resync to apply it. Nginx Comment out the log lines in the nginx vhost master template in /us/local/ispconfig/server/conf/ and use Tools > Resync to apply it. For all changes: To make them update save, copy the modified template file to conf-custom folder.
Hello till, thank you, this is perfect. Now I am pretty sure to fulfill the new regulations, because I will no longer gather any data of my visitors
By default, logging is not turned off as web statistics won't work anymore without logging and you won't be able to debug any PHP errors in websites without error log. But I explained in #2 how to turn it off.
+ Well and exactly there's the Problem. According to GDPR and other data privacy laws, it is forbidden to log ANY IP address. Therefor, this HAS to be disabled by default. Web statistics DO work if you use other tools than the ones provided by ISPConfig (Matomo for example). The law is not trivial, but if you want to follow it to the tee (and prevent being sued), then you have to do exactly this!
If I understand it correctly, GDPR states that you have to take all possible and state of the art measures to protect personal data and to ensure that personal data does not get stolen from your servers. To defend against brute force attacks on passwords which would allow hackers to steal personal data from your websites, databases and files, you have to log IP addresses. For DDOS prevention, you need IP addresses as well. Storing personal data, and an IP address is personal data, is in line with the GDPR if it's technically required to provide a given service. Otherwise, you also won't be able to e.g. secure sessions in websites or REST API's anymore with an IP lock too. I'm not talking about sharing an IP with others, of course, like you would do when using Google analytics without anonymization or doing anything else with that IP addresses than securing your server. The law, as far as I've understood it is not that explicit as you state it above and it might even be necessary to log IP addresses to comply with the GDPR to ensure that the data on the server is safe from attacks. Also, other law might override GDPR here. I guess we will not know if logging on servers is disallowed completely before the first court decisions were made in future. But if your server does not hold any sensitive data and you want to be 100% sure that your data use is in compliance with the GDPR, then you should turn off logging at all. But be aware that this always comes at the risk to breach other laws, even the GDPR itself, by not taking safety measures against losing personal data. That said, I'm not a lawyer and this is not legal advice. You might want to contact your lawyer if you need an advice on how to configure your server. If someone has an article form a lawyer that states that logging has to be disabled in any case, even when you risk to lose personal data due to that, then please post that link.
ISPConfig is less or more GDPR compliant. That's my opinion. However, alot of things are still unclear and how it should be done in practice. For example encrypted backups. Are they really necessary? Only time can tell us the not-so-obvious things and how the courts or the European Parliament will adjust the GDPR after taking effect. Regarding the Vhost logging (apache/nginx) the GDPR permits website logging for security reasons for a short period of time. One week should be absolutely safe, maybe also two weeks, but probably not longer though. The GDPR enforces sparingness but it does not prohibit data collection completely. Especially when it is required due to security reasons. All the other server logfiles (ssh logins aka secure log, maillogs, pure-ftpd etc) can be adjusted by the server admin by configuring logrotate accordingly. ISPConfig is not involved in this part... Maybe we should do a listing of features where ISPConfig is already GDPR compliant and in which points it is not?
That's a good idea. I started a similar post in the bug tracker about a week ago, were a user contacted me privately regard to GDPR. I made that post publicly visible now, you can find it here. It might be a good starting point. https://git.ispconfig.org/ispconfig/ispconfig3/issues/5003 I found already a vlogger patch that adds IP anonymization, this is one part that I would like to integrate as an option in the next release. Plus the ability to turn off logging completely, for those who want to do that. In addition, we should make the 30-day log rotation time for the weblogs configurable, so that one can reduce it to 7 or 14 days to stay compliant.
Are there any texts only that state this? Because whenever I search for how long I am allowed to store this data for security reasons, I come up empty handed. Thank you in advance.
Here we go: https://www.it-recht-kanzlei.de/faq-datenschutz-grundverordnung.html#abschnitt_172 In one of the iX or c't releases this year the same has been stated. Using the access_log is simply not forbidden. You need it for securing or improving your website. If both don't affect you then you certainly should better not use access logs... However, keeping access log files for a long time is not permitted, DSGVO/GDPR emphasize and actually enforces data sparingness. A FAQ or summary listing on the ISPConfig website might be the better choice, since the majority won't look into the bugtracker (most likely). But for the moment - while couple of things are in planning/development state - it should be sufficient to have these things in the bugtracker. IP anonymization should be optional and selectable in the backend by the client. IP anonymization for NGINX seems to be natively supported via the mapping module, see: https://stackoverflow.com/questions/6477239/anonymize-ip-logging-in-nginx Regarding "rotation time": I've contributed a logfile retention few months ago, but I think this feature could be improved. Currently only users with the permission to access the "option" tab can change the retention. This should be accessible by the user later. So, moving this feature to another tab might be better. Maybe we should create a new tab called "Log files and data privacy" for things like this? Dunno... There still is the question if backups need to be encrypted, or if this is optional. Otherwise ISPConfig will need the possibility to encrypt its backups.
That probably quite expensive in regard to computing time, but the important thing is that it's possible You're right, this feature exists already. Totally forgot that at the time I wrote my post That's a good question. My guess is that this refers more to backups that you might do on a USB stick or hard disk locally as I don't see any security benefit to encrypt the local server backups as the security level is basically the same on the backup server system and local system and the server needs to know the key to encrypt the data anyway and the backup drive has to be mounted by the server to do the backup.
What would happen with the rest of programs? I'm thinking in example in syslog. There are solutions although not too much information: https://moblog.wiredwings.com/archives/20130214/linux-anonymize-ip-logs-with-syslog-ng.html I don't know of any guide to avoid ip logs in a linux system in a complete way. Any contribution would be interesting to know Anyway, absence of logs can have a double side regarding privacy and security. It would be better adding a second option with pubilic key encryption.
Other logs like syslog are not managed or written by ISPConfig, so they are not in the scope of functions or functionality provided by ISPConfig. As @exynenem and I pointed out above, the GDPR does not forbid logging of IP's in our opinion (and in the FAQ text from the lawyer that is linked above), it just says that you must have a good reason to do that (and security of private data held on that system should be a good reason, you can not really defend the server with anonymized IP addresses) and that you do not keep the log longer as absolutely necessary for that purpose, which means that you should consider modifying the logrotate config of your Linux system to keep logs for a short period only. @exynenem posted a link from a lawyer that explicitly states that logging of IP addresses is ok when it is necessary to improve the stability and functionality of the website and I guess the same applies to ther services like email, ftp, etc too. E.g. without IPlogging, you won't be able to use postgrey anymore. According to the lawyer "This constitutes a predominant legitimate interest of the online merchant in their storage and makes them harmless in this respect.". But it is required that you inform about that fact in your data protection declaration. That said, I'm not a lawyer and this post is my personal opinion and not a legal advice.
by the law you need that log's!!!?? In case of invasion of a website for example you need to comunicate the source of attack!?!
I guess all users outside of the EU will call us mad if the read this thread One more thing, not specific to ISPConfig but it might affect most mail systems. What about using RBL (Real-time Blacklists) in mail systems? Or is the fact IP = private data limited to HTTP clients, I don't think so, but who knows. If not, then a mail server owner might need a data processing contract with each RBL provider. Has anyone read something about this aspect on a reliable source?
Interesting question. An IP could be an IP of a mailserver where - I think - it's uncommon to link it to just one single person. Also Dialin-IPs are in most cases not fixed to one internet access/contract (of course this does exist, but you know the majority...) so it's difficult to connect one dynamical IP to a single person. I don't think that one would need a processing contract with each RBL provider he/she is using. However, this entire processing contract thing can be really driven ad absurdum if you ask me... I do also wonder if a company needs a data security officer, because of the emails that are being processed for the customers. In Germany a company needs a data security officer when it has more than 10 employees, but the DSGVO aka GDPR also says here in Germany that a company with less than 10 employees would also need a data security officer because of personal data processing and by that I would assume that mailboxes are being counted as this too.
I read on that topic yesterday too and I'm still not completely sure. In my understanding, the 10 employee rule would be void if you either process sensitive data like medical data, or when you use data to score persons (e.g. SCHUFA in Germany). I would not put email receiving, sending and storing in this extra sensitive area as you don't actually process these emails in form of analyzing or working with their content nor do you request such information from your clients, so I would say a mail system owner with < 10 employees needs no data security officer. I guess this will be different if you would e.g. analyze the email content to show ads based on the topics of the emails as your business model. Thus said as I mentioned above, this is my personal opinion based on my current knowledge of that topic and no legal advice, so I might be completely wrong here.
thanks for these news and expanded information. Just I wonder about the scope and real purpose because at least I doubt the ips aren't logged in another level of the ISP or nodes, while sysadmins will lose useful information to check attacks and intrusions. A better idea would be some public/private encryption schema with encrypted chains, then available to be processed later in statistics, security and etc. I wonder if this would be legal while no ip's are stored. This wouldn't be difficult to implement for stored logs with some script. Problem is with those logs in real time. In example, there is this Debian module for Apache2 able to anonymize ip's by overwriting the REMOTE_ADDR variable with a fixed value: https://packages.debian.org/wheezy/libapache2-mod-removeip although I have never tried. No idea. It would be nice having a similar thing to encrypt the ip's in a public/private schema For statistics there is also Matomo(Piwik) without logging the complete ip's: https://matomo.org/privacy/
I don't think that encryption of logs would make a big difference here. When an encryption is reversible, then you own the data as you are able to retrieve the IP addresses after decrypting the log and when you own them, the GDPR gets applied. Beside that, I guess encryption of logs in real-time would use up a lot of CPU power.
