Fix: How to Install a Hidden Service on Apache Over Ubuntu 16.04 [22.12.2018]

Ciao mondo!

ANTEFATTO:

Vogliamo dedicare un post specifico (Lez. 23) a questa procedura nel titolo(*), poiché è abbastanza attendibile, ma contiene delle inesattezze marginali che ne impedivano la convergenza, ma che nel seguito saranno risolte (fix).
(*)
mi riferisco all’articolo che stiamo commentando:

http://smhow.com/how-to-install-a-hidden-service-on-apache-over-ubuntu/

Sapevate che potete mettere on line un Vs sito web senza dovere passare per un gestore di spazi web come ad esempio Aruba, etc ?

Si tratta dei domini “onion”, in cui se tenete acceso un computer mettendo on line 1 o più pagine fatte da voi, allora, siete direttamente su internet!

Abbiamo già affrontato questa tematica a link seguente:
https://6viola.wordpress.com/deep-web/ 

.. esattamente alla Lez. N2: come metodo di navigazione nel deep web grazie a una pennetta usb e web browser detto “tor” (e questo solo per leggere)

.. ma per scrivere, 

o meglio per avere una Vs pagina dentro la rete tor, avevamo trattato il tema nella lezione Lez. 3 (sempre al link sopra citato).

Nella Lez. 4, avevamo esplorato i limiti e i miglioramenti che si possono apportare per tutelare la sicurezza.

Nella Lez. 5 studio dei dispositivi di protezione come i firewall

Nella Lez. 6 studio dei software detti server ed in particolare del server Apache2.

Nella Lez. 7 studio configurare usb con apache2 + tor per avere un sito web, ma dovevamo passare per la installazione di una partizione dedicata.

Nella Lez. 8 studio della presenza di più sistemi operativi sullo stesso computer. Studio del software Grub che rende possibile il caricamento (boot) multiplo.

Nella Lez. 9 fallimento della installazione multipla e perdita momentanea dell’accesso alla partizione avviabile. Metodi di recupero dell’accesso al computer, grazie ad attivazione del DOS. Ripresa di controllo del pc.

Nella Lez. 10 studio del sistema operativo Kali-Linux.

Nella Lez. 11 la intelligenza naturale e artificiale che guarda se stessa pensante.

Nella Lez. 12 entriamo nel dettaglio di come si può realizzare un sito onion. Siamo riusciti a configurare Apache, ma non ANCORA la tipologia onion.

Nella Lez. 13 entriamo nel dettaglio di TOR che si propone in questo caso non di leggere ma di presentare il sito web. Qui il primo errore del principiante: scaricare il software come si usa in windows e poi metterlo non nelle cartelle che tor si aspetta con una configurazione “canonica”. Vedremo solo nell’articolo attuale .. che per potere ottenere questo risultato sia apache che tor vanno installati con una diversa procedura: sudo apt-get install apache2, sudo apt-get install tor. Si noti che TOR si installa, ma come browser anche da archivio scompattato in qualunque link, ma NON al fine del sito onion!

Lez. 14 qui -per la prima volta- .. abbiamo provato a implementare la procedura di cui oggi abbiamo realizzato il FIX. NON vi erano errori di logica, ma di indirizzamento!

Ecco, ripeto, il testo originale dell’articolo qui esaminato:
http://smhow.com/how-to-install-a-hidden-service-on-apache-over-ubuntu/
In blu (nel seguito) le modifiche di fix .. (errata corrige)

Ma va messo a confronto con il testo “canonico” (ufficiale) che però -purtroppo- è deficitario nella preparazione:
https://www.torproject.org/docs/tor-onion-service.html
Tuttavia il testo canonico conferma le mie modifiche ..

dal link seguente:
http://smhow.com/how-to-install-a-hidden-service-on-apache-over-ubuntu/

How to Install a Hidden Service on Apache Over Ubuntu

1. Update packages and install apache and tor
sudo apt-get update
sudo apt-get install -y apache2 tor
2. Limit apache to only listen to localhost over port 80
echo "Listen 127.0.0.1:80" >  /etc/apache2/ports.conf
3. Set permissions for debian-tor
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).

service apache2 stop 
sudo chown -R debian-tor:debian-tor /var/{lock,log}/apache2 /var/www 
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.

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.

5. Create a test page and start apache
echo "Test page" >  /var/www/index.html 
service apache2 start
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

