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

AWHOIS

AWHOIS – Nuovo tool whois dedicato alla rete! Rilasciata la seconda versione

Tool complementare a whois che in automatico ricerca sia l’indirizzo IP associato a un nome host sia i dettagli di rete per quanto riguarda ASN, Classe IP, COUNTRY, ORGANIZZAZIONE. Questo tool è utile nella gestione della rete e delle blacklist o blackholing tramite BGP.

Nella versione 0.2 è stato introdotto il riconoscimento automatico dell’IP con la conseguente gestione senza risoluzione del nome. Di fatto con la versione 0.1 non era possibile utilizzare il tool per interrogare i server WHOIS direttamente con l’IP.

Ver 0.2 – DOWNLOAD – 28.11.2013
Ver 0.1 – DOWNLOAD – 6.11.2013

Richiede un sistema linux con installato Perl, Whois e host.

Cisco ASA, CallManager, VPN e telefono cisco 7941

Mi sono imbattuto in una configurazione con: Cisco ASA, CallManager, VPN e telefono cisco 7941. La configurazione risulta essere molto semplice, un centro stella con un firewall Pfsense collegato con una sede periferica in cui si è deciso di installare un Cisco ASA 5505. Il traffico della sede periferica deve accedere ai server del centro stella, la cosa più immediata da fare è una VPN IPsec. Fino a questo punto per la parte dati no ci sono problemi, appena attacco il telefono Cisco 7941 all’ASA si accende, visto che la rete telefonica remota ha una classe IP diversa da quella dei dati sono costretto a fare una seconda fase 2 della VPN IPsec in modo da instradare correttamente il traffico voce dalla sede periferica al centro stella dove è installato il Cisco Call Manager. La VPN sale e il telefono inizia sia a scaricare il firmware si a scaricare la configurazione, peccato che non è in grado di capire cosa contiene il file di configurazione. Ogni 2 minuti e 25 secondi riscarica il file ma non riesce a collegarsi con successo al Call Manager. Dopo un po’ di indagini, mi viene il sospetto che possa essere un banale problema di MTU. Provando semplicemente a mondificare il parametro MTU della WAN e della LAN non ne esco. Ad un certo punto mi viene in mente di provare a modificare  tcp-mss con il comando:

# sysopt connection tcp-mss 1300

Una volta fatta questa banale modifica e dopo aver scovato la giusta dimensione di 1300 tutto si è risolto come per magia.

La seguente immagine rappresenta la rete realizzata

Cisco ASA, CallManager, VPN e telefono cisco 7941