Archives de catégorie : Apache

Masquer les versions apache et php

Indiquer la version du serveur Apache ainsi que la version PHP peut aider des personnes malveillantes à tenter de les exploiter afin de trouver une faille éventuelle de sécurité.

Pour masquer la version Apache, il suffit ajouter ServerTokens Prod dans le fichier /etc/apache2/conf.d/security parfois /etc/apache2/apache2.conf

Pour masquer la version de PHP, il faudra mettre à off la directive expose_php = Off dans le fichier php.ini.

Mise à jour sécurité – Debian 6

Pour corriger les failles de sécurité découvertes entre autre sur Bash, il faut ajouter les dépôts squeeze-lts dans le fichier sources.list

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

Ceci permettra de corriger apache, php, fail2ban, libssl…

Protéger l’accès à l’interface d’administration de WordPress

Je constate de plus en plus de tentatives de connexion sur l’interface d’administration de mon WordPress.

Plus étrange encore, depuis plusieurs mois la même adresse IP essaie de se connecter sur le wp-login.php, j’ai résolu le problème en mettant une règle iptables. Il s’agit peut-être d’un robot, mais bon qui essaie de se connecter avec une demande de login/pass, c’est plutôt louche. Le problème reste toujours présent pour des tentatives de connexion d’internautes malveillants. Il existe des plugins disponibles avec WordPress, mais il suffit d’une faille de sécurité dans le plugin en question et c’est encore pire.

Dans les logs d’apache, on voit que l’accès au fichier se fait de façon directe, comme le fait de tapez l’url directement dans la barre d’adresse du navigateur.

xxx.xxx.xxx.xxx - - [09/Nov/2012:21:52:00 +0100] "POST /wp-login.php HTTP/1.1" 200 3684 "-"

La solution que j’ai mis en place, c’est de refuser les accès directs, en utilisant le referer. Pour cela je dis que l’accès au fichier wp-login.php ne peut se faire que si le referer est www.mbardot.com, ce qui revient à cliquer sur le lien connexion de la page d’accueil de WordPress. Je mets le referer  dans une variable d’environnement et j’interdis tout le monde sauf www.mbardot.com. Je combine tout cela avec la protection par .htaccess. Dans mon cas la protection est mise dans le vhost d’apache. Cette protection n’est bien sûr pas limité uniquement à WordPress, il suffit de l’adapter à ses besoins.

Ps: il faut que le mod env d’apache soit chargé.
/etc/apache2/mods-enabled/env.load

Pour la config c’est par là.

SetEnvIf Referer "^http://www.domaine.autorisé/" protection_wordpress
<Directory "/repertoire/du/wordpress/">
<files wp-login.php>
Order Deny,Allow
Deny from all
Allow from env=protection_wordpress
</files>
</Directory>

Un petit reload d’apache et c’est tout bon.

[Sat Nov 10 14:15:18 2012] [error] [client xxx.xxx.xxx.xxx] client denied by server configuration: /chemin/vers/fichier/wp-login.php

squirrelmail + courier-imap sur debian sarge

Squirrelmail est un webmail, qui comme tout webmail permet de consulter et envoyer des mails de partout dans le monde
Il suffit pour cela d’une connexion internet. Pour pouvoir utiliser squirrelmail, il faudra installer le démon : courier-imap

1) Installation de courier-imap

apt-get install courier-imap

2) Installation de squirrelmail.
On récupère les sources sur le site officiel: http://www.squirrelmail.org/

wget http://ovh.dl.sourceforge.net/sourceforge/squirrelmail/squirrelmail-1.4.4.tar.gz

3) Configuration de squirrelmail.

Placer les scripts de squirrelmail dans un répertoire accessible par le web, par exemple http://mon_domaine.com/squirrelmail/
Lire le fichier INSTALL.
Se rendre ensuite dans le répertoire « config » de squirrelmail et lancer la configuration.

./conf.pl

Renseigner les différents champs.
Si vous souhaitez la langue française, il faudra choisir les locales fr_FR et télécharger les locales.
A télécharger ici:

wget http://ovh.dl.sourceforge.net/sourceforge/squirrelmail/fr_FR-1.4.4-20050308.tar.gz

décompresser le paquet, et lancer le script: ./instal
Le script ne fait que déplacer les fichiers dans le bon répertoire de squirrelmail.
Il est conseillé de tester la conf:

http://mon_domaine.com/squirrelmail/src/configtest.php

4) Finalisation de l’installation.

