Archivi tag: httpd

CentOS 6: realizzare un network intrusion detection system open source – Parte 3

Dopo aver installato e configurato snort, barnyard2, pulledpork e MySQL (vedi qui e qui), ora vedremo come installare l’interfaccia Web del nostro sistema NIDS, ovvero Snorby.

Poichè tale interfaccia si basa su Ruby, è necessario predisporre il nostro sistema per il supporto del linguaggio di scripting in questione.

snorby-dashboard

Preparazione della macchina

Per prima cosa installiamo i software prerequisiti, mediante i comandi:

yum -y groupinstall "Development Tools"

yum install -y openssl-devel readline-devel libxml2-devel libxslt-devel mysql mysql-devel mysql-libs mysql-server urw-fonts libX11-devel libXext-devel qconf fontconfig-devel libXrender-devel unzip

yum -y install xz urw-fonts libXext openssl-devel libXrender

Successivamente, scarichiamo ed installiamo ImageMagick , per la creazione di immagini bitmap, e wkhtmltopdf, per la conversione delle pagine HTML in PDF (funzionalità indispensabile durante la generazione dei report):

cd /usr/local/src

wget ftp://ftp.fifi.org/pub/ImageMagick/ImageMagick-6.8.9-6.tar.gz

tar -xvf ImageMagick-6.8.9-6.tar.gz

cd ImageMagick-6.8.9-6

./configure

make

make install

ldconfig 

cd ..

wget http://sourceforge.net/projects/wkhtmltopdf/files/0.12.1/wkhtmltox-0.12.1_linux-centos6-amd64.rpm/download

rpm -Uvh wkhtmltox-0.12.1_linux-centos6-amd64.rpm

Adesso scarichiamo rvm, attraverso il quale sarà possibile installare la versione di Ruby compatibile con Snorby (ovvero la 1.9.3, che, purtroppo, è ormai obsoleta e non più mantenuta):

curl -L get.rvm.io | bash -s stable

Installiamo dunque Ruby e facciamo in modo che il sistema utilizzi la versione 1.9.3 come default:

rvm install 1.9.3

rvm use --default 1.9.3

Ora, utilizzando il packet manager di Ruby (ovvero gem), procediamo con l’installazione di Rails (il framework) e di passenger (necessario per integrare Snorby e Apache):

gem install rails

gem install passenger

passenger-install-apache2-module

Installiamo alcuni pacchetti prerequisiti:

gem install devise_cas_authenticatable -v '1.1.0'

e

gem install bundler

In particolare, quest’ultimo si occupa di gestire le dipendenze tra i gem (ed è il software responsabile della creazione dei file Gemfile e Gemfile.lock).

Installazione e configurazione di Snorby

Creiamo la directory nella quale ospitare Snorby:

mkdir -p /var/www/html/snorby

e scarichiamo l’applicazione vera e propria:

cd /var/www/html/snorby

wget -O snorby.zip --no-check-certificate https://github.com/Snorby/snorby/archive/master.zip

Scompattiamo l’archivio, posizioniamoci nella directory snorby-master e spostiamone il contenuto all’interno di /var/www/html/snorby:

unzip snorby.zip

cd snorby-master/

mv * ../

Modifichiamo ora il contenuto del file Gemfile, sostituendo le direttive di default per rake, json e devise_cas_authenticatable con le seguenti:

gem 'rake', '0.9.2.2'
gem 'json', '~> 1.8.3'
gem 'thin'

gem 'devise_cas_authenticatable',  '~> 1.1.0'

Inoltre, è necessario inserire la direttiva gem ‘thin’ subito dopo gem ‘json’, commentando quella dopo gem “letter_open”:

gem 'json', '~> 1.8.3'
gem 'thin'

group(:development) do
     gem "letter_opener"
   # gem 'thin'

Discorso simile vale per il file Gemfile.lock, in cui bisogna modificare le direttive rake e json nel seguente modo:

rake (0.9.2.2)

json (1.8.3)

Lanciamo il comando bundle install in modo da installare i pacchetti gem (con le relative dipendenze) definiti all’interno del Gemfile precedentemente editato:

bundle install

Eliminiamo la dir snorby-master (ormai vuota) e passiamo alla configurazione di Snorby:

rm -rf snorby-master/

cd config

cp snorby_config.yml.example snorby_config.yml

