Fix_n2: Tor’s white_list?

Tratteremo nell’articolo attuale alcune questioni (il concetto di white list & black list) relative all’uso della rete TOR.

Per capire bene come la rete TOR nel valutare di accogliere un nuovo sito (come “miosito.onion”) si protegge da un utente che sia autore di un possibile “nodo” di TOR non correttamente configurato .. si deve leggere il mio articolo precedente:

dalla collezione:

https://6viola.wordpress.com/deep-web/

mi sto riferendo, in particolare a Lez.23:

https://6viola.wordpress.com/2018/12/22/fix-how-to-install-a-hidden-service-on-apache-over-ubuntu-16-4-22-12-2018/

Riassumo la situazione già precedentemente esposta e poi passo ai dettagli di essere in white list con TOR:

L’articolo precedente -se ci riflettete- è una impostazione direct-engineering!

E cioé senza rinviare ad altri link, ma partendo da una situazione ex novo, vergine, ci dice come mettere on line -in locale- cioé presso il computer che fa da server (apache) un sito web da noi realizzato, anche solo una pagina html, che dica per esempio:

“ciao mondo!”

Ora dobbiamo fare .. messo un sito miosito.onion che sia finito in black_list .. le pulizie dalla cache sul server, poiché -almeno nel mio caso- ho modificato più volte la impostazione di configurazione per verificare il funzionamento in locale, come caricamento della pagina, ma anche in remoto (con varie tipologie di ftp, anche ssh, ma non solo)(**).

(**) 18.01.2019, ore 22.30:
Dobbiamo aggiungere che la difesa non si basa solo su una base di dati interna al server e riempita dalla “rete TOR” presso il server che mette on line il miosito.onion! Ma anche in riferimento a “risorse esterne”! Sebbene il percorso sia “casuale” tra un nodo sorgente e un nodo destinazione, ciò non toglie che un indirizzo può avere le seguenti caratteristiche:
1) non essere mai entrato in rete TOR
2) essere già entrato in rete TOR secondo una configurazione di tipo a caricamento solo locale
3) essere già entrato in rete TOR secondo una configurazione di tipo a caricamento ANCHE da remoto.
Da cui oltre che la funzione di “ricerca di un link” ciascuna zona TOR ha anche una funzione di “assegnazione di hostname & private_key”, ma anche di

  • verifica se nella cartella dedicata agli hidden-service .. hostname & private_key sono vuote (e nel tal caso vengono riempite)
  • verifica se nella cartella dedicata agli hidden-service .. hostname & private_key sono piene (e nel tal caso vengono corredate) .. e quindi corredate delle info elaborate dai nodi adiacenti che già conoscono quell’indirizzo. 

Nonostante la nota (**) qui sopra, nel resto del presente articolo provavamo a pulire la cache del server e in una prima fase lasciamo la hostname e private_key per verificare se il sito onion è letto da remoto con il vecchio indirizzo. Ci accorgeremo alla fine di questa sperimentazione che siamo ancora in black list. E quindi con le modifiche del seguito t1 fino a t14 daremo conto se siamo riusciti a raggiungere la visibilità da remoto chiedendo un nuovo indirizzo avendo cancellato anche hostname e private_key nella configurazione solo da locale

Per intanto metto qui di seguito la sola configurazione senza avere tolto hostname e private_key

start (1) modifica!

Per pulire la cache sul server, però, non si può accedere direttamente, e serve il “reverse engineering”!

Cioé ci dobbiamo chiedere .. cosa ci ha fatto perdere il controllo degli indirizzi hidden?

Quando e come “abbiamo ceduto il diritto di cancellare il contenuto e gli indirizzi hidden“?

Si deve andare -allora- alla procedura della Lez.23 già sopra citata e che ripetiamo:

https://6viola.wordpress.com/2018/12/22/fix-how-to-install-a-hidden-service-on-apache-over-ubuntu-16-4-22-12-2018/

e notare che questo è avvenuto -principalmente- scrivendo:

sudo chown R debiantor:debiantor /var/{lock,log}/apache2 /var/www

ma prima ancora avevamo eseguito:

++

cit on1

++

3. Set permissions for debian-tor

Nota Bene: “t” sta per time; “t1” è indicato nel seguito, quindi “t4” è riviato a _dopo_ “t1”..

(t4; start): scambio debian-tor & www-data

