Franck Joncourt wrote:
On Wed, May 16, 2007 at 07:54:59AM +0200, Benjamin RIOU wrote:
(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
On Sun, May 20, 2007 at 01:15:21PM +0200, mouss wrote:
Franck Joncourt wrote:
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 Sun, 20 May 2007 13:15:21 +0200
mouss [EMAIL PROTECTED] a écrit:
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh.
depuis que j'ai bougé le port, j'en vois plus (plus que des logs
iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Ponctuellement,
On Sun, May 20, 2007 at 02:33:02PM +0200, François Boisson wrote:
Le Sun, 20 May 2007 13:15:21 +0200
mouss [EMAIL PROTECTED] a écrit:
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh.
depuis que j'ai bougé le port, j'en vois plus (plus que des logs
iptables). ça ne
Le Sun, 20 May 2007 13:35:26 +0200,
Franck Joncourt [EMAIL PROTECTED] a écrit :
Moi j'ai mis en place du port knocking pour le SSH,
Si j'ai compris, ca consiste à se connecter à une série de ports
diverses pour déclancher l'état OPEN sur le port SSH ?
++
Ben
--
Le moi intérieur : Tu regardes
On Sun, May 20, 2007 at 04:04:51PM +0200, Benjamin RIOU wrote:
Le Sun, 20 May 2007 13:35:26 +0200,
Franck Joncourt [EMAIL PROTECTED] a écrit :
Moi j'ai mis en place du port knocking pour le SSH,
Si j'ai compris, ca consiste à se connecter à une série de ports
diverses pour déclancher
On Wed, May 16, 2007 at 12:03:33AM +0200,
François Boisson [EMAIL PROTECTED] wrote
a message of 33 lines which said:
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
On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson [EMAIL PROTECTED] 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
Le Wed, 16 May 2007 08:05:04 +0200
Stephane Bortzmeyer [EMAIL PROTECTED] a écrit:
On Wed, May 16, 2007 at 12:11:31AM +0200,
François Boisson [EMAIL PROTECTED] wrote
a message of 25 lines which said:
J'ai du mal à croire qu'un gars ait dix mille machines à sa
disposition pour te
On Wed, May 16, 2007 at 10:06:11AM +0200,
François Boisson [EMAIL PROTECTED] wrote
a message of 38 lines which said:
Il ne manque que le prix de location et l'endroit où trouver cela.
La mafia russe ne pratique pas la transparence tarifaire :-) Quant aux
endroits pour trouver cela, je
Bonsoir à tous,
Finalement, c'est Benjamin Riou
(http://lists.debian.org/debian-user-french/2007/05/msg00765.html) qui,
j'espère, m'a mis sur les rails pour trouver une solution. J'espère
parce que l'attaque s'est arrêtée (jusqu'à la prochaine fois...). Comme
quoi, une probable connerie n'en est
On Wed, May 16, 2007 at 07:54:59AM +0200, Benjamin RIOU wrote:
(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
Le Wed, 16 May 2007 21:25:55 +0200
Franck Joncourt [EMAIL PROTECTED] 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.
On Wed, May 16, 2007 at 09:32:14PM +0200, François Boisson wrote:
Le Wed, 16 May 2007 21:25:55 +0200
Franck Joncourt [EMAIL PROTECTED] 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
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
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
Bonsoir à tous,
La discussion continue, c'est cool :-)
Quelques précisions, adaptées à et motivées par ce cas précis.
Pourquoi je n'ai pas retenu la solution Redirect ? Parce que cela
m'oblige à potentiellement renvoyer une information à l'attaquant,
dévoilant par là même ma stratégie de défense
Jean Baptiste Favre, mercredi 16 mai 2007, 23:17:50 CEST
Bonsoir à tous,
’soir,
[...]
port 8040.
[...]
(Ça c’est de la citation ;o)
Ça ne gêne pas tes clients ce port non standard ? (Personne
n’est filtré ?)
--
Sylvain Sauvage
Bonsoir à tous,
De petits rigolos s'amusent à ouvrir des connections TCP sur mon serveur web
sans envoyer de requêtes.
Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière.
Le problème et que j'ai une appli un peu lourde qui nécessite un timeout
d'apache à 25 minimum.
J'ai beau chercher, je ne
PROTECTED]
A : Jean-Baptiste FAVRE [EMAIL PROTECTED]
Copie à :
Objet : Re: Protection contre un DDOS tcp open
Salut !
Que penses tu de limiter le nombre connexion par IP avec connlimit (si
les attaques sont issues d'un sous réseau IP défini) ou bien avec le
module recent d'iptables
Le 15/05/07, Jean-Baptiste FAVRE[EMAIL PROTECTED] a écrit :
Salut,
En fait, déjà envisagé mais, j'aurais dû le préciser dans mon premier mail
désolé, une dizaine de milliers d'IP (heureusement pas simultanées) provenant
d'une 30aine de pays différents...
Un peu dur à gérer :-)
Merci quand
On Tue, May 15, 2007 at 06:47:53PM +0200,
Jean-Baptiste FAVRE [EMAIL PROTECTED] wrote
a message of 13 lines which said:
Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière.
Les SYN cookies, sans hésiter.
syncookies=yes dans /etc/network/options et redémarrage (ou bien
sysctl à la main).
--
Salut,
Stephane Bortzmeyer a écrit :
Jean-Baptiste FAVRE [EMAIL PROTECTED] wrote :
Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière.
Les SYN cookies, sans hésiter.
Si je ne m'abuse, les SYN cookies ne protègent que contre les connexions
half-open (pas de ACK en réponse au SYN-ACK).
On Tue, May 15, 2007 at 11:11:25PM +0200,
Pascal Hambourg [EMAIL PROTECTED] wrote
a message of 26 lines which said:
Si je ne m'abuse, les SYN cookies ne protègent que contre les
connexions half-open (pas de ACK en réponse au SYN-ACK).
Hmmm, oui, en relisant le message originel, en effet.
On Tue, May 15, 2007 at 08:13:39PM +0200,
Benjamin RIOU [EMAIL PROTECTED] wrote
a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP
simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple
Je fais une réponse un peu groupée:
Netfilter Recent: pourquoi pas mais il faudrait alors que je marque les
connexions ouvertes et que je guette le paquet suivant dans une fenêtre
de temps définie. Reste qu'Apache prendra quand même la connexion
(puisqu'ouverte), et la fenêtre de temps pourrait
Stephane Bortzmeyer a écrit :
syncookies seriously violate TCP protocol,
C'est très discuté.
do not allow to use TCP extensions,
C'est exact. Qui utilise ces options ? Qui les a déjà vues dans un
paquet réel ?
L'option MSS ? Tout le monde, non ?
--
Lisez la FAQ de la
Les SYN-Cookies sont déjà activés, sans problèmes (effets de bord)
jusqu'à présent.
Merci quand même,
JB
Stephane Bortzmeyer a écrit :
On Tue, May 15, 2007 at 11:11:25PM +0200,
Pascal Hambourg [EMAIL PROTECTED] wrote
a message of 26 lines which said:
Si je ne m'abuse, les SYN cookies ne
Re,
J'avais oublié le filtrage de couche 7:
Vu qu'aucune requête HTTP ne parvient au serveur, je risque d'avoir un
peu de mal :-)
Le fond du problème est donc bien de détecter qu'une connexion TCP
légitime au sens TCP du terme ne l'est plus au niveau applicatif car
aucune requête HTTP n'est
On Tue, May 15, 2007 at 10:40:17PM +0200, Stephane Bortzmeyer wrote:
On Tue, May 15, 2007 at 06:47:53PM +0200,
Jean-Baptiste FAVRE [EMAIL PROTECTED] wrote
a message of 13 lines which said:
Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière.
Les SYN cookies, sans hésiter.
On Tue, May 15, 2007 at 11:15:52PM +0200, Stephane Bortzmeyer wrote:
On Tue, May 15, 2007 at 11:11:25PM +0200,
Pascal Hambourg [EMAIL PROTECTED] wrote
a message of 26 lines which said:
Si je ne m'abuse, les SYN cookies ne protègent que contre les
connexions half-open (pas de ACK en
On Tue, May 15, 2007 at 11:29:09PM +0200, Pascal Hambourg wrote:
Stephane Bortzmeyer a écrit :
syncookies seriously violate TCP protocol,
C'est très discuté.
do not allow to use TCP extensions,
C'est exact. Qui utilise ces options ? Qui les a déjà vues dans un
paquet
Le Tue, 15 May 2007 23:28:46 +0200
Jean Baptiste Favre [EMAIL PROTECTED] a écrit:
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3
connexions simultanées depuis la même IP. En fait, le problème est
qu'Apache attend sagement le timeout (et je ne peux pas le baisser,
Ces
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.
Je viens de voir que le ACK est renvoyé par le client à chaque fois (tu as
donc SYN-- ,
On Tue, May 15, 2007 at 11:19:16PM +0200, Stephane Bortzmeyer wrote:
On Tue, May 15, 2007 at 08:13:39PM +0200,
Benjamin RIOU [EMAIL PROTECTED] wrote
a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP
simultanées pour chaque IP (voir le
On Wed, May 16, 2007 at 12:03:33AM +0200, François Boisson wrote:
Le Tue, 15 May 2007 23:28:46 +0200
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
Jean Baptiste Favre a écrit :
Le fond du problème est donc bien de détecter qu'une connexion TCP
légitime au sens TCP du terme ne l'est plus au niveau applicatif car
aucune requête HTTP n'est envoyée dans un délai à définir (AMHA
inférieur à 5 secondes en étant généreux).
Oui, et qui est
S'il n'y a pas de point commun entre les adresses IP sources, je vois
mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peut
apporter dans la mesure où le mal est fait : la connexion est établie,
occupant des ressources du serveur, et plus aucun paquet n'est transmis.
(ce qui
38 matches
Mail list logo
