2010/12/4 Prune <[email protected] <mailto:[email protected]>>
On 4 déc. 2010, at 17:59, Hugo Deprez wrote:
> Bonjour à tous,
>
>
> je subis comme je l'imagine 99% des équipements connectés à
internet des scan de port sur mon firewall depuis diverses IP.
> Je ne sais pas trop comment traiter ce genre de risques, surtout
que j'ai remarqué que beaucoup de scan sont effectués depuis un
proxy cache03.msr.oleane.net...
> Je ne peux donc pas dropper tous les paquets provenant de cette IP.
>
> Comment réagissez vous devant ces scans ? Quelles sont les
bonnes pratiques ?
>
> D'avance merci pour votre retour d'expérience !
>
> Hugo
>
2010/12/4 Prune <[email protected] <mailto:[email protected]>>
Bloquer l'IP pendant un certain temps, déclenché sur une règle de
ton choix, du genre X ports différents en Y secondes ?
Des outils "unix" existent pour cela, plus des centaines de
scripts de firewall utilisables avec les firewall linux, sans
parler des grands fabriquant qui ont tous ce genre de fonction (ou
pas).
Apres j'ai envie de dire ça dépend du matériel que tu utilise... ?
--
Prune
Le 05/12/2010 18:18, Hugo Deprez a écrit :
Bonjour,
Le problème de bloquer l'ip c'est les effets de bords, si jamais cette
IP provient d'un serveur proxy par exemple...
Effectivement sous linux je connais par exemple fail2ban qui fait ce
genre de chose.
Dans mon cas j'utilise des firewall Checkpoint et Fortigate.
Hugo
Pour ce qui est du 'scan de port' (et uniquement des ports), à moins que
ce soit réélement énorme au point de faire chuter les performances, je
crois que peu de gens s'en préoccupent vraiment.
Par contre, pour protéger à minima les accès, oui, Fail2Ban sur les
machines unix-like est très bien car configurable "comme j'aime".
En cas d'un nombre d'echec d'authentification qu'on défini (1, 3, 10,
100..), il crée une regle drop dans iptable et quelque soit la requête
suivante ça fait un beau plouf.
Au bout du temps défini dans sa config, il retire la règle automatiquement.
Associé à une impossibilité de se connecter aux comptes sensibles depuis
une autre adresse que localhost, donc l'obligation d'être d'abord loggé
en utilisateur simple avant de faire un su -, ça limite fortement la casse !
Par contre, on à subit une attaque récemment que l'on attendait pas
sur... du compte SIP !! Fail2Ban n'était pas en mesure d'appliquer sa
surveillance ici.
Moralité, que le système soit protégé, verrouillé et blindé, on oublie
toujours un truc, donc, garder un oeil sur les logs reste une mesure
importante pour les machines sensibles :D
Alex.
