SourceForge.net Logo

Configuration

<French>    English

Cette page a pour but d'expliquer comment configurer SynDetector !

Il y a trois parties bien distinctes pour configurer SynDetector :
   - Configuration pre-compilation
   - Configuration d'iptables
   - Configuration de SynDetector

Configuration pre-compilation :

Il faut éditer le fichier definition.h afin d'y adapter les valeurs ! En fonction des versions il peut y avoir plus ou
moins de champs à renseigner.

Pour les versions < 3_3 il n'y a que deux valeurs vraiment importante : TEMPSFLUSH et MAXPORT.

TEMPSFLUSH est le temps par défaut avant de vider la liste des IP et IPC bannies.
MAXPORT est le nombre maximum de port que le logiciel est autorisé à surveiller.

Pour les versions >= 3_3 il faut considérer aussi : TEMPSFLUSH2, TIMEOUT, RETRYLIMIT, PORT, PORT2 et CRYPTSALT

TEMPSFLUSH devient le temps maximum avant de vider la liste des IP bannies.
TEMPSFLUSH2 devient le temps maximum avant de vider la liste des IPC bannies.
TIMEOUT est le temps maximum d'inactivité lorsque l'on est connecté à SynDetector pour toutes actions.
RETRYLIMIT est le nombre de tentative d'exécution de l'ordre avant d'abandonner en cas d'erreur ! Cela peut arriver...
PORT est le port de connection sur SynDetector pour donner des ordres.
PORT2 est un port a usage interne de SynDetector uniquement pour transmettre les ordres à exécuter.
CRYPTSALT est à modifier éventuellement pour personnaliser la clée de cryptage à sa convenance.

Configurer iptables :

Pourquoi faut-il configurer iptables pour utiliser SynDetector ? Tout simplement car pour capturer les paquets j'utilise
la solution libipq qui consiste à appliquer des règles iptables avec comme cible (argument -j) QUEUE au lieu
de REJECT ou DROP.
Cette solution ressemble finalement à une utilisation de libpcap avec les bon filtres BSD.
Lorsque l'on lance SynDetector sans argument il donne un exemple de paramètrage d'iptables pour surveiller le
serveur web sur le port 80 :

iptables -A INPUT -p tcp --dport 80 -j QUEUE
Cette règle permet d'analyser les paquets entrant vèrs le serveur web,
iptables -A OUTPUT -p tcp --sport 80 -j QUEUE
Alors que celle-ci concerne les réponses du serveur web.

Les deux sont nécessaire au bon fonctionnement du programme.

Il est tout à fait possible de vouloir surveiller plus d'un port. Il est nécessaire d'avoir ces deux règles
pour chaque port que l'on désire surveiller.
Si vous ne voulez pas avoir à vous embetter sachez qu'il est parfaitement possible d'étendre ces règles
à l'ensemble des ports comme ceci :

iptables -A INPUT -p tcp -j QUEUE
iptables -A OUTPUT -p tcp -j QUEUE

le programme ne fera d'analyse que si le port apparaît comme surveillé dans SynConf.txt.
Cette solution a des avantages et des inconvénients... Elle permet une grande souplesse d'utilisation de SynDetector
car il suffit d'ajouter les ports dans SynDetector et ça marche ! Par contre il faut savoir que tout paquet
passant par SynDetector prend du temps machine et que si le serveur subit un fort trafic alors cela peut devenir
embettant... Qui plus est si jamais SynDetector venait à planter alors tout les ports en connection TCP
deviendrait inutilisable... Car si aucun programme n'utilise les paquets mis en QUEUE par iptables ceux-ci seront
supprimer. Ce système de fonctionnement semble embettant MAIS il faut se mettre dans le contexte d'un programme
de sécurité ! Si le programme ne peut plus assurer la défence d'un service alors il doit se débrouiller
pour éviter que le service ne soit endommagé par l'attaque (plantage du serveur web par exemple) et donc le
service en question se doit d'être mis hors connection !
Cela signifie aussi que si le programme plante il faut un moyen de le relancer le plus vite possible pour que ce problème
dur le moins longtemps possible...

Pour les versions >= à 3_3 il est nécessaire si on ne veut pas fausser les statistiques d'ajouter deux règles
supplémentaires :

iptables -I INPUT -p tcp --dport 80 -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -I OUTPUT -p tcp --sport 80 -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

