debian lenny django mod-wsgi

aptitude install libapache2-mod-wsgi python-imaging gettext python-mysqldb

## download django src/svn

## apache cfg

### DJANGO begin ###
Alias  /media/ /var/www/htdocs/website/django/website/media/
WSGIScriptAlias / /var/www/htdocs/website/django/website/apache/django.wsgi
WSGIDaemonProcess nuovacigat user=website group=website  processes=1 threads=1 maximum-requests=1000 display-name=website.dj
WSGIProcessGroup website
### DJANGO end ###

## cat  /var/www/htdocs/website/django/website/apache/django.wsgi

import os
import sys

sys.stdout = sys.stderr

#Calculate the path based on the location of the WSGI script.

apache_configuration= os.path.dirname(__file__)project = os.path.dirname(apache_configuration)workspace = os.path.dirname(project)sys.path.append(workspace)
sys.path.append(‘/var/www/htdocs/website/django/django-website’)      <–  django fw
sys.path.append(‘/var/www/htdocs/website/django/website’)       <– app
import django.core.handlers.wsgi
os.environ[‘DJANGO_SETTINGS_MODULE’] = ‘website.settings’
application = django.core.handlers.wsgi.WSGIHandler()

Posted in Apache at April 1st, 2010. No Comments.

Apache http return code table

100 Continue
101 Switching Protocols
102 Processing
200 OK
201 Created
202 Accepted
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 unused
307 Temporary Redirect
400 Bad Request
401 Authorization Required
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
408 Request Time-out
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Large
415 Unsupported Media Type
417 Expectation Failed
418 unused
419 unused
420 unused
421 unused
422 Unprocessable Entity
423 Locked
424 Failed Dependency
500 Internal Server Error
501 Method Not Implemented
502 Bad Gateway
504 Gateway Time-out
506 Variant Also Negotiates
507 Insufficient Storage
508 unused
509 unused
510 Not Extended

Posted in Apache at September 17th, 2008. No Comments.

Debian apache utf8 problem

Di default le pagine vengono (anche in presenza di un tag meta) restituite con encoding iso-8859-1

Cio’ porta a notevoli problemi se le pagine vengono scritte in utf8, per ovviare apache ci mette a disposizione la direttiva applicabile a qualsiasi context

AddDefaultCharset

Se si vuole lasciare libertà completa allo sviluppatore basta disattivare questa funzionalità con

AddDefaultCharset Off

Per visualizzare testo/codice nei vari standard e soprattutto in rapidità link l’unicode code converter giunto alla 4^ versione

Posted in Apache at May 23rd, 2007. No Comments.

APACHE Script monitor hits/day

#  Script per conteggiare le richieste di un singolo ip all’interno del access log
#+ e monitorare attivita’ di richieste sospette.

#check utente ROOT
ROOT_UID=0

#codice errore se nn root
E_NONROOT=67

if [ “$UID” -ne “$ROOT_UID” ]
then
echo “Devi essere root….”
exit $E_NONROOT
fi

if [ ! “$(echo $1 | grep ‘[0-9]\{1,3\}[.][0-9]\{1,3\}[.][0-9]\{1,3\}[.][0-9]\{1,3\}’)” ]
then
echo “Uso: `basename $0` indirizzo_IP numero_giorni”
exit 1
fi

IP=$1

echo “—————————–”
if [ -n “$2″ ]
then
for i in $(seq 0 $2); do
DATA_PER_ACCESSLOG=$(date –date=”$i day ago” ‘+%d/%b’)
TOT=`grep -c $IP.*$DATA_PER_ACCESSLOG /var/www/htdocs/web/logs/web-access.log`
echo $DATA_PER_ACCESSLOG ”  ” $IP ”  ” $TOT
# echo $i
done
else
#date –date=’2 day ago’ ‘+%s’
DATA_PER_ACCESSLOG=`date +’%d/%b’`
TOT=`grep -c $IP.*$DATA_PER_ACCESSLOG /var/www/htdocs/web/logs/web-access.log`
echo $DATA_PER_ACCESSLOG ”  ” $IP ”  ” $TOT
fi
echo “—————————–”

exit 0

Posted in Apache, Bash, Linux at August 23rd, 2006. 1 Comment.

APACHE Script monitor hits per ip in un arco di N minuti

#!/bin/bash
# Script per monitorare il numero di hits per ip in un arco di N minuti, solo utente root

#default minuti
DEFAULTMIN=1440

#check utente ROOT
ROOT_UID=0

#codice errore se nn root
E_NONROOT=67

if [ “$UID” -ne “$ROOT_UID” ]
then
echo “Devi essere root….”
exit $E_NONROOT
fi

if [ -n “$1” ]
then
NUMERO=$1
else
NUMERO=$DEFAULTMIN
echo “Uso: `basename $0` numero_minuti [DEFAULT 1440]”
fi

#Linea per far puntare la variabile ACCESSLOGTMPFILE al file access.log originale
ACCESSLOGTMPFILE=’/var/www/htdocs/web/logs/web-access.log’

LIMITE=$NUMERO
for ((i=1; i <= LIMITE; i++)) do CONFRONTO=`date --date="$i minutes ago" +"%d/%b/%Y:%R"` printf $CONFRONTO printf "\t" grep $CONFRONTO $ACCESSLOGTMPFILE |wc -l done exit 0

