Hi there, I have a client who's just got the usual error message when trying to log in to her account: Possible attack detected. This action has been logged. When I checked in the ISPConfig log (under Monitor), I see the following: I've already asked my client to remove her cookies in her browser because it looks like it's coming from there if I read the error message well. I'm not completely sure it's going to solve this issue for her, though. And, by the way, a lot of my clients don't even know how to do that and it can be annoying to explain sometimes... My first question is then: how a simple cookie in the browser can be so harmful for ISPConfig? I can connect to any bank account online without having to remove any cookie from my browser and it works just fine... Please forgive my ignorance on this matter but I just don't get it Second question, which is actually connected to the first one: appart from raising the limit (as I've seen in another thread on this forum) and putting our server at risk, isn't there any viable solution to this problem? Something you might be working on currently or any idea, that would fix this issue behind the scene, invisible for end users? Thanks!
This message is not usual, I never get it on any of my systems and other users with properly installed systems won't see it too, unless they try to attack the server. In your case, the message is not caused by an attack, it is caused by a misconfiguration of your system, you must have installed a conflicting laravel software which tries to inject cookies into ispconfig domain space. Your online banking software would probably deny access as well when it detects that someone was able to get control over the domain name of the bank to inject cookies that were not issued by the bank software itself. So the question is how a laravel cookie could be set on the subdomain and port that is exclusively reserved for ISPConfig. You must have some laravel software installed on the same domain name which injects the cookie. Put ispconfig or that laravel software on a different domain. If the laravel software is already on a different subdomain, then it is probably configured wrong to issue a cookie on all subdomains and not just on the subdomain it is installed on. If you can't fix that laravel software installation, then your only other option is to turn off the IDS in ISPConfig and stay unprotected.
Oh my god! Thanks for this Till, I just realized I have a "dormant" website on my main domain (the one on ports 80/443)... I didn't know it would interfere with ISPConfig, on a different port... I've just deactivated this site and this should fix the problem, right?
You'll have to try it. The site must be accessed by the clients which had that problem as it created that cookie.
I just did and it seems to run smoothly now! I logged in and out several times and no more error message. I guess that's it: these clients might have landed accidentally on the website before getting to the ISPConfig panel and then boom! Cookie in their browser... Till, you made my day :-D Thank you so much for your help!!! Happy Easter ;-)