Il reste encore à installer le module d’authentification authvchkpw (cause qmail/vpopmail)
Modifier la ligne suivante comme ceci.

vi /etc/courier/imapd
AUTHMODULES= »authvchkpw »

Le problème est qu’avec la debian sarge le paquet n’est pas installé, les dépendances ne sont pas satisfaites.
Celui de la woody fonctionne parfaitement:
On récupère le paquet et on l’installe.

wget http://packages.dotdeb.org/dists/woody/courier-authvchkpw/
courier-authvchkpw_0.37.3-7.dotdeb.1_i386.deb
dpkg -i courier-authvchkpw_0.37.3-7.dotdeb.1_i386.deb
/etc/init.d/courier-imap restart

Un petit test:
http://mon_domaine.com/squirrelmail/src/login.php

Ming sous Fedora Core 4

Ming ne semble pas être disponible sous la Fedora Core 4

Pour info la librairie Ming permet de générer des documents flash à la volée via des scripts php.

Pour le faire fonctionner, j’ai récupéré les modules sous debian sarge
Copie de :

========== Debian ========= | ======= Fedora Core 4 =========
cp /usr/lib/php5/20041030/ming.so | /usr/lib/php/modules/ming.so
cp /usr/lib/libming.so.0.3beta1        | /usr/lib/libming.so.0.3beta1
cp /usr/lib/libungif.so.4.1.3              | /usr/lib/libungif.so.4.1.3

Ensuite : sous Fedora.

cd /usr/lib
ln -s /usr/lib/libming.so.0.3beta1 libming.so.0
ln -s /usr/lib/libming.so.0 libming.so
ln -s /usr/lib/libungif.so.4.1.3 libungif.so.4

Pour php :

création du fichier /etc/php.d/ming.ini

; Enable ming extension module vient de debian
extension=ming.so

Restart d’apache : /etc/init.d/httpd restart

Pour voir : un bout du phpinfo()

En cadeau : Deux swf générés à la volée, les scripts ne sont pas de moi, pour le code c’est par ici.
http://www16.brinkster.com/gazb/ming/

Ils sont très connus: sokoban et invaders

suPHP 0.6.0 compilation et installation

La compilation de la nouvelle version de suPHP (0.6.0) semble poser quelques soucis.

Avec les sources d’origine on obtient une erreur à la compilation, pour éviter cette erreur il faut modifier le fichier source: src/apache2/Makefile.in

Info sur http://lists.marsching.biz/pipermail/suphp/2005-June/000840.html

Before doing ./configure i added « -I/usr/include/apr-0 » to AM_CFLAGS
(line 96 src/apache2/Makefile.in) then i did:
./configure –with-apache-user=apache –with-apxs=/usr/sbin/apxs2
make

And it compiles!

Ofcorse this is not a good solution, but with the little C experience i have it is the best i can come up with 🙁 sorry.

Gr. Steven

Après cette modif le ./configure, le make ne plante plus, par contre on obtient une erreur au début.
un apt-get install automake et tout se passe bien.
le make install semble se faire correctement par contre, lorsque l’on veut exécuter un script php, le navigateur ne reconnait pas le type mime et veut télécharger le fichier.

Dans la doc comprise dans le tarball, une nouvelle directive fait son apparition: suPHP_AddHandler à rajouter dans la conf apache
Mais pour pouvoir être reconnu par apache, il faudra modifier le script
src/apache2/mod_suphp.c ligne 316 et 317
RSRC_CONF | ACCESS_CONF au lieu de ACCESS_CONF

Bon, on recommence:

debian:~/suphp-0.6.0# make clean
debian:~/suphp-0.6.0# ./configure –prefix=/usr –with-apxs=/usr/bin/apxs2 –with-setid-mode=paranoid –with-apache-user=www-data –with-php=/usr/bin/php4-cgi –with-logfile=/var/log/apache2/suphp.log

debian:~/suphp-0.6.0# make
Fin du make
make[3]: Leaving directory `/root/suphp-0.6.0/src’
make[2]: Leaving directory `/root/suphp-0.6.0/src’
make[1]: Leaving directory `/root/suphp-0.6.0/src’
make[1]: Entering directory `/root/suphp-0.6.0′
make[1]: Nothing to be done for `all-am’.
make[1]: Leaving directory `/root/suphp-0.6.0′

