Certificats SSL pour Apache avec Let’S Encrypt

Adminstration Server Linux, Debian, Sécurité No Comments »

Petit « How-to » pour l’installation de certificats SSL Let’s Encprypt pour Apache.
On install Git pour pouvoir récupérer l’environnement Let’S Encrypt

git clone https://github.com/letsencrypt/letsencrypt

On install ensuite l’environement

git clone https://github.com/letsencrypt/letsencrypt

On coupe temporairement Apache

service apache stop

On lance ensuite la commande

cd letsencrypt
./letsencrypt-auto certonly --standalone -d www.mondomaine.be --email moi@mondomaine.be --agree-tos

Il faut ensuite reconfigurer le vhost en ajoutant/remplaçant les lignes suivante

SSLEngine on
SSLProtocol -all -SSLv3 +TLSv1.2
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

SSLCertificateFile /etc/letsencrypt/live/www.mondomaine.be/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mondomaine.be/privkey.pem

On relance finalement apache

service apache2 restart && service apache2 status

Utiliser un partage SMB avec Samba et des permissions Active Directory

Adminstration Server Linux, Adminstration Server Windows, Debian, Sécurité 1 Comment »

Avec ce mémo, vous allez mettre en place un partage SMB à l’aide de Samba tout en utilisant authentification et les permissions de votre domaine Active Directory
Le serveur Samba tourne sur Debian 6.0 et le DC sur Windows Server 2008 R2

Installation des paquets

Avant d’installer assurez-vous d’avoir un serveur à jour

aptitude update && aptitude safe-upgrade

Ensuite installez les paquets suivant

aptitude install samba winbind krb5-user libkrb53 ntpd ntpdate

Heure du serveur

Avant de commencer il est primordial de synchroniser l’heure du serveur sur le DC notament pour l’authentification kerberos

/etc/.init.d/ntp stop
vi /etc/ntp.conf

Configurez la ligne server avec l’ip de votre DC

ntpdate 
/etc/.init.d/ntp start

Configuration de Kerberos

vi /etc/krb5.conf

Attention respectez scrupuleusement les majuscules ( à adapter : DOMAINE.COM, server_dc1, domaine, DOMAINE)

[libdefaults]
	default_realm = DOMAINE.COM
	clock_skew = 300
	ticket_lifetime = 24000
	default_tkt_enctypes = des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc
	default_tgs_enctypes = des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc
	dns_lookup_realm = false
	dns_lookup_kdc = true
[realms]
	DOMAINE.COM = {
		kdc = server_dc1
		admin_server = server_dc1
		default_domain = DOMAINE.COM
	}
[domain_realm]
	.domaine = DOMAINE
	domaine = DOMAINE

Configuration de Samba

vi /etc/samba/smb.conf
[global]
	netbios name = srv-shares
	workgroup = DOMAINE
	server string = Backup Server
	realm = DOMAINE.COM
	security = ADS
	encrypt passwords = true
	password server = server_dc1.domaine.com
	idmap uid = 10000-20000
	idmap gid = 10000-20000
	winbind enum groups = yes
	winbind enum users = yes
	winbind use default domain = yes

[shares]
	path = /home/shares
	comment = shares
	writable = yes
	browseable=yes
	read only = no
	inherit acls = yes
	inherit permissions = yes
	create mask = 700
	directory mask = 700
	valid users = @"DOMAINE+Domain Users"
	admin users = @"DOMAINE+Domain Admins"

Configuration de nsswitch

Pour que Samba puisse utiliser les utilisateurs et groupes de l’AD, il faut configurer nsswitch afin de lui ajouter Winbind comme possibilité d’authentification

vi /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Redémarrage des services

/etc/init.d/winbind stop && /etc/init.d/samba restart && /etc/init.d/winbind start

Jonction à l’Active Directory

net join -U Administrator

Ensuite pour tester

kinit administrator
klist
wbinfo -u
wbinfo -g

