Alright, now I crashed it completely After changing it back and forth, All IPs are resolved to localhost. Like, I browse a site on my server, look at my Matomo instance and find the IP to be 127.0.0.0, even though it's a valid public IP. Any ideas what I crashed here? Please don't tell me I have to reinstall the whole system....
To all german speakers: The new "iX 5/2018" issue will have the DSGVO/GDPR as their maintopic. While the iX 1/2018 issue covered already the DSGVO with more website relevant things, the iX 5/2018 seems to cover more the behind the scene/server administration parts that are affected by the DSGVO/GDPR. Hope to find some good and useful read in this issue...
Very interesting topic. I jsut wanted to add a very useful link which gives the best summary about DSGVO I have found so far: https://www.golem.de/news/datenschu...und-admins-jetzt-tun-muessen-1803-133122.html Apart from that, does anyone have a clue how to deal with demands for data deletion for example? i.e. a website visitor, uses a customers website to demand the deletion of his personal details. Now the customer has to check what personal data of this visitor he has stored but in the end he'll end up asking the ISP to also delete logs - what do we do then?
That's a good question. Most likely one would need a kind of script to search for the IP in log files, to unpack archived logs, modify them and pack them again etc. But, this problem might never occur in real: if you set a short log period of e.g. 10 days and you have a timespan of 30 days to respond to a request (as far as I know), the whole logs are gone within 10 days, so you can safely reply after 2 weeks that the data has been deleted. But, can a customer request all lines with a specific IP to be deleted at all? I don't know, at least if it's a dynamic IP, then it can be that you have let's say 3 different customers that got the same IP within 10 days in your logs, so by following the delete request, you would delete the requests for 1 customer correctly but for 2 other customers you delete them in error. Ok, it probably does not matter for you if you delete too much from your log files though, just something to think about. What I find interesting though is if someone requests to receive data by giving you an IP as 'search' token for his personal data. What will you respond to that person? If he is not listed in whois as the owner of the IP, then your response might only be that he needs a certification of the ISP that owns this IP (in whois) that the IP was assigned in a given timespan to that person.... Just thinking about edge cases, so take this with a grain of salt. I really wonder which kind of requests users might send us in result to this new law...
All valid points Till and I must admit I have just done a 5 day course by TÜV as "Datenschutzbeauftragter" and I'm still struggling to answer certain questions regarding DSGVO. A lot of things are still unclear which we'll only know once the first rounds of law suites have passed
some of my customers have to store full logs for 7 days to allow crime investigations, eventually. After that all IPs needs to be anonymized or logs have to be deleted.
Then set the log duration to 7 days on the options tab of the website and ensure to update to git-stable regularly these days as we are constantly roll out GDPR related functions, or wait until 3.1.12 release which will be ready before may 25 as well.
@till thank you but yeah thank you I may update or just wait, doing nothing related to hosting just for customers to "manage" their servers. All set up just fine - from the server point of view lulz just mentioned it, since he talked with a lawyer aswell edit: aaand some advertising ... nah interesting source - unfortunally german https://www.datenschutz-guru.de/
I think all these time frames like 'delete after 7 days' or 10 days or whatever are just wild guesses from the lawyers and will be defined by court rules at a later time, I've not seen anywhere that the GDPR actually states a number of days for log files. And when you ask a lawyer, they will tell you the shortest possible time as you might sue them otherwise when their assumption of a valid timeframe was too long. In my opinion, the GDPR law just says to minimize the time you store personal data or in other words, don't store it longer as absolutely necessary and don't store data that you don't need to run the site or server safely. So if you e.g. have a good reason to store logs for 60 days and you really asked yourself if a third party will be able to follow your arguments, then you probably might store them for 60 days. This does not mean that I would do so or recommend such a long storage time. I just mean that probably nobody really knows what time is allowed or not at the moment.
yeah the 7 days is interpreted from this one I guess https://www.cr-online.de/blog/2014/10/28/bgh-bestaetigt-webserver-logfiles-nicht-nach-§-100-abs-1-tkg-erlaubt/
Basically, I find what @till said so far about this GDPR law makes more sense to me than any others that I have read.
@ahrasis Thanks! But please keep in mind, I'm not a lawyer and what I posted is just my opinion on that matter, so I might be completely wrong. Even if the GDPR is a European law, each country has made its own 'local' law out of it and the GDPR 'interacts' with many other laws that override it. Also, there seem to be huge differences between the countries. For example: the court decisions that @ztk.me posted are probably relevant for providers from Germany only while other European countries might have very different court decisions on that matter which I don't know. Another example: according to the opinion of several lawyers in Germany that I found on the net (just to name e-recht24 and it recht kanzlei), it is still fine here in Germany to just inform about cookies after may 25 in the way we do it already now. In other countries, it seems to be that you have to provide a cookie opt-in already. Here in Germany, the cookie rules are expected to change in 2019 when the new e-privacy law becomes applicable. But who knows what this will mean in the end as the law is still in the works at the EU.
If you are not a provider then IP addresses should not be logged at all or it should be shortened (and so be anonymized). Here is a quick solution on how to store shortened IP address in nginx & ISPConfig: Edit /etc/nginx/nginx.conf and in the http {} section add the following lines: Code: map $remote_addr $ip_anonym1 { default 0.0.0; "~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" $ip; "~(?P<ip>[^:]+:[^:]+):" $ip; } map $remote_addr $ip_anonym2 { default .0; "~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" .0; "~(?P<ip>[^:]+:[^:]+):" ::; } map $ip_anonym1$ip_anonym2 $ip_anonymized { default 0.0.0.0; "~(?P<ip>.*)" $ip; } Copy /usr/local/ispconfig/server/conf/nginx_vhost.conf.master to /usr/local/ispconfig/server/conf-custom/nginx_vhost.conf.master Edit /usr/local/ispconfig/server/conf-custom/nginx_vhost.conf.master, find the access_log line and replace it with Code: log_format anonymized '$ip_anonymized - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; access_log /var/log/ispconfig/httpd/<tmpl_var name='domain'>/access.log anonymized; Now in the ISPConfig amdinistration use Tools/Resync and resync the websites. Voilà - now the last octet in your IP address in the webserver logfiles will be replaced by a 0. Hope this solutions helps someone.... Best regards Carsten
ISPConfig has this already builtin, so no need for any manual configuration. Just enable it under system > server config.
ISPConfig 3.1.12 announcement says this feature is available: https://www.ispconfig.org/blog/ispconfig-3-1-12-released/