Posted in Apache, Bash, Linux at August 23rd, 2006. No Comments.

Configurazione Pound Debian

Esempio di configurazione di pound per il load balancing/reverse proxy del webserver apache su Debian Sarge.
Ipotizzando di dover mettere in produzione dei servizi web per un totale di macchine (eterogenee o non) che supera nettamente il nostro range di ip pubblici pound si rivela uno strumento eccezionale.

#apt-get install pound

Il file di configurazione da modificare è /etc/pound/pound.cfg

Nell’esempio sottostante si fa riferimento ad una situazione composta da 4 macchine di back-end di cui 2 mirror a carico bilanciato

User    www-data
Group  www-data
ExtendedHTTP   0
WebDAV  0
LogLevel 3
Alive 10
ListenHTTP  xxx.xxx.xxx.xxx,80
######FOO########
UrlGroup ".*"
HeadRequire Host ".*foo.texilee.it*"
Session IP 300
BackEnd 10.10.10.10,80,9
EndGroup
######BAR########
UrlGroup ".*"
HeadRequire Host ".*bar.texilee.it*"
Session IP 300
BackEnd 10.10.10.13,80,9
EndGroup
###### Load Balancing########
UrlGroup ".*"  Session IP 300
BackEnd 10.10.10.15,80,9
BackEnd 10.10.10.25,80,1
EndGroup
Posted in Apache, Linux at July 26th, 2006. No Comments.

Advanced Bash Apache IDS part1

Esistono innumerevoli sistemi IDS, molti a pagamento, molti con funzionalità totalmente inutili, alcuni troppo “permissivi” e proporzionalmente altri troppo “aggressivi”.
In questo articolo, primo di una lunga serie tempo permettendo, cerco di mostrarvi le tecniche per costruirsi le basi per mettere in piedi un IDS casalingo utilizzando gli strumenti che bash ci offre.

Potrebbe essere un ottimo esercizio mirato ad affinare le tecniche di scripting bash, vi ricordo che potet raggiungere lo stesso obiettivo con altri linguaggi stile php / perl ma quasi sicuramente otterrete a parità di risultati un utilizzo più massiccii in termini di cpu.

Iniziamo con il postprocessing dell’analisi del file access.log di apache con l’opzione “combined”

Lo scopo è avere a portata di mano una utility che ci permetta al volo di capire quali determinati IP hanno effettuato richieste verso il nostro sito.

awk '{print $1}' /var/log/apache/access.log

Possiamo contare il numero di hits totale

awk '{print $1}' /var/log/apache/access.log|wc -l

e passare a qualcosa di più utile: ordinamento e conteggio

awk '{print $1}' /var/log/apache/access.log|
sort|uniq -c|sort

Sono bastati un paio di comandi per fare qualcosa che via php/perl (senza usare CPAN!) vi sarebbe costato qualche ciclo… ora togliamo anche le “” virgolette che contornano l’indirizzo IP

awk '{print $1}' /var/log/apache/access.log|
sort|uniq -c|sort|sed s/\"//g

Se volessimo sapere quante sono in tutto le richieste e ip unici aggiungiamo un awk

awk '{print $1}' /var/log/apache/access.log|
sort|uniq -c|sort|sed s/\"//g|
awk '{print $0;tot+=1;sum+=$1}
END {print "HITS: "sum "|IP: " tot}'

Lo script è “corto” quanto basta per essere ancora scritto a video e richiamato via history e relativo !ID_CMD. Ovviamente ha le sue limitazioni in quanto la funzionalità è relativa ai settaggi del vostro logrotate. Nel prossimo articolo inserirò il metodo per potere parsare solo gli ultimi X minuti del file access.log e rendere lo script più performante nella sintassi

./hits ARG1

Posted in Apache, Bash, Linux at July 21st, 2006. No Comments.

Hardening Debian Linux LAMP Servers

Hardening Debian Linux Web PHP Servers

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.

Posted in Apache, Linux, Mysql, Php at June 30th, 2006. No Comments.

Apache 1.3 stato dei processi figli script PHP

Apache 1.3 su Unix è un server Web basato su processi. Il programma Apache, al suo avvio, genera (fork) svariati processi figli; con il fork un processo primario genera copie identiche di se stesso, chiamate figli. Ognuno di tali figli può servire una richiesta indipendente dalle altre, con il vantaggio di migliorare la stabilità: se uno di tali figli ha un comportamento anomalo (va fuori controllo o ha perdite di memoria) può essere interrotto senza alcun effetto sugli altri. La stabilità è conseguita a spese delle prestazioni. Nella maggior parte dei sistemi Unix, la creazione di processi e il cambiamento del contesto (assegnazione di tempo del processore a ogni processo) sono operazioni costose in termini di risorse di sistema, dal momento che i processi sono isolati gli uni dagli altri e non possono quindi facilmente condividere codice e dati. [www.pluto.it]

Per controllare lo “stato” di ognuno dei processi figli di apache via php si può utilizzare questo semplice script, la consultazione dello stato dei processi risulta estremamente rapida.

<?php echo "<h3>Apache Forked Status Viewer< /h3>"; $cmd = '/bin/ps --User www-data -o \'%p %C\''; exec($cmd,$status); foreach ($status as $val) echo '<br />'.$val; ?>
Posted in Apache, Linux, Php at June 9th, 2006. No Comments.