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)
Abbiamo deciso di provare una soluzione a basso costo che possa soddisfare i clienti che non hanno grosse pretese. Normalmente lavoravamo con Sonicwall, ma per due ragioni non riusciamo più a proporli ai nostri clienti. I motivi essenzialmente sono due: esiste una notevole mole di clienti che hanno la serie vecchia dei firewall tipo NSA3500 o NSA2400, questi firewall non sono compatibili con il nuovo sistema operativo V6.X e di conseguenza non sono compatibili con i nuovi access point Sonicwall Wave2 che sembrano essere veramente notevoli. Oltre a ciò oltre che avere prestazioni notevoli questi access point hanno anche il costo veramente notevole, che scoraggia chiunque. Quindi abbiamo pensato che trovare un’alternativa low-costs poteva essere fruibile.
TP-Link AC500
Abbiamo notato che TP-Link ha alcune soluzioni interessanti a basso costo. Siamo rimasti sorpresi quando abbiamo notato i prezzi dei controller della linea AURANET che con meno di 60 euro ci si porta a casa un controller che può gestire sino a 50 access point e con meno di 200 euro si acquista AC500 che di access point ne gestisce 500. Abbiamo optato per il modello superiore in quanto ha le interfaccie a gigabit.
Per quanto riguarda gli access point abbiamo tre possibili modelli compatibili con questi controller: CAP300, CAP1200, CAP1750
Noi abbiamo scelto il modello medio in quanto ha due radio e non ha un costo eccessivo, si dovrebbe trovare a meno di 150 euro.
Il Test
Per ora abbiamo effettuato un solo test in lab, dopo qualche minuto di configurazione veramente banale si possono vedere tutti gli access point rilevati dall’interfaccia web del controller. La nostra rete di test prevedeva un rete untagged per l’indirizzamento degli AP e due reti tagged per due SSID. Molto banale e normale: praticamente tutti i clienti vogliono almeno 2 SSID: un guest e un corporate. Per questo specifico caso, le richieste erano che la rete corporate sia autenticata a livello mac address dei client, mentre la guest fosse autenticata con un captive portal e utenti direttamente impostati sul controller con scadenza in 10 ore.
Risultato
l’SSID della rete corporate, quello autenticato con mac address ha funzionato immediatamente, mentre per la rete guest, ho dovuto aprire un ticket con TP-Link. Sottolineo che il supporto è in italiano e che il personale è gentile e preparato. Purtroppo non sono riusciti a risolvere il problema del captive portal. Nel momento che il client riceve l’url di reindrizzamento al captive portal questo punta l’indirizzo IP del controller sulla network di base, ovvero quella untagged e pare proprio che il server web (nginx) non ‘voglia’ rispondere ad una richiesta in una rete diversa da quella ‘untagged’ (il client è su una rete tagged ovviamente). Il problema si può risolvere velocemente impostando che l’SSID guest sia sulla rete untagged. Purtroppo, secondo me, non è corretto avere gli access point e i client direttamente sulla stessa rete IP. Questo problema il supporto non è riuscito a risolverlo e dunque ho dovuto effettuare una NAT sul defaut gateway in modo da far pervenire la richiesta come se fosse originata dal default gateway. In questo modo funziona perfettamente. Direi che la soluzione comunque è da considerare validissima, anche in relazione del suo basso costo.
