Mein Server, die Proxyschlampe

Jump to last post
Tone

Tone

beobachtet
Registriert
20 Juli 2013
Beiträge
300
Moin,
wenn ich meine access.log richtig interpretiere, benutzt mich der gemeine Chinese als Proxy.
Mein Frage wäre, wie kann ich das nachstellen, bzw. wie macht der das?

Im Netz habe ich schon ein paar Sachen gefunden wie ich das wohl unterbinden kann, aber ich würde es gerne mal selbst nochmal nachvollziehen.

[src=bash]115.231.222.14 - - [01/Nov/2015:16:16:02 +0100] "GET http://zc.qq.com/cgi-bin/common/attr?id=260714&r=0.9216452253579834 HTTP/1.1" 302 622 "-" "Mozilla/5.0 $[/src]


EDIT:
Habs nun selbst gefunden..
[src=bash] telnet yoursite.example.com 80
GET http://www.yahoo.com/ HTTP / 1.1
Host: www.yahoo.com [/src]
 
Zuletzt bearbeitet:
Öhm.... das heißt dein Webserver (welcher ist das?) nimmt Anfragen von extern an die ihm sagen er soll eine beliebige anderen Webseite abrufen?
Das macht mir irgendwie sorgen .....

Gerade mal bei mir probiert... dort kommt zum Glück *Bad Request* ...
# GET
You do not have permission to view link please Anmelden or Registrieren
HTTP / 1.1
HTTP/1.1 400 Bad Request
Server: nginx/1.7.10
Date: Mon, 02 Nov 2015 11:12:54 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.7.10</center>
</body>
</html>
Zum Vergrößern anklicken....
 
  • Thread Starter Thread Starter
  • #4
Mir macht sorgen, dass in der Doku beim einrichten der vHosts, nirgends ein Verweis ist, wie es gleich sinnvoll eingerichtet werden sollte, sondern man erst aktiv nach dem Fehler suchen muss um drauf aufmerksam zu werden.

Aber sei's drum, Konfig wurde angepasst, nun geht's nicht mehr.
 
  • Thread Starter Thread Starter
  • #6
Fehlerhaft trifft es meiner Meinung nach nicht, eher unvollständig.

Ich hatte quasi nirgends gesagt, dass er auf Anfragen außerhalb meines 'Document-root'-Verzeichnis nicht reagieren soll (dachte das wär von Haus aus so).

Hier ist es an sich ganz schön beschrieben:
You do not have permission to view link please Anmelden or Registrieren
 
Mir macht sorgen, dass in der Doku beim einrichten der vHosts, nirgends ein Verweis ist, wie es gleich sinnvoll eingerichtet werden sollte, sondern man erst aktiv nach dem Fehler suchen muss um drauf aufmerksam zu werden.
Zum Vergrößern anklicken....
Mir macht eher Sorgen das du offenbar die Verantwortung für die fehlerhafte Konfiguration mindestens teilweise woanders siehst obwohl das ganz klar in deinen Verantwortungsbereich fällt und zwar zu 100%.

Und wenn man überhaupt irgendetwas bei einer syntaktisch korrekten funktionalen Konfiguration fehlerhaft nennt, dann das.
 
Danke für diesen Beitrag, war mir nicht bewusst, dass man das überhaupt so "falsch" konfigurieren kann.
 
Nun ja was soll der Apache denn als Default machen wenn du kein Default einrichtest?
Also weil du erwartet hast das er automatisch schon einen Fallback eingebaut hat.

Gut ich finde es vom Apache auch dämlich das er die Konfiguration überhaupt zulässt...
Aber "normal" fängt man immer mit dem Default an (Ist der nicht sogar in der Standardconfig eh drin??? Und du hast ihn extra gelöscht?) und baut dann vHosts drum rum.
 
Ich verstehe nicht wieso Tones Server hier als Proxy gearbeitet haben soll.
Ich glaube viel eher da missinterpretiert jemand seine Logs und hat gar nicht getestet was wirklich passiert.
Denn für einen Forward Proxy müsste die Directive ProxyRequests auf On gestellt sein. (Default: Off)

Apache liefert per Default die Standartseite aus. Das mag bescheuert klingen, hat aber Sinn:
Im Kern ist Apache nur ein HTTP Server, Domain-Namen sind gar nicht seine Aufgabe. Er vertraut darauf, dass DNS dafür sorgt, dass er die HTTP-Requests bekommt, die für ihn gedacht sind.
(Außerdem könnte man auch "pfeif auf DNS" sagen und sich einfach eine IP auf die Visitenkarte drucken :D)
Natürlich kann Apache viel mehr (z.B. unterschiedliche vHosts für unterschiedliche Domains) und auf unbekannte Domains mit Bad Request antworteten. Aber das sind eben alles nur Features.

Ganz ohne Config und ohne Dateien würde ich bei einer "yahoo.com" Anfrage erwarten, dass ein Directory Listing des Verzeichnisses "/usr/local/apache/htdocs" erscheint. Liegt dort eine index.html ab, würde die ausgeliefert werden.

