Il blog sull'informatica

Premesso che sia possibile fare questo, vediamo qual è la tecnica per bypassare il proxy aziendale (e le relative restrizioni).

Per prima cosa occorre configurare PuTTy affinchè riesca ad aprire un socket su localhost, possibilmente su una porta alta (fuori dal range delle well known, ovvero 1-1023), poichè è proprio da una di queste porte che solitamente partono le richieste HTTP/HTTPS dei client verso i server Web.

Per fare ciò occorre posizionarsi su SSH -> Tunnels, impostare come source port ad esempio la 4021 e quindi selezionare Dynamic ed Auto. Infine, è necessario cliccare su Add.

Ecco uno screenshot abbastanza esplicativo:

Per verificare che la porta sia effettivamente in bind occorre lanciare il seguente comando da prompt:

netstat -ano | find "4021"

Ok, ora non ci resta che configurare Firefox affinchè sfrutti il tunnel SSH per navigare.

Per fare ciò occorre posizionarsi si Strumenti -> Opzioni -> Avanzate -> Rete -> Impostazioni e settare come socks4 localhost avente come porta di ascolto la 4021.

Ora, poichè solitamente i nameserver locali consentono la risoluzione diretta solo dei nomi di dominio, è necessario fare in modo che Firefox utilizzi la macchina remota (ovvero il server SSH) come nameserver.

Per fare questo si deve accedere alle configurazioni avanzate del suddetto browser, digitando sulla barra degli indirizzi about:config.

Il parametro che ci interessa è network.proxy.socks_remote_dns, da settare su true.

A questo punto aprite la connessione SSH verso il server remoto ed enjoy!

Alla prossima.

Ultimamente mi è capitato di dover accedere via SSH su un server remoto. Peccato però che il firewall non consentisse traffico TCP sulla porta 22 in uscita. Proprio per questo motivo ho spulciato la configurazione di PuTTY ed ho individuato un'interessantissima funzionalità, ovvero Connection -> Proxy.

Una volta impostati i diversi parametri quali tipologia di proxy (HTTP), porta del proxy (8080) e credenziali (Username e Password), sono riuscito ad ottenere accesso alla shell, "aggirando" il firewall.

Ecco uno screenshot esplicativo:

Ma perchè è stato possibile fare ciò? Semplicemente perchè il proxy non riesce a distinguere (se non opportunamente configurato) il traffico HTTPS da quello SSH.

Occorre precisare, però, che tale trucchetto non funziona con Squid. Infatti, per default, il proxy in questione forwarda solo il traffico destinato e proveniente da determinate porte (tale operazione è possibile mediante la definizione di opportune ACL). Ad esempio:

acl SSL_ports port 443          # https
acl SSL_ports port 563          # snews
acl SSL_ports port 873          # rsync
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
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

Come potete notare, la porta 22 non è listata tra le safe ports.

Ergo se utilizzate Squid come proxy potete stare certi che per default è impossibile utilizzarlo come proxy per le sessioni SSH.

A presto.

In questo post abbiamo visto come impedire a squid di rivelare ai siti che stiamo visitando l'IP privato della nostra workstation. Adesso vi illustrerò alcune dritte per aumentare ulteriormente il livello di privacy offerto dal nostro proxy. 

Per prima cosa, dobbiamo evitare che il sito Web di destinazione si accorga che stiamo navigando mediante proxy. Per fare ciò è sufficiente inserire all'interno del file /etc/squid/squid.conf la seguente direttiva:

header_access Via deny all

e successivamente lanciare il comando

nightfly@nightbox:~$ sudo squid -k reconfigure

Successivamente, impediamo agli utenti della nosra LAN di visualizzare la versione di squid che stiamo utilizzando nel caso in cui quest'ultimo restituisca una pagina di errore:

nightfly@nightbox:~ sudo nano /etc/squid/squid.conf

e decommentiamo la stringa # httpd_suppress_version_string off, settandola su on:

httpd_suppress_version_string on

Infine, verifichiamo il livello di privacy offerto dal nostro proxy contattando il sito http://checker.samair.ru/. Se il risultato del test è high-anonymous (elite) proxy significa che il nostro lavoro si è concluso nel migliore dei modi.

A presto.