Da gibt es eine Firma die immer wieder auf meine Seite Zugriff erlangt, obwohl ich ihre IP schon lange gesperrt habe. Nennen wir ihre IP 123.123.123.123 Das sieht so aus: Struktur: Domain-root/ordner1/ordner2 in Domain-root, ordner1 und ordner2 habe ich je eine .htaccess mit deny from 123.123.123.123 in einer index.php unter Domain-root/ordner1/ordner2, also Domain-root/ordner1/ordner2/index.php habe ich ein mail(...) eingerichtet, sodaß ich beim Laden eine Mail bekomme, in der die IP des besuchers steht. Und trotzdem bekomme ich eine mail, daß 123.123.123.123 auf meiner Seite war. Trage ich meine IP-Adresse ein bekomme ich weder eine Mail noch habe ich Zugriff auf die Seiten. Woran kann es noch liegen(Linux-Server gehackt nicht ausschließen).
Rene Peters schrieb: > habe ich je eine .htaccess Und die wird auch benutzt? Ich würde sowas ja in der Konfiguration des Servers selbst eintragen.
Jörg Wunsch schrieb: > Ich würde sowas ja in der Konfiguration des Servers selbst eintragen. Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer. Peter II schrieb: > was steht denn im Access log so drin? Wo finde ich den access log?
Rene Peters schrieb: > Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer. Möglicherweise sowas wie /etc/apache2/sites-enabled/000-default Wenn darin kein override zugelassen wurde, dann sind .htaccess Files wirkungslos.
A. K. schrieb: > Möglicherweise sowas wie /etc/apache2/sites-enabled/000-default > Wenn darin kein override zugelassen wurde, dann sind .htaccess Files > wirkungslos. Rene Peters schrieb: > Trage ich meine IP-Adresse ein bekomme ich weder eine Mail noch habe ich > Zugriff auf die Seiten.
Rene Peters schrieb: > Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer. Das ist eher ... unwahrscheinlich. Wo hast Du nach dieser Datei gesucht?
Rufus Τ. Firefly schrieb: > Das ist eher ... unwahrscheinlich. Das ist mittlerweile ziemlich normal. Die Konfiguration setzt sich aus diversen Files zusammen, basierend auf /etc/apache2/apache2.conf. httpd.conf ist dann leer, übrig aus vergangenen Zeiten, in denen man alles da reinklatschte. debian: apache2.conf => mods-enabled/*.{load,conf} => httpd.conf (leer) => ports.conf => conf.d/* => sites-enabled/*
:
Bearbeitet durch User
Was ist denn das: GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1 war ein Request, wurde mit 400 quittiert. Es gab sogar eine ganze Menge davon: http://pastebin.com/YsrBSWPu Dann gab es vor kurzem folgenden Request: POST /?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2 D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6 E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65 %5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73% 65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5 F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66 %6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65% 64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%7 4%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%7 0%75%74+%2D%6E HTTP/1.1 übersetzt POST /?-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 -d auto_prepend_file=php://input -n HTTP/1.1 das mit einem 200 quittiert wurde! Und dann noch ein GET http://24x7-allrequestsallowed.com/?PHPSESSID=7jy745aa00143YWMVWR_EABFUOT HTTP/1.1 und ein GET http://91.188.124.233/index.html HTTP/1.1 das auch mit einem 200 quittiert wurde. Was tun?
Rufus Τ. Firefly schrieb: > Rene Peters schrieb: >> Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer. > > Das ist eher ... unwahrscheinlich. Wo hast Du nach dieser Datei gesucht? find / -name httpd.conf. Es gab einen Treffer.
Zum eigentlichen Problem: was muß ich in der apache2.conf ändern um das Problem zu beheben?
Hallo. Da kannst du nicht viel tun. Manche Leute haben ne Menge Zeit und scannen das ganze Web nach allen möglichen Dingen ab. Ich nutze ein Fail2Ban nach 3 Scans und die IP kommt nicht mehr an den Server dran. Martin
Über die 400er braucht man sich keine Sorgen zu machen, Interessant sind die 200er. Schnapp dir http://www.openvas.org und schnüffle selbst nach den Löchern in deiner Installation.
Rene Peters schrieb: > das mit einem 200 quittiert wurde! heist noch gar nix, mein lighty liefert die Seite trotzdem aus... Ist allerdings definitiv ein Angriff... (Allerdings ist mir der Angriffsvektor im Augenblick unbekannt... Hat jemand infos?)
Rene Peters schrieb: > GET http://91.188.124.233/index.html HTTP/1.1 > das auch mit einem 200 quittiert wurde. Normalerweise ist das genau die Sorte Zugriff, für die ein Webserver gebaut wird. Oder stört dich die IP?
A. K. schrieb: > Rene Peters schrieb: >> GET http://91.188.124.233/index.html HTTP/1.1 >> das auch mit einem 200 quittiert wurde. > > Normalerweise ist das genau die Sorte Zugriff, für die ein Webserver > gebaut wird. Oder stört dich die IP? naja, wenn man sich den Inhalt (text "TRON LEGACY") anschaut ist es verdächtig... Könnt ein Root-Kit sein.. Hab aber nichts gefunden, der Film versaut da den namespace bei google ziemlich
A. K. schrieb: > Normalerweise ist das genau die Sorte Zugriff, für die ein Webserver > gebaut wird. Oder stört dich die IP? Öhm... normal ist das sicher nicht, seit wann gehört das Protokoll und der Host in die GET Anfrage?
Nachdem ich fail2ban per apt-get geholt und per fail2ban start gestartet habe, läuft es dann automatisch immer weiter?
Auch fail2ban Konfiguriert? Achja, fail2ban ist für authorization errors, nicht gegen exploits.
:
Bearbeitet durch User
Hallo. Man kann fail2ban auch für mehrere 200 von einer IP in zB 10 Minuten konfigurieren. Martin
Immer diese halbgaren Antworten. Statt "Auch fail2ban Konfiguriert?" schreibst du in Zukunft. Um fail2ban zu konfigurieren machst du a, b und c.
Nicht persönlich nehmenm, die Kids spielen mit DFind rum. htaccess ist ein guter Startpunkt, für solche Sachen kann ich dir aber empfehlen sich mit mod_security auseinander zu setzen. Ach ja, ich habe auf meinem Server damals noch folgenden trick angewandt: robots.txt anlegen mit folgendem Inhalt. User-agent: * Disallow: /auf/wiederseen Normale Menschen gucken sich die Datei nicht an, einige "Hackertools" schon. Sobald jemand probiert diesen Ordner anzusteuern -> Ban.
Rene Peters schrieb: > Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer. Rene Peters schrieb: > Wo finde ich den access log? Du solltest m.E. keinen Server betreiben der öffentlich erreichbar ist, da du offensichtlich nicht über die notwendigen Fähigkeiten verfügst das Ding zu warten und vor allem abzusichern. Rene Peters schrieb: > Um fail2ban zu konfigurieren machst du a, b und > c. Ja, klar, ist alles so einfach, dann kann jeder Depp ohne Hintergrundwissen einen Server absichern, man muss nur a, dann b und zum Schluss c machen... man muss dafür nur mal in einem Forum nachfragen und das reicht dann schon. Dir ist hoffentlich klar dass du dafür veantwortlich bist falls jemand deine Maschine für illegale Sachen missbraucht. Einen sog. Managed Server zu mieten mag anfangs mehr kosten, aber dann machen andere für dich die Arbeit.
Mein Ung schrieb: > Du solltest m.E. keinen Server betreiben Du solltest nicht antworten wenn deine Antworten weiterhin diese niedrige Qualität haben.
Rene Peters schrieb: > Du solltest nicht antworten wenn deine Antworten weiterhin diese > niedrige Qualität haben. Recht hat er aber: du betreibst einen Server, der öffentlich erreichbar ist, und hast die Konfiguration nicht einmal so weit gelesen und verstanden, dass du das Zugriffs-Log finden kannst? Ja, das kann gut gehen, schließlich ist der Indianer ein relativ gutmütiger Geselle, den man auch ohne Ahnung benutzen kann :). Andererseits: du benutzt offenbar PHP, und das ist nun schon gar nicht mehr so gutmütig, es war in der Vergangenheit schon ein paarmal für irgendwelche Sicherheitslücken in Webservern zuständig.
Rene Peters schrieb: > Was tun? Den Job von jemandem machen lassen, der damit nicht überfordert ist.
Läubi .. schrieb: > Öhm... normal ist das sicher nicht, seit wann gehört das Protokoll und > der Host in die GET Anfrage? Das ist zwar unüblich, aber der Standard erlaubt es ;D Rene Peters schrieb: > POST /?-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 -d auto_prepend_file=php://input -n HTTP/1.1 > > das mit einem 200 quittiert wurde! Hier wird wohl versucht falsch als CGI eingebundenes PHP anzugreifen. Sofern die Lücke nicht tatsächlich vorhanden ist, wird aber einfach das Standarddokument ausgeliefert (also vermutlich index.html oder index.php) > > Und dann noch ein > > GET > http://24x7-allrequestsallowed.com/?PHPSESSID=7jy745aa00143YWMVWR_EABFUOT > HTTP/1.1 Sofern das mit 200 beantwortet wird und dein Host nicht '24x7-allrequestsallowed.com' ist, betreibst du womöglich einen offenen Proxy-Server! Ein Blick in die access_log wäre wohl schon interessant ;D
Jörg Wunsch schrieb: > Rene Peters schrieb: >> Du solltest nicht antworten wenn deine Antworten weiterhin diese >> niedrige Qualität haben. > > Recht hat er aber Recht hat er nicht.
♪Geist schrieb: > robots.txt anlegen mit folgendem Inhalt. > > User-agent: * > Disallow: /auf/wiederseen > > Normale Menschen gucken sich die Datei nicht an, einige "Hackertools" > schon. Sobald jemand probiert diesen Ordner anzusteuern -> Ban. Kann man machen, aber auch nur, wenn man will, das keien Suchmaschine die Seite indiziert. Den Suchmaschinen steuern diesen Ordner auch an. Wenn die Seite eh nicht gefunden werden soll ist es wurscht, ansonnsten eher keine Lösung
Eine Suchmaschine, die ein Disallow ignoriert, will ich eh nicht haben.
Rene Peters schrieb: > Um fail2ban zu konfigurieren machst du a, b und > c. Das setze ich mal voraus das man nicht alles vorbeten muss. RTFM. Ausserdem habe ich kein apache am start, so dass ich mich selber erst einlesen müsste. Martin schrieb: > Hallo. > > Man kann fail2ban auch für mehrere 200 von einer IP in zB 10 Minuten > konfigurieren. > > Martin Auf 200er zu banen finde ich irgendwie sehr fehleranfällig... Da kann ich ja meinen Server auch nicht mehr benutzen wie ich will. Der TO möchte ja eigentlich gezielt eine IP raussperren, und da wäre sein Ansatz via htaccess schon mal richtig, er muss nur rausfinden warum es nicht geht. Allerdings -- dass muss ihm klar sein -- kann man das sehr einfach umgehen. Alternativ, wenn es nur wenige user den Server benutzen (sollen), kann man auch ein altbewährtes HTTP-Auth fordern....
:
Bearbeitet durch User
bluppdidupp schrieb: > Sofern das mit 200 beantwortet wird und dein Host nicht > '24x7-allrequestsallowed.com' ist, betreibst du womöglich einen offenen > Proxy-Server! Ich habe meine Serveradresse mit allen offenen Ports als Proxyserver auf meinem Heimrechner eingetragen und ich konnte keine Seite aufrufen. Die Verbindung zum Proxyserver konnte nicht hergestellt werden. Der Zugriff wurde verweigert. Ich habe keinen ungewollten Proxyserver.
Tobias Frost schrieb: > Allerdings -- dass muss ihm klar sein -- kann man das > sehr einfach umgehen. Und schon wieder Ende. Wie kann man das umgehen.
z.b: Anderen Internetzugang verwenden? z.B vom Handy, daheim, Freund .... Evtl. hat die IP in Frage noch einen Backup-zugang? Vielleicht haben die Leute doch gar nicht so unrecht wenn sie Dir raten nicht selber zu hosten. Da fehlts an den Basics. :(
Rene Peters schrieb: > Tobias Frost schrieb: >> Allerdings -- dass muss ihm klar sein -- kann man das >> sehr einfach umgehen. > > Und schon wieder Ende. > > Wie kann man das umgehen. IP-Adressen sind Schall und Rauch. Einfach einen Web-Proxy benutzen und schon denkt dein Server, du hättest eine Anfrage aus dem weißen Haus in Washington, während der eigentliche Browser im Nachbarhaus agiert.
Rene Peters schrieb: > Was ist denn das: > > GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1 Erster Google-TreffeR: http://timkunze.eu/w00tw00t-at-isc-sans-dfind/
Karl Heinz schrieb: > Eine Suchmaschine, die ein Disallow ignoriert, will ich eh nicht haben. Eine öffentliche Website, die man per Suchmaschine nicht finden kann, erscheint mir freilich auch nur begrenzt sinnvoll.
Tobias Frost schrieb: > z.b: Anderen Internetzugang verwenden? z.B vom Handy, daheim, > Freund > .... Evtl. hat die IP in Frage noch einen Backup-zugang? Der, um den es geht hat einen gehosteten Server mit IP-range. Einmal ordentlich geblockt und es gibt kein Problem mehr. > Da fehlts an den Basics. :( Nein, da fehlt es nicht an den Grundlagen.
Rene Peters schrieb: > Nein, da fehlt es nicht an den Grundlagen. Ach nein? Rene Peters schrieb: > Wo finde ich den access log? RTFM Rene Peters schrieb: > Was ist denn das: > > GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1 Google-Suche liefert in weniger als einer Minute eine brauchbare Antwort
Mark Brandis schrieb: > Rene Peters schrieb: >> Nein, da fehlt es nicht an den Grundlagen. Du hast in diesem Thread dein Wissen noch nicht unter Beweis gestellt, warum fängst du nicht mal langsam damit an - oder ist es etwa nicht vorhanden?
Damit Menschen ihr Wissen auch mitteilen können sollten genau diese Menschen auch wissen woran es hapert und mit Informationen versorg werden. z.B: Schreibst du Rene: > in Domain-root, ordner1 und ordner2 habe ich je eine .htaccess mit > deny from 123.123.123.123 und schreibst gleich dazu das es wohl nicht funktioniert. Den Hinweis das das in deiner Apache Konfiguration auch eingestellt sein muss wird quasi ignoriert. Du weißt Offensichtlich nicht einmal wo die Config sich versteckt oder wie die auf deinen System zusammen sitzt (der Hinweis das es bei einem aktuellen System mehr als eine Datei ist). Eine .htaccess Datei wird nur verarbeitet wenn der Apache auch weis das er diese Dateien auch verarbeiten soll, den der Name der Datei ist wie immer schal und rauch. >AccessFileName .htaccess Das alleine wäre zu einfach, da gibt es noch den "AllowOverride" mit der bestimmt wird was du in der .htaccess reinschreiben darfst um damit andere Einstellung für das Verzeichnis zu haben in dem die Datei steht. >AllowOverride AuthConfig Damit darfst du gerne Passwort abfragen für ein Verzeichnis machen, aber ein "deny from" wird ignoriert. >AllowOverride AuthConfig Limit Nun darf neben Passwort auch mit Deny gearbeitet werden. siehe https://httpd.apache.org/docs/2.2/de/mod/core.html#allowoverride DU schaffst es aber nichtmal deine Config dazulegen oder weißt nicht viel drüber. Wie soll man den dir da helfen ? OS ? Apache Version ? Verwaltungstools ala Plesk ? Globale Einstellung oder nur für einen Vhost ? Jetzige Einstellungen ? Was hat du bisher unternommen ? Das Thema ist zu vielfältig und zu speziell um da allgemein gültige Aussagen treffen zu können.
:
Bearbeitet durch User
Hallo Rene. Ich finde deine Reaktion auf Hilfestellungen hier im Forum auch nicht gut. Die Leute helfen freiwillig, du machst keine genauen Angaben zum Setup und forderst nur. Ich würde endlich mal im Logfile nachschauen was dort steht im Falle eines deny der 123.x.x.x. IP. Ich habe da auch schon böse Überraschungen erlebt mit einem Leerzeichen an der falschen Stelle in der .htaccess Syntax. Martin
Hier die default unter sites-available:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
deny from 123.123.123.123
</Directory>
ScriptAlias cgi-bin /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error,
crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
Alias doc "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>
Habe AllowOverride nicht geändert, sondern gleich die IP(meine IP)
reingeschrieben, wie es besser ist.
Habe es gespeichert, habe den Server neugestartet, die Seite liegt in
einem Unterverzeichnis von /var/www
Trotzdem kann ich darauf zugreifen, verdammt nochmal.
Wenn du die 123er Adresse meinst: Kommst du laut Logfile auch wirklich mit jener IP rein, die da drinsteht? Nicht dass da noch ein Proxy mitspielt.
Um dem Fehler näherzukommen mehr details: So sieht es aus:
1 | Domain-root/ordner1/ordner2 |
unter domain-root ist eine index.php. In dieser steht etwa
1 | <?php echo "Wurzel"; ?> |
Ist in Domain-root auch eine htaccess mit deny from <meineIP> dann bekomme ich ein denied wie gewünscht. In Domain-root/ordner1 ist auch eine index.php und eine htaccess mit deny from <meineIP>. In dieser index.php steht
1 | <?php
|
2 | require('ordner2/1.php'); |
3 | ?>
|
4 | <div class="blah"> |
5 | |
6 | <?php require("ordner2/2.php"); |
7 | require('ordner2/3.php'); |
8 | require('ordner2/4.php'); |
9 | require('ordner2/5.php'); |
10 | ?>
|
11 | <?php require("ordner2/6.php"); ?> |
12 | <?php require("ordner2/7.php"); ?> |
13 | <?php require("ordner2/8.php"); ?> |
14 | </div>
|
15 | |
16 | <?php
|
17 | require 'ordner2/9.php'; |
18 | ?>
|
In Domain-root/ordner1/ordner2 sind die 1.php bis 9.php und eine htaccess mit deny from <meineIP>. Habe ich die htaccess dort nicht, wird die Seite angezeigt und die htaccess in Domain-root/ordner1 und Domain-root ignoriert. Habe ich sie, wird die Seite trotzdem angezeigt aber nur als Text, jedes Bild, jede CSS-Formatierung fehlt. Scheint ein selektives deny from zu sein, Text kommt durch Bilder nicht. Der Text findet sich in den 1 bis 9.php ohne weitere requires als schlichtes echo.
Ich glaube du zeigst uns nicht das richtige Config File.
Denn in dieser Config werden weitere .htaccess expliziet unterbunden.
Wenn du dann noch schreibst, dass deine .htaccess im Unterverzeichnis
funktioniert, stimmen was nicht. Ev. Apache noch nie neu gestartet ?
Ansonsten ist der Fehler schnell ersichtlich, deine Access rule stimmt
nicht.
Wenn du dir ein Howto oder Doku mal durchgelesen haettest, dann waere
dir
dieser Fehler nicht unterlaufen, weil extra auf dies dort hingewiesen
wird.
Order allow,deny
muss so lauten:
Order deny,allow
chris schrieb: > Ich glaube du zeigst uns nicht das richtige Config File. > Denn in dieser Config werden weitere .htaccess expliziet unterbunden. > Wenn du dann noch schreibst, dass deine .htaccess im Unterverzeichnis > funktioniert, stimmen was nicht. Ev. Apache noch nie neu gestartet ? > Ansonsten ist der Fehler schnell ersichtlich, deine Access rule stimmt > nicht. > Wenn du dir ein Howto oder Doku mal durchgelesen haettest, dann waere > dir > dieser Fehler nicht unterlaufen, weil extra auf dies dort hingewiesen > wird. > Order allow,deny > muss so lauten: > Order deny,allow Hat nichts geändert. > Ev. Apache noch nie neu gestartet ? Rene Peters schrieb: > Habe es gespeichert, habe den Server neugestartet, die Seite liegt in > einem Unterverzeichnis von /var/www
Kann es sein, daß eine Datei, die wichtiger ist als die default diese ignorieren läßt?
Schreib doch den Order um, und stell auch sicher, dass in deiner Htaccess im Unterordner nicht wieder der order allow,deny steht. Es ist ganz einfach. Order allow,deny heisst, erlaube alle, und nachdem alle erlaubt sein, sperre 133. ... . Da alle erlaubt sind, ist auch 133. ... erlaubt. Wenn du aber den order umdrehst, also order deny,allow dann sperrt er den 133. ... und wenn es kein 133. ... ist, dann erlaubt er diese.
chris schrieb: > Es ist ganz einfach. Scheinbar nicht. ;-) > Order allow,deny heisst, erlaube alle, und nachdem alle erlaubt sein, > sperre 133. ... . Da alle erlaubt sind, ist auch 133. ... erlaubt. Passt so schon, wenn er genau diese eine Adresse ablehnen will. Zu "Order Allow,Deny": "First, all Allow directives are evaluated; at least one must match, or the request is rejected. Next, all Deny directives are evaluated. If any matches, the request is rejected. Last, any requests which do not match an Allow or a Deny directive are denied by default." http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order
:
Bearbeitet durch User
Rene Peters schrieb: > Was ist denn das: > > GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1 > > war ein Request, wurde mit 400 quittiert. Es gab sogar eine ganze Menge > davon: http://pastebin.com/YsrBSWPu > > Dann gab es vor kurzem folgenden Request: > > POST > /?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2 D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6 E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65 %5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73% 65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5 F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66 %6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65% 64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%7 4%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%7 0%75%74+%2D%6E > HTTP/1.1 ist ein automatisierter scan nach verwundbaren php-http servern. > POST /?-d allow_url_include=on -d safe_mode=off -d ... siehe https://www.google.de/search?q=POST+/%3F-d+allow_url_include%3Don was der exploit macht weiß ich nicht, deine sache. normalerweise versucht man auf webservern eigenen code unterzubringen, also z.b. eigene php/perl/shell (je nachdem was dein webserver interpretiert) scripte im filesystem unterzubringen und diese vom webserver ausführen zu lassen. das kann beliebig komplex werden, bis hin zu base64 encodierten binaries die zeilenweise hochgeladen und dort wieder zusammengebaut werden - ziel wäre in dem fall z.b. einen telnetd zu plazieren um sich die weitere arbeit leichter zu machen. du willst wissen was (eventuell) auf deinem server passiert ist? hol dir professionelle hilfe, vor allem wenn du schon probleme hast die ganz normalen access/error-logs zu finden (die übrigens gefälscht sein können, je nachdem wie tief jemand ins system eingrdrungen ist.).
c.m. schrieb: > du willst wissen was (eventuell) auf deinem server passiert ist? hol dir > professionelle hilfe, vor allem wenn du schon probleme hast die ganz > normalen access/error-logs zu finden (die übrigens gefälscht sein > können, je nachdem wie tief jemand ins system eingrdrungen ist.). Professionelle Hilfe will er nicht: Rene Peters schrieb: > Mein Ung schrieb: >> Du solltest m.E. keinen Server betreiben > > Du solltest nicht antworten wenn deine Antworten weiterhin diese > niedrige Qualität haben. Rene Peters schrieb: > Jörg Wunsch schrieb: >> Rene Peters schrieb: >>> Du solltest nicht antworten wenn deine Antworten weiterhin diese >>> niedrige Qualität haben. >> >> Recht hat er aber > > Recht hat er nicht. Rene Peters schrieb: >> Da fehlts an den Basics. :( > > Nein, da fehlt es nicht an den Grundlagen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.