Newsgroup: it.comp.reti.cisco
Titolo: DDoS - filtrare lo spazio RFC-1918 -

Ciao a tutti,
ho letto una white paper di cisco che suggerisce come evitare alcuni DDoS.
Tra questi suggerimenti c'è anche quello di usare una ACL per filrare tutto 
lo spazio degli indirizzi privati del tipo:
access-list 101 deny ip 10.0.0.0    0.255.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 172.16.0.0  0.15.255.255 any
access-list 101 permit ip any any
da applicare all'interfaccia:interface xy
   ip access-group 101 inMa se nella ACL c'è anche lo spazio degli indirizzi 
della mia rete privata e io applico la ACLal dialer quando cerco di uscire 
per andare che so su internet non verrei io stesso filtrato?Per esempio io 
ho una rete 
192.168.1.0/24
 e applico la ACL al dialer.Se volessi uscire dal 
dialer per andare su internet verrei filtrato dalla seconda riga della 
ACL... o no?GrazieMauro 

 ACL... o no?GrazieMauro 
Mi sa che devie ristudiarti le ACL ed il NAT.
Internet <-> Dialer1---ROUTER---FastEth0 <-> LAN
Consiglio di creare DUE access list estese, una 101 per filtrare il 
traffico in ingresso (come dice CISCO nel White Paper) e l'altra 102 
quello in uscita:
access-list 101 remark INBOUND CONNECTIONS
access-list 101 deny   ip 127.0.0.0 0.255.255.255 any log-input
access-list 101 deny   ip 0.0.0.0 0.255.255.255 any log-input
access-list 101 deny   ip 10.0.0.0 0.255.255.255 any log-input
access-list 101 deny   ip 169.254.0.0 0.0.255.255 any log-input
access-list 101 deny   ip 172.16.0.0 0.15.255.255 any log-input
access-list 101 deny   ip 192.168.0.0 0.0.255.255 any log-input
access-list 101 deny   ip 224.0.0.0 31.255.255.255 any log-input
access-list 101 deny   ip 255.0.0.0 0.255.255.255 any log-input
access-list 101 permit.....
access-list 101 deny.....
access-list 102 deny   ip any any log-input
access-list 102 remark OUTBOUND CONNECTIONS
access-list 102 deny   ip 127.0.0.0 0.255.255.255 any log-input
access-list 102 deny   ip 10.0.0.0 0.255.255.255 any log-input
access-list 102 deny   ip 169.254.0.0 0.0.255.255 any log-input
access-list 102 deny   ip 172.16.0.0 0.15.255.255 any log-input
access-list 102 deny   ip 192.168.0.0 0.0.255.255 any log-input
access-list 102 deny   ip any 127.0.0.0 0.255.255.255 log-input
access-list 102 deny   ip any 10.0.0.0 0.255.255.255 log-input
access-list 102 deny   ip any 169.254.0.0 0.0.255.255 log-input
access-list 102 deny   ip any 172.16.0.0 0.15.255.255 log-input
access-list 102 deny   ip any 192.168.0.0 0.0.255.255 log-input
access-list 101 permit.....
access-list 101 deny.....
access-list 102 deny   ip any any log-input
A questo punto puoi applicarle sull'iterfaccia WAN (tipicamente la Dialer1):
interface Dialer1
  description CONNESSIONE AD INTERNET (Dialer 1).
  bandwidth 9000000
  ip address negotiated
  ip access-group 101 in
  ip access-group 102 out
  .....
Caso A (la 102 applicata in uscita sulla Dialer1)
-------------------------------------------------
Vuoi andare su Internet quindi mandi la tua richiesta (un pacchetto) 
verso l'esterno (verso la Dialer1 a da li ad Internet).
Il pacchetto che tenta di uscire avrà IP sorgente 192.168.x.x e riesce a 
passare la FastEth0 (che non ha ACL applicate) ed arrivare nel router.
A questo punto entra in gioco il NAT che che cambia IP sorgente al 
pacchetto dandogli quello pubblico (per intenderci quello che hai sulla 
Dialer1) es. 82.101.34.5
Solo a questo punto il pacchetto passa attraverso l'ACL 102 che lo 
lascia passare, visto che l'IP sorgente è pubblico.
Inoltre l'ACL che ti ho scritto in più blocca anche i pacchetti che 
tentano di uscire con IP di destinazione privato (cosa che non dovrebbe 
mai accadere).
Caso B (la 102 applicata in ingresso sulla FastEth0)
----------------------------------------------------
Vuoi andare su Internet quindi mandi la tua richiesta verso l'esterno 
(verso la Dialer1 a da li ad Internet).
Il pacchetto che tenta di uscire avrà IP sorgente 192.168.x.x e non 
riesce a passare la FastEth0 per via dell'ACL 102.
Dando per scontato tu sappia quale differenza passa tra IP pubblici e 
privati, per quanto riguarda la 101 non vedo particolari problemi.
Semplicemente viene bloccato il traffico in ingresso (da Internet verso 
la tua LAN) che si presenta con IP *privato*.
Cosa quest'ultima che non dovrebbe mai accadere ma che è invece 
solitamente sfruttata per penetrare in LAN e fare danni.
Riguardo alla sicurezza dei router CISCO dai un occhio anche a:
http://www.nsa.gov/snac/routers/cisco_exec_sum.pdf
http://www.dslreports.com/faq/7766
P.S. Quando nella riga di una ACL neghi qualcosa, alla fine della riga 
stessa piazzaci 'log-input' cosi quando la riga è matchata viene mandato 
il relativo messaggio al tuo server 'syslog'.
In caso di attacchi o troubleshooting aiuta a risolvere il problema.
-- 
Akira

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Akira wrote:
[Complete CUT!]
E' bello vedere queste politiche di sicurezza...
Pero' si parla di un DDOS, il cui impatto si basa
principalmente sulla quantita' di traffico...
Quindi, nel caso in cui tu abbia una connessione
adsl o un Fastweb 10mega...e ti arriva un'attacco
da 100 mega, il flood sul tuo link sara' comunque
superiore alla connettivita' e tali filtri non faranno
altro che sovracaricare il router sul deny...
Se poi la tua connettivita' si chiude con un nat in
overload praticamente tutti questi pacchetti vengono
scartati dal router non trovando associazioni nella
traslation table del nat.
Per quanto riguarda intrusioni che si tentano con
ip sorgenti in classe privata la cosa e' praticamente
impossibile se la tua wan e' su internet, vorrei
sapere come farebbero a fare una connessione TCP...
Politiche di blocco su indirizzamento privato e
i riservati dello iana andrebbero implementati dagli
ISP e dai Carier, sopratutto sui router che danno
connettivita' verso uplink o accesso remoto...
Come politiche' di filtro sui broadcast...
La cosa che si puo fare e' quello di evitare che dalla
propria rete possa uscire indirizzamento privato su internet,
bloccare qualsiasi protocollo MS, telnet, snmp... o
avere delle serie politiche di accesso su tali protocolli.
Evitare di rispondere agli echo request, spesso usati per
generare dei flood...
Ma qui si entra in un discorso diverso da quello iniziato.
- --
==
"Vorrei solo sapere che sei morto.
Cosi', per stare un po meglio."
- -
Per scrivermi una email o avere la mia PGP Key, posta
un messaggio con il seguente soggetto:"REQUEST EMAIL HARTIGAN".
==
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFFDFLduuxRXtjsR9sRA4WUAKDkU1uIUPwR6unCOHI84pJh5A8NtQCgg5Js
KOcqEK2AQAw7AEzDu5eMwuc=
=eKZS
-----END PGP SIGNATURE-----