## 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()

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

#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

#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

#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

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

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.

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;

?>