I. Présentation

Les derniers systèmes d’exploitation de Microsoft, à savoir Windows 8, Windows 8.1, Windows Server 2012 et 2012 R2, intègre un nouveau groupe de sécurité local qui permet à des utilisateurs non-administrateurs de la machine de gérer totalement l’application Hyper-V, et ce sans limite.

Nous allons nous intéresser à ce cas précis, pour ma part je me trouve sous Windows 8.1.

Pour information, sur les versions plus anciennes de Windows il était nécessaire de modifier le système pour permettre ce genre de configuration. Désormais, les choses sont simples et efficaces sur ce point.

II. Procédure

Ouvrez le gestionnaire de système sur votre machine : “Windows + X” – “Gestion de l’ordinateur“.

Une fois la console ouverte, cliquez sur “Outils système“, “Utilisateurs et groupes locaux“. Sous “Groupes” vous trouverez un groupe nommé “Administrateurs Hyper-V“.

Pour ajouter un utilisateur dans ce groupe, double cliquez dessus et de cliquer sur “Ajouter“.

L’ensemble des utilisateurs ajoutés à ce groupe de sécurité bien spécifique, pourront accéder à la console d’administration d’Hyper-V et gérer totalement l’hyperviseur.

Par ailleurs, ces utilisateurs ne sont pas pour autant Administrateurs de la machine, c’est donc un accès privilégié mais limité.

La version de 14.0 de XBMC intègre un changement majeur puisque c’est directement l’application qui va changer de nom. Ainsi, ce ne dîtes plus XBMC mais Kodi (Kodi Enterainment Center).

Pour ceux qui suivent un peu l’historique de cette application qui permet la création d’un media-center libre et gratuit, ce n’est pas la première fois qu’elle change de nom : Xbox Media Player, Xbox Media Center, XBMC et maintenant Kodi.

Ce changement de nom est justifié comme l’explique Nathan Betzen dans un article, puisque XB signifiait Xbox, et, MC signifiait Media Center. Depuis plusieurs années XBMC ne portait plus sur la console de Microsoft, ce qui retirait le sens du terme XBMC, d’où le changement de nom.

Entre nous, il faut dire aussi que XBMC ce n’est pas très pratique à dire, Kodi, c’est sympa non ?

Cependant, cette version 14 qui s’appellera donc Kodi n’est qu’en phase Alpha pour le moment. Pour l’heure, la version d’XBMC 13.1 publiée en juin 2014 est toujours d’actualité et sera suivie de la version 13.2 en version beta actuellement.

Hello Kodi !

Sept mois après la version ownCloud 6, la septième mouture de la plate-forme de stockage et de partage de données en ligne voit le jour. Globalement, cette version a pour objectif de faciliter le partage de fichiers, et, d’améliorer la gestion et la prévisualisation des documents.

De nombreuses nouveautés sont disponibles, pour les plus importantes, on note des améliorations au niveau des fonctionnalités de partage. En effet, il est désormais possible d’activer ou de désactiver la fonction de partage selon des groupes utilisateurs, mais aussi, de filtrer les fichiers selon plusieurs critères, être notifié d’un partage, afficher le nom de la personne qui partage un fichier, etc.

Par ailleurs, ownCloud se met à l’heure du ResponsiveDesign afin que l’interface s’adapte à différentes tailles d’écrans, notamment pour les smartphones et les tablettes. La consultation pourra ainsi se faire aisément peut importe le périphérique depuis lequel vous êtes. Sachez toutefois qu’il est toujours possible de passer par les applications mobiles pour Android et iOS.

Enfin, les performances sont optimisées, les administrateurs seront pourvus de nouvelles fonctions, etc… Globalement la plate-forme se veut encore plus complète qu’auparavant afin de montrer une véritable évolution au fil des versions !

Si vous désirez mettre à niveau votre installation voici la documentation : Update ownCloud

Un tutoriel sera peut être à venir sur le site, puisque je vais sûrement devoir réaliser une mise à niveau de ce type de la version 6 vers la 7.

ownCloud 7

I. Présentation

L’accès SSH à une machine permet de manager cette dernière via un terminal (CLI). Par défaut, on peut utiliser tous les utilisateurs présents sur le système pour s’y authentifier. Néanmoins, il peut être dangereux de laisser l’utilisateur root se loguer en SSH car cela peut ouvrir la porte à des brute force qui donneront un accès direct au plus au niveau de privilège de la machine, c’est pour cela que nous allons voir comment interdire les connexions SSH en tant que root dans ce tutoriel.

II. Procédure

Si SSH est déjà installé (apt-get ou yum install openssh-server si ce n’est pas le cas), sa configuration se trouvera dans “/etc/ssh/sshd_config“. Nous allons dans un premier temps nous y rendre puis y trouver et décommenter la ligne suivante :

PermitRootLogin yes

Après l’avoir décommentée, nous passerons sa valeur “yes” à “no”. Enfin, nous pourrons redémarrer notre service SSH, pour Debian :

service ssh restart

pour CentOS :

service sshd restart

Voila, vous pourrez à présent essayer de vous connecter en root via SSH pour voir que ce n’est plus possible. Si vous souhaitez avoir plus de conseil sur la sécurisation du protocol SSH, suivez le guide : Sécuriser l’accès SSH

L’application de sécurité anti-virus Symantec Endpoint Protection contient trois failles de sécurité zero-day.

Exploiter ces failles permettrait d’obtenir une élévation de privilèges sur la machine, et, obtenir des informations en cache concernant les administrateurs de domaine (identifiants).

Ces failles sont la découverte de la société Offensive Security, spécialisée dans les tests d’intrusion et les formations en sécurité. Mati Aharoni a précisé que la découverte a eu lieu lors d’un test d’intrusion effectué pour une société de services financiers.

Ces informations sont remontées auprès de Symantec qui mène actuellement une enquête.

Source