texilee:/# /etc/init.d/mysql stop
Stopping MySQL database server: mysqld.

texilee:/# mysqld_safe –skip-grant-tables &
[1] 29756
texilee:/## Starting mysqld daemon with databases from /var/lib/mysql
mysqld_safe[29793]: started

texilee:/# mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.0.32-Debian_7etch5-log Debian etch distribution

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> update user set password=PASSWORD(‘__NEW__PASSWORD__’) where User=’root’;
Query OK, 2 rows affected (0.02 sec)
Rows matched: 2 Changed: 2 Warnings: 0

mysql>
mysql>
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> \q
Bye

texilee:/# kill 29756 && /etc/init.d/mysql start


echo "show processlist;" | \
mysql -s -u root --password="xxxxxxxxxx"| \
awk -v tot=0 ' {print $4; $tot=tot+1; \
print "in TOTALE"}'| \
grep -v NULL| sort | uniq -c | sort -n | less


restituisce una tabella (mal formattata ma rende l’idea) di due colonne contenenti il numero totale di connessioni in piedi per db ed il nome del db stesso, in fondo restituisce il numero totale delle connessioni stabilite.

Per settare il numero massimo consentito (dopo si presenta il classico too many connection ) si setta la variabile

max-connections

Può tornare utile come strumento di monitoraggio al volo.

La connessione una volta stabilita rimane in attesa di poter essere riutilizzata ( da un processo figlio di apache per esempio )

Se si vuole modificare questo paramentro settate il timeout in secondi che desiderate

interactive_timeout 28800

Se riscontrate errori sul numero di connessioni massime e notate query in stato locked potete AL LIMITE della disperazione affidarvi al comando

kill ID

L’ID lo recuerate da “show processlist”

echo "SHOW STATUS LIKE 'qcache_%'" |  \

mysql -H -u root --password=lamiapwd > \

/var/www/query_cache.html

Il tool è scritto in php e si avvicina al celeberrimo phpmyadmin

L’interfaccia è graficamente molto curata e piacevole, purtroppo le funzionalità sono molto ridotte rispetto al MyAdmin.

Elenco delle funzionalità:

• Simple upload-and-use design ( No need for setup on most servers! )
• Config file or session based login
• Multiple server support
• View multiple databases
• View table status
• CREATE, DROP, EMPTY, and OPTIMIZE multiple tables
• VIEW, EDIT, and DELETE multiple fields
• Supports all standard MySQL fields
• Run batch queries
• Load and edit MySQL query files
• Export databases to textarea, file
• Error handeling

Requisiti

• PHP v4.3.1 +
• MySQL v4.0.27-standard +

Adatto agli sviluppatori che non necessitano il pieno controllo di MySql, o per i fornitori di hosting che desiderano offrire ai clienti la possibilità di interagire con il database. Considerando la giovane età del prodotto aspettiamo le prossime release per iniziare a fare paragoni sulle performance.

L’aspetto più rilevante nella configurazione di un web server è senza dubbio la completa collaborazione fra sviluppatori di codice e sistemisti (gli sviluppatori grafici non hanno voce in questione )

Inutile preparare una macchina dalla configurazione hardware ottimale con RAID 5 o 10 su 4 dischi SCSI e un firewall di 3000 righe per scoprire di lunedì mattina che il DB è vuoto. Motivo? Account di amministratore settato con USER: “Admin” e Password indovinate un po’… … “Admin” ovvio!

Sprecare quel paio d’ore in più a chiacchierare con lo sviluppatore non è male, ma cosa buona e giusta! Prendetevi tutto il tempo per rendere stabili e congruenti le modifiche e non abbiate nè fretta nè timore di far osservare qualche policy di sicurezza in più al vostro collega cresciuto su manuali che danno per scontato il non effettuare input sanitazing.

Per la preparazione del kernel (personalmente pendo dalla parte degli amanti di conf monolitiche con le giuste patch applicate vedi grsecurity) penso di scrivere qualcosina più avanti.

