Perte de connexion sur un interface suite à attaque ?
-
PFsense : ( virtualisé sous proxmox, sans aucun problemes de se genre depuis 1an)
Version 2.4.4-RELEASE-p2 (amd64)
Basé sur Wed Dec 12 07:40:18 EST 2018 FreeBSD 11.2-RELEASE-p6
Type de CPU Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
4 CPUs: 1 package(s) x 4 core(s) AES-NI CPU Crypto: Yes (active)
Encryption matérielle AES-CBC,AES-XTS,AES-GCM,AES-ICM
Noyau PTI ActivéBonjour, j'observe depuis peu des attaques ponctuelles aux concours de circonstance très inquiétant:
Côté WAN :
2019-10-01 12:24:17 1 UDP A Network Trojan was detected 3.80.190.130 53 myExternalIP 40537 1:2018455 ET TROJAN DNS Reply Sinkhole - Anubis - 195.22.26.192/26côté LAN :
2019-10-01 12:24:17 1 UDP A Network Trojan was Detected 3.80.190.130 53 MyFileServerInternalIP 64439 :2018455 ET TROJAN DNS Reply Sinkhole - Anubis - 195.22.26.192/26.Ceci, chronologiquement ,suite à un utilisateur interne qui abuse clairement de P2P. Pile au moment de l'attaque plus d'enregistrement P2P. mais plus d’accès WAN par l'interface externe non plus.
Le plus inquiétant est que cet IP n'existe pas, c'est donc clairement du spoofing. et qu'il traverse le par feu alors que toutes connexions entrante sont refusé.
Il ma fallu désactiver et réactiver l'interface via la config Pfsence pour retrouver une communication WAN. J'ajouterais que le routeur externe de mon fournisseur d’accès n'a apparemment
pas enregistré de problèmes pour lui.Avons nous une piste sur la méthode de se prémunir contre ce genre de chose? Avez vous l’expérience nécessaire pour m'aider a solutionner ceci ? merci d'avance.
-
Bien évidemment, la description est TRES TRES faible et notablement insuffisante pour aider un lecteur à deviner (parce que comprendre n'est pas le verbe adapté).
Le firewall est virtualisé
On va supposer que l'installation est correcte, mais c'est totalement sans garantie ! Si l'installation était physique, on pourrait avoir une petite certitude, mais je suis sûr que de ce que je vois !Comment détecter vous ce phénomène ?
Je suppose que c'est le package snort installé sur le firewall !
Comme il écoute sur toutes les interfaces, on ne peut savoir si c'est un paquet de WAN (qui sera rejeté) ou un paquet venant de LAN. Comme d'hab, absence de compréhension de l'inefficacité de placement d'une sonde sur un firewall : une sonde DOIT être en deça du firewall !Port d'attaque : 53
Une attaque sur 53 (tcp ou udp) = une attaque sur dns. Un flux dns entrant ??? Gérer en interne un dns public est une erreur sérieuse, pourtant facile à éviter.Concernant le trafic DNS, les bonnes pratiques et assez évidentes : une seule machine interne doit être autorisée à accéder à dns et, de préférence, uniquement aux dns du fai. les machines internes ne doivent pas résoudre avec un serveurs dns externes. Idéalement, il faudrait vérifier de temps en temps les requêtes dns effectuées : y a-t-il des noms dns bizarres ? (Je ne connais pas d'autres serveur dns que Bind capable de lister les noms résolus). Encore idéalement, 2 serveurs dns : l'un, qui résout les noms internes et est celui de référence pour les pc et serveurs internes, l'autre sui sert au premier à résoudre depuis l'externe (et n'est pas accessibles aux autres pc et serveurs internes). Enfin, ce dernier est le seul autorisé à causer aux dns du FAI, et idéalement en dnssec. Rien que de très évident à écrire, pas forcément simple à réaliser ...
-
@megs said in Perte de connexion sur un interface suite à attaque ?:
Le plus inquiétant est que cet IP n'existe pas, c'est donc clairement du spoofing
Je ne suis pas certain de comprendre de quelle ip il s'agit.
La 3.80.190.130 fait partie du réseau AWS
La 195.22.26.192 est chez Claranet.
Celle de Claranet est renseignée pour avoir fait transiter récemment (détection de puis le 27/9) des malwares. Comprendre des trojan ont été téléchargés depuis cette ip.il traverse le par feu alors que toutes connexions entrantes sont refusé.
Je ne suis pas certain de vous suivre dans vos analyses. Et encore moins sur le fait que les interfaces de pFsense soient mises hors d'usage par le télépchargement éventuel d'un fichier compromis.
Au fait d'où viennent ces informations : UDP A Network Trojan was Detected ?La première méthode serait de s'assurer de la bonne qualité de l'infrastructure réseau, de la pertinence de sa mise en œuvre puis de l'adéquation des moyens de protection.
-
"On va supposer que l'installation est correcte, mais c'est totalement sans garantie ! Si l'installation était physique, on pourrait avoir une petite certitude, mais je suis sûr que de ce que je vois !"-> j’aurais dit la même chose, je valide..
quel données souhaiterais tu avoir pour comprendre sans compromettre la sécurité " toute relative" de la chose ? on s'entend bien là dessus.
L'installation est de mon point de vue correcte( relativisons ), la pfsense à très bien fonctionné pendant un an sans ce genre de problème. une autres VM mineure est abrité par l'hyperviseur (utilisant conjointement l'interface physique et consommant très peu de volume réseau) et aucune coupure d'interface n'est enregistré chez elle. selon cette donnée il semble que le problème se cantonne à la VM de la pfsense.
Mieux , il ma fallu désactiver réactiver le port concerné dans les paramètres pfsense pour que tout revienne à la normale ( donnée qui a elle seule cantonne le problème au niveau de la PF, ou de la gestion des interfaces de celle-ci, si vous voyez d'autres ouvertures je suis tout ouie).Je complete mes precedentes informations concernant les detections: les deux detections se valident l'une l'autre et concerne probablement le même paquet. Le premier est reçu d'un IP foireux et abouti sur un port externe de la PF côté WAN, le second repart de la PF côté LAN et est destiné à un serveur de fichier en interne.
Les machines internes résolves avec leurs DNS internes (AD) qui translatent vers l'externe, les LAN qui ne sont pas dépendants d'un AD translatent vers le resolveur de la PF.
Je complète mes précédentes informations concernant les détections-*( snort ): les deux detections se valident l'une l'autre et concernent probablement le même paquet. Le premier est reçu d'un IP foireux et abouti sur un port externe de la PF côté WAN, le second repart de la PF côté LAN et est destiné à un serveur de fichier en interne. plutôt inquiétant de premier abord. mais en fait, j'ai sur ce serveur un service DNS d'appoint. ce qui pourrait expliquer notre affaire. celui-ci est pourtant configuré pour aller chercher vers les DNS AD qui l'entourent pas en externe.
Pour la désactivation de l'interface, j'entends coupure d’accès web/externe. Mais j'ai aussi des incohérences de routage et de par feu ne interne. comme si d'un coup, malgré les regles établis, PAF, les LAN ne se voient plus entre eux. notamment les LAN 1,2 ne peuvent plus accéder au LAN des services. en revanche la pate externe sur l'interface ADSL continue de fournir l'acces a certains services internet. c'est quelque peu perturbant. Comme si il y avait un ramdam monstrueux dans la config. comme ça d'un coup.
(pas eu le temps de faire une vérification de paramètres actif en ligne de commande). Mais il est clair que les paramètres actifs ne sont plus alors le reflet des paramètres configuré sur l'interface PF. Accessoirement j'ai aussi des groupements de passerelles et des sorties priorisé en fonction du service qui explique que l'adsl fonctionne encore. Peu être ais je mal configuré ses derniers qui réagissent mal aux coupures ou latences excessives ( pourquoi pas dûe à un excès de p2p ).
hmmm, peut être bien finalement... que l'un n'a rien a voir avec l'autre en effet. merci ccnet et jdh pour les fils conducteurs. -
Concernant la virtualisation,
Il est TOUJOURS préférable d'avoir un firewall physique (appliance ou serveur dédié) avec suffisament d'interfaces ethernet pour les multiples wan (1 wan = 1 interface = 1 câble de couleur précise) ainsi qu'au moins une interface pour les réseaux internes LAN, DMZ, SRV, ... (idéalement une interface par réseaux internes)
Je préconiserais pour Proxmox, une interface ethernet physique par réseaux internes, de préférence. Cela simplifie la lecture de l'interface par rapport à une interface correspondant à un vlan.Concernant Snort,
Vous citez 2 alertes et vous indiquez les mêmes données ... qui concernent un flux improbable (dns entrant). C'est encore la démonstration que la sonde n'est pas bien située : si la sonde était en deça du firewall, il n'y aurait sans doute pas d'alertes !La sécurité, c'est d'abord savoir ce qu'on veut, et en particulier être capable de l'exprimer clairement : si c'est clair dans sa tête, si c'est clair dans les mots et dans le texte, c'est plus facile d'y arriver.
La sécurité doit être explicite : on interdit tout par défaut, et on précise ce qui est autorisé explicitement. En particulier, les flux entrants sont TRES limités. Il me parait hautement improbable que vous ayez du dns entrant ! Mais les flux sortants doivent aussi être limités : un seul serveur peut requêter du dns, et encore vers des serveurs définis, idem pour http/https/ftp, smtp sauf la destination.
La règle à supprimer DE BASE est tout est autorisé en sortie : une fois cette règle supprimé, tout est plus facile ...On est assez loin de cela : je ne comprends pas beaucoup tout ce que vous écrivez ...
-
Je suis désolé mais je ne comprend pas grand chose à ces explications.