Et puis si on fait "allow only at this time" lors du lancement >de JAB,
Nicob le mien il cause en français "autoriser cette fois seulement"
oui ça a l'air bien , même indispensable à qui travaille tout le jour dans les malwares ou simplement beaucoup connecté (adsl). n'ayant qu'un forfait RTC et dont "la securité" n'est pas le metier , c'est un peu du luxe ici Guil.
Nicob à écrit
Et puis si on fait "allow only at this time" lors du lancement >de
JAB,
Nicob
le mien il cause en français "autoriser cette fois seulement"
oui ça a l'air bien , même indispensable à qui travaille
tout le jour dans les malwares ou simplement
beaucoup connecté (adsl).
n'ayant qu'un forfait RTC et dont "la securité" n'est pas le metier ,
c'est un peu du luxe ici
Guil.
Et puis si on fait "allow only at this time" lors du lancement >de JAB,
Nicob le mien il cause en français "autoriser cette fois seulement"
oui ça a l'air bien , même indispensable à qui travaille tout le jour dans les malwares ou simplement beaucoup connecté (adsl). n'ayant qu'un forfait RTC et dont "la securité" n'est pas le metier , c'est un peu du luxe ici Guil.
Roland Garcia
Quant à la notion d'irresponsabilité, je trouve qu'un des aspects légaux faisant le plus défaut en France est une loi protégeant juridiquement les personnes qui signalent les faillds aux éditeurs, webmasters et admins.
Trop gros, passera pas ;-)
Un gars qui fait de la sécurité applicative (comme moi) trouve en moyenne, et sans trop chercher, 1 à 5 failles par mois sur des sites qu'il *utilise à titre personnel* (banque en ligne, site "compagnon" d'un bouquin, mutuelle, ...). A chaque fois, je stresse pour remonter ces failles, en essayant d'éviter le doux son de la BEFTI qui tape à la porte au p'tit matin. Du coup, quand c'est trop sensible, je ferme ma gueule et laisse la faille en l'état.
Et puis c'est pas le cas "Kitetoa vs Tati" qui va relancer des vocations de "Robin des Bois des failles de sécu" :(
Quel pleurnicheur, pour un peu on y croirait :-)
Roland Garcia
Quant à la notion d'irresponsabilité, je trouve qu'un des aspects
légaux faisant le plus défaut en France est une loi protégeant
juridiquement les personnes qui signalent les faillds aux éditeurs,
webmasters et admins.
Trop gros, passera pas ;-)
Un gars qui fait de la sécurité applicative (comme
moi) trouve en moyenne, et sans trop chercher, 1 à 5 failles par mois sur
des sites qu'il *utilise à titre personnel* (banque en ligne, site
"compagnon" d'un bouquin, mutuelle, ...). A chaque fois, je stresse pour
remonter ces failles, en essayant d'éviter le doux son de la BEFTI qui
tape à la porte au p'tit matin. Du coup, quand c'est trop sensible, je
ferme ma gueule et laisse la faille en l'état.
Et puis c'est pas le cas "Kitetoa vs Tati" qui va relancer des vocations
de "Robin des Bois des failles de sécu" :(
Quant à la notion d'irresponsabilité, je trouve qu'un des aspects légaux faisant le plus défaut en France est une loi protégeant juridiquement les personnes qui signalent les faillds aux éditeurs, webmasters et admins.
Trop gros, passera pas ;-)
Un gars qui fait de la sécurité applicative (comme moi) trouve en moyenne, et sans trop chercher, 1 à 5 failles par mois sur des sites qu'il *utilise à titre personnel* (banque en ligne, site "compagnon" d'un bouquin, mutuelle, ...). A chaque fois, je stresse pour remonter ces failles, en essayant d'éviter le doux son de la BEFTI qui tape à la porte au p'tit matin. Du coup, quand c'est trop sensible, je ferme ma gueule et laisse la faille en l'état.
Et puis c'est pas le cas "Kitetoa vs Tati" qui va relancer des vocations de "Robin des Bois des failles de sécu" :(
Quel pleurnicheur, pour un peu on y croirait :-)
Roland Garcia
LaDDL
Nicob wrote:
Je sais comment marche un reverse-proxy, mais ça sert prinicipalement à protégér un serveur Web. Oui mais on peut élargir ses fonctionnalités c'est juste IMHO une
histoire de config & paramétrage des filtres/règles.
Or, dans le cas de JAB, point de serveur Web à protéger. lol merci on avait compris.
Etant donné qu'il faut protèger le client web (ici IE). En filtrant ses requêtes/réponses théoriquement JAB est bloqué dans les deux sens ou bien dans un mais cela dépend de la politique de filtrage. Enfin je voulais savoir si tu avais pu déjà testé JAB avec un reverse proxy. So ?
Nicob wrote:
Je sais comment marche un reverse-proxy, mais ça sert prinicipalement à
protégér un serveur Web.
Oui mais on peut élargir ses fonctionnalités c'est juste IMHO une
histoire de config & paramétrage des filtres/règles.
Or, dans le cas de JAB, point de serveur Web à
protéger.
lol merci on avait compris.
Etant donné qu'il faut protèger le client web (ici IE). En filtrant ses
requêtes/réponses théoriquement JAB est bloqué dans les deux sens ou
bien dans un mais cela dépend de la politique de filtrage.
Enfin je voulais savoir si tu avais pu déjà testé JAB avec un reverse
proxy.
So ?
Je sais comment marche un reverse-proxy, mais ça sert prinicipalement à protégér un serveur Web. Oui mais on peut élargir ses fonctionnalités c'est juste IMHO une
histoire de config & paramétrage des filtres/règles.
Or, dans le cas de JAB, point de serveur Web à protéger. lol merci on avait compris.
Etant donné qu'il faut protèger le client web (ici IE). En filtrant ses requêtes/réponses théoriquement JAB est bloqué dans les deux sens ou bien dans un mais cela dépend de la politique de filtrage. Enfin je voulais savoir si tu avais pu déjà testé JAB avec un reverse proxy. So ?
djehuti
salut "Nicob" a écrit dans le message news:
On Mon, 29 Sep 2003 21:49:09 +0200, LaDDL wrote:
Mais comme je l'ai déjà longuement exprimé dans le thread "réponse à une intrusion"/"watermarking" sur fcs il faut contrôler l'accès à ce genre d'information très sensible.
Mort de rire.
c'est vrai qu'il vaut mieux en rire !
C'est moi qui ait écrit ce code, donc si une loi obligeant à s'inscrire à un "club des malwares" venait à paraitre, JAB ne serait tout simplement pas public (enfin .. connu des membres de ce "club") mais je l'utiliserais quand même et en ferais profiter quelques potes.
The files received do not contain a virus, and are not considered trojans because they do not damage systems maliciously. We have added detection for it but not removal. This is for legal and copyright reasons, and because many programs will have a legitimate use, and may have been paid for and installed intentionally. [/quote]
l'est pourtant détecté comme cheval de troie par d'autres AV (même par NAV) ... je dois avouer que cet éditeur (que j'aime bien quand même) a rectifié le tir et détecte cette menace
voilà, j'espère que j'ai pas répondu trop à côté de la plaque... j'ai d'énormes problèmes de compréhension
@tchao
salut
"Nicob" <usenet@nicob.net> a écrit dans le message news:
pan.2003.09.30.07.34.57.66083@nicob.net
On Mon, 29 Sep 2003 21:49:09 +0200, LaDDL wrote:
Mais comme je l'ai déjà longuement exprimé dans le thread "réponse à
une intrusion"/"watermarking" sur fcs il faut contrôler l'accès à ce
genre d'information très sensible.
Mort de rire.
c'est vrai qu'il vaut mieux en rire !
C'est moi qui ait écrit ce code, donc si une loi obligeant à
s'inscrire
à un "club des malwares" venait à paraitre, JAB ne serait tout
simplement pas public (enfin .. connu des membres de ce "club") mais
je l'utiliserais quand même et en ferais profiter quelques potes.
The files received do not contain a virus, and are not considered trojans
because they do not damage systems maliciously. We have added detection for
it but not removal. This is for legal and copyright reasons, and because
many programs will have a legitimate use, and may have been paid for and
installed intentionally.
[/quote]
l'est pourtant détecté comme cheval de troie par d'autres AV (même par NAV)
...
je dois avouer que cet éditeur (que j'aime bien quand même) a rectifié le
tir et détecte cette menace
voilà, j'espère que j'ai pas répondu trop à côté de la plaque... j'ai
d'énormes problèmes de compréhension
Mais comme je l'ai déjà longuement exprimé dans le thread "réponse à une intrusion"/"watermarking" sur fcs il faut contrôler l'accès à ce genre d'information très sensible.
Mort de rire.
c'est vrai qu'il vaut mieux en rire !
C'est moi qui ait écrit ce code, donc si une loi obligeant à s'inscrire à un "club des malwares" venait à paraitre, JAB ne serait tout simplement pas public (enfin .. connu des membres de ce "club") mais je l'utiliserais quand même et en ferais profiter quelques potes.
The files received do not contain a virus, and are not considered trojans because they do not damage systems maliciously. We have added detection for it but not removal. This is for legal and copyright reasons, and because many programs will have a legitimate use, and may have been paid for and installed intentionally. [/quote]
l'est pourtant détecté comme cheval de troie par d'autres AV (même par NAV) ... je dois avouer que cet éditeur (que j'aime bien quand même) a rectifié le tir et détecte cette menace
voilà, j'espère que j'ai pas répondu trop à côté de la plaque... j'ai d'énormes problèmes de compréhension
Enfin je voulais savoir si tu avais pu déjà testé JAB avec un reverse proxy.
Je désespère d'un jour comprendre ce thread.
Tu veux que je mette un reverse-proxy devant mon serveur JABd, c'est ça ? Si je fais ça, je vais mettre des règles autorisant le client à se connecter, vu que c'est : 1) mon but initial (faire communiquer clients et serveur) 2) et moi qui ait la main sur le serveur hébergeant JABd
Donc ça ne changera rien ...
Nicob, désespéré
On Tue, 30 Sep 2003 14:18:02 +0200, LaDDL wrote:
Enfin je voulais savoir si tu avais pu déjà testé JAB avec un reverse
proxy.
Je désespère d'un jour comprendre ce thread.
Tu veux que je mette un reverse-proxy devant mon serveur JABd, c'est ça ?
Si je fais ça, je vais mettre des règles autorisant le client à se
connecter, vu que c'est :
1) mon but initial (faire communiquer clients et serveur)
2) et moi qui ait la main sur le serveur hébergeant JABd
Enfin je voulais savoir si tu avais pu déjà testé JAB avec un reverse proxy.
Je désespère d'un jour comprendre ce thread.
Tu veux que je mette un reverse-proxy devant mon serveur JABd, c'est ça ? Si je fais ça, je vais mettre des règles autorisant le client à se connecter, vu que c'est : 1) mon but initial (faire communiquer clients et serveur) 2) et moi qui ait la main sur le serveur hébergeant JABd
Donc ça ne changera rien ...
Nicob, désespéré
LaDDL
Nicob wrote:
Supposons que je laisse tomber la sécurité informatique pour aller faire barman ou horticulteur. Je ne pourrais plus, selon toi, avoir accès à SubSeven, nmap, l'exploit pour les failles RPC I et II et JAB, c'est bien ça ? IMHO le user lambda n'a pas exploiter/utiliser ce genre de tools et
autres exploits. En revanche, on le sait tous de nombreux users avertis contribuent à faire progresser la SI/SSI donc il serait stupide de les exclure du système. Et je pense qu'il faut identifier/qualifier les users dans ce domaine (uniquement bien entendu !). C'est pourquoi je considère aussi qu'il faut être pragmatique et souple dans ce domaine qui ne relève pas uniquement de mesures légales. Mais d'une vraie politique de SI/SSI : gestion des risques, classification de l'information, etc... au plan national & international.
Des professionnels en SI/SSI oui et non des potes Nicob !!! T'es un bon programmeur (IMHO) mais "putain" quand tu dis des choses comme ça je trouve ça irresponsable de ta part.
Ben si, des potes ... Des potes en SI/SSI ok.
Mais pas des potes.
Au fait tu peux définir tes "potes" stp ?
C'est moi qui écrit le code, je peux donc choisir qui en disposera. Oui c'est ton rôle de contrôler sa diffusion mais c'est aussi de ta
responsabilité de ne pas le mettre dans n'importe quelles mains.
Je peux te dire que si je vois ta JAB là où elle ne devrait pas être ça va chier.
De toute façon, ça passe toujours par des potes Potes/relations en SI/SSI ok.
Mais pas à refiler à n'importe qui ?!
tu fais une version pas trop bugée (la beta), tu la files à des potes qui testent et te remontent des bugs ou des demandes de features, tu passes le soft amélioré à un cercle un peu plus grand (newsgroup, conf, mailing-list) et tu as encore du retour. Tu ponds une doc et tu enlèves les gros mots de tes commentaires, puis tu mets le soft en libre téléchargement, et enfin tu l'annonces (PacketStorm, SecTools, ...) C'est la méthode classique ça depuis longtemps. Rien de nouveau. ;)
Le problème c'est que le tool est accessible en qq secondes par n'importe qui sur le réseau.
A la fin de ce "cycle de développemnt", entre 15 et 100 personnes ont eu le code, Soit mais pour ma part comme bon nombre de mes confrères l'échange/le
partage et surtout la publication doit être encadrée.
mais le RSSI de base qui lit Bugtraq n'est pas encore au courant. C'est pas le plus important pour lui. Ses priorités, sa fonction & son
rôle sont ailleurs.
C'est la vie, c'est comme ça, Bruno ... Je ne suis pas de ton avis.
Ces données sensibles doivent rester dans une communauté de users identifiés.
Et moi je veux un réseau plus sûr pour demain.
Quant à la notion d'irresponsabilité, je trouve qu'un des aspects légaux faisant le plus défaut en France est une loi protégeant juridiquement les personnes qui signalent les faillds aux éditeurs, webmasters et admins. Définir des règles entre nous (les acteurs de la SI/SSI) ok.
Je te rappelle quand même que le cadre légal existe. Simplement parfois (moins dorénavant) certains oublient qu'avant de publier une faille on informe l'éditeur/CERTs.
Un gars qui fait de la sécurité applicative (comme moi) trouve en moyenne, et sans trop chercher, 1 à 5 failles par mois sur des sites qu'il *utilise à titre personnel* (banque en ligne, site "compagnon" d'un bouquin, mutuelle, ...). Dois-je te rappeler les règles déontologiques des tests intrusifs ?
A chaque fois, je stresse pour remonter ces failles, en essayant d'éviter le doux son de la BEFTI qui tape à la porte au p'tit matin. Du coup, quand c'est trop sensible, je ferme ma gueule et laisse la faille en l'état. Contactes et prends RDV avec la DCSSI.
D'autre part, si tu respectes les règles de base du métier je ne vois pas pourquoi tu devrais stresser ou être emmerder.
Nicob wrote:
Supposons que je laisse tomber la sécurité informatique pour aller faire
barman ou horticulteur. Je ne pourrais plus, selon toi, avoir accès à
SubSeven, nmap, l'exploit pour les failles RPC I et II et JAB, c'est bien
ça ?
IMHO le user lambda n'a pas exploiter/utiliser ce genre de tools et
autres exploits.
En revanche, on le sait tous de nombreux users avertis contribuent à
faire progresser la SI/SSI donc il serait stupide de les exclure du
système. Et je pense qu'il faut identifier/qualifier les users dans ce
domaine (uniquement bien entendu !).
C'est pourquoi je considère aussi qu'il faut être pragmatique et souple
dans ce domaine qui ne relève pas uniquement de mesures légales. Mais
d'une vraie politique de SI/SSI : gestion des risques, classification de
l'information, etc... au plan national & international.
Des professionnels en SI/SSI oui et non des potes Nicob !!!
T'es un bon programmeur (IMHO) mais "putain" quand tu dis des choses
comme ça je trouve ça irresponsable de ta part.
Ben si, des potes ...
Des potes en SI/SSI ok.
Mais pas des potes.
Au fait tu peux définir tes "potes" stp ?
C'est moi qui écrit le code, je peux donc choisir qui en disposera.
Oui c'est ton rôle de contrôler sa diffusion mais c'est aussi de ta
responsabilité de ne pas le mettre dans n'importe quelles mains.
Je peux te dire que si je vois ta JAB là où elle ne devrait pas être ça
va chier.
De toute façon, ça passe toujours par des potes
Potes/relations en SI/SSI ok.
Mais pas à refiler à n'importe qui ?!
tu fais une version
pas trop bugée (la beta), tu la files à des potes qui testent et te
remontent des bugs ou des demandes de features, tu passes le soft
amélioré à un cercle un peu plus grand (newsgroup, conf, mailing-list)
et tu as encore du retour. Tu ponds une doc et tu enlèves les gros mots
de tes commentaires, puis tu mets le soft en libre téléchargement, et
enfin tu l'annonces (PacketStorm, SecTools, ...)
C'est la méthode classique ça depuis longtemps. Rien de nouveau. ;)
Le problème c'est que le tool est accessible en qq secondes par
n'importe qui sur le réseau.
A la fin de ce "cycle de développemnt", entre 15 et 100 personnes ont eu
le code,
Soit mais pour ma part comme bon nombre de mes confrères l'échange/le
partage et surtout la publication doit être encadrée.
mais le RSSI de base qui lit Bugtraq n'est pas encore au courant.
C'est pas le plus important pour lui. Ses priorités, sa fonction & son
rôle sont ailleurs.
C'est la vie, c'est comme ça, Bruno ...
Je ne suis pas de ton avis.
Ces données sensibles doivent rester dans une communauté de users
identifiés.
Et moi je veux un réseau plus sûr pour demain.
Quant à la notion d'irresponsabilité, je trouve qu'un des aspects
légaux faisant le plus défaut en France est une loi protégeant
juridiquement les personnes qui signalent les faillds aux éditeurs,
webmasters et admins.
Définir des règles entre nous (les acteurs de la SI/SSI) ok.
Je te rappelle quand même que le cadre légal existe.
Simplement parfois (moins dorénavant) certains oublient qu'avant de
publier une faille on informe l'éditeur/CERTs.
Un gars qui fait de la sécurité applicative (comme
moi) trouve en moyenne, et sans trop chercher, 1 à 5 failles par mois sur
des sites qu'il *utilise à titre personnel* (banque en ligne, site
"compagnon" d'un bouquin, mutuelle, ...).
Dois-je te rappeler les règles déontologiques des tests intrusifs ?
A chaque fois, je stresse pour
remonter ces failles, en essayant d'éviter le doux son de la BEFTI qui
tape à la porte au p'tit matin. Du coup, quand c'est trop sensible, je
ferme ma gueule et laisse la faille en l'état.
Contactes et prends RDV avec la DCSSI.
D'autre part, si tu respectes les règles de base du métier je ne vois
pas pourquoi tu devrais stresser ou être emmerder.
Supposons que je laisse tomber la sécurité informatique pour aller faire barman ou horticulteur. Je ne pourrais plus, selon toi, avoir accès à SubSeven, nmap, l'exploit pour les failles RPC I et II et JAB, c'est bien ça ? IMHO le user lambda n'a pas exploiter/utiliser ce genre de tools et
autres exploits. En revanche, on le sait tous de nombreux users avertis contribuent à faire progresser la SI/SSI donc il serait stupide de les exclure du système. Et je pense qu'il faut identifier/qualifier les users dans ce domaine (uniquement bien entendu !). C'est pourquoi je considère aussi qu'il faut être pragmatique et souple dans ce domaine qui ne relève pas uniquement de mesures légales. Mais d'une vraie politique de SI/SSI : gestion des risques, classification de l'information, etc... au plan national & international.
Des professionnels en SI/SSI oui et non des potes Nicob !!! T'es un bon programmeur (IMHO) mais "putain" quand tu dis des choses comme ça je trouve ça irresponsable de ta part.
Ben si, des potes ... Des potes en SI/SSI ok.
Mais pas des potes.
Au fait tu peux définir tes "potes" stp ?
C'est moi qui écrit le code, je peux donc choisir qui en disposera. Oui c'est ton rôle de contrôler sa diffusion mais c'est aussi de ta
responsabilité de ne pas le mettre dans n'importe quelles mains.
Je peux te dire que si je vois ta JAB là où elle ne devrait pas être ça va chier.
De toute façon, ça passe toujours par des potes Potes/relations en SI/SSI ok.
Mais pas à refiler à n'importe qui ?!
tu fais une version pas trop bugée (la beta), tu la files à des potes qui testent et te remontent des bugs ou des demandes de features, tu passes le soft amélioré à un cercle un peu plus grand (newsgroup, conf, mailing-list) et tu as encore du retour. Tu ponds une doc et tu enlèves les gros mots de tes commentaires, puis tu mets le soft en libre téléchargement, et enfin tu l'annonces (PacketStorm, SecTools, ...) C'est la méthode classique ça depuis longtemps. Rien de nouveau. ;)
Le problème c'est que le tool est accessible en qq secondes par n'importe qui sur le réseau.
A la fin de ce "cycle de développemnt", entre 15 et 100 personnes ont eu le code, Soit mais pour ma part comme bon nombre de mes confrères l'échange/le
partage et surtout la publication doit être encadrée.
mais le RSSI de base qui lit Bugtraq n'est pas encore au courant. C'est pas le plus important pour lui. Ses priorités, sa fonction & son
rôle sont ailleurs.
C'est la vie, c'est comme ça, Bruno ... Je ne suis pas de ton avis.
Ces données sensibles doivent rester dans une communauté de users identifiés.
Et moi je veux un réseau plus sûr pour demain.
Quant à la notion d'irresponsabilité, je trouve qu'un des aspects légaux faisant le plus défaut en France est une loi protégeant juridiquement les personnes qui signalent les faillds aux éditeurs, webmasters et admins. Définir des règles entre nous (les acteurs de la SI/SSI) ok.
Je te rappelle quand même que le cadre légal existe. Simplement parfois (moins dorénavant) certains oublient qu'avant de publier une faille on informe l'éditeur/CERTs.
Un gars qui fait de la sécurité applicative (comme moi) trouve en moyenne, et sans trop chercher, 1 à 5 failles par mois sur des sites qu'il *utilise à titre personnel* (banque en ligne, site "compagnon" d'un bouquin, mutuelle, ...). Dois-je te rappeler les règles déontologiques des tests intrusifs ?
A chaque fois, je stresse pour remonter ces failles, en essayant d'éviter le doux son de la BEFTI qui tape à la porte au p'tit matin. Du coup, quand c'est trop sensible, je ferme ma gueule et laisse la faille en l'état. Contactes et prends RDV avec la DCSSI.
D'autre part, si tu respectes les règles de base du métier je ne vois pas pourquoi tu devrais stresser ou être emmerder.
LaDDL
Nicob wrote:
[...]
Tu veux que je mette un reverse-proxy devant mon serveur JABd, c'est ça ? Mais non lol.
Je formule ma question autrement : As-tu auditer/tester un réseau dont l'architecture comprenait un ou plusieurs reverse proxies ?
[...]
Nicob wrote:
[...]
Tu veux que je mette un reverse-proxy devant mon serveur JABd, c'est ça ?
Mais non lol.
Je formule ma question autrement :
As-tu auditer/tester un réseau dont l'architecture comprenait un ou
plusieurs reverse proxies ?
