Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
Viruscan :
contrôle le courrier entrant pour la majorité des clients POP3
C'est là que je me demande où Viruscan fait sa surveillance ?
Et je pense qu'il ne le fait pas au niveau POP3 (comme le fait NOD32 par
exemple), ni au niveau TCP/IP (ce qui permet facilement de couvrir tous
les protocoles supérieurs). Mais le doute reste...
Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
Viruscan :
contrôle le courrier entrant pour la majorité des clients POP3
C'est là que je me demande où Viruscan fait sa surveillance ?
Et je pense qu'il ne le fait pas au niveau POP3 (comme le fait NOD32 par
exemple), ni au niveau TCP/IP (ce qui permet facilement de couvrir tous
les protocoles supérieurs). Mais le doute reste...
Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
Viruscan :
contrôle le courrier entrant pour la majorité des clients POP3
C'est là que je me demande où Viruscan fait sa surveillance ?
Et je pense qu'il ne le fait pas au niveau POP3 (comme le fait NOD32 par
exemple), ni au niveau TCP/IP (ce qui permet facilement de couvrir tous
les protocoles supérieurs). Mais le doute reste...
Tristan wrote:Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
On peut effectivement parler de proxy, dans ce cas.
Le "facilement" me parait un poil excessif : pour pouvoir couvrir les
protocoles superieurs, il faut que le proxy comprenne tous les protocoles
en question
Pour autant, je ne connais pas la methode utilisee par les AVs qui reposent
sur les fonctions MAPI pour filtrer les emails, mais je ne crois pas qu'ils
passent par le scan d'un cache "sur disque". Il me semble plus probable que
certaines fonctions MAPI soient "hookees" par l'AV (detournees : a l'appel
de ces fonctions, l'AV va faire la requete POP/SMTP correspondante, analyser
le flux et le transmettre, tout ceci etant transparent pour le mailer
"client")
L'autre technique est d'installer explicitement le proxy et de
configurer explicitement le client mail de facon a ce qu'il fasse la requete
a ce proxy qui va lui-meme transmettre celle-ci au serveur POP/SMTP.
D'ailleurs, j'aurais moi aussi une petite question : comment les AVs
procedent-ils pour gerer les versions securisees (i.e. pour lesquelles
les donnees sont cryptees, comme SPOP) de ces protocoles
Tristan wrote:
Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
On peut effectivement parler de proxy, dans ce cas.
Le "facilement" me parait un poil excessif : pour pouvoir couvrir les
protocoles superieurs, il faut que le proxy comprenne tous les protocoles
en question
Pour autant, je ne connais pas la methode utilisee par les AVs qui reposent
sur les fonctions MAPI pour filtrer les emails, mais je ne crois pas qu'ils
passent par le scan d'un cache "sur disque". Il me semble plus probable que
certaines fonctions MAPI soient "hookees" par l'AV (detournees : a l'appel
de ces fonctions, l'AV va faire la requete POP/SMTP correspondante, analyser
le flux et le transmettre, tout ceci etant transparent pour le mailer
"client")
L'autre technique est d'installer explicitement le proxy et de
configurer explicitement le client mail de facon a ce qu'il fasse la requete
a ce proxy qui va lui-meme transmettre celle-ci au serveur POP/SMTP.
D'ailleurs, j'aurais moi aussi une petite question : comment les AVs
procedent-ils pour gerer les versions securisees (i.e. pour lesquelles
les donnees sont cryptees, comme SPOP) de ces protocoles
Tristan wrote:Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
On peut effectivement parler de proxy, dans ce cas.
Le "facilement" me parait un poil excessif : pour pouvoir couvrir les
protocoles superieurs, il faut que le proxy comprenne tous les protocoles
en question
Pour autant, je ne connais pas la methode utilisee par les AVs qui reposent
sur les fonctions MAPI pour filtrer les emails, mais je ne crois pas qu'ils
passent par le scan d'un cache "sur disque". Il me semble plus probable que
certaines fonctions MAPI soient "hookees" par l'AV (detournees : a l'appel
de ces fonctions, l'AV va faire la requete POP/SMTP correspondante, analyser
le flux et le transmettre, tout ceci etant transparent pour le mailer
"client")
L'autre technique est d'installer explicitement le proxy et de
configurer explicitement le client mail de facon a ce qu'il fasse la requete
a ce proxy qui va lui-meme transmettre celle-ci au serveur POP/SMTP.
D'ailleurs, j'aurais moi aussi une petite question : comment les AVs
procedent-ils pour gerer les versions securisees (i.e. pour lesquelles
les donnees sont cryptees, comme SPOP) de ces protocoles
Sachez que parmi les AV que vous avez cité ici : KAV, NOD32 et McAfee
détectent Swen sans MAJ parce que leur moteur d'analyse heuristique sont
parmi les plus avancés et sophistiqués du secteur.
ben... visiblement pas KAV
Je te confirme qu'avec la 4.5 la source a été détecté. Vérifies tes
paramètres de Mail Checker.
Sous la 3.5 je ne sais pas.
Non, KAV a détecté l'exploit Iframe du message mais pas Swen.
Autant pour moi je n'aurais pas dû employer le terme source. ;)
Sachez que parmi les AV que vous avez cité ici : KAV, NOD32 et McAfee
détectent Swen sans MAJ parce que leur moteur d'analyse heuristique sont
parmi les plus avancés et sophistiqués du secteur.
ben... visiblement pas KAV
Je te confirme qu'avec la 4.5 la source a été détecté. Vérifies tes
paramètres de Mail Checker.
Sous la 3.5 je ne sais pas.
Non, KAV a détecté l'exploit Iframe du message mais pas Swen.
Autant pour moi je n'aurais pas dû employer le terme source. ;)
Sachez que parmi les AV que vous avez cité ici : KAV, NOD32 et McAfee
détectent Swen sans MAJ parce que leur moteur d'analyse heuristique sont
parmi les plus avancés et sophistiqués du secteur.
ben... visiblement pas KAV
Je te confirme qu'avec la 4.5 la source a été détecté. Vérifies tes
paramètres de Mail Checker.
Sous la 3.5 je ne sais pas.
Non, KAV a détecté l'exploit Iframe du message mais pas Swen.
Autant pour moi je n'aurais pas dû employer le terme source. ;)
In article <3f7540e2$0$16266$,
says...Tristan wrote:
Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Soit mais l'analyse des paquets concerne aussi ceux de ton AV.
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
Le seul qui scanne les strings est NOD32 actuellement.
In article <3f7540e2$0$16266$79c14f64@nan-newsreader-02.noos.net>,
alamaisonHIT-THE-DIRT@noos.HIT-THE-DIRT.fr says...
Tristan wrote:
Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Soit mais l'analyse des paquets concerne aussi ceux de ton AV.
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
Le seul qui scanne les strings est NOD32 actuellement.
In article <3f7540e2$0$16266$,
says...Tristan wrote:
Sans entrer dans une définition absolue, la fonction d'un FW n'est pas le
contrôle AV (même si on peut le coupler à un AV).
Soit mais l'analyse des paquets concerne aussi ceux de ton AV.
Dès lors qu'un flux passe le FW, l'AV devrait jouer son rôle avant même
que le logiciel client (mailer, navigateur, ...) ne reçoive le fichier,
pour être optimum.
Le seul qui scanne les strings est NOD32 actuellement.
Pour autant, je ne connais pas la methode utilisee par les AVs qui reposent
sur les fonctions MAPI pour filtrer les emails, mais je ne crois pas qu'ils
passent par le scan d'un cache "sur disque". Il me semble plus probable que
certaines fonctions MAPI soient "hookees" par l'AV (detournees : a l'appel
de ces fonctions, l'AV va faire la requete POP/SMTP correspondante, analyser
le flux et le transmettre, tout ceci etant transparent pour le mailer
"client")
Je ne sais pas non plus ce qu'offre MAPI,
MAPI est tout simplement une norme utilisée par bon nombre de programmes
mais effectivement il est
possible que cette API offre des exits ou des possibilités de hooks pour
intercepter les échanges (sans même avoir à les relayer au niveau du
protocole).
Il y a deux principales méthodes pour envoyer un mail :
Mais MAPI est utilisé par quel logiciel client internet ?
Outlook ; Outlook Express ; Netscape Messenger ; Eudora ; The Bat
N'est-ce pas de l'héritage Windows pré-1998 ?
Apparu d'abord avec Win2000.
C'est ce que fait NOD32 (v1) pour le POP3.
Mais ça ne couvre que le POP3...
Migre vers la v2 ;)
Pour autant, je ne connais pas la methode utilisee par les AVs qui reposent
sur les fonctions MAPI pour filtrer les emails, mais je ne crois pas qu'ils
passent par le scan d'un cache "sur disque". Il me semble plus probable que
certaines fonctions MAPI soient "hookees" par l'AV (detournees : a l'appel
de ces fonctions, l'AV va faire la requete POP/SMTP correspondante, analyser
le flux et le transmettre, tout ceci etant transparent pour le mailer
"client")
Je ne sais pas non plus ce qu'offre MAPI,
MAPI est tout simplement une norme utilisée par bon nombre de programmes
mais effectivement il est
possible que cette API offre des exits ou des possibilités de hooks pour
intercepter les échanges (sans même avoir à les relayer au niveau du
protocole).
Il y a deux principales méthodes pour envoyer un mail :
Mais MAPI est utilisé par quel logiciel client internet ?
Outlook ; Outlook Express ; Netscape Messenger ; Eudora ; The Bat
N'est-ce pas de l'héritage Windows pré-1998 ?
Apparu d'abord avec Win2000.
C'est ce que fait NOD32 (v1) pour le POP3.
Mais ça ne couvre que le POP3...
Migre vers la v2 ;)
Pour autant, je ne connais pas la methode utilisee par les AVs qui reposent
sur les fonctions MAPI pour filtrer les emails, mais je ne crois pas qu'ils
passent par le scan d'un cache "sur disque". Il me semble plus probable que
certaines fonctions MAPI soient "hookees" par l'AV (detournees : a l'appel
de ces fonctions, l'AV va faire la requete POP/SMTP correspondante, analyser
le flux et le transmettre, tout ceci etant transparent pour le mailer
"client")
Je ne sais pas non plus ce qu'offre MAPI,
MAPI est tout simplement une norme utilisée par bon nombre de programmes
mais effectivement il est
possible que cette API offre des exits ou des possibilités de hooks pour
intercepter les échanges (sans même avoir à les relayer au niveau du
protocole).
Il y a deux principales méthodes pour envoyer un mail :
Mais MAPI est utilisé par quel logiciel client internet ?
Outlook ; Outlook Express ; Netscape Messenger ; Eudora ; The Bat
N'est-ce pas de l'héritage Windows pré-1998 ?
Apparu d'abord avec Win2000.
C'est ce que fait NOD32 (v1) pour le POP3.
Mais ça ne couvre que le POP3...
Migre vers la v2 ;)
La méthode pour contrer cela est de configurer le serveur SMTP pour qu
il refuse de relayer des mails qui ne viennent pas de l'intérieur de la
société en vérifiant l'adresse mail de l'expéditeur.
Cependant Internet offre assez facilement (malheureusement) des noms de
serveur SMTP aux personnes malintentionnées.
N'est-ce pas de l'héritage Windows pré-1998 ?
Apparu d'abord avec Win2000.
La méthode pour contrer cela est de configurer le serveur SMTP pour qu
il refuse de relayer des mails qui ne viennent pas de l'intérieur de la
société en vérifiant l'adresse mail de l'expéditeur.
Cependant Internet offre assez facilement (malheureusement) des noms de
serveur SMTP aux personnes malintentionnées.
N'est-ce pas de l'héritage Windows pré-1998 ?
Apparu d'abord avec Win2000.
La méthode pour contrer cela est de configurer le serveur SMTP pour qu
il refuse de relayer des mails qui ne viennent pas de l'intérieur de la
société en vérifiant l'adresse mail de l'expéditeur.
Cependant Internet offre assez facilement (malheureusement) des noms de
serveur SMTP aux personnes malintentionnées.
N'est-ce pas de l'héritage Windows pré-1998 ?
Apparu d'abord avec Win2000.
http://news.hut.edu.vn/books/MAPI%20SAPI%20and%20TAPI%20Developer's/ch3.htm
8<------------8<-----------
This means that programs using MAPI services that were written under
Windows 3.1 will still be able to access those same MAPI services under
Windows 95.
8<------------8<-----------
Aucun problème sur les origines de MAPI. ;)
http://news.hut.edu.vn/books/MAPI%20SAPI%20and%20TAPI%20Developer's/ch3.htm
8<------------8<-----------
This means that programs using MAPI services that were written under
Windows 3.1 will still be able to access those same MAPI services under
Windows 95.
8<------------8<-----------
Aucun problème sur les origines de MAPI. ;)
http://news.hut.edu.vn/books/MAPI%20SAPI%20and%20TAPI%20Developer's/ch3.htm
8<------------8<-----------
This means that programs using MAPI services that were written under
Windows 3.1 will still be able to access those same MAPI services under
Windows 95.
8<------------8<-----------
Aucun problème sur les origines de MAPI. ;)
