Se ti stai chiedendo cos’è OSPF e a cosa serve allora non andare avanti in questo articolo, vai su google e cerca. Se invece sai dicosa parlo, implementare OSPF su Sonicwall è semplice: occorre usare le VPN in modalità tunnel anzichè “site to site” in modalità numbered. Le versioni si sonicOS che supportano questa modalità sono superiori alla V6.0. Occorre solo ricordarsi di comunicare al motore OSPF di non pubblicare i pool di indirizzi IP sulle interfaccie WAN. Purtroppo questa configurazione si fa soltanto in CLI e non è possibile farla da GUI.
Dopo aver abilitato “advanced routing” andando sulla CLI possiamo configurare OSPF in modo che non pubblichi certe reti. Normalmente si configura OSPF per “ridistribuire le reti direttamente connesse” e altrettanto ovviamente si deve configurare per non distribuire i pool di ip presenti sulle (o sulla) WAN. Si procede in questo modo:
admin@18B169529ADC> configure terminal config(18B169529ADC)# routing (config-routing)# ospf ARS OSPF>configure terminal ARS OSPF(config)>router ospf ARS OSPF(config-router)>summary-address 81.81.81.8/29 not-advertise ARS OSPF(config-router)>exit ARS OSPF(config)>exit ARS OSPF>write file Configuration saved to OSPF ARS OSPF>
Una volta che i tunnel sono attivi, devi aggiungere un’interfaccia in network/interface add “Virtual Tunnel Interface” in modo da poter dare un ip statico /30. In questo modo si crea una rete cosidetta di trasporto, tra il tuo firewall e l’altro partner. Resta da configurare i setting generali di OSPF in modo da dare un nome univoco al questo firewall a livello OSPF come in figura e scegliere quali sono le reti che devono essere redistribuite. Notare che sonicwall configlia di usare l’ip della X0 nel campo ‘OSPF Router’ in modo che sia univoco.
A questo punto occorre configurare configurare su quale interfaccia OSPF dovrà essere attivato, ovvero sulla rete di trasporto /30 che abbiamo creato con la VPN in modalita’ tunnel, come di seguito:
se abbiamo fatto tutto correttamente apparira’ una pallina verde che significa che OSPF è in comunicazione con il partner e la routing table si popolera’ di nuove rotte con peso 110 valore classico di OSPF. Se invece rimane una pallina rossa, la cosa piu’ probabile è che il tunnel non sia attivo. Nella figura si vedono due tunnel con OSPF abilitato.
Attenzione: occorre rimuovere dalla pubblicazione le reti che non interessano, ovviamente ci sono le WAN, che non si capisce come mai, nessun HOWTO le cita, ma sopratutto le reti ‘cosidette’ di trasporto, le varie /30 che si vanno a creare tra i vari Sonicwall, che inoltre generano conflitti negli aggiornamenti di rotte OSPF. Questo problema si evidenzia sempre tra due Sonicwall adiacenti. Entrambi annuncieranno che quella rete è di loro proprieta’.
E’ un ampli che assomiglia alla serie ‘blu’ dei piu’ blasonati SA-7800/SA-8800/SA-9800 ma nulla di piu’. E’ molto differente, sia come costruzione sia come componentistica. Ovviamente è piu’ economico.. oggi si vedono dei prezzi sulla baia per un semplice SA-7800 da rabbrividire.. poi non so se riescono a venderli, pero’ ci provano. Questo ampli è se ben tenuto potrebbe valere attorno ai duecento euro. Qui di seguito trovate il ‘service manual’ che non si trova proprio facilmente. Messo a confronto con il mio SA-8800 ame risulta un po’ chiuso alle alte e piu’ ‘avanti’ in gamma media. Per quanto riguarda la potenza, 45+45 RMS sono comunque sufficienti per un ascolto domestico: non sono un gran fan di questo parametro.. io a casa ascolto con un single-ended valvolare con delle 6L6 che non arriva a 3 watt per canale.
Il problema è la partizione dedicata a mysql quasi piena: come risolvere il problema. Visto che era una VM basta solo aggiungere un disco e spostare il contenuto di /var/lib/mysql e successivamente montare il nuovo device al posto del vecchio device ormai quasi pieno. Non ho la registrazione di quello che ho fatto, vado a memoria:
Ho creato una partizione primaria sul nuovo disco “fdisk /dev/sda” e dopo l’ho formattata con il comando mkfs.xfs /dev/sdb1 – A questo punto ho creato una directory dentro /mnt/disco-da-15-giga e poi lo ho editato in fstab in modo che venga montato all’atto dell’avvio della vm. Ora bisogna spostare il contenuto della /var/lib/mysql su /mnt/disco-da-15-giga – si puo’ fare in diversi modi, io ho scelto di fare un archivio cosi’: tar cvfz dati.tar.gz /var/lib/mysql in seguito ho estratto tutto in /mn/nuovodisco e ho eseguito un chown mysql:mysql * dentro la directory per riportare l’owner corretto dei file.
Ora si tratta di editare /etc/my.cnf.d/mysql-server.cnf in modo da cambiare datadir e socket come vedi:
Ora se fai partire mysqld dovrebbe funzionare normalmente.. solo che ora usa il nuovo disco. Ora bisogna informare Zabbix che il socket non è piu’ il default ma è da un’altra parte: questo si fa editando il file zabbix.conf e precisamente questa riga:
DBSocket=/mnt/disco-da-15-giga/mysql/mysql.sock
Ora contrariamente a quello che si puo’ normalmente pensare bisogna fare l’ultimo passo, perche’ altrimenti il server Zabbix funziona normalmente (lo vedi dai log di zabbix) ma non riesci ad entrare nella GUI via web. Bisogna editare il file /etc/php.ini precisamente questa riga:
La figura rappresenta la trasmissione di un messaggio attraverso la rete. Qui la definizione di messaggio è ampia, puo’ essere un file, un’immagine, una pagina web.
In questa figura vediamo alcuni dispositivi piu’ usati nei diagrammi di rete.
Le interfaccie nelle reti locali.
Le interfaccie di rete normalmente venono chiamate NIC, ci si riferisce alle porte ethernet . Le NIC sono caratterizzate a livello rete da un MAC address (Media Access Control), il quale è un indirizzo (pressoche’) univoco sulla rete LAN. Oggi le NIC hanno connettori solo connettori RJ45. Da notare che il MAC address è valido solo per le reti locali e partecipa alle conversazioni tra dispositivi entro la rete locale. Il MAC è costituito da 6 byte di cui i primi 3 sono codificati in modo da poter risalire al costruttore del NIC.
Come è fatto un indirizzo MAC
Spendiamo qualche parola sul protocollo ethernet. Inizia ad essere commercilizzata nel 1980 e dopo qualche tempo sostituisce altre tecnologie piu’ vecchie come Token Ring e FDDI. In origine il cavo per connettere dispositivi era 10BASE5 che utilizzava un cavo coassiale il quale poi verra’ sostituito con cavo coassiale 10BASE2 e successivamente con il cavo che conosciamo ai nostri tempi a 4 coppie intrecciate. Questo tipo di collegamento viene chiamato 10BASET (approfondimenti: https://it.wikipedia.org/wiki/10Base-Thttps://it.wikipedia.org/wiki/Ethernet
Il protocollo grazie al quale ethernet funziona è CSMA/CD (Carrier Sense Multiple Access with Collision Detection) e funziona nella maniera piu’ sempliche che ci si possa immaginare (parte del successo di ethernet è dovuto a questo – implementazione del software del NIC semplice). La direttiva è la seguente: “Ascolta prima di trasmettere e mentre trasmetti. Se mentre trasmetti rilevi collisioni, fermati, segnala a tutte le altre stazioni la collisione e riprova più tardi secondo modalità di ritrasmissione stabilite” Da cui se ne deduce che, visto che la rete locale è un media broadcast, ovvero, quando un device trasmette tutti lo ricevono (almeno per quanto riguarda l’implementazione originale vedi ‘switch’), che meno device si ‘affacciano’ sulla rete e meglio funziona ethernet, specialmente se i device non hanno ‘molto’ da trasmettere. Infatti piu’ device, piu’ trasmissioni, piu’ messaggi da inviare significano, piu’ collisioni, piu’ attese. Infatti una rete ethernet inizia ad avere qualche problema di efficienza quando i dati che transitano superano il 40% della portata massima. (approfondimenti: https://it.wikipedia.org/wiki/CSMA/CD
Due dispositivi in rete locale che si scambiano dei messaggi comunicano via ethernet inviando delle serie di bit sulla rete. Il protocollo MAC è l’insieme di regole che permette la comunicazione tra loro. Un dispositivo che deve inviare un messaggio costruisce quello che si chiama “frame ethernet” ed è costituito in questo modo
Un frame ethernet tipico ha una grandezza compresa tra 64 e 1518 byte ed è formato da:
8 byte per il campo Preambolo; 6 byte per il mac address di destinazione; 6 byte per il mac address sorgente; 2 byte per l’Ethertype; da 46 a 1500 byte per i dati; 4 byte per il FCS.Approfondimenti: http://wwwusers.di.uniroma1.it/~reti/Reti_Elab_html/Cap4.pdf
Dentro al campo ‘payload’ puo’ incapsulare un pacchetto IP, il quale usa il protocollo MAC per essere trasportato in una rete locale. Questo è il principio di funzionamento ‘reale’ dei livelli OSI di cui abbiamo sentito parlare. Nelle reti costituite da più livelli, come appunto il TCP/IP, in una trasmissione dati i pacchetti dei livelli superiori vengono inseriti o incapsulati nei pacchetti dei livelli inferiori: tale operazione è definita “imbustamento”. In ricezione si ha situazione o processo inverso: a partire dai livelli più bassi ogni protocollo analizza il proprio header e passa al protocollo di livello superiore quello che per lui è carico utile cioè il pacchetto restante che quindi perde via via informazioni aggiuntive di protocollo salendo di strato fino a rimanere nei soli dati utili a livello applicativo. Approfondimento: https://it.wikipedia.org/wiki/Pacchetto_(reti)
Il protocollo IP
Il protocollo ip è costituito da 4 byte e il formalismo con cui è universalmente conosciuto è dotted quad
L’indirizzo IPv4 è costituito da 32 bit (4 byte) suddiviso in 4 gruppi da 8 bit (1 byte), separati ciascuno da un punto (notazione dotted) (es. 11001001.00100100.10101111.00001111). Ciascuno di questi 4 byte è poi convertito in formato decimale di più facile identificazione (quindi ogni numero varia tra 0 e 255 essendo 28=256). Un esempio di indirizzo IPv4 è 172.16.254.1.
Le classi degli indirizzi IP
Le classi degli indirizzi IP sono 5 ma le piu’ comuni sono 3 e sono determinale dai primi due bit dell’ottetto piu’ a sinistra.
Classe A Il primo byte rappresenta la rete; gli altri tre gli host per ogni rete. In notazione decimale gli IP variano nel modo seguente: 0-127.H.H.H; La maschera di rete è 255.0.0.0 (o anche detta /8 in quanto i bit di rete sono 8); Questi indirizzi in binario iniziano con il bit 0. Classe B I primi due byte rappresentano la rete; gli altri due gli host per ogni rete. In notazione decimale gli IP variano nel modo seguente: 128-191.N.H.H; N varia da 0 a 255. La maschera di rete è 255.255.0.0 (o anche detta /16 in quanto i bit di rete sono 16); Questi indirizzi in binario iniziano con i bit 10. Classe C I primi tre byte rappresentano la rete; l’ultimo gli host per ogni rete. In notazione decimale gli IP variano nel modo seguente: 192-223.N.N.H; La maschera di rete è 255.255.255.0 (o anche detta /24 in quanto i bit di rete sono 24); Questi indirizzi in binario iniziano con i bit 110.
Servizi di rete
DHCP
Questo servizio ha lo scopo di assegnare un indirizzo IP ad un host che ha il NIC impostato per avere indirizzo IP dinamico. Oltre a questo fornisce il default gateway e il servizio di risoluzione dei nomi (DNS). Questo servizio è il piu’ importante in una rete di dispositivi configurati con ip dinamico: un problema su questo servizio e nessun computer potra’ comunicare con gli altri dispositivi. Approfondimento: https://it.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
DNS
E’ il servizio che risolve un nome di un host con un indirizzo ip. Per esempio www.tech2.it deve prima essere risolto in un ip per riuscire ad avere la web page sul nostr browser: questo servizio effettua questa conversione. Approfondimento: https://it.wikipedia.org/wiki/Domain_Name_System
Default gateway
E’ l’indirizzo ip del dispositivo che ci permette di ‘uscire’ dalla nostra rete locale, solitamente è l’ip corrispondente ad un router o ad un firewall. Senza questo dispositivo non possiamo navigare in Internet e siamo costretti a comunicare solo nella rete locale. Approfondimenti:https://it.wikipedia.org/wiki/Gateway_predefinito
Purtroppo ‘di serie’ non esiste un decoder per il log di HAProxy, quindi, a parte fare in modo che HAProxy scriva un log via rsyslog e puntarlo con il file di configurazione ossec.conf bisogna scrivere un decoder, cosa molto facile dopo averlo scritto:
<rule id=”100012″ level=”8″ frequency=”4″ timeframe=”30″> <if_matched_sid>100011</if_matched_sid> <same_source_ip /> <description>CMS (WordPress or Joomla) brute force attempt.</description> <group>pci_dss_6.5,pci_dss_11.4,pci_dss_6.5.10,pci_dss_10.2.4,pci_dss_10.2.5,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SA.11,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,</group> </rule>
Questo decoder e regola fa si che se in 30 secondi rileva piu’ di 4 ‘wp-login’ banna l’ip semplicemente triggerando una regola di livello 8: nel mio sistema una regola triggera un “Active Response” se il livello è uguale o maggiore di 6.
Prima o poi ci si scontra con qualcuno che vuole che la comunicazione tra un server Zabbix e un agent Zabbix avvenga in modalita’ sicura. Ho fatto questo howto principalmente per me, che ho la memoria corta, come si suol dire. In effetti non ci vuole molto, basta semplicemente preparare un file con dentro una “pre-shared key” generata con:
e inserire il file in /etc/zabbix/zabbix.psk o dove vuoi tu.. basta che poi lo dichiari in c:\etc\zabbix\zabbix_agent.conf inserendo anche in fondo al file le seguenti righe:
Poi fai partire l’agent e controlli il file /var/log/zabbix/zabbix_proxy.log che non ci siano errori: attento che è sempre meglio che il l’hostname che hai definito nel server sia uguale all’hostname che trovi ‘remmato’ dentro alla configurazione dell’agent. Di seguito vedi come si configura sul server un host da controllare con connessione psk:
Ossec è un software HIDS freeware che ci permette di proteggere i nostri server dagli attacchi. Personalmente lo uso da molto tempo. Ho sostituito fail-to-ban con ossec, perchè mi pare che funzioni meglio. Inoltre ha una funzione server, che viene bene in situazioni particolari come… la nostra.
Ossec si può installare in diverse modalità: stand alone, server oppure agent. Il server raccoglie tutti i log degli agent e comanda agli agent cosa fare in caso di attacco. In parole povere, a me serviva che, se un agent rileva un attacco, il server invia a tutti gli agent di bloccare quel determinato IP in modo da mitigare l’attacco. Nel nostro caso vista la complessità della rete, i nostri web server sono colpiti da reverse proxy basati si HAProxy e non hanno la possibilità di divendersi in quanto il proxy rigenera la sorgente quindi il server web ‘vede’ come sorgente l’ip di HAProxy. Da qui l’idea di installare un agent su HAProxy e sui web server in modo che, nel momento che un agent su un web server rileva un attacco venga informato il server che inoltra il comando di chiusura a tutti gli agent e quindi anche all’agent di HAProxy, di fatto chiudendo la comunicazione con l’IP attaccante. Tutto questo è semplicemente eseguito da una regola sul server dentro al blocco active-response:
<location>all</location>
Con questa istruzione ossec server invia a tutti gli agent il comando di blocco.
La GUI
Ho trovato un documento che descrive come installare Splunk con una applicazione ossec in modo da avere una gui degna di questo nome: la gui di ossec server non ha molta utilità a parer mio. Inoltre si può utilizzare Splunk in quanto (almeno nel mio caso) i log sono sotto alla soglia oltre la quale occorre acquistare una licenza per Splunk. Il documento che spiega molto bene un’installazione ossec ‘quick and dirty’ lo trovate a questo indirizzo: (Grazie a Nicolas Zin)
