Temporini Matteo

Dopo aver spiegato come configurare Squid nei suoi elementi basilari, vediamo ora come aumentarne la sicurezza, inserendo un meccanismo di autenticazione, onde evitare che chiunque possa usare il nostro proxy per navigare.

Presupposto di questo articolo è che abbiate già uno squid funzionante, senza alcun meccanismo di autenticazione.

Innanzitutto dobbiamo discriminare come abbiamo installato il nostro squid

1- Compilato da sorgenti

2- Pacchetto Slackware

nel primo caso l’eseguibile ncsa_auth dovrebbe essere già installato nel nostro sistema, nel secondo caso purtroppo, dovremo provvedere a compilarcelo a mano.

Basta scaricare i sorgenti di Squid e fare quanto segue:

root@localhost:# wget http://www.squid-cache.org/Versions/v3/3.0/squid-3.0.STABLE6.tar.gz
root@localhost:# tar -zxvf squid-3.0.STABLE6.tar.gz
root@localhost:# cd squid-3.0.STABLE6
root@localhost:# ./configure && make ./configure --prefix=/usr/local/squid
root@localhost:# cd helpers/basic_auth/NCSA/
root@localhost:# make
root@localhost:# make install

A questo punto nella cartella /usr/local/squid/libexec/ncsa_auth dovremmo avere l’eseguibile che ci serve.

Editiamo ora il file /etc/squid/squid.conf

decommentiamo la riga

#auth_param basic program < uncomment and complete this line >

e facciamola diventare

auth_param basic program /usr/local/squid/libexec/ncsa_auth /etc/squid/passwd

dove il file /etc/squid/passwd sarà il file che conterrà user e password degli utenti che potranno usare il nostro proxy.

Ora non resta che specificare una acl che abiliti l’autenticazione con l’istruzione proxy_auth.

acl nomeacl proxy_auth REQUIRED

e di seguito permettere l’accesso a questa acl

http_access allow nomeacl

Creiamo ora il primo user che potrà usare il nostro proxy, tramite il comando

root@localhost:# htpasswd -c passwd nomeutente
New password:
Re-type new password:
Adding password for user nomeutente

Riavviamo lo squid con

root@localhost:# /etc/rc.d/rc.squid restart

da ora in avanti il nostro proxy chiederà l’autenticazione tramite una finestra, ogni volta che si vorrà navigare mediante lui.

Saluti

SQUID è un caching proxy per il web per i protocolli HTTP, HTTPS, FTP e molti altri.

Mi è nata la necessità di configurarlo a casa, in quanto lavorando spesso in giro per il pianeta a volte ho la necessità di una navigazione libera, che spesso non ci è concessa, e questa soluzione fa a pieno al caso nostro.

In questo breve articolo spiegherò (o almeno cercherò di farlo), come configurare squid in pochi passi, inserendo oltre alla navigazione tramite proxy, anche una rudimentale autenticazione onde evitare che chiunque ci possa usare per navigare.

Innanzitutto procuriamoci i sorgenti, i pacchetti della nostra distro o quello che meglio ci va per installarelo.

Nel caso di sorgenti il sito di riferimento è squid-cache.org, io utilizzando ul server slackware, mi sono avvalso del pacchetto messo a disposizione da linuxpackages.net.

Seguirà la spiegazione su come installare il pacchetto slackware (la compilazione da sorgenti la evito in quanto banale come al solito, ./configure && make all && make install fine).

Installiamo il pacchetto slackware, loggandoci come root

wget http://slackware.rol.ru/linuxpackages/Slackware/Slackware-12.1/Daemon/Squid/squid-3.0.STABLE6-i486-1zan.tgz

installpkg squid-3.0.STABLE6-i486-1zan.tgz

A questo punto il pacchetto è stato installato correttamente, e non ci resta che editare il file squid.conf

pico /etc/squid/squid.conf

Editiamo la porta su cui vogliamo che giri il nostro SQUID, nel mio esempio pratico ho utilizzato la porta 443, modificando la riga

http_port 3128 in http_port 443

