Re: Protection contre un DDOS tcp open
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 ('tain, ça fait riche la
phrase là. J'vais la noter pour quand je ferai consultant :-) ).
Accessoirement, cela oblige à ouvrir à tout va le port xxxx sur lequel
écoute HTTPD. Donc accessible aussi au méchant.
Pourquoi je n'ai pas retenu la solution RewriteRules ? Pour diverses
raison, par exemple parce que la solution proxy est plus complète, plus
souple et permet un plus grand contrôle, parce que je ne connais que
très mal les RewriteRules, ...
Pourquoi je n'ai pas retenu la solution Iptables/* ? Parce que cela ne
règle pas le problème puisque les connexions parviennent au serveur
HTTP, ce que je veux à tout prix éviter.
Pourquoi j'ai finalement retenu la solution proxy (sous réserve des
tests) ? Parce qu'elle répond à mon besoin sans dévoiler d'informations
à l'attaquant qui n'aura qu'une seule porte d'accès au système: le
proxy. Reste à trouver un proxy qui tienne la charge (pound et/ou
haproxy en phase de tests).
Si vous avez d'autres idées, je suis preneur évidemment :-)
Bon week-end,
JB
Benjamin RIOU a écrit :
>> 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.
>
> je n'ai pas compris comme toi.
> Le client ouvre une connexion vers le port 80.
> Le port 80 lui renvoie une erreur 304 : Moved Permantly (@ip : 8040).
> ** Point barre. Une unique connexion vers le port 80 et un timeout très
> court.
> Y a rien de renvoyé en local ou quoi que ce soit.
>
> Le client ouvre une connexion une connexion vers le port 8040, et est
> connecté au serveur.
>
> Le botnet ne faisant pas de requete GET /,
> Jean Baptiste a choisi de le localiser les mauvaises connexions de
> cette manière.
> Ce qui revient à faire un filtrage de couche 7 (conso CPU en montée en
> charge ?)
>
> ++
> Ben
Reply to: