Le blog de llaumgui - sécurité

Pimp my Dotclear ;-)

llaumgui — Mon, 21 Apr 2008 22:35:00 +0200

Dotclear est un logiciel simple et léger permettant de créer son blog (comme ici) ou de mettre en place une plateforme de blog pouvant héberger plusieurs blogs comme c'est le cas sur la plateforme de blog de fedora-fr.

Optimiser Dotclear

Utilisation de connexions persistantes

Ludovic en parlait sur son Blog, les connexions persistantes sont à présent directement configurables depuis le fichier config.php de Dotclear :

define('DC_DBPERSIST',true);

Cache statique

Toujours en développement, le plugin staticCache est disponible via le dépôt SVN. Il permet de générer non pas du code php comme le fait le cache de template mais de stocker du code HTML qui sera directement rendu aux visiteurs de votre blog.

Pour l'activer, ça se passe encore dans le fichier config.php

define('DC_SC_CACHE_ENABLE', true );

Sécuriser son Dotclear

La première chose à faire pour sécuriser son Dotclear est de le mettre à jour. En effet, des failles de sécurité ont récemment étaient découvertes.

La gestion des uploads

Si vous êtes le seul à utiliser votre blog, la question se pose moins, mais si d'autres personnes utilisent le système d'upload, ils pourraient très bien envoyer des fichier php sur le serveur et les exécuter. Toujours dans le domaine de la supposition, ces fichiers pourraient permettre d'inclure le fichier config.php et d'en parcourir le contenu, dévoilant ainsi les mots de passe de la connexion à la base de données. Sur un serveur très très mal configuré, ces fichiers pourraient aller jusqu'à lire des fichiers du répertoire /etc/ !

Pas de panique : depuis la révision #1714, Dotclear permet d'exclure des extensions de fichier du gestionnaire de médias et ce via la directive media_exclusion du plugin about:config (plus d'infos).

Empêcher l'upload de fichier php c'est bien, mais empêcher l'exécution de fichier php dans le répertoire public, c'est mieux. Pour cela, on configurera apache :

<Location ~ "public/.*\.php$">

     ForceType text/plain

     RemoveHandler php

</Location>

Remi + Borsalino = php5.2 + MySQL 5 mis à jour

llaumgui — Sun, 20 Jan 2008 18:02:00 +0100

Devant la coupure de service, surement due à une monté en charge de Borsalino, et devant les failles récentes révélées pour php : j'ai décidé de basculer Borsalino sur le dépôt de l'ami Remi Collet qui maintient toujours les packages php et MySQL pour Fedora 6 alias Zod !

On install le dépôt :

root@borsalino ~> wget http://remi.collet.free.fr/rpms/remi-release-6.rpm

root@borsalino ~> rpm -Uvh remi-release-6.rpm

On active le dépôt en passant enabled à 1 :

root@borsalino ~> vim /etc/yum.repos.d/remi.repo

Et on mets à jour :

root@borsalino ~> yum clean all; yum update

[...]

Dependencies Resolved



=============================================================================

 Package                 Arch       Version          Repository        Size 

=============================================================================

Updating:

 mysql                   i386       5.0.45-1.fc6.remi  remi              2.1 M

 mysql-server            i386       5.0.45-1.fc6.remi  remi               10 M

 php                     i386       5.2.5-1.fc6.remi  remi              1.3 M

 php-cli                 i386       5.2.5-1.fc6.remi  remi              2.5 M

 php-common              i386       5.2.5-1.fc6.remi  remi              226 k

 php-eaccelerator        i386       1:0.9.5.2-1.fc6.remi  remi              136 k

 php-gd                  i386       5.2.5-1.fc6.remi  remi              115 k

 php-ldap                i386       5.2.5-1.fc6.remi  remi               33 k

 php-mbstring            i386       5.2.5-1.fc6.remi  remi              1.1 M

 php-mcrypt              i386       5.2.5-1.fc6.remi  remi               28 k

 php-mysql               i386       5.2.5-1.fc6.remi  remi               83 k

 php-pdo                 i386       5.2.5-1.fc6.remi  remi               89 k

 php-pear                noarch     1:1.6.2-1.fc6.remi  remi              400 k

 php-xml                 i386       5.2.5-1.fc6.remi  remi               97 k

