I. Présentation

Dans un précédent tutoriel, nous avions vu comment mettre à jour l’aide de PowerShell grâce à la commande Update-Help. Aujourd’hui, nous allons voir comment automatiser la mise à jour de l’aide de la console PowerShell, automatiquement et périodiquement. Par exemple, on peut automatiser la mise à jour de l’aide une fois par semaine.

Cela permettra de s’assurer d’avoir une aide à jour lorsque l’on s’en servira, plutôt sympa, non ?

Pour cela, nous allons créer une tâche planifiée qui exécutera une console PowerShell avec une commande d’update de l’aide.

II. La tâche planifiée PowerShell

Commencez par ouvrir le planificateur de tâches, pour ma part je suis sous Windows 8.1 je peux donc le trouver rapidement via une recherche depuis le menu d’Accueil.

On commence par créer une tâche en faisant clic droit puis “Créer une nouvelle tâche“.

Ensuite, nommez la tâche en remplissant le champ “Nom” avant de passer à l’onglet “Déclencheurs“.

Créez un nouveau déclencheur, puis choisissez d’exécuter la tâche “À l’heure programmée“. Pour ma part, je paramètre la tâche de manière à l’exécuter tous les lundis à 12:45. À vous d’adapter selon vos besoins… Je conseille également d’activer l’option “Arrêter la tâche si elle s’exécute plus de” afin que la tâche soit coupée automatiquement si elle dure trop longtemps (on ne sait jamais s’il y a un bug…).

Maintenant, place à l’étape la plus importante : la création de l’action. Tout d’abord, en type d’action indiquez “Démarrer un programme” ce dernier étant “powershell.exe” qu’il faudra indiquer dans le champ “Programme/script“.

Ajouter ensuite l’argument suivant afin de modifier temporairement la politique d’exécution des scripts Powershell sur la machine (Bypass) et d’exécuter la commande d’update :

-ExecutionPolicy Bypass -Command Update-Help -Force;

Validez. La tâche est désormais créée et doit fonctionner, pour en être sûr vous pouvez l’exécuter une première fois manuellement.

Novidy’s, Elu pour la 3ème fois en 5 ans partenaire de l’année par Palo Alto Network, après 5 années de déploiement Firewalls de Nouvelle Génération. L’histoire des Firewalls Next Gen par Edouard PAVIS, Directeur Technique de Novidy’s :

Il est loin le temps où un Firewall stateful permettait de sécuriser son architecture. Les Firewalls, inventés au milieu des années 90 permettaient de réaliser un filtrage basé sur l’adressage IP et les ports (TCP/UDP). Jadis, ces ports permettaient de discriminer les applications entre elles, mais l’explosion d’Internet et les évolutions des applications web compliquent et rendent obsolète cette approche passée. En parallèle, nous assistons depuis plus de 10 ans à une « Webification » des applications métiers des entreprises et à l’avènement du SaaS (Software As A Service). Enfin, la multiplication des accès aux réseaux (VPN SSL, 4G, WiFi, etc…) et l’extrême mobilité des utilisateurs rendent également caduque la reconnaissance de ces derniers en fonction de leur adresse IP.

Aujourd’hui, la majorité des applications utilisent les fameux ports 443 et 80 et l’adresse IP source ne permet plus de savoir qui vient se connecter à une application.

En 2004, un nouveau concept émerge alors, les UTM (Unified Threat Management). Ce terme a été inventé par Charles Kolodgy du cabinet de conseil IDC (International Data Corporation). En plus des fonctions traditionnelles portées par les Firewalls (Filtrage niveau 4, IPSec, NAT,…), les éditeurs ajoutent à leurs équipements des nouvelles fonctions dites « avancées » en matière de sécurité telle que : Filtrage d’URL par catégories, IPS, Anti-Virus,…

L’idée est excellente, car en 2004, de plus en plus de menaces ne sont plus simplement réseau, mais applicative. Des failles « Zero-Day » sont découvertes tous les jours sur les OS, les applications, les plug-ins des Navigateurs, … et nécessite l’ajout de fonction non prévu initialement sur ces Firewalls et nécessitant majoritairement du « pattern matching ». En effet, ces équipements (hardware et logiciel) n’ont pas été conçus pour réaliser ce type de tâches. Les performances n’étant pas au rendez-vous (lorsque toutes les fonctions sont activées, les performances annoncées peuvent être divisées par 100), l’UTM ne semble répondre aux entreprises qui n’ont pas exigence en matière de performances.