Tones Server antwortete auf "cgi-bin/common/attr?..." aber mit 302. Erwartet hätte ich ein 404, denn per default liegt keine "cgi-bin/common/attr" Datei im htdocs. Also entweder wurde diese erstellt, oder ein Alias / Redirect / ErrorDocument / somethingelse eingestellt.
Solche Configs können natürlich auch von der Distro, oder dem Hoster sein.
Ohne zu wissen wie der Apache genau konfiguriert wurde kann ich aber nicht viel mehr sagen wie: Standartverhalten ist es nicht. Und ohne es explizit anzuschalten wird vorallem nicht geproxied. Denn auch das ist eben nur ein Feature.
 
Zuletzt bearbeitet:
Ich denke der Aufruf GET.......cgi-bin usw. hatte eben nicht die Domain des TS im Logfile (Die er dann anonymisiert hat) - sondern eine Externe Domain? - Wenn in seinem Access-Log ausschließlich eine Externe Domain auftaucht und das mit Success quitiert statt mir Bad Request - wird er wohl die externe Domain zumindest mal aufgerufen haben oder nicht?
 
  • Thread Starter Thread Starter
  • #12
BurnerR schrieb:
Mir macht eher Sorgen das du offenbar die Verantwortung für die fehlerhafte Konfiguration mindestens teilweise woanders siehst obwohl das ganz klar in deinen Verantwortungsbereich fällt und zwar zu 100%.

Und wenn man überhaupt irgendetwas bei einer syntaktisch korrekten funktionalen Konfiguration fehlerhaft nennt, dann das.
Zum Vergrößern anklicken....

Wenn's dich glücklich macht von mir aus.
Meiner Meinung nach hätte in der Doku mindestens stehen müssen, dass alles was nicht definiert ist, erlaubt ist.
Ich gehe doch nicht davon aus, dass wenn ich ein root-Verzeichnis anlege, trotzdem auf andere Punkte drauf zugegriffen werden kann..


drfuture schrieb:
(Ist der nicht sogar in der Standardconfig eh drin??? Und du hast ihn extra gelöscht?)
Zum Vergrößern anklicken....
Sagen wir's so, mir wäre nicht bewusst, dass ich sowas rausgelöscht habe.


Shodan schrieb:
Tones Server antwortete auf "cgi-bin/common/attr?..." aber mit 302. Erwartet hätte ich ein 404, denn per default liegt keine "cgi-bin/common/attr" Datei im htdocs.
Zum Vergrößern anklicken....
Hier verstehe ich dich nicht ganz. Der Chinamensch hat doch nicht versucht auf meinen Server nach dem Verzeichnis zu suchen, sondern auf "http://zc.qq.com/".
 
Kann auch nen Redirect sein, im Grunde kann da alles im GET stehen.

QQ scheint nen Email-Anbieter zu sein, vielleicht hat einer dort ne Email und hat nen Link zu deinem Server/Webserver verschickt.
 
Tone schrieb:
Mir macht sorgen, dass in der Doku beim einrichten der vHosts, nirgends ein Verweis ist, wie es gleich sinnvoll eingerichtet werden sollte, sondern man erst aktiv nach dem Fehler suchen muss um drauf aufmerksam zu werden.
Zum Vergrößern anklicken....
Es gibt 298346892345689734659238749645834659837689 Konfigurationsmöglichkeiten, die sinnvoll und je nach Anwendungszweck passend/ erwünscht sind. Welche dieser Konfigurationen erwartest du als Standard? - Richtig, irgendeine.
Es ist deine Aufgabe, wenn du einen Software installierst, diese für deinen Anwendungszweck passend zu konfigurieren. Der Distributor ist nur dafür verantwortlich dir funktionierende Software zu liefern, nicht sie für deinen Anwendungszweck vorzukonfigurieren!

Tone schrieb:
Meiner Meinung nach hätte in der Doku mindestens stehen müssen, dass alles was nicht definiert ist, erlaubt ist.
Zum Vergrößern anklicken....
Die Dokumentation von Apache ist sehr gut. Hättest du dir insbesondere die Standardkonfiguration angeschaut, würdest du sehen, was dort (mit "warum") wie konfiguriert ist. Solltest du irgendwo Verständnisprobleme gehabt haben, hätte ein Keyword bei der Suchmaschine deiner Wahl zu 99,999% einen Treffer geliefert.


Sorry, aber du bist Administrator und damit Hauptverantwortlicher für den Server. Ein "das habe ich nicht gewusst" oder "ich hätte erwartet, dass.." sind für dich nicht zulässig. Wenn du etwas nicht weißt oder etwas erwartest, dann hast du 10x zu prüfen, ob das wirklich so ist, bevor du den Server öffentlich zugänglich machst. Im Zweifelsfall hilft dieses Kommando:

[src=bash]sudo shutdown -Ph 0 "Wartungsarbeiten"[/src]
 
Zuletzt bearbeitet von einem Moderator:
@Tone ich sehe nicht die Schuld bei dir, aber die Verantwortung hast trotzdem du :beer:
 
btw. Wenn man einen Dienst <Dienst> noch nie laufen hatte vorher

"<Dienst> best practice"
"<Dienst> secure"
"<Dienst> hardening best"

bei Google eingeben. Als absolutes Minimum, bevor man ihn mit mehreren Milliarden Computer verbindet.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben