Comincio questo post per imparare se possibile come difendermi in rete da attacchi
La mia idea è di configurare l'HUB come fireware se è possibile allego uno show run dello stesso un 1568M della Cisco
ip address 192.168.0.6 255.255.255.0
ip default-gateway 192.168.0.1
!
!
interface Fastethernet 1/0/1
!
interface Fastethernet 1/0/2
!
interface Fastethernet 1/0/3
!
interface Fastethernet 1/0/4
lo show run mi mostra solo 4 porte perchè ho solo 4 periferiche connesse suppongo.
avendo il comando configure se fosse come il router a livello software teoricamente potrei assegnare delle regole ad ogni porta
Attendo conferma o smentita da TheIrish e MrCisco
Grazie
sicurezza in rete
Moderatore: Federico.Lagni
- TheIrish
- Site Admin
- Messaggi: 1840
- Iscritto il: dom 14 mar , 2004 11:26 pm
- Località: Udine
- Contatta:
intendevi dire firewall vero?l'HUB come fireware
Allora, l'hub non può svolgere questa funzione perché è un'apparecchiatura di livello 1, nemmeno lo switch classico che è di livello 2.
I router che tradizionalmente sono di livello 3 ma spaziano (quelli buoni) persino fino al 7, fungono pienamente allo scopo.
Ne consegue che l'unico attrezzo in tuo possesso in grado di fare firewalling, è il tuo router.
Quindi, abbandoiamo il discorso hub.
il tuo router è composto da 1 interfaccia ethernet, 1 atm e un'interfaccia virtuale atm0.1 creata da te nella conf descritta in http://www.ciscoforums.it/viewtopic.php?t=154
ethernet 0 e atm0.1 ci serviranno nella creazione del firewall.
Dipendentemente da ciò che devi far funzionare, le istruzioni di firewall possono essere più o meno complesse, più numerose o più esigue.
Certo, una conoscenza approfondita è sempre utile, ma per adesso forse è meglio costruire delle acl ad-hoc e in un secondo tempo pensare ad imparere qualcosa di nuovo, o no?
Quindi, posta su questo thread cosa fai normalmente con il computer e vedrò di buttare giù un paio di acl, commentando riga per riga, ok?
-
- Cisco fan
- Messaggi: 29
- Iscritto il: ven 31 dic , 2004 9:53 am
in linea di massima uso il pc fisso per scaricare con emule e chattare con mirc e msn poi ho il decoder che usa internet per scaricarsi dati una volta al giorno il portatile lo uso raramente ma piu per navigare che altro e pensavo di mettere su un pc esclusivamente per torrent visto che me ne avanza 1 poi ho i bambini che navigano col loro molto raramente (usano il mio che ha schermo lcd
poi ultima cosa uso vnc ogni tanto dal lavoro per controllare se è tutto om a casa sul mio pc
poi ultima cosa uso vnc ogni tanto dal lavoro per controllare se è tutto om a casa sul mio pc
- TheIrish
- Site Admin
- Messaggi: 1840
- Iscritto il: dom 14 mar , 2004 11:26 pm
- Località: Udine
- Contatta:
Allora, cominciamo!
Il fondamentale strumento di sicurezza offerto dai router Cisco sono le Access-Control-List.
Lavorano sui livelli 2, 3 e 4. Quindi sanno manipolare mac-address, indirizzi ip, porte e protocolli di trasporto. Addizionalmente, contemplano informazioni di livello superiore.
Ogni acl è un elenco di regole che vengono applicate nell'ordine in cui vengono scritte. Appena un pacchetto viene riconosciuto in una riga dell'acl, viene presa la decisione descritta da quella riga e il resto viene ignorato.
L'acl, poi, viene applicata ad un'interfaccia e questo serve a stabilire in che momento viene messa in pratica.
In fondo all'access list c'è un implcito deny any, ovvero, se il pacchetto non ha avuto alcun riscontro fino alla fine dell'acl, buttalo via.
Io comincio subito dalle ACL estese perché quelle base tendono ad avere poca applicazione nel networking moderno.
Il prototipo di una access list estesa è:
Questo in realtà è un prototipo molto scarno in quanto l'espressività e le possibilità offerte sono molto di più.
Facciamo subito un esempio:
sta a significare, qualsiasi dato tcp proveniente da qualsiasi indirizzo, verso l'host 192.168.0.5, porta 80, è accettato.
Ma anche:
significa, accetta qualsiasi dato tcp da qualsiasi host verso il network 192.168.0.0, 255.255.255.0 . Si noti come il secondo quartetto di ottetti non sia una netmask, ma il suo inverso, noto come wildcard.
Adesso, aggiungiamo un elemento di livello superiore:
Questo è un po' più particolare. Significa, accetta i dati tcp da qualsiasi host verso 192.168.0.0 255.255.255.0, solo se sono stati richiesti da 192.168.0.0 255.255.255.0, altrimenti passa oltre... comodo no?
Si noti come, per indicare 1 singolo ip, sia necessaria la parola chiave host
Ora che possediamo un po' di dimestichezza, proviamo una configurazione tipo, semplice semplice:
Con questo esempio:
1a riga: ciò che richiediamo tcp, può entrare
2a riga: le richieste di risoluzione DNS possono entrare
3a riga: accettiamo la tcp/4662 (edonkey tcp) se la destinazione è 192.168.0.5
4a riga: accettiamo la tcp/4672 (edonkey udp, credo) se la destinazione è 192.168.0.5.
Tutto il resto, viene buttato!
Adesso dobbiamo solo applicare queste regole ad una interfaccia...
Perché out? perché dobbiamo vedere il verso dei dati dall'interno del router. Out, perché esce da e0.
Fine prima lezione!!!
Facci sapere i tuoi progressi
Il fondamentale strumento di sicurezza offerto dai router Cisco sono le Access-Control-List.
Lavorano sui livelli 2, 3 e 4. Quindi sanno manipolare mac-address, indirizzi ip, porte e protocolli di trasporto. Addizionalmente, contemplano informazioni di livello superiore.
Ogni acl è un elenco di regole che vengono applicate nell'ordine in cui vengono scritte. Appena un pacchetto viene riconosciuto in una riga dell'acl, viene presa la decisione descritta da quella riga e il resto viene ignorato.
L'acl, poi, viene applicata ad un'interfaccia e questo serve a stabilire in che momento viene messa in pratica.
In fondo all'access list c'è un implcito deny any, ovvero, se il pacchetto non ha avuto alcun riscontro fino alla fine dell'acl, buttalo via.
Io comincio subito dalle ACL estese perché quelle base tendono ad avere poca applicazione nel networking moderno.
Il prototipo di una access list estesa è:
Codice: Seleziona tutto
access-list <100-199> <permit/deny> <tcp/udp/icmp> <sorgente/i> eq <porta sorgente> <destinazione> eq <porta destinazione>
Facciamo subito un esempio:
Codice: Seleziona tutto
access-list 101 permit tcp any host 192.168.0.5 eq 80
Ma anche:
Codice: Seleziona tutto
access-list 101 permit tcp any 192.168.0.0 0.0.0.255
Adesso, aggiungiamo un elemento di livello superiore:
Codice: Seleziona tutto
access-list 101 permit tcp any 192.168.0.0 0.0.0.255 established
Si noti come, per indicare 1 singolo ip, sia necessaria la parola chiave host
Ora che possediamo un po' di dimestichezza, proviamo una configurazione tipo, semplice semplice:
Codice: Seleziona tutto
access-list 101 permit tcp any 192.168.0.0 0.0.0.255 established
access-list 101 permit udp any eq domain 192.168.0.0 0.0.0.255
access-list 101 permit tcp any host 192.168.0.5 eq 4662
access-list 101 permit udp any host 192.168.0.5 eq 4672
1a riga: ciò che richiediamo tcp, può entrare
2a riga: le richieste di risoluzione DNS possono entrare
3a riga: accettiamo la tcp/4662 (edonkey tcp) se la destinazione è 192.168.0.5
4a riga: accettiamo la tcp/4672 (edonkey udp, credo) se la destinazione è 192.168.0.5.
Tutto il resto, viene buttato!
Adesso dobbiamo solo applicare queste regole ad una interfaccia...
Codice: Seleziona tutto
#conf t
(conf)interface e0
(conf-if)ip access-group 101 out
Fine prima lezione!!!
Facci sapere i tuoi progressi
-
- n00b
- Messaggi: 10
- Iscritto il: lun 03 gen , 2005 6:17 pm
- Contatta:
Complimenti per questo post-tutorial davvero ben fatto!
Fa sempre comodo un piccolo ripasso!
Ciauz
Luk
Fa sempre comodo un piccolo ripasso!
Ciauz
Luk
- TheIrish
- Site Admin
- Messaggi: 1840
- Iscritto il: dom 14 mar , 2004 11:26 pm
- Località: Udine
- Contatta:
Visto che la cosa sembra utile, passo alla seconda lezione!
La teoria vorrebbe che le Access-List benissero posizionate più vicine possibile alla sorgente dei dati. Allora perché non abbiamo posto le ACL su atm0.1? Daltra parte, sarebbe la posizione più vicina all'esterno!
Vero, però non dobbiamo dimenticare una cosa! Il roter in questione effettua il NAT. Quando i dati passano attraverso atm0.1, gli header dei pacchetti possiedono un indirizzo IP di origine e un indirizzo IP di destinazione... che però è quello di atm0.1! In altre parole, nulla ci vieta di porre le ACL su atm0.1, ma non saremmo in grado di controllare la destinazione effettiva (l'ip privato, per capirci).
Normalmente, io applico una acl anche all'interfaccia WAN, usando i criteri in logica inversa a quella dell'acl per e0.
Esempio:
Telnet è una brutta bestia e non vorremmo mai che, per disattenzione, una linea di configurazione fosse aperta anche all'esterno o che un server telnet per uso locale, venisse usato da fuori:
Ecco fatto, se il protocollo è telnet, allora scarta, altrimenti accetta. NON dimenticate il permit ip any any alla fine!!
Altra cosa curiosa potrebbe essere la seguente. Molti trojan horse usano le porte riservate per funzionare.... se noi non abbiamo server dietro il nostro router, perché permettere che queste siano in qualche modo raggiungibili??
Adesso non ci rimane che applicarla ad atm0.1 o a un dialer, dipendentemente dalla connessione.
In, perché stiamo controllando i dati in entrata.
CMQ sia, non pensiate che questa acl sia sufficiente! Rimane valida la sinergia con quella da applicare a E0!
Per ora basta! Aspettate il mio tutorial! CMQ, le domande sono bene accette
La teoria vorrebbe che le Access-List benissero posizionate più vicine possibile alla sorgente dei dati. Allora perché non abbiamo posto le ACL su atm0.1? Daltra parte, sarebbe la posizione più vicina all'esterno!
Vero, però non dobbiamo dimenticare una cosa! Il roter in questione effettua il NAT. Quando i dati passano attraverso atm0.1, gli header dei pacchetti possiedono un indirizzo IP di origine e un indirizzo IP di destinazione... che però è quello di atm0.1! In altre parole, nulla ci vieta di porre le ACL su atm0.1, ma non saremmo in grado di controllare la destinazione effettiva (l'ip privato, per capirci).
Normalmente, io applico una acl anche all'interfaccia WAN, usando i criteri in logica inversa a quella dell'acl per e0.
Esempio:
Telnet è una brutta bestia e non vorremmo mai che, per disattenzione, una linea di configurazione fosse aperta anche all'esterno o che un server telnet per uso locale, venisse usato da fuori:
Codice: Seleziona tutto
access-list 105 deny tcp any any eq telnet
access-list 105 permit ip any any
Altra cosa curiosa potrebbe essere la seguente. Molti trojan horse usano le porte riservate per funzionare.... se noi non abbiamo server dietro il nostro router, perché permettere che queste siano in qualche modo raggiungibili??
Codice: Seleziona tutto
access-list 106 deny ip any any lt 1023
access-list 106 permit ip any any
Codice: Seleziona tutto
#conf t
(config)interface atm0.1
(config-if)ip access-group 106 in
CMQ sia, non pensiate che questa acl sia sufficiente! Rimane valida la sinergia con quella da applicare a E0!
Per ora basta! Aspettate il mio tutorial! CMQ, le domande sono bene accette