PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Attention à ces clones de jeux sur le Microsoft Store : ils sont malveillants !

vendredi 25 février 2022 à 09:31

Un malware appelé Electron Bot a été découvert au sein de plusieurs jeux disponibles sur le Microsoft Store et qui sont des clones de jeux populaires. Des milliers de machines sont déjà infectées !

Imaginez la situation suivante : vous ouvrez le Microsoft Store à la recherche d'un nouveau jeu, et là, vous trouvez la perle rare, le jeu qui va vous faire votre soirée. Sauf qu'au lieu de récupérer uniquement le jeu, vous allez récupérer aussi un malware nommé Electron Bot ! Cela est d'autant plus dangereux et trompeur qu'il est distribué au sein de clones de jeux très populaires tels que Subway Surfer et Temple Run. Le schéma ci-dessous montre clairement la présence du Microsoft Store au tout début de la chaîne d'infection :

Electron Bot

D'après l'entreprise Check Point, le logiciel malveillant a déjà infecté plus de 5 000 machines en Suède, Israël, Espagne et aux Bermudes. Une fois en place sur une machine, il agit comme une porte dérobée qui donne un accès à distance aux pirates, notamment pour exécuter des commandes, mais aussi effectuer d'autres actions en temps réel. L'objectif étant d'utiliser Electron Bot pour agir sur vos comptes Facebook, Google, YouTube et Sound Cloud afin de commenter des publications et faire la promotion de contenus malveillants.

Cela fait trois ans que ce malware existe et qu'il évolue constamment, pour arriver à la version telle qu'elle est aujourd'hui. Codé en Electron, d'où ce nom, le malware est capable d'ouvrir un navigateur en arrière-plan puis de simuler une navigation Internet avec des clics, scroll, saisie au clavier, etc.

Ce qui est surprenant, mais compréhensible, c'est que les jeux malveillants ont des évaluations positives sur le Microsoft Store ! En effet, même si le jeu est infecté, cela n'empêche pas l'utilisateur de récupérer le jeu et d'en profiter ! Le malware quant à lui agit en tâche de fond et n'est pas forcément visible !

Les éditeurs suivants sont associés aux applications malveillantes qui circulent sur le Microsoft Store :

Avant de télécharger un paquet sur le Microsoft Store (ou ailleurs), pensez à vérifier les avis, mais aussi, et surtout, l'éditeur. Reste à voir comment Microsoft peut renforcer la sécurité de son côté également.

Source

The post Attention à ces clones de jeux sur le Microsoft Store : ils sont malveillants ! first appeared on IT-Connect.

Le ransomware Cuba s’en prend aux serveurs Exchange

vendredi 25 février 2022 à 08:23

Le ransomware Cuba exploite des vulnérabilités connues au sein de Microsoft Exchange pour obtenir un accès au réseau d'entreprises et chiffrer les machines une fois l'infrastructure compromise.

L'entreprise spécialisée en sécurité Mandiant, suit de près les activités du gang UNC2596 et de leur ransomware nommé COLDDRAW, bien connu sous le nom de Cuba. Il n'est pas nouveau puisqu'il est en activité depuis la fin 2019, et en 2021 il s'est montré particulièrement actif. À tel point que le FBI a émis un bulletin de sécurité au sujet du ransomware Cuba car ses auteurs ont compromis 49 organisations critiques aux États-Unis.

D'ailleurs, d'après le rapport de la société Mandiant, on peut voir qu'il agit surtout aux États-Unis et au Canada. Sa présence en Europe est relativement faible, mais il n'est pas à exclure que cela évolue.

Lorsque le serveur est compromis, une porte dérobée est installée sur le serveur, en s'appuyant sur deux outils : Cobalt Strike et NetSupport Manager, un logiciel de prise en main à distance. En complément, les pirates utilisent leurs propres outils :

Pour effectuer des mouvements latéraux sur l'infrastructure de la victime, ils s'appuient sur différentes méthodes et outils : RDP, SMB, PsExec et Cobalt Strike. Enfin, des données peuvent être exfiltrées vers la propre infrastructure des pirates, et non pas vers des services Cloud, avant que les données soient chiffrées par le ransomware Cuba.

Quelles sont les vulnérabilités utilisées ?

