In seguito al post fatto da Andre321 sul forum di ISAServer.it ho pensato di chiarire come ISA Server elabora la Firewall Policy, concentrando l'attenzione sugli aspetti principali, rimandando ad altri post ulteriori approfondimenti.
La Firewall Policy è costituita da due gruppi di Access rule:
1. Regole di Sistema (System Policy)
2. Regole definite dall'amministratore (Access Rule)
Nota: Le regole di sistema non sono eliminabili dall'amministratore del firewall.Non e' possibile per l'amministratore del firewall creare nuove regole di sistema dalla consolle di amministrazione di ISA Server. Solo alcune regole di sistema sono attivabili/disattivabili o modificabili, limitatamente ad alcuni attributi, dall'amministratore.
In questo post ci concentreremo principalmente sulla elaborazione delle Access rule create dall'amministratore per controllare il traffico uscente.
Scenario
Consideriamo una configurazione di ISA Server di tipo Edge - 2 NIC: 1 Internal, 1 External - e membro di dominio. La rete External connette ISA Server ad Internet.
Tipologia di Accesso
Sono definite tre tipologie di accesso identificate da tre diversi User:
User1 si connette da una postazione configurata come WebProxy Client - es. una postazione Internet -.
User2 si connette da una postazione configurata come SecureNAT Client - es. un server pubblicato -.
User3 da una postazione configurata con il Firewall Client - es. un postazione di dominio -.
Tipologia di Traffico
Sono identificati due tipologie di traffico:
A. Traffico HTTP (Anonimo)
B. Qualunqe altro tipo di traffico - es. FTP, POP3 ecc. - (Autenticato)
Per raggiungere il nostro obiettivo creiamo una Firewall Policy cosi' strutturata:
1. Regola #1
2. Regola #2
Regola #1:
Action: Allow
Protocol: HTTP
From: Internal
To: External
Schedule: Always
User: All Users
Questa regola dice:
E' consentito l'utilizzo del protocollo HTTP dalla rete Internal verso la rete External da parte di tutti gli utenti (accesso anonimo)
Regola #2:
Action: Allow
Protocol: All Outbound Traffic
From: Internal
To: External
Schedule: Always
User: All Authenticated Users
Questa regola dice:
E' consentito l'utilizzo di qualunque protocollo dalla rete Internal verso la rete External da parte di tutti gli utenti riconoscibili (accesso autenticato)
Come ISA Server analizza le richieste
Per prima cosa ISA Server verifica che sia presente una Network rule fra la rete di origine - Internal - e quella di destinazione - External -. Se non esiste una regola che collega la rete di origine con quella di destinazione la richiesta viene rifiutata!!
Nota: Questa condizione non si applica per i client WebProxy.
Una volta verificata l'esistenza della Network rule, ISA Server inizia l'elaborazione delle Access rule in base all'ordine con cui sono visualizzate nella Consolle di Amministrazione - sezione Firewall Policy -.
Ciascuna Access rule e' composta da una serie di componenti - es. Protocol, Source, Users ecc. -. Una Access rule viene elaborata se e solo se tutti i campi sono verificati, in caso contrario ISA potra' procedere con l'elaborazione della regola successiva o negare immediatamente l'accesso senza procedere con le regole successive.
I campi della Access rule vengono elaborati seguendo un preciso ordine:
1. Protocol
2. From (source) address e port
3. Schedule
4. To (destination) addresses, names, URLs
5. Users
6. Content groups
Alla luce di quanto detto consideriamo il caso in cui i nostri tre utenti tipo generano traffico secondo le due tipologie di traffico che stiamo considerando.
Ecco come vengono elaborate le richieste per i vari utenti.
CASO A - Traffico HTTP
Gli utenti User1, User2 e User3 vogliono accedere al forum di ISAServer.it - http://www.isaserver.it/forum -.
User1(WebProxy) genera traffico HTTP
| | Regola #1 | Richiesta | Esito |
| Protocol | HTTP | HTTP | PASS |
| From | Internal | <IP Client in LAN> | PASS |
| Schedule | Always | * | PASS |
| To | External | www.isaserver.it/forum | PASS |
| Users | All Users | Dominio\User1 | PASS |
| Content | All Content | * | PASS |
Tutti i campi sono verificati, si applica la Regola#1 a User1.
Esito: User1 esce su Internet ed ISA non procede con l'elaborazione della Firewall Policy.
User2(SecureNAT) genera traffico HTTP
| | Regola #1 | Richiesta | Esito |
| Protocol | HTTP | HTTP | PASS |
| From | Internal | <IP Client in LAN> | PASS |
| Schedule | Always | * | PASS |
| To | External | www.isaserver.it/forum | PASS |
| Users | All Users* | Anonimo** | PASS |
| Content | All Content | * | PASS |
(*) All Users include anche l'utente Anonimo
(**) Il client SecureNAT si presenta sempre come Anonimo
Tutti I campi sono verificati, si applica la Regola#1 a User2.
Esito: User2 esce su Internet ed ISA non procede con l'elaborazione della Firewall Policy.
User3(Firewall Client) genera traffico HTTP
| | Regola #1 | Richiesta | Esito |
| Protocol | HTTP | HTTP | PASS |
| From | Internal | <IP Client in LAN> | PASS |
| Schedule | Always | * | PASS |
| To | External | www.isaserver.it/forum | PASS |
| Users | All Users | Dominio\User3 | PASS |
| Content | All Content | * | PASS |
Tutti I campi sono verificati, si applica la Regola#1 a User3.
Esito: User3 esce su Internet ed ISA non procede con l'elaborazione della Firewall Policy.
CASO B - Traffico NON HTTP
Gli utenti
User1, User2 e User3 vogliono accedere al sito FTP di Microsoft -
ftp.microsoft.com -.
User1(WebProxy) genera traffico FTP Download
| | Regola #1 | Richiesta | Esito |
| Protocol | HTTP | FTP | FAIL |
Non essendo verificato il protocollo, ISA Server passa alla Regola successiva
| | Regola #2 | Richiesta | Esito |
| Protocol | All Out. Tr. | FTP | PASS |
| From | Internal | <IP Client in LAN> | PASS |
| Schedule | Always | * | PASS |
| To | External | ftp.microsoft.com | PASS |
| Users | All Auth. Users | Dominio\User1 | PASS |
| Content | All Content | * | PASS |
Tutti I campi sono verificati, si applica la Regola#2 a User1.
Esito: User1 puo' scaricare da Internet file via FTP , ISA non procede con l'elaborazione della Firewall Policy e si mette in attesa di elaborare una nuova richiesta.
User2(SecureNAT) genera traffico FTP Download
| | Regola #1 | Richiesta | Esito |
| Protocol | HTTP | FTP | FAIL |
Non essendo verificato il protocollo, ISA Server passa alla Regola successiva
| | Regola #2 | Richiesta | Esito |
| Protocol | All Out. Tr. | FTP | PASS |
| From | Internal | <IP Client in LAN> | PASS |
| Schedule | Always | * | PASS |
| To | External | ftp.microsoft.com | PASS |
| Users | All. Auth. Users | Anonimo | FAIL |
| Content | All Content | * | PASS |
Questa condizione va analizzata con attenzione; in questo caso la regola richiede il riconoscimento dell'utente (All Authenticated Users).
Vediamo come si comporta ISA Server quando una Access Rule richiede l'autenticazione dell'utente:
- Se l'utente fornisce le proprie credenziali ed e' membro del gruppo inserito nella regola, allora viene processata la regola (Allow o Deny), ISA Server NON prosegue a leggere la Firewall Policy ed e' pronto per processare una nuova richiesta.
- Se l'utente fornisce le proprie credenziali ma NON e' membro del gruppo inserito nella regola, allora ISA passa ad analizzare la regola successiva. ISA Server continua a scorrere la Firewall Policy fino a trovare una Access rule che si applica al tipo di traffico generato dall'utente. Se non trova nessuna Access rule definita dall'amminstratore allora applicherà l'ultima Access rule in eleneco che, solitamente, e' quella di default.
- Se l'utente non fornisce le proprie credenziali presentandosi come Anonimo, ISA nega immediatamente l'accesso all'utente, interrompe l'elaborazione delle Firewall Policy e si mette in attesa di elaborare una nuova richiesta.
Nel caso di client SecureNAT l'utente si presenta SEMPRE come anonimo, quindi NON riconoscibile. Non potendo riconoscere l'utente, cosi' come richiesto dalla Access rule, ISA Server nega l'accesso e non procede oltre con l'elaborazione della Firewall Policy.
In questo caso User2 si presenta come anonimo. ISA non potendolo riconoscere blocca l'accesso e NON procede oltre.
Esito: User2 NON puo' scaricare da Internet file via FTP , ISA non procede con l'elaborazione della Firewall Policy e si mette in attesa di elaborare una nuova richiesta.
Nota: Un client SecureNAT e' un client in cui e' stato inserito il default gateway nella configurazione del TCP/IP; nessun'altra configurazione e' stata fatta sul browser Internet.
User3(Firewall Client) genera traffico FTP Download
| | Regola #1 | Richiesta | Esito |
| Protocol | HTTP | FTP | FAIL |
Non essendo verificato il protocollo, ISA Server passa alla Regola successiva
| | Regola #2 | Richiesta | Esito |
| Protocol | All Out. Tr. | FTP | PASS |
| From | Internal | <IP Client in LAN> | PASS |
| Schedule | Always | * | PASS |
| To | External | ftp.microsoft.com | PASS |
| Users | All. Auth. Users | User3 | PASS |
| Content | All Content | * | PASS |
Tutti I campi sono verificati, si applica la Regola#2 a User3.
Esito: User3 puo' scaricare da Internet file via
FTP , ISA non procede con l'elaborazione della
Firewall Policy e si mette in attesa di elaborare una nuova richiesta.
Conclusioni:
ISA Server elabora le regole nell'ordine con cui sono inserite nella Firewall Policy. La regola da applicare viene riconosciuta analizzando nell'ordine i seguenti parametri:
1. Protocol
2. From (source) address e port
3. Schedule
4. To (destination) addresses, names, URLs
5. Users
6. Content groups
Se Tutti i campi solo validati allora si applica la regola, in caso contrario ISA continua l'elaborazione con la regola successiva.
Nel caso in cui la regola richiede all'utente di identificarsi - es. quando si utilizzano gruppi di utenti - e l'utente non e' in grado di fornire le proprie credenziali, ISA Server blocca la richiesta e non procede con l'elaborazione.
E' comunque importante evidenziare che questo avviene solo se l'utente ha generato un tipo di traffico - es. FTP, HTTP; POP3 ecc. - che e' analizzato dalla regola che prevede l'autenticazione.
Buon lavoro con ISAServer.it