all’interno di questo file non ci resta che modificare le seguenti voci

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

ora bisogna editare correttamente le ultime due voci cache_effective_user e cache_effective_group, che servono a indicare gli utenti effettivi con cui lo squid lavorerà, il consiglio è di creare un utente e un gruppo che si chiamano squid, poi chiaramente siete liberi di scegliere che gruppi e utenti volete al riguardo.

groupadd squid
useradd -g squid squid

ultima cosa che rimane da fare, almeno per questa guida, è impostare l’acl che permette la navigazione, andiamo a modificare

http_access deny all

e settiamola come

http_access allow all

e abbiamo finito.

Questa semplice configurazione, serve solo a tirare su lo squid e usarlo come proxy, non abbiamo fatto attenzione a nulla, andrebero impostate opportune acl per la lan, e eventualmente un meccanismo di autenticazione (cosa che spiegherò nel prossimo articolo).

Il tutto è stato creato seguendo la guida di riferimento http://tldp.org/HOWTO/TransparentProxy-4.html

Saluti

Solitamente sui server sono abbastanza contrario all’installazione di pannelli di controllo (plesk, cubepanel, cpanel o simili), in quanto non fanno altro che appesantire i server, portare bug e problemi di vario tipo.

Purtroppo in alcune situazioni essi sono indispensabili (pensate ad un provider che deve permettere ai proprio utenti di gestirsi tutto il loro spazio, e questi non sanno nemmeno cos’è un webserver).

Quello di cui vogliamo parlare oggi è webmin, si tratta di un pannello di controllo molto “low-level”, non è molto user-friendly come ptorebbe essere un plesk, è leggerissimo e permette di gestire pressochè qualunque servizio all’interno di un server (cosa che nessun altro pannello di controllo fa, solitamente si limitano alla parte web-hosting).

Prima di iniziare installiamo i pacchetti necessari sulla nostra debian:

apt-get install libnet-ssleay-perl openssl libauthen-pam-perl libio-pty-perl libmd5-perl

senza questi pacchetti non potremmo installare il nostro pannello, per cui fatelo.

Ora scarichiamo gratuitamente dal sito www.webmin.com il nostro file .deb nelo specifico al momento in cui sto scrivendo l’articolo siamo alla versione 1.400, ora con un semplice

wget http://garr.dl.sourceforge.net/sourceforge/webadmin/webmin_1.400_all.deb

installiamo semplicemente il pacchetto tramite dpkg

dpkg -i webmin_1.400_all.deb

ora non ci resterà altro da fare che accedere tramite un browser all’url https://ip.del.nostro.server:10000

Il tutto è corredata da una svariata quantità di plugin aggiuntivi e di terze parti per poter configurare anche servizi non previsti di default, fra i quali vi segnalo Virtualmin per poter avere una migliore gestione edgli utenti e poter dare loro accesso a particolari sezioni o gestirsi autonomamente i propri dati.

Questa guida non vuole essere il solito howto dove si spiega, che in iptables, ci sono le catene, le policy di default, quali sono e come funzionano, ma vuole essere una versione più pratica di un howto, e spiegare come configurare un firewall per linux con le seguenti caratteristiche:

- policy di default: drop di tutti i pacchetti

- permettere solo ai servizi che ci interessano di essere accessibili all’esterno

- permettere certi servizi accessibili solo dalla LAN

caso tipico di confiurazione di un firewall in ambito aziendale.

Per prima cosa impostiamo le policy di default in DROP, in modo che qualunque cosa venga scartata se non permessa dalle nostre regole successive Read the rest of this entry »

Se avete un sistema a 32bit o semplicemente perchè siete pigri non avete installato una distribuzione a 64bit, quelo può essere la causa del vostro problema.

Con semplici calcoli matematici, che non vi riporto, è possibile infatti capire che con 32bit è possibile indirizzare al massimo circa 4gb di ram.

Per ovviare a questo ci sono due strade

1- installare o ricompilare il vostro kernel con l’estensione PAE

2- installare una versione a 64bit del vostro sistema linux, se ovviamente è possibile.