Lorsque l'on évoque la compromission d'un serveur de messagerie Exchange, il y a deux noms qui ressortent à chaque fois depuis l'année dernière : ProxyShell et ProxyLogon. Bingo ! Ces deux ensembles de vulnérabilités sont exploités par le gang UNC2596 afin de compromettre les serveurs Exchange.

D'ailleurs, ces failles de sécurité font partie du top 10 des vulnérabilités de 2021 selon l'ANSSI, et cela se confirme une fois de plus qu'elles sont très appréciées par les pirates. Il y a fort à parier qu'il existe encore des serveurs Exchange vulnérables un peu partout dans le monde, alors c'est l'occasion de faire une piqure de rappel sur la nécessité d'installer les correctifs disponibles depuis plusieurs mois.

Source

The post Le ransomware Cuba s’en prend aux serveurs Exchange first appeared on IT-Connect.

Top 10 des vulnérabilités de 2021, selon l’ANSSI

jeudi 24 février 2022 à 13:32

L'ANSSI a publié un rapport qui recense les 10 vulnérabilités les plus critiques de l'année 2021, et sur lesquelles a pu travailler l'ANSSI durant l'année passée.

Pour l'ANSSI, c'est également l'occasion de faire les comptes et de préciser qu'en 2021, le CERT-FR a publié 991 avis et 22 alertes concernant des vulnérabilités situées au sein de produits suivis par l'agence française. Quant au top 10 des vulnérabilités, il y a des noms qui vont forcément vous parler dans cette liste, notamment ProxyLogon, ProxyShell, PrintNightmare ou encore Log4Shell, cette dernière a fait beaucoup de bruit fin 2021.

Pour mettre fin au suspens, voici le top 10 des vulnérabilités de 2021 :

Les vulnérabilités ProxyLogon et ProxyShell affectent les serveurs de messagerie Exchange (versions 2010, 2013, 2016 et 2019) et elles ont fait de nombreuses victimes en 2021. En effet, un attaquant pouvait prendre le contrôle d'un serveur Exchange grâce à une exécution de code à distance, et au final devenir administrateur du domaine Active Directory. En vérité, derrière les noms ProxyLogon et ProxyShell se cachent un ensemble de 7 vulnérabilités.

Les vulnérabilités sont particulièrement critiques lorsqu'elles sont exploitables à distance, sans authentification, et qu'elles touchent des serveurs exposés sur Internet. C'est le cas de la vulnérabilité CVE-2021-26084 qui a touché la solution Confluence, où il y a eu des campagnes menées par des attaquants afin de détecter les serveurs Confluence exposés sur Internet. La vulnérabilité CVE-2021-22205 qui a touché GitLab est également un autre exemple, dans le même esprit.

Avant de vous laisser prendre connaissance du rapport complet de l'ANSSI, je suis obligé de vous (re)parler de deux vulnérabilités : PrintNightmare et Log4Shell. La première, baptisée "PrintNightmare" touche le service "Spouleur d'impression" de Windows et elle peut permettre à un attaquant d'obtenir les droits SYSTEM sur une machine, y compris un contrôleur de domaine, à partir du moment où le service est actif sur la machine. Rapidement patchée par Microsoft, elle est devenue un cauchemar pour de nombreuses entreprises et plus particulièrement les admins systèmes. En effet, Microsoft a publié plusieurs correctifs pour protéger les machines, mais ils ont créé d'énormes problèmes d'impression, notamment en réseau, au sein des entreprises. Une galère de plusieurs mois.

Et puis, pour finir l'année 2021 en beauté, nous avons eu le droit à cette faille de sécurité critique au sein de la bibliothèque Log4j, dévoilée en décembre 2021 et associée à un score CVSS de 10/10. Utilisée par énormément de sites, produits, et services, elle a littéralement secoué Internet. Parmi les entreprises concernées, nous pouvons citer Cisco, Bitdefender, Docker, IBM, Jenkins, McAfee, Microsoft, NetApp, Nutanix, Oracle, Plesk, Puppet, Salesforce, Sophos, SonicWall, Synology, TP-Link, TrendMicro, Veeam, VMware, etc... Du beau monde.

Je vous laisse en compagnie du rapport de l'ANSSI, disponible à cette adresse : Top 10 des vulnérabilités 2021 - ANSSI

The post Top 10 des vulnérabilités de 2021, selon l’ANSSI first appeared on IT-Connect.