nano snorby_config.yml

definendo la giusta timezone:

time_zone: Europe/Rome

A questo punto possiamo configurare la connessione al database, editando il file config/database.yml:

cd ..

cp config/database.yml.example config/database.yml

nano config/database.yml

il cui contenuto sarà simile al seguente:

# Snorby Database Configuration
#
# Please set your database password/user below
# NOTE: Indentation is important.
#
snorby: &snorby
  adapter: mysql
  username: vostrouser
  password: "vostrapassword" # Example: password: "s3cr3tsauce"
  host: localhost

development:
  database: snorby
  <<: *snorby

test:
  database: snorby
  <<: *snorby

production:
  database: snorby

Avviamo l’applicazione (con finalità di test), mediante i comandi:

rake snorby:setup

rails server thin -e production

da lanciare all’interno della dir /var/www/html/snorby ed il cui output dovrebbe essere simile al seguente:

=> Booting Thin
=> Rails 3.1.12 application starting in production on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop

http://ip:3000/users/login

Provando ora a connetterci (con il nostro browser) a http://ip:3000/users/login dovremmo riuscire a visualizzare l’interfaccia di Snorby (con il relativo form per il login, dove l’email di default è snorby@example.com e la password è semplicemente snorby).

Integrazione tra Snorby e Apache

Come già affermato in precedenza, il modulo di Apache che consente al nostro server Web di interfacciarsi con le applicazioni scritte in Ruby prende il nome di passenger.

Per prima cosa occorre dunque configurare il suddetto modulo:

nano /etc/httpd/conf.d/mod_passenger.conf

il cui contenuto dovrà essere:

LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p551/gems/passenger-5.0.16/buildout/apache2/mod_passenger.so

PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p551/gems/passenger-5.0.16
PassengerDefaultRuby /usr/local/rvm/gems/ruby-1.9.3-p551/wrappers/ruby

Infine, modifichiamo il file di configurazione di Apache (/etc/httpd/conf/httpd.conf), creando un virtual host opportuno (in ascolto sulla porta TCP 82):

Listen 82

<VirtualHost *:82>
     Servername vostroserver.vostrodominio.com
     DocumentRoot /var/www/html/snorby/public
     <Directory /var/www/html/snorby/public>
        Order deny,allow
        Allow from all
        Options -MultiViews
        AuthName "Snorby Access"
        AuthType Basic
        AuthUserFile /etc/snorby/passwd
        Require valid-user
    </Directory>
</VirtualHost>

Tale virtual host richiede l’autentica HTTP, ergo occorre creare il file in cui verranno salvate le coppie username/password da utilizzare:

mkdir -p /etc/snorby

htpasswd -c /etc/snorby/passwd vostroutente

Infine, riavviamo Apache:

service httpd reload

ed abbiamo finito.

Alla prossima.

CentOS 6: Watchdog open source mediante Monit

Premesso che Monit può essere configurato anche come NMS a tutti gli effetti (sia centralizzato che distribuito, vedi M/Monit), lo scopo di questo post è quello di illustrarne la configurazione come semplice watchdog.

watchdogEsso, infatti, si occuperà di riavviare eventuali servizi “in stallo” (nella fattispecie httpd e mysql), riducendo notevolmente i tempi di downtime.

Per prima cosa occorre installare il suddetto applicativo:

[root@server ~]# yum install monit

Una volta installato possiamo editarne la configurazione (/etc/monit.conf) nel modo seguente:

set httpd port 2813 and #2813 è la porta su cui è in ascolto l'interfaccia Web di Monit
     use address <indirizzo IP>  #l'indirizzo IP è quello su cui l'interfaccia Web di Monit è in binding
     allow 0.0.0.0/0          #semplice ACL per consentire a qualunque IP sorgente di connettersi alla suddetta interfaccia  
     allow username:password      # credenziali di accesso all'interfaccia Web di Monit
     allow @monit           
     allow @users readonly

A questo punto creiamo due file all’interno della directory /etc/monit.d, rispettivamente httpd e mysqld.

Il primo conterrà le seguenti direttive:

check process httpd with pidfile /var/run/httpd.pid
group apache
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed host 94.23.68.182 port 80
protocol http then restart
if 5 restarts within 5 cycles then timeout

Il secondo, invece, avrà il seguente contenuto:

