ESA: dual layer deployment

digg_url = “http://portadiferro.blogspot.com/2010/02/esa-dual-layer-deployment.html”;digg_title = “ESA: dual layer deployment”;digg_bgcolor = “#FFFFFF”;digg_skin = “normal”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;
Affrontiamo oggi le problematiche di un deployment dual layer della piataforma ESA. si tratta di una modalità di deployment composta da 2 distinte linee di ESA che assolvono funzioni diverse in termini di processo della mail.

Perchè un dual layer?

Innanzi tutto occorre capire se e quando occorre effettuare un dual layer. In deployment di tipo dual layer vi è sempre un elevato numero di appliance e lo scopo è, ovviamente, quello di gestire elevate moli di traffico e frequenti spike o attacchi. Si tratta quindi di deployment da grandi numeri ma l’analisi è meritevole di interesse. Esistono, innanzi tutto, 2 diverse filosofie di approccio al deployment dual layer:
  • reputation di frontend ed analisi al backend
oppure
  • divisione carico di analisi backend e frontend.
Entrambe le strutture rispondono ad esigenze specifiche di carico di lavoro e quindi sono da scegliersi previa analisi del carico di traffico da processare.
nel primo caso si opta per una prima linea che si “limiti” a processare le connessioni in ingresso utilizzando la reputation  e la gestione dei limiti di traffico smtp e quindi effettuando la delivery al layer sccessivo.
nel secondo caso si discrimina in funzione di qualche parametro la attività elaborativa dei due layer, il parametro piu comune è la mail size. in questo secondo caso alcune mail vengono consegnate direttamente al mailserver di backend mentre alcune vengono passate al secondo layer di analisi per poter essere poi consegnate al mailserver di backend.
Ci soffermeremo oggi, per ragioni di tempo, sulla analisi del modello che fa reputation e rimanderemo il secondo modello ad un altro post.

Dual Layer: 1° reputation filtering –> 2° altri processi

