AirModelClub al Fireparty 2014 Merate

AirModelClub al Fireparty 2014 Merate

AirModelClub al Fireparty 2014 Merate un’occasione imperdibile di divertimento. AirModelClub è stato invitato al FireParty 2014 organizzato da Amis di Pumpier de Meràa presso la stazione dei pompieri dei vigili del fuoco di Merate. Come tutti gli anni questa manifestaizone si svolge a cavallo di due settimane. Quest’anno il gruppo droni dell’AriModelClub è stato invitato per provvedere alle riprese della manifestazione. Domenica 31.08.2014 si è svolta la Parata e la prima giornata densa di appuntamenti. Sabato 6 e Domenica 7 Settembre invece saremo presso il presso tracciato in via Leonardo Da Vinci – Verderio Superiore dove i Pompieri con la collaborazione di 4 Zampe Off-Road provvederà a una nuova attività di istruzione della Protezione Civile al fuoristrada. Anche in questo caso ci sono state richieste le riprese. Non dimenticate e non perdetevi le sucessive attività di Modellismo a cura di Italian Truck Team e i voli in elicottero (presso piazzola in via Fratelli Cernuschi – Merate) Eliwork Non mancate a questo appuntamento, il divertimento continua anche Domenica 7 Settembre!!

Presto i video dell’evento online. Resta in contatto!

Fireparty Merate 2014

Fireparty Merate 2014

LACP NETAPP 2240 e CISCO 3750G

Procedura per la configurazione delle porte in LACP tra due switch Cisco 3750G e un NETAPP FAS2040-2. Questa configurazione di rende necessaria per arrivare ad avere un bilanciamento di traffico sulle 4 porte di rete del NETAPP. Questo tipo di implementazione viene usata normalmente per ottenere oltre alla ridondanza dei link anche la maggior performance possibile. Molto utile quando si utilizza un protocollo come NFS o iSCSI tra lo storage e i server applicativi o di virtualizzazione. Fondamentale è avere due switch in stack tra di loro con l’apposito cavo di stack

port-channel load-balance src-dst-ip
!
spanning-tree mode pvst
spanning-tree extend system-id
!
system mtu routing 1500
system mtu jumbo 9000
!
!
interface Port-channel1
 description LACP multimode VIF for netapp1
 switchport access vlan 64
 switchport mode access
 load-interval 30
!
!
interface GigabitEthernet1/0/3
 description NETAPP C1P1
 switchport access vlan 64
 switchport mode access
 load-interval 30
 channel-protocol lacp
 channel-group 1 mode active
!
interface GigabitEthernet1/0/4
 description NETAPP C1P2
 switchport access vlan 64
 switchport mode access
 load-interval 30
 channel-protocol lacp
 channel-group 1 mode active
!
!
interface GigabitEthernet2/0/3
 description NETAPP C1P3
 switchport access vlan 64
 switchport mode access
 load-interval 30
 channel-protocol lacp
 channel-group 1 mode active
!
interface GigabitEthernet2/0/4
 description NETAPP C1P4
 switchport access vlan 64
 switchport mode access
 load-interval 30
 channel-protocol lacp
 channel-group 1 mode active
!

La configurazione sul netapp è la seguente:























































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