On se lance:
debian:~/suphp-0.6.0# make install
Making install in src
make[1]: Entering directory `/root/suphp-0.6.0/src’
Making install in apache2
make[2]: Entering directory `/root/suphp-0.6.0/src/apache2′
make[3]: Entering directory `/root/suphp-0.6.0/src/apache2′
make[3]: Nothing to be done for `install-exec-am’.
/usr/bin/install -c -d ‘/usr/lib/apache2/modules’
/usr/bin/install -c -m 0755 .libs/mod_suphp.so ‘/usr/lib/apache2/modules’/mod_suphp.so
make[3]: Leaving directory `/root/suphp-0.6.0/src/apache2′
make[2]: Leaving directory `/root/suphp-0.6.0/src/apache2′
make[2]: Entering directory `/root/suphp-0.6.0/src’
make[3]: Entering directory `/root/suphp-0.6.0/src’
/bin/sh ../config/mkinstalldirs /usr/sbin
/bin/sh ../libtool –mode=install /usr/bin/install -c suphp /usr/sbin/suphp
/usr/bin/install -c suphp /usr/sbin/suphp
make install-exec-hook
make[4]: Entering directory `/root/suphp-0.6.0/src’
chmod u+s /usr/sbin/suphp
make[4]: Leaving directory `/root/suphp-0.6.0/src’
make[3]: Nothing to be done for `install-data-am’.
make[3]: Leaving directory `/root/suphp-0.6.0/src’
make[2]: Leaving directory `/root/suphp-0.6.0/src’
make[1]: Leaving directory `/root/suphp-0.6.0/src’
make[1]: Entering directory `/root/suphp-0.6.0′
make[2]: Entering directory `/root/suphp-0.6.0′
make[2]: Nothing to be done for `install-exec-am’.
make[2]: Nothing to be done for `install-data-am’.
make[2]: Leaving directory `/root/suphp-0.6.0′
make[1]: Leaving directory `/root/suphp-0.6.0′

debian:~/suphp-0.6.0# ls -la /usr/sbin/suphp
-rwsr-xr-x 1 root root 2330978 Jun 24 21:52 /usr/sbin/suphp

Désormais suPHP semble devoir fonctionner avec un fichier de conf
la compil devrait le placer dans /usr/etc/suphp.conf mais il n’en est rien il faudra le faire à la mano.
Pour info un exemple est fourni avec les sources, il suffit d’en faire la copie et de l’adapter.

On essaie:
debian:~/suphp-0.6.0# /etc/init.d/apache2 start
cela ne fonctionne toujours pas.
ajout du suPHP_AddHandler x-httpd-php dans le fichier de conf d’apache

debian:~/suphp-0.6.0# /etc/init.d/apache2 start

Génial ça fonctionne!!!!!! je n’y croyais plus.

Nouvelle version de suPHP 0.6.0

Nouvelle version pour SuPHP 0.6.0. Télechargement du tarball sur le site officiel: http://www.suphp.org/Home.html

Pour rappel, suPHP est un module permettant de faire tourner PHP avec les droits de l’utilisateur et non plus les droits d’apache. Cela procure une plus grande sécurité pour l’exécution des scripts PHP.

Une partie de l’info du site officiel:

suPHP 0.6.0 has been released.
For this release suPHP has been completely rewritten. This in an (incomplete) list of only the most important changes:

* Complete code rewritten now using C++ instead of C
* Automake based build system
* suPHP is now reading its runtime configuration from a file
* Apache 1.3 module completely rewritten – now all modes are supported with Apache 1.3, too
* Support for concurrent use of different PHP version (e.g. 3, 4, 5)

This release was sponsored by Techno-vi – Wanix.
Thanks to the sponsor!

Affichage des accents dans apache Fedora

l’affichage des accents n’est pas correct sous Fedora avec apache. Il faut aller modifier le fichier /etc/httpd/conf/httpd.conf et modifier la ligne AddDefaultCharset

#AddDefaultCharset UTF-8
AddDefaultCharset ISO-8859-1

Ensuite un petit reload d’apache /etc/init.d/httpd reload

Avant la modif :

Après la modif :

Have Fun !!!

Apache 2 + php5 avec suPHP sur Fedora Core 4

Ce document décrit en quelques commandes l’installation d’apache 2, php 5 avec suPHP.

1) Installation d’apache 2

yum install httpd

2) Installation de PHP

yum install php

3) Installation de suPHP