questo tipo di configurazione prevede che si pongano due layer distinti di apparati ESA che assolvano a funzioni diverse.
Il primo livello deve essere esposto su internet e quindi assolvere il servizio di Mx record, si prende in carico di gestire le connessioni entranti ed effettuare la analisi di reputation attraverso il Sender Base Reputation Score (SBRS) ela regolazione degli altri parametri di gestione del traffico smtp in ingresso. Deve quindi fare la delivery alle macchine di backend offrendo un eventuale buffer in caso di attacco sulla sua coda di delivery.
Il secondo livello preleva i messaggi esclusivamente dal primo livello e su questo effettua analisi antispam, antivirus, vof, content filtering e DLP offrendo una seconda linea di buffer in caso di overload o problematiche di consegna dei messaggi verso il mailserver.
dal punto di vista del deployment le macchine di front-end sono, in questa modalità, più piccole delle macchine di backend dovendo effettuare solo operazioni di gestione della connessione e di delivery. In questa ottica le macchine della famiglio C360 offrono le prestazioni più indicate, consentendo infatti di gestire un numero di mail consegnate pressocchè analogo ai piu grossi x1050.
Una maggiore capacità elaborativa non serve in quanto i processi più CPU intensive sono svolti dal secondo livello.
Essendo il primo livello il front-end della transazione è possibile fargli puntare direttamente gli MX record in maniera paritetica dando al servizio DNS round robin l’onere di ditribuire il carico.
Alternativamente è possibile prevedere un bilanciatore, indicato sopratutto nel caso vi siano limitazioni nel numero di IP utilizzabili.
le Macchine di front-end quindi devono prendere carico della mail in ingresso effettuando innanzi tutto il controllo della connessione attraverso il servizio senderbase.
Il primo livello quindi deve gestire le connessioni in ingresso.
A seguito della ricezione di una richiesta di connessione da parte di un host esterno (1)la prima attività svolta è notoriamente quella di effettuare un controllo sbrs al syn ack di presentazione del mittente effettuando una richiesta DNS verso senderbase (2). Senderbase risponderà (3) con il valore SBRS di quella sorgente, e quindi  l’apparato confronterà (4) tale valore con le policy di accettazione e procederà alla eventuale consegna.
dal momento che non esistono ulteriori attività da svolgere è possibile concentrarsi nella configurazione opportuna delle policy di accettazione delle connessioni.
Dal momento che la macchina è in grado di processare molto velocemente connessioni e delivery dei massaggi, non dovendo fare attività di AV o AS o DLP, è possibile essere piu conservativi per quello che riguarda il filtro senderbase rispetto ad una configurazione a singlolo layer.
Questo è legato, essenzialemente, al fatto che il tempo di processo di una conessione smtp è molto piu veloce, essendo scarica di servizi aggiuntivi, e quindi vengono rese disponibili risorse per la accettazione di nuove connessioni piu velocemente, per contro interrompere o limitare in maniera piu puntuale e severa la connettività smtp consente di ridurre in maniera ancora piu sensibile il traffico illegittimo.
In altre parole si cerca di ridurre il traffico in ingresso per connessione e, contemporaneamente, aumentare il numero di connessioni gestite.
In questo modo, visto che a livello smtp le connessioni illegittime non vengono di solito replicate, si ottien l’effetto di ridurre il traffico illegittimo non riducendo in maniera sensibile il traffico legittimo.
Un altro parametro da tenere presente su questo tipo di layer è il rischio di synflood, mailbombing o genericamente, ddos activities.
Dobbiamo distinguere, in questo caso, su due distinti livelli di attacco: a livello di connettività IP (es il synflood) o a livello SMTP (come ad esempio il mailbombing).
per capire il tipo di problematica cerchiamo di esemplificare il processo di connessione che porta alla consegna di un messaggio di posta:
1) il mittente (o l’ultimo hop) cerca di connettersi con una macchina il cui IP è identificato dalla risoluzione MX DNS o direttamente (caso piu comune in caso di attacco).
2) la prima connessione è ovviamente una connessione di tipo IP, ed il mittente si presenta con sun synack per attivare la connessione.
3) se la connessione viene rifutata per quache motivo (silent drop)  il mittente ritenta la connessione, assumendo un problema di connettività della controparte
4) se la connessione viene accettata si alza un nuovo handshaking per determinare la natura della connessione smtp
5) vengono determinati, a questo livello, una serie di parametri tra cui il numero di connessioni concorrenti da quella sorgente, il numero di messaggi che possono passare per connessione, il range di dimensioni accettate per i messaggi, il numero di recipient massimo accettato e cosi via.
6) se la connessione viene rifiutata a livello smtp con un messaggio di errore il sistema mittente non ritenta la trasmissione (o non dovrebbe ritentare) al più in funzione del messaggio generato
7) se la connessione è rifiutata senza ulteriori specifiche (silent drop) il mittente dovrebbe effettuare un retry della connessione assumendo che vi è stato un problema di comunicazione nel canale ip istaurato.
diventa quindi importante capire a che livello conviene interrompeere la connettività ed in che modo.
Effettuando un silent drop a livello di syn (TCP Refuse) gli host mittenti effettuano comunque un tentativo di connessione indipendentemente dal fatto che siano di origine malevola o meno. Questo è legato al fatto che, fondamentalmente, anche piattaforme infette che cercano di inviare traffico illegittimo si appogiano, dal punto di vista dello stack tcp-ip alle piattaforme OS su cui sono ospitate e quindi ne seguono il comportamento ai layer 2 e 3.
daltro canto effettuare un drop a livello syn è estremamente rapido e impiega poche risorse dellos tack tcp-ip.
la alternativa è aspettare ad effettuare il silent drop dopo l’apertura della sessione smtp (reject o delayed reject). Questa operazione impegna maggiormente lo stack tcp-ip ma ha il vantaggio di evitare i retry legati agli errori syn.
Come sappiamo le componenti che cositituiscono la mail flaw policy (la policy che determina il comportamento di accettazione o meno di una connessione) si basa su un comportamento iniziale definito dal seguente elenco

1. ACCEPT
La connessione viene accettata e vengono quindi appicate le restrizioni legate ai parmetri SMTP.
2. REJECT
La connessione viene inizialmente accettata ma al tentativo di invio di un messaggio il mittente riceve un  4XX or 5XX greeting. è anche possibile configurare AsyncOS per effettuare il reject al momento del RCPT TO, questa configurazione è detta Delayed Reject.
3. TCPREFUSE
La connessione è rifiutata a livello TCP.
4. RELAY
La connessione è accettata e non vengono posti vincoli di alcun tipo..

