Newsgroup: it.comp.reti.cisco
Titolo: Configurazione PIX: mi date una mano?

Ciao!
Lavoro da anni sui firewall ma non sui Cisco PIX. 
Per serie di motivi, dovrò dare un'occhiata ad un PIX (version 6.2) e
quindi volevo alcune conferme e chiarimenti da voi che conoscete bene
questo specifico firewall. Conto sul vostro aiuto :)
1) Il NAT verso l'esterno viene implementato con la coppia di comandi
(NAT,GLOBAL). Corretto?
2) Il NAT verso l'interno viene implementato attraverso il comando
STATIC. Corretto?
3) Il NAT da una interfaccia all'altra DEVE avvenire sempre. Corretto?
4) Se sì al punto 3), perchè esiste questa logica del PIX con il NAT
obbligatorio? Perchè non lasciare la possibilità di configurare un
firewall in base ad un semplice routing più delle acl?
5) Un acl mappata come "in" indica che viene applicata in ingresso
all'interfaccia e quindi in ingresso al pix attraverso tale
interfaccia. Corretto?
6) E' possibile associare delle acl in uscita alle interfacce  e
quindi creare dei filtri in uscita dall'inside all'outside?
7) Cosa lascia passare (ossia a cosa serve)  in pratica un'acl che
permette tutto e il solo traffico ip (e non tcp/udp/icmp)?
8) In quale ordine ad un pacchetto che arriva al pix vengono
applicati: routing, NAT e acl? Forse: ACL (tipo "in"), poi NAT e poi
routing?
9)  In uscita dal pix, avviene la stessa cosa (con le acl "out")?
10) Affinchè un pacchetto giunga effettivamente a destinazione devono
essere presenti il routing (comando ROUTE),  il natting (GLOBAL+NAT o
STATIC), e le acl (access-list permit) per tale pacchetto? Se manca
uno e uno solo di questi elementi, il pacchetto non viene instradato?
es. se uso solo un opportuno routing e un'acl (senza nat) il pacchetto
arriverà alla destinazione? Oppure solo nat ed acl?
11) Trovate qualcosa di scorretto, anomalo o poco pulito su una
configurazione come la seguente:
nameif ethernet1 inside security100
nameif ethernet3 dmz security50
ip address inside 192.168.100.15 255.255.255.0
ip address dmz 192.168.2.15 255.255.255.0
access-group acl_dmz in interface dmz
access-list acl_dmz permit tcp 192.168.2.0 255.255.255.0 host
192.168.2.31 eq netbios-ssn
static (inside,dmz) 192.168.2.31 192.168.100.110 netmask
255.255.255.255 0 0
12) La versione 6.2 del Pix implementa la stateful inspection dei
pacchetti? Occorre specificare qualcosa nella configurazione oppure è
di default nelle acl?
13) La versione 6.2 supporta l'accesso via SSHv2 e non solo SSHv1?
14) Esistono vulnerabilità note per tale firewall?
15) Qualche consiglio dal punto di vista della sicurezza?
Un milione di grazie ^___^
The Big O

15) Qualche consiglio dal punto di vista della sicurezza?
Sono tutto orecchi! :)
Infine, un paio di questioni più generali:
a) Avendo abbastanza ip pubblici da copire tutti i server pubblici
esistenti, perche' NON dovrei usare il NAT tra la outside e la DMZ?
Ossia in che scenario usare gli ip pubblici sulla DMZ senza NAT?
b) Che controindicazioni generali può avere una default route verso
l'inside?
Grazie ancora :)
The Big O

e per avitare che il deny ip any any implicito spazzi via tutto
Ponendola in altro modo: cosa farebbe passare in più un'acl "permit ip
any any" rispetto a una " permit tcp any any + udp any any" ?
Grazie
The Big O

The Big O wrote:

dopo permit tcp e udp any any non serve
dopo una riga deny si

 any any" rispetto a una " permit tcp any any + udp any any" ?
mah...per esempio il ping.
Ciao
Marco

mah...per esempio il ping.
Si? Non e' necessario avere un permit icmp any any?
The Big O


se metti permit ip any any funziona anche il ping che utilizza il protocollo
IP, ma non e' ne' TCP ne' UDP, ma appunto ICMP. Con permit ICMP permetti il
ping ma blocchi TCP e UDP...
Ciao
Marco

ping ma blocchi TCP e UDP...
Ok, quindi con ip permetto tutti i protocolli basati su ip.
su un pix si potrebbe dire quindi che permit ip any any č come permit
tcp any any, permit udp any any, permit icmp any any?
Grazie ancora
The Big O

 tcp any any, permit udp any any, permit icmp any any?
mah...direi di si...non mi vengono in mente altri protocolli che utilizzino
IP.
Ciao
Marco