Everything is flagged as suspicious

[Pingger]

Hi,

I'm currently experiencing the issue, that every single connection is flagged as suspicious!
Even:

• 127.0.0.1
• The IP of the initial setup
• The Servers own IP

My logfile is literally multiple gigabytes large and almost exclusively full of lines like this:
{"reqId":"o20VWlrQIU1OTT0n90QI","level":2,"time":"2020-08-07T12:52:09+00:00","remoteAddr":"127.0.0.1","user":"server","app":"suspicious_login","method":"MKCOL","url":"/remote.php/dav/files/<redacted>","message":"Detected a login from a suspicious login. user=server ip=127.0.0.1 strategy=ipv4","userAgent":"curl/7.68.0","version":"18.0.7.1"}

The Graph in the security section telling me: "Yay 99% of my detected suspicious logins are actually suspicious" is so next to useless as it is literally telling me: 99% of your users get an unnecessary notification and have to reload the website just to continue doing their job (the amount of "warnings" causes nextcloud to invalidate the current token) ...

Nextcloud Version: 18.0.7
Addon Version: 3.1.0

Greetings

PS: this is not limited to curl! Chrome and firefox have the same issues.

[ChristophWurst]

The Graph in the security section telling me: "Yay 99% of my detected suspicious logins are actually suspicious" is so next to useless as it is literally telling me: 99% of your users get an unnecessary notification and have to reload the website just to continue doing their job (the amount of "warnings" causes nextcloud to invalidate the current token) ...

So you really think the passive aggressive statement helps move things forward faster?

I'm assuming you use a reverse proxy, but it's misconfigured. Please read the docs and configure it accordingly. The training will then be more reliable.

the amount of "warnings" causes nextcloud to invalidate the current token

This is a false claim. The app doesn't do anything but trigger a notification, but that is also debounced and capped after a few of those. Please spare me with the exaggerations for the next bug report, this doesn't add any value.

[Pingger]

Hi,

no, I don't think that it makes things go faster and I apologize for that. To put my behaviour into context: I had some very unreasonable People that Day, that already aggravated me and only getting to know of this being an issue only because another monitoring software caught the 2GB logfile mentioned below, tipped me off quite a bit as it suddenly made so much sense, why I had relogin so often into my nextcloud.

Your assumption, that I use a reverse Proxy is wrong!
It's an apache2 with PHP 7.4. No ReverseProxy trickery something like that.
The config for that VirtualHost is this:

<VirtualHost 0.0.0.0:443>
	ServerName nextcloud.redacted.TLD
	ServerAdmin admin@redacted.TLD
	DocumentRoot /var/www/nextcloud
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
	
	Include /etc/apache2/options-ssl-apache.conf
	SSLCertificateFile /etc/letsencrypt/live/redacted.TLD/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/redacted.TLD/privkey.pem
</VirtualHost>

Yes, it is a false claim, that nextcloud invalidates the session, the PHP settings, that are set by nextcloud cause this ...

nextcloud.log.txt
This just the (filtered) log of the last 7 days before I disabled the plugin. (it was 60MB total, vs the previous log that is 2GB total, where I only greped to check for a few Browsers and users.)
USER_1 is server, IP_1 is 127.0.0.1
And yes, the server-User has the most accesses! It's uploading a few files every 5 minutes, so that other users can access them without being able to access the originials (those keep being changed by another program)

In the Log you can also see, that the timeout after the 5th 'suspicious login' notification is within your 1 hour window, which should have stopped the warning after the 3rd notification. Not only that, but I could find several cases where I get over 100 of those notifications for the same user from the same IP within the same hour.

And curl doesn't rely on the session token, as it logs in again each time it connects, so the script never failed on the upload step.

Greetings

[ChristophWurst]

If you don't use a proxy, how come the client IP is detected as 127.0.0.1? Is the Nextcloud hosted on your work machine?

[ChristophWurst]

In the Log you can also see, that the timeout after the 5th 'suspicious login' notification is within your 1 hour window, which should have stopped the warning after the 3rd notification. Not only that, but I could find several cases where I get over 100 of those notifications for the same user from the same IP within the same hour.

The logic relies on data written by other processes, so if large numbers of requests from the same user hit nextcloud close to simultaneously, the process might read outdated data, depending on your isolation level set in the database.

[Pingger]

The client IP is 127.0.0.1, because there is a CRONJOB on the server that literally connects to 127.0.0.1!
Other clients connect from outside. A request from another Server has the IP "85.235.x.x"!
{"reqId":"OwvLkDr98pItXmiOEsIb","level":2,"time":"2020-08-07T12:52:06+00:00","remoteAddr":"85.235..x.x","user":"server","app":"suspicious_login","method":"GET","url":"/remote.php/dav/files/server/100KProject/_MP4","message":"Detected a login from a suspicious login. user=server ip=85.235..x.x strategy=ipv4","userAgent":"curl/7.68.0","version":"18.0.7.1"}

The script in question:
curl -T file -u ${nextcloud_username}:${nextcloud_password} --resolve "nextcloud.redacted.TLD:127.0.0.1" --insecure "https://nextcloud.redacted.TLD/remote.php/dav/files/server/<shared/folder>/file";

The --resolve is there, so we don't use an external connection to reduce the measured traffic by the provider (as it does cost money). The --insecure is there, because the 127.0.0.1 voids the credibility for the Certificate.

[Pingger]

In the Log you can also see, that the timeout after the 5th 'suspicious login' notification is within your 1 hour window, which should have stopped the warning after the 3rd notification. Not only that, but I could find several cases where I get over 100 of those notifications for the same user from the same IP within the same hour.

The logic relies on data written by other processes, so if large numbers of requests from the same user hit nextcloud close to simultaneously, the process might read outdated data, depending on your isolation level set in the database.

"close to simultaniously" should not apply for over 100 requests of which 5 requests are bunched up and then a 5 minutes break, before the next 5 requests occur.

[Pingger]

And just in case, your further responses are one of the reasons, why I opened the initial ticket the way I did: Other devs did literally the same. Jumping to wrong conclusions by disregarding disqualifying information that was already provided ...

[ChristophWurst]

I'm giving free support, so please excuse me for not having time to read all the details.

I'll have another look when time allows to dig deeper.

[ChristophWurst]

Just disable the app for now if it annoys you. It doesn't add any value for your current setup anyway.

[Pingger]

sorry, for the late response. I read it, it got automatically marked as read and I forgot about it.

It doesn't add any value for your current setup anyway.

Why wouldn't it add any value to my setup?!
Just because a single client of ~20 Clients is the server itsself?
Or because it doesn't work as intended?

Eitherway, I already have it disabled, because of the HUGE logfiles caused by the issue ...

[ChristophWurst]

If you get spammed with false positives, you won't notice when an actual attackers logged into your system.