Am Wed, 4 Jun 2014 18:45:07 +0200 schrieb "Lentes, Bernd"
ich bin eben über seltsame Einträge im access_log des httpd gestolpert:
1.163.5.79 - - [10/May/2014:14:40:52 +0200] "CONNECT mx3.mail2000.com.tw:25 HTTP/1.0" 200 16566 "-"
Nicht gut, status code 200 heißt laut http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html , der "Gast" hat erfolgreich über Dein System auf einen fremden Server zugegriffen (gehe mal davon aus, dass mx3.mail2000 nicht bei Dir steht ;) Bei mir schlagen auch solche Requests auf... Connection attempts using mod_proxy: 1.163.222.253 -> mx0.mail2000.com.tw:25: 1 Time(s) 111.241.26.219 -> mx2.mail2000.com.tw:25: 1 Time(s) ...aber die werden dann abgelehnt... 405 Method Not Allowed mx0.mail2000.com.tw:25: 1 Time(s) mx2.mail2000.com.tw:25: 1 Time(s) Beides aus dem täglichen logwatch-Report.
Die IP's sind teilweise aus China und Taiwan. Nachdem was ich bisher gelesen habe (http://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_Tunneling ), kann man damit einen http-Proxy benutzen. Den habe ich aber nicht:
Denke schon, dass bei Dir ein Proxy läuft, wie der obige status code 200 belegt.
pc52974:~ # rpm -qa|grep -i apache
Das betrifft das Apache-Modul mod_proxy samt "Submodulen" und das ist m.W. kein extra rpm-Paket. Kontrollier mal Deine Apache-config auf das Laden von mod_proxy. Kenne die Apache-Systematik bei Suse nicht, also stimmen vielleicht die Pfade nicht, aber im Kern muss es ein Verzeichnis mit den vorhandenen Modulen geben. Bei RHEL sind die z.B. per ll /usr/lib*/httpd/modules/*proxy* zu finden. Alternativ "apache2" statt "httpd", "modules" heisst anders, etc.. Theoretisch könnten die Module auch statisch einkompiliert in den Apache2 sein, aber ist eigentlich unüblich. Die Liste der Module wird aber m.W. beim Start des Webservers geloggt. Dann gibt es irgendwo einen Aufruf, wo die gewünschten Module geladen werden. Steht meist irgendwo unter /etc/httpd bzw. /etc/apache2 - der betreffende Befehl (zum greppen) heißt "LoadModule". Für die Proxy-Funktionalität werden hauptsächlich mod_proxy.so und mod_proxy_http.so verwendet. Und dann muss da noch eine Konfiguration existieren. Am besten, Du greppst Deine Apache-config-files nach "Proxy", kann z.B. ProxyPass, ProxyRequests oder ProxySet heißen, ausserdem mag es noch einen Proxy control block namens "Proxy" geben.
Weitere Frage: das proxy-Modul vom httpd hat nix mit Squid zu tun, oder ? Es versuchen also Clients meinen nicht vorhandenen Proxy zu mißbrauchen. Kann ich was gegen diese Zugriffe tun ?
Apache kann ähnlich wie squid als Webproxy alias "forward proxy" eingesetzt werden. Typischer ist allerdings die Anwendung als reverse proxy. Um unerwünschtes proxying zu verhindern, kannst Du z.B. eine Proxy - directive mit einer ACL einrichten. http://httpd.apache.org/docs/2.2/mod/mod_proxy.html Man kann natürlich auch das Laden der proxy-module verhindern, aber dann funktionieren auch etwaige reverse-proxies für lokale Applikationsserver nicht mehr.
Außerdem habe ich noch dieses:
222.93.235.16 - - [27/Nov/2013:22:43:58 +0100] "GET http://www.google.com/ HTTP/1.0" 200 16566 "-"
Stand zu erwarten: Wenn schon der Zugriff auf SMTP-services über Deinen "Proxy" möglich ist, dann natürlich erst recht der Zugriff auf http-Server.
Wenn ich den GET mit der Protokollversion (GET http://www.google.com/ HTTP/1.0) absetze, kriege ich nach einigen Minuten eine Seite mit Statuscode 400, die vorgibt von www.google.com zu sein:
GET http://www.google.com/ HTTP/1.0
Wäre mir neu, dass man die Protokollversion einfach an die URL anhängen kann. M.E. frägt er hier eine URL auf google.com ab, die aus einem Leerzeichen und "HTTP/1.0" besteht.
HTTP/1.1 400 Bad Request
Ganz offenbar wurde HTTP/1.1 verwendet. Status code 400 ist eine Client Fehler - "malformed request" auf neudeutsch. Offenbar ist eine URL " HTTP/1.0" nicht erlaubt.
<p>Your browser sent a request that this server could not understand.<br /> </p> <hr> <address>Apache Server at www.google.com Port 80</address> </body></html>
Lt. tcpdump ist aber kein Paket zu www.google.com gegangen und es kam auch keines von dort. ???
Hm, kontrollier das besser nochmal en detail. Ansonsten vermute ich, dass dieser Request syntaktisch so falsch ist, dass ihn bereits der als Proxy arbeitende Apache ablehnt. Die formale Kontrolle der requests auf application level ist ja einer der zentralen Gründe für den Einsatz als ALG. Warum er das dann im Namen von www.google.com tut, entzieht sich meinem Vorstellungsvermögen. -- Gruß, Tobias. no email, only xmpp: crefeld@xabber.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org