Newsgroup: it.comp.reti.cisco
Titolo: TCP non-stateful filtering su ASA

Ciao,
mi domandavo se fosse possibile, in qualche modo, avere delle
access-list su tcp che siano stateless, ovvero facciano passare, ad
esempio, pacchetti ACK anche se non riconosciuti come appartenenti a
sessioni esistenti.
Saluti.


Nell'ultima release c'� la possibilit� di escludere il motore di firewall 
per le connessioni vpn, per il resto mi risulta che l'asa non ne voglia 
sapere di essere declassato ad un semplice router.
Ciao,
         Tosh. 

 ne voglia sapere di essere declassato ad un semplice router. 
Da quando poter scegliere è un "declassamento"?

> Da quando poter scegliere � un "declassamento"?
Puoi gi� scegliere, se vuoi avere insieme un firewall e un router ci sono 
gi� i router con l'ios security, perch� cercare un doppione nell'asa?
Ciao,
         Tosh. 


Riporto una esperienza quasi-diretta:
server RBLDNSD, flusso >5000 query/sec -tutte ovviamente UDP- 
provenienti da IP sorgenti praticamente casuali, a totalizzare pochi 
megabit di traffico.
Appliance privi della possibilit� di escludere quel traffico dalla 
gestione degli stati andavano facilmente a saturare (parliamo di qualche 
anno fa, ma non di eoni).
Escludere quel flusso dalla state machine ha impatto zero sulla 
sicurezza di quel flusso, non impatta sulla gestione stateful di tutto 
il resto del traffico e consente di utilizzare apparati di dimensioni 
"pi� sensate" per le effettive esigenze.
Win-win.
Upgradare ad un apparato in grado di gestire tutti gli stati, per poi 
sottosfruttarlo in termini di banda e funzionalit�, sarebbe stato assurdo.
-- 
http://bofhskull.wordpress.com/


Stateful � addirittura un termine fuori luogo riferito a traffico udp, visto 
che udp non ha nessun concetto di stato, quindi la tua esposizione pu� 
essere condivisibile, in effetti un firewall puro non avrebbe aggiunto molto 
in termini di sicurezza in uno scenario del genere.
Devi per� essere incappato in un prodotto abbastanza limitato, visto che un 
non modernissimo pix515, che tra l'altro non era esattamente famoso per le 
sue prestazioni, garantiva una cosa tipo (spero che la memoria non mi 
tradisca) 130000 sessioni concorrenti e qualcosa tipo 7/8000 nuove sessioni 
al secondo.
Il Pix515 � uscito pi� o meno nel 1998.
Ciao,
         Tosh. 

 Il Pix515 � uscito pi� o meno nel 1998.
L'esperienza � "quasi diretta" nel senso che -appunto- non la ho vissuta 
io direttamente e non so nemmeno quale fosse di preciso l'apparato in 
questione.
Mantenendosi sul vago, era uno dei due mirror italiani di una 
estremamente nota DNSBL internazionale: uno dei mirror sta da me ed � 
mantenuto da me. L'altro stava da un grosso ISP di dimensione nazionale 
ed era mantenuto da loro.
Quest'ultimo aveva grossi problemi con il firewall piazzato davanti al 
mirror, del tipo succitato, che ogni tanto "rasava" il traffico diretto 
al mirror causando mancanza di risposte alle interrogazioni, fino a 
quando si � deciso di eliminare quel mirror dal pool (anche in 
conseguenza di altre condizioni, per essere sinceri). Questo avveniva 
nel 2004-2005, mi pare di ricordare.
Il mirror da me fa da firewall per s� stesso e, per la cronaca, il 
computo medio degli stati si attesta attorno a quota 80K, con picchi 
oltre quota 120K (potrei anche escludere quel traffico dalla state 
machine, ma non me ne sono mai preso la briga).
Se un ipotetico firewall da 130K stati gli stesse davanti, dovrebbe 
servire solo lui, o anche la mera presenza di attivit� poco intensive lo 
saturerebbe facilmente...
-- 
http://bofhskull.wordpress.com/

 nell'asa? 
Perchè se ho *già* un pezzo di ferro, vorrei potere usare quello senza
doverne comprare un altro.

 Stateful è addirittura un termine fuori luogo riferito a traffico udp
Il concetto di stato, parlando di firewall, può essere generalizzato
anche per protocolli la cui natura è stateless.

 anche per protocolli la cui natura � stateless.
Questo perch� il firewall ha bisogno di creare le regole per il traffico di 
ritorno, quindi deve inventarsi uno stato anche quando non esiste, di fatto 
deduce (meglio dire che immagina) lo stato di una connessione udp dal 
semplice fatto che passino o non passino pacchetti. 

 saturerebbe facilmente...
Questi sono numeri del 2009, non vorrai mica farli manipolare da un prodotto 
del 1998? :-)
Il numero di sessioni concorrenti gestibili � essenzialmente un problema di 
memoria, un qualunque prodotto moderno possiede multipli della memoria che 
aveva il pix515 (64M o 128M) ad una frazione del costo.

 doverne comprare un altro.