Mi soffermo sul primo punto.

Nel caso in cui vogliate installare un kernel precompilato come per esempio su Centos o Fedora vi basta installare la versione del kernel con questa estensione, semplicemente con il comando

yum install kernel-PAE

In alternativa dovete ricompilarvi il kernel a manina, abilitanto le opzioni

Processor type and futers –> High Memory Support

e scegliere fra le tre opzioni possibili

off
4 GB
64 GB

vi bastano 64gb di ram adesso?

Questo articolo serve a correggere un problema che si può verificare Cyrus IMAP, nel caso in cui utilizzi troppa memoria.

Nello specifico l’output che si legge in /var/log/maillog è il seguente:

DBERROR db4: Logging region out of memory; you may need to increase its size

All’inizio questo errore compare sporadicmanete, poi con il passare dei giorni aumenta, sino ad arrivare al blocco totale della macchina.

La soluzione a tutto questo è qumentare lo spazio destinato al logging del database Berkeley D, per fare questo dobbiamo aumentare la regione di cache di Cyrus (dare una letta eventualmente a Cyrus performance FAQ).

Creiamo il file DB_CONFIG nella cartella /var/lib/imap/db/ e all’interno mettiamo le seguenti righe:

# cat /var/lib/imap/db/DB_CONFIG
set_cachesize 0 2097152 1
set_lg_regionmax 1048576

In questo modo abbiamo settato la dimensione della cache a 2MBin un segmento (la documentazione relativa la potete trovare su Berkeley DB docs), e la regione di log a 1MB. Su sistemi fedora pare siano 648K e 96KB, rispettivamente.

Dopo aver messo il file al suo posto, fermate cyrus, lanciate il comando

db_recover -h /var/lib/imap/db

e avviate cyrus.

Ora per ottenere le statistiche e vedere che effettivamente tutto sia corretto eseguiamo i comandi

# db_stat -m -h /var/lib/imap/db

e

# db_stat -l -h /var/lib/imap/db

db_recover e dbstats fanno parte del pacchetto db4-utils.

La saga dei miei piccoli how-to sulle configurazioni di mrtg non finisce.

Questa volta mi serviva avere uno strumento per controllare il carico di lavoro del dns, dove per carico di lavoro non intento i carichi della CPU (già discussi nell’articolo sulla configurazione dell’snmp di questo sito).

Un buon parametro per effettuare questi contorlli su un DNS (Domain Name System) è il numero di query al minuto che vengono fatte, in tal modo è possibile avere una cronostoria e una rappresentazione di questo parametro che ci permette di valutare il numero delle richieste ed eventualmente evidenziare potenziali anomalie (es: un tetnativo di DDoS sulla porta 53 con un numero elevato di query).

Il numero di query sul dns non verrà generato a partire da un parametro snmp, bensì da uno script che effettua il parsing dei file di log del bind.

Per ottenere questi log dobbiamo modificare il file /etc/bind/named.conf.options (se avete un unico file probabilmente sarà /etc/named/named.conf o /etc/bind/named.conf) ed aggiungere le seguenti righe:

zone-statistics yes;
statistics-file "named.stats";

e rivviamo il named con

/etc/init.d/named restart

oppure

/etc/init.d/bind9 restart

a seconda della distribuzione che utilizzate. Ora all’interno del file /var/cache/bind/named.stats avrete delle statistiche sul numero di query per i singoli domini.

Il named ora è configurato correttamente, dobbiamo utilizzare i fati contenuti in nel file named.stats e utilizzarli con mrtg per generare i grafici.

Questo viene fatto utilizzando uno script (lo potete scaricare tramite wget).

Salviamo il file all’interno della cartella /etc/mrtg/ o dove avete le vostre configurazioni di mrtg ed editiamo il file /etc/mrtg/mymrtg.cfg aggiungendo quanto di seguito riportato