Les listes de contrôle d’accès (ACL) avec Cisco

jeudi 24 février 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons aborder la notion d'ACL, c'est-à-dire les listes de contrôle d'accès, avec quelques exemples pratiques à mettre en œuvre sur Cisco.

Une ACL, c’est quoi et pourquoi ?

Les ACL, pour Access Control List, sont des règles appliquées aux trafics transitant via les interfaces du routeur que ce soit en entrée (in) ou en sortie (out). Les ACL filtrent le trafic en demandant aux interfaces d’acheminer on non les paquets qui y transitent. Pour ce faire, le routeur lit l'en-tête de chaque paquet afin de déterminer s'il doit être acheminé ou non en fonction des conditions définies dans la liste de contrôle d’accès ACLs.

Les avantages de les mettre en place sont nombreux, on peut citer par exemple :

Les ACL s'appliquent selon un ordre séquentiel en évaluant les paquets au début de la liste d’instruction. Si le paquet répond aux critères de la première instruction (appelées ACE pour Access Control Entry), il ignore le reste des règles. Pour reproduire ce tutoriel, vous pouvez utiliser du matériel virtuel Cisco sous Packet Tracer.

II. ACL : entrante ou sortante

Une question très importante que l'on peut se poser lorsque l’on veut mettre en place l’ACLs, c'est savoir sur quelle interface faut-il appliquer les ACLs ? L’interface entrante ou sortante du routeur ? Répondons à cette question dans cette première partie de l'article.

Les ACLs peuvent être associés à une interface particulière et pour une direction du flux (en entrée ou en sortie). En outre, ces règles de filtrages peuvent être appliquées avant que le routeur ne prenne sa décision de routage (interface en entrée), ce qui est un bon moyen d'économiser les ressources matérielles du routeur, ou après que le routeur ait pris sa décision de transfert et déterminé l’interface de sortie à utiliser pour acheminer le paquet.

Un petit exemple :

Dans la topologie ci-dessus, l’interface entrante de R1 est Gi 1/0, et l’interface sortante est Gi 0/0.

L’interface entrante de R2 est Gi 0/1 et l’interface sortante est Gi 0/3. Si par exemple, nous avons activé une ACL sur l’interface Gi 0/2 de R2, cette ACL ne pourrait pas filtrer les paquets envoyés de PC2 au serveur S1, car les paquets ne passent pas l’interface Gi 0/2.

En somme, pour filtrer un paquet, on doit activer une ACL sur l’interface qui traite le paquet.

Si on active l’ACL sur R1 pour les paquets entrants sur l’interface Gi1/0, R1 va comparer chaque paquet entrant sur cette interface aux entrées de l’ACL afin de décider le sort de ce paquet : continuer sans changement et acheminer le paquet ou le rejeter.

III. La correspondance des paquets

C’est la manière dont on configure les ACL, on indique les informations qui seront utilisées par le processus de filtrage, cela peut être une adresse IP ou bien un protocole réseau. En se basant sur ces informations, le routeur déterminera s’il doit autoriser on refuser les paquets.

Le diagramme ci-dessous illustre mes propos :

Lors du traitement de l’ACL, le routeur traite le paquet comme suit :

Les ACLs utilisent la logique de première correspondance. Une fois qu’un paquet correspond à une ligne dans l’ACL, le routeur exécute cette règle puis le processus s’arrête.

L’exemple ci-dessous nous permettra de voir ce que cela signifie précisément :

Sur l'exemple ci-dessous, l'ACL est appliquée sur l’interface Gi1/3 et elle contient trois règles :

On considère qu’un paquet est envoyé par le PC1 (10.1.1.1) au serveur S1, le routeur R1 compare ce paquet à l’ACL correspondant à la première ligne de l'ACL, le paquet sera autorisé, car l'adresse IP du PC correspond à celle définie dans l'ACL.