Dal tuo punto di vista � pi� che comprensibile, per� non ho mai visto cisco 
molto smaniosa di correre dietro a funzionalit� che non fossero *diciamo 
cos�* strategiche sui pix e poi sugli asa.
Fin dall'inizio cisco ha privilegiato la stabilit� e la sicurezza al 
proliferare delle funzionalit�, soprattutto se si parla di funzionalit� poco 
richieste.
Ricordo che lo slogan di allora era *sistema operativo su misura e codice 
ridotto all'osso* in contrasto al noto e pi� agguerrito (oltre che ai tempi 
pi� blasonato) concorrente che si appoggiava ad un sistema operativo general 
purpose, per giunta a finestre.
Ricordo anche quanto tempo si sono aspettate certe funzionalit�, la prima 
che mi viene in mente � il supporto per l'esmtp.
Ancora adesso non � possibile ad esempio impostare una modalit� mista 
routing/bridging quando diversi concorrenti lo fanno da anni, da quanto ne 
so io pagando per� un prezzo nella stabilit�
Non ho la minima idea se nelle prossime release avrai quello che ti serve, 
al momento non mi risulta che sia possibile fare quello che chiedi, per� se 
ci spieghi meglio il tuo problema magari possiamo trovare un sistema per non 
farti buttare l'asa.
Ciao,
        Tosh. 

 aveva il pix515 (64M o 128M) ad una frazione del costo.
Vero. Il che sposta in alto la soglia critica dove il problema di 
saturazione si presenta.
Ma -a differenza della possibilit� di escludere dei flussi dalla state 
machine- non lo risolve in alcun modo.
Prima una macchina come quella ti saturava gli stati. Adesso ne servono 
5. Ma d'altra parte la banda media a disposizione � 5 volte superiore 
(se non di pi�), il che ti riporta nella stessa identica situazione 
potenziale...
-- 
http://bofhskull.wordpress.com/


Se non ho capito male i dati che hai fornito erano attuali, quindi seguendo 
il tuo ragionamento una macchina come il pix515 avrebbe solo da poco tempo 
iniziato ad essere "stretta" e parliamo di un prodotto che ha oltre dieci 
anni di vita tecnologica, non capisco proprio dove sia il problema.
Ma se hai la possibilit� e ci tieni non sono assolutamente contrario ad 
escludere dei flussi dagli stati, in fondo � roba tua, semplicemente al 
momento se hai un cisco non mi risulta tu possa farlo, che questo sia 
discutibile sarei anche d'accordo, ma non posso per� farci niente. 

 discutibile sarei anche d'accordo, ma non posso per� farci niente.
Direi che stai rigirando la frittata in maniera abbastanza plateale: 
l'attuale ramo del thread giunge proprio in conseguenza del fatto che 
Whip diceva "possibile che il pix non lo faccia?" e tu rispondevi 
"perch� mai dovrebbe farlo?"
La mia era una testimonianza sul perch�, in alcune situazioni, sarebbe 
utile che lo potesse fare.
Fine.
-- 
http://bofhskull.wordpress.com/

 utile che lo potesse fare.
Come io ti ho spiegato che cisco non si sceglie per la flessibilit�, 
concorderai che imbottire i prodotti di funzionalit� ingrossa il codice e lo 
rende potenzialmente pi� instabile e insicuro, proprio il contrario di 
quello che molti cercano in un prodotto di sicurezza, che sempre pi� regge 
applicazioni strategiche per le aziende e non la semplice navigazione.
Poi c'� funzionalit� e funzionalit�, aggiungere ad esempio una certification 
authority a lumi vuol dire aggiungere un sacco di codice che per� � 
totalmente slegato da quello del sistema, mentre aggiungere la possibilit� 
di escludere del traffico dagli stati � sicuramente una cosa che impatta 
pesantemente sul motore del firewall e dovrebbe portare a criticit� ben 
diverse.
Ciao,
        Tosh. 

 quindi ho cambiato leggermente posizione, dovresti esserne compiaciuto.
Compiaciutissimi, davvero, di avere una visione del networking un po' più
generale del networking rispetto ai monovendor advocates.

 generale del networking rispetto ai monovendor advocates.
Per le guerre di religione sono disponibile solo in pvt. 

 Per le guerre di religione sono disponibile solo in pvt.
Io non sono disponibile neanche in privato, essendo generalmente agnostico
rispetto a tecnologie e vendor.
Uso ciò che meglio conosco e con cui mi trovo meglio quando possibile, o 
ciò che mi viene imposto laddove ci siano dei vincoli contrattuali, per cui
quando la controparte ritiene che un tunnel ipsec non possa essere chiuso
(chissà perchè) con un linux o bsd, ma vuole necessariamente un terminatore
cisco/checkpoint/whatever, beh, lo si fa, amen.
Evitare amene illazioni sull'altrui sanità mentale, a fronte di una domanda 
assolutamente sensata, contribuisce senza dubbio a evitare guerre, questo è 
certo.
Ciao.

 certo.
La domanda � sensata a posteriori, all'inizio non ho nessuna difficolt� a 
dire che mi sembrava quantomeno stramba, ma ho gi� detto di essermi 
ricreduto, evidentemente la mia (lunga, credimi) esperienza non ha mai 
contemplato nessun caso del genere.
In quanto alla sanit� mentale mi sembra chiaro che si trattava di una 
semplice espressione colorita, visto che subito dopo ho ammesso che un senso 
ce l'aveva, ma se ti sei offeso ti chiedo scusa.
Ciao,
         Tosh. 

 senso ce l'aveva, ma se ti sei offeso ti chiedo scusa. Ciao,
Nessun problema, personalmente, davo solo un senso a un'evidente escalation
verbale. :-)
Ciao.