E’ entrato ormai a far parte del parlare comune il termine PEC. Alcuni ancora non sanno cos’è, ve lo spiegherò brevemente.

Ad oggi, chiunque invii un’email, non ha mai la certezza assoluta che tale email sia arrivata a destinazione (le ricevute di ritorno classiche possono essere facilmente bypassate), per questo motivo è nata la PEC, meglio conosciuta come Posta Elettronica Certificata.

Tale sistema sta prendendo parecchia importanza, in quanto il suo utilizzo (data la natura della Certificazione dell’email, e la conferma temporale della consegna, della lettura e della notifica di ricezione) è equiparato all’invio di una raccomandata con ricevuta di ritorno. Questo vuol dire che con un servizio low cost, con 5-6 euro l’anno noi possiamo mandare quante raccomandate AR vogliamo, senza spendere nulla. Oltre a questo da fine anno, sarà obbligo per tutte le aziende ed enti pubblici disporre almeno di un indirizzo di questo tipo.

Per spedire un’email ad un indirizzo bisogna necessariamente possederne uno, oppure non si  potrà utiizzare questa tecnologia.

Per iniziare a studiare la cosa, ho creato il mio indirizzo PEC temporini.matteo@pec.it

Saluti

Parliamo oggi di un problema che si è presentato su uno dei siti con cui collaboro, nello specifico dopo gli ultimi update con l’installazione di ie8, il sito non poteva essere visto in quanto il plugin NextGEN Gallery, lo faceva crashare.

Tale problema è causata da alcune jquery errate nel codice (che speriamo vengano fixate a breve).

Sino ad allora ecco a voi il workaround

Inserite nel codice di wordpress nel codice di wordpress nel file header.php del vostro tema la stringa

<meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE7″>

in questo modo il sito viene fatto girare in compatibilità ie7 e il sito funziona perfettamente anche con ie8.

In alternativa qualora steste usando tale plugin altrove, potete inserire le seguenti righe di codice php per ovviare al problema:

1. if (strpos($_SERVER['HTTP_USER_AGENT'],“MSIE 8″)) {header(“X-UA-Compatible: IE=7″);}

2. if (strpos($_SERVER['HTTP_USER_AGENT'],“MSIE 8″)) {header(“X-UA-Compatible: IE=EmulateIE7″);}

Nel caso 1. fate girare il sito in compatibility mode ie7, nel secondo caso invece, lo fate girare con il motore standard di ie7.

In questi giorni mi sono trovato ad affrontare un problema che mi era già capitato e che su altri sistemi avevo risolto in altro modo, cioè la presenza di query in stato di sleep.

Nello specifico per risolvere il problema ho trovato della documentazione su internet che diceva di modificare il valore della variabile wait_timeout, ma su Ubuntu non funziona …

A detto di molte guide per fare questo bastava editare il file my.cnf o my.ini per cambiarlo ma di fatto non funziona.

Leggendo la documentazione di mysql ho letto invece che la variabile wait_timeout dipende direttamente dalla variabile interactive_timeout, pertanto editando il file di configurazione di mysql come segue

[mysqld]
…
interactive_timeout = 30
…

In automatico modifichiamo sia la variabile interactive_timeout che la variabile wait_timeout

In questi ultimi anni spesso mi sono trovato di fronte a questo problema: il resume dei file caricati via ftp è una cosa che deve supportare il server o i client?

Sino ad oggi me ne sono altamente sbattuto della risposta, avendo ormai da anni per le mani connessioni molto stabili, ma per alcune esigenze di questi ultimi mesi ho dovuto affrontare di petto il problema.

La risposta che posso darvi per esperienza personale è che il problema del resume dei file è una combo violentissima server e client.

Nello specifico il server ftp deve supportare il trasferimento binario e allo stesso modo il client.

Ora come ora tutti tutti i server ftp e tutti i client ftp li supportano entrambi, premettendo che i server ftp di default li hanno abiitati entrambi, possiamo ricondurre il problema solo al client.

Quindi per supportare il ripristino dei file non ci resta altro da fare che impostare il trasferimento dei file in modalità binaria (o binary).

Saluti
Matteo

Di cosa stiamo parlando? Alcuni di voi sicuramente sapranno che cosa sono i rootkit, per quelli che non lo sanno i rootkit sono delle “collezioni” di software utilizzate per amministrare una macchina linux senza possedere i privilegi di amministratore.

Solitamente vengono utilizzate dagli intrusi di un sistema, ad esempio un utente malevolo che riesce a sfruttare la vulnerabilità di un utente non privilegiato, potrebbe utilizzare un rootkit per procedere poi a una privilege escalation per diventare amministratore della macchina.

Per difendersi da questo tipo di utilizzi, la cosa migliore è cercare di tenere sempre aggiornato il sistema, soprattutto se si tratta di server online con accesso pubblico, quello di cui voglio occuparmi ora, non è tanto questo aspetto, ma è quello di controllare se la nostra macchina è stata “infettata” da un rootkit o meno.

A questo scopo ho iniziato ad utilizzare il programma rkhunter, che serve a controllare tramite degli hash, se i nostri file di sistema importanti sono stati in qualche modo modificati.

L’installazione in ubuntu si fa un semplice

apt-get install rkhunter

o

aptitude install rkhunter

