Everything is flagged as suspicious about suspicious_login HOT 15 OPEN

Well, I just learned enough to decide to delete this silly app. Does nothing but annoy. Thanks for nothing.

from suspicious_login.

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 [email protected]
	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

from suspicious_login.

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.

from suspicious_login.

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.

from suspicious_login.

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

from suspicious_login.

ah I needed the trusted_proxies. Thx

from suspicious_login.

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.

from suspicious_login.

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?

from suspicious_login.

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.

from suspicious_login.

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 ...

from suspicious_login.

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.

from suspicious_login.

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

from suspicious_login.

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 ...

from suspicious_login.

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.

Hi,

I have the same problem but my nextcloud (running apache2) is behind a reverse proxy (nginx). What do I need to do?

from suspicious_login.

I have the same problem but my nextcloud (running apache2) is behind a reverse proxy (nginx). What do I need to do?

https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/reverse_proxy_configuration.html

from suspicious_login.