vim /etc/apache2/envvars

Comment out:

#export APACHE_RUN_USER=www-data
#export APACHE_RUN_GROUP=www-data

And add:

export APACHE_RUN_USER=debian-tor
export APACHE_RUN_GROUP=debian-tor

Save (Esc :w) and quit(:q).

(t4; stop)

++

cit off1

++

Quindi “per riprendere il controllo” (per riportare il sistema in white list) .. dobbiamo fare l’inverso!

Cioé inabilitare debian-tor (grazie ad aggiungere #) e poi abilitare www-data (togliendo il  simbolo # dall’inizio della riga in cui compariva).

Però prima di procedere a tali modifiche dovremo fermare sia apache2 che tor e lo faremo con le seguenti istruzioni:

(t1)
scollegarci dalla connessione al web

(t2)
sudo service apache2 stop

#ferma il server apache

(t3)
sudo service tor stop

#ferma il software tor

stop (1) modifica!

start (2) modifica!

Esaminiamo ancora il seguito di quanto fatto nella Lez 23 (per fare l’inverso):

++

cit on 2

++

sudo chown -R debian-tor:debian-tor /var/{lock,log}/apache2 /var/www

++

cit off 2

++

con questa istruzione l’utente (user) debian-tor, del gruppo (group) debian-tor, diveniva il proprietario delle directory indicate!

Quindi, per fare l’inverso, dovremo scrivere:

(t5; start)

si noti che abbiamo già fermato apache2

con la seguente istruzione da konsole ubuntu cambiamo il proprietario delle directory; il proprietario diviene www-data ..

sudo chown -R www-data:www-data /var/{lock,log}/apache2 /var/www

(t5; stop)

stop (2) modifica!

start (3) modifica!

++

cit on 3

++

4. Secure your private key
vim /etc/apache2/apache2.conf

nota bene: la modifica seguente va _aggiunta_ a quanto già esiste come “FilesMatch”:

<FilesMatch "private_key">
        Require all denied

Save and quit.

++

cit off 3

++

Dovremmo scrivere # davanti alla <FilesMatch “private_key”> & seguito .. così:

#<FilesMatch “private_key”>
#Require all denied
#</FilesMatch>

ma poiché stiamo togliendo la proprietà a debian-tor di esame e NON esistono più gli indirizzi hidden, possiamo anche trascurare tale modifica, poiché alla fine di queste modifiche dovremmo rimettere in linea “miosito.onion” e quindi dovremo questa volta fare engineering diretto!

stop (3) modifica!

start (4) modifica!

Esaminiamo:

++

cit on 4

++

vim /etc/apache2/conf-enabled/security.conf

nota bene: le 2 righe seguenti NON vanno aggiunte alla configurazione originaria, ma devo _modificare_ la configurazione originaria: in particolare evitano di dare informazioni sul tipo di ServerSignature (grazie ad Off) e Tokens (grazie a Prod)
more info:
https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

ServerSignature Off
ServerTokens Prod

Save and quit.

++

cit off 4

++

In questo 4° esame bisogna solo fare un controllo che la ServerSiganture e ServerTokens non siano scritte più di una volta e magari contradditorie!

Poiché si può lasciare il file come indicato sia in direct & anche in inverse engineering!

stop (4) modifica!

start (5) modifica!

sulla 5°  modifica (equivalente al passo 5 dell’articolo che stiamo seguendo: generazione di una pagina index) si può tranquillamente NON operare sia in modalità diretta che inversa, a meno di non volere correggere sia l’indirizzo dove è il file index, e anche il contenuto del file index

stop (5) modifica!

start (6) modifica!

E’ molto importante notare che con la situazione diretta che cito:

++

cit on 6

++

6. Configure tor

errata_N1:

cat >> /etc/tor/torrc << EOF 
HiddenServiceDir /var/www
HiddenServicePort 80 127.0.0.1:80
EOF 

 

corrige_N1:
cat >> /etc/tor/torrc << EOF
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
EOF

++

cit off 6

++

.. è molto importante -dicevo- notare che si stanno abilitando le directory “hidden” sia come indirizzo che come porte ..

quindi andrà lasciato della fase .. di volere cambiare gli indirizzi hidden ..

(t6; start)

supponiamo di volere entrare con

vim /etc/tor/torrc (anziché con cat)

per operare sugli indirizzi hidden di tor dobbiamo configurare come nelle 2 righe seguenti:

#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80

(t6; stop)

prima di entrare a cancellare negli hidden indirizzi.

poi andrà riabilitata la situazione dopo avere cancellato i file cache negli hidden indirizzi.

stop (6) modifica!

start (7) modifica!

++

cit on 7

++

vim /etc/apparmor.d/system_tor

Add:

owner /var/www/** rwk,

++

cit off 7

++

NON è necessario abilitare e disabilitare la citazione qui sopra!

Infatti in system_tor scrivendo:

owner /var/www/** rwk,

Non stiamo modificando chi è il proprietario! ma solo ciò che può fare!

Eviteremo quindi di fare cambiamenti inutili.

stop (7) modifica!

Ora le operazioni di cancellazione in zona hidden, ma anzitutto vediamo la situazione:

(già riportata in Lez.23)

copio ed incollo da konsole ubuntu 16.04:

(t7; start)

root@lino-Precision-5530:/var/lib/tor/hidden_service# cd /var/lib/tor
root@lino-Precision-5530:/var/lib/tor# ls

(t7; stop)

situazione della memorizzazione dopo ls:
cached-certs cached-microdescs ftp-service lock
cached-microdesc-consensus cached-microdescs.new hidden_service state


esempio di cancellazione del file “state”

(t8; start)

root@lino-Precision-5530:/var/lib/tor# rm /var/lib/tor/state

(t8; stop)

una volta svuotata la cartella ftp-service ..

esempio di cancellazione della cartella “ftp-service” qui  di seguito:

(t9; start)

root@lino-Precision-5530:/var/lib/tor# rmdir /var/lib/tor/ftp-service

(t9; stop)

Nota Bene: nel caso che la directory sia hidden_service .. si può lasciare e sarà tor a riempire con un nuovo hostname e private_key che saranno diversi da quelli vecchi se abbiamo deciso di sperimentare un nuovo indirizzo per verificare se riusciamo a rientrare in white list.

situazione dopo le “pulizie” .. lascio solo la vecchia cartella hidden_service e il suo contenuto in 2 file (1)hostname (2)private_key

root@lino-Precision-5530:/var/lib/tor# ls
hidden_service

Ma non appena mi ricollego on line trovo:

root@lino-Precision-5530:/var/lib/tor# ls
cached-certs cached-microdescs  lock
cached-microdesc-consensus cached-microdescs.new hidden_service state

e va NOTATO che ho sempre il precedente indirizzo e la associata private_key

sarebbero cambiate (hostname & private_key) solo se lasciavo la cartella hidden_service vuota.

°°°°°°°°°°°°°°°°°°°°°°°°

SPERIMENTAZIONE:

°°°°°°°°°°°°°°°°°°°°°°°°

Ore 15.51 del 17 gen 2019

(t10; start)

ripristino le inizializzazioni di tor:

significa che _prima_ di rimettermi on line devo ripetere quanto è impostato alla Lez. 23:

https://6viola.wordpress.com/2018/12/22/fix-how-to-install-a-hidden-service-on-apache-over-ubuntu-16-4-22-12-2018/

e cioé riconfigurare tor come se fosse la prima volta.

infine riavviare tor > riavviare apache2 > rimettermi on line.

(t10; stop)

 

nota bene:

fermare, prima di eseguire le modifiche, con

service tor stop

il servizio di tor, altrimenti .. nonostante tor sia scollegato dal web .. tor tende a scrivere negli indirizzi hidden.

seguo la traccia dal blog di come si programma per avere tor online (la installazione di tor non ci è utile, poiché useremo quella vecchia).

(1) passo

tor è già installato.

(2) passo

vado a controllare ports.conf

all’indirizzo /etc/apache2/ports.conf

è attiva solo la porta 80 come desiderato.

(t11; start)

(3) passo

vado a controllare envvars

all’indirizzo vim /etc/apache2/envvars

(3)-a disabilito www-data, abilito debian-tor

(t11; stop)

(t12; start)

(3)-b lancio:

sudo chown -R debian-tor:debian-tor /var/{lock,log}/apache2 /var/www

(t12; stop)

(4) passo

controllare apache2.conf

all’indirizzo vim /etc/apache2/apache2.conf

dunque non serve di “manutenzione”.

la private_key (in apache2.conf) era stata lasciata come deve essere perché tor sia abilitato
(poiché non inabilitava comunque la pulizia della cache hidden).

dunque non serve di “manutenzione”.

La security.conf è all’indirizzo seguente:

vim /etc/apache2/conf-enabled/security.conf

era già impostata affinché tor sia abilitato.

dunque non serve di “manutenzione”.

(5) passo

la test page non mi serve

(6)-a passo

devo entrare all’indirizzo seguente per verificare la situazione:

(t13; start)

vim /etc/tor/torrc

da disabilitate ad abilitate le due righe seguenti:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

(t13; stop)

(6)-b passo

controllare

vim /etc/apparmor.d/system_tor

che deve avere scritto:

owner /var/www/** rwk,

era stato lasciato come serve per abilitazione di tor.

dunque non serve di “manutenzione”.

(7)

  • t0: abilitare tor
  • t1: abilitare apache2
  • abilitare wi-fi
  • abiliatare localhost

(t14; start)

sudo service tor start
sudo service apache2 start
abilito wi-fi
abilito localhost

(t14; stop)

stop

verifica della convergenza:

si vede ora il miosito.onion?

NO! alla data 18-01-2019, ore 22.36
SI’! alla data 20-01-2019, ore 16.20 (con la procedura da t1 fino a t14: avendo richiesto un nuovo nome a dominio che è il seguente:
www.4nplovidwsib43pn.onion

Considerazione del 18-01-2019, ore 22.36
E’ stata una vera sorpresa -per noi- constatare la assenza di flessibilità riconfigurazione della architettura TOR. Si fa fiducia, nel progetto TOR, su un meccanismo di facilità di riottenere un nuovo indirizzo onion e si rinuncia alla ipotesi di potere tornare indietro a una configurazione solo in locale, almeno per una fase di studio, sia sul server che chiede un indirizzo e sia sul browser che viene esentato di una vera ricerca laddove si chiede un indirizzo non più di una configurazione con socks e né proxy. La collocazione geografica di un server è senzaltro una informazione da tenere riservata, in una logica di criptazione e riservatezza. E proprio per questo rendere “non riconfigurabile” un indirizzo di un sito porterà a un consumo in aumento di “richiesta di nuove locazioni” per chi sperimenta. Ciò porterà a stringhe sempre più lunghe di indirizzamento per l’esaurirsi delle stringhe disponibili. Andava quindi introdotto una un meccanismo di verifica del reset da una configurazione verso una nuova. NON è utile che i siti geograficamente vicini ad un nodo temano un nodo anomalo e cerchino di isolarlo come non affidabile magari perché ha cambiato configurazione! Infatti migliora la sicurezza se nessuno sa i fatti degli altri. La standardizzazione di una procedura, scritta in chiaro e che debba essere applicata da _tutti_ è la migliore garanzia che nessuno sia un cigno nero per attirare su di se la attenzione e mettere a rischio la riconoscibilità geografica. Viceversa vi sono -ufficialmente- più soluzioni di configurazione del servizio TOR. E poi però non è possibile impostare un cambio di configurazione associato a un dato indirizzo e si è costretti all’ex novo, nel caso di cambio di configurazione. Ci potrebbe essere persino il paradosso che l’indirizzo abbandonato venga riestratto da altri e considerato anomalo perché aveva chiesto una configurazione da remoto e poi l’ha chiesta da locale, e accettabile solo per la scelta ultima, ma non per la precedente.

Considerazione del 20-01-2019, ore 16.20
Ecco la foto del nostro rientro in white_list in data 20-01-2019, ore 16.20:

Come avevamo previsto con un nuovo hostname e private_key siamo riusciti a collegarci con il sito onion creato da noi, e configurato per operare solo in locale con server apache2.

C’è da annotare, però, che la rete TOR ci consente di vedere da un computer “terzo” il link:

www.4nplovidwsib43pn.onion

solo se abilitiamo una configurazione “proxy” su browser_tor, ed in particolare nella modalità seguente:

preferenze > avanzate > rete > impostazioni >

Viceversa se impostiamo

[v] Nessun proxy

il browser non riesce a collegarsi a nessun sito hidden!

C’è -allora- da annotare che nella nostra prima connessione questo non succedeva e potevamo vedere la rete TOR senza impostare nessun proxy!

Dove risiede la memoria che ha acquisito queste informazioni?

Dalla nostra sperimentazione non risiede in locale al server del miosito.onion

Secondo la nostra valutazione la rete TOR non è solo un meccanismo aleatorio e criptografico di connessione.

Ma -nell’accettare un nuovo “nodo”- che è equivalente alla messa on line di un nuovo sito web, comincia a memorizzare in modo distribuito tra più server una cronistoria del comportamento del singolo nodo nel dialogo con la mappa locale.

Faccio un esempio:

supponiamo di avere la seguente situazione:

n1__n2__n3
|        |        |
n4__n5__n6
|        |        |
n7__n8__n9

n1: sia collegato fisicamente vs n2, n4

n2: sia collegato fisicamente vs n1, n3, n5

etc

Se con n5 (n5 siamo noi) chiediamo di entrare in rete TOR

questo potrebbe avvenire tramite uno dei seguenti nodi:

n4, n2, n6, n8

supponiamo che avvenga, in modo aleatorio, e sia “estratto”  n2

Ora n2 si fa i  fatti nostri e scrive come è configurato n5 e lascia un promemoria sia su n5 e sia su se stesso (n2).

Se la richiesta di collegamento si ripete, ed è “estratto” n4

Ora n4 si fa i fatti nostri e scrive come è configurato n5 e lascia un promemoria sia su n5 e sia su se stesso (n4).

Dopo più richieste di collegamento tutti i nodi adiacenti di n5 sanno i fatti di n5 nel senso che sia ben configurato.

Se -quindi- n5 azzera la sua cronistoria localmente a n5, provvederanno i nodi adiacenti a recuperare la cronistoria di n5 non solo su se stessi, ma anche su n5, se n5 conserva il suo indirizzo.

Come abbiamo visto nell’ultimo aggiornamento del presente articolo, solo chiedere un nuovo nome consente di buttare a mare la cronistoria di n5 e permettergli di essere trovato, poiché la cronistoria pregressa funziona da “casellario giudiziario” del comportamento di n5 non per azioni illecite, ma per inaffidabilità sul pregiudizio che abbia dimostrato in passato di non avere una corretta configurazione, e quindi il nodo viene marchiato come inattendibile a veicolare traffico anonimo.

Questa è la mia analisi per quanto si è potuto capire dalla presente sperimentazione.

Io penso, quindi, che la rete TOR è una rete scarsamente “elastica” e si basi sul “pregiudizio”, affidandosi alla sola possibilità di una richiesta di un nuovo indirizzo per migliorare e recuperare la fiducia di essere un nodo correttamente configurato.

Ciò può creare notevoli problemi di configurabilità di un sito onion a chi non fosse un esperto di informatica!

Poiché la configurazione potrebbe divenire esatta dopo vari tentativi, ma la rete TOR rimarrebbe della opinione che quel nodo NON vada usato!

Forse è una tecnica di difesa a scoraggiare chi gioca con il web .. anziché avere reali interessi e non per esercizio ludico.

Ma -a nostro avviso- non è la strada giusta per la espansione di TOR, come invece noi auspichiamo.

Se infatti tutti -e con facilità- riescono a essere un nodo di TOR la associazione geografica tra un indirizzo onion ed un utente che lo usa NON deve rappresentare una “minaccia” alla sicurezza di TOR, che -invece- si deve basare non sulla configurazione “geografica” da tenere occulta, ma su un sistema di sicurezza robusto che non abbia necessità di rendere anonimi gli utenti e i siti associati.

COME?

Ad esempio NON affidando ai nodi adiacenti di tenere memoria di una cronistoria del comportamento della loro zona di dialogo, poiché NON è utile creare un “pregiudizio” di tipo “casellario giudiziario” per il singolo nodo che chiede di entrare in rete!

Una configurazione o un comportamento possono essere ben formati, oppure no. Nel caso che non siano bene formati, la esclusione deve spiegare i motivi della esclusione.

Se in un club non si possono dire “parolacce” il socio che vìola la regola sa che sarà espulso. stop.

 

ultimo aggiornamento

ore 11.28 del 2 feb 2019

Questa voce è stata pubblicata in deep web, POLITICA. Contrassegna il permalink.

Una risposta a Fix_n2: Tor’s white_list?

  1. Pingback: Fix: How to Install a Hidden Service on Apache Over Ubuntu 16.04 [22.12.2018] | 6 VIOLA

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...