Ainsi, Nir Zuk ancien employé Checkpoint, puis Onesecure, va créer un Firewall qui répond au challenge à venir en matière de sécurité. Ce nouveau Firewall doit :

• Reconnaitre les applications, quels que soient les ports utilisés
• Reconnaitre les utilisateurs, quels que soient les IP utilisés
• Scan les flux qui le traverse afin de faire de la reconnaissance de contenue et proposer des fonctions comme l’IPS, l’Anti-Virus, du DLP, du Filtrage d’URL, etc. sans baisse de performance.

Enfin, le Firewall devra pouvoir déchiffrer les flux SSL, afin de réaliser tous ces traitements et ainsi sécuriser l’entreprise.

Les premiers Firewall Palo Alto Networks sont commercialisés dès 2007 aux États Unis. Ces derniers tiennent des performances de plus de 10 Gbps, quelles que soient les fonctionnalités activées.

Ils arrivent en Europe en 2009, au moment où les créateurs de Silicomp Réseaux créent Novidy’s, intégrateur spécialisé en sécurité et réseaux. Ainsi dès leur création, Novidy’s intègre les premiers firewalls next generation Palo Alto chez leur client.

En 2010, le cabinet Gartner les places dans la case des visionnaires. Dès 2011, Palo Alto va truster la case des leaders et réalise plus de 600 M$ de chiffre d’affaires et est devenu le 3eme vendeur de Firewall dans le monde, derrière Cisco et Checkpoint.

Depuis, Palo Alto Networks travaille régulièrement à l’ajout de nouvelles fonctionnalités en matière de sécurité dont notamment Wildfire.

Wildfire, c’est l’adjonction de la puissance du cloud afin de protéger les Entreprises contre les menaces ciblées et inconnues (nommées Zero-Day). Tous les fichiers potentiellement vecteurs de menaces transitant par le Firewall et dont le hash est inconnu sont envoyés dans le cloud de Palo Alto pour analyse en Sandbox. Des batteries de VM font ainsi tourner les fichiers afin d’en analyser le comportement et ainsi en déterminer une éventuelle dangerosité. Cette analyse est possible sur plus de 400 applications, quel que soit le port, que ce soit chiffré ou non.

En cas de fichier malicieux, Palo Alto Networks envoie à tous ces clients dans le quart d’heure une signature pour le fichier en question.

Concernant le hardware, Palo Alto a également sorti une version VM ainsi qu’un châssis, le PA-7050, orienté Datacenter et capable de traiter jusqu’à 100 Gbps de trafic avec l’ensemble des fonctionnalités activées.

Plus récemment, Palo Alto a acquis la startup Israélienne CYVERA, dont le logiciel de « Endpoint Security », Traps (Targeted Remote Attack Prevention System), apporte une approche en totale rupture avec les protections traditionnelles. Le nombre de Malware explose et il devient impossible de signer les nouvelles failles. En se concentrant sur ces techniques d’exploitation et non pas sur les failles elles-mêmes, Traps de Palo Alto peut prévenir les attaques, sans pour autant connaitre les failles, quel que soit le niveau de patch sur le software et sans aucune signature. Ainsi, Traps est fait pour prévenir les attaques ciblant les failles des softwares basées sur les corruptions de mémoire ou encore les attaques à base de « Logic Flaw ». Ainsi, il est possible de prévenir une multitude d’attaques (Heap spray, Various memory corruption types, Memory leakage utilization, Java code from running in browsers, under certain conditions, DLL hijacking, Hijacking program control flow, Intercepting OS Handlers to Inject Malicious Code).

Palo Alto se définit comme un éditeur spécialisé en solution de sécurité. En forte croissance, il s’appuie sur un réseau de partenaires dont Novidy’s en fait partie. Novidy’s est un partenaire certifié Platinum et a été élu Partner of the year en 2010, 2011 et 2014.

Novidy’s et un partenaire en forte croissance depuis sa création grâce à une équipe dynamique. La société est en recherche perpétuelle d’ingénieurs réseaux et sécurité afin de continuer leur fort développement et de garder leur positionnement de Partner of the year.

Pour plus d’informations :
Palo Alto Networks
Novidy’s

I. Présentation d’editcap et mergecap

Lors de la manipulation et l’étude de paquets réseaux en tant qu’administrateur systèmes, administrateur réseaux ou même dans le domaine de la sécurité et du forensic, on peut vite être amené à manipuler des fichiers au format PCAP, par exemple pour effectuer des filtres dessus, en fusionner ou en couper en plusieurs petits fichiers. C’est ce que nous allons voir dans ce cours.

