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

Ebbene si, il mio blog non mi bastava! Sono stato contattato dall’amico marco, l’obiettivo è parlare in modo concreto di amministrazione di sistemi GNU/Linux prendendo spunto dai reali problemi affrontati nella vita lavorativa di ogni giorno, il sito è tuxblog.it.

Questo progetto non è un isola da sola in mezzo al nulla, fa parte infatti di una piccola rete di blog che si sta creando a cui collaborano daniel (PHP5Blog.it) e matteo (CSSBlog.it).

Il tutto riunito sotto la rete chiamata gagblog.it!

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 »

Forse siamo arrivati alla svolta, IPv6 sta diventando una realtà.

Primi fra tutti è l’ICANN, che ha cominciato nei gorni scorsi ad aggiungere registrazioni IPv6 sui suoi server di dominio.

Due articoli interessanti al riguardo si possono trovare su theinquirer.it e su iana.org, link gentilmente forniti dal Dott. Chiavone

Forse finalmente i miei studi universitari e le ore passate su IRC ai tempi d’oro torneranno utili

Ah per la cronaca ho trovato ora anche l’annuncio ufficiale dell’ICANN “IPv6 Address Added for Root Servers in the Root Zone“

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

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.

Questa sera discutendo col Dott. Chiavone, ero triste e affranto discutendo del fatto che IPv6 ancora non era decollato (ricordo che la mia tesi riguardava proprio su questo argomento)… ma questo mio stato d’animo è durato molto poco, dopo la segnalzione di questo articolo di PI intitolato “Il RIPE: IPv6 è molto più che urgente“.

Io lo sostengo da anni, e qui viene confermato gli indirizzi IP stanno finendo!! Ma come al solito, fino a quando qualcuno di grosso (un politico o chissà chi), non si incazzerà perchè non avrà un indirizzo IP libero per guardarsi il porno di turno, continueremo tutti a usare IPv4.

Io continuo a sostenere che le tecnologie per utilizzare IPv6 ci sono da parecchio tempo (non per niente ci ho fatto una tesi sopra), ma a causa di qualche interesse legato all’attuale schema di indirizzamento (si pensi ai provider che fanno pagare per dare indirizzi ip aggiuntivi, a volte anche senza alcuno scopo) non si iniziano a prendere provvedimenti o effettuare interventi per preparare la rete al passaggio al nuovo protocollo.

Io voglio IPv6!!!

Con IPv6 l’utente medio può fare esattamente le stesse cose che fa con IPv4: navigare, scaricare la posta, chattare, usar un ftp, connettersi a database. Tutte queste cose che ho elencato da ANNI ormai sono in grado di supportare nativamente IPv6.

Una volta, la scusa più banale era l’overhead dovuto al protocollo (intorno al 10% se non ricordo male), senza contare che in caso di passaggio a sistemi nativi IPv6 (e non incapsulati in IPv4) questo overhead sparirebbe quasi del tutto, e su linee molto veloci come una qualunque adsl a 2Mbit sarebbe pressochè imprecettibile.

A questo si aggiungono le problematiche tecniche di sostituzione dei router che non supportano ancora IPv6… ma io dico se da anni esistono router che lo supportano, perchè non hanno ancora fatto nulla!!!!

Sveglia!!!!

(p.s.: so che questo articolo non servirà a niente come al solito, ma magari qualcuno che non sa che cos’è l’IPv6 approfitterà per documentarsi.)

A chi non è mai capitato di porconare vedendosi una linux box con una bella scritta “kernel panic”, e oltre a questo incazzarsi perchè non si riesce nemmeno a scorrere la console per avere maggiori delucidazioni sugli errori che hanno portato al crash?
Ecco qua la soluzione ai nostri mai

echo "1" >/proc/sys/kernel/panic_on_oops

In questo modo prima di andare in crash la amcchina funziona ancora per pochi secondi in modo di dare tempo a klogd (ma penso funzioni anche per altro) di loggare tutti i dati che ci servono, e permetterci quindi di vedere in seguito con calma la causa del crash.