Newsgroup: it.comp.os.linux.sys
Titolo: Sicurezza: firewall e Initial Sequence Number

Ciao a tutti, 
ho lanciato una sessione di nessus di testare un firewall da poco
configurato con iptables.
A parte alcuni messaggi poco importanti, nel report di nessus trovo anche:
"Vulnerability found on port general/tcp
The remote host seems to generate Initial Sequence Numbers
(ISN) in a weak manner which seems to solely depend
on the source and dest port of the TCP packets.
The Raptor Firewall is known to be vulnerable to this flaw,
as may others be.
An attacker may use this flaw to establish spoofed connections
to the remote host.
Solution : If you are using a Raptor Firewall, see
http://www.symantec.com/techsupp/bulletin/archive/firewall/082002firewall.html
or else contact your vendor for a patch
Risk factor : High"
A parte il fatto che sto utilizzando un firewall linux e non un Raptor
Firewall, sinceramente non so proprio dove mettere le mani per ovviare al
problema. Ha a che fare per caso con la randomizzazione delle intestazioni
ip?
Inoltre l'ultima versione di Nessus riesce ad identificare il sistema
operativo (linux kernel 2.4.0 2.5.0). C'è un modo per impedirlo?
Grazie per l'aiuto.
Ciao Tony
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 operativo (linux kernel 2.4.0 2.5.0). C'è un modo per impedirlo?
Per *impedirlo* no. Al massimo puoi sviarlo, patchando il kernel ( e
quidi il suo stack) per presentare comportamenti di default diversi da
quelli che contraddistinguono l'originale. [1]
[1] tale risposta si basa dal presupposto che l'identificazione
effettuata da nessus sia basata *esclusivamente* sullo stack e non su
eventuali banner, dato che questi, a rigor di logica, non dovrebbero
esserci affatto, essendo per definizione un firewall privo di servizi.
Byez
-- 
Emanuele Balla aka Skull
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

 tu...).
Si tratta solamente di una macchina di prova alla quale non è collegato
nulla e sulla quale non è configurato alcun servizio tranne pptpd e sshd. 
Tutti i banner e issue sono stati eliminati.
Ciao Tony.
PS: il quote va meglio adesso? :-)


 modo la serie 2.4 ).
Ho fatto la seguente prova: nel server sotto esame ho lasciato attiva solo
l'interfaccia pubblica (eth0). Ho lanciato una nuova sessione di nessus e
tuttavia viene sempre riscontrato il "security hole" tcp/ip di cui parlavo
nel msg iniziale. Nel server è caricato un kernel (ricompilato da me)
della serie 2.4.19. 
Sulla stessa macchina, con un kernel (sempre ricompilato da me) della
serie 2.4.18 rilanciando la stessa sessione di nessus, il buco di
sicurezza scompare. 
C'è qualche bug nella serie 2.4.19 oppure sbaglio qualcosa?


 C'è qualche bug nella serie 2.4.19 oppure sbaglio qualcosa?
Non lo so. di bug non mi risulta plausibile:
nei changelog che vanno dal 2.4.18 al 2.4.19 non mi risulta una sola riga
di codiche che vada a toccare lo stack, al massimo qualche fix nei driver
di singole schede...
Ho anche fatto qualche prova con nmap sulle mie macchine e non noto
grosse differenze tra la 19 e le precedenti:
questa è la 2.4.19:
TCP Sequence Prediction: Class=random positive increments
                         Difficulty=5841166 (Good luck!)
questa è una 2.4.3:
TCP Sequence Prediction: Class=random positive increments
                         Difficulty=1594844 (Good luck!)
Il range di casualità dell'ISN è più o meno invariato, vedendo la
media...
Poi c'è da dire che non ho idea su cosa si basi. Può anche essere che si
basi su qualcosa che applicato alla tua macchina dà risultati meno
"randomici" di quanto dovrebbe...
Oppure è nessus che canna qualcosa...
Prova direttamente con nmap, e vedi che salta fuori...


 Prova direttamente con nmap, e vedi che salta fuori...
Probabilmente hai ragione tu, perché ho fatto la stessa prova con nessus
su un'altra macchina 2.4.19 e il problema non si presenta. Però non so
proprio cosa sia perché sulla macchina bacata è installato solo postfix
sshd iptable e poco altro.
Per il resto ho tolto tutto.
Adesso controllo e poi ti so dire.
Grazie 
Ciao Tony.


 Adesso controllo e poi ti so dire.
Hmmm... la generazione dell'ISN è cablata nel kernel, difficilmente può
dipendere da qualsiasi cosa in userspace.
Non ho idea di come venga generata, di solito si va a pescare una serie
di indirizzi di memoria o robine simili e si fanno operazioni su quelli
per ottenere il numero che serve.
La mia ipotesi era (magari) che nel tuo caso, magari, alcuni dei
parametri su cui si basa la generazione tendano a risultare nulli,
diminuendo il grado di entropia dell'algoritmo.
Potrebbe essere qualsiasi cosa, l'unico modo di venirne a capo è
studiarsi l'algoritmo per capire da dove va a prendere i parametri e
cercare di capire che cosa accade a basso livello... al limite cercare di
contattare chi lo ha fatto, ma solo dopo che sei molto sicuro che il
comportamento è effettivamente quello (un po' di ethereal e nmap non
sarebbe male...)
Byez.


 cosa accade a basso livello... al limite cercare di contattare chi lo ha
Per la cronaca 'sta parte di codice la trovi (da una breve ricerca nei
sorgenti) in /usr/src/linux/net/ipv4/tcp_minisocks.c...
Non noto commenti esplicativi riguardo all'algoritmo usato nella
generazione dell'ISN, ma magari hai un po' di tempo da dedicarci (che io
non ho :-( )...