Vous pouvez à présent configurer les permissions avec les commandes habituelles.

chown DOMAINE\user1 repdeuser1
chgrp DOMAINE\groupe1 repdegrp1

Installation et configuration du mod_security pour apache2 sous Debian

Adminstration Server Linux, Debian, Sécurité 14 Comments »

Le module Security est une sorte de firewall pour Apache qui apporte une solution aux problèmes de sécurité et d’attaques applicatives web. En effet, malgrés le déploiement de mesures de sécurité élevées sur un serveur web, il est toujours possible qu’une simple erreur de programmation dans un script « cgi » ou « php » mette en péril l’intégrité et la confidentialité des données stockées.
Pour faire simple ce module bloque les requêtes pouvant être dangereuses.
Exemple en image :

modsecurity

Installation.

Ce module n’est pas installé de base avec Apache, je vais vous proposer deux méthodes à vous de choisir la votre :
L’installation par la commande dpkg est très simple, wget doit être installé sur votre système.

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/mod-security-common_2.5.9-1_all.deb
wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/libapache-mod-security_2.5.9-1_i386.deb

Installation du paquet :

dpkg -i mod-security-common_2.5.9-1_all.deb libapache-mod-security_2.5.9-1_i386.deb

Voila le module est installé. Maintenant on active ce dernier auprès d’Apache.

 a2enmod mod-security

L’installation du module Security est terminée

Configuration

La configuration du module Security consiste dans sa plus grande partie à ajouter des règles “de filtrage”.
Ces règles sont séparées en plusieurs fichiers (blacklist, proxy, règles de bases, rootkits, etc…).
On créé un répertoire modsecurity2 dans le répertoire /etc/apache2/, on se place dedans et on télécharge les règles.

mkdir /etc/apache2/modsecurity2/
cd /etc/apache2/modsecurity2/
wget http://www.gotroot.com/downloads/ftp/mod_security/2.0/apache2/apache2-gotrootrules-modsec2.0-latest.tar.gz

Une fois le téléchargement terminé nous allons décompresser l’archive contenant les règles.

tar zxvf apache2-gotrootrules-modsec2.0-latest.tar.gz

Puis créez un fichiers nommé mod_security pour y ajouter les lignes suivantes :

vi /etc/apache2/conf.d/mod_security
# A adapter en fonction de la version du module qui est utilisé.


# Analyse uniquement les requêtes dynamiques.
#SecFilterEngine DynamicOnly

# Active le filtrage.
SecFilterEngine On

# Rejette les requêtes ayant le status 500.
SecFilterDefaultAction "deny,log,status:500"

# Quelques règles de bases.
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckCookieFormat On
SecFilterCheckUnicodeEncoding Off
SecFilterNormalizeCookies On
# Active la version 1 (RFC 2965) cookies
SecFilterCookieFormat 1

# Ne donne aucune précision sur le serveur web.
SecServerResponseToken Off

# Scanner le flux de sortie.
#SecFilterScanOutput On
#SecFilterOutputMimeTypes "(null) text/html text/plain"

# Autorise presques toutes les valeurs de bytes.
SecFilterForceByteRange 1 255

# Masquer le serveur.
#fake server banner - NOYB used - no one needs to know what we are using
SecServerSignature "NOYB"

#SecUploadDir /tmp
#SecUploadKeepFiles Off

# Only record the interesting stuff
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log

# Configuration du module de debuggage.
SecFilterDebugLevel 0
SecFilterDebugLog /var/logs/apache2/modsec_debug_log

# Règles d'exlusion.
# Cette ligne doit rester devant les autres.
Include /etc/apache2/modsecurity2/exclude.conf

# Règles de protections.
Include /etc/apache2/modsecurity2/rules.conf

# Règles dédiées au spam.
Include /etc/apache2/modsecurity2/blacklist.conf

# Règles de filtrage des hotes, proxy, etc...
Include /etc/apache2/modsecurity2/blacklist2.conf