i parametri di definizione della connessione sono quindi descritti nella seguente tabella, estratta dalla userguide del prodotto (mica mi scrivevo tutto di nuovo a mano )
The maximum size of a message that will be accepted by this listener. The smallest possible maximum message size is 1 kilobyte.
Maximum concurrent connections from a single IP
The maximum number of messages that can be sent through this listener per connection from a remote host.
By default, the appliance will include the hostname associated with the interface of the listener when displaying the SMTP banner to remote hosts (for example: 220-hostname ESMTP). You may choose to override this banner by entering a different hostname here. Additionally, you may leave the hostname field blank to choose not to display a hostname in the banner.
Rate Limiting: Maximum Recipients per Hour
The maximum number of recipients per hour this listener will receive from a remote host. The number of recipients per sender IP address is tracked globally. Each listener tracks its own rate limiting threshold; however, because all listeners validate against a single counter, it is more likely that the rate limit will be exceeded if the same IP address (sender) is connecting to multiple listeners.
Rate Limiting: Max. recipient per Hour Exceeded Error Code
The SMTP code returned when a host exceeds the maximum number of recipients per hour defined for this listener.
Rate Limiting: Max. Recipients Per Hour Exceeded Error Text
The SMTP banner text returned when a host exceeds the maximum number of recipients per hour defined for this listener.
Group by Similarity of IP Addresses: (significant bits 0-32)
Used to track and rate limit incoming mail on a per-IP address basis while managing entries in a listener’s Host Access Table (HAT) in large CIDR blocks. You define a range of significant bits (from 0 to 32) by which to group similar IP addresses for the purposes of rate limiting, while still maintaining an individual counter for each IP address within that range. Requires “Use SenderBase” to be disabled. For more information about HAT significant bits, see the “HAT Significant Bits Feature” in chapter 1 of the IronPort AsyncOS for Email Advanced User Guide.
Directory Harvest Attack Prevention: Maximum Invalid Recipients Per Hour
The maximum number of invalid recipients per hour this listener will receive from a remote host. This threshold represents the total number of RAT rejections combined with the total number of messages to invalid LDAP recipients dropped in the SMTP conversation or bounced in the work queue (as configured in the LDAP accept settings on the associated listener). For more information on configuring DHAP for LDAP accept queries, see “LDAP Queries” in the IronPort AsyncOS for Email Advanced User Guide.
Directory Harvest Attack Prevention: Drop Connection if DHAP threshold is Reached within an SMTP Conversation
The IronPort appliance will drop a connection to a host if the threshold of invalid recipients is reached.
Drop Connection if DHAP threshold is reached within an SMTP Conversation
Specify the code to use when dropping connections due to DHAP within an SMTP conversation. The default code is 550.
Enable anti‑spam scanning on this listener.
Enable the anti‑virus scanning on this listener.
Allows, disallow, or requires SMTP Authentication from remote hosts connecting to the listener. SMTP Authentication is described in detail in the “LDAP Queries” chapter of the IronPort AsyncOS for Email Advanced User Guide.
If Both TLS and SMTP Authentication are enabled:
Enable SPF/SIDF Verification
Set the SPF/SIDF conformance level. You can choose from SPF, SIDF or SIDF Compatible. For details, see IronPort AsyncOS for Email Advanced User Guide.
Downgrade PRA verification result if ‘Resent-Sender:’ or ‘Resent-From:’ were used:
If you choose a conformance level of SIDF compatible, configure whether you want to downgrade Pass result of the PRA Identity verification to None if there are Resent-Sender: or Resent-From: headers present in the message. You may choose this option for security purposes.
Configure whether you want to perform a test against the HELO identity (Use this for SPF and SIDF Compatible conformance levels).
Consider Untagged Bounces to be Valid
Applies only if bounce verification tagging (discussed in detail in the IronPort AsyncOS for Email Advanced User Guide) is enabled. By default, the appliance considers untagged bounces invalid and either rejects the bounce or adds a custom header, depending on the Bounce Verification settings. If you choose to consider untagged bounces to be valid, the appliance accepts the bounce message.
in configurazione dula layer è quindi indispensabile definire correttamente le policy di accettazione per offrire il filtro piu efficace in caso di traffico illegittimo e mantenere la operatività per il traqffico legittimo.
In questa ottica solitamente consiglio di attivare il delayed reject per le connessioni di cui si effettua il reject, ed addirittura il TCP refuse per valori di sbrs particolarmente bassi.
Nel caso di sessioni accettate via ACCEPT è opportuno definire un range di policy che consentano di filtrare il traffico in funzione del punteggio sbrs. (ricordiamoci che mentre le policy sono statiche il punteggio sbrs varia in real time alla connessione e quindi un mittente può finire in una o l’altra policy in funzione del suo status come emettitore di traffico legittimo eo illegittimo).
Tendenzialmente non è buona norma consentire l’ACCEPT a valori di SBRS minori di –3 e non è consigliabile il TCP refuse per valori di SBRS superiori al –5.
Va anche ricordato che SBRS definisce sia un punteggio “0” che un punteggio “none” che indicano cose abbastanza diverse ma sono profondamente relati l’un con l’altro.
Un “None” indica che tale IP non è mai stato monitorato dal sistema, mentre un punteggio “0” indica un punteggio neutro. è anche vero che molte nuove entry in senderbase hanno all’inizio un punteggio “0”, quinid molti “None” diventano presto “0” prima di assumere un valore stabilizzato in funzione del traffico che generano.
La mail flaw policy di primo livello, quindi, va costruita attorno a fasce di punteggi SBRS.
A parità di punteggio sbrs è poi opportuno definire opportune policy di filtro legate al PTR.
Come sapete il PTR non è un requirement forte per le RFC che fanno riferimento all mail, e quindi bloccare i messaggi porvenienti da sorgenti non PTR compliant provocherebbe un alto rischio di falso positivo. è anche vero che la maggior parte dei sistemi postali correttamente configurati dovrebbe avere definiti gli opportuni PTR, è quidi comprendsibile definire policy piu lasche per chi ha definito correttamente il PTR e piu stringenti per chi non lo ha fatto.
Vi ricordo, per altro, che nella maggior parte dei DNS servers la definizione di una entry diretta nel database non comporta la creazione automatica di PTR.
è possibile definire un set di mail flaw policy estremamente puntuale, e va portata una particolare attenzione ai parametri di concorrenza. La comunicazione col secondo livello è demandata dalla definizione delle opportune smtp routes.
Ovviamente è possibile definire sia l’acesso diretto verso le appliance di backend in maniera paritetica per ogni appliance (usando smtp routes paritetiche) o con weighted routes per distribuire il traffico in maniera asimmetrica per i diversi appliances di frontend.
è anche possibile definire filtri per distribuire il traffico in funzione, ad esempio, della dimensione dei messaggi. questa opzione potrebbe avere un senso sopratutto nel caso che esistano diffeenze significative nella struttura e natura dei messaggi in arrivo.
per quello che concerne la configurazione del backend, ovviamente occorre ricordarsi che va configurato per gestire il forntend come trusted source. In questa maniera non viene corso il rischio di bloccare flussi di traffico dal frontend.
inoltre questa operazione permette al sistema di non utilizzare reputation all’ingresso ma di utilizzzarlo poi su ipas per la determinazione dello spam.
sul layer di backend esistono almeno un paio di operazionie che ha senso affettuare:
1) Aumento della dimensione minima dei messaggi che devono essere analizzati come spam
questa operazione, resa possibile dal minor carico elaborativo e dal buffer introdotto dal layer 1, permette una maggire efficacia nella detection di spam di dimensioni medie. Questo trend è in progresso a causa del diffondersi di una maggiore banda e cpacità elaborativa degli host infetti.
2) attivazione della detection del mass email marketing su ipas
ovviamente è consigliabile anche attivare la funzionalità di intelligent multiscanning per far operare in maniera concorde i motori antispam disponibili sulla piattaforma (ipas e cloudmark). Questa operazione migliora ulteriormente la capacità di detection e abbassa l’onere elaborativo dell’appliance utilizzando in maniera efficace le diverse caratteristiche dei due motori antispam.
alla prossima puntata affronteremo il tema del dimensionamento di questa soluzione, introducendo dei temi piu generali che valgono per il generico dimensionamento di una soluzione di security.
ovviamente qualsiasi commento è ben accetto
ciao
A
Enhanced by Zemanta

ESA: dual layer deployment was originally published on The Puchi Herald Magazine

To the official site of Related Posts via Taxonomies.

CC BY-NC-SA 4.0 ESA: dual layer deployment by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.