yum install httpd-devel
wget http://www.suphp.org/download/suphp-0.5.2.tar.gz
tar xvzf suphp-0.5.2.tar.gz
cd suphp-0.5.2
./configure –prefix=/usr/local –with-apxs=/usr/sbin/apxs –with-setid-mode=paranoid –with-apache-user=apache –with-php=/usr/bin/php-cgi –with-logfile=/var/log/httpd/suphp_log
make
make install

4) Finalisation des paramètres

le PHP va tourner en CGI et non plus en module d’apache, je renomme le fichier de conf php.conf en php.conf-module

/etc/httpd/conf.d/php.conf devient /etc/httpd/conf.d/php.conf-module

Création du fichier suphp.conf dans /etc/httpd/conf.d/suphp.conf

# suphp.conf
<IfModule mod_suphp.c>
AddHandler x-httpd-php .php .php4 .php3 .php5
suPHP_Engine on
</IfModule>

La compilation de suPHP a dû ajouter la ligne suivante dans /etc/httpd/conf/httpd.conf

LoadModule suphp_module /usr/lib/httpd/modules/mod_suphp.so

Pour faire tourner php en CGI avec suPHP, il faut un utilisateur avec un UID/GID > 100

On ajoute dans /etc/httpd/conf/httpd.conf

# Config pour suphp
suPHP_UserGroup nfsnobody nfsnobody

Dans le répertoire utilisateur: /var/www/html/

Création du script index.php avec les droits

-rw-r–r– 1 nfsnobody nfsnobody 20 jun 16 23:06 index.php

<?php

phpinfo();

?>

Un petit reload d’apache:

/etc/init.d/httpd restart

5) Le résultat

Pas mal, n’est-ce pas….

Apache 2, PHP4 et MySQL 4 sur distribution Ubuntu 5.04

Installation du serveur MySQL.

root@ubuntu:~ # apt-get install mysql-server

Installation d’apache 2

root@ubuntu:~ # apt-get install apache2-mpm-prefork apache2-prefork-dev

Le paquet apache2-prefork-dev nous servira pour installer PHP4 avec suPHP.

Installation de PHP4.

root@ubuntu:~ # apt-get install php4-cgi

Installation de suPHP.

root@ubuntu:~ # wget http://www.suphp.org/download/suphp-0.5.2.tar.gz
root@ubuntu:~ # tar xvzf suphp-0.5.2.tar.gz
root@ubuntu:~ # cd suphp-0.5.2
root@ubuntu:~ # ./configure –prefix=/usr/local –with-apxs=/usr/bin/apxs2 –with-setid-mode=paranoid –with-apache-user=www-data –with-php=/usr/bin/php-cgi –with-logfile=/var/log/apache2/suphp.log
root@ubuntu:~ # make
root@ubuntu:~ # make install

Création des 2 fichiers de conf pour faire tourner php4 en cgi avec suphp

# suphp.conf
<IfModule mod_suphp.c>
AddHandler x-httpd-php .php .php4 .php3 .php5
suPHP_Engine on
</IfModule>

# suphp.load
LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so

Activation des 2 fichiers dans le répertoire /etc/apache2/mods-enabled/

ln -s /etc/apache2/mods-available/suphp.conf .
ln -s /etc/apache2/mods-available/suphp.load .

A la compilation de suphp le chargement du module a été inscrit dans le fichier /etc/apache2/httpd.conf
Il suffit d’en commenter la ligne
C’est presque fini…
suPHP étant compilé en mode paranoid, il faut que les scripts aient un user/group qui se trouve dans le passwd et supérieur à 100.
Pour l’exemple on prendra nobody/nogroup

root@ubuntu:# chown -R nobody.nogroup /var/www/apache2-default/

Il faudra ajouter dans le fichier de conf d’apache2 la ligne suivante:

suPHP_UserGroup nobody nogroup

Redemarrage d’apache 2

/etc/init.d/apache2 restart

Et Bingo!!!

PS: Par défaut la distribution Ubuntu est installée en mode restricted, ce qui fait que les modules curl, gd, mysql etc… sont absents.

Il faudra décommenter les lignes suivantes du fichier /etc/apt/sources.list pour corriger tout ça.

deb http://fr.archive.ubuntu.com/ubuntu hoary universe
deb-src http://fr.archive.ubuntu.com/ubuntu hoary universe

deb http://security.ubuntu.com/ubuntu hoary-security universe
deb-src http://security.ubuntu.com/ubuntu hoary-security universe

Et cette fois-ci c’est bien mieux.

apt-get install php4-curl php4-gd php4-imap php4-ldap php4-mcal php4-mcrypt php4-mysql php4-mhash php4-xslt