Is it possible to track the files users are looking into? i.e. if they look at an image or document?
Some background info: We are running a nextcloud instance having some users which we’d suspect doing bad things - so auditing what they do would be the basic idea.
With files_downloadactivity, it tracks if users view or download (though it calls them both “download”) when shared through a public link. However, I don’t think there’s a way to track what a user looks at if they have an account on the cloud. I start to wonder if they have an account and they’re suspected of doing bad things, why do they have an account on your system?
Or if they have an account, then why do they have access to files they should not be looking at?
files_downloadactivity sadly doesn’t track things like pdf files viewed in the pdf viewer - or images.
The users we are talking about are part of a community using the nextcloud server for storing/exchanging info. I just cannot ban users without some hard facts - but that’s out of scope of this discussion.
Hm. I’m still not clear on your scenario. I just tested a public shared link to a PDF file, which immediately displayed in the PDF viewer. It then showed as “downloaded via public link” in the activities. Again, this only applies to non account holders accessing files through a public link.
Are you trying to track what non users are viewing, files that were shared outside? Or are you trying to track what logged in users are viewing?
It really doesn’t make any sense to track what logged in users are viewing because you can already look at what files are stored in their accounts on your server. Or you could set up automatic tagging rules based on file names or file types or other options, to prevent it from being uploaded to your server in the first place.
By the way in Nextcloud 12, you can masquerade as any user and browse their files. You can also look at the activity to see the history of which files were added, moved, and deleted. Maybe that gives you enough information?
If you can judge the IPs these users are coming from, the Apache access.log (or other_vhost_access.log depending on your setup there) will output every request made, for example:
cloud.server.org:443 148.45.74.46 - - [09/Jun/2017:19:28:33 +0000] "GET /apps/files/ HTTP/1.1" 200 8304 "https://cloud.server.org/apps/files_pdfviewer/?file=%2Fremote.php%2Fwebdav%2FDocuments%2FDefending%2520Office%2520365%2520Against%2520Denial-of-Service%2520Attacks.pdf" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"
The above refers to me opening a file named Defending Office 365 Against Denial of Service Attacks.pdf in Documents
It’s not an app within NC, granted, but it’s an option.
@linucksrox you’re putting too much thought into this, I wouldn’t expect @ToeiRei to divulge any more info. @ToeiRei wants to see when a file is accessed, hence:[quote=“ToeiRei, post:3, topic:13842”]
like pdf files viewed in the pdf viewer - or images
[/quote]
And: [quote=“ToeiRei, post:1, topic:13842”]
track the files users are looking into
[/quote]
Suggest it’s users, not guests. This is like an audit.
Sorry, I didn’t realize I was asking too many questions… I don’t understand how I’m asking for too much information, and I don’t understand why you would say that you wouldn’t expect @ToeiRei to divulge any more info… why not?
I think the answer I gave about masquerading as a user and looking at their activity history provides some valuable information.
I just don’t understand the question of what files users are looking at. If the files are in their account, can’t it be assumed they have looked at them? Therefore shouldn’t we just monitor which files are in the user’s account?
Activity history doesn’t show files opened, at least for me, only those created/modified. It’s opening that’s of interest here though if they are creating files that’d be fine.
Likely a community shared folder and someone has done something with information inside a file they shouldn’t have (shared it publicly, or something)
Maybe Piwik is a Solution?
@JasonBayton: that was the original attempt I am coming from. I ended up with hacking up a PHP page for filtering the access log on rotation sending me a report in some useable (read: Management readable) form.
@linucksrox: I was asking for some technical solution and it looks like you’re trying to understand the motivation behind. Imagine a situation where you’d have to share for the reason being shared and nobody actually looks into except for special cases. - i.e. a user browsing a shared document containing emergency phone numbers might actually have a problem and it could come in handy. In my case I am not allowed to disclose more info about why I need that stuff logged. But I am sure you can use your imagination.
@Lars_M: Piwik iis a bit too big for that job which is basically some grep/awk and a logfile. As we’re already having download-activity as a plugin I’d suspect it shouldn’t be hard to hook into the API there extending that a bit if possible…
I hope I wasn’t annoying. You asked an interesting question that I haven’t seen asked before and I was just curious to know more about how and why it would be useful.
Maybe they will extend the download activity plugin like you suggested, but for now scanning the Apache access log sounds like the best option.
Increase the level of details of the logs (of Nextcloud as well as your web server software, maybe also the firewall etc) and send them to a log analysis tool like Graylog (Open Source) or Splunk (not Open Source) and then you can write some rules to find out all the instances where certain users share unauthorized stuff. This is a bit of work, but it is easier to than going through logs manually in the long run.
You can do the log analysis manually, of course, but it is a lot more hassle.
You can do this with the auditing feature in Nextcloud, see the datasheet on this page. Enable audit logs, increase the log level and use a tool of your choice to search through the logs.
Here is also an app that does exactly this, but still not bumped to Nextcloud 12: