Temporini Matteo

Si lo so in questi giorni sono monotematico, ma che ci posso fare son tutti infervorato dal nuovo browser!!!

Come potete vedere da http://www.spreadfirefox.com/it/worldrecord i geniacci di Mountain View ce l’hanno fatta, sono entrati nel guinness dei primati!!

Il programma più scaricato nel giro di 24 ore, 8 milioni di download!!!

Grandi!!!!

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

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 »

Stamane ho effettuate l’upgrade di Wordpress alla versione 2.3.1.

Non ho risonctrato alcun problema, e tutto pare funzionare regolarmente.

Tutte le indicazioni su come effettuare l’upgrade le trovata sul sito italiano http://www.wordpress-it.it, alcuni hanno segnalato qualche problema durante l’update, ma penso abbiamo sbagliato qualcosa o si siano dimenticati di seguire qualche passo importante.

I file per l’installazione lo trovate a questo link

http://www.wordpress-it.it/wp-content/archives/wordpress-it_IT-2.3.1.zip

mentre la guida per l’aggiornamento si trova a questo indirizzo

http://www.wordpress-it.it/wiki/Main/Upgrade-20

Si tratta di una relase di Bug Fix, fra le quali segnalo:

• Supporto ai tag per Windows Live Writer
• Correzione per il problema di login per gli utenti il cui indirizzo Blog differisce dall’indirizzo di WordPress
• Query al database per la tassonomia molto più veloci, specialmente quelle che eseguono interrogazioni di intersezione sui tag
• Correzioni all’importatore di link

Segnalatemi pure eventuali problemi che riscontrate.

Come al solito le problematiche al lavoro sono le più disparate, oggi mi sono dovuto occupare del tuning di un firewall che utilizzo sul lavoro.

Nello specifico per ragioni di comodità e facilità d’uso (purtroppo non sono l’unico a utilizzarei server e devo badare anche a questo aspetto), utilizzo firestarter.

Si tratta di un firewall molto semplice da utilizzare anche ai “non addetti ai lavori“, in quanto non si tratta altro che di un semplice front end grafico per iptables, assai più ostico da utilizzare per i principianti.

Questo breve documento non si occuperà pertanto di configurare il firewall (discretamene semplice anche senza documentazione) ma semplicemente spiegherà come apportare direttamente delle modifiche tramite iptables che sono escluse dalle casistiche previste dal frontend.

Il firewall l’ho configurato in un modo molto semplice, ho messo come policy di default tutto in drop, ed ho aggiunto le eccezioni per i servizi che mi interessavano.

Pertanto la mia situazione di partenza era che qualunque pacchetto inviato da e verso la macchina veniva scartato ad eccezione di: webserver, dns e posta.

Ora il problema che mi si era posto era il seguente: avevo dei simpatici “amici” che non avevano nulla da fare e ogni tanto senza preavviso iniziavano a dossare una macchina, e l’unica soluzione possibile senza dover intervenire sulla dorsale (di cui ovviamente non ho il minimo controllo) era di fare in modo che venissero scartate le connessioni di quella specifica rete.

La soluzione è stata molto semplice, con firestarter basta editare il file

[root@localhost ~]# nano /etc/firestarter/user-pre

e a questo punto aggiungere i comandi di iptables che ci interessavano, ad esempio

iptables -A INPUT -d 195.54.0.0/20 -j DROP
iptables -A INPUT -s 195.54.0.0/20 -j DROP
iptables -A OUTPUT -d 195.54.0.0/20 -j DROP
iptables -A OUTPUT -s 195.54.0.0/20 -j DROP
iptables -A FORWARD -d 195.54.0.0/20 -j DROP
iptables -A FORWARD -s 195.54.0.0/20 -j DROP

In tal modo vengono droppate tutte le connessioni che entrano, escono o solamente transitano su questa classe di ip.

Una volta aggiunte le righe che ci interessano basta dare un semplice

[root@localhost ~]# /etc/init.d/firestarter restart

ed ecco fatto, il nostro piccolo firewall personalizzato

Ovviamente con questo metodo si possono creare tutte le policy che ci interessano tramite i comandi di iptables.

In questo breve articolo descriverò brevemente come configurare l’accesso ad una shell senza dover digitare ogni volta la password, tramite scambio di chiavi RSA sfruttando il protocollo OpenSSH.

Mi è tornata utile tale funzione per gestire un backup incrementale remoto tramite rsync (magari un giorno scrivo due righe anche su questo così magari qualcuno mi da qualche consiglio), appoggiandomi sul protocollo criptato fornito dal servizio OpenSSH.

Ipotizziamo di operare in una LAN nella sottorete 192.168.0.0/24 e che la macchina da cui vogliamo effettuare l’accesso senza password sia la 192.168.0.2, mentra quella su cui vogliamo loggarci senza password sia la 192.168.0.3.

Dalla macchina dalla quale ci si vuole connettere senza digitare la password (192.168.0.2), digitiamo il seguente comando per generare la chiave RSA

[root@192.168.0.2 ]# ssh-keygen -b 2048 -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
f7:ec:0d:c8:f4:df:7a:6c:2b:1d:a1:59:ee:c7:ae:a0 root@192.168.0.2

Ora copiamo la chiave che abbiamo generato nella macchina di destinazione

[root@192.168.0.2 ]# scp /root/.ssh/id_rsa.pub root@192.168.0.3:.

Logghiamoci ora nella macchina alla quale ci si vuole connettere senza utilizzare la password e digitiamo il seguente comando

[root@192.168.0.3 ]#cat /root/id_rsa.pub >> /root/.ssh/authorized_keys

Finito, adesso dalla macchina 192.168.0.2 potremo loggarci sulla 192.168.0.3 senza digitare alcunapassword, ma non viceversa.

Questa tecnica può essere usata per gestire le connessioni tramite rsync appoggiandosi al protocollo OpenSSH.

[root@192.168.0.2 ~]# ssh root@192.168.0.3
Last login: Thu Jul 19 15:20:29 2007 from 192.168.0.2
[root@192.168.0.3 ~]#

Ebbene siamo giunti ormai alla slackware 12.

Siamo giunti alla versione 12, da giorni circolavano in reti articoli riguardanti la versione in versione Relase Candidate ma ora se provate ad aggiornare i vostri server/desktop alla versione current vi ritroverete con l’ultima versione

Fra le novità più importanti:

- kernel 2.6

- pacchettizzazione di X.Org 7.2 con supporto a XGL e Compiz (viva il 3d!!)

- GCC 4.1.2

e finalmente…

- apache 2  e php 5

vi linko l’output che ho già sul mio server (aggiornato a current) all’esecuzione del seguente comando

XXX@insidia:~$ cat /etc/slackware-version
Slackware 12.0.0
XXX@insidia:~$

Ci voleva questo aggiornamento finalmente

Purtroppo per esigenze legate al mio lavoro sono stato obbligato a usare Fedora core 5 (l’alternativa era Red Hat ma per questioni economiche è stata scartata).

Da quanto ne so Fedora nasce come una branca di Red Hat in versione free e fin qua nessun problema, solo che mi chiedo come può rilasciare una versione nuova nel giro di pochissimi mesi?

Nel mio caso ho iniziato ad utilizzare Fedora dal core 5, pochi mesi dopo è uscita la versione 6 (un flop incredibile è durata un mese scarso se non ricordo male) e adesso siamo alla versione 7… e per novembre sarà pronta la 8!!!

La domanda che mi pongo è molto semplice, ma tutte queste versioni (ricordo che Fedora core 3, 4, 5 sono ancora mantenute) per quanto tempo dureranno? Contando che tutte le possibilità di upgrade da una versione all’altra sono altamente sconsigliate uno cosa deve fare (da una versione all’altra cambiano i nomi dei pacchetti e non hanno previsto alcun tipo di risoluzione a questo problema)? Migrare i dati su nuovi server ogni 2-3 mesi?

Conosco parecchie aziende che la utilizzano per fini commerciali, ma sto sinceramente iniziando a pensare che non sia il massimo dell’affidabilità per quanto concerne un utilizzo commerciale.

Per quanto riguarda il suo funzionamento sinceramente non posso lamentarmi, in un anno di utilizzo non ho mai avuto mezzo problema negli aggiornamenti, a parte qualche errore di permessi sistemato in pochi minuti, però il giorno che diranno “da oggi fedora core 5 non la manteniamo più” oppure “entro il prossimo anno saremo a fedora 12″ cosa farà tutta la gente che utilizza questa ditribuzione?

A detta degli sviluppatori Fedora 7 (ndr.: questa si chiama Fedora 7 e non Fedora CORE 7) è stata definita come “Fedora 7 è stata fatta allo scopo di migliorare il modo in cui le future versioni di Fedora saranno fatte“, e questo mi fa pensare che si tratti solo di una specie di relase di test o di transito del sistema, su cui faranno degli esperimenti per future versioni.

Purtroppo il prodotto della apple per windows, è stato un vero e proprio flop. Sui blog online si leggono solo commenti negativi sul browser che avrebbe potuto dare filo da torcere a firefox ed explorer.

Oltre ai problemi legati alla sicurezza (a 24 ore dal rilascio è stato scoperto il primo bug), vi sono dei grossi problemi di stabilità anche in seguito all’esecuzione di azioni banalissime e non meno importanti gravissimi problemi legati alla visualizzazione del layout dei siti.

La speranza è che trattandosi solo di una versione beta le cose possano migliorare, o per lo meno è la speranza di tutti. Non posso ancora esprimere un parere personale in quanto non ho ancora avuto tempo/voglia di provarlo, ma lo farò quanto quanto prima!!!

Immagino che safari 3 per Mac sicuramente non abbia questi problemi di stabilità come al solito

Consiglio di leggere l’articolo di punto informatico a chi potesse interessare l’argomento .