Ensuite, considérons qu’un paquet est envoyé par le PC2 (10.1.1.2) au serveur S1. À l’arrivée du paquet, le routeur va poursuivre la même logique de recherche en comparant le paquet à la première ligne de notre ACL. Il ne fera pas une correspondance, car 10.1.1.2 (adresse IP de PC2) n'est pas égal à l'adresse IP définie dans la première règle (10.1.1.1). Donc, R1 passe ensuite à la deuxième instruction à savoir "10.1.1.x deny", où x correspond à n’importe quelle valeur qui peut exister dans le dernier octet. En ne comparant que les trois premiers octets, R1 réalise que notre paquet émis depuis PC2 a une adresse IP source qui correspond à "10.1.1". De ce fait, R1 considère qu’il s’agit bien d’une correspondance à la deuxième règle de notre ACL et applique l’action comme indiqué dans la règle, à savoir refuser le paquet (deny). Le routeur R1 arrête également le traitement ACL sur ce paquet, en ignorant la troisième règle de l’ACL.

Finalement, admettons que le PC3 (10.3.3.3) veut envoyer un paquet au serveur S1. R1 examine les deux premières règles dans l’ACL, et il voit qu’elles ne correspondent pas à l'adresse IP 10.3.3.3 (adresse IP source du paquet), donc il poursuit l’exécution de l’ACL. De ce fait, il regarde la troisième règle qui s'applique à toutes les adresses IP sous la forme "10.X.X.X", ce qui correspond à l'adresse IP de PC3. La troisième règle de l'ACL s'applique, donc le paquet est autorisé et poursuit son chemin vers le serveur S1.

Si jamais un paquet ne correspond à aucune des règles de la liste ACLs, le paquet est rejeté. On parle d'un refus implicite.

Il est important de savoir que le traitement des ACL en mode séquentiel, en lisant les règles dans l'ordre, s’applique sur tout type d’ACL.

IV. Les types d'ACLs

Il existe plusieurs types d'ACL, que nous allons découvrir ensemble sans plus attendre.

A. Les ACL standards

Dans ce type, l’ACL ne peut être liée qu'à l’adresse IP source du paquet. Ces ACLs sont identifiables par identifiant correspondant à un nombre allant de 1 à 99 et de 1300 à 1999.

Nous pourrons utiliser ce type d'ACL pour autoriser ou interdire un segment du réseau ou l'adresse IP d’une machine à communiquer avec un autre segment de réseau ou une autre machine.

Afin de concrétiser la notion d’ACL standard, nous allons les mettre en place sur un routeur Cisco.

Dans l’exemple ci-dessus, les trois ordinateurs, situés sur des segments réseau différents, communiquent entre eux. Le but est d’interdire au réseau « 10.1.1.0/24 » de communiquer avec le réseau « 10.1.2.0/24 » tout en ayant la possibilité de communiquer avec le réseau « 10.1.3.0/24 » pour ce faire, nous allons, sur l’interface Gi0/2, interdire les paquets provenant du réseau « 10.1.1.0/24 »

Pour parvenir aux résultats souhaités, nous appliquons trois étapes :

1 - Après s’être connecté sur le routeur en mode de configuration globale en tapant les commandes "enable" puis "configuration terminal", on commence par la création de la règle :

Router(config)#access-list 1 deny 10.1.1.0 0.0.0.255

En précisant "access-list 1" on attribue un ID à notre ACL, puis ensuite on précise que l'on veut refuser avec "deny", et enfin on précise l'adresse IP de destination (10.1.2.0) et le masque au format inversé appelé wildcards mask (0.0.0.225).

Wildcards mask ? De quoi parle-t-on ? Une petite explication s’impose. En effet, souvent, l’objectif de mettre en œuvre l’ACL c’est de faire correspondre une plage d’adresse IP (ou un sous-réseau complet) à l'ACL plutôt qu’une seule adresse IP. Cela est faisable à l’aide ce que l’on appelle Wildcards mask, ou en français masque générique (ou inversé). Notez qu’il ne s’agit pas d’un masque de sous-réseau. Par le biais de cette notation, nous avons la possibilité d’ignorer des parties de l’adresse IP, comme si elles correspondaient déjà.

Cela signifie que :

C’est-à-dire pour la règle « deny 10.1.2.0 0.0.0.255 » le routeur va refuser tous les paquets où les trois premiers octets de l'adresse IP source correspondent à ce masque générique. D'autre valeurs sont possible pour le wildcard mask, permettant d'affiner le filtrage en fonction des plages IP ou des regroupements de plages. Ainsi, un wildcard mask en 0.0.255.255 correspondra à un masque en /16; un wildcard mask en 0.0.63.255 correspondra à un masque en /18. Pour calculer la valeur, rien de plus simple, il suffit de soustraire la valeur du masque de sous-réseau à 255.