Pour rappel, un fichier PCAP est un fichier issu d’un sniffe de flux réseaux (par exemple avec Wireshark ou TCPDump), ce sniff réseaux ayant été traité avec la librairie libpcap qui produit justement un enregistrement au format PCAP (ou PCAPNG parfois). Ces fichiers peuvent alors être transportés, stockés et rouverts plus tard, on voit alors tout l’intérêt de savoir les manipuler avec précisions.

II. Installation d’editcap et de mergecap

Editcap fait partie de l’environnement des outils Wireshark, il permet de lire une grande partie des paquets capturés par Wireshark (ou d’autre application comme TCPDump) à partir d’un fichier, on pourra optionnellement les convertir et les trier selon divers critères  et écrire le résultat dans un nouveau fichier au format PCAP. L’utilisation typique est le fait d’avoir un gros fichier PCAP dont on souhaite filtrer le contenu pour l’écrire dans un nouveau fichier à part.

Mergecap est un outil complémentaire d’Editcap qui n’interviendra que pour une utilisation particulière : la fusion de plusieurs fichiers au format PCAP.

Editcap et Mergecap seront donc présents sur votre système Linux dès que vous installerez Wireshark, si vous souhaitez tout de même n’installer que editcap et mergecap, ceux-ci sont  contenus dans le paquet “Wireshark-common”, pour Debian et Ubuntu :

apt-get install wireshark-common

Pour CentOS/RHEL, il faut passer par l’installer de Wireshark directement :

yum install wireshark

Editcap est un outil très complet, bien que nous ne verrons que quelques une de ses fonctionnalités dans ce cours.

III. Couper un fichier PCAP

Nous allons tout d’abord voir comment couper un fichier PCAP. On va simplement mettre en entrée un fichier PCAP puis obtenir un second fichier PCAP à partir de celui-ci en lui appliquant une règle spécifique qui peut, par exemple, être un certain nombre de paquets ou un temps défini. Il peut parfois être pratique de savoir comment couper un très gros fichier PCAP en plusieurs fichiers plus petits pour les faire analyser par plusieurs personnes par exemple. Voici la syntaxe générale d’editcap dans ce contexte :

editcap -c <paquets-par-fichiers> <fichier-pcap-entrée> <préfixe-fichier-pcap-sortie>

Plus clairement, voici comment utiliser editcap avec un fichier PCAP si on souhaite le couper en plusieurs fichiers de 10 000 paquets :

editcap -c 10000 capture.pcap capture-partie

Je mets donc avec l’option “-c” (“count”) le nombre de paquets par fichier, ensuite le fichier à lire (“capture.pcap”) puis le préfixe des fichiers en sortie, soit “capture-partie”, la suite du nom des fichiers sera complétée automatiquement par editcap. En sortie, avec un fichier PCAP de 73 000 paquets, voici ce que j’aurai :

J’ai donc bien 7 fichiers de 10 000 paquets  au format PCAP, quelle précision !

On peut aussi effectuer un découpage chronologique, c’est à dire en fonction de la durée de la capture initiale. Voici la syntaxe générale :

editcap -i <secondes-par-fichiers> <fichier-pcap-entrée> <préfixe-fichier-pcap-sortie>

Par exemple si l’on souhaite effectuer un découpage pour avoir des fichiers contenant 60 secondes de capture chacun, on utilisera la commande suivante :

editcap -i 60 capture.pcap capture-partie

Nous aurons donc en sortie un résultat similaire à celui précédent sauf que nous aurons cette fois-ci des fichiers correspondant à 60 secondes de capture chacun.

IV. Fusionner des fichiers PCAP

Nous allons maintenant voir comment fusionner des fichiers au format PCAP, on peut par exemple avoir besoin de cette manipulation si l’on dispose de plusieurs fichiers PCAP obtenus sur des écoutes procédées sur des machines différentes que l’on souhaite analyser en même temps. Supposons que l’on dispose d’un fichier capture1.pcap, d’un fichier capture2.pcap et d’un fichier capture3.pcap. On va vouloir fusionner les trois dans un fichier capture-123.pcap :

merge capture-123.pcap capture1.pcap capture2.pcap capture3.pcap

On se retrouvera donc avec le fichier capture-123.pcap contenant les paquets des trois autres.

V. Filtrer le contenu d’un fichier PCAP

