==============================================================================
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--------------------[ previous ]---[ index ]---[ next ]---------------------
------------------------[ AN0NiMiZZARE i SiSTEMi UNiX ]-----------------------
-----------------------[ Van Hauser (trad. by Blinking) ]---------------------
- 0.1 Introduzione
Ho deciso di tradurre questo documento in lingua inglese scritto da van Hauser,
THC <vh@reptile.rug.ac.be> poiche' offre validi spunti per personalizzare il
proprio sistema *nix in modo da garantire la massima privacy e riservatezza;
ma non solo, anche perche' non ho ancora trovato nessun documento in lingua
italiana che tratti in modo pratico della riservatezza dei dati per end-users.
Sono qui illustrati alcuni esempi di come possano essere integrati nel sistema
operativo in ottimo modo i pacchetti di crittografia disponibili in rete come
PGP, CFS, TCFS, SFS, secure_delete solo per citarne alcuni.
La mia non ha la pretesa di essere un "howto secure your linux", ma solo una
panoramica delle possibilita' offerte da questo sistema operativo.
La traduzione e' da considerarsi libera; ho cercato di interpretare il senso
di cio' che lo scrittore voleva esprimere, per ogni suggerimento scrivetemi.
Le frasi che iniziano con la scritta "NB" sono delle mie considerazioni o
aggiunte personali a quanto menzionato nel documento. Buona lettura!
- 1. Utilizzatori
Questo guida e' stata scritta per ogni persona umana che vuole mantenere i
propri dati e la propria privacy lontani da ogni occhio indiscreto,
monitoraggi del traffico di rete e furto/accesso dei computer. Hacker,
phreaker, membri di partiti democratici in stati totalitari, persone
impegnate nella difesa dei diritti umani, persone con alte cariche potrebbero
essere interessate a queste informazioni. La guida e' stata scritta in modo
particolare per hackers novelli in modo da non essere facilmente arrestati
quando scoperti per la loro curiosita'.
- 2. Obbiettivi
Gli obbiettivi sono quelli di fornire soluzioni ai seguenti enunciati:
a. La soluzione dovrebbe essere semplice e facile
b. Tutti i dati degli utenti dovrebbero essere inaccessibili a chiunque
eccetto il proprietario dei dati stessi
c. Nessuno dovrebbe essere in grado di ricostruire cosa sta succedendo
nel sistema
- 3. Pre-requisiti
E' importante soddisfare le seguenti condizioni per questo progetto:
a. Il sistema dovrebbe essere sicuro. Nessun exploit remoto (e nemmeno locale)
b. Il system administrator deve essere fidato e intenzionato a tutto questo
c. Il sistema operativo che permette tutto cio' e' Unix (nel nostro caso
Linux)
Si noti che la soluzione presentata non si adatta al 100% con tutti i server.
Tuttavia e' (vicino alla) perfetta utilizzazione per gli utenti finali.
Per la parte Unix, noi mostriamo la soluzione per Linux perche' e' il sistema
Unix piu' facile per i principianti (e non solo aggiungo....) per metterci
mano ed amministrarlo. La distribuzione Linux che noi usiamo e' la SuSe Linux
Distribution 6.0. La Debian e' migliore, ma piu' complicata per i
principianti; ed a me non piace RedHat (NB: o RedAss, come dice Cavallo) per
la sua mancanza di sicurezza. Dovremmo inoltre conoscere abbastanza di Unix
(cosa e' portmap, mount, rc2.d, ecc.) prima di provare a capire questa guida.
Non e' un Linux-Howto!
- 4. Dati degli utenti
4.1 Dati 'sensibili' degli utenti
Cosa sono i dati sensibili degli utenti? Ogni dato di un account di un utente.
Questo include:
- utmp/wtmp/lastlog (tempo di login e durata piu' host di login)
- history files (quali comandi hai digitato durante la tua sessione)
- email
- files temporanei di applicazioni come emailer, browser, ecc.
- applicazioni e le loro configurazioni
- i tuoi dati personali (documenti, foto :P, dati confidenziali)
- time stamps sui tuoi dati (quando i file hanno avuto accessi o modifiche)
- su sistemi multiutente: cosa gli utenti stanno attualmente facendo. Questo
include la lista dei processi e le connessioni di rete cosi' come utmp (che
e' gia' incluso in un'altra categoria, cioe' quella di rendere proc piu'
restrittivo).
Stiamo tentando di proteggere tutte queste informazioni.
Si noti che tmp/wtmp/lastlog e le email (mqueue/mail/fax/lpd) sono gestiti
nella sezione "Dati di sistema". Tutti gli account degli utenti possono essere
visti da /etc/passwd, cosi' potresti voler aggiungere qualche (o molti)
account fasulli, insieme alle loro directory home e dati criptati.
4.2 Proteggere la directory /home
La cosa piu' importante nella protezione dei dati degli utenti e' la
protezione della directory /home. Ogni directory home deve essere criptata
con un metodo robusto, cosi' anche in caso di accesso fisico al sistema (del
tipo se vi portano via l'hdd) i dati non possono essere ugualmente ottenuti.
Correntemente conosco solo un software che provvede a fornire una soluzione a
questa richiesta: CFS - il filesystem crittografato.
Ci sono anche altri soluzioni crittografiche disponibili: TCFS, SFS e il loop
filesystem con supporto per la crittografia. Questi sono piu' veloci, ma hanno
lo svantaggio che devi ricompilare il tuo kernel con patch per questi tool.
Cosi', per scelta di semplicita', scelgo CFS qui. (Gli indirizzi di tutti
questi programmi si trovano alla fine).
Per abilitare CFS dobbiamo mettere queste sei linee in uno script rc2.d:
portmap
rpc.mountd -P 894 # mountd should bind to port 894
cfsd 895 # cfsd should bind to port 895
rm -rf /tmp/.tmp
mkdir -p -m 700 /tmp/.tmp
mount -o port=895,intr localhost:/tmp/.tmp /home
In aggiunta, dobbiamo mettere questa linea in /etc/exports:
/tmp/.tmp localhost
Ok, questo fa partire il sunrpc con il mountdaemon che sono necessari per far
partire ed usare CFS. Ora abbiamo bisogno di verificare le seguenti cose: se
un utente fa il login ed il sistema ha verificato che e' gia' loggato
all'interno deve decidere in quali casi decriptare la directory home
dell'utente. Questo sembrerebbe difficle, ma e' facile: la directory
/home/user dell'utente user non esiste (ed anche se esistesse le nove linee
seguenti del comando mount la farebbero non esistente), cosi' la variabile
HOME dell'utente e' settata su '/' (senza apici) della directory di root.
Allora la sua login shell che viene avviata cerchera' il proprio script di
partenza. Ed e' li dove noi metteremo il nostro zampino.
Abbiamo creato (questo esempio e' per la shell bash) il file ./profile con il
seguente contenuto
cattach /crypt/$USER $USER || exit 0
export HOME=/home/$USER
cd $HOME
if test -f $HOME/.profile; then
. $HOME/.profile
fi
Quanto un utente fa il login la prima volta, lo script viene eseguito.
L'utente deve quindi inserire la password per la sua directory criptata e dopo
di questo la variabile HOME corretta e' settata e il normale profilo di login
viene caricato ed inizializzato. Se un utente non conosce la password per la
sua directory criptata, resta chiuso fuori dal sistema.
Ma noi come possiamo rimuovere la directory home decryptandola dopo il logout?
Questo script dovrebbe essere intelligente, perche' un utente potrebbe
essersi loggato diverse volte, e solo una volta deve essere rimossa quando
l'ultima login di shell esce. Grazie a Dio, ache questo e' facile; noi
creiamo uno script in /home/user/.bash_logout .
# se il numero delle shell dell'utente e' maggiore di 3 allora questa e'
# l'ultima
hells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l`
test $shells -lt 3 || exit 0
export HOME=/
cd /
cdetach $USER
E' tutto. Da ora in poi, le directory home degli utenti sono sicure.
Si noti che un utente ora non puo' piu' fare il login, avviare un processo
in background e fare il logout perche' la sua directory home verrebbe rimossa.
Lo script .bash_logout completo incluso controlla il file $HOME/.keep e nel
caso in cui esista non rimuove la directory $HOME.
Per login in rete dovresti tenere in mente che i login non dovrebbero essere
fatti con rlogin, telnet, ecc perche' inviano tutto il traffico (incluse le
password) in testo semplice attraverso la rete. Dovresti usare un tool che
codifica il proprio traffico cone SSLTelnet oppure SSH (per SSH devi settare
"UseLogin yes" nel file /etc/sshd_config).
Troverai tutti questi script con correzione degli errori, creazione degli
utenti, script d'arresto e file di configurazione della sezione "Esempi di
configurazione".
Si noti che abbiamo lanciato i demoni nella sezione che puo' essere
contattata da remoto; se tu non lo vuoi (perche' non ci sono utenti esterni
che necessitano di mountare i loro dati cifrati sulla loro macchina) dovresti
firewallare queste porte. Guarda nelle pagine del manuale ("man ipchains"
oppure "man ipfwadm").
4.3 Tracciabilita' dell'attivita' degli utenti
Tramite i timestamp e' facile vedere chi e' loggato sul sistema e cosa sta
facendo. Anche se tutti i tuoi dati sono criptati, controllando l'ultima data
di accesso ai tuoi files, qualcuno potrebbe controllare quando ti sei loggato
l'ultima volta, per quanto tempo e se eri idle o stavi facendo molte cose.
Esempio: il primo accesso per un file criptato nella tua directory home puo'
essere visto con:
ls -altur /crypt/$USER | head -1 # mostra il file di logout con alcune
ls -altu /crypt/$USER | more # cose che troverai al momento del login
allora hai anche la durata della sessione.
Controllando i cambiamenti/modifiche e il tempo di accesso di questi files
criptati con i loro timestamp qualcuno puo' vedere quanto tu stavi lavorando,
e trarre conclusioni (ad esempio molti files suddivisi in un ramo a tre
livelli con directory che sono stati modificate, probabilmente appertengono
ad un browser - cosi' tu stavi navigando...)
Questo ora rendera' possibile controllare quali comandi sono stati eseguiti:
diciamo che il login e' stato effettuato 22 ore fa, quindi lancieremo:
find / -type f -atime 0 -ls # mostra i file che hanno avuto accessi
find / -type f -mtime 0 -ls # mostra i file che hanno avuto modifiche
(questo puo' essere fatto anche con le directory).
Ora controlliamo l'output con l'elenco dei tempi esatti, e analizziamo
cosa si puo' trovare. Per esempio e' stato usato il client telnet; e'
cosi' probabile che l'utente si sia connesso ad un altro sistema.
Ora puoi immaginare cosa sia possibile fare...
Proteggerti da tutto cio' e' molto semplice:
crea il file /usr/local/bin/touch_them e rendilo eseguibile con i seguenti
contenuti
find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch
Dopodiche inserisci la seguente linea in /etc/crontab
50 * * * * root /usr/local/bin/touch_them
e per finire cambia la 4a colonna di tutte le linee in /etc/fstab che
hanno la scritta "ext2" nella loro terza colonna (del tipo di filesystem).
defaults (o ogni qualsiasi altra cosa)
dovrebbe diventare
defaults,noatime (il vecchio valore viene mantenuto e noatime
aggiunto)
esempio:
/dev/hda1 / ext2 defaults 1 1
diventa
/dev/hda1 / ext2 defaults,noatime 1 1
Cosa abbiamo fatto? Il crontab con lo script aggiorna gli atime, mtime e
ctime delle directori speciali (specialmente quelle che potrebbero
contenere dati di utenti) all'ora corrente ogni ora.
4.4 Proteggere /var/spool/*
/var/spool/mail
Ora usiamo uno stratagemma: come possiamo proteggere la nuova posta per un
utente ad occhi indiscreti? Non puo' essere spedita direttamente nella
directory home dell'utente come qmail vorrebbe fare, perche' e' criptata.
La soluzione piu' semplice da utilizzare e' quella di usare pgp per
criptare le tue email in uscita e di dire ai tuoi amici che anche loro
dovrebbero criptare tutte le loro email per te.
Tuttavia questo non e' soddisfacente. Qualcuno potrebbe ancora vedere chi
ha spedito all'user l'email; la sola possibilita' di nasconderlo, e'
quella di usare un anonymous remailer. Non e' una grande soluzione,
percio' questo punto resta aperto (vedi sezione 10.2: Altri pensieri)
/var/spool/{mqueue|fax|lpd} :
Tutto quello che possiamo fare e' tentare di fare il flush di quelli in
lista nella fase di shutdown del sistema.
Devi aver deciso se eliminare i files che rimangono in modo sicuro, oppure
lasciarli dove sono; oppure se programmare uno script che fa qualcosa con
i dati (come compattarli e criptarli con pgp, facendo le operazioni
inverse quando il sistema e' riavviato).
Potresti anche creare una propria partizione criptata che contenga /var,
ma questo richiederebbe qualcuno alla console al momendo del boot ogni
volta.
- 5. Dati di sistema
5.1 Dati di sistema "sensibili"
Cosa sono i dati di sistema sensibili? Ogni cosa che permette di trarre
conclusioni sui dati in ingresso e uscita, files di configurazione, log,
avvii e spegnimenti del sistema.
Questo include:
- utmp/wtmp/lastlog (avvio, riavvio, ora dello shutdown e tempi degli
utenti)
- script per le connessioni dial-up ppp
- configurazioni di sendmail e tcp wrapper
- dati dei cache proxy (come squid web/ftp proxy)
- messaggi del syslog
- dati in /var/spool/* {mqueue|fax|lpd|mail}
- files temporanei da demoni (daemons)
- timestamp sui dati (quando ci sono stati accessi/modifiche)
5.2 Tracciabilita' dell'attivita' di sistema
Si puo' tracciare l'attivita' del sistema semplicemente controllando i
files temporanei creati da demoni ed applicazioni. Alcuni si trovano in
/tmp, mentre per le applicazioni di root solitamente (dovrebbero) si
trovano in /var/run. Ne parleremo nella sezione 5.3 "Log". Tutto quello
che per ora devi fare e' questo, e devi farlo una volta sola.
cd /var
mv run log
ln -s log/run run
Questi comandi spostano la directory /var/run in /var/log/run e creano un
link simbolico nella directory iniziale cosi' le applicazioni possono
ancora trovare i loro files.
5.3 Log - importanti e pericolosi
Loggare e' importante per determinare i problemi come errori di
configurazione.
Loggare e' pericoloso perche' un curiosone (NB: preferisco chiamarlo cosi'!)
potrebbe vedere dati importanti nei file di log, come i gli orari di login
e logout di un utente, oppure se ha eseguito "su" oppure altri comandi, etc.
Noi cercheremo di trovare un compromesso tra questi due.
La nostra soluzione: scrivere tutti i files di log in una directory
speciale. La directory e' un RAM disk, in modo tale che i dati vengono
persi dopo lo shutdown del sistema. Assicurati che il syslogd
[/etc/syslog.conf] ed altri demoni (esempio httpd [apache]) scrivano solo
nella nostra directory speciale o nella console di sistema. /var/log
dovrebbe essere usato come la directory speciale.
Ora inseriamo i seguenti comandi in /sbin/init.d/boot.local
umask 027
mke2fs -m0 /dev/ram0 1> /dev/null 2>&1
rm -rf /var/log/* 2> /dev/null
mount -t ext2 /dev/ram0 /var/log
chmod 751 /var/log
cd /var/log
mkdir -m 775 run
chgrp uucp run
for i in `grep /var/log /etc/syslog.conf|grep -v '^#'| \
awk '{print $2}'|sed 's/^-//'`
do > $i ; done
umask 007 # potrebbe essere anche usato 002
for i in run/utmp wtmp lastlog
do > $i ; chgrp tty $i ; done
cd /
kill -HUP `pidof syslogd` 2> /dev/null
Dopo il tuo prossimo reboot il sistema si comportera' come descritto sopra.
A qualcuno potrebbe non piacere l'idea di non avere nessun log dopo il
reboot, in questo modo non si puo' tracciare un intruso o trovare dai
tuoi log che cosa ha fatto crashare il tuo pc. Ad ogni modo puoi sempre
comprimere e criptare i files con pgp prima che lo shutdown sia completato
(ma i dati verrebbero persi comunque in caso di crash); oppure potresti
anche usare ssyslog o syslog-ng, sistemi di log speciali con supporto per
la crittografia e scrivere i dati che veramente vuoi tenere in (e' solo
un esempio) /var/slog.
Puoi anche creare una intera partizione criptata /var, ma questo
richiederebbe qualcuno alla console di sistema durante il boot, ogni volta.
5.4 Proteggere la configurazione di sistema
Qui ci vuole un po di ingegno, l'obbiettivo e' facile da raggiugere, ma ad
un costo: se noi creiamo un account con uid 0 che ha la directory home in
/home ed e' da questo momento protetta dalla configurazione di CFS,
dovrai essere alla console ad ogni reboot. Questo non e' comodo per i
sistemi server che necessitano di essere amministrati e riavviati da
remoto. Quindi questa soluzione e' adatta solo per utenti finali di pc.
Crea un account con uid settato a 0 (esempio, con login name "admin"),
puoi usare lo script create_user dalla sezione 9. Inserisci la
configurazione dei dati sensibili in questa directory (script per il
dialup ppp, file di sendmail sendmail.cf, squid con la loro directory di
cache settata ad una sottodirectory di "admin", etc.). Ora crea un piccolo
script di shell che avvia questi demoni con una linea di comando con
l'opzione di usare i files di configurazione nella directory home
dell'utente chiamato "admin".
Il sistema e' quindi sicuro dall'estrapolazione di informazioni sensibili
dai files di configurazione, ma con un prezzo: devi loggarti dopo ogni
reboot come utente "admin", inserire la password per CFS e lanciare lo
script.
5.5 Memoria dei computers e interfaccia /proc
Assicurare la privacy nei sistemi multiutente per gli utenti on-line
richiede da parte dell'amministratore di nascondere la lista dei processi
degli utenti; cosa che un utente potrebbe normalmente vedere quando esegue
comandi come "who" oppure "ps".
Per proteggere la lista dei processi di un utente, puoi usare la patch per
il kernel secure-linux di Solar Designer.
Per proteggere utmp/wtmp/lastlog assicurati che questi files siano
leggibili solo dalla root e gruppi tty; da questo momento un utente
normale non puo' accedere a questi dati (questo viene fatto tramite lo
script di esempio boot.local).
Ora manca solo un problema cioe' quello che con della RAM normale una
organizzazione economicamente dotata puo' salvare i contenuti della memoria
anche dopo lo spegnimento del sistema. Con le moderne SDRAM in cui i dati
restano nella ram permanentemente fino a quando dei nuovi dati vengono scritti,
e' ancora peggio. Per questo ho introdotto un piccolo tool nel "secure_delete"
package 2.1 chiamato "smem" che cerca di pulire la memoria; questo programma
dovrebbe essere lanciato dallo shutdown, come e' stato fatto nell'esempio 6.4
- 6. Dati cancellati e swap
6.1 Come cancellare i files in modo sicuro
Quando un file viene cancellato, solo l'inode viene cancellato mentre i dati
contenuti NON sono eliminati e possono essere raccolti con dei tool come "dd"
oppure manipulate_data dei THC.
Peter Gutmann scrisse il libro "Secure Deletetion of Data from Magnetic and
Solid-State Memory" presentato nel 1996 al sesto Usenix Security Symphosium;
e' il miglior libro che illustra come eliminare e ripulire i dati in modo che
sia difficile recuperarli anche con il microsopio elettronico.
In giro ci sono quattro tool che usano le tecniche qui descritte per eliminare
i dati in modo sicuro: due chiamati "wipe", uno chiamato "srm" dal pacchetto
secure_delete dei THC e "shred" che e' incluso nel pacchetto fileutil GNU.
Quello dei THC dovrebbe essere il migliore come progetto, caratteristiche e
sicurezza ed ha anche tutte le opzioni in linea di comando (quelle base e
avanzate) per una maggiore velocita'.
Per usare uno qualsiasi di questi tool per cancellare file, semplicemente si
puo' settare un alias in /etc/profile
alias rm=srm # oppure wipe oppure shred
oppure, ancora meglio, spostare /bin/rm in /bin/rm.orig e copiare il programma
per la cancellazione sicura in /bin/rm. Questo assicura che tutti i dati
cancellati tramite il comando rm vengano eliminati in modo sicuro.
Se non e' possibile installare uno qualsiasi di questi pacchetti (per qualsiasi
ragione) si puo' comunque settare il wipe flag nel filesystem ext2 sui file che
si vuole pulire prima di rimuoverli con rm. E' all'incirca lo stesso, ma non
e' cosi' sicuro come il wipe menzionato precedentemente;
chattr +s nomedeifile
6.2 Come pulire (wipe) lo spazio libero dei dischi
La maggior parte delle applicazioni (come gli editor nei programmi di posta)
scrivono dei file temporanei e tu non ne sai niente - molte volte non ti viene
neanche chiesto. Poiche' questi files non vengono eliminati in modo sicuro
potrebbero essere recuperati da un intruso che potrebbe prendere tutte le tue
email senza che tu nemmeno lo sappia. Cio' non e' buona cosa.
La soluzione: usare un programma che pulisca tutto lo spazio libero dalle
partizioni dei dischi. Il solo disponibile e' quello dei THC secure_delete
(NB: non ne sono sicuro, ma nell'articolo non ne vengono citati altri).
Puoi mettere il comando "sfill" (e' cosi' che si chiama) nel crontab cosi'
viene lanciato regolarmente anche se questo potrebbe creare problemi quando
devono essere lanciate applicazioni piu' importanti; quindi lo si puo' far
lanciare almeno quando il sistema fa lo shut down.
Metti questo nella sezione "stop" di uno degli script in rc2.d
sfill --llf /tmp 2> /dev/null
sfill --llf /var/spool 2> /dev/null
Si noti che e' anche una buona idea creare una nuova partizione da usare per
/tmp e mettere un link simbolico da /usr/tmp e /var/tmp verso /tmp. In questo
modo e' piu' facile controllare ed eliminare.
Ancora, se non puo installare il pacchetto secure_delete per qualche motivo,
puoi ancora usare questa soluzione (anche se e' lenta e non cosi' sicura):
dd if=/dev/zero of=/tmp/cleanup
sync
rm /tmp/cleanup
6.3 Come gestire i dati di swap
Cancellazione sicura dei files e pulizia dello spazio libero delle partizioni:
che cosa manca? Al giorno d'oggi i MB degli hard disk sono piu' economici
delle RAM, ed e' per questo che gli swap sono utilizzati per espandere la RAM
disponibile; nella realta' lo swap e' un file o una partizione nel tuo
hardisk.
Anche qui c'e' solo un tool che aiuta, "sswap" dal pacchetto secure_delete
(NB: vale lo stesso discorso di prima, non ho potuto verificare).
Metti questa linea dopo la linea "swapoff" in /sbin/init.d/halt
sswap -l /dev/XXXX # XXXX e' il device per il tuo swap.
# controlla quale e' in /etc/fstab
6.4 Come gestire la RAM
Nella sezione 5.1 ho scritto circa le informazioni sensibili nella RAM, la
memoria veloce dei computer; essa puo' contenere informazioni molto riservate
come le email che hai scritto prima di codificarle con pgp, password, ogni
cosa. Per assicurarsi che la memoria venga pulita, usa l'utility sms; dovrebbe
essere lanciata come qui nella parte stop di uno degli script in rc2.d (come
gia' menzionato precedentemente), dopo il wipe del file /tmp.
smem -ll
6.5 Dati temporanei
Dopo che hai reso sicuro, anonimizzato, privatizzato il tuo sistema ogni cosa
e' pronta - o hai dimenticato qualcosa?
Ricordati cosa abbiamo detto nella sezione 6.1, i dati temporanei sono scritti
da qualche parte e a volte non lo sai. Se sei sfortunato, tutto quello che
abbiamo fatto e' inutile; dobbiamo quindi assicurarci che non ci siano file
temporanei sui device e che non possano nemmeno essere recuperati.
Ora che abbiamo gia' trattato di /var/log, /var/run e la posta in uscita
(/var/spool/...) ed abbiamo ripulito tutto lo spazio libero nei dischi,
dobbiamo ripolire anche i dati temporanei. Metti questa linea nella sezione
"stop" di uno degli script in rc2.d (prima di sfill dalla ezione 6.3):
( cd /tmp ; ls -A | xargs -n 250 srm -r ; )
Dovrebbe essere anche creata una directory $USER/tmp per tutti gli utenti
che hanno la protezione di CFS e sono all'interno di /home; deve quindi anche
essere settata la variabile TMPDIR in modo oppurtuno per ogni utente su questa
directory (NB: ad esempio se l'utente si chiama abc avra'la directory tmp
in /home/abc/tmp e la variabile TMPDIR sara' settata a /home/abc/tmp).
Vedere la sezione 9 per tutti questi script...
- 7. Connessioni
Questa e' una sezione molto specifica del documento. Ho scritto alcuni modi
su come si possa proteggere una parte dei dati che vengono trasferiti tramite
internet.
I prerequisiti base sono i seguenti: che tu abbia un POP3 e un SMPT (mail
relayer) esterni dove prendi e spedisci le tue email. Quando vai in irc,
preferisci che il tuo vero hostname non venga visualizzato nei canali.
Il tuo mail server esterno dovrebbe essere in un altro stato, perche' se
qualche agenzia ufficiale ha motivo di pensare che tu stia facendo qualcosa
di illegale (e sono sicuro che tu non lo farai) e' piu' difficile
garantire una ricerca. E' anche piu' difficile perche' le compagnie
o gli individui che cercano i tuoi dati avrebbero bisogno di investire piu'
tempo, lavoro e soldi per averli.
Puoi instradare la tua connessione SMPT e POP3 attraverso ssh al mail server
esterno.
Per il POP3 e' semplice, ma per l'SMPT e' un po piu' difficoltoso.
Solo per esempio, anche il traffico irc potrebbe essere instradato con ssh,
ma le dcc non funzioneranno (in questo modo non funziona, mentre l'altro
sarebbe quello di rivelare il tuo indirizzo ip al mittente e i dati non
verrebbero codificati da nessuna delle due parti). Si noti che e' anche
possibile utilizzare redirector e proxy (NB: bounce, wingate, ecc) per
effettuare altri redirector per altri protocolli (www, irc, ftp proxy, ecc).
E' tutto. Tutto il traffico via email (e come puoi vedere di seguito anche
quello irc) viene codificato tra te e il tuo mail/proxy server.
sendmail.cf (parti importanti):
DSsmtp:[127.0.0.1]
DjTHE_DOMAIN_NAME_OF_YOUR_EMAIL
DMTHE_DOMAIN_NAME_OF_YOUR_EMAIL
- Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
+ Msmtp, P=[IPC], F=mDFMuXk, S=11/31, R=21, E=\r\n, L=990,
(add the "k" switch to the smtp option config line)
~user/.fetchmailrc:
poll localhost protocol POP3:
user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here
mda "/usr/sbin/sendmail -oem USER_LOCAL"
(usa i corrispondenti USER_* e PASSWORD qui)
La linea di comando per ssh che instrada il traffico per il POP3, SMTP ed irc:
ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \
25:localhost:25 your_mail_server.com
E' tutto, non ti diro' niente di piu'. Usa il cervello ;)
- 8. Nascondere i settaggi per la privacy
8.1 Mount e' tuo amico
Dai uno sguardo ai seguenti comandi:
# ls -l /home
total 3
drwxr-x--- 1 root root 1024 Mar 28 14:53 admin
drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh
drwxr-x--- 1 user users 1024 Mar 28 11:22 user
# mount -t ext2 /dev/hda11 /home # oppure un ramdisk, non fa importanza
# ls -l /home
total 0
# : oops, dove sono le directory home ?
# umount /home
# ls -al /home
total 3
drwxr-x--- 1 root root 1024 Mar 28 14:53 admin
drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh
drwxr-x--- 1 user users 1024 Mar 28 11:22 user
# : ah si, ci sono ancora
Questa e' un buon modo per nascondere i tuoi dati criptati e i tuoi
eseguibili. Devi solo mettere i tuoi files in, per esempio, /usr/local/bin
e /usr/local/crypt e fare il mount di un filesystem decoy; se quindi hai
un processo avviato nei tuoi script di boot che apre un file sul filesysyem
decoy, non puo' essere effettuato l'unmount fino a quando il processo non e'
terminato. In questo modo, e' molto piu' difficile per qualcuno scovare i
tuoi dati!
8.2 Media rimovibili
Una possibilita' migliore sarebbe quella di mettere tutti i tuoi dati
sensibili su un supporto rimuovibile, fare il mount e lanciarlo dallo script
d'avvio che attiva tutte le cose per la privacy. In questo modo hai fatto un
altro passo per rendere piu' difficile a qualcuno conoscere cosa stia
succedendo.
8.3 ???
Altre idee? Pensaci! (e magari spediscimele ;-)
- 9. Script di configurazione ed esempi
NB: preleva il file anonymous-unix-0.7.tar.gz dal sito dei THC (21.613 bytes)
- 10. Commenti finali
10.1 Dove prendere i programmi menzionati nel testo
_Crypto Filesystems _
CFS (Cryptographic File System) http://www.replay.com
TCFS (Transparent CFS) ftp://mikonos.dia.unisa.it/pub/tcfs/
SFS (Stegano File System) http://www.linux-security.org/sfs
Crypto Loopback Filesystem ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/
_Tools_
THC's secure_delete package http://www.infowar.co.uk/thc
secure-linux kernel patch http://www.false.com/security
syslog-ng http://www.balabit.hu/products/syslog-ng.htm
ssylog http://www.core-sdi.com/ssyslog
10.2 Considerazioni aggiuntive - Saluti - Come contattare il gruppo dei thc
NB: Sono tutte informazioni che non ho inserito o che potrei non aver
interpretato correttamente si possono trovare nella forma completa ed in
inglese nel sito:
http://r3wt.base.org
http://thc.pimmel.com
http://www.infowar.co.uk/thc
- 100 Conclusione
Desidero in ultimo fare alcuni ringraziamenti e saluti a (in ordine casuale):
tutta la crew di s0ftpj, HarLoK, 3p41R0x, crl, Alphard, Nobody88, DanteAlig,
ulntwh99, area[c], THC. Sono apprezzati suggerimenti, critiche, saluti,
aggiunte.
Blinking
--------------------[ previous ]---[ index ]---[ next ]---------------------
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
==============================================================================