Exemple :

255.255.255.255

 -255.255.255.0

= 0.0.0.255

On retrouve bien notre wildcard mask correspondant à notre /24.

Deuxièmement, comme évoqué précédemment, il faut autoriser explicitement les réseaux que l’on veut laisser passer, dans notre exemple c’est « 10.1.3.0/24 ». À défaut, il n’y aura pas de correspondance entre l’IP source contenue dans l’en-tête du paquet et les règles ACL, ce qui veut dire que le routeur va les refuser implicitement et notre réseau en 10.3.0/24 ne pourra pas non plus communiquer  avec le 10.1.2.0/24.

Router(config)#access-list 1 permit 10.1.3.0 0.0.0.255

Notez qu'ici, on pourrait utiliser le mot clé "any" à la place de la plage réseau et du wildcard mask. Ce mot clé , qui veut dire "n'importe qui" peut être utilisé lorsque la règle s'adresse à tous les réseaux et hôtes. Comme on à déjà interdit en premier lieu notre premier réseau, on peut très bien estimer que le reste est permis.

Troisièmement, on sélection l’interface concernée par la règle :

Router(config)#interface gigabitEthernet 0/2

Enfin, on applique la règle en sortie :

Router(config)# ip access-group 1 out

Le "1" étant le numéro de l’ACL créée à la première étape, et "out" signifie que la règle s’applique sur les paquets sortants de l’interface.

Nous avons vu les ACLs Standard et leur champ d’application, passons maintenant au deuxième type d’ACLs à savoir les « ACLs étendues ».

B. Les ACL étendues

Les ACL étendues présentent plusieurs similitudes par rapport aux ACL Standards décrites dans la section précédente. Tout comme une ACL standard, on active les ACL étendues sur les interfaces pour les paquets entrants ou sortants, puis le routeur cherche dans la liste de manière séquentielle.

Les ACL étendues utilisent également la logique de première correspondance, car dès que la première instruction est mise en correspondance, le routeur arrête la recherche dans la liste d'ACL, en effectuant l’action définie.

En comparaison des ACL standards, les ACLs étendues vont permettre d'analyser une plus grande variété de champs au sein de l'en-tête d'un paquet. Cela rend les ACL étendues plus puissantes, plus précises, mais aussi un peu plus complexes.

Les ACL étendues suivent la même logique que les ACL standards, elles sont identifiables par un numéro, allant de 100 à 199 et de 200 à 2699.

Un exemple sera plus parlant, nous allons créer une règle qui aura pour but d’interdire le Ping de PC2 vers le PC3, tout en l'autorisant vers le PC1, en posant les règles sur les sous-réseaux (tous en /24). Mettons ça en place en reprenant la même topologie :

Voici la configuration à appliquer sur notre routeur Cisco :

Router(config)# access-list 100 deny icmp 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
Router(config)# access-list 100 permit icmp 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
Router(config)#interface gig 0/2
Router(config-if)#ip access-group 100 in

Dans l'exemple ci-dessus, "icmp" correspond au protocole, en l'occurrence ici c'est un moyen de bloquer le ping. Ensuite, "10.1.3.0" c'est l'adresse IP d'origine suivie de son masque générique, et "10.1.2.0" l'adresse IP de destination suivie aussi de son masque générique.

Il est à noter que les ACLs étendues peuvent aussi examiner des parties d'en-têtes TCP ou UDP, en particulier les champs qui contiennent le numéro de port source et port de destination. Les numéros de port identifient le service qui envoie ou reçoit les données. Quand le mot "tcp" ou "udp" est inclus dans la règle de l'ACL, cela permet de préciser le port source et le port de destination afin d'avoir une règle plus précise.

Voici un exemple :

Router(config)# access-list 100 permit tcp 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 eq 21

Concernant « eq » il s’agit d’un opérateur qui veut dire égal, et le numéro de port 21 utilisé par le serveur FTP. On autorise le réseau 10.1.1.0/24 à communiquer sur le port 21 (pour le FTP) avec le réseau 10.1.2.0/24.

Prenons un autre exemple...

