Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la
réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui
revient. Il y a donc de grande chances que l'IP d'origine soit
fausse.
Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la
réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui
revient. Il y a donc de grande chances que l'IP d'origine soit
fausse.
Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la
réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui
revient. Il y a donc de grande chances que l'IP d'origine soit
fausse.
J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te polluer mais je ne comprends pas comment il
fait...
J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te polluer mais je ne comprends pas comment il
fait...
J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te polluer mais je ne comprends pas comment il
fait...
On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson wrote
a message of 25 lines which said:
> J'ai du mal à croire qu'un gars ait dix mille machines à sa
> disposition pour te polluer mais je ne comprends pas comment il
> fait...
C'est un petit botnet. Les plus gros font plus de cent mille
machines. « A botnet is comparable to compulsory military service for
Windows boxes » (Stromberg)
Voir l'excellent article de Honeynet « Know your Enemy »
http://www.honeynet.org/papers/bots/
On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson <user.anti-spam@maison.homelinux.net> wrote
a message of 25 lines which said:
> J'ai du mal à croire qu'un gars ait dix mille machines à sa
> disposition pour te polluer mais je ne comprends pas comment il
> fait...
C'est un petit botnet. Les plus gros font plus de cent mille
machines. « A botnet is comparable to compulsory military service for
Windows boxes » (Stromberg)
Voir l'excellent article de Honeynet « Know your Enemy »
http://www.honeynet.org/papers/bots/
On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson wrote
a message of 25 lines which said:
> J'ai du mal à croire qu'un gars ait dix mille machines à sa
> disposition pour te polluer mais je ne comprends pas comment il
> fait...
C'est un petit botnet. Les plus gros font plus de cent mille
machines. « A botnet is comparable to compulsory military service for
Windows boxes » (Stromberg)
Voir l'excellent article de Honeynet « Know your Enemy »
http://www.honeynet.org/papers/bots/
Il ne manque que le prix de location et l'endroit où trouver cela.
Il ne manque que le prix de location et l'endroit où trouver cela.
Il ne manque que le prix de location et l'endroit où trouver cela.
Le Wed, 16 May 2007 08:05:04 +0200
Stephane Bortzmeyer a écrit:On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson wrote
a message of 25 lines which said:J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te polluer mais je ne comprends pas comment il
fait...
C'est un petit botnet. Les plus gros font plus de cent mille
machines. « A botnet is comparable to compulsory military service fo r
Windows boxes » (Stromberg)
Voir l'excellent article de Honeynet « Know your Enemy »
http://www.honeynet.org/papers/bots/
Merci de ce papier particulièrement complet, Il ne manque que le prix de
location et l'endroit où trouver cela. Je ne pensais pas que ce phé nomène
s'était généralisé à ce point.
Le problème consiste donc à différencier une connexion vivante d' une connexion
endormie et ce, juste après l'établissement de la dite connexion. J e ne vois
qu'une fonctionnalité de netfilter que je ne connaitrais pas ou un wr apper à
Apache (à faire)...
François Boisson
Le Wed, 16 May 2007 08:05:04 +0200
Stephane Bortzmeyer <stephane@sources.org> a écrit:
On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson <user.anti-spam@maison.homelinux.net> wrote
a message of 25 lines which said:
J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te polluer mais je ne comprends pas comment il
fait...
C'est un petit botnet. Les plus gros font plus de cent mille
machines. « A botnet is comparable to compulsory military service fo r
Windows boxes » (Stromberg)
Voir l'excellent article de Honeynet « Know your Enemy »
http://www.honeynet.org/papers/bots/
Merci de ce papier particulièrement complet, Il ne manque que le prix de
location et l'endroit où trouver cela. Je ne pensais pas que ce phé nomène
s'était généralisé à ce point.
Le problème consiste donc à différencier une connexion vivante d' une connexion
endormie et ce, juste après l'établissement de la dite connexion. J e ne vois
qu'une fonctionnalité de netfilter que je ne connaitrais pas ou un wr apper à
Apache (à faire)...
François Boisson
Le Wed, 16 May 2007 08:05:04 +0200
Stephane Bortzmeyer a écrit:On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson wrote
a message of 25 lines which said:J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te polluer mais je ne comprends pas comment il
fait...
C'est un petit botnet. Les plus gros font plus de cent mille
machines. « A botnet is comparable to compulsory military service fo r
Windows boxes » (Stromberg)
Voir l'excellent article de Honeynet « Know your Enemy »
http://www.honeynet.org/papers/bots/
Merci de ce papier particulièrement complet, Il ne manque que le prix de
location et l'endroit où trouver cela. Je ne pensais pas que ce phé nomène
s'était généralisé à ce point.
Le problème consiste donc à différencier une connexion vivante d' une connexion
endormie et ce, juste après l'établissement de la dite connexion. J e ne vois
qu'une fonctionnalité de netfilter que je ne connaitrais pas ou un wr apper à
Apache (à faire)...
François Boisson
(ce qui suit est probablement une immense connerie)
Mettons que ton service à contacter sur le port 80.
Serait-il possible de faire une erreur 301 "Moved Permanantly" vers
un autre port ?
Je m'explique,
X se connecte à ton serveur sur le port 80. Il fait un GET /
La page lui répond d'aller voir sur le port 8040, sur laquelle ton
serveur est doresetnavant.
X se connecte alors au 8040 et tout va bien.
Formidable.
Maintenant, le bot va pas aller sur le port 8040 car il fait pas de
requette HTTP.
Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port
80, et un timeout plus long sur le 8040.
Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être
jetté sur le champ.
Qu'est-ce que t'en penses ?
(ce qui suit est probablement une immense connerie)
Mettons que ton service à contacter sur le port 80.
Serait-il possible de faire une erreur 301 "Moved Permanantly" vers
un autre port ?
Je m'explique,
X se connecte à ton serveur sur le port 80. Il fait un GET /
La page lui répond d'aller voir sur le port 8040, sur laquelle ton
serveur est doresetnavant.
X se connecte alors au 8040 et tout va bien.
Formidable.
Maintenant, le bot va pas aller sur le port 8040 car il fait pas de
requette HTTP.
Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port
80, et un timeout plus long sur le 8040.
Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être
jetté sur le champ.
Qu'est-ce que t'en penses ?
(ce qui suit est probablement une immense connerie)
Mettons que ton service à contacter sur le port 80.
Serait-il possible de faire une erreur 301 "Moved Permanantly" vers
un autre port ?
Je m'explique,
X se connecte à ton serveur sur le port 80. Il fait un GET /
La page lui répond d'aller voir sur le port 8040, sur laquelle ton
serveur est doresetnavant.
X se connecte alors au 8040 et tout va bien.
Formidable.
Maintenant, le bot va pas aller sur le port 8040 car il fait pas de
requette HTTP.
Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port
80, et un timeout plus long sur le 8040.
Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être
jetté sur le champ.
Qu'est-ce que t'en penses ?
Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
8040, cela ne va pas aider. C'est un peut le meme principe que de faire
ecouter son serveur SSH sur un port different de 22 : aucun interet.
Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
8040, cela ne va pas aider. C'est un peut le meme principe que de faire
ecouter son serveur SSH sur un port different de 22 : aucun interet.
Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
8040, cela ne va pas aider. C'est un peut le meme principe que de faire
ecouter son serveur SSH sur un port different de 22 : aucun interet.
Le Wed, 16 May 2007 21:25:55 +0200
Franck Joncourt a écrit:
> Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
> 8040, cela ne va pas aider. C'est un peut le meme principe que de faire
> ecouter son serveur SSH sur un port different de 22 : aucun interet.
Si, dès que le client fait une requête quelle qu'elle soit, le serveur renvoit
la requête en local sur le port 8040. Cela permet de faire un traite ment
différent ET automatique aux connexions suivies d'un GET /?? et aux simples
connexions ouvertes sans effet.
Le Wed, 16 May 2007 21:25:55 +0200
Franck Joncourt <franck.joncourt@wanadoo.fr> a écrit:
> Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
> 8040, cela ne va pas aider. C'est un peut le meme principe que de faire
> ecouter son serveur SSH sur un port different de 22 : aucun interet.
Si, dès que le client fait une requête quelle qu'elle soit, le serveur renvoit
la requête en local sur le port 8040. Cela permet de faire un traite ment
différent ET automatique aux connexions suivies d'un GET /?? et aux simples
connexions ouvertes sans effet.
Le Wed, 16 May 2007 21:25:55 +0200
Franck Joncourt a écrit:
> Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
> 8040, cela ne va pas aider. C'est un peut le meme principe que de faire
> ecouter son serveur SSH sur un port different de 22 : aucun interet.
Si, dès que le client fait une requête quelle qu'elle soit, le serveur renvoit
la requête en local sur le port 8040. Cela permet de faire un traite ment
différent ET automatique aux connexions suivies d'un GET /?? et aux simples
connexions ouvertes sans effet.
> Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET qui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion directeme nt
sur le port 8040.
> Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET qui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion directeme nt
sur le port 8040.
> Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET qui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion directeme nt
sur le port 8040.
> > > Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
> > 8040, cela ne va pas aider. C'est un peut le meme principe que de faire
> > ecouter son serveur SSH sur un port different de 22 : aucun interet.
>
> Si, dès que le client fait une requête quelle qu'elle soit, le serveur
> renvoit la requête en local sur le port 8040. Cela permet de faire un
> traitement différent ET automatique aux connexions suivies d'un GET /?? et
> aux simples connexions ouvertes sans effet.
Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET qui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion directement
sur le port 8040.
> > > Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
> > 8040, cela ne va pas aider. C'est un peut le meme principe que de faire
> > ecouter son serveur SSH sur un port different de 22 : aucun interet.
>
> Si, dès que le client fait une requête quelle qu'elle soit, le serveur
> renvoit la requête en local sur le port 8040. Cela permet de faire un
> traitement différent ET automatique aux connexions suivies d'un GET /?? et
> aux simples connexions ouvertes sans effet.
Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET qui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion directement
sur le port 8040.
> > > Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
> > 8040, cela ne va pas aider. C'est un peut le meme principe que de faire
> > ecouter son serveur SSH sur un port different de 22 : aucun interet.
>
> Si, dès que le client fait une requête quelle qu'elle soit, le serveur
> renvoit la requête en local sur le port 8040. Cela permet de faire un
> traitement différent ET automatique aux connexions suivies d'un GET /?? et
> aux simples connexions ouvertes sans effet.
Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET qui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion directement
sur le port 8040.