# Règles interdisant certains client, robots, etc...
Include /etc/apache2/modsecurity2/useragents.conf

# Protection contre les rootkits.
Include /etc/apache2/modsecurity2/rootkits.conf

# Règle empéchant l'utilisation du serveur comme proxy.
# A utiliser seulement si le serveur n'est pas en mod proxy.
Include /etc/apache2/modsecurity2/proxy.conf

# Quelques règles de plus, uniquement pour Apache2.
Include /etc/apache2/modsecurity2/apache2-rules.conf

La configuration du module est terminé, il ne reste plus qu’a relancer Apache.

/etc/init.d/apache2 restart

Mise à jour des règles.

Un script a été conçu pour permettre le téléchargement des nouvelles règles automatiquement.
Cette méthode nécessite l’ajout d’une tâche dans votre crontab.

Dans le répertoire /etc/cron.d/ nous allons créer un fichier modsecurity contenant ceci :

vi /etc/cron.d/modsecurity
# Tout les jours à 5h30 du matin.
30 5 * * * /etc/apache2/modsecurity2/modsec.sh

Ce script bash a été adapté pour une distribution Debian, il aura pour nom modsec.sh et sera placé dans /etc/apache2/modsecurity2/

vi /etc/apache2/modsecurity2/modsec.sh
#!/bin/sh

# Autoupdater for modsec rulesets.
 #
 # This script will attempt to update your rulefiles, and restart apache.
 # If it apache does not start after changing rules, it will roll back to
 # the old ruleset and restart apache again.
 #
 # Version: $Id: modsec.sh,v 1.1 2005/06/29 18:07:53 olei Exp $
 # URL: http://cs.evilnetwork.org/cycro
 # Copyright 2005, All Rights Reserved

APACHESTART="/usr/sbin/apache2ctl start"
 MODSECPATH="/etc/apache2/modsecurity2 "
 APACHEPID="/var/run/apache2.pid"

##########################################################################
 ######### you probably don't need to change anything below here ##########
 ##########################################################################

# urls
 BLACKLIST="http://www.gotroot.com/downloads/ftp/mod_security/blacklist.conf"
 RULES="http://www.gotroot.com/downloads/ftp/mod_security/rules.conf"
 APACHE2="http://www.gotroot.com/downloads/ftp/mod_security/apache2-rules.conf"

# internal
 PID=`cat ${APACHEPID}`
 UPDATED=0

echo -n "Changing PWD: "
 cd ${MODSECPATH}
 echo `pwd`

# blacklist
 echo -n "Updating blacklist.conf: "
 /usr/bin/wget -t 30 -O blacklist.conf.1 -q ${BLACKLIST}
 if [ `md5sum blacklist.conf | cut -d " " -f1` != `md5sum blacklist.conf.1 | cut -d " " -f1` ] ; then
 /bin/mv blacklist.conf blacklist.conf.bak
 /bin/mv blacklist.conf.1 blacklist.conf
 UPDATED=`expr $UPDATED + 1`
 echo "ok."
 else
 echo "allready up to date."
 /bin/rm -f blacklist.conf.1
 fi

# rules
 echo -n "Updating rules.conf: "
 /usr/bin/wget -t 30 -O rules.conf.1 -q ${RULES}
 if [ `md5sum rules.conf | cut -d " " -f1` != `md5sum rules.conf.1 | cut -d " " -f1` ] ; then
 /bin/mv rules.conf rules.conf.bak
 /bin/mv rules.conf.1 rules.conf
 UPDATED=`expr $UPDATED + 1`
 echo "ok."
 else
 echo "allready up to date."
 /bin/rm -f rules.conf.1
 fi