Nous allons maintenant voir une utilisation un peu plus avancée de l’outil editcap. On va en effet chercher à ouvrir un fichier PCAP, filtrer son contenu, puis écrire ce qui est sorti du filtre dans un nouveau fichier.

On peut par exemple avec editcap effectuer un filtre sur une fenêtre de temps très précise. Si j’effectue un enregistrement du trafic réseau permanent que j’enregistre dans un fichier PCAP, puis que je souhaite récupérer ce qu’il s’est passé entre 21:14:00 et 21:15:00 le 3 février 2015, on pourra utiliser la ligne de commande suivante :

editcap -A '2015-03-02 21:14:00' -B '2015-03-02 21:15:00' capture-input.pcap capture-sortie.pcap

J’aurais donc dans le fichier “capture-sortie.pcap” les paquets reçus et émis dans la fenêtre de temps précisée grâce à l’option “-A” pour la date de début et “-B” pour la date de fin.

Note : Attention à bien utiliser le bon format de date, à savoir “AAAA-MM-DD HH:MM:SS”

Également, on pourra très facilement extraire un nombre précis de paquets dans une capture au format PCAP. Par exemple si l’on souhaite extraire les paquets du numéro 1500 au numéro 1700 :

editcap apture-input.pcap capture-sortie.pcap 1500-1700

Nous avons ici vu différents contextes d’utilisation des outils editcap et mergecap qui font partie de la suite Wireshark, ceux-ci peuvent être utilisés dans nombre d’autres contextes, mais la construction des syntaxes ressemblera à ce que l’on a vu ici.

 

 

Asustor annonce être le premier à porter Kodi sur ses NAS, Kodi étant la nouvelle génération du très connu XBMC. Les NAS des séries 50, 51 et 70 peuvent bénéficier de Kodi, alors que pendant ce temps Asustor annonce la disponibilité de quatre nouveaux NAS au format Tour : AS5008T, AS5010T, AS5108T et AS5110T.

Depuis son magasin d’application, Asustor propose de télécharger et d’installer Kodi, depuis la section “Apps en Beta“. Il ne s’agit donc pas d’une version finale du successeur d’XBMC mais bien de la dernière Beta disponible.

Quatre nouveaux NAS, destinés aux pros et aux PME

Asustor annonce la disponibilité de quatre nouveaux NAS : AS5008T, AS5010T, AS5108T et AS5110T.

Ces quatre modèles ont des points communs :

– Possibilité d’étendre la RAM jusqu’à 8 Go
– 4 ports Ethernet Gigabit
– 3 ports USB 3.0
– 2 ports USB 2.0
– 2 ports eSata
– Remplacement à chaud de disques durs
– RAID (Simple, JBOD, RAID 1/5/6/10)

… Mais il y a aussi, des différences bien sûr, notamment au niveau de la RAM et du processeur.

Les modèles AS5008T et AS5010T sont équipés des processeurs Intel Celeron 2.41 GHz, Dual-Core, et 1 Go de mémoire SO-DIMM DDR3L. Par ailleurs, les modèles AS5108T et AS5110T sont équipés avec les processeurs Intel Celeron 2.0 GHz Quad-Core et 2 Go de mémoire SO-DIMM DDR3L.

De plus, les modèles AS5108T et AS5110T disposent d’un écran LCD qui permet d’accéder rapidement aux informations de base du système, mais aussi de lancer l’initialisation du système grâce aux touches de configuration. Sur ces deux modèles, les disques durs sont sécurisés puisque les tiroirs de disques sont protégés par des serrures. Un point intéressant, à mon sens.

Au niveau du système d’exploitation, ces NAS Asustor intègrent la nouvelle version 2.3 de l’OS, avec une nouvelle interface.

D’un point de vue stockage (c’est tout l’intérêt d’un NAS…), les modèles 8 baies fournissent jusqu’à 48 To d’espace de stockage tandis que les modèles 10 baies fournissent jusqu’à 60 To. Enfin, je tiens à préciser que ces quatre nouveaux NAS sont Citrix et Hyper- V ready.

Enfin, pour le prix, le communiqué de presse d’Asustor ne contient aucune information à ce sujet.

Asustor et IT-Connect

Pour notre part et dans le cadre d’un partenariat avec Asustor, nous allons prochainement recevoir le NAS Asustor 5002T afin de pouvoir le tester en avant-première. Restez connectés !

Source

