Re : [IPTABLES] Comment lister les paquets rejet és ?

[Florian <florian.blanc.adm@gmail.com>]

Si je comprend bien, vous avez un serveur web avec un cms type blog et vous avez des attaques sur votre backend. 

Car dans ce cas là, ma solution était de mettre votre répertoire d'administration en deny pour tous port 80 dans la conf de votre apache/nginx ou autre..

Vu que pour un système de blog les lecteurs n'ont pas besoin de SSL, vous pouvez vous le réserver. 

Parfait alors vous mettez également votre serveur web en écoute sur le port 443.

Maintenant je trouve assez sympa le principe de louer un NOIP pour que je puisse avoir un moyen de me faire identifier ..

Car maintenant ma règle est simple et efficace ... Je flush ma table "dynamique" créer exprès.  J'ai donc ma regle iptables qui vient ajouter le lookup de mon NOIP toute les 40 minutes pour le port 443.

Et je laisse mon client NOIP ouvert. Sinon je sais que au pire si je tombe à un mauvais moment, il faudra que j'attende 40 minutes ce qui n'est pas bien grave comparé ce dont je me débarrasse.

J'espère avoir bien compris votre situation :/

Cordialement

--
Florian

Le lundi 9 juin 2014 à 18:06, Philippe Gras a écrit :

Le 9 juin 14 à 17:15, Florian a écrit :

Et vis à vis des règles, toujours pour un service web, je serais plus d'avis à répondre par un bon 404 pour une requête demandant une ressource incorrecte simplement. Ensuite ça dépend ... Si tu n'as aucune page de login accessible en front, est-ce que le fait de répondre par un 404 simplement te coûte plus que de rejeter un packet filtré ? (Sachant que online et ovh fournissent la partie ddos). 

Ensuite oui, si tu as une page de connexion tu va obligatoirement "logger" et blacklister la source. 

(À savoir que ton backend n'a pas à être accessible par tout le monde).

Justement oui, j'ai un login sur le site qui a été attaqué la semaine dernière, et qui a motivé

mon intervention sur le serveur, l'édition des règles Iptables, et ma demande d'aide à cette

liste. J'ai un login et ça m'a coûté de laisser le bot attaquer la page de login parce que je ne

pouvais pratiquement plus naviguer sur le tableau de bord de l'administration de mon site.

Parce que là, on n'est plus dans le cas où le robot reçoit une 40X et passe son chemin !

Comme c'est la 2ème fois que cela m'arrive, ceci sans compter les fois où ça ramait de façon

anormale sans que je sache où aller chercher la bonne réponse, j'ai décidé de faire en sorte

que ça n'arrive pas une 3ème fois.

Je fais un peu de rédaction sur un blog qui est continuellement surchargé en backend. Je me

demande maintenant si mon cas est tellement isolé que ça ;-)

Attention aux réglages trop sophistiqués, au risque de laisser des trous dans votre muraille ou de perdre en efficacité.

Cordialement. 

Là dessus, complètement d'accord ! C'est ma politique également :-)

--
Florian

Le lundi 9 juin 2014 à 12:26, Florian Blanc a écrit :

Bonjour,

Tout d’abord je trouve ce topic plutôt sympa :)

Je viens juste ajouter ma petite expérience sur l’administration de serveurs DISTANTS.

Premièrement il ne faut laisser d’accessible que le strict minimum !

Dans le cas d’un service web (http) il ne faut donc que le 80 et peut-être le 443 en fonction des cas .. (pour le public).

Le backend web je le met accessible uniquement sur le port 2222 par exemple (avec SSL!).

Deux solutions, avoir un vpn dédié ou une IP fixe ou utiliser un service de DNS dynamique.

(préférer le dns dynamique que l’ip fixe car il aura les memes avantages que le vpn, c’est à dire utilisable meme si vous n’êtes pas chez vous).

J’ai préféré le DNS car je n’ai pas besoin de gérer les attaques sur le vpn :)

Donc à partir de là, dans mes règles iptables je n’autorise que mon dyndns sur le 22 et le 2222 (backend web ssl).

Comment je fais pour actualiser mon dyndns ?

dans mon crontab j’ai : */40 * * * * /etc/init.d/firewall-update-dynamics >/dev/null

Le fichier firewall-update-dynamics va être exécuté toute les 40 minutes.

et dans ce fichier on trouvera par exemple … 

/sbin/iptables -F INDYNAMIC

/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src MON-NO-IP.BIDULE --dport 22 -j ACCEPT

/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src MON-NO-IP.BIDULE --dport 2222 -j ACCEPT

Je suis preneur de toutes remarques.

Cordialement à tous et bon repos :)