Hardening di un web server Apache: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Hardening di un web server Apache (visualizza wikitesto)

Versione delle 16:07, 8 feb 2018

12 505 byte aggiunti ,  8 feb 2018
→‎Disabilitare l'accesso pubblico a server-info e server-status
 
(35 versioni intermedie di 5 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|Squeeze|Wheezy|Jessie|Stretch}}
== Introduzione ==
== Introduzione ==
Apache come ogni software usato in rete, è soggetto a bug che lo possono rendere vulnerabile ad attacchi di diversa natura: Denial of Service, Information Disclosure, System Violation, Data Corruption...<br/>
Apache come ogni software usato in rete, è soggetto a bug che lo possono rendere vulnerabile ad attacchi di diversa natura: Denial of Service, Information Disclosure, System Violation, Data Corruption...<br/>
Riga 7: Riga 9:
== Direttive di Apache ==
== Direttive di Apache ==
Debian prevede un file specifico per la configurazione e la gestione della sicurezza di Apache: <code>/etc/apache2/conf.d/security</code>.<br/>
Debian prevede un file specifico per la configurazione e la gestione della sicurezza di Apache: <code>/etc/apache2/conf.d/security</code>.<br/>
'''Attenzione'''. Da Debian Stretch il file si trova nel percorso: <code>/etc/apache2/conf.available/security.conf</code>.<br/>
Si consiglia quindi di apportare in questo file tutte le modifiche seguenti che desiderate implementare nella vostra configurazione.
Si consiglia quindi di apportare in questo file tutte le modifiche seguenti che desiderate implementare nella vostra configurazione.
=== Impedire il controllo degli accessi per directory ===
=== Impedire il controllo degli accessi per directory ===
Riga 15: Riga 19:
</Directory>
</Directory>
</pre>
</pre>
E' poi possibile "aprire" per directory e funzionalità selezionate, la possibilità di fare l'override della conf generale tramite i file ''.htaccess'' locali.
È poi possibile "aprire" per directory e funzionalità selezionate, la possibilità di fare l'override della conf generale tramite i file ''.htaccess'' locali.
Le diverse opzioni di <code>AllowOverride</code> controllano quali direttive possono essere definite nei file ''.htaccess'': <code>All, AuthConfig, FileInfo, Indexes, Limit, Options, None</code>.
Le diverse opzioni di <code>AllowOverride</code> controllano quali direttive possono essere definite nei file ''.htaccess'': <code>All, AuthConfig, FileInfo, Indexes, Limit, Options, None</code>.
=== Usare .htaccess per limitare l'accesso a directory e file ===
In alcune circostanze può essere necessario limitare l'accesso ad una o più sottodirectory del nostro sito.<br/>
Per gestire tali limitazioni di accesso possiamo intervenire sulle singole directory mediante il file <code>.htaccess</code> (il quale avrà valore unicamente dentro la directory in cui è contenuto).
<br/>
Un semplice esempio di file <code>.htaccess</code> è:
<pre>
<limit GET POST>
order deny, allow
deny from all
allow from .dominio1.com
allow from .dominio2.com
allow from 123.123.123.123
<limit>
</pre>
Lo scopo del codice qui sopra è limitare l'accesso a tutte le chiamate GET e POST (deny from all), tranne quelle dei domini (dominio1.com, dominio2.com) e dell'IP (123.123.123.123) esplicitamente indicati:
* abbiamo impostato la direttiva limit per tutte le chiamate GET e POST;
* abbiamo definito l'ordine (order deny, allow) di inserimento delle nostre istruzioni: prima deny e poi allow
* abbiamo negato l'accesso a tutti (deny from all) tranne...
* ... agli hostname e gli IP indicati con allow from ...;
Ovviamente avremmo potuto fare anche la cosa opposta, ovvero consentire l'accesso a tutti tranne a singoli domini, IP o classi di IP.
Volendo è possibile agire, oltre che su intere cartelle, anche su singoli file o gruppi di file (ad esempio tutti i file con una data estensione). Ad esempio:
<pre>
<FilesMatch \.(inc|conf)>
order allow, deny
deny from all
</FilesMatch>
</pre>
impedisce a chiunque (deny from all) l'accesso a file che finiscono con .inc o .conf (estensioni tipiche dei file di configurazione).


