On 2016-06-17 at 22:12, pa011 wrote:
Thank you Michael, solving that obviously easy question :-)
So what was this "attac" then about, on which way, how can I see that ?
Nice weekend to all
Paul
Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
On 2016-06-17 at 21:51, pa011 wrote:
Thank you both !
@ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block
"HTTP/1.1 404 293..." are these the ports the traffic went trough ?
Hi,
Glad to hear other people already helped you out with your first question :)
To answer this one: No, this is just the HTTP version (so protocol and version), the HTTP status code (404 for "Not Found"; file was not found on the server) and the size of the message that was transmitted to the client, 293 bytes in this case.
Best Regards, Michael Armbruster
Hi Paul,
assuming the default HTTP port, it was an attack to the port 80. Furthermore, the cryptic looking signs (%XX, whereas X is 0-9 or A-F), are url escaped characters. Unescaping them leads to something like this:
/cgi-bin/php-cgi?-d+allow_url_include=on+-d+safe_mode=off+- d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+- d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+- d+cgi.redirect_status_env=0+-n
(I only inserted line breaks, so it does look nicer. The url itself has NO line breaks).
So the attacker accessed /cgi-bin/php-cgi on the webserver with some arguments. Looking at those, we can see "allow_url_include=on" and "safe_mode=off" etc. So the attacker tried to modify the CGI servlet (the executable he tried to access) via some url manipulation to deactivate various security features.
Now to the other things per log entry.
At the beginning of each log entry, we have the IP address of the "attacker" (your node in this case, you replaced it with x characters for anonymity, that's good for this mailing list).
Secondly, we see the time when the access took place.
Then, we see the method of the request, in this case, its a POST. POST means that we send additional data with our request to the server, while GET does not do that (GET can only send data like the url manipulation does, via the url, though of course, usually you submit important data like the ID of an article you try to read on a news site).
Putting all those bits together, we can conclude that an attacker tried to access the PHP executable on the CGI path on a webserver and disabling various security features. The malicious code or data he tried to send to the server was sent via POST data. Though we cannot see the post data, so we can only speculate what the attacker tried to do. A good bet would be to upload a shell to the webserver to gain further access on the server, but that's only speculation.
I hope I could answer your question well enough :)
Best Regards, Michael