Installing for dependencies:

 mysql-libs              i386       5.0.45-1.fc6.remi  remi              1.5 M

 sqlite2                 i386       2.8.17-1.fc6     extras            170 k



Transaction Summary

=============================================================================

Install      2 Package(s)         

Update      14 Package(s)         

Remove       0 Package(s)         



Total download size: 20 M

Pour finir, on peut utiliser mon script pour notifier des mises à jour via yum...

Pourquoi n'ai je pas encore fais de billet sur Fedora 8 ?

llaumgui — Thu, 20 Sep 2007 13:38:00 +0200

Et oui, pourquoi ? La raison est simple et tient en 2 mots : « Kernel Panic ».

En effet, si je compte basculer mon portable dès Fedora 7.92 (Test 3) ; j'ai pour habitude, avant cela, de me monter une installation virtualisée de chaque Fedora de tests et d'en faire une petite revue (comme ce fut le cas pour Fedora 7).
Or mon application de virtualisation préférée, VirtualBox, ne semble pas aimer Fedora 8... J'ai donc entrepris de tester Fedora 7.91 via le Live CD.
Là encore des petits problèmes avec Nautilus ont entamé ma motivation et m'ont empêché de vous livrer une floppée de screenshot.
Vous pouvez cependant voir des captures de Fedora 8 ici.

Ce que je retiens :