=== Impedire la lettura via Web a file ''.htaccess'' ===
=== Impedire la lettura via Web a file ''.htaccess'' ===
Riga 22: Riga 56:
<pre>
<pre>
<Files ~ "^\.ht">
<Files ~ "^\.ht">
     Order allow,deny
  # Fino a Jessie
     Deny from all
     #Order Allow,Deny
     Satisfy All
     #Deny from all
 
    # Da Stretch
     Require all denied
</Files>
</Files>
</pre>
</pre>
Riga 33: Riga 70:
<pre>
<pre>
<FilesMatch \.(inc|conf)>
<FilesMatch \.(inc|conf)>
     Order Allow,Deny
     # Fino a Jessie
     Deny from all
    #Order Allow,Deny
     #Deny from all
 
    # Da Stretch
    Require all denied
</FilesMatch>
</FilesMatch>
</pre>
</pre>
Riga 45: Riga 86:
#AddHandler server-parsed .shtml
#AddHandler server-parsed .shtml
</pre>
</pre>
per cui se si vogliono usare dei Server Side Includes o degli script CGI al di fuori della directory predefinita con la direttiva <code>ScriptAlias /cgi-bin/ "@@ServerRoot@@/cgi-bin/"</code>, queste righe vanno scommentate.
per cui se si vogliono usare dei Server Side Includes o degli script CGI al di fuori della directory predefinita con la direttiva <code>ScriptAlias /cgi-bin/ "@@ServerRoot@@/cgi-bin/"</code>, queste righe vanno decommentate.


=== Disabilitare l'accesso pubblico a server-info e server-status ===
=== Disabilitare l'accesso pubblico a server-info e server-status ===
Riga 51: Riga 92:
<pre>
<pre>
#<Location /server-status>
#<Location /server-status>
#   SetHandler server-status
  # SetHandler server-status
#    Order deny,allow
  # Fino a Jessie
#   Deny from all
   #Order Allow,Deny
#   Allow from .your-domain.com
  #Deny from all
  #Allow from .your-domain.com
 
    # Da Stretch
    Require all denied
    Require local
    Require ip 192.168.1.0/24
#</Location>
#</Location>


#<Location /server-info>
#<Location /server-info>
#    SetHandler server-info
#    SetHandler server-info
#    Order deny,allow
  # SetHandler server-status
#   Deny from all
  # Fino a Jessie
#   Allow from .your-domain.com
   #Order Allow,Deny
  #Deny from all
  #Allow from .your-domain.com
 
    # Da Stretch
    Require all denied
    Require local
    Require ip 192.168.1.0/24
#</Location>
#</Location>
</pre>
</pre>
Se si vogliono visualizzare server-status e server-info, scommentare queste righe e specificare i domini o gli IP da cui è permesso visualizzarli.
Se si vogliono visualizzare server-status e server-info, decommentare queste righe e specificare i domini o gli IP da cui è permesso visualizzarli.


===Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti) ===
===Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti) ===
Riga 74: Riga 128:
</Location>
</Location>
</pre>
</pre>
Per disabilitare il directory listing si può anche direttamente rimuovere il caricamento (o la compilazione) del modulo ''mod_autoindex''; se invece si vuole abilitarlo, ma al contempo escludere dal listing dei file potenzialmente sensibili si può usare una direttiva come:
Per disabilitare il directory listing si può anche direttamente rimuovere il caricamento (o la compilazione) del modulo ''mod_autoindex''; se invece si vuole abilitarlo, ma al contempo escludere dal listing dei file potenzialmente sensibili, si può usare una direttiva come:
<pre>
<pre>
IndexIgnore .??* *.bak *.swp *# HEADER* README* RCS
IndexIgnore .??* *.bak *.swp *# HEADER* README* RCS
Riga 166: Riga 220:
# aptitude install libapache2-mod-evasive
# aptitude install libapache2-mod-evasive
</pre>
</pre>
Durante l'installazione del modulo il servizio Apache sarà riavviato e il modulo automaticamente caricato al successivo riavvio. E' possibile verificare il corretto caricamento del modulo con:
Durante l'installazione del modulo il servizio Apache sarà riavviato e il modulo automaticamente caricato al successivo riavvio. È possibile verificare il corretto caricamento del modulo con:
<pre>
<pre>
# find /etc/apache2/ | xargs fgrep -nH evasive
# find /etc/apache2/ | xargs fgrep -nH evasive
</pre>
</pre>
Su alcuni siti viene suggerito di aumentare la sicurezza del modulo aggiungendo alcuni parametri di configurazione al file <code>/etc/apache2/mods-available/mod-evasive.load</code>:
Su alcuni siti viene suggerito di aumentare la sicurezza del modulo aggiungendo alcuni parametri di configurazione al file <code>/etc/apache2/mods-available/mod-evasive.load</code>.<br/>
'''Attenzione'''. Da Debian Stretch il file da modificare è <code>/etc/apache2/mods-available/evasive.conf</code>:
<pre>
<pre>
<IfModule mod_evasive20.c>
<IfModule mod_evasive20.c>
Riga 185: Riga 240:
# /etc/init.d/apache2 restart
# /etc/init.d/apache2 restart
</pre>
</pre>
E possibile testare il corretto funzionamento del modulo con il seguente script, installato insieme al modulo stesso:
È possibile testare il corretto funzionamento del modulo con il seguente script, installato insieme al modulo stesso:
<pre>
<pre>
# perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl
# perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl
Riga 295: Riga 350:


