FIREWALL EN C
djmacou
Messages postés
4
Date d'inscription
dimanche 28 avril 2002
Statut
Membre
Dernière intervention
5 octobre 2003
-
3 oct. 2003 à 12:41
SMarmotte Messages postés 53 Date d'inscription vendredi 17 janvier 2003 Statut Membre Dernière intervention 12 novembre 2005 - 30 nov. 2005 à 18:45
SMarmotte Messages postés 53 Date d'inscription vendredi 17 janvier 2003 Statut Membre Dernière intervention 12 novembre 2005 - 30 nov. 2005 à 18:45
A voir également:
- Firewall c
- Connexion à travers proxy/firewall ✓ - Forum C
9 réponses
SMarmotte
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005
5 oct. 2003 à 12:36
5 oct. 2003 à 12:36
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é
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é
cs_aardman
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
5 oct. 2003 à 13:59
5 oct. 2003 à 13:59
Salut,
Et si un programme utilise autre chose que les sockets pour la communication reseau, il passe a travers ton "firewall" ?
Et si un programme utilise autre chose que les sockets pour la communication reseau, il passe a travers ton "firewall" ?
djmacou
Messages postés
4
Date d'inscription
dimanche 28 avril 2002
Statut
Membre
Dernière intervention
5 octobre 2003
5 oct. 2003 à 15:13
5 oct. 2003 à 15:13
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
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
cs_aardman
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
5 oct. 2003 à 15:22
5 oct. 2003 à 15:22
Salut,
Wininet, Winhttp, etc...
Wininet, Winhttp, etc...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
SMarmotte
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005
6 oct. 2003 à 19:05
6 oct. 2003 à 19:05
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
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
cs_aardman
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
6 oct. 2003 à 19:16
6 oct. 2003 à 19:16
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.
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.
SMarmotte
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005
7 oct. 2003 à 09:44
7 oct. 2003 à 09:44
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)
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)
Oeil_de_taupe
Messages postés
150
Date d'inscription
samedi 31 janvier 2004
Statut
Membre
Dernière intervention
16 février 2009
29 nov. 2005 à 18:38
29 nov. 2005 à 18:38
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
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
SMarmotte
Messages postés
53
Date d'inscription
vendredi 17 janvier 2003
Statut
Membre
Dernière intervention
12 novembre 2005
30 nov. 2005 à 18:45
30 nov. 2005 à 18:45
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
@+
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
@+
