FIREWALL EN C

Signaler
Messages postés
4
Date d'inscription
dimanche 28 avril 2002
Statut
Membre
Dernière intervention
5 octobre 2003
-
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005
-
Bonjour à tous...

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

9 réponses

Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005

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

Voilà j'espère que ca t'a aidé
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
2
Salut,
Et si un programme utilise autre chose que les sockets pour la communication reseau, il passe a travers ton "firewall" ?
Messages postés
4
Date d'inscription
dimanche 28 avril 2002
Statut
Membre
Dernière intervention
5 octobre 2003

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)

Sinon pour Linux j'ai chopé ca sur le net et ca à l'air plus simple
http://www.guill.net/index.php?cat=6&prg=12

aardman :

Perso je connais pas d'autre moyen que les socket pour la communication.... (il y en a?) :question)
Macou
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
2
Salut,
Wininet, Winhttp, etc...
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005

salut

regarde les dépendances de wininet.dll et compagnie ....
tu trouvera forcément une DLL de socket (ws_32.dll ou autre)

donc moi je ne connais QUE les sockets, tous les autres moyens en sont dérivés
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
2
Salut,
Heuresement qu'il n'existe pas que les sockets.
Ca serait bien chiant sinon.

Aucune dépendance de ws2_32.dll trouvée dans wininet.dll.
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005

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)
Messages postés
150
Date d'inscription
samedi 31 janvier 2004
Statut
Membre
Dernière intervention
16 février 2009

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 : L'ami des diagrammes
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005

Salut à tous



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



@+