Archivi tag: blacklist

Aggirare il proxy mediante un tunnel SSH

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:

 

tunnel.jpg

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.

 

socks4.jpg

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.

IP pubblico blacklistato da out.virgilio.it

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.

blacklist.jpg

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).

Installazione e configurazione base di squidGuard

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

 

squidGuard

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:

dbhome /var/lib/squidguard/db/blacklists
logdir /var/log/squid

dest aggressive {
        domainlist aggressive/domains
        log verbose aggressive.log
}

dest gambling {
        domainlist gambling/domains
        log verbose gambling.log
}

dest hacking {
        domainlist hacking/domains
        log verbose hacking.log
}

dest porn {
        domainlist porn/domains
        log verbose porn.log
}

dest proxy {
        domainlist proxy/domains
        log verbose proxy.log
}

dest redirector {
        domainlist redirector/domains
        log verbose redirector.log
}

dest spyware {
        domainlist spyware/domains
        log verbose spyware.log
}

dest suspect {
        domainlist suspect/domains
        log verbose suspect.log
}

dest violence {
        domainlist violence/domains
        log verbose violence.log
}

dest warez {
        domainlist warez/domains
        log verbose warez.log
}

acl {
        default {
                pass !aggressive !gambling !hacking !porn !proxy !redirector !spyware !suspect !violence !warez
                redirect http://192.168.1.2/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.

In aggiunta, abbiamo deciso di loggare tutto ciò che viene negato o consentito da ciascuna blacklist. Tali log verranno salvati all’interno della dir /var/log/squid e per fare in modo che squidGuard sia in grado di scriverci dentro sarà necessario modificare il loro owner con il seguente comando:

nightfly@nightbox:~$ sudo chown proxy:proxy -R /var/log/squid/*.log

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.

Script bash per l’aggiornamento delle blacklist utilizzate da squidGuard

L’accoppiata squid + squidGuard rappresenta un’ottima soluzione per l’implementazione di un sistema dedicato al content filtering. Infatti, basta scaricare le blacklist aggiornate di squidGuard per avere un un filtraggio dei contenuti Web efficace ed efficiente.

 

squidguard

 

A tal proposito, ho pensato di realizzare uno scrip bash per l’aggiornamento automatico di tali blacklist. Ecco il codice:

#!/bin/bash

logfile=/var/log/squidguardupdate.log

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

        ERRORE1="Errore 1: Devi essere root per eseguire lo scrip"
        echo $ERRORE1
        echo "$(date) $ERRORE1" >> $logfile

        exit 1

fi

wget http://squidguard.mesd.k12.or.us/blacklists.tgz

tar -xvf blacklists.tgz

cd blacklists/

cp -R * /var/lib/squidguard/db

squidGuard -d -C all

chown proxy:proxy -R /var/lib/squidguard/db

squid -k reconfigure

cd ..

rm blacklists.tgz

exit 0

Tale scrip non fa altro che scaricare le blacklist mediante wget, compilarle ed aggiornare la configurazione di squid.

Per ulteriori chierimenti contattatemi.

A presto.