check process MySQL-Server with pidfile /var/run/mysqld/mysqld.pid
    start program = "/etc/init.d/mysqld start"
    stop program = "/etc/init.d/mysqld stop"
    if failed host localhost port 3306
    protocol mysql then restart
    if 5 restarts within 5 cycles then timeout

Verifichiamo la sintassi delle suddette configurazioni mediante il comando:

[root@server ~]# monit -t

Ora possiamo avviare il nostro watchdog:

[root@server ~]# service monit start

imponendone l’avvio automatico dopo ogni reboot del server:

[root@server ~]# chkconfig monit on

Verifichiamo l’effettiva raggiungibilità dell’interfaccia Web di Monit mediante la URL:

http://IP:2813

ed il gioco è fatto.

E’ tutto. Alla prossima.

Centos 6: Apache e le ACL basate sull’IP sorgente

Per fare in modo che il contenuto di alcuni file presenti nella directory a cui punta Apache possa essere visualizzato solo da determinati IP sorgenti è necessario definire delle ACL direttamente nel file .htaccess posizionato nella suddetta dir, oltre ad effettuare una piccola modifica all’interno del file di configurazione di Apache stesso, ovvero /etc/httpd/conf/httpd.conf.

 

apache-logo_new.png

Il contenuto del file .htaccess dovrà essere strutturato nel modo seguente:

Order Deny,Allow
Deny from All
Allow from <IP1>
Allow from <IP2>
Allow from <IP3>
Allow from <IP4>
Allow from <IP5>

mentre all’interno del file di configurazione di Apache occorre aggiungere la seguente direttiva:

<Directory /var/www/securecontent>
         AllowOverride All
</Directory>

dove securecontent è la directory il cui contenuto vuole essere riservato solo ai suddetti IP.

Infine eseguiamo un reload della configurazione di Apache:

[root@webserver ~]# service httpd reload

ed abbiamo finito.

Alla prossima.

Apache virtual host su IP pubblico dedicato

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.

 

apache,virtual host,httpd,bind,virtual interface,dedicated public ip,private access,logging,syslogd,iptables,rc.local

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-scrips/:

[root@server network-scrips]# 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-scrips]# ifup eth0:0

[root@server network-scrips]# 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.

Apache, virtual host ed SSL su CentOS

La cosa fantastica di Apache è che ti consente di gestire i cosiddetti virtual host, ovvero N server Web virtuali, ognuno dei quali presenta le proprie caratteristiche peculiari.

Essi risultano particolarmente comodi quando si ha la necessità di imbastire dei frontend che rispondano per alcuni domini su HTTPS e per altri su HTTP.

logo_apache22.jpg

Come al solito, la presente guida si focalizzerà sulla configurazione del server vera e propria (httpd.conf), e successivamente sulla configurazione di ciascun virtual host.

Configurazione del server

La prima modifica da effettuare nel file di configurazione di Apache riguarda l’abilitazione del protocollo HTTPS. In particolare, esso verrà gestito grazie ad uno specifico modulo, ovvero mod_ssl.so, non presente nell’installazione di default relativa ad Apache.

Ergo, sarà necessario dapprima scaricarlo mediante il comando:

[root@serverweb conf]# yum install mod_ssl

Non ho installato anche openssl in quanto sono partito dal presupposto che siate già in possesso dei certificati X.509 (nel formato Apache) relativi al vostro dominio.

A questo punto è necessario abilitare il suddetto modulo aggiungendo la seguente direttiva nel file /etc/conf/httpd.conf:

LoadModule ssl_module modules/mod_ssl.so

Successivamente, si dovrà procedere con la messa in ascolto sul server della porta TCP 443 (HTTPS).

Per fare ciò si può aggiungere la seguente stringa nel file di configurazione di Apache:

Listen 443

Infine, sempre nel file di configurazione in questione, si dovrà specificare in quale directory sono presenti le direttive relative ai virtual host:

# Include the virtual host configurations:
Include /etc/httpd/vhosts.d/*.conf

Configurazione del virtual host

Posizioniamoci nella directory oggetto dell’include e creiamo un nuovo file di configurazione per il virtual host:

[root@serverweb vhosts.d]# nano virtualhost1.conf

Il cui contenuto sarà simile al seguente:

<VirtualHost *:443>
  ServerName www.miodominio.com

  DocumentRoot /var/www/virtualhosts/www.miodominio.com/htdocs

  SSLEngine on
  SSLCertificateFile /etc/ssl/sslcert.crt
  SSLCertificateKeyFile /etc/ssl/sslkey.pem
  SSLCertificateChainFile /etc/ssl/sf_bundle.crt

  <Directory /var/www/virtual/static.betuniq.info/htdocs>
      AllowOverride All
      Order allow,deny
      Allow from all
   </Directory>

  ErrorLog /var/www/virtualhosts/www.miodominio.com/logs/ssl_error.log
  CustomLog /var/www/virtualhosts/www.miodominio.com/logs/ssl_access.log combined
  #ServerSignature Off

  Redirect 404 /favicon.ico

  <Location /favicon.ico>
   ErrorDocument 404 “No favicon”
  </Location>

</VirtualHost>

Come avrete intuito, il virtual host in questione è in ascolto sulla porta TCP 443, quindi è in grado di servire solo ed esclusivamente il traffico HTTPS:

<VirtualHost *:443>

Con ServerName specifico il dominio associato al virtual host in questione mentre con DocumentRoot indico la direcotry in cui sono presenti le pagine Web (e relativi file, come immagini, fogli di stile, ecc.).

Con SSLEngine on abilito il motore SSL e con le direttive:

SSLCertificateFile /etc/ssl/sslcert.crt
SSLCertificateKeyFile /etc/ssl/sslkey.pem
SSLCertificateChainFile /etc/ssl/sf_bundle.crt

indico rispettivamente il pathname relativo al certificato X.509 (sslcert.crt), della chiave privata RSA (sslkey.pem) e del certificato di terze parti (sf_bundle.crt).

Le altre stringe riguardano semplicemente i file di log e le politiche di overwrite sulla directory (ad esempio mediante file .htaccess).

Ora, affinchè il suddetto dominio rimanga in ascolto sia sulla 443 che sulla 80 (HTTP puro), si può creare un ulteriore file di configurazione, contenente però la direttiva:

<VirtualHost *:80>

nessuna entry associata all’SSL ed ai certificati ma la stessa DocumentRoot del vhost precedente.

Per rendere effettive le modifiche senza creare disservizio è sufficiente lanciare il comando:

[root@serverweb conf]# service httpd reload

Se tale comando non restituisce errori è un ottimo segno.

Per avere ulteriore conferma del corretto funzionamento relativo al nostro server Web, si possono fare due check mediante netstat:

[root@serverweb conf]# netstat -anp | grep :80

e

[root@serverweb conf]# netstat -anp | grep :443

Se il server risulta in Listen è molto probabile che stia funzionando correttamente. Fate comunque delle prove con un browser per esserne certi.

E’ tutto. Alla prossima.

Logging con Varnish Cache

In questo post ho spiegato, a grandi linee, cos’è Varnish Cache ed a cosa serve. Il problema che mi ponevo era, sostanzialmente, quello di individuare l’IP sorgente delle richieste HTTP, in modo che il log di Apache (httpd) fosse in grado di tenerne traccia.

http, header http, client ip, logging, x-forwarded-for, varnishlog, backand, varnishncsa, httpd, apache

Infatti, nel caso in cui Varnish sia in esecuzione sulla stessa macchina su cui gira Apache, l’IP sorgente delle richieste HTTP sarà sempre e comunque 127.0.0.1 (aka localhost). In particolare, sarà Varnish ad intercettare le suddette richieste sulla porta 80 e, successivamente, ad inoltrarle al server Web di backend.

Sempre nel post in questione ho mostrato una direttiva del file di configurazione di Varnish (dafault.vcl), in cui viene manipolato il dato HTTP, modificandone l’header (precisamente considerando il campo X-FORWARDED-FOR come IP sorgente della richiesta, in modo da inserirlo nel file di log). Inutile dire che tale soluzione, seppure lecita, è sconveniente per due motivi:

1) manipolare i dati HTTP risulta in qualche modo oneroso in termini computazionali;

2) tale operazione potrebbe non andare a buon fine, in quanto il campo X-FORWARDED-FOR potrebbe essere vuoto.

Cosa fare dunque? Semplice, utilizzare due validi strumenti messi a disposizione da Varnish Cache, ovvero varnishncsa e varnishlog.

Il primo ci consente di salvare in un file di log apposito le richieste HTTP che Varnish ha preso in carico. Il secondo, invece, può essere facilmente customizzato, in modo da tenere traccia solo delle informazioni che ci interessano. Personalmente, ritengo che utilizzare entrambi per loggare il traffico utente sia inutile, ecco perchè uso varnishncsa per il logging delle richieste HTTP e varnishlog per tenere traccia delle comunicazioni con i backend.

Ma vediamo adesso come utilizzare i tool in questione (che su CentOS sono semplicemente dei demoni).

Per prima cosa avviamo varnishncsa utilizzando il comando:

[user@host varnish]# service varnishncsa start

Successivamente, facciamo in modo che il suddetto demone entri in esecuzione automaticamente su diversi runlevel, mediante il comando chkconfig:

[user@host varnish]# chkconfig --level 2345 varnishncsa on

A questo punto non ci rimane che configurare varnishlog. Se lanciamo il comando:

[user@host varnish]# varnishlog help

otteniamo una lista delle flag utilizzabili. Quella che a noi interessa è -b, ovvero si vuole imporre a varnishlog di registrare solo gli eventi relativi alla comuncazione con i backend (utile in caso di troubleshooting). Ecco uno stralcio del man che indica il significato della suddetta flag:

 -b     Include log entries which result from communication with a backend server.  If neither -b nor -c  is  specified, varnishlog acts as if they both were.

Modifichiamo il demone, posizionandoci nella directory /etc/init.d e digitando:

[user@host varnish]# nano varnishlog

Nella direttiva:

DAEMON_OPTS="-a -w $logfile -D -P $pidfile"

inseriamo la flag -b. Essa diventerà:

DAEMON_OPTS="-a -b -w $logfile -D -P $pidfile"

Ora impostiamo l’esecuzione automatica del demone in questione (come già fatto per varnishncsa):

[user@host varnish]# chkconfig --level 2345 varnishlog on

Infine, avviamolo:

[user@host varnish]# service varnishlog start

Adesso Varnish Cache sarà in grado di loggare tutti gli eventi che la coinvolgono.

Alla prossima.

Varnish + httpd su CentOS 5: logging del vero IP sorgente

Per ottimizzare i tempi di risposta dei server Web possono essere utilizzati degli accelleratori http (i quali svolgono principalmente operazioni di caching). Uno di questi prende il nome di varnish, software open source piuttosto diffuso ed altamente performante.

cache, varnish, httpd, apache, centos 5, http accelerator, caching, logging, source IP

Ora, poichè dal punto di vista legislativo è necessario che vengano loggati gli IP sorgenti delle richieste http, è indispensabile che il demone httpd sia in grado di individuarli e registrarli correttamente. Con una configurazione standard del suddetto demone ciò non è possibile, in quanto l’IP sorgente sarà sempre e comunque quello del server varnish che gli ha inoltrato la richiesta.

Per aggirare tale problematica occorre operare sulla configurazione di varnish e di httpd.

Per prima cosa, modifichiamo il file /etc/varnishd/defaul.vcl aggiungendo la seguente entry:

sub vcl_recv {
if (req.http.x-forwarded-for) {
    set req.http.X-Forwarded-For =
    req.http.X-Forwarded-For ", " client.ip;
  } else {
    set req.http.X-Forwarded-For = client.ip;
  }
}

In questo modo il campo http.X-Forwarded-For presente nell’header http verrà popolato con il vero IP sorgente della richiesta.

A questo punto dobbiamo semplicemente dire al demone httpd come interpretare le informazioni ricevute da varnish:

[root@bqweb1 varnish]# nano /etc/httpd/conf/httpd.conf

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" varnishcombined

e come CustomLog utilizzeremo la seguente direttiva:

CustomLog logs/access_log varnishcombined

Riavviamo sia varnish che httpd ed il gioco è fatto.

Alla prossima.

Apache2: disabilitare il directory listing

Uno dei tuning fondamentali per rendere sicuro il nostro Web server Apache consiste nel disabilitare il directory listing. Infatti, non è raro imbattersi in dei siti su cui è possibile visualizzare il contenuto delle directory in essi contenute, quali images, doc e compagnia bella (i termini Google hacking e la dork intitle:Index of vi dicono qualcosa?).

apache.jpg

 

Bene, per prima cosa è necessario aprire in lettura il file default (default-ssl se il vostro server utilizza il protocollo criptato https) che si trova nella dir /etc/apache2/sites-available:

nightfly@nightbox:/etc/apache2/sites-available$ sudo nano default

Adesso, nella sezione riportata di seguito rimuoviamo l’opzione Indexes:

      <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

In questo modo, tale sezione deventerà:

     <Directory /var/www/>
                Options FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
     </Directory>

Riavviamo Apache per rendere effettive le nuove impostazioni lanciando il comando:

nightfly@nightbox:/etc/apache2/sites-available$ sudo service apache2 restart

ed il gioco è fatto.

A presto.

Apache mod_rewrite sui link generati da sarg

Recentemente ho avuto a che fare con uno scenario piuttosto complesso, in cui gli utenti della LAN riescono a navigare sul Web grazie all’intermediazione di un proxy, nella fattispecie di Squid.

Ora, per facilitare la vita ai net admin, esiste un tool particolare che si integra alla perfezione con Squid e permette di analizzare il traffico generato da ciascun utente, in modo da poter osservare eventuali comportamenti ambigui e monitorare le loro attività sul Web. Tale software prende il nome di sarg, acronimo di Squid Analysis Report Generator.

Fin qui tutto chiaro, peccato però che i vari utenti si autentichino al proxy sfruttando NTLM e che il proxy identifichi gli spazi presenti negli username con la notazione ASCII, ovvero con %20. Quindi, nel momento in cui clicco su un link generato da sarg, del tipo:

nome%20cognome

il server apache che mi risponde interpreta il %20 come uno spazio, ragion per cui anzichè provare ad aprirmi il link:

http://proxy.dominio.com/sarg/nome%20cognome

cercherà di visualizzare il link

http://proxy.dominio.com/sarg/nome cognome

rispondendomi picche. Come fare dunque per risolvere tale problematica? Semplice, sfruttando il mod_rewrite messo a disposizione da Apache.

In particolare, tale feature consente di modificare al volo le URL richieste dall’utente, permettendo la sostituzione del %20 con un backslash, il carattere di escape , il quale serve proprio ad indicare al Web server che il %20 va interpretato in modo letterale e non come uno spazio.

Ma passiamo ai fatti. Per prima cosa identifichiamo la directory in cui è installato sarg, che per la distro CentoOS 5.0 è /var/www/sarg.

Posizioniamoci ora nella directory relativa al file di configurazione di apache, ovvero /etc/httpd/conf ed apriamo tale file di configurazione (httpd.conf) in scrittura:

[root@proxy conf]# vi httpd.conf

Verifichiamo che sia presente la direttiva:

LoadModule rewrite_module modules/mod_rewrite.so

e che non sia commentata.

Adesso inseriamo le seguenti direttive per la directory in cui si trova sarg:

<Directory "/var/www/sarg">

Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all

</Directory>

In realtà, quello che ci interessa è abilitare l’ovverride per la directory di sarg, in modo da consentire il corretto funzionamento del mod_rewrite.

Posizioniamoci adesso nella dir relativa a sarg e creiamo il file .htaccess:

[root@proxyint sarg]# vi .htaccess

e successivamente inseriamo all’interno del file le seguenti direttive:

RewriteEngine On

RewriteRule ([^ ]+) ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3%20$4 [R=301,L]

RewriteRule ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3 [R=301,L]

RewriteRule ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2 [R=301,L]

Adesso verifichiamo che il mod_rewrite funzioni correttamente. Per fare ciò creiamo una directory all’interno di /var/www/sarg e chiamiamola pro%20va:

[root@proxyint sarg]# mkdir pro%20va

Infine, proviamo ad accedere a tale directory mediante il nostro browser, digitando nella barra degli indirizzi la seguente URL:

http://proxy.dominio.com/sarg/pro%20va

Se il server Web vi risponde con un errore 404 (page not found), vuol dire che il mod_rewrite non sta funzionando. Viceversa, se la directory pro%20va è vuota ed il browser vi risponde con la pagina Index of /sarg/pro%20va, vuol dire che tutto sta funzionando alla perfezione (noterete anche la presenza nella URL del backslash codificato in ASCII, ovvero %25).

Da questo momento in poi, ogni volta che proverete ad accedere alle statistiche generate da sarg, verrete correttamente reindirizzati alla pagina che state cercando.

A presto.