En octobre dernier, j’attirais votre attention sur la nécessité à maintenir une documentation digne de ce nom puis, un mois plus tard, je vous proposais quelques réflexions autour de la CMDB… Je vous propose aujourd’hui d’entrer un peu plus dans le détail de ce que pourrait être une documentation « idéale » et ce, quelque soit la taille de votre organisation…

Dans cet article, je vous propose seulement d’organiser votre documentation, de manière simple et efficace mais il y a un « monde » entre une simple documentation et un système de CMDB complet…

Sachez qu’il existe aujourd’hui des solutions beaucoup plus complexes intégrant toute la chaîne de production, à savoir :

• inventaire des matériels,
• auto-configuration des matériels nouvellement ajoutés à l’inventaire,
• ajout des nouveaux matériels dans l’outil de supervision,
• documentation intégrée,
• ticketing (gestion du support)
• …/…

Mais tout cela requiert certaines compétences que l’on ne pourra pas trouver dans les organisations de petite ou de moyenne taille…

Revenons-en à notre sujet…

Je rappelle qu’une documentation est OBLIGATOIRE que vous soyez à la tête d’un petit système d’information ou d’un gros, que vous soyez seul ou des dizaines de personnes à gérer le S.I !

Si vous partez de zéro, vous allez me dire que vous n’avez pas le temps et pas d’argent… Pour l’argent, j’ai une solution : le monde libre vous apporte quantité de solutions professionnelles et libre d’accès (ayez toutefois une petite pensée pour eux en leur payant une bière! – en clair un petit don ne fait pas de mal à toutes ces communautés…) et pour le temps, c’est vous qui voyez mais si vous continuez à perdre du temps pour trouver l’origine d’une « panne », les « machines » prendront alors le dessus et vous serez rapidement au bord du gouffre (inefficace, surmené, critiqué…).

Dans nos métiers, ce qui est simple, est simple à comprendre, simple à documenter et ce sont l’accumulation de choses simples qui font, de nos S.I, des systèmes performants et stables. Néanmoins, même l’accumulation de choses simples peut s’avérer complexe à maîtriser, complexe à maintenir…

C’est pourquoi une documentation s’avère indispensable, ne serait-ce que pour consigner, en un endroit unique, l’interaction de toutes ces choses simples… Une DSI fournit des services, eux mêmes conçus avec des composants. Exemple : « Fournir un accès Internet à ses utilisateurs » est un service et, pour ce faire, il faut un certain nombre de composants tels que : un navigateur, un proxy, de l’authentification, du filtrage et un fournisseur d’accès à Internet…etc… Si un de ces composants ne fonctionne pas, alors c’est le service tout entier qui ne pourra être rendu à l’utilisateur final.

Dans l’article daté du mois d’octobre (Faire encore plus simple) je vous parlais de la solution DokuWiki, qui est un wiki simple à appréhender et très simple à mettre en œuvre. Je vous livre ci-dessous, une copie d’écran de la documentation que j’ai réalisée pour ma propre organisation :

On y aperçoit la page d’accueil de la documentation et, dans la première partie, un item « Services » et un item « Composant »…C’est bien là que cela se passe…

On entre maintenant dans le détail d’un service et de ses composants… Rien de bien compliqué là-dedans, il suffit de lister « bêtement » les composants nécessaires à la fabrication de ce service et, derrière chaque service, se cache la documentation dudit composant…

On a cliqué sur un des composants pour charger la documentation de celui-ci et observez bien l’icône en haut à droite de cet écran et que j’ai entouré de rouge… C’est une des fonctionnalités « standard » de DokuWiki qui permet tout simplement de lister les pages qui pointent vers ce composant et, c’est là que cette petite magie opère puisque, vous avez bien compris, vous allez accéder tout simplement à la liste des services où ce composant va être utilisé…(voir Figure 4).

Voilà comment, d’une manière très simple, on peut utiliser un Wiki et obtenir en quelques clics une documentation dynamique qui vous permettra de voir, en un coup d’œil, la liste de tous les services utilisant un même composant.

Non seulement c’est utile en cas d’incident mais c’est tout aussi utile lorsque que vous vous apprêtez à mettre à jour ou à remplacer un composant de votre de S.I afin de vérifier, un à un les services qui seront impactés par ce composant et qu’il faudra donc tester/valider.

Créer son Wiki est un travail « collaboratif » où chaque membre de la DSI va (doit !) documenter les composants qu’il gère. Cela requiert une certaine discipline, discipline indispensable à nos métiers…

Alors, vous vous y mettez quand ?