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.

Da un po' di tempo a questa parte mi capita di non ricevere le notifiche via mail da qualcuno dei miei server. Purtroppo ciò accade saltuariamente ed in modo pseudorandom, quindi per mettere bene a fuoco la problematica ho dovuto effettuare un'attenta analisi degli eventi.

Ma andiamo con ordine. Ieri, dopo aver aperto il mio client di posta elettronica, mi sono accorto che mancavano TUTTE le email di notifica del mio server casalingo (qualche giorno prima mi era successo la stessa cosa con il server di un amico commercialista). Accedo quindi alla shell via SSH e lancio il comando:

nightfly@nightbox:~$ cat /var/log/exim4/mainlog | grep mioindirizzoemail

Una delle entry riportava le seguenti informazioni:

** *@nightbox.it R=hub_user_smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2430: host rm.virgilio.it [62.211.72.20]: 550 mail not accepted from blacklisted IP address [188.11.59.93]

Uhm, il mio IP pubblico, ovvero 188.11.59.93 è stato blacklistato dall'SMTP di virgilio... ma per quale motivo?

Mi collego dunque al sito www.senderbase.org e digito il mio indirizzo IP pubblico. Come risultato mi becco una bella schermata in cui c'è scritto che l'IP da me digitato è classificato come poor ed è stato inserito nella pbl di spamhaus.org. Bene, ma cosa diavolo è questa pbl? Cito testualmente:

The Spamhaus PBL is a DNSBL database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP ranges.

Ok, quindi il problema è dovuto al fatto che ho inviato le email al mio MTA (out.virgilio.it) senza essermi prima autenticato. Inoltre, il controllo viene effettuato solo sugli IP pubblici che iniziano con 188.*, ovvero gli ultimi (in ordine di tempo) messi a disposizione per gli utenti di Aliceadsl.

Ne è la riprova il fatto che gli altri server che utilizzano un IP pubblico diverso da 188.* non vengono blacklistati, nonostante continuino a non usare l'autentica per connettersi all'SMTP di virgilio.

Per completezza, queste sono le blacklist su cui si basa l'SMTP citato in precedenza:

http://www.spamhaus.org
http://ipremoval.sms.symantec.com
http://cbl.abuseat.org
http://psbl.surriel.com

Ma come fare per risolvere il problema? Semplice, basta fare in modo che venga utilizzata l'autentica in fase di invio dei messaggi email (soluzione definitiva), oppure cambiare indirizzo IP pubblico, sperando che non ce ne venga assegnato nuovamente uno del blocco 188.* (soluzione temporanea).

A presto.

Aggiornamento

A quanto pare il controllo sull'autenticazione SMTP è stato esteso anche ad altri netblock, ad esempio il 79.*. Dunque vi consiglio di settare l'autentica per lo smarthost (se utilizzate exim4 come mail server locale, potete trovare informazioni utili in questo post).

Grazie a squid ed alla sua estensione squidGuard è abbastanza semplice realizzare un proxy open-source in grado di filtrare i contenuti Web.

Supponendo che squid sia già presente sulla nostra macchina (in questo post è riportata l'intera procedura di installazione e configurazione), vedremo adesso come installare e configurare correttamente squidGuard.

Per prima cosa scarichiamo ed installiamo tale estensione digitando il comando:

nightfly@nightbox:~$ sudo apt-get install squidguard

Ora, affinchè squid possa utilizzare squidGuard per i redirect, occorre aggiungere la seguente stringa all'interno del file /etc/squid/squid.conf:

#Squidguard
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

Fatto ciò, scarichiamo e scompattiamo le blacklist che verranno utilizzate da squidGuard per il content filtering:

nightfly@nightbox:~$ wget http://squidguard.mesd.k12.or.us/blacklists.tgz

nightfly@nightbox:~$ tar -xvf blacklists.tgz

nightfly@nightbox:~$ cd blacklists/

Copiamo tutto il contenuto della dir blacklists all'interno di /var/lib/squidguard/db:

nightfly@nightbox:~/blacklists$ sudo cp -R * /var/lib/squidguard/db

Compiliamo successivamente le blacklist appena scaricate:

nightfly@nightbox:~/blacklists$ sudo squidGuard -d -C all

Adesso cambiamo l'owner (sia a livello di gruppo che a livello di singolo utente) per la directory db il cui path è /var/lib/squidguard/db:

nightfly@nightbox:~$ sudo chown proxy:proxy -R /var/lib/squidguard/db

Modifichiamo, inoltre, il file squidGuard.conf presente nella dir /etc/squid inserendo le seguenti direttive:

dest aggressive {
        domainlist aggressive/domains
}

dest drugs {
        domainlist drugs/domains
}

dest gambling {
        domainlist gambling/domains
}

dest hacking {
        domainlist hacking/domains
}

dest porn {
        domainlist porn/domains
}

dest proxy {
        domainlist proxy/domains
}

dest redirector {
        domainlist redirector/domains
}

dest spyware {
        domainlist spyware/domains
}

dest suspect {
        domainlist suspect/domains
}

dest violence {
        domainlist aggressive/domains
}

dest warez {
        domainlist warez/domains
}

acl {
        default {
                pass !aggressive !drugs !gambling !hacking !porn !proxy !redirector !spyware ! suspect !violence !warez
                redirect http://ipvostramacchina/block.html
        }

}


Così facendo, abbiamo definito l'acl default che nega (!) l'accesso ai siti contenuti nelle varie blacklist (ads, aggressive, audio-video, ecc.), consentendo tutto il resto.

L'ultimo passo consiste nel realizzare la pagina su cui verranno reindirizzati gli utenti quando tenteranno di accedere ad un sito Web non consentito:

nightfly@nightbox:~/blacklists$ cd /var/www

nightfly@nightbox:~/blacklists$ sudo nano block.html

<html>
<head>
<title>Proibito</title>
</head>
<body>
PROIBITO
</body>
</html>

Ovviamente tale pagina (estremamente semplice e scarna) rappresenta solo un esempio. Potete infatti sbizzarrirvi e creare una pagina Web ad hoc, inserendo all'interno di essa il logo aziendale, eventuali indirizzi email per contattare gli amministratori, ecc.

Rendiamo effettive le nuove impostazioni aggiornando la configurazione di squid attraverso il comando:

nightfly@nightbox:/var/www$ sudo squid -k reconfigure

ed abbiamo finito.

A presto.