En effet le futur GUI est en fait une interface web en php à utiliser sur la même machine que SynDetector (de
préférence) et donc ces deux règles vous permettrons d'éviter de passer par le module et d'être
comptabilisé dans les statistiques lorsque vous vous connecterez sur votre serveur web via l'ip 127.0.0.1 !
Ces règles peuvent aussi être utiliser sur des IP non locales pour qu'elle ne soit pas limité par le module
mais dites vous bien que se sera autant de failles potentielles pour un pirate qui arriverait à spoofer ces IP...

SynDetector va aussi bloquer les connections sur l'IPserveur depuis l'IPserveur pour des raisons de sécurités !
C'est à dire que lorsque vous êtes sur la machine qui possède l'IPserveur vous ne pouvez pas vous connectez
sur un port surveillé de cette même machine sur cette IP.
Du moins pas sans ajouter une autre règle dans iptables. Mais cette règle n'est pas sans conséquence.
En fait la règle en question correspond a la deuxième des deux règles précédentes mais sur l'IPserver :

iptables -I OUTPUT -p tcp --sport 80 -s IPserveur -d IPserveur -j ACCEPT

Grâce à cette règle vous pouvez vous connecter en local sur l'IPserveur MAIS SynDetector analysera
quand même une partie du trafic et appliquera les paramêtres des détections et de bloquages si il
considère qu'il y a un synflood. Seulement le système de détection d'IP spoofé sera faussé,
enfin uniquement pour ces connections locales l'IP sera considérée comme fausse.

Configurer SynDetector :

Voici les différents éléments qu'il faut configurer pour chaque port du fichier de configuration :

PORT :
           Le numéro de port voulu.

LENGHTETE :
           Est la taille de la file des connections à analyser donc plus
           elle est grande plus c'est lent mais plus l'échantillon sera
           représentatif (avec les bons réglages de LIMTEMPORELLE/SENSEUR/
           PERCENT)

SENSEUR :
           Dans l'idée de sensibilité, le fait de mettre senseur à 2 par exemple va
           permettre de ne vérifier qu'une ip/2 dans la liste des connections de
           LENGHTETE ce qui permet d'améliorer la détection dans le cas ou des
           ip "parasites" de clients normaux s'intercalent dans la liste malgré la
           rapidité probable du synflood... Attention donc à ce que LENGHTETE ne
           soit quand même pas trop gros pour empêcher toute détection toujours à
           cause de ces ip "parasites" car l'analyse ne commence que quand LENGHTETE est pleine.

LIMTEMPORELLE :
           Lorsque l'on veut définir une limite pour le synflood de par exemple
           X requêtes/Ys on mettra LENGHTETE=X et LIMTEMPORELLE=Y. Attention il
           n'est pas vrai du tout de considérer que 50/10s <=> 5/1s, du fait du
           fonctionnement des requêtes des clients web normaux lors du chargement
           des objets d'une page qui peut faire, si il y a 5 images, 5 requêtes très
           rapidement sans que cela soit du synflood ! Dans le premier cas il
           n'est pas bannie et dans le deuxième cas il l'est ! Attention donc à
           bien dimensionner l'échantillon.

PERCENT :
           Dans le sens de pourcentage bien sur... C'est une notion assez sensible
           basée sur le principe qu'il suffit d'avoir un certain pourcentage de la
           file pleine d'une même ip dans le temps LIMTEMPORELLE toujours pour
           éviter le phénomène d'ip "parasites" ET pour casser un peu le phénomène
           de rigidité de SENSEUR qui prend de façon trop régulière une ip sur deux
           ou trois. Donc même si avec une ip sur deux ou trois il reste des ip
           "parasites" le fait de relativiser ceci par un pourcentage permet d'assouplir
           la détection. Attention, si c'est trop faible il y aura beaucoup de détection
           incorrecte. Pour calculé le pourcentage dites vous simplement que vous
           travaillez sur LENGHTETE, ex: 80% de LENGHTETE. Même si la formule de
           l'algorithme prend en compte SENSEUR vous n'avez pas à vous en souciez.


La disposition dans le fichier de configuration est vraiment simple et il vous suffira de regarder celui donnez en exemple une
fois pour comprendre comment disposez vos valeurs !

Pour les version >= 3_3 l'interface client/serveur permettra d'agir directement sur la configuration en cour d'utilisation
et même de les sauvegarder ! Mais il est quand même obligatoire d'avoir un fichier de configuration existent même
si il est vide !

Téléchargé the fichier de configuration d'exemple SynConf.txt ici