Diminuire gli attacchi alla propria rete tramite Null Route

Diminuire gli attacchi alla propria rete tramite Null Route; approntiamo una strategia di sicurezza della propria rete in modo attivo tramite Null Route. Questa idea sfrutta il principio del blackholing, manderemo quindi tutto il traffico diretto a una lista di reti ben distinte e identificate come dannose verso Null. So perfettamente che non è nulla di nuovo, tuttavia propongo questa soluzione dopo averla implementata per limitare gli attacchi alla rete che gestisco. Ultimamente gli attacchi ai CMS continuano ad aumentare, per questo motivo mi sono deciso ad attivare una struttura basata su BGP che sia in grado di aggiornarsi automaticamente diverse volte al giorno e bloccare il traffico delle reti insicure. Una forma di autodifesa perimetrale della rete di produzione. Analizziamo cosa sta alla base di questo sistema, l’idea è di usare delle liste di rotte provenienti da fonti antispam. Con queste liste opportunamente inserite da script in un server con installato quagga, si implementano le rotte verso Null necessarie. Quagga, un software installabile in ambienti linux, è in grado di generare un router virtuale cisco like nel sistema operativo che può instaurare delle sessioni BGP con i border router della nostra rete. In questo modo il sistema Quagga è in grado di rilasciare le rotte che opportunamente trattate da route-map manderanno il traffico verso un’interfaccia loopback che dirigerà, a sua volta, il traffico verso null. Il beneficio di quest’operazione è portato dalla mancata risposta al potenziale aggressore. Ulteriore vantaggio è il blocco delle connessioni scaturite da host già compromessi atte a scaricare componenti di codice malevolo in fase di preparazione degli attacchi. Le difficoltà in questo tipo di soluzione è scovare delle fonti sufficientemente ricche e con frequenti aggiornamenti da poter maneggiare per ottimizzare i blocchi.

Il sistema alla fine si presenterà come nel seguente grafico

Schema quagga protezione su border routers

Le fonti con cui ho deciso di lavorare sono le seguenti:

  • Spamhaus
  • blocklist.de
  • team-cymru.org

Per il funzionamento del sistema in automatico è necessario scrivere del software di automazione per l’aggiornamento delle rotte installate in quagga.
La configurazione da usare sui router di border sono le seguenti:

!
! Interfaccia Loopback per maneggiare in routing il traffico non desiderato
interface Loopback0
 ip address 172.26.0.1 255.255.255.255
!
! Configurazione della parte BGP tra il border router e Quagga
router bgp XXXXX
 redistribute static route-map blackhole
 neighbor [QUAGGA IP NEIGHBOR] remote-as 65249
 neighbor [QUAGGA IP NEIGHBOR] description QUAGGA
 neighbor [QUAGGA IP NEIGHBOR] ebgp-multihop 255
 neighbor [QUAGGA IP NEIGHBOR] update-source GigabitEthernet0/1
 neighbor [QUAGGA IP NEIGHBOR] version 4
 neighbor [QUAGGA IP NEIGHBOR] soft-reconfiguration inbound
 neighbor [QUAGGA IP NEIGHBOR] prefix-list no-out out
 neighbor [QUAGGA IP NEIGHBOR] route-map bgpf in
!
! Rotta per mandare il traffico non desiderato verso NULL
ip route 172.26.0.1 255.255.255.255 Null0
!
! Prefix list per prevenire la propagazione di prefissi non desiderati sulla sessione BGP con QUAGGA
ip prefix-list no-out seq 10 deny 0.0.0.0/0
!
! Route map per far si che il traffico intercettato venga rediretto verso nulla con priorità massima
route-map bgpf permit 10
 description border blackholing
 set local-preference 600
 set ip next-hop 172.26.0.1
!

Per quanto concerne il funzionamento degli script di automazione non sono ancora in grado di rilasciarli, per necessità scrivetemi

Cisco Errori WIC-1BRI-S/T-V3

 

Qualcuno ha già visto questi errori?
Parliamo di un cisco 1841 con una scheda WIC-1BRI-S/T-V3

System image file is “flash:c1841-advipservicesk9-mz.123-8.T11.bin”

[…]

cisco 1841 (revision 7.0) with 118784K/12288K bytes of memory.
Processor board ID FCZXXXXXXXXXX
2 FastEthernet interfaces
1 Serial(sync/async) interface
1 ISDN Basic Rate interface

Feb  3 09:14:26.421: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/1/0, TEI 84 changed to up
Feb  3 09:14:38.668: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0/1/0, TEI 84 changed to down
Feb  3 09:14:48.867: ASSERTION FAILED: file “/vws/bvb/CPY-v123_8_t_throttle.V123_8_T11/vob/ios.sys7/sys/obj-5k-c1840/../chips/gt96k/gt96k_timer.c”, line 771

 

Router Cisco

In pochi giorni due router cisco un 857-k9 e un 1801-k9 danneggiati. In entrambi i casi sono bruciate le porte atm.

Già in mendo di 48 ore a diversi chilometri di distanza in giorni di sole si sono danneggiate in modo irreparabile le porte atm dei router. Sapete perfettamente che difronte a una machina guasta non resisto e voglio aprire. Svito le viti, tolgo la copertura, controllo nei pressi della porta ed ecco! Un vistosissimo guasto dovuto a una sovratensione presumibilmente di circa 50V che hanno fatto fondere l’optoisolatore della porta. La tensione è stata così elevata e somministrata per un periodo (lungo) che ha addirittura carbonizzato la scheda in vetronite spessa due mm.

Ora il caso dice che i due router guastati erano collegati a una linea di un operatore N appoggiata sull’ultimo miglio telecom in due province differenti a almeno quaranta chilometri di distanza. La domanda sorge spontanea… Non è che per caso telecom ha qualche cos che non va sulle proprie linee…

Bho speriamo che non ricapiti su altri apparati….

Come al solito potete trovare le foto a questo link

Piscina in Riempimento