L’exemple suivant se concentre sur la compréhension de la syntaxe de base. Ici, l'objectif est de créer une ACL pour empêcher l'utilisateur David d’utiliser le protocole FTP pour se connecter sur les serveurs. Pour cela, on va le bloquer en entrée sur l’interface Gi0/0 de R2, car c’est l’interface la plus proche de la source, donc l’ACL sera associée à cette interface. Quant à l'utilisateur Florian, on va lui interdire l’accès au serveur Web de serveur1. Dans cet exemple, on active l’ACL sur R3 en entrée de l'interface Gi0/0.

Voici la topologie :

Je vous propose que l'on se connecte sur R2 afin de créer la première règle.

La première chose à faire, c’est interdire David d’accéder à tous les serveurs FTP :

access-list 101 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp

Au sein de la commande ci-dessus, on précise bien l'hôte de David avec "host 172.16.3.10", car cela correspond à la source à bloquer selon notre schéma initial.

La deuxième règle va permettre d'autoriser tout le reste du trafic :

access-list 101 permit ip any any

On applique l'ACL à l'interface concernée :

R2(config)# interface gi0/0 
R2(config-if)#ip access-group 101 in

Interdisons maintenant à Florian d’accéder au serveur Web :

access-list 101 deny tcp host 172.16.2.10 host 172.16.1.100 eq www

Note : vous pouvez remarquer que j'ai utilisé le même numéro d'ACL que pour la première réalisée. Cela n'a pas d'importance, car ce numéro est interne au routeur, et je ne suis pas sur le même routeur.

Encore une fois, on autorise tout le reste du trafic ensuite :

access-list 101 permit ip any any

Après avoir créé les règles d'ACL, il nous reste plus qu’à les appliquer toujours à partir du routeur R1 :

R3(config)# interface gi0/0
R3(config-if)#ip access-group 101 in

Voilà, mission accomplie ! 

C. Named IP Access Lists

Comme vous le savez, toutes les listes d’accès doivent être identifiées par un nom ou un numéro. Ce type de liste d’accès est plus pratique, car on peut spécifier un nom significatif qui est facile à retenir et associer à une règle.

Les ACL nommées peuvent correspondre aux mêmes champs qu’une ACL standard et étendue, cependant, elles présentent trois grandes différences par rapport aux listes de contrôles d’accès numérotées, voyons cela ensemble :

On va reproduire le même schéma :

Cette fois-ci, on va changer un peu les règles du jeu : le but sera d’interdire David d’accéder au serveur Web (Serveur1) via le protocole http. On aura besoin donc d’une ACL qui contiendra plusieurs informations : IP source, IP destination et un protocole bien précis. Pas le choix, il faudrait utiliser une ACL étendue.

Profitons de cet exemple pour utiliser une ACL nommée et poursuivre notre découverte des ACLs.

Sur le R1, tout d’abord, on crée l’ACLs avec le nom "David-HTTP" :

R2(config)# ip access-list extended David-HTTP

Puis, on se retrouve dans cette ACL, donc on ajoute notre règle :

R2(config-ext-nacl)#deny tcp host 172.16.3.10 host 172.16.1.100 eq www

Vous constatez bien que le prompt a changé, car on se trouve dans l’invite de configuration de l’ACL nommée. On pose une interdiction via la directive "deny" depuis l’adresse source "172.16.3.10" vers le serveur web avec l'adresse IP "172.16.1.100". « www » c’est pour faire référence au service web, mais on peut bien évidement mettre le port 80 au lieu de www.

En dernier lieu, on autorise toutes les autres connexions, car souvenez-vous, la directive implicite (deny any ) se trouve à la fin de chaque ACL !

R1(config-ext-nacl)#permit ip any any

Il ne reste plus qu’à associer l’ACL à l’interface G0/0 de R2 comme vous savez le faire maintenant. Vous pouvez retrouver d'autres exemples sur le site de Cisco.

V. Placement des ACL

Bon, nous savons maintenant qu'il y a deux types d'ACL : standards et étendues. On sait aussi qu'il y a deux possibilités pour les placer : en entrée ou en sortie d'une interface. Mais alors, où placer tel type d'ACL? Sur quel routeur? Quelle interface?

Dans tous les cas, il existe une règle simple et immuable : une ACL standard se placera toujours au plus proche de la destination, une ACL étendue se placera toujours au plus proche de la source.

