ARGOMENTO:

Salve, ho difficolta' a chiudere 'esercizio e non caspico cosa abbia sbagliato, in allegato il file.
ciao

Ciao Roberto,
la soluzione prevede l'utilizzo di 2 ACL extended (una va quindi spostata sul Branch).

L'ACL extended da te configurata su HQ invece, sebbene funzionante, non corrisponde a quella della soluzione del PT. Chiaro che le ACL, rispetto ad un match 1 a 1 presentano un problema di valutazione (le ACL si possono scrivere in tanti modi). Quindi direi che per l'ACL extended in questione, non si può propriamente parlare di errore. Su quella standard invece direi che non andrebbe preferita da best practice ad una extended (se possibile), per filtrare a monte.

La soluzione prevista su HQ è la seguente:

ip access-list extended BranchServer
deny tcp any host 172.16.128.1 eq www
deny tcp any host 172.16.128.1 eq 443
permit ip any any

contro:

ip access-list extended BranchServer
deny tcp 172.16.64.0 0.0.63.255 host 172.16.0.1 eq www
deny tcp 172.16.64.0 0.0.63.255 host 172.16.0.1 eq 443
permit ip any any

entrambe ovviamente applicate verso entrante sulla G0/0 di HQ.

La riflessione che invito a fare è la seguente (colgo la scusa del tuo post per rivolgermi a tutti i tuoi compagni di corso):

Specificare la subnet dietro la g0/0 (ripeto, non è un errore), o scrivere "any", è uguale?

Quindi non ci sono errori logici ma solo scelte, e quindi ti vorrei dare le motivazioni delle scelte e ti facio osservare che per quanto concerne la acl extended quella che io ho impostato in maniera piu' restrittiva dal mio punto di vista risponde all'esigenza di non bloccare quanto non espressamente richiesto, quindi io ho bloccato solo cio' che e'stato esplicitamente indicato secondo a filosofia che tutto e' consentito a meno che non si siano espliciti divieti, considera che questo modo di "risolvere" ha un impatto importante in un eventuale ampliamento della sottorete 172.16.0.0/18 che dovesse ampliarsi e diventare una 172.16.0.0/17 la acl impostata come ho fatto io non avrebbe nessun impatto sugli host aggiunti e le acl resterebbero configurare allo stesso modo, invece con la scelta fatta per la risoluzione dell'esercizio un eventuale ampliamento della sottorete implicherebbe la revisione delle acl.
Per quanto concerne la questione della acl stadard non so come ma mi era parso di aver capito che esercizio mi stesse chiedendo in maniera esplicita di fare le acl standard (bohh), ma rileggendo adesso mi sono accorto che forse il mio inglese e' un po out of service.
Mi ritengo soddisfatto.

Chiarissimo il tuo punto di vista, ma la situazione in cui si rivede l'indirizzamento di una LAN (o anche si aggiunga un'ulteriore rete a valle della medesima) e si lascino inalterate le ACL è inverosimile.

L'any ha un senso diverso, ha quello di ottenere una sicurezza maggiore: evita infatti la possibilità da parte degli utenti di tale LAN di fare spoofing, ovvero utilizzare come sorgenti degli IP differenti e di fatto, unilateralmente, raggiungere il server sia in HTTP che HTTPS.

allora avrebbero dovuto dire che andava bloccato tutto il traffico in arrivo all'interfaccia xxxx verso gli indirizzi zzzz nel www https.
Comunque sono questioni marginali che riguardano, come al solito del resto, il processo di comissioning delle attivita'.
Resta il fatto che comunque se da una interfaccia di rete attestata alla lan dovesse uscire un pacchetto ip con indirizzo sorgente differente dal range ufficiale (che il router conosce bene perche configurato nela netmask dell'interfaccia di rete che si affaccia sulla sottorete) con destinazione e protocollo pero' ricadente nella filtro delle acl impostate penso che il router in primis un po tutta la rete non ruoterebbe il traffico destinato in maniera corretta e se anche dovesse arrivasse al router finale un pacchetto con un indirizzo destinazine al di fuori del range della lan non riesco ad immaginare come il roter lo possa ruotare crrettamente poi fare arp ecc.. ecc.. dimmi come.

Resta il fatto che comunque se da una interfaccia di rete attestata alla lan dovesse uscire un pacchetto ip con indirizzo sorgente differente dal range ufficiale (che il router conosce bene perche configurato nela netmask dell'interfaccia di rete che si affaccia sulla sottorete) con destinazione e protocollo pero' ricadente nella filtro delle acl impostate penso che il router in primis un po tutta la rete non ruoterebbe il traffico destinato in maniera corretta

I filtri lavorano in AND logico, se quindi uno dei parametri (es IP sorgente) non trova match l'ACE non trova match. Il routing lavora per IP destinazione, quindi la rete ruoterebbe correttamente se conosce la destinazione (in fase di routing il sorgente non viene visionato).

e se anche dovesse arrivasse al router finale un pacchetto con un indirizzo destinazine al di fuori del range della lan non riesco ad immaginare come il roter lo possa ruotare crrettamente poi fare arp ecc.. ecc..

Quando scrivi un pacchetto con un indirizzo destinazione immagino tu ti riferisca al sorgente ribaltato nella risposta. Ovviamente non potrebbe certo tornare indietro, andrebbe verso la sua reale destinazione se presente (avevo infatti scritto unilateralmente proprio per intendere il mancato routing di ritorno rispetto alla LAN di origine). Se ci pensi però, il PC è di fatto in grado di interagire (e dunque eventualmente veicolare attacchi) con tale server, sia in HTTP che HTTPS. Mi potresti dire che non si andrebbe oltre un eventuale SYN del TCP, resta il fatto però che il SYN non solo arriverebbe, ma verrebbe letto e genererebbe una risposta, a prescindere da dove essa poi verrebbe ruotata.

bene, comunque sarebbe cosi uno spoofing da organizzare utilizzando due host su due sottoreti differenti, uo per trasmetter ed un'altro per ricevere, ma visto che per fare cosi si deve accedere a due host ed anche a quello di cui si vuole sottrarre l'identita' no rieso a capire che utilita' potrebbe trarre.
O forse no, intravedo una utilita' ........