Bloquer les scans
-
Bonjour,
Nouveau utilisateur de pfsense je m'interroge sur plusieurs points.
Je surveille le traffic tous les jours et notamment les logs firewall.
Je suis effaré par le nombre de scans de ports.
Plusieurs questions :- est-il possible de bloquer pendant plusieurs heures une ip qui à fait au moins un scan de port qui est fermé ?
- dans les logs j'ai souvent cette ligne qui revient WAN2 | 10.0.0.0 | 224.0.0.1 | IGMP. Qu'est-ce que c'est ?
- je reçois des scans "w00tw00t" dans mes logs apache. Est-ce possible de les bloquer avec pfSense ?
J'ai installé snort et configuré des règles.
Quand snort est lancé je vois bien les 2 croix rouges qui me permettrait d'arrêter snort et c'est marqué ENABLED à côté.
Ce soir j'ai retrouvé l'écran snort avec la flèche verte mais toujours marqué ENABLED à côté.
Par contre dans les alertes de snort il y avait ceci "BAD-TRAFFIC potential dns cache poisoning attempt - mismatched txid"
Est-ce cette attaque qui a fait tomber la croix rouge ?Merci pour vos réponses.
Nicolas
-
J'y reviendrai plus longuement mais rapidement pour ce soir : quels sont vos enjeux de sécurité derrière de ce Pfsense ?
Juste histoire d'être cohérent entre l'artillerie à déployer et l'importance stratégique de la place. Du côté du commandement l'expérience ne semble pas énorme. -
Ce pfSense est en première ligne d'une infrastructure web.
Derrière nous avons un reverse proxy apache puis un serveur web et enfin un serveur de base de données.
Il y a donc un extranet web, mais aussi un serveur de mail et un serveur FTP.
pfSense sert également de serveur OpenVPN (bien pratique).Je reconnais volontier mon manque d'expérience dans la gestion de la sécurité c'est pour cela que je me permet de poser quelques questions sur ce forum.
J'espère avoir correctement répondu à ta question.
-
Mon conseil à propos de cette architecture et de sa sécurisation :
Si ce n'est pas fait, répartir les composant dans des zones distinctes, accessibles seulement en passant par le firewall. Le reverse dans une dmz externe, le serveur web dans une dmz interne, le serveur de base de données dans un zone lan. Les noms sont arbitraires et à titre d'exemple.
Pour le mail : un relais en dmz externe, le serveur de mail en dmz interne.
Pour le ftp : le mieux est de s'en passer mais sinon en dmz externe ou interne si vous pouvez mettre un mandataire en dmz externe. Tout dépend de la nature du ftp.L'utilisation de Snort
Les scan de ports ne sont pas si graves après tout.
Snort fascine assez vite ceux qui le découvre. J'ai un peu écris sur le sujet sur ce forum je vous donne les liens :
http://forum.pfsense.org/index.php/topic,33047.0.html
http://forum.pfsense.org/index.php/topic,27400.0.html
http://forum.pfsense.org/index.php/topic,20304.0.html
http://www.snort.org/docs/iss-placement.pdfWAN2 | 10.0.0.0 | 224.0.0.1 | IGMP.
Vous avez une machine qui fait de la diffusion multicast. Rien de grave, juste du bruit.
http://fr.wikipedia.org/wiki/Internet_Group_Management_ProtocolAutre point à considérer, une gestion des logs centralisée et bien ciblée. Pour cela vous pouvez considérer PartyLog2 qui est une appliance vmware gratuite de GrayLog2. Une bonne gestion des logs est importante pour la sécurité.
Un lien qui vous intéressera sans doute :
http://spamcleaner.org/fr/misc/w00tw00t.htmlSegmentation et défense en profondeur !
On en reparle lorsque vous avez regardé toute cette littérature. -
Bonjour
Je te remercie pour tes réponses.
Pour pousser plus loin dans mes explications, pfSense est installé sur un environnement VMWare. C'est un cloud privé loué chez OVH.
J'ai installé pfSense en dépit d'avoir mieux. Je suis en attente d'une solution matérielle chez OVH.
De plus, OVH ne permet pas de créer des vLANs différents et donc de vraiment segmenter les différentes zones DMZ etc…
Je tout de même segmenté en mettant effectivement les reverses sur une patte bien distincte de pfSense appelée de façon très originale DMZ.
Par contre j'ai laissé sur la patte nommée LAN le serveur web et de base de données. J'avais pas poussé plus loin la segmentation.
Le serveur de mail est lui aussi en DMZ.
Le serveur FTP c'est pas encore installé. Il ne servira que de dépot de fichier. Un ETL va chercher régulièrement les fichiers déposés pour les traiter ailleurs.Pour snort, au vu des lectures, j'ai l'impression que c'est peut être un rouleau compresseur et pas forcément nécessaire sur notre infra... Je vais pousser mes recherches un peu pour voir.
En ce qui concerne la gestion des logs je n'avais pas du tout considéré la question.
J'ai une vm dédiée avec Nagios et Centreon qui surveille l'activité des machines mais pas les logs.
Je vais regarder car c'est intéressant.Merci beaucoup de ton aide.
Nicolas
-
Pour pousser plus loin dans mes explications, pfSense est installé sur un environnement VMWare. C'est un cloud privé loué chez OVH.
J'ai installé pfSense en dépit d'avoir mieux. Je suis en attente d'une solution matérielle chez OVH.Pfsense est un excellent produit mais clairement l'installation virtualisée relève considérablement le niveau de risque. Dans ce cas la solution matériel fournie par OVH est bien celle à privilégier. D'urgence. A défaut de cloisonnement, vous aurez du mal en empêcher les rebonds en cas de compromission d'une machine, vous pouvez toujours "firewaliser" chaque machine.
On oublie souvent de veiller à la bonne exploitabilité des logs.
Vous avez un ESX de base chez OVH ? La version sous licence permet d'utiliser Vshield. Pensez aussi à durcir votre esx.
-
Effectivement toutes les VM windows 2008 R2 ont le firewall et les VM linux sont avec Iptables d'activé.
Je vais me pencher sur vShield
Merci
-
Bonjour,
Merci beaucoup pour votre aide !
Je pensais que je n'avais pas l'option vShield mais si (puisque j'ai des Host L+). C'est juste OVH qui avait oublié de l'activer sur mon compte du coup je ne voyais pas l'onglet dans mon vSphere.
Je l'ai donc configuré hier.
Depuis, presque plus rien dans les logs de pfSense.
Juste ce genre de choseJul 19 10:16:16 | WAN2 | 115.126.199.77 | mon ip publique | ICMP
Jul 19 09:47:05 | WAN | 69.175.126.170:41612 | mon ip publique:137 | UDP
Jul 19 09:46:31 | WAN2 | 69.175.126.170:41612 | mon ip publique 2:137 | UDPQu'entendez-vous par "durcir" les ESX ?
Merci pour vos réponses
-
Durcir un esx c'est appliquer certains paramètres de configuration, comme desactiver les changements d'adresses mac. Il y a un doc là dessus sur le site de Vmware. Ensuite il y a plus sophistiqué mais on entre dans le spécifique. Pas d'utilisation de root en ssh sans authentification forte, analyser les flux vmware utiles et leur cloisonnement, désactiver snmp, attention à ntp, etc …