Le départ de Diana Fong est largment compensé par la monté en puissance de Máirín Duffy qui nous signe là un thème ultra sobre (pas d'omniprésence du logo), ultra propre bref un must !
Gnome 2.20.
GnomeDB, à voir si je peux m'en servir pour des liens ODBC.
Fedora est déjà l'une des distros les plus sécurisées "out of the box", les GUIs pour SELinux et Setroubleshoot se voient encore améliorés tout comme le GUI pour gérer le firewall qui est tout simplement génial (avez vous encore besoin de FireStarter sous Fedora ???!!!).

Les Dedibox seraient elles plus victimes d'attaques ?

llaumgui — Wed, 12 Sep 2007 23:56:00 +0200

Que ce soit professionnel ou personnel : je gère, à la louche, un parc de 15 serveurs dédiés.
Si je mets de côté les serveurs sous Windows qui sont à eux seuls, à la fois une aberration et une faille de sécurité; je dois m'occuper d'une bonne dizaine de serveurs Linux. Ces serveurs sont variés et tournent sous des Debian Sarge et Etch, des CentOS 5 ou Fedora 5. On peut localiser ce parc par 8 serveurs chez Ikoula et 2 Dedibox.

Après avoir décrit le parc, je vais décrire mes habitudes. Comme je suis conscient que tout le monde il est pas beau et que tout le monde il est pas gentils; j'ai pris l'habitude d'installer fail2ban et logwatch sur mes serveurs.
Le premiers détecte les tentatives d'intrusions par brute force et bloque, pendant une durée X, l'IP de toute personne ayant tenté par 3 fois et sans succès, de se connecter sur un serveur.
Le second est une tâche planifiée qui m'envoie un rapport journalier sur les serveurs.

Maintenant que le décor est planté, ma constatation : Les attaques par brute force ou par tentative d'exploitation de faille CMS ou de forums^[1] sur mes 2 Dedibox sont largement supérieures à celles de mes serveurs chez Ikoula voir même supérieures à l'ensemble de toutes les autres machines.

J'ai ouvert un topic sur le sujet chez Dedibox-news et l'explication qu'il m'a été faite me parait à la fois effrayante et réaliste : à 29€ HT, Dedibox démocratise le dédié et n'importe quel clampin peu s'offrir une box sans aucune compétence en administration. Bilan, les IPs Dedibox auraient une réputation plus facile...

^[1] Erreur 404 représentant des URLs typiques de script répendu tel que phpMyAdmin, joomla ou autres.

fail2ban et l'erreur "Please check the format and your locale settings."

llaumgui — Wed, 25 Apr 2007 22:44:00 +0200

J'avais déjà parlé de fail2ban dans un précédent billet, hors depuis quelque temps, je ne reçoit plus de mail d'alerte de la part de ce scripts... Arrêterait-on de forcer les accès SSH de Borsalino ?
C'est donc en contrôlant les logs (/etc/log/fail2ban.log), que je tombe sur près de 45.000 entrées.

root@borsalino ~> wc -l /var/log/fail2ban.log

45 751 /var/log/fail2ban.log

Un petit cat et je me rends compte d'une ligne récurante :

ERROR: time data did not match format: data=Mar 21 10:00:50 fmt=%b %d %H:%M:%S

ERROR: Please check the format and your locale settings.

Après recherche sur le wiki de fail2ban, et la lecture de la faq, il s'avère que ce message vient d'un bug (#1457620) introduit dans la version 0.6.1, fixé (0.6.2) et du à l'expression régulière en charge de l'analyse des logs.

En effet mon système étant en français (fr_FR), fail2ban s'attend à trouver des logs (/var/log/secure) avec des dates françaises, ce qui n'est pas le cas... Pour cela, comme indiqué dans la faq, il suffit de renseigner la ligne locale dans le fichier de configuration (/etc/fail2ban.conf) :

# Option:  locale

# Notes.:  global (cannot be redefined per section) locale to use for

#          timestamp pattern matching by changing LC_TIME for

#          fail2ban process. Empty entry sets locale to default one

#          (usually specified by LC_ALL environment variable).

# Values:  LOCALE  Default:

#

locale = en_US

Protéger les accès SSH avec fail2ban

llaumgui — Mon, 13 Nov 2006 19:45:00 +0100

Après l'attaque de ce week-end et après une lecture des logs d'accès ssh, je me suis décidé à mettre en place une gestion automatique des bannissements d'IPs.

L'idée est simple : bannir les IPs qui tentent de passer le compte root en "Brut de force".
Il est évident que l'accès root n'est pas autorisé en ssh (PermitRootLogin no) tout comme les mots de passe (PasswordAuthentication no), et que de telles attaques ne peuvent pas aboutir, mais c'est pour le principe ;-).

root@borsalino ~> cat /var/log/secure.1 | grep "Failed password for root" --count

1812

Sur les conseils de Titax, je me suis penché sur fail2ban, mais à la différence de la méthode proposée par Thierry, j'ai préféré utiliser le dépôts dries.

Si vous ne l'avais pas installé, vous en trouverez la config ici.

Pour installer fail2ban :

root@borsalino ~> yum --enablerepo=dries install fail2ban

Une fois le service installé, il faut le configurer, ça ce passe dans /etc/fail2ban.conf, le fichier et très bien documenté vous pourrez y régler le nombre de tentative, la durée du bannissement, les services concernés (ssh mais possibilité de le mettre en place pour apache), et l'envoi de mail lors d'un bannissement.

Ensuite, pour activer le service :

root@borsalino ~> /sbin/chkconfig --add fail2ban

root@borsalino ~> /sbin/service fail2ban start

Première attaque sur Borsalino

llaumgui — Sun, 12 Nov 2006 02:13:00 +0100

Ce soirs Borsalino, le serveur de fedora-fr, a fait une montée en charge impressionnante (85) due aux services httpd et mysqld. Une charge m'obligeant à couper le serveur web pendant 10 minutes le temps d'analyser la situation.

Une fois les logs d'erreur (errors.log) contrôlés, j'ai du me rendre à l'évidence : je code rudement bien et il n'y a rien de ce côté là (Qui a dit que je me jeté des fleurs ;-)).

Mes soupçons ce sont alors portés sur les logs d'accès (acces.log) :

xxx.xxx.xxx.xxx - - [11/Nov/2006:08:56:44 +0100] "GET /index.php?title=Special:Recentchanges&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=atom&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=atom&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp%3Bfeed=atom&amp;amp%3Bamp%3Bamp%3Bamp%3Bfeed=rss&amp;amp%3Bamp%3Bamp%3Bfeed=atom&amp;amp%3Bamp%3Bfeed=atom&amp;amp%3Bfeed=rss&amp;feed=rss HTTP/1.1" 200 60626 "-" "Mozilla/5.0 (compatible; Yoono; http://www.yoono.com/)"

Après investigation, il apparaîtrait que ce soit une attaque exploitant une faille, corrigée sur notre version, de Wikimedia.

D'après le whois, les IPs viendraient d'une société spécialisée dans la sécurité informatique (un comble !) et d'une résidence universitaire française... On peut supposer qu'on est en présence, soit d'étudiants s'amusant un samedi soir, soit de machines sous Windows transformées en zombies et attaquant à tout-va !

root@borsalino ~> cat access.log |grep ":Recentchanges&amp;amp%3Bamp%3Bamp%3Bamp%3Bamp" --count

6498

Sachant que je grep un log qui est en rotation journalière... Ca fait quand même beaucoup !

La sanction :

iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP

Et ce, afin de bloquer l'accès à la machine à cette IP et aux autres...

Merci à SpeedFire du chan #fedora-fr pour son cour sur iptables.

Montage cifs, extensions Unix et paramètres uid/gid

llaumgui — Tue, 05 Sep 2006 23:18:00 +0200

Après une soirée entière de galère à ne pas comprendre pourquoi les uid (utilisateur identifiant) et gid (groupe identifiant) forcés lors de mon montage cifs n'étaient pas pris en compte, j'ai réussi a trouver le fautif (avec l'aide d'un ami) : les extension Unix.

Pourquoi forcer l'uid et le gid lors d'un montage cifs ? Il peut arriver que l'uid et le gid du propriétaire des fichiers sur le serveur samba ne soit pas le même que celui qui monte la partition. Utiliser les paramètres uid et gid lors du montage sert à corriger cette différence.

Cependant, il s'avère que les extensions Unix empêchent ce forçage, la solution est alors de les supprimer :

unix extensions = no

Pour info, voici ma ligne de fstab :

//192.168.1.1/sites     /mnt/deepspace9         cifs    user,noauto,credentials=/home/llaumgui/.credentials,uid=500,gid=500 0 0

Vous remarquez que j'utilise l'option credentials pour aller chercher mes identifiants dans un fichier à part et éviter qu'il soit lisible de tous ceux ayant accès au fstab (de base, il est en lecture seule pour les utilisateurs). La syntaxe de ce fichier est :

username=toto

password=titi

Nouvelle installation de Fedora Core 4 et SELinux

llaumgui — Thu, 14 Jul 2005 14:21:00 +0000

Ayant apprécié Fedora Core depuis sa version 2, qui fut la première à propulser mon serveur, j'ai entrepris de migrer mon serveur sous Fedora Core 4.
Ayant plusieurs problèmes de stabilité avec ma version 3 (problème de doublons dans mes paquets), j'opte pour une complète réinstallation.

Anaconda (le système d'installation de Fedora) est toujours un véritable régale et je me retrouve enfin avec un serveur Fedora Core 4.
Comme à mon habitude, je lance VNC (Système de contrôle du bureau à distance) et débranche clavier et souris...

Première étape: faire communiquer ma station Windows et mon serveur Linux tous 2 en réseau. C'est là qu'intervient Samba. Et là, problème :

[2005/07/07 13:54:53, 0] smbd/service.c:make_connection_snum(615) '/home/serv_backup' does not exist or is not a directory, when connecting to [serv_backup]

J'en suis 4 jour de testes/installation/réinstallation, durant lesquels j'en ai profité pour tester tout un tas de distribs (Suse 9.3, Debian 3.1r0a, Ubuntu 5.04 Hoary Hedgehog), j'ai même refait (histoire de me rassurer :-)) une installe de Fedora Core 3 que j'ai configurer en 5 minutes et sans problème...

Après une inscription sur Fedora Forum (il faut être membre pour utiliser la recherche), support officiel mais en langue anglaise, la solution fut trouvée, ou plutôt le responsable : SELinux.

SELinux, pour Security-Enhanced Linux, est un LSM (Linux security module), qui permet de définir une politique d'accès MAC (mandatory access control) aux éléments d'un système basé sur Linux. Conçu à l'origine par la NSA, son architecture dissocie l'application de la politique d'accès et sa définition. Il permet notamment de classer les applications d'un système, en différents groupes, avec des niveaux d'accès plus fins. Il permet aussi d'attribuer un niveau de confidentialité pour l'accès à des objets systèmes, comme des descripteurs de fichier.
Sources : Wikipedia

En conclusion, il est fort étrange qu'une politique aussi restrictive soit activée par défaut sous Fedora Core 4, mais cette dernière peut être désactivé (et réactivée sans problème par la suite) durant l'installation.

Bien débuter le développement d'une application web niveau sécurité

llaumgui — Sun, 01 May 2005 23:02:00 +0000

Suite à une discutions sur les forums d'IPBR-Fr initiée par Darken, et à la critique émise lors de mon précédent billet : je me demande, comment bien partir dans le développement d'application web (Ou mod IPB) du point de vu sécurité ? En effet, la question de la sécurité doit être pensé lors du développement et non après coup.

I. Ne plus utiliser de fonction dévaluées :

php est un langage en perpétuelle évolution. Certaines vieilles fonctions sont toujours supportées dans les dernières versions mais sont fortements dévaluées... Pour des raisons de sécurité et de compatibilité dans les futures versions, éviter de telles fonctions se révèle une bonne chose.
Ainsi, par exemple, on préfèrera $_SESSION['TOTO'] à session_register().

II. register_global = Off :

L'un des point de sécurité les plus important celon moi.
Depuis php 4.2, register_global prend la valeur off et php.net préconise de le laisser comme ça. Malheureusement trop de script ne tourne pas en environnement register_global = off, ce qui fait que les serveurs professionnels tourne sous On. Cela n'est pas grave en soit si vous avez développé votre application en Off car elle sera sécurisée.

Imaginez que vous utilisiez une variable $login pour identifier un visiteur de votre site et que vous n'ayez pas travaillé dans un environnement registerglobal = On. Si $login n'est pas présent dans la session, php ira le chercher dans le cookie puis dans les supers variables POST et GET... Comment savoir d'où est affectée cette variable dans ce cas là ?

La réponse est simple, si vous devez chercher cette variable dans la session, faite $_SESSION['login'], dans un cookie : $_COOKIE['login'] et dans $_POST et $_GET pour les autres supers variables. Ainsi, vous saurez exactement d'où provient la valeur prise par une variable et pourrez la contrôler.

III. Typage de variable :

Le point fort de php est d'être facile à apprendre et entreprendre. De ce fait, il n'y a pas de typage des variables à proprement parler...
De cette facilité, née une faille de sécurité dont l'une des principales conséquences sont les injonctions SQL (Objet d'un prochain billet).
Forcer le typage des variables issues notamment de $_GET et surtout celle qui ne sont pas des chaînes de caractère se révèle donc indispensable.
Ainsi si notre variable $login représente un identifiant entier nous la récupèrerons ainsi :

$login_id = intval(@$_GET['login'])

La sécurité dans le domaine du web est devenue un point primordial de tout développement. Au risque de me répéter, cette question doit être abordée lors de l'analyse/conception de votre application.
Quel variables dois je récupérer à partir de super variables ? Comment dois je passer certaines informations de page en page ? Cookies ou sessions ? Sont autant de question non négligeable.