(ndr: le due righe che iniziano con il nero esistono già in torrc e basta “decommentarle” togliendo il #)
(quindi si può entrare con vim, premere il testo “i” (insert) togliere le # e premere il tasto “ESC” e quindi premere “:wq” (senza le virgolette) che corrisponde a salva ed esci.

vim /etc/apparmor.d/system_tor

Add:

owner /var/www/** rwk,

(ndr: la aggiunta (Add) della scritta “owner /var/www/** rwk,” va scritta nella zona sotto gli altri “owner” che già esistono. Tutto il resto, in “system_tor”, non va modificato).

Save and quit.

service apparmor restart 
service tor restart
All done

You can get your domain from /var/www/hostname

errata_N3:

cat /var/www/hostname

corrige_N3:
cat /var/lib/tor/hidden_service/
(vedi seguito more info)

And publish it.


stop
al link che stiamo commentando

Va detto inoltre che

“service tor restart” va premuto ogni volta che si aggiorna il file torrc, come risulta dlla seguente fonte:

http://lpw.io/tor-hidden-services-for-beginners.html
cito: dalla sezione “Install Tor”
After editing the `torrc` you need to restart tor.

Inoltre la ..

5. Create a test page and start apache
echo "Test page" >  /var/www/index.html 
service apache2 start
è errata!

corrige_N2:

Infatti la pagina index è in

/var/www/html/index.html

Il browser (per mostrare il sito web)  deve essere lanciato ..

http://localhost/

e vedrà index.

errata_N3:

il nome host non sarà in

/var/www/

ma nel seguente indirizzo insieme alla private key che (questa ultima) non deve essere resa nota.

corrige_N3:

/var/lib/tor/hidden_service/

Nota Bene:

Va notato che la cartella “hidden_service” non va preparata da noi!

ma sarà la rete tor dopo il comando

“service tor restart”

a creare la cartella hidden_service oltre che l’associato contenuto.

Ciò è possibile _perché_ abbiamo scritto:

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

.. se avessimo scritto anziché “hidden_service” un altro nome ad esempio “www_service”

i 2 file “hostname” & “private_key” sarebbero andati all’indirizzo:

/var/lib/tor/www_service/
con
/var/lib/tor/www_service/hostname
/var/lib/tor/www_service/private_key

fonte di conferma ed estensione a più siti web onion (nel link seguente) su un solo computer (nella mia verifica) che assolve funzione di server grazie ad ubuntu 16.04 + apache2:
https://unix.stackexchange.com/questions/328007/how-to-set-up-multiple-tor-hidden-services-in-the-same-host

 

“hostname”

va precisato che sarà un file che contiene una “stringa di caratteri” generata automaticamente dopo il “restart”, tramite “service tor restart” che abbiamo appena detto.

La stringa generata (dal sistema TOR), nel mio caso, e che ciascuno (per la sua stringa) deve conservare, è stata la seguente:

ykju7rtmw2ijnnf6

quindi solo nella parte in blu .. www & onion .. lo dovremo aggiungere noi nel navigatore terzo, come firefox-modificato=tor_browser, e salvare l’indirizzo, per la ricerca, mentre dobbiamo digitare localhost nel computer che espone index.html.

www.ykju7rtmw2ijnnf6.onion

Insomma da 2 computer .. sul primo mettiamo on line il sito web

indirizzo=localhost,

e sul secondo computer lo andiamo a cercare nel deep web ..

indirizzo=www.ykju7rtmw2ijnnf6.onion

non sarà inoltre facile entrare nella cartella hidden

da linea di comando fate così:

sudo -s (comando)

pw (vi viene chiesta la vostra password che dovrete scrivere)

cat /var/lib/tor/hidden_service/hostname (comando)

il copia ed incolla dal terminale .. i comandi sono in blu
sono qui di seguito:

lino@lino-Precision-5530:~$ sudo -s
[sudo] password di lino:
root@lino-Precision-5530:~# cd /var/lib/tor/hidden_service/
root@lino-Precision-5530:/var/lib/tor/hidden_service# ls
hostname private_key
root@lino-Precision-5530:/var/lib/tor/hidden_service# cat /var/lib/tor/hidden_service/hostname
ykju7rtmw2ijnnf6.onion

post scriptum:

il mio sito onion difficilmente lo vedrete .. perché serve un computer acceso e chi si collega per vederlo! (io non terrò un computer sempre accesso per esporre il mio sito onion!) .. ma è molto utile per realizzare un laboratorio di sperimentazione di andare a fare una analizzatore di stato su un server (che è ora il mio computer che con server apache mette on line un sito web) che sono autorizzato ad indagare perché è “il mio server web” altrimenti “un gestore dei siti web” (che non sia io) che non alloggia solo il mio potrebbe dirmi .. “perché analizzi il traffico su una risorsa che non sei autorizzato a monitorare?”

Infatti siamo ancora all’epoca della “pietra” in merito allo studio di come viaggiano i segnali sul web .. e concludo l’articolo mostrando 3 lezioni on line, non mie ma di chi insegna i rudimenti di base di questa materia:

(continua .. devo andare a cercare dove ho messo il link)

🙂

https://www.areanetworking.it/corso-wireshark-prima-lezione.html

AGGIORNAMENTO 15 gen 2019, ore 12.23

Dunque .. supponiamo di entrare nella rete TOR come se una persona fosse entrata in un labirinto! ..

al nodo di ingresso il computer utilizzato come browser .. chiede ..

“mi colleghi con l’indirizzo www.ykju7rtmw2ijnnf6.onion“?

Poiché a ogni indirizzo, compreso quello citato, corrisponde una key ..

la coppia

(1) hostname=www.ykju7rtmw2ijnnf6.onion & (2) private_key

sarà un nodo legittimo di TOR se non è in una black list.

Se la coppia è in una white list, e cioé non è stata ancora segnalata come scorrettamente configurata, il meccanismo di ricerca di un browser gira la richiesta di collegamento ad un nodo di ingresso alla rete.

Tale nodo inizia una procedura di sgancio da chi ha fatto la domanda e di inizio di criptazione come potrebbe essere di non collegarsi subito all’host name e mascherare chi ha chiesto, ma richiedere un collegamento non subito all’indirizzo finale, ma solo dopo un numero fissato di collegamenti.

Si crea -allora- una catena di collegamenti criptati (ne ho contati 8 compresi nodo di ingresso e di uscita) in cui ciascun nodo non conosce direttamente la destinazione oppure l’origine (tranne il nodo di ingresso per l’origine; e il nodo di uscita per la destinazione), poiché le info vengono mascherate nella catena di collegamento e solo “il canale” è in grado di ricostruire sorgente e destinazione.

Appena il numero di collegamenti è quello stabilito l’ultimo nodo che non conosce la sorgente ma solo il suo predecessore, fa una verifica se la coppia:

“(1)hostname & (2)private_key” coincidono sul nodo che espone l’indirizzo richiesto.

Poiché da host name non si riesce a sapere private key

ma da private key si riesce a sapere se genera quella stringa che è in host name ..

.. tanto è vero che esistono programmi come shallot che per stringhe molto corte (fino a circa 4 caratteri in pochi minuti) riescono ad associare persino da hostname quale deve essere la private key, ma non non per stringhe molto lunghe, quindi la ricostruzione -in genere- è mono direzionale! (cioé da private key -> host e non viceversa).

Supponiamo ora, che –come nel mio caso– io abbia messo on line una pagina considerata “non ben formata” e cioé che potrebbe attentare alla sicurezza di TOR..

Come si protegge TOR da ciò?

crea una black list!

Dove risiederebbe questa black list?

Se si esamina bene la cartella hidden_service (sul computer utilizzato come server per la messa on line del sito onion) troviamo:

cd /var/lib/tor/

copio ed incollo da konsole ubuntu 16.04:

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

in grassetto ftp-service sono cartelle che contengono altri files

senza grassetto sono files al livello cd /var/lib/tor/

Quindi il link www.ykju7rtmw2ijnnf6.onion è ora irragiungibile NON solo per un problema del browser(*), ma del fatto che la rete TOR ha dei meccanismi di “difesa”(**) nel caso “chi si collega”=”server del sito onion” .. NON sia considerato correttamente configurato.
(*)
infatti anche il browser_tor ha una cache, vedi seguito: successivo “aggiornamento”.
(**) 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. 

Una sperimentazione -allora- potrebbe essere la seguente:
(vedremo in seguito che anziché questa soluzione procederemo più gradualmente)

  1. dis-istallerò tor nella versione attuale.
  2. re-installerò tor e chiederò un “nuovo indirizzo”!
  3. mi collegherò alla nuova configurazione a cui mi sarà stata assegnata una nuova key
  4. avrò conferma se -poiché il nuovo indirizzo non è in una black list- risulterà visibile da un browser di un diverso computer da quello che mette on line il mio sito onion.

dalla nota (**) 18.01.2019, ore 22.30 qui sopra pulire solo la cache del browser e del server non sarà sufficiente a meno di non chiedere un nuovo indirizzo! Oppure riconfigurare il server non più per essere caricato solo in locale, ma in ftp, poiché quell’indirizzo se ha chiesto il collegamento non solo in locale, è ORAMAI considerato di una tipologia non solo a caricamento locale.

AGGIORNAMENTO 15 gen 2019, ore 14.49

Una questione molto importante per evitare che il browser sia tratto in inganno dalle memorizzazioni precedenti! (esamino qui di seguito) ..

Supponiamo, come nel mio caso, che io non abbia previsto nella prima versione del miosito.onion di volere effettuare ftp da remoto, ma solo da locale.

La cache del browser_tor (al momento del primo lancio dopo la installazione) lo chiede ..
“vuoi utilizzare un proxy (che avrà un servizio ad esempio sockes)?”

nella prima versione gli dico di no!

Successivamente supponiamo che indicando la porta 22 gli stiamo dicendo invece che vogliamo un servizio hidden da remoto (la porta 22 è predefinita per questo).

Allora se cambiamo la configurazione “sia sul server e sia sul browser per i sockes”, (da assenza di socks a presenza di socks) la cache potrebbe essere tratta in inganno.

“Se non puliamo la cache .. -infatti- il risultato della ricerca ci dirà sempre che non riesce a trovare i socks associati al link richiesto! anche se ora vogliamo vedere solo il miosito.onion solo con il browser, e senza ftp”.

Questo si può evitare “pulendo la cache!” (ci stiamo riferendo alla memoria cache del browser da remoto al sito=client).

fonte:
https://www.clear-browser-cache.com/firefox/clear-cache-firefox-osx/

Tuttavia questo “lavoro di pulizia”, dal lato client, NON sarà sufficiente a fare comparire il miosito.onion, poiché la “cronistoria” del sito è anche contenuta -come abbiamo visto sopra- nella cache al link del server seguente:

cd /var/lib/tor/

Da cui -per la nostra sperimentazione- anziché disinstallare completamente il miosito.onion, procederemo “alle pulizie di primavera”

🙂

e cioé a

  • NON togliere  >>host name e sia private key<<
  • togliere  >>ftp-server<< (il service che avevamo sperimentato per il collegamento in ftp).
  • togliere tutti i file di >>cache<<!

Dopo queste pulizie, proveremo a vedere se miosito.onion risulta di nuovo visibile.
(confermato: vedi seguito)

Se si confermasse la mancanza di visibilità per miosito.onion, toglieremo ANCHE >>homename e private_key<< e vedremo se ci viene riassegnato una nuova coppia.

Se anche in questo coso la pulizia non funziona .. procederemo alla disinstallazione di tor e quindi alla reinstallazione.

Nel prossimo “aggiornamento” i risultati della sperimentazione ..

dalla nota (**) 18.01.2019, ore 22.30 qui sopra pulire solo la cache del browser e del server non sarà sufficiente a meno di non chiedere un nuovo indirizzo! Oppure riconfigurare il server non più per essere caricato solo in locale, ma in ftp, poiché quell’indirizzo se ha chiesto il collegamento non solo in locale, è ORAMAI considerato di una tipologia non solo a caricamento locale.

AGGIORNAMENTO 16 GEN 2019, ore 16.33

Le pulizie di primavera -c’era da aspettarselo a causa degli indirizzi hidden- sono state più faticose del normale ..

La difficoltà principale è stata il fatto che neanche in veste di super_amministratore si riesce a scrivere nella directory hidden_service!

perché?

Perché avevamo ceduto a debian-tor il diritto esclusivo di proprietà con la istruzione seguente già incontrata all’inizio del presente articolo:

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

Quindi andava riportata la situazione alle condizioni di prima della configurazione di tor!

Dopo di ciò si può cancellare con rm (remove file) e con rmdir (remove directory) ciò che è stato aggiunto (dalla navigazione con file scritti dalla rete TOR sul nostro computer). Queste cancellazioni ci rimetteranno in “white list”, ma prima dovremo rifare tutta la procedura di ri-configurazione di TOR, come se non la avessimo mai fatta!

Entreremo nei dettagli di queste procedure nel prossimo articolo, ecco il link:

https://6viola.wordpress.com/2019/01/17/fix_n2-tors-white_list/

Una ultima considerazione: 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.
Rinvio all’ultimo link sopracitato per more info.

prima redazione:

23 dic 2018, ore 8.22

ultimo aggiornamento:

18 gen 2019, ore 22.58

 

 

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

Una risposta a Fix: How to Install a Hidden Service on Apache Over Ubuntu 16.04 [22.12.2018]

  1. Pingback: Fix_n2: Tor’s white_list? | 6 VIOLA

Rispondi

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

Logo 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...