Discussion :

[boboss123]

Bonjour,

Je suis en train de mettre en place un serveur Web sur un système embarqué.
J'ai un système de gestion de session HTTPS et je me posais une question : au moment de l'ouverture d'une session, je peux enregistrer dans une table la correspondance IP/SESSION_ID. Et donc faire en sorte que pour toute requête HTTPS, mon serveur ne considère pas la requête comme étant valide si l'IP ne correspond pas... ce qui aurait comme conséquence de rediriger l'utilisateur vers la page de login/password et donc limiterait le risque de vol de session.
... mais est-ce que ça ne peut pas mettre le bazarre ?... Est-ce que durant une connexion, l'IP source vu par le serveur peut changer ? Vous avez déjà vu ce type de protection sur un serveur Web ?

Aussi ça m'amène à une autre question : quels type de logs faut-il que je mette en place pour savoir s'il y a eu des attaques réseau sur mon système embarqué ?
Je pensais déjà à ceux là :
- ouverture/fermeture de connexion HTTPS/SSH
- mauvais login/password entré pour HTTPS/SSH/SNMP
- ping reçu

[fredoche]

Oui c'est parfois d'usage sur certains systèmes

Et oui c'est parfois bien chiant d'autant que ça ne sert à rien, puisque le contrôle de session juste par une IP serait absolument inutile face à du XSS ou autres joyeusetés
C'est à l'usage par exemple chez OVH, le site de pole-emploi, des trucs comme ça

Je le sais parce que j’utilise à mon domicile du load-balancing entre 3 lignes : donc avec du vrai LB et du fail-over. Sur ces sites-là si je ne force pas les échanges sur une seule ligne ( et donc une seule IP source), je suis systématiquement redirigé vers un nouveau login, ou bien l'enchainement des écrans se bloque

Bref ça ne permet pas de maintenir des sessions pour les gens qui font comme moi du load-balancing ou fail-over

Un ping n'est pas une attaque réseau
Des tentatives de connexion ne sont pas des attaques réseaux
Et attention parfois les logs peuvent être l'outil idéal pour planter un système en surchargeant le service de logs

[boboss123]

ok merci pour le retour .

Donc les logs importants à mettre en place serait lesquels ?

[fredoche]

Tu peux bien logguer toutes ces choses là

ce qu'il est important de logguer, c'est ce qui te permet de tracer l'activité de ton application après coup, pour comprendre ce qui pose problème quand ça déconne.
Typiquement un serveur web, on loggue les requêtes et les codes réponses http, le poids, etc. C'est ne niveau minimum de débug


C'est juste cette notion d'attaque, je crois que tu parles de systèmes embarqués et je me demande si je t'ai pas lu ailleurs discuter d'un programme disposant de peu de mémoire. Il faut donc faire gaffe à bien purger régulièrement, à faire de la gestion active de ressources, sinon ça peut devenir un point faible

Par expérience, et tu peux faire l'essai, mets un serveur SSH ou HTTPS en ligne accessible depuis internet, il sera forcément visité, et tu auras forcément des tentatives de connexion en tous genres, des tests de failles et de footprints. Un serveur SSH recevra en gros toutes les secondes au moins une tentative de login qui peut venir de n'importe où

[boboss123]

C'est juste cette notion d'attaque, je crois que tu parles de systèmes embarqués et je me demande si je t'ai pas lu ailleurs discuter d'un programme disposant de peu de mémoire. Il faut donc faire gaffe à bien purger régulièrement, à faire de la gestion active de ressources, sinon ça peut devenir un point faible

Par expérience, et tu peux faire l'essai, mets un serveur SSH ou HTTPS en ligne accessible depuis internet, il sera forcément visité, et tu auras forcément des tentatives de connexion en tous genres, des tests de failles et de footprints. Un serveur SSH recevra en gros toutes les secondes au moins une tentative de login qui peut venir de n'importe où

Oui effectivement mon système a de la RAM de limitée mais par contre, le stockage des logs est dans une mémoire non-volatile assez conséquente : donc il faut juste que je m'assure d'avoir assez de RAM pour avoir un buffer tampon assez grand pour gérer les temps d'écriture des logs.
Mon équipement n'est pas sur Internet, il est sur un réseau local privé : donc si pleins de logs sont créés d'affilés, ce n'est pas forcément gênant d'en perdre quelques uns, car ça voudra probablement dire qu'il y a eu une attaque (par contre, ça ne doit pas perturber le fonctionnement normal de l'équipement).
Mon but est donc d'avoir des infos pertinentes dans les logs (détecter une attaque et la source) et que l'utilisateur ne soit pas noyé dans une grosse quantité d'informations non essentielles... et que ces informations soit compréhensibles car quand l'utilisateur n'est pas bien formé (ce qui est souvent le cas), fournir des informations trop techniques devient inutile et peu nuire à la compréhension de ce qui s'est passé.

Après les autres cas à gérer, c'est de veiller à :
- un utilisateur authentifié n'arrive pas à élever son niveau d’accréditation
- un utilisateur s'est fait voler login/password (ex : détection de connexion en dehors de certaines plages horaires)
... voilà, ce sont des pistes de réflexion que j'ai.