== Il modulo <code>mod_security</code> di Apache ==
== Il modulo <code>mod_security</code> di Apache ==
Il modulo di Apache <code>mod_security</code> e’ un modulo che permette di loggare i piu’ comuni attacchi ad Apache come XSS, remote command execution, file disclosure e tutto quello che puo’ essere considerato dannoso nei confronti di un povero web server. Il sito ufficiale del modulo è http://www.modsecurity.org , ma per fortuna esiste un pacchetto Debian, presente in Squeeze e nei Backport di Lenny.<br/>
Il modulo di Apache <code>mod_security</code> è un modulo che permette di loggare i più comuni attacchi ad Apache come XSS, remote command execution, file disclosure e tutto quello che può essere considerato dannoso nei confronti di un povero web server. Il sito ufficiale del modulo è http://www.modsecurity.org , ma per fortuna esiste un pacchetto Debian, presente in Squeeze e nei Backport di Lenny.<br/>
Per installarlo è quindi sufficiente:
Per installarlo è quindi sufficiente:
* Lenny:
* Lenny:
Riga 301: Riga 356:
# apt-get -t lenny-backports install libapache-mod-security
# apt-get -t lenny-backports install libapache-mod-security
</pre>
</pre>
* Squeeze:
* Da Squeeze a Wheezy:
<pre>
<pre>
# apt-get install libapache-mod-security
# apt-get install libapache-mod-security
</pre>
</pre>
* Da Jessie:
<pre>
# apt-get install libapache2-mod-security2
</pre>
{{Warningbox|Da '''Debian Stretch''', il modulo arriva già configurato con le opzioni mostrate qui sotto, che erano necessarie per le vecchie versioni di Debian. Se state usando Debian Stretch '''dovete saltare il resto del paragrafo'''.}}
===Fino a Jessie===
Abilitiamo il modulo appena installato e ci troveremo già con una configurazione minimale funzionante:
Abilitiamo il modulo appena installato e ci troveremo già con una configurazione minimale funzionante:
<pre>
<pre>
# a2enmod mod-security
# a2enmod mod-security
# /etc/init.d/apache2 restart
# /etc/init.d/apache2 restart
</pre>
Come prima cosa, possiamo sostituire la stringa di informazioni della direttiva <code>ServerTokens</code> e renderla ancora più anonima:
<pre>
# nano /etc/apache2/conf.d/security
</pre>
oppure, da Jessie:
<pre>
# nano /etc/apache2/conf-enabled/security
</pre>
Cerchiamo la direttiva <code>ServerTokens</code> e cambiamola in modo apparentemente meno sicuro:
<pre>
ServerTokens Full
</pre>
Quindi cerchiamo la direttiva <code>ServerSignature</code> e cambiamola così:
<pre>
#ServerSignature On
SecServerSignature Web_Server_di_Ferdy
</pre>
</pre>
La forza di questo modulo, però, risiede nella sua possibilità di tuning. Creiamo quindi il file <code>/etc/apache2/conf.d/mod_security</code> e impostiamo una prima configurazione di base personalizzata:
La forza di questo modulo, però, risiede nella sua possibilità di tuning. Creiamo quindi il file <code>/etc/apache2/conf.d/mod_security</code> e impostiamo una prima configurazione di base personalizzata:
Riga 352: Riga 432:
* ''SecFilterCheckUrlEncoding (On|Off)'': controlla se i caratteri speciali vengono encodati prima di essere passati all'URL
* ''SecFilterCheckUrlEncoding (On|Off)'': controlla se i caratteri speciali vengono encodati prima di essere passati all'URL
* ''SecFilterCheckUnicodeEncoding (On|Off)'': controlla se l'encoding Unicode è valido
* ''SecFilterCheckUnicodeEncoding (On|Off)'': controlla se l'encoding Unicode è valido
* ''SecFilterForceByteRange'':  forza le richiest dentro un range predefinito di bytes. Può aiutare a prevenire attacchi stack overflow. Il range può essere impostato da 0 a 255.
* ''SecFilterForceByteRange'':  forza le richieste dentro un range predefinito di bytes. Può aiutare a prevenire attacchi stack overflow. Il range può essere impostato da 0 a 255.
* ''SecServerSignature'': cambia la signature nella risposta agli header. Perchè funzioni è necessaria la direttiva Apache <code>ServerTokens Full</code>.
* ''SecServerSignature'': cambia la signature nella risposta agli header. Perché funzioni è necessaria la direttiva Apache <code>ServerTokens Full</code>.
* ''SecAuditEngine (On|Off|RelevantOnly)'': abilita o disabilita il loggind di mod-security. RelevantOnly logga solo le richieste che coincidono con una regola impostata.
* ''SecAuditEngine (On|Off|RelevantOnly)'': abilita o disabilita il loggind di mod-security. RelevantOnly logga solo le richieste che coincidono con una regola impostata.
* SecAuditLog /path/to/audit_log: define the file where mod-security will write its logs.
* SecAuditLog /path/to/audit_log: define the file where mod-security will write its logs.
Riga 366: Riga 446:
e riavviamo Apache:
e riavviamo Apache:
<pre>
<pre>
/etc/init.d/apache restart
# /etc/init.d/apache restart
</pre>
Per verificare il corretto funzionamento del modulo appena installato è sufficiente aprire il file di log di Apache:
<pre>
# tail /var/log/apache2/error.log
</pre>
e verificare che dopo l'ultimo riavvio compaia una riga simile a questa:
<pre>
[Sat Nov 13 13:09:49 2010] [notice] ModSecurity for Apache/2.5.11 (http://www.modsecurity.org/) configured.
</pre>
</pre>
A questo punto potremmo voler abilitare la protezione per alcuni attacchi comuni attraverso le cosiddette [http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project Core Rules], che possiamo scaricare da qui: http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/modsecurity-crs_2.0.8.tar.gz/download
A questo punto potremmo voler abilitare la protezione per alcuni attacchi comuni attraverso le cosiddette [http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project Core Rules], che possiamo scaricare da qui: http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/modsecurity-crs_2.0.8.tar.gz/download
Riga 392: Riga 480:
e riavviamo Apache:
e riavviamo Apache:
<pre>
<pre>
/etc/init.d/apache restart
# /etc/init.d/apache restart
</pre>
</pre>
=== Ulteriori regole e aggiornamento automatico ===
La comunità [http://www.gotroot.com Got Root?] mette a disposizione un ulteriore pacchetto di regole molto completo e con possibilità di aggiornamento automatico. Vediamo come utilizzarlo.
<br/>
Inannzitutto creiamo una nuova directory per archiviare le regole:
<pre>
# cd /etc/apache2/modsecurity-crs
# mkdir gotroot_rules
</pre>
Quindi apriamo il file di configurazione del modulo:
<pre>
# nano /etc/apache2/conf.d/mod_security
</pre>
e aggiungiamo sul fondo del file la direttiva:
<pre>
Include /etc/apache2/modsecurity-crs/gotroot_rules/*.conf
</pre>
Ora prepariamoci al download e all'installazione delle regole:
<pre>
# cd /etc/apache2/modsecurity-crs/gotroot_rules
# wget http://www.gotroot.com/downloads/ftp/mod_security/2.0/apache2/apache2-gotrootrules-modsec2.0-latest.tar.gz
# tar -xzvf apache2-gotrootrules-modsec2.0-latest.tar.gz
# rm apache2-gotrootrules-modsec2.0-latest.tar.gz
</pre>
Quindi prepariamo un file script per l'aggiornamento automatico delle regole:
<pre>
# nano /etc/apache2/modsecurity-crs/gotroot_update.sh
</pre>
con contenuto:
<pre>
#!/bin/sh
# Autoupdater for modsec rulesets.
#
# This script will attempt to update your rulefiles, and restart apache.
# If it apache does not start after changing rules, it will roll back to
# the old ruleset and restart apache again.
#
# Version: $Id: modsec.sh,v 1.1 2005/06/29 18:07:53 olei Exp $
# URL: http://cs.evilnetwork.org/cycro
# Copyright 2005, All Rights Reserved
APACHESTART="/usr/sbin/apache2ctl start"
MODSECPATH="/etc/apache2/modsecurity-crs/gotroot_rules"
APACHEPID="/var/run/apache2.pid"
##########################################################################
######### you probably don't need to change anything below here ##########
##########################################################################
# urls
BLACKLIST="http://www.gotroot.com/downloads/ftp/mod_security/blacklist.conf"
RULES="http://www.gotroot.com/downloads/ftp/mod_security/rules.conf"
APACHE2="http://www.gotroot.com/downloads/ftp/mod_security/apache2-rules.conf"
# internal
PID=`cat ${APACHEPID}`
UPDATED=0
echo -n "Changing PWD: "
cd ${MODSECPATH}
echo `pwd`
# blacklist
echo -n "Updating blacklist.conf: "
/usr/bin/wget -t 30 -O blacklist.conf.1 -q ${BLACKLIST}
if [ `md5sum blacklist.conf | cut -d " " -f1` != `md5sum blacklist.conf.1 | cut -d " " -f1` ] ; then
/bin/mv blacklist.conf blacklist.conf.bak
/bin/mv blacklist.conf.1 blacklist.conf
UPDATED=`expr $UPDATED + 1`
echo "ok."
else
echo "allready up to date."
/bin/rm -f blacklist.conf.1
fi
# rules
echo -n "Updating rules.conf: "
/usr/bin/wget -t 30 -O rules.conf.1 -q ${RULES}
if [ `md5sum rules.conf | cut -d " " -f1` != `md5sum rules.conf.1 | cut -d " " -f1` ] ; then
/bin/mv rules.conf rules.conf.bak
/bin/mv rules.conf.1 rules.conf
UPDATED=`expr $UPDATED + 1`
echo "ok."
else
echo "allready up to date."
/bin/rm -f rules.conf.1
fi
# apache2 rules
echo -n "Updating apache2-rules.conf: "
/usr/bin/wget -t 30 -O apache2-rules.conf.1 -q ${APACHE2}
if [ `md5sum apache2-rules.conf | cut -d " " -f1` != `md5sum apache2-rules.conf.1 | cut -d " " -f1` ] ; then
/bin/mv apache2-rules.conf apache2-rules.conf.bak
/bin/mv apache2-rules.conf.1 apache2-rules.conf
UPDATED=`expr $UPDATED + 1`
echo "ok."
else
echo "allready up to date."
/bin/rm -f apache2-rules.conf.1
fi
# try restart
if [ "$UPDATED" -gt "0" ]; then
echo -n "Restarting apache: "
/bin/kill -HUP ${PID} 2>/dev/null
# did it work?
if `/bin/kill -CHLD ${PID} >/dev/null 2>&1`; then
echo "ok."
exit 0
fi
echo "error. Apache not running."
# blacklist
echo -n "Rolling back blacklist.conf: "
/bin/mv blacklist.conf blacklist.conf.new
/bin/mv blacklist.conf.bak blacklist.conf
echo "ok."
# rules
echo -n "Rolling back rules.conf: "
/bin/mv rules.conf rules.conf.new
/bin/mv rules.conf.bak rules.conf
echo "ok."
# apache2 rules
echo -n "Rolling back apache2-rules.conf: "
/bin/mv apache2-rules.conf apache2-rules.conf.new
/bin/mv apache2-rules.conf.bak apache2-rules.conf
echo "ok."
# try starting httpd again
`${APACHESTART}`
PID=`cat ${APACHEPID}`
# did that fix the problem?
if `/bin/kill -CHLD ${PID} >/dev/null 2>&1`; then
echo "That did the trick."
exit 0
fi
echo "Fatal: Apache still not running! Run apache2ctl -t to find the error."
exit 999
fi
</pre>
Rendiamo eseguibile lo script:
<pre>
# chmod 700 /etc/apache2/modsecurity-crs/gotroot_update.sh
</pre>
Infine mettiamo nel crontab lo script appena creato:
<pre>
# crontab -e
</pre>
aggiungendo al file la riga:
<pre>
## Got Root Modsecurity rules
00 5 * * * /etc/apache2/modsecurity-crs/gotroot_update.sh
</pre>
In questo modo le regole verranno aggiornate ogni giorno alle 5 di mattina.
=== Il modulo <code>mod_security</code> e Drupal ===
=== Il modulo <code>mod_security</code> e Drupal ===
Sembra che alcune regole possano interferire con l'installazione e/o le normali operazioni di amministrazione del CMS Drupal. A [http://drupal.org/node/695902 questo indirizzo] è possibile trovare un how-to per ovviare al problema.
Sembra che alcune regole possano interferire con l'installazione e/o le normali operazioni di amministrazione del CMS Drupal. A [http://drupal.org/node/695902 questo indirizzo] è possibile trovare un how-to per ovviare al problema.
Riga 399: Riga 630:
=== Documentazione di <code>mod_security</code> ===
=== Documentazione di <code>mod_security</code> ===
A [http://modsecurity.org/documentation/ questo indirizzo] è possibile trovare l'ottima documentazione ufficiale di ModSecurity, unitamente a diversi esempi di regole personalizzate.
A [http://modsecurity.org/documentation/ questo indirizzo] è possibile trovare l'ottima documentazione ufficiale di ModSecurity, unitamente a diversi esempi di regole personalizzate.
== Apachetop ==
Pur non essendo tecnicamente uno strumento per l'hardening di un server web, l'utility Apachetop può venire utile nell'analisi dei processi che stanno occupando le risorse di Apache.<br/>
Apache top è un'utilità basata su curses che mostra informazioni in tempo reale su una istanza di Apache in esecuzione.
<br/>
È modellata prendenda ad esempio l'utilità "top" e mostra informazioni quali il numero di richieste al secondo, i byte al secondo e gli URL visualizzati più popolari.
<br/>
Deve essere eseguito da una macchina su cui gira Apache dato che funziona analizzando i file di registro in /var/log/apache.
<br/>
Per installarlo:
<pre>
# apt-get install apachetop
</pre>
Per utilizzarlo:
<pre>
# apachetop
last hit: 00:00:00        atop runtime:  0 days, 00:00:05            20:27:44
All:            0 reqs (  0.0/sec)          0.0B (    0.0B/sec)      0.0B/req
2xx:      0 ( 0.0%) 3xx:      0 ( 0.0%) 4xx:    0 ( 0.0%) 5xx:    0 ( 0.0%)
R (  5s):      0 reqs (  0.0/sec)          0.0B (    0.0B/sec)      0.0B/req
2xx:      0 ( 0.0%) 3xx:      0 ( 0.0%) 4xx:    0 ( 0.0%) 5xx:    0 ( 0.0%)
</pre>
== Asql ==
Questo pacchetto contiene un semplice strumento che permette di fare facilmente interrogazioni SQL sui comuni file di log di Apache.
<br/>
Può dare informazioni più chiarificanti rispetto alla visione di analisi statiche dei file di log. Per installarlo:
<pre>
# apt-get install asql
</pre>
Una volta installato, avviamolo con:
<pre>
# asql
</pre>
Quindi, come prima cosa, carichiamo il file di log che vogliamo analizzare:
<pre>
asql v1.5 - type 'help' for help.
asql> load /var/log/apache2/access.log
Loading: /var/log/apache2/access.log
asql>
</pre>
Quella che segue è una veloce sessione in Asql dove vengono impostati alcuni alias:
<pre>
asql> select COUNT(id) FROM logs
5277
asql> alias hits SELECT COUNT(id) FROM logs
ALIAS hits SELECT COUNT(id) FROM logs
asql> alias ips SELECT DISTINCT(source) FROM logs;
ALIAS ips SELECT DISTINCT(source) FROM logs;
asql> hits
5277
asql> ips
127.0.0.1
160.78.28.135
184.73.137.204
217.201.81.207
31.44.184.50
65.52.109.151
66.220.149.245
66.220.149.251
67.207.141.237
79.10.163.223
80.76.69.7
82.50.107.25
92.240.68.153
93-58-79-25.ip157.fastwebnet.it
93.144.42.66
93.58.79.25
crawl-66-249-68-22.googlebot.com
crawl-66-249-72-170.googlebot.com
crawl-66-249-72-209.googlebot.com
host-89-107-230-194.routergate.com
host223-163-dynamic.10-79-r.retail.telecomitalia.it
klopstock.ce.unipr.it
localhost
msnbot-65-52-109-151.search.msn.com
net-93-144-42-66.cust.dsl.teletu.it
ns1.eliteturk.net
proxy-03.icteam.it
asql> quit
</pre>
Per un utilizzo approfondito di questo strumento consiglio una letture alle pagine man.
== Ulteriori configurazioni ==
Diamo qui di seguito alcuni veloci consigli per impostare delle strategie di ottimizzazione e di protezioni di alcuni altri componenti della struttura di un server LAMP.
=== Configurazione di PHP ===
A livello di configurazione di PHP è possibile:
* Limitare l'utilizzo delle risorse di sistema da parte di una pagina PHP
* Introdurre filtri standard sugli input passati a query SQL
* Limitare l'accesso al file system da parte di script PHP
=== Configurazione di MySQL ===
A livello di configurazione di MySQL è possibile:
* Controllare e impedire accesso in lettura o in scrittura a dati da parte di applicazioni Web
=== Applicazioni web ===
A livello di applicazione web si deve:
* Controllare i dati in input e renderli inoffensivi ad attacchi basati su SQL Injection, Cross Site Scripting, accesso al file sistema, abuso di risorse locali.
* Verificare la logica del codice per impedire accesso ad aree riservate da parte di utenti non autorizzati
== Sitografia ==
Per la redazione di questa guida sono state assai utili le informazioni raccolte qui:
* [http://openskill.info/topic.php?ID=83 Openskill - Sicurezza e Apache]
* [http://www.debuntu.org/2006/08/13/86-secure-your-apache2-with-mod-security Debuntu - Secure your Apache]
* [http://isp-control.net/documentation/howto:security:mod_security_on_debian ISP CP Omega]
{{Autori
|Autore = [[Utente:Ferdybassi|Ferdybassi]] 22:10, 11 nov 2010 (CET)
}}
[[Categoria:Web server]]
[[Categoria:Debian e sicurezza]]
Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/22423...42376"

Menu di navigazione