Il blog sull'informatica

Da un po' di tempo a questa parte ho deciso di rendere raggiungibili i miei server Web solo mediante il protocollo HTTPS. Una volta fatto ciò, ho riscontrato (con mio enorme dispiacere) che l'interfaccia Web di ntop (in ascolto sulla porta 3000 TCP) non era più utilizzabile.

Proprio per questo motivo (e per non cambiare la regola di forwarding sul mio router e sui miei 2 firewall), ho deciso di effettuare qualche modifica al demone in questione.

In particolare, ho fatto in modo che ntop rimanesse in ascolto sulla porta 3000, accettando però connessioni HTTPS.

Ecco la modifica nello specifico:

start-stop-daemon --start --quiet --name $NAME --exec $DAEMON --
  -d -L -u $USER -w 0 -W 3000 -P $HOMEDIR

ovvero ho disabilitato l'ascolto su HTTP (-w 0) ed abilitato l'ascolto su HTTPS (-W 3000).

Il file da modificare è /etc/init.d/ntop.

A modifiche completate si può procedere con un riavvio del demone, digitando:

nightfly@nightbox:/etc/init.d$ sudo service ntop restart

ed abbiamo finito.

Enjoy.

Di seguito riporto la configurazione del mio Swatch, in grado di tenere sotto controllo ciò che accade sul server Web (Apache) che attualmente ho in gestione:

ignore /nagios-plugins/

#HTTP Forbidden
watchfor  /403/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Access Forbidden

#HTTP Not Found
watchfor  /404/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Not Found

#HTTP Internal Server Error
watchfor  /500/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Internal Server Error

#HTTP OK
watchfor  /200/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Hit OK

Poichè sul server è presente anche nagios che ogni tanto effettua dei check sull'HTTPS, ho dovuto utilizzare la entry ignore /nagios-plugins/, evitando così di ricevere un'email ad ogni controllo.

Inoltre, sul server Web è presente l'autentica .htaccess, quindi ho messo sotto monitoraggio anche le hit andate a buon fine, in modo da poter verificare quale utente ha effettuato l'accesso alle aree riservate. Ciò è stato possibile anche grazie al fatto che sul server non vi è una grande mole di richieste. In caso contrario avrei certamente evitato una configurazione del genere, pena il rischio di beccarmi un ban sullo smarthost.

Infine, non ho ritenuto opportuno controllare gli errori HTTP 401 (Unauthorized), in quanto tale funzione è svolta egregiamente da fail2ban.

A presto.

Recentemente ho installato da un amico un proxy basato su Squid. Ora, per bloccare il traffico diretto alle porte http, https ed http-alt ho utilizzato un firewall (Iptables), mentre per il controllo dei contenuti Web mi sono avvalso di squidGuard.

Dopo aver effettuato diverse prove di navigazione ed aver constatato che tutto funzionava correttamente, lascio la mia postazione e mi dirigo a casa per godermi un po' di meritato riposo. Peccato però che dopo qualche minuto mi chiama il mio amico lamentando l'impossibilità di scaricare gli aggiornamenti di Windows.

Uhm, mi sa che qui abbiamo a che fare con Windows Update 5... bene, vorrà dire che forzerò le workstation (4 Win-XP) ad utilizzare il proxy anche in fase di download degli aggiornamenti.

Ritorno dunque dall'amico e comincio a lanciare tale comando su ciascuna postazione di lavoro:

C:> proxycfg -p proxy.cliente.lan:3128

Successivamente, digito il comando (come ulteriore verifica):

C:> proxycfg

A questo punto procedo con il download degli aggiornamenti e tutto funziona come dovrebbe.

A presto.

PS: ovviamente in nessuna delle 4 macchine coinvolte veniva utilizzato IE come browser predefinito (per ragioni di sicurezza). In caso contrario avrei potuto lanciare il comando:

C:> proxycfg -u

al posto di:

C:> proxycfg -p proxy.cliente.lan:3128

impostando come proxy quello usato da IE.