# apache2 rules
 echo -n "Updating apache2-rules.conf: "
 /usr/bin/wget -t 30 -O apache2-rules.conf.1 -q ${APACHE2}
 if [ `md5sum apache2-rules.conf | cut -d " " -f1` != `md5sum apache2-rules.conf.1 | cut -d " " -f1` ] ; then
 /bin/mv apache2-rules.conf apache2-rules.conf.bak
 /bin/mv apache2-rules.conf.1 apache2-rules.conf
 UPDATED=`expr $UPDATED + 1`
 echo "ok."
 else
 echo "allready up to date."
 /bin/rm -f apache2-rules.conf.1
 fi

# try restart
 if [ "$UPDATED" -gt "0" ]; then
 echo -n "Restarting apache: "
 /bin/kill -HUP ${PID} 2>/dev/null
 # did it work?
 if `/bin/kill -CHLD ${PID} >/dev/null 2>&1`; then
 echo "ok."
 exit 0
 fi
 echo "error. Apache not running."

# blacklist
 echo -n "Rolling back blacklist.conf: "
 /bin/mv blacklist.conf blacklist.conf.new
 /bin/mv blacklist.conf.bak blacklist.conf
 echo "ok."

# rules
 echo -n "Rolling back rules.conf: "
 /bin/mv rules.conf rules.conf.new
 /bin/mv rules.conf.bak rules.conf
 echo "ok."

# apache2 rules
 echo -n "Rolling back apache2-rules.conf: "
 /bin/mv apache2-rules.conf apache2-rules.conf.new
 /bin/mv apache2-rules.conf.bak apache2-rules.conf
 echo "ok."

# try starting httpd again
 `${APACHESTART}`
 PID=`cat ${APACHEPID}`

# did that fix the problem?
 if `/bin/kill -CHLD ${PID} >/dev/null 2>&1`; then
 echo "That did the trick."
 exit 0
 fi

echo "Fatal: Apache still not running! Run apache2ctl -t to find the error."
 exit 999
 fi

Il faut rendre ce script exécutable.

chmod +x /etc/apache2/modsecurity2/modsec.sh

Plugins Fail2Ban pour Munin

Adminstration Server Linux, Sécurité 14 Comments »

Ne trouvant pas mon bonheur parmi les plugins munin pour fail2ban j’ai décidé de l’écrire moi même. Le plugins s’adapte automatiquement à votre fail2ban car il récupère les jails activées.

On crée le fichier /usr/share/munin/plugins/fail2ban et on le remplit le avec le code ci-dessous

#! /bin/bash

PROGNAME=fail2ban
STATEDIR=/var/lib/munin/plugin-state
LISTJAIL=$(fail2ban-client status | grep " Jail list:" | sed 's/`- Jail list:\t\t//g' | sed 's/,//g')

if [ "$1" = "config" ]
then
 echo 'system.type ABSOLUTE'
 echo 'graph_title Fail2ban'
 echo 'graph_vlabel Number of ban'
 echo 'graph_category Security'
 for f  in $LISTJAIL; do
 echo "$f.label $f"
 done
 exit 0
fi

for f  in $LISTJAIL; do
 echo "$f.value $(fail2ban-client status $f | grep " Currently banned:" | sed 's/   |- Currently banned:\t//g')"
done

Ensuite on active le plugins en créant le lien symbolyque

ln -s /usr/share/munin/plugins/fail2ban /etc/munin/plugins/

Il faut également élever les privilèges de munin pour qu’il puisse utiliser fail2ban

vi /etc/munin/plugin-conf.d/munin-node

On ajoute à la fin :

[fail2ban]
user root

On termine on redémarrant munin

/etc/init.d/munin-node restart

Et vous devriez avoir après quelques jours un graphique semblable 🙂

Graph Munin Fail2ban

Graph Munin Fail2ban

Configurer SSH via un jeu de clé privée/publique

Adminstration Server Linux, Sécurité No Comments »

Dans ce mémo j’expliquerais comment générer un jeu de clé avec PuttyGen et comment l’installer sur le server afin que le user ROOT ne puisse se connecter qu’avec un jeu de clé.

