Voilà je voudrais faire un petit firewall en C pour un projet de fin d'année...
Seulement je n'ai trouver aucune source sur le site pour m'aider...
Si qqun sait ou je peux trouver une source qui pourrait m'aider, je suis preneur...
Merci par avance
Macou
mouais ... j'ai déjà réfléchi à ce genre de problème ...
Tres compliqué
Pour les systèmes Windows, une idée est de procéder ainsi :
La solution la plus faisable à mon goût est que tu fasse un prog qui hooke les fonctions socket (send, sendto, recv, recvfrom, ... et quelques autres encore).
Là où il y a problème c'est qu'il faut hooker pour TOUS les process existant.
Indication :: pour le hook pose un WH_CBT et un WH_MESSAGE qui vont appeler ta routine quand un process reçoit un message ou une opération de fenètrage à faire (on peut donc supposer presque au démarrage du programme).
Dans la routine de hook, tu en profite pour patcher l'Import Address Table du programme (voir format de executables PE - ca se trouve sur le web) pour modifier l'adresse des fonctions socket et les rediriger chez toi (tu auras bien entendu prévu des routines appropriées).
Jusque là : trivial
Nouveau soucis : il faut hooker aussi TOUS les NOUVEAUX process (et là c'est un peu plus compliqué surtout si ledit programme est un virus sans fenètre ...).
Si tu arrive déjà à faire ça se sera pas mal et tu auras quelques résultats.
Mais ton firewall ne sera pas efficace à 100% car si un prog fait un LoadLibrary et utilise GetProcAddress pour déterminer l'adresse de la fonction, il te contournera.
=> Donc tu vas devoir aussi hooker Loadlibrary et GetProcAddress du KERNEL32
> Nouvelle parade : NTDLL contient des fonction qui font LoadLibrary et GetProcAddress
=> Il te faudra aussi les hooker
Ca reste encre faisable mais c'est chaud .... tres chaud
Voilà qui je pense te fait comprendre comment s'y prendre
Sinon, tu fais un fichier .SYS qui espionne toutes les entrées sorties PPP et réseau (mais ça moi je sais pas faire)
Il existe une autre solution qui fonctionne mais là c'est carrément du debogage de process et c'est hyper axé assembleur ... donc on quitte le C
Merci de ta réponse SMarmotte...
De toute facon je sais que c'est balaise de faire un firewall pour Windows..Surtout si je veux proteger sur les trois niveaux.
Mais ce que je cherche à faire c vraiment un truc basique du genre bloquer les ports pour tel ou tel adresse.. autorisé tel port en sortis etc...
Enfin un truc tout bete
C juste pour un projet de fin d'année, et je crois que ca ce sera déjà pas mal pour avoir une pure note :big)
cherche mieux ....
moi j'ai trouvé au moins 3 fois WS_32.dll dans wininet ...
ne te cantonne pas qu'aux dépendances simple de la DLL mais aussi aux dépendances des dépendances ....
comme j'aime pas argumenter sans preuves, je vous joins un screenshot montrant que ws_32 est bien dans wininet (indirectement certes) ....
donc je reviens à la charge : il n'existe QUE les sockets pour communiquer
c'est la seule librairie intégrée par windows permettant de communiquer directement avec le hardware (en passant par les drivers)
Wininet utilise les sockes (d'après le petit shéma que j'ai trouvé sur
MSDN). Par contre si je me souvient bien, NetBios utilise aucun socket.
Voilà un petit diagramme en italien ou espagnole mais les lignes sont
traduites en français
Sinon pour Wininet je crois avoir vu sur MSDN que ca utilisait bien les sockets.Un diagramme bien fait :
et comme beaucoups de Chinois passe sur Code-Source (je sais même pas si c'est vraiment du chinois)
Même en chinois c'est clair, Wininet utilise des chaussettes.
Oeil_de_Taupe, tu dis "Par contre si je me souvient bien, NetBios
utilise aucun socket". Pour ma part, je ne suis pas d'accord car
NetBIOS utilise entre autres les ports TCP 137, 138 et 139. Si ma
mémoire est bonne, il utilise aussi des ports UDP.
Or pour utiliser ces protocoles, soit tu utilises les sockets (ou toute
librairie dérivée) soit tu crée toi même un KMD (Kernel Mode Driver)
spécifique à ta carte pour envoyer les signaux pouvant correspondre à
des trames réseau (fortement improbable).
Donc NetBIOS utilise bel et bien les sockets.
Pour info, dans le modele OSI (en super incomplet et simplifié)
Niveau #1 : le cable réseau
Niveau #2 : MAC (adresse physique)
Niveau #3 : IP (adresse logique)
Niveau #4 : TCP / UDP / .... toute sorte de protocoles
Niveaux #5 à #7 : mise en forme pour les applications
