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 :)
