ISPConfig 3.1.11 on Debian GNU/Linux 9.4 Stretch. The included lines show up in logwatch output. Reading past forum messages indicates I could install apache module modsecurity to do something about these, but should I? Looks like ISPConfig does not configure modsecurity, that makes me think it is not really necessary. Code: A total of 19 possible successful probes were detected (the following URLs contain strings that match one or more of a listing of strings that indicate a possible exploit): /login/index.php?system=../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?page=../../../../../../../../../etc/passwd HTTP Response 200 /login/index.php?../../../../../../../etc/passwd HTTP Response 200 /admin/index.php?page=unexisting../../../../../../../../../../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?WE_LANGUAGE=../../../../../../../../etc/passwd%00 HTTP Response 200 /?lang=../../../../../../../../../etc/passwd%00.png&p_id=60 HTTP Response 200 /login/?lang=../../../../../../../../../etc/passwd%00.png&p_id=60 HTTP Response 200 /login/index.php?theme=../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?fct=preview&p=../../../../../../../../../../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?PathPrefix=../../../../../../../../../../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?page=/etc/passwd HTTP Response 200 /login/index.php?lng=../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?pg=1&d=../../../../../../../../../../../../../../../../../../ HTTP Response 200 /login/index.php??p=../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?page=../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?ip=;/bin/cat%20/etc/passwd HTTP Response 200 /login/index.php?page=../../../../../../../../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?p=../../../../../../../../../../etc/passwd%00 HTTP Response 200 /login/index.php?page=../../../../../../../../../../../etc/passwd%00 HTTP Response 200
I'm pretty worried about the HTTP Response 200 on all of those lines, why would apache give an ok to those requested URI's? However it's weird that is actually giving a 200 response on ALL of those URI's. You might try the grep the access logs for the '/etc/passwd' string to see if you got any other attempts that actually gave a 404 (which it should have done i think on all of them) And keep in mind, yes ISPConfig is delivered with some additional security but that does not mean you are safe from all kinds of attacks. You still will need additional measures on top of ISPConfig/Fail2ban/JailKit/ClamAV/rkhunter etc etc etc. Also check your error logs specifically for php error's on the same timeframes.
Are these really successful probes? I don't think so. Have you tried to run one of these URL's in the browser and did they really show the content of /etc/passwd My guess is that logwatch is not able to see if a probe was successful as it can not know what the result (output, not response code) of the listed URL's was. The response must be 200 when the file /login/index.php exists, no matter which variable was set behind ? in the URL. So the actual 200 response code is nothing to worry about in my opinion. But one should test the URL's to see what they return in the browser as actual html / txt output.
I did a short test, my guess was that these URL's might match the ISPConfig UI, which they do (other applications may have a folder /login/ with an index.php inside as well of course). Here the log excerpt of some of them where you can see the 200 code as well: Code: server1.example.com:8080 192.168.1.9 - - [13/Jul/2018:09:09:01 +0200] "GET /?lang=../../../../../../../../../etc/passwd%00.png&p_id=60 HTTP/1.1" 200 767 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.42 Safari/537.36" server1.example.com:8080 192.168.1.9 - - [13/Jul/2018:09:08:45 +0200] "GET /login/index.php?../../../../../../../etc/passwd HTTP/1.1" 200 4083 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.42 Safari/537.36" I explained the reason why this must end with a 200 and not 404 code already above. What you actually get in the browser is not the content of the password file, in fact, you either get the message: "Possible attack detected. This action has been logged." or just the ISPConfig login page, which means that the parameter was ignored completely. So these are all false positives from logwatch and nothing to worry about.