Security is a process, not a result (sia chiaro in partenza…)

Security a livello di sistema

Questo è il compito del sistemista … effettivamente c’è bisogno di parecchio tempo per raffinare la tecnica e centralizzare le politiche in un layer di controllo non troppo invasivo.

Prima di iniziare a stilare qualche linea di codice e iniziare a riconfigurare mezza /etc è un consiglio confrontarsi con lo sviluppatore. Bisogna tener conto delle effettive esigenze del developer: upload (accesso ftp per lo spostamento di file) , directory con permessi di scrittura lato utenza apache (chmod www-data dir ), parametri dimensionali (massimo tempo di esecuzione script), necessità di reloadare servizi (accesso ssh), accettare traffico da e verso determinati ip e porte.

Il bello della configurazione di un server è che ogni volta che ne andrete a creare uno nuovo vi verrà sempre più naturale orientarlo verso sicurezza e performance, ovviamente se avete voglia di imparare e tenervi aggiornati!

Stilata la lista delle necessità dello sviluppatore iniziamo a modificare le configurazioni più “critiche”.

Dividiamo in due rami il nostro compito: network security e file system security, iniziamo a leggere le specifiche e trarre le conclusioni. Il server web ospiterà un cms php/mysql, dovrà essere permesso l’invio di mail, il webmaster dovrà modificare i file della htdocs, e restartare o stoppare apache e mysql. Installiamo una LAMP e phpmyadmin per l’amministrazione del DB, qmail per l’invio delle mail, il demone ssh per permettere “ftp” over SSH (quindi niente proftpd o simili) e la gestione dei demoni (via sudo darete la possibilità all’utente webmaster di compiere quelle determinate operazioni…)

Network security

#netstat -l -n -p -t -u -w
Active Internet connections (only servers)
Proto  Local Address         PID/Program name
tcp    127.0.0.1:3306        31920/mysqld
tcp    192.168.168.168:80    15695/apache
tcp    192.168.168.168:22    26850/sshd
tcp    127.0.0.1:25          15809/tcpserver

L’elenco delle porte in ascolto sul server, comprende i vari protocolli ma esclude i socket unix (canali di comunicazione fra ad esempio apache e mysql) e qualche colonna poco utile a fini didattici.

#nmap -sS 192.168.168.168

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap finished: 1 IP address (1 host up) scanned in 0.578 seconds

Perfetto (siamo ancora sprovvisti di firewall) vengono riconosciute da nmap le porte dei servizi che saranno contattabili dal segmento pubblico e nn solo da localhost: apache sulla 80 e ssh sulla 22