Una volta installato il programma, procediamo con l’aggiornamento delle definizioni con il comando

rkhunter --update

ottenendo come output una cosa simile a:

[ Rootkit Hunter version 1.3.0 ]

Checking rkhunter data files...
Checking file mirrors.dat                                  [ No update ]
Checking file programs_bad.dat                             [ No update ]
Checking file backdoorports.dat                            [ No update ]
Checking file suspscan.dat                                 [ No update ]
Checking file i18n/cn                                      [ No update ]
Checking file i18n/en                                      [ No update ]
Checking file i18n/zh                                      [ No update ]
Checking file i18n/zhutf                                   [ No update ]

Ora facciamo partire la nostra prima scannata con il comando

rkhunter -c

questo metodo di scan ha una modalità interattiva, ad ogni particolare tipologia di scan dovrete premere enter, alla fine otterrete una tabella riassuntiva come quella seguente

System checks summary
=====================

File properties checks...
Files checked: 127
Suspect files: 0

Rootkit checks...
Rootkits checked : 110
Possible rootkits: 0

Applications checks...
Applications checked: 6
Suspect applications: 0

The system checks took: 3 minutes and 44 seconds

All results have been written to the logfile (/var/log/rkhunter.log)

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

Per ottenere uno scan non intereattivo aggiungete l’opzione -sk alla fine

rkhunter -c -sk

Fra i vari report rkhunter vi segnalerà che avete abilitato l’accesso root via ssh, che di norma non è il massimo della siscurezza e vi darà un segnale di errore tipo questo

Checking for allowed root login... Watch out Root login possible. Possible risk!
info: "PermitRootLogin yes" found in file /etc/ssh/sshd_config
Hint: See logfile for more information about this issue

Se sapete cosa state facendo, per eliminarlo basta editare /etc/rkhunter.conf

e cambiate la riga da ALLOW_SSH_ROOT_USER=no a ALLOW_SSH_ROOT_USER=yes

Una volta che avete lanciato il primo scan e tutto è corretto e non vi sono state segnalazioni strane, lanciate il comando

rkhunter –propupd

Questo comando, aggiorna le tabelle hash dei vostri file, di modo che se vengono modificati in qualche modo verrete notificati al riguardo. Quando farete degli update che aggiornano i file interessato da rkhunter, noterete che vi verrà notificato il fatto che tali file sono cambiati. Solitamente quando fate gli aggiornamenti, se tutto è corretto, dovreste eseguire questo comando dopo l’aggiornamento, di modo che le tabelle hash per i check verranno aggiornate con i nuovi eseguibili e non riceverete (giustamente), notifiche al riguardo.

Saluti

Questa guida vuole essere una quick reference per installare un server di posta con antispam e gestione relativamente semplice di utenti e domini, tramite ubuntu 8.04 TLS 64bit.

Le feature principali sono:

- SMTP-AUTH e TLS

- password encrypted

- Amavisd, SpamAssassin e ClamAV

Read the rest of this entry »

Di recente (neanche tanto a dire il vero) è stato resa nota una falla di molti dns che permette, tramite un attacco di dns poisoning, di manomettere i nomi host utlizzati da molti dns server sul pianeta.

Per fare un esempio pratico, ipotizziamo di voler aprire un sito come www.l.google.com che ha un indirizzo ip pari a 209.85.135.147, ora quello che fa un potenziale “hacker” non fa altro che sfruttare la falla del dns per fare risolvere www.l.google.com invece che con il suo indirizzo vero con un indirizzo qualunque tipo 127.0.0.1.

Ora per controllare se il proprio dns server è sicuro da questo tipo di problemi ci sono due strade:

1- collegarvi direttamente al sito DoxPara, sulla destra trovete la finestrella “dns checker” non dovrete fare altro che premere il pulsante Check My DNS.

2- oppure tramite linux mediante il comando dig.

Per il secondo punto il comando da lanciare è il seguente:

root@localhost:# dig +short @[your nameserver] porttest.dns-oarc.net txt

dove dovete sostituire [your nameserver] con l’indirizzo ip del dns di cui volete fare il controllo.

Esaminiamo ora i possibili risultati.

Se utilizziamo come dns uno dei dns del servizio OpenDNS otteniamo quanto segue:

root@localhost:# dig +short @208.67.222.222 porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.69.34.8 is GREAT: 26 queries in 4.1 seconds from 26 ports with std dev 15951"

se vedete scritta nell’ultima riga GREAT allora il dns è ok ed è stato correttamente patchato.

Nel caso contrario invece utilizzando uno dei dns Telecom STRANAMENTE, i dns non sono patchati e quindi vulnerabili a questo tipo di attacchi

root@localhost:# dig +short @151.99.125.1 porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"82.53.187.212 is POOR: 26 queries in 4.8 seconds from 1 ports with std dev 0"

come vedete questa volta nell’ultima riga trovate scritto POOR che indica che il dns non è correttamente aggiornato e quindi vulnerabile.

Su windows il comando è il seguente da lanciare da una console del DOS:

nslookup -querytype=TXT porttest.dns-oarc.net. ns1.nucleus.be

Saluti

Matteo

Aggiornato il sito alla versione 2.7 di wordpress.

Notificatemi eventuali problemi dovuti all’update o altro.

Grazie a tutti per la collaborazione.

Saluti

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