Pourquoi? Tout simplement, car une ACL standard, comme vous avez pu le constater, est très restrictive (blocage de tout le trafic d'un réseau ou d'un hôte), un placement au plus proche de la source risque de limiter fortement les possibilités de celles-ci. En revanche, l'ACL étendue filtrant au niveau de la couche 4 (ports TCP/UDP), son placement au plus proche de la source permet d'éviter de faire transiter des paquets qu'on ne souhaite pas voir sur le réseau, ainsi, on économise du temps de calcul.

Un petit exemple, en reprenant le schéma de la partie II :

ACL standard VS ACL étendue

Admettons que le PC1 soit la source, à savoir que c'est à partir de lui que je vais déterminer mes règles. Je veux interdire à ce PC1 d'accéder au réseau du serveur S1, je vais donc placer l'ACL standard sur l'interface Gi 0/3 de R2 en sortie . En revanche, si je veux interdire à PC1 d'accéder en SSH au serveur S1, je vais placer mon ACL étendue sur l'interface Gi 1/0 de R1 en entrée.

VI. Conclusion

Nous avons vu ensemble comment les ACLs peuvent être utiles pour contrôler le réseau afin de filtrer certains flux. Les ACL permettent un filtrage au niveau du réseau et peuvent être complétées avec le filtrage applicatif (Proxy) qui va venir au niveau de la couche Application du modèle OSI. Le filtrage de paquet via ACLs opère niveaux 3 et 4 du modèle OSI, ce qui permet de faire déjà beaucoup de choses, mais peu ne pas suffire dans certains cas.

Merci à Florian Duchemin pour sa relecture technique avant publication.

The post Les listes de contrôle d’accès (ACL) avec Cisco first appeared on IT-Connect.

Cyberattaque : l’Ukraine ciblée par un malware destructeur de données

jeudi 24 février 2022 à 08:17

À l'heure actuelle, la situation est très difficile en Ukraine, et au-delà de la guerre sur le terrain, ce pays est également la cible de nombreuses cyberattaques. Un malware s'en prend aux machines afin de détruire les données.

L'Ukraine est touchée par de nombreuses cyberattaques, notamment des attaques DDoS contre des banques et des agences gouvernementales, mais aussi des attaques avec un logiciel malveillant qui a un seul objectif : détruire les données des machines infectées.

De nombreuses machines sont victimes de ce que l'on appelle un "data wiper", c'est-à-dire un logiciel malveillant qui a pour objectif de corrompre les données afin de les rendre inutilisables. Contrairement à un ransomware où les données sont récupérables si l'on paie la rançon, là c'est de la destruction de données pure et simple.

Symantec et ESET ont fait la découverte de ce data wiper, et sur VirusTotal, cette souche malveillante "Win32/KillDisk.NCV" est détectée seulement par 28 des 71 moteurs de détection de la liste. Disons que les principaux antivirus sont capables de le détecter : ESET, BitDefender, Avast, Kaspersky, Fortinet, McAfee, Webroot, etc.

D'après Symantec, ces cyberattaques ciblent des centaines de machines associées à des organismes financiers et des entreprises qui travaillent pour le gouvernement Ukrainien. En complément, la Lituanie et la Lettonie sont également ciblées.

De son côté, ESET remarque que le malware a été compilé le 28 décembre 2021 : une preuve que ces attaques étaient planifiées depuis un bon moment. Le malware s'appuie sur des pilotes associés à l'éditeur EASUS, ce dernier propose des logiciels pour la sauvegarde des données, mais aussi le partitionnement des disques. Le data wiper s'appuie sur ces pilotes EASEUS pour corrompre les données avant de redémarrer la machine.

Toujours d'après ESET, dans le cadre de l'une de ces attaques, le logiciel malveillant a été déployé sur les machines directement à partir d'un contrôleur de domaine. On imagine les conséquences désastreuses sur les machines associées à ce domaine Active Directory. Là encore, cela signifie que les attaquants avaient accès à l'infrastructure depuis un moment.

En janvier dernier, l'Ukraine était déjà la cible d'un data wiper nommé "WhisperGate". Cette fois-ci, cela est coordonné avec l'offensive Russe sur le terrain, même si ce n'est pas précisé si ce sont les Russes qui utilisent ce data wiper (on peut s'en douter !).

Source

The post Cyberattaque : l’Ukraine ciblée par un malware destructeur de données first appeared on IT-Connect.