Cheatsheets

Esattamente qui una serie di cheatsheet per avere a portata di mano i comandi per fare un sacco di cose.

Grazie a http://www.datadisk.co.uk/

Protocollo DNS e le sue debolezze

Si è parlato molto della recente "scoperta" della grave vulnerabilità propria del protocollo DNS. Vulnerabilità causata da un problema di design e che quindi interessa molte, forse tutte le implementazioni software in circolazione.

E' stato trovato un workaround e le patches sono arrivate in tempi brevi; come al solito mi chiedo chi tra coloro che sono a rischio si è occupato di patchare.
Noi l'abbiamo fatto (tra l'altro grazie a questo ho scoperto cose che ignoravo) e la falla, diciamo, è stata tappata alla buona. La soluzione finale è, comunque, passare a DNSSEC, che per come è stato pensato, non può soffrire del problema del fratello protocollo più anziano.

Parlandone con la mia compagna, che è entrata in tempi recenti nel mondo lavorativo IT, mi ha chiesto di spiegarle, con un esempio, il problema.

E allora le ho risposto, che se ho ben capito io stesso, può immaginare questo:

"Il tuo conto BancoPosta al quale accedi quando hai bisogno di effettuare operazioni, potrebbe essere un bersaglio. Il problema che un attaccante può sfruttare nei DNS è l'avvelenamento della cache. Il nome del sito che normalmente viene risolto a 62.241.4.82, viene cambiato a un'altro dove risiede una copia contraffatta dello stesso. La vittima non se ne accorge facilmente, inoltre le pagine fasulle, hanno links che puntano a url familiari e corrette, a differenza dei siti di pishing, dove ci si accorge della truffa verificando i links e notando che puntano a indirizzi estranei e non conformi alle pagine originali che vorremmo visitare.
Quindi è possibile che non ci si accorga della truffa, o che ci si riesca troppo tardi."

Con un pò di fantasia si può pensare ad altri attacchi, quindi la situazione è piuttosto tesa, e le continue raccomandazioni a patchare ne sono prova.
Inoltre è uscito l'exploit, cosicchè, chi non è in grado di fabbricarsene uno, può sfruttare questo. E' contenuto in Metasploit, un tool per penetration testing, IDS e simili.

Qui una descrizione della vulnerabilità: http://www.kb.cert.org/vuls/id/800113

E la pagina dell'ISC, curatori di BIND, contenente l'advisory:

YOU ARE ADVISED TO INSTALL EITHER THE PATCHES, STAYING WITHIN YOUR MAJOR VERSION, (9.5.0-P1, 9.4.2-P1, 9.3.5-P1) OR THE NEW BETA RELEASES (9.5.1b1, 9.4.3b2) IMMEDIATELY.

The patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. The beta releases include optimized code that will reduce the impact in performance to non-significant levels.

Trovate il resto qui: http://www.isc.org/sw/bind/bind-security.php

Debian: voglio sempre lo stesso kernel!

Stasera cercavo di far smettere ad apt di continuare a propormi l'ennesimo update del kernel.
Questo per ovviare al "piccolo inconveniente" di dover aggiornare qualcosa come 10 revisions in 10 giorni ... un bit esagerato, trovo.

Il mio amico Norsys mi punta a una guida su Debianizzati.org, la cosa è semplice quanto interessante.

dpkg --get-selections > selections.txt

Questo mi genera un file di testo contenente la lista dei pacchetti e l'azione da intraprendere in caso di update.

Esse possono essere: install, deinstall, hold.

Ciò di cui ho bisogno è di mettere in hold l'attuale kernel contenuto nel pacchetto linux-image-2.6.24-16-386 e i suoi amichetti tipo restricted-modules ecc. Metto il tag hold, et voilà.

E' necessario reimportare le selezioni

dpkg --set-selections < selections.txt

A questo punto la presenza della revision 19 dell'immagine del kernel in un apt-get update è
censurata con grande happiness del sottoscritto.
C'è da considerare che, come anche indicato nella guida, questa scelta potrebbe inibire
l'update di altri pacchetti che dipendono da un linux-image più recente, ma questo era già stato
messo in conto e quindi è da consigliare un aggiornamento di tanto in tanto.

UNpatching di massa

In seguito a un problema sorto dopo un patching di massa di un Solaris10, dove un comando ha cessato di funzionare correttamente, ho deciso di ricorrere alla rimozione delle patch che interessano il binario in questione: si tratta di cfgadm, che semplicemente ha deciso di piantarsi quando lanciato; non muore nemmeno con un kill -9

In /var/sadm/patch ho i riferimenti per il ripristino dei files unpatched.
Vediamo a chi appartiene cfgadm:

pkgchk -l -p `which cfgadm`

mi ritorna un:

Referenced by the following packages:
SUNWcsu


Bene, la mia strategia è di verificare quali patches tra quelle presenti in /var/sadm/patch hanno partecipato alla modifica dell'installato del pacchetto SUNWcsu.
E di conseguenza rimuoverle. Un reboot, la speranza che la macchina "venga su".
Andiamo con ordine. E' necessario uno script, e qui ci si diverte:
Tipo questo:

root@ubigasmmg1->cd /var/sadm/patch
root@ubigasmmg1->for i in `showrev -p|grep SUNWcsu|/usr/xpg4/bin/awk '{print $2}'`
> do
> if [[ `ls -l|awk '{print $9}' |grep $i` ]]; then
> echo $i
> fi
> done

La prima riga apre il for sul risultato di un grep del pacchetto SUNWcsu ripulito con awk. Il particolare di usare quella versione specifica di awk viene dal fatto che il solito /usr/bin/awk aveva dei problemi nel trattare la lista generata da questa catena di pipe, sporcandola.
All'interno del for è necessario inserire la condizione che $i sia presente nella dir attuale; questo perchè, ovviamente, la lista generata nella riga prima è diversa da quella presente in /var/sadm/patch.
Il resto è di semplice comprensione e ne risulta:

125417-04
125500-01
125502-01
125550-01
126146-01
126148-01
126257-04
127112-03
127727-01
127758-01
127877-01
127921-01
127969-01


Ora si può rilanciare lo stesso script con il comando patchrm al posto dell 'echo.
Ha funzionato mica male, ora cfgadm non rimane più appeso senza speranza. Non resta che rileggermi uno a uno i README delle patch rimosse e cercare di capire dove salta fuori l'inghippo

Patch Check Advanced

Io uso PCA per gestire le patches sui servers che amministro. A detta di molti se non tutti, questo script Perl, sembra essere di gran lunga migliore di tutti i tools che Sun nel tempo ha tirato fuori, e direi missed, per l'installazione delle numerose patches, tra l'altro uno dei più painful aspetti di Solaris;
per qualche motivo, la cosa sembra non piacere a Sun, o è solo una mia impressione; fatto sta che di tanto in tanto PCA si "rompe" ... quanti cambiamenti fa Sun ai suoi siti?
L'unico modo per tenerlo in forma e funzionante e riscaricare lo script qui:
http://www.par.univie.ac.at/solaris/pca/news.html
stando al passo con gli sforzi di Martin Paul di ovviare agli inconvenienti che spesso rendono broken il suo geniale script.
L'ho appena sistemato dopo che per quasi tutto agosto (MP era in ferie) le patches non erano disponibili via pca.