Re: icmp o non icmp ?? questo ? il problema

On Feb 11, sikurezza@xxxxxxxxx wrote:

 >A parte M.D. che sicuramente dira' che e' un sistema super complesso, il
 >che puo' anche essere vero, in questo modo mi sento abbastanza
 >rilassato.
Di nuovo, il punto è che non è stato definito un threat model in base a
cui progettare le proprie difese, cioè quali risorse di rete, quali
capacità e quanto tempo ha a disposizione l'attaccante.

Dal mio punto di vista il problema è che non è sano lasciare un demone
ssh a disposizione sulla porta 22, vista la sua storia di problemi di
sicurezza, e ritengo che sia una contromisura soddisfacente proteggerlo
con una ACL a livello di kernel (netfilter) o applicativo (tcpd).
A questo punto si presenta la necessità di aprire selettivamente questa
ACL da remoto usando un protocollo sufficientemente semplice da potere
essere ragionevolmente sicuri che il demone che lo implementa non abbia
buchi.
Il portknocking è una tecnica interessante se si suppone che
l'attaccante non sia molto furbo e non possa leggere il tuo traffico,
altrimenti è "inutile". Inoltre, a mio parere è utile solo quando è
possibile generare la sequenza con tool standard che ci si aspetta di
trovare su ogni sistema, per esempio ping e telnet. Se diventano
necessari tool specializzati allora tanto vale scrivere un protocollo
testuale ad hoc da usare con telnet, oppure semplicemente inviare
un'email.
Se invece si suppone che l'attaccante conosca il contenuto di ogni
pacchetto inviato e ricevuto allora si può risolvere facilmente il
problema usando il solito protocollo testuale ma autenticandosi con
OPIE (S/Key).
Se si fa attenzione a inviare autenticazione e comandi in un unico
pacchetto direi che si possono evitare tutti i soliti attacchi a TCP
(ma come verificarlo in user space in modo semplice? Una alternativa
simpatica a TCP è ping -p).
Una volta aperta l'ACL non credo che mettere in mezzo una VPN fornisca
più sicurezza, considerando che SSH consente già l'autenticazione e la
verifica dell'identità dell'host remoto tramite protocolli a chiave
pubblica.

Come esercizio lascio agli interessati il compito di implementare in
perl un demone con le seguenti caratteristiche:
- apra un socket TCP in ascolto e per ogni connessione faccia fork,
  chroot, imposti i limiti, cambi UID, legga quello che c'è da leggere
  dalla rete, ne faccia il parsing e lo invii tramite una pipe al
  processo padre (che starà ben attento a cosa legge...)
- verifichi la password con OPIE e se è corretta riscriva hosts.allow
  con l'IP giusto
- tolga l'IP dal file quando il processo figlio muore (cosa che può
  succedere quando viene chiusa la connessione o quando il padre lo
  uccide dopo un breve timeout)

Ci sono altri accorgimenti da usare per blindare il demone ma non mi
dilungherò a descriverli tutti.

-- 
ciao, |
Marco | [4578 al4slcYoaWFaI]

Attachment: signature.asc
Description: Digital signature