access-list e IP dinamico con Cisco IOS

[popeye]

Domanda semplice semplice...

Supponiamo che io abbia una interfaccia con indirizzo IP assegnato dinamicamente (esempio: un "Dialer" configurato con "ip address negotiated") e che debba creare per tale interfaccia una access-list rule nella quale usare come indirizzo IP (sorgente o destinazione) proprio l'IP assegnato dinamicamente all'interfaccia.

Esiste un modo per farlo?

Su alcuni router (non Cisco) esiste in genere una "magic word" (es: <router> oppure <wan0-ip> oppure <self> etc.) che equivale all'indirizzo del router (o, meglio, della specifica interfaccia), in IOS non mi risulta una cosa del genere.

Any idea?

[TheIrish]

Non esiste che io sappia, ma d'altro canto non riesco a capitre a cosa potrebbe servirti visto che le interfacce del router non generano traffico autonomamente... se mi spieghi perché ti serve magari troviamo una soluzione equivalente

[popeye]

Non esiste che io sappia, ma d'altro canto non riesco a capitre a cosa potrebbe servirti visto che le interfacce del router non generano traffico autonomamente... se mi spieghi perché ti serve magari troviamo una soluzione equivalente

Credo anche io che, purtroppo, non esista; ed e` una seccante limitazione.

Riguardo l' "a cosa potrebbe servire" :

1) la tua domanda sottintende l'intenzione di filtrare il traffico USCENTE, ma a me non interessa SOLO quello; ed anche in quel caso cio` che dici non e` esatto: il router di traffico ne genera, e puo` essere anche parecchio. Qualche esempio:

- connessioni esplicitamente originate dal router (es. un telnet, un ftp/tftp)
- pacchetti verso un server RADIUS o TACACS
- messaggi di logging (remote logging)
- pacchetti verso un server NTP
- propagazione delle tabelle di routing
- pacchetti ICMP
- innumerevoli altri casi (ho citato solo i primi che mi sono venuti in mente)

In tutti i casi, com'e` ben noto, i pacchetti generati dal router hanno come indirizzo IP sorgente quello dell'interfaccia piu` prossima alla destinazione (in altri termini, l'interfaccia "da cui esce il pacchetto").

Considera un edge-router che collega una LAN (stub-network) alla Internet attraverso un link point-to-point con indirizzo IP assegnato dinamicamente (caso tipico: un PVC ATM ppp-mux verso la Internet, il classico PPPoA da/verso il carrier/provider, per intenderci); se dal router faccio un telnet verso un host presente in Internet (non della LAN interna, insomma), la connessione ha come IP di origine quello della WAN del router (negoziato dinamicamente dal PPP/IPCP).

Per avere un minimo controllo su casi del genere, IOS ci consente di specificare l'indirizzo sorgente per la maggior parte delle connessioni originate dal router (es: "ip telnet source-interface xxx", "ip radius source-interface xxx", "ip tftp source-interface xxx", etc.), ma in parecchi casi questo non e` sufficiente/desiderabile.

2) il problema si pone ANCHE per il traffico entrante: supponi, per esempio, che per un qualsiasi motivo voglia impedire un telnet dalla Internet verso l'IP dell'interfaccia WAN del router, ma consentirlo verso l'IP della ethernet (nell'ipotesi che quest'ultimo sia pubblico e ruotato staticamente dal carrier/provider)


Infine, e veniamo al motivo reale della mia richiesta, un filtro del genere risulta indispensabile per una efficace protezione contro lo spoofing e per un preciso controllo dei pacchetti sparati verso la Internet.

E` buona regola (e mia abitudine) che un edge-router blocchi immediatamente tutti i tentativi di spoofing del "source-address"; mi spiego meglio: se dalla Internet mi vedo arrivare un pacchetto che ha come indirizzo sorgente un IP appartenente alla mia rete interna, devo bloccarlo dal momento che e` certamente un pacchetto irregolare ("spoofed"). Questo vale, ovviamente, ANCHE per l'indirizzo esterno (quello dinamico) del router. Ci sono centinaia di DoS-attack basati su questo principio (quasi tutti i DoS-attack con protocollo UDP operano uno spoofing del source address). Ebbene, io non sono in grado di filtrare i pacchetti con IP sorgente "spoofed" con quello assegnato dinamicamente al router.

...si, lo so che questo fatto specifico e` risolvibile in altro modo (interface command "ip verify unicast reverse-path", previa abilitazione del Cisco Express Forwarding), ma questa soluzione diventa parecchio rognosa nel caso in cui il router non sia al bordo di una stub-network e/o si sia in presenza di routing asimmetrico.

Spero di essere stato abbastanza chiaro.

Ciao.

[TheIrish]

ed anche in quel caso cio` che dici non e` esatto: il router di traffico ne genera, e puo` essere anche parecchio. Qualche esempio:

ammetto la mia carenza. Credevo (errando) che il traffico generato dal router avesse, in fase di routing, ancora l'indirizzo di loopback come di fatto avviene in linux.
Ho appena provato e in effetti non è così...
Sì, il problema è effettivamente gravoso.
Per il traffico entrante non è un gran problema perché in linea di massima si può risolvere parzialmente con il nat...
in effetti è un bel fastidio!

E` buona regola (e mia abitudine) che un edge-router blocchi immediatamente tutti i tentativi di spoofing del "source-address"; mi spiego meglio: se dalla Internet mi vedo arrivare un pacchetto che ha come indirizzo sorgente un IP appartenente alla mia rete interna, devo bloccarlo dal momento che e` certamente un pacchetto irregolare ("spoofed").

Direi che è essenziale.

Questo vale, ovviamente, ANCHE per l'indirizzo esterno (quello dinamico) del router. Ci sono centinaia di DoS-attack basati su questo principio (quasi tutti i DoS-attack con protocollo UDP operano uno spoofing del source address). Ebbene, io non sono in grado di filtrare i pacchetti con IP sorgente "spoofed" con quello assegnato dinamicamente al router.

Non ho capito... spoofano l'indirizzo dell'interfaccia WAN? in questo caso il router dovrebbe scartare il pacchetto automaticamente in prerouting.

[TheIrish]

RETTIFICA:
ci ho riflettuto un po' e francamente non sono riuscito a farmi uno scenario in testa in cui il problema non possa essere aggirato.
Sai dirmene uno, così magari ci penso. Mi intrippa 'sta cosa!
Il caso di telnet con una ethernet con ip pubblico si risolve discriminando la destinazione in logica inversa... quindi secondo me non è significativo