Target[mydomain_DNS]: `/etc/mrtg/dnsstats.pl`
Options[mydomain_DNS]: gauge,growright,nopercent,integer,unknaszero
Title[mydomain_DNS]: DNS Server
RouterUptime[mydomain_DNS]: public@localhost
MaxBytes[mydomain_DNS]: 32000
AbsMax[mydomain_DNS]: 64000
WithPeak[mydomain_DNS]: wmy
Colours[mydomain_DNS]: YELLOW #F9C000,RED #F90000,LIGHT YELLOW #FFFFBB,LIGTH RED #FF8080
ShortLegend[mydomain_DNS]:queries/m
YLegend[mydomain_DNS]: Qs per Minute
Legend1[mydomain_DNS]: Queries received over 1 minute
Legend2[mydomain_DNS]: Failed Queries received over 1 minute
Legend3[mydomain_DNS]: Maximal Queries over 5 minutes
Legend4[mydomain_DNS]: Maximal Failed Queries over 5 minutes
LegendI[mydomain_DNS]: Queries:
LegendO[mydomain_DNS]: Failures:
PageTop[mydomain_DNS]: <H1>DNS Info</H1><TABLE><TR><TD>System:</TD> <TD>mydomain</TD></TR><TR><TD>Maintainer:</TD> <TD>Matteo Temporini (temporini.matteo@gmail.com)</TD></TR><TR><TD>Description:</TD><TD>DNS Monitor</TD></TR><TR><TD>Details:</TD> <TD>Query Monitor</TD></TABLE>

Mi raccomando fate attenzione che l’ultimo parametro stia tutta sulla stessa riga o vi darà errore.

Ora non ci resta altro da fare che rigenerare l’index.html di mrtg con il nuovo parametro

indexmaker --output=/var/www/html/mymrtg/index.html /etc/mrtg/mymrtg.cfg

e gustarci i nostri grafici che vedete qua sotto

Per esigenze non dipendenti dalla mia volontà, mi si è presentato il problema di dover realizzare dei piccoli filmati dimostrativi su come utilizzare alcuni siti web su cui lavoro ogni giorno.

In un primo momaento avevo pensato di utilizzare Windows, in quanto dal punto di vista della multimedilità forse è migliore di linux, ma poi mi son detto come al solito “perchè dalla vinta a zio Bill?”, e così sono riuscito a fare tutto utilizzando software free e opensource per linux, tra l’altro in modo semplice e intuitivo.

Per fare questo ho utilizzato due programmi: Read the rest of this entry »

Salve, oggi lavorando con vmware mi è capitata una cosa assai strana, all’avvio di una virtual machine, mi si è presentato questo errore:

“The network bridge on device VMnet0 is temporarily down because the bridged Ethernet interface is down. The virtual machine may not be able to communicate with the host or with other machines on your network.“

Ho iniziato a cercare su internet per problemi simili, ho trovato moltissimi thread al riguardo ma nessuno mi dava la soluzione corretta.

Ho iniziato a cercare da solo il problema e finamente ho capito cos’era. Dopo un aggiornamento hardware della macchina l’interfaccia eth0 non esisteva più, al suo posto vi era eth1, il problema era che il brdige veniva creato comunque su eth0 anche se non esisteva più.

Per risolvere il problema è stato sufficente modificare il file /etc/vmware/locations e sostituire tutte le occorrenze di eth0 con eth1, riavviare vmware server e tutto ha funzionato alla perfezione.

Problema del giorno… quante volte capita che qualche script non sicuro (es. form php senza controlli di sicurezza sull’inserimento dei dati e conseguente invio di un’email), riempia le code dei nostri server di posta? A me sinceramente molto spesso (si pensi a qualcuno che crea uno script di “test” che basta lanciarlo e viene spedita un’email, lo script viene dimenticato li e trovato da qualche bontempone che si diverte a esguirlo centinaia di volte… voi direte “ma chi vuoi che lo faccia?!?!?!?” e io vi rispondo dicendo solo… “più di quanti si possa immaginare”).

Conseguenza di tutto questo sono ore perse a cercare qualche script, sito o altro responsabile del fattaccio, con conseguenti improperi verso ogni genere di essere vivente vi si presenti vicino.

Read the rest of this entry »