Come fare a disabilitare i servizi di default? Semplicemente commentate le entry relative nei file di configurazione sotto /etc e sotto /etc/init.d per i file di configurazione come quello di qmail. E’ inutile lasciare servizi che non dovranno essere raggiungibili dal mondo esterno in ascolto. Meglio bindarli su localhost. Su Debian date uno sguardo /etc/inetd.conf /etc/init.d/* e /etc/default

IPTABLES

Per completare la nostra configurazione di rete non rimane che scrivere un piccolo firewall da mettere sulla macchina, che rimarrà cmq. in dmz dietro a un altro firewall un po’ più corposo. La politica che preferisco è quella del DROP, check del set di regole e in caso di pacchetto non contemplato loggo e droppo. Loggo cmq. tutti i tentativi di accesso verso ssh, molti cambiano porta per l’accesso ssh ( sempre molta fantasia.. 220,2200,222,2222), tuttavia non sento questa necessità perchè permetto l’accesso solo da determinati IP o classi se dinamici.

#policy in drop
/sbin/iptables -t filter -P INPUT DROP

#loggo tentativi ssh
/sbin/iptables -t filter -A INPUT -p tcp -m state –state NEW –dport 22 -j LOG –log-prefix ***SSH*** –log-level ERR

#permetto in input connessioni già “fidate”
/sbin/iptables -t filter -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

#permetto http da tutti
/sbin/iptables -t filter -A INPUT -p tcp –dport 80 -j ACCEPT

#permetto ssh da client fidati
/sbin/iptables -t filter -A INPUT -s 192.168.168.169 -p tcp –dport 22 -j ACCEPT
/sbin/iptables -t filter -A INPUT -s 45.98.45.98 -p tcp –dport 22 -j ACCEPT

#loggo input con dest non ok
/sbin/iptables -t filter -A INPUT -j LOG –log-level ERR –log-prefix “input: ”

#e droppo
/sbin/iptables -t filter -A INPUT -j DROP

Il firewall da mettere direttamente sul server è abbastanza completo, megli lavorare più massicciamente sul firewall con eth con ip esterno, anche per effettuare analisi sulla rete senza dover disattivarlo ogni volta.
Per salvare le nostre regole

#iptables-save > /root/fw
#chmod 600 /root/fw

ed eventuale restore

iptables-restore < /root/fw

oppure crearsi uno script bash iniziando con

#!/bin/sh

Per quanto riguarda SSH modificate le seguenti entries nelfile /etc/ssh/sshd_config

Port 22
ListenAddress 192.168.168.168
Protocol 2
PermitRootLogin no
AllowUsers texilee webmaster

e reload

/etc/init.d/ssh restart

File System
E' cosa buona non creare una sola partizione / ma suddividere in base alle esigenze il FS in diverse partizioni e montarle in maniera diversa. Le più critiche sono la /tmp e la /var, se nella prima è di moda parcheggiarci rootkit nella seconda il problema può essere causa di DOS per log "impazziti" che nel giro di poco tempo riempiono il filesystem. Appurato che non lanceremo nulla dalla /tmp poichè i nostri script e binari risiedono da tutt'altra parte possiamo impedire a livello di filesystem l'esecuzione di codice dall'interno di tmp modificando il file /etc/fstab in questa maniera

/dev/hda2 /tmp ext3 nodev,nosuid, noexec 0 0

Può capitare (tipico esempio uno dei centinaia bachi di tipo "esecuzione di codice arbitrario" di prodotti php open source) che un attaccante ti sfondi la macchina e parcheggi nella /tmp il suo simpatico rootkit, ti hanno appena modificato ls e netstat e non te ne puoi accorgere se non facendo delle analisi da un'altra macchina messa in eth promiscous mode... tornano utili un paio di tools: samhain chkrootkit

Samhain crea un database con "firme" di file di sistema presenti al momento della esecuzione del tool, record contenenti valori quali data dimensione inode. Il demone controlla periodicamente l'integrità dei file sul FS con le informazioni contenute nel suo DB ed in caso di incongruenza si occupa di mandare una mail all'indirizzo specificato nel file di configurazione. Su Debian apt-get install samhain chkrootkit , i file di configurazione come al solito sotto /etc.

Per concludere trovo estremamente interessante costruire qualche script bash per tracciare quelle situazioni di gravità (disco pieno, troppe connessioni dallo stesso ip, carico di lavoro troppo elevato... argomento di prossimi post ) e l'utilizzo di atsar (apt-get install atsar) per avere uno storico del carico di lavoro e poter rintracciare con facilità nei log i motivi di "sbalzi" particolarmente elevati di carico.

Mysql implementa un meccanismo per cashare i risultati delle query al fine di poterli riutilizzare senza interrogare di nuovo il DB. Questo meccanismo e’ estremamente utile quando una appz utilizza massivamente le stesse query. Non esiste un configuerazione ottimale in generale, vi invito ad utilizzare quella di default e iniziare tuning più avanti.

Parametri di configurazione:

Il file di configurazione my.cnf contiene le direttive per settare tutte le opzioni che interagiscono col meccanismo di cache.

Prestare attenzione a query_cache_size e query_cache_type.

have_query_cache
MAN: Indica al server di supportare il meccanismo di caching delle query
TYPE: boolean (YES o NO)
VERSION: a partire dalla 4.0.2

query_cache_limit

MAN: dimensione massima del risultato della query ( detto record set o result set) per essere ammessa in cache
TYPE: intero espresso in MB
VERSION: a partire dalla 4.0.1

La query cache e’ stata introdotta per poter “cachare” il numero maggiore possibile di query, non il record set delle query piu’ corpose. Dovrebbe essere settato ad un valore relativamente basso

query_cache_min_res_unit

MAN: dimensione minima del record set per essere ammesso in cache
TYPE: espresso in KB
VERSION: a partire dalla 4.0.1
query_cache_size

MAN: memoria dedicata alla query cache
TYPE: intero espresso in MB
VERSION: a partire dalla 4.0.1

Se il valore impostato e’ 0 il caching e’ disabilitato. Se il valore e’ > 0 ma la direttiva query_cache_type e’ 0 oppure OFF, la memoria dedicata al caching viene utilizzata ma non viene effettivamente letta dal mysql

query_cache_type

MAN: specifica lo stato della query cache
TYPE: intero (0,1,2)
VERSION: a partire dalla 4.0.3

0-> Non viene messo in cache nulla, ma la memoria viene lo stesso dedicata

1-> Se e’ impostato a 1 i risultati della query con dimensione minore di query_cache_limit vengono cachati, a meno che la query non contenga la direttiva SQL_NO_CACHE

2-> Se e’ impostato a 2 i risultati della query con dimensione minore di query_cache_limit vengono cachati, a meno che la query contenga la direttiva SQL_CACHE

query_cache_wlock_invalidate

MAN:Se le tabelle interrogate stanno subendo operazioni e sono in stato di “lock” settando questo parametro a 1 i risultati in cache vengono eliminati e non si ha il rischio di ottenere risultati non piu’ validi. Questo è un parametro specifico per DB MyISAM
TYPE: boolean(0,1)
VERSION: a partire dalla 4.0.19

Come abilitare la Query Cache?

Per abilitare la cache query basta settare :

query_cache_type a 1 oppure 2
query_cache_size > 0

E’ importante settare correttamente entrambi i parametri, altrimenti si rischia di dedicare memoria che non verra’ utilizzata.

Mysql necessita di un minimo di 40Kb di memoria per poter avviare il meccanismo di cache. Se non ce’ abbastanza memoria nel file di log viene inserito un warning

Tuning Query Cache

Qualche query da utilizzare

FLUSH QUERY CACHE > deframmenta la struttura della memoria, non elimina nessuna query nella cache

RESET QUERY CACHE > svuota la cache

SHOW STATUS LIKE ‘qcache_%’ > per vedere le statistiche

Qcache_lowmem_prunes -> contiene il numero di query e results sets rimossi dalla cache per far posto a nuovi dati.
Per verificare in generale l’efficienza della cache query si dovrebbe far riferimento a quel valore, se cresce costantemente nel tempo la cache memory non sta fornendo un servizio utile ai fini della velocita’ e dovrebbe essere disabilitata, o i parametri diversamente settati in base al peso delle query più comuni, alla potenza della macchina..
Se i valori di Qcache_hits e Qcache_lowmem_prunes crescono rapidamente, bisognerebbe aumentare la query_cache_size

Qcache_not_cached indica il numeri di query eseguite ma non messe in cache

In generale e’ dovuto al valore superato di query_cache_limit.

Aumentare la query_cache_limit puo’ essere utile, bisogna pero’ considerare il rapporto fra Qcache_hits e Qcache_lowmem_prunes, se scende e’ opportuno farlo.

Controllate quotidianamente i valori “statistici” e fate numerose prove prima di definire delle linee guida per la configurazione dei parametri di tuning.

Autore Boyd Hemphill , libera traduzione di Tenivella Enrico.

Mysql implementa un meccanismo per cashare i risultati delle query al fine di poterli riutilizzare senza interrogare di nuovo il DB. Questo meccanismo e’ estremamente utile quando una appz utilizza massivamente le stesse query.

Parametri di configurazione:

Il file di configurazione my.cnf contiene le direttive per settare tutte le opzioni che interagiscono col meccanismo di cache.

Prestare attenzione a query_cache_size e query_cache_type.

have_query_cache

* Indicates that the server supports the query cache
* Specified as Boolean (YES or NO)
* Available as of 4.0.2

query_cache_limit

* Maximum size of a cacheable result set
* Specified in megabytes
* Available as of 4.0.1

La query cache e’ stata introdotta per poter cachare il numero di query maggiore possibile, non il risultato delle query piu’ corpose. Dovrebbe essere settato ad un valore relativamente basso

query_cache_min_res_unit

* Minimum block size of the query cache
* Specifed in kilobytes
* Available as of 4.1

query_cache_size

* Memory allocated to the query cache
* Specified in megabytes
* Available as of 4.0.1

Se il valore impostato e’ 0 il caching e’ disabilitato. Se il valore e’ > 0 ma la direttiva query_cache_type e’ 0 oppure OFF, la memoria dedicata al caching viene utilizzata ma non viene effettivamente letta dal mysql

query_cache_type

* Sets the query cache state
* Specified as an integer (0,1,2)
* Available as of 4.0.3

Se e’ impostato a 0 non viene messo nell cache nulla, ma la memoria dedicata viene lo stesso sporcata(wasted)

Se e’ impostato a 1 i risultati della query con dimensione minore di query_cache_limit vengono cachati, a meno che la query non contenga la direttiva SQL_NO_CACHE

Se e’ impostato a 2 i risultati della query con dimensione minore di query_cache_limit vengono cachati, a meno che la query contenga la direttiva SQL_CACHE

query_cache_wlock_invalidate

* Controls locking aspects of tables with rows in the cache
* Specified as integer value of 1
* Available as of 4.0.19
* Specific to MyISAM

Se le tabelle interrogate stanno subendo operazioni e sono in stato di “lock” settando questo parametro a 1 i risultati in cache vengono eliminati e non si ha il rischio di ottenere risultati non piu’ validi.

Abilitare la Query Cache

Per abilitare la cache query basta settare :

query_cache_type a 1 oppure 2
query_cache_size > 0

E’ importante settare correttamente entrambi i parametri, altrimenti si rischia di allocare memoria che non verra’ utilizzata.

Mysql necessita di un minimo di 40Kb di memoria per poter avviare il meccanismo di cache. Se non ce’ abbastanza memoria nel file di log viene inserito un warning

Tuning Query Cache

* FLUSH QUERY CACHE > deframmenta la struttura della memoria, non elimina nessuna query nella cache

* RESET QUERY CACHE > svuota la cache

* SHOW STATUS LIKE ‘qcache_%’ per vedere le statistiche

Qcache_lowmem_prunes -> contiene il numero di query e results sets rimossi dalla cache per far posto a nuovi dati.
Per verificare in generale l’efficienza della cache query si dovrebbe far riferimento a quel valore, se cresce costantemente nel tempo la cache memory non sta fornendo un servizio utile ai fini della velocita’ e dovrebbe essere disabilitata.

Se i valori di Qcache_hits e Qcache_lowmem_prunes crescono rapidamente, bisognerebbe aumentare la query_cache_size

Qcache_not_cached indica il numeri di query eseguite ma non messe in cache

In generale e’ dovuto al valore superato di query_cache_limit.

Aumentare la query_cache_limit puo’ essere utile, bisogna pero’ considerare il rapporto fra Qcache_hits e Qcache_lowmem_prunes, se scende e’ opportuno farlo.