A télécharger si vous ne les avez pas encore Putty et PuttyGen sur PuTTY Download Page

Génération d’une paire de clés (privée/publique) avec PuTTYGen

On commence par lancer PuTTYGen, choisir le type de clé à générer SSH-2 RSA, et la longueur de la clé 1024 bits. On clique ensuite sur le bouton Generate, il faut faire bouger la souris dans la fenêtre de PuTTY Key Generator de façon aléatoire, et c’est ce mouvement aléatoire qui va servir à générer la clé.

puttygen

Une fois la clé générée , on doit arriver à quelque chose ressemblant à ça :

puttygen2

On commence par remplir le champ passphrase afin d’avoir encore un peu de plus de sécurité. Ainsi, même si quelqu’un avait accès à notre clé privée, il lui faudrait le mot de passe pour s’en servir. On peut maintenant sauvegarder la clé publique et la clé privée; pour la clé publique on peut lui affecter l’extension que l’on veut, mais on prend généralement .pub, et on peut largement diffuser cette clé, alors que pour la clé privée, ce sera l’extension .ppk, et cette clé DOIT rester confidentielle.
Attention : laissez ouvert votre PuTTYGen ouvert, afin d’avoir la clé à copier/coller sous la main.

Enregistrement d’une session dans Putty

On va maintenant ajouter la configuration d’une session vers un serveur dans putty. Pour cela, ouvre Putty. On renseigne les champs hostname, Saved Session,  l’encodage des caractères dans Window > Translation (puisque la plupart des serveurs sont en UTF-8 alors que PuTTY est en ISO par défaut), etc. Pour gagner encore un peu de temps lors de chaque connexion, on peut rentrer le nom d’utilisateur dans Connection > Data, au champ auto-login username.

putty

On peut maintenant retourner dans Session, enregistrer notre session sous le nom que l’on veut, et, enfin, ouvrir la connexion en cliquant sur Open.

Ajout de la clé publique sur le serveur Linux

La première connexion au serveur se déroule comme d’habitude, il faut rentrer notre mot de passe. Une fois cette tâche effectuée, on va éditer le fichier /root/.ssh/authorized_keys, et on va copier/coller notre clé publique dans ce fichier (n’hésitez pas à créer le répertoire et le fichier s’ils n’existent pas). On retourne sur la fenêtre de PuTTYGen, et on copie/colle la clé. Si jamais vous aviez fermé bêtement la fenêtre de PuTTYGen, vous pouvez rouvrir le logiciel, et charger votre clé privée grâce au bouton load. Il faut respecter simplement le fait de placer une seule clé par ligne dans le fichier /root/.ssh/authorized_keys.

Configuration de OpenSSH

Il faut configurer le serveur ssh pour qu’il n’autorise que l’accès par clé y compris pour root. On passe les options suivantes dans /etc/ssh/sshd_config

PermitRootLogin without-password
AllowUsers toto root
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no

Il faut ensuite redémarrer le sshd

/etc/init.d/ssh reload

On peut désormait se loguer en root en utilisant uniquement un jeu de clé.

Installation du mod evasive sur apache 2.2 pour contrer des attaques DOS

Adminstration Server Linux, Sécurité 8 Comments »

Cette après midi après plusieurs test de charge du serveur Web, je me suis rendu compte que c’était un jeu d’enfant de faire planter à la fois le apache mais aussi la machine.

Comment me direz-vous, tous simplement en flood le serveur de centaine de thread, la charge CPU monte la ram aussi, vient ensuite le tour de la swap et puis c’est la fin, le serveur ne répond plus à rien sauf au ping.

htop

Après quelque recherche j’ai installé le mod_evasive qui permet de détecter les floods et les tentatives de déni de service.  Ce module renvoie des erreurs HTTP 403 lorsque le seuil de sollicitation du serveur Web par IP a été dépassé. Ce blocage dure pendant 10 secondes (paramétrable). Il est aussi possible de demander au module d’exécuter une commande lorsque qu’un flood est détecté, il est ainsi possible d’ajouter une règle Iptables à chaque nouvelle détection de flood.

