Den Traffic kann man immer zuordnen wenn es nicht so wäre wie sollte dann
der Webserver z.b. wissen wo er was hinschicken soll. Das einzige was man
wenn nicht erfahren kann ist was im Traffic steckt wenn es verschlüsselt ist.
Auch mit einem unverschlüsselten Proxy sendet der Webserver seine Daten nur an den Proxy, wodurch für den Provider nur nachvollziehbar ist, dass Daten an den Proxy gesendet wurden und von dort Daten zurück kamen. Welche Website angesurft wurde, kann man dann nur mittels DPI ermitteln, was man z.B. durch einen SSH-Tunnel erschweren kann.
Beispiel:
Squid-Proxy mit folgender Konfiguration auf einem VServer einrichten:
Code:
http_port 8080
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_access_log none
cache_store_log none
hosts_file /etc/hosts
auth_param basic program /usr/lib/squid/pam_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 12 hours
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl password proxy_auth REQUIRED
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563 # https, snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow password
http_access deny all
http_reply_access allow all
icp_access allow all
forwarded_for off
Pfade nach Bedarf anpassen. Damit sollte jeder, der einen Shell-Account hat auch den Squid nutzen können. Nun einfach einen SSH-Tunnel zwischen Squid und localhost legen und schon hat man eine ziemlich sichere Verbindung, die die meisten Zugangssperren für's WWW umgehen kann. Ggf. muss man den Squid noch auf einen anderen Port legen wenn Port-Sperren aktiv sind. Spätestens wenn er auf Port 80 gelegt wird, sollten kaum noch Zugangssperren greifen, sofern die Verbindung mittels SSH verschlüsselt ist. Dem Browser muss man natürlich den Tunnel-Endpunkt also 'localhost' und den Port, zu dem man getunnelt hat, als Proxy angeben.
Spezieller Tipp für China: Wenn man auf die VServer-Squid-SSH-Lösung zurückgreift, sollte man sicherstellen, dass der VServer auch aus China erreichbar ist. Es gibt einige Anbieter in Deutschland die nicht 100% aus China erreichbar sind. Sobald man die Kiste also gebucht hat, gleich jemanden aus China via SSH auf der Kiste einloggen lassen. Erst wenn das geht, lohnt sich der Aufwand einen Squid einzurichten. Wenn es funktioniert, hat man eine sichere Lösung, wie man zumindest das WWW unzensiert nutzen kann. Ich betreibe das in ähnlicher Form bereits seit Jahren.
Für Zugriffe, die über das WWW hinaus gehen, empfiehlt sich ein Socks-Proxy, wo allerdings der Einrichtungsaufwand etwas höher ist. Das genannte Squid-Beispiel lässt sich auf Debian-Servern relativ einfach einrichten: 1. Squid-Paket installieren, 2. squid.conf anpassen, 3. Squid restarten, 4. Benutzer anlegen.
Für Windows gibt es Anleitungen für Putty, wie man SSH-Tunnel aufbaut. Bei Mac, Linux und Unix muss man nur folgenden Befehl im Terminal ausführen:
Code:
ssh -f user@server.de -L 8080:server.de:8080 -N
Damit wird ein Tunnel zwischen server.de Port 8080 und localhost Port 8080 gelegt, so dass man localhost mit Port 8080 auch als Proxy im Browser eintragen kann. Beim ersten Verbindungsaufbau wird der Browser dann nach dem Login fragen, woran man auch sieht, dass die Verbindung steht. Im Optimalfall sollte man den SSH-Login in der MOTD mit einem eindeutigen String ausstatten, mit dem sichergestellt ist, dass man wirklich auf dem richtigen Server ist. Dadurch vermeidet man Honeypots.