apt-get install libapache2-mod-evasive

On édite le fichier de configuration d’apache2 et on ajoute les lignes suivante :

vi /etc/apache2/apache2.conf
# mod_evasive


DOSHashTableSize 3097
DOSPageCount 3
DOSSiteCount 50
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 300
DOSEmailNotify "admin@majorxtrem.be"
DOSLogDir "/var/log/mod_evasive/"
#DOSSystemCommand "/sbin/iptables -I INPUT -s %s -j DROP"
DOSSystemCommand "/bin/echo %s >> /var/log/mod_evasive/dos_evasive.log && /bin/date >> /var/log/mod_evasive/dos_evasive.log"
DOSWhiteList 127.0.0.1
DOSWhitelist 66.249.65.*
DOSWhitelist 66.249.66.*
DOSWhitelist 66.249.67.*

Les valeurs données dans cette exemple sont à adapter selon votre serveur.

Explications :

DOSHashTableSize Size of the hash table. The greater this setting, the more memory is required for the look up table, but also the faster the look ups are processed. This option will automatically round up to the nearest prime number.
DOSPageCount définie le nombre de fois ou une page peut être appelée par la même adresse IP avant que celle-ci soit bloquée.
DOSSiteCount définie le nombre de fois ou un site peut être demandé par la même adresse IP avant que celle-ci soit bloquée.
DOSPageInterval détermine un interval en seconde qui autorise l’affichage de la même page avant un bloquage.
DOSSiteInterval détermine un interval en seconde qui autorise l’affichage de d’un même site avant un bloquage.
DOSBlockingPeriod détermine la durée de bloquage.
DOSEmailNotify permet qu’un email soit envoyé à chaque bloquage d’adresses IP.
DOSSystemCommand permet de définir une commande bien précise en cas d’attaque (bannissement de l’adresse IP dans IPTables par exemple).
DOSLogDir détermine le chemin ou seront stockés les logs d’attaques.
DOSWhiteLt définie une liste blanche d’adresse IP.

DOSSystemCommand "/sbin/iptables -I INPUT -s %s -j DROP"

Cette commande permet de bloquer une adresse IP à l’aide d’IPTable.
Cependant l’utilisation de DOSSystemCommand doit être prise au sérieux car en cas d’attaques massives l’instruction déterminée entre ”“ sera répétée autant de fois qu’il faut.

Pour que l’adresse IP soit ajoutée à IPTables il est nécessaire que l’utilisateur “www-data” ait les droits pour manipuler IPTables

On crée le dossier /var/log/mod_evasive/ et on lui donne les bon droits

mkdir /var/log/mod_evasive/
chown -R www-data /var/log/mod_evasive/

On charge le module

a2enmod mod-evasive

On termine en redémarrant apache

/etc/init.d/apache2 restart

On va maintenant tester la configuration à l’aide d’un petit script perl mais il faut avant tous commenter temporairement la ligne DOSWhiteList 127.0.0.1 et redémarrer apache

vi test.pl
#!/usr/bin/perl

# test.pl: small script to test mod_dosevasive's effectiveness

use IO::Socket;
use strict;

for(0..100) {
  my($response);
  my($SOCKET) = new IO::Socket::INET( Proto   => "tcp",
                                      PeerAddr=> "127.0.0.1:80");
  if (! defined $SOCKET) { die $!; }
  print $SOCKET "GET /?$_ HTTP/1.0nn";
  $response = <$SOCKET>;
  print $response;
  close($SOCKET);
}

On le rend exécutable

chmod +x test.pl

Et on le lance

./test.pl

Code Source & Résultat

Votre serveur apache est désormais capable de réagir sur des attaques DOS

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Connexion
ipv6 ready