Avec Everything et Flow Launcher, vous avez le combo gagnant pour une recherche windows rapide et pertinante… Surtout…

Installation

Via winget : winget install Flow-Launcher.Flow-Launcher voidtools.Everything
Via les sites officiels : everything et flow-launcher

Configurer Everything

Désactiver l’indexation de tous les drives

Dans les options d’Everything, allez dans Indexes > NTFS

1. Retirer les automatismes
2. pour chaque volume actuel, décocher Include in database et appliquer

Dans Indexes > Folders :

1. Ajouter vos répertoires de documents, vos nextcloud, vos onedrive
2. Pour chacun d’entre eux, planifier un scan à une heure où le pc est allumé, comme à midi
3. scanner tout

Arrêter la recherche windows indexed

Aller dans Windows Search settings > Advanced Search indexer Settings > Modify et retirez tous les disques, laissez Start Menu histoire de garder quelques chose si Microsoft pousse une mise à jour qui réactiverait l’indexation

Arrêtez le service d’indexation via services.msc

configurer Flow launcher

Au lancement, suivez les instructions

Choisissez une raccourci non utilisé, dans mon cas, ALT+F :

Activer Flow Launcher au démarrage :

Allez dans les settings de Flow Launcher > Plugins Explorer :

Dans l’onglet Everything Settings, indiquez le chemin du bin d’everything : C:\Program Files\Everything\Everything.exe

Dans l’onglet General Setting

• sélectionnez Everything au lieu de Windows Index pour la recherche
• Allez désactiver l’indexation windows si ce n’est déjà fait
• Dans mon cas j’utilise le launcher en priorité pour les recherches de fichiers, donc je veux que les résultats de ce plugin soit en haut de la liste, priorité 5

Enjoy avec ALT+F

L’article Recherche rapide windows avec Everything et Flow Launcher est apparu en premier sur Mon linux.

Pour utiliser Nmap pour identifier l’OS Windows, vous pouvez utiliser la commande suivante :

nmap -O [IP_ADDRESS]

Pour l’identification plus poussée via le protocole SMB :

export NMAPDIR=.
mkdir scripts

wget http://nmap.org/svn/scripts/smb-os-discovery.nse

nmap --script smb-os-discovery.nse -p445 127.0.0.1

nmap -sU -sS --script smb-os-discovery.nse -p U:137,T:139 127.0.0.1

Nmap scan report for 10.xx.xx.xx
Host is up (0.00020s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: F8:BC:xx:xx:xx:xx (Unknown)
Host script results:
| smb-os-discovery:
|   OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
|   NetBIOS computer name: IHATEWINDOWS
|   Workgroup: WORKGROUP
|_  System time: 2015-03-20 22:55:05 UTC+1

Nmap done: 1 IP address (1 host up) scanned in 0.49 seconds

La librairie se trouve ici : smb-os-discovery NSE Script.

Ce ne sera que les windows répondant à SMB.

Et la version qui essaye d’authentifier l’OS comme précédemment + les hotes en samba (plus fouillis mais au moins on prouve que c’est du matos switch, linux, vmware, etc)

nmap --script smb-os-discovery.nse -O -p445 10.102.69.0/22 --exclude 10.102.69.107 > scan-$(date '+%d-%m-%Y-%H-%M.txt')

Disponible en version graphique avec zenmap.

L’article NMAP – identification exacte de l’OS d’un Windows est apparu en premier sur Mon linux.

Ce script permet de lancer un tunnel SSH vers un serveur et ensuite de lancer Proxifier afin de faire passer mon trafic ce manière sécurisé car mes deux types de VPN ne passaient pas sur ce réseau. Pourquoi faire cela ? Car sur ce réseau, de l’analyse des paquet https est faite via le firewall qui chiffre à la volée avec un certificat interne sur la machine du parc. Les mots de passe sont redevenus en claire pour le firewall….

Le script actions_connection_event.ps1

Ce script actions_connection_event.ps1 est à mettre dans un répertoire C:\Scripts :

[void][Windows.Networking.Connectivity.NetworkInformation, Windows, ContentType = WindowsRuntime]


$rootedConnexion="WIfiX","WifiY"

# can be a path
# or an array of 3 string : path / -argumentList / -WindowStyle
$exeToStart= @(
  @("ssh","home-socks -p 2222","hidden"),
 "C:\Program Files (x86)\Proxifier\Proxifier.exe"
)


$pidFile=$env:TEMP+'\tunnelSocksProcess.pid'

$connProfil = [Windows.Networking.Connectivity.NetworkInformation]::GetInternetConnectionProfile()
$actuelNetworkNames=$connProfil.GetNetworkNames()

# check if pid not already running
if (-not(Test-path $pidFile -PathType Leaf)) {
  if ($actuelNetworkNames -in $rootedConnexion) {
    foreach ($exe in $exeToStart) {
      if ($exe -is [array]) {
        Start-Process -FilePath $exe[0] -argumentList $exe[1] -WindowStyle $exe[2] -PassThru | select-object -ExpandProperty id | Out-File -Append -FilePath $pidFile
        # -PassThru return a process object # -ExpandProperty get only the value (no header)
      }
      else {
        Start-Process -FilePath $exe -PassThru | select-object -ExpandProperty id | Out-File -Append -FilePath $pidFile
      }
    }
  }
}
# if pid exist, check if network change
else {
  if (-not($actuelNetworkNames -in $rootedConnexion)) {
    #write-host "Network change"
    $currentPid=get-content -Path $pidFile
    stop-process -id $currentPid
    remove-item $pidFile
  }
}

#write-host "Actual network : $actuelNetworkNames"

Tâche planifiée

Pour tester la tâche planifiée, l’event choisi doit être :

• Log : Microsoft-Windows-NetworkProfile/Operationel
• Source : NetworkProfile
• Event ID : 10000

Dans les actions, pour tester, faite avec une simple commande :

cmd.exe /c "echo network change && pause"

On n’oublie pas de désélectionner le fait de démarrer uniquement lorsque l’on est sur secteur.

On change de connexion pour le teste et une fois validé on va mettre la bonne action :

powershell.exe C:\Scripts\actions_connection_event.ps1

L’article Lancement de tâches à un changement de connexion réseau est apparu en premier sur Mon linux.

Installer docker Desktop : Documentation et téléchargement direct.

Commencer par installer le plugin Portainer, cela vous permettra de travailler proprement avec des docker-compose plutôt que de simple container. Il est évidemment possible de faire en ligne de commande, mais l’interface est plus convivial pour du développement.

Ouvrir Portainer :

En configuration pour développement local utiliser Get Started :

Nous pouvons expendre le menu pour se repérer plus facilement la première fois :

On sélectionne notre environnent local pour créer un réseau afin qu’il soit permanent pour être utilisé entre notre reverse proxy Traefik et nos apps. Je le nomme proxy-net :

Notre réseau est présent avec un range IP attribué : 172.24.0.0/16. Si cela pose problème avec un réseau déjà existant dans l’entreprise, vous pouvez en attribuer un autre

On crée notre stack Traefik et un stack Mailhog comme exemple d’application web derrière Traefik. Cela peut être via un copier coller, mais aussi via un repository. Pratique pour mettre le docker-compose.yml dans notre projet directement

Stack de traefik sous Docker Desktop

Voici la stack ou docker-compose pour Traefik :

version: "3.7"

services:
  proxy:
    image: "traefik:v2.8"
    container_name: proxy
    command:
      - --entrypoints.web.address=:80
      - --providers.docker
      - --api.insecure
    ports:
      - "80:80"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    networks:
      - proxy-net

    labels:
      - traefik.enable=true
      - traefik.http.services.mgt.loadbalancer.server.port=8080
      - traefik.http.routers.mgt.entrypoints=web
      - "traefik.http.routers.mgt.rule=Host(`mgt.localhost`)"

networks:
  proxy-net:
    external: true

On test via l’url http://mgt.localhost si on a bien l’interface traefik :

Pas besoin d’ajouter quoi que ce soit dans son fichier hosts pour un sous domaine de localhost.

On y voit déjà notre première application qui passe par le reverse proxy qui n’est autre que l’interface de management de traefik. Dans un environnent accessible depuis l’extérieur nous devrions sécuriser l’accès via un login/password. Mais ici aucune nécessité en localhost sur notre pc si notre fw est bien configuré.

Pour le sécuriser, générer un mot de passe pour Apache via un container :

docker run --rm --name apache httpd:alpine htpasswd -nb user password

Les labels :

- "traefik.http.middlewares.auth-mgt.basicauth.users=MONUSER$xxxx$$STiVjGO4$ATj6up2mVZR7Jqk4YzD8h."
- traefik.http.routers.mgt.middlewares=auth-mgt

Stack de Mailhog sous Docker Desktop

Les points importants sont de déclarer ET d’utiliser le réseau proxy-net commun avec le reverse proxy pour que celui-ci puisse communiquer avec notre application en backend.
Quand un container de notre application expose plusieurs ports, bien définir à Traefik lequel utiliser via loadbalancer.server.port car il ne sera pas choisir à notre place… S’il n’y a qu’un seul port d’exposer, le label est facultatif.

version: "3.7"
networks:
  proxy-net:
    external: true

services:
  mailhog:
    image: mailhog/mailhog
    container_name: mailhog
    ports:
      - 25:25
    networks:
      - proxy-net
    user: root
    labels:
      - traefik.enable=true
      - traefik.http.services.mailhog.loadbalancer.server.port=8025
      - traefik.http.routers.mailhog.entrypoints=web
      - "traefik.http.routers.mailhog.rule=Host(`mailhog.localhost`)"

Une fois le stack lancé, on le voit sur la page de management de traefik et il est accessible via l’url http://mailhog.localhost :

L’article Minimal Docker Desktop stack de développement sous windows est apparu en premier sur Mon linux.

Il est intéressant de savoir comment récupérer ces informations brutes, afin d’identifier les objets à intégrer à notre système de monitoring par exemple.

Linux

Le client pour récupérer les données

J’utilise Debian Wheezy pour ces notes. Voici de quoi récupérer toutes les informations SNMP, que ce soit en SNMP v1 ou v2c. La version sécurisée de SNMP sera vue plus tard.

Les paquets nécessaires :

#apt-get install snmp snmp-mibs-downloader

Éditer le fichier /etc/snmp/snmp.conf et commenter la ligne « mibs: »
Les MIB ne sont pas sélectionnées par défaut lorsque l’on interroge un périphérique. Il faut le spécifier avec l’option -m

# snmpwalk -m UPS-MIB -c public -v 2c ups2 1.3.6.1.2.1.33.1.2.5
UPS-MIB::upsBatteryVoltage.0 = INTEGER: 857 0.1 Volt DC
# snmpwalk -v 1 -c public 192.168.29.5

Afin d’obtenir l’OID, numéro unique permettant d’identifier la variable SNMP, voici un exemple pour l’uptime :

# snmpwalk -On -v 1 -c public 192.168.56.21 .1.3.6.1.2.1.25.1
    .1.3.6.1.2.1.25.1.1.0 = Timeticks: (705809) 1:57:38.09

Cet OID sert à créer le service dans un logiciel de monitoring comme Centreon par exemple.

-On  permet d’avoir l’OID et pas la translation du nom

Pour avoir les noms d’affichés au lieu des OID, on spécifie les MIB à utiliser :

# snmpwalk -v 2c -c monitor -m UPS-MIB 10.184.4.250
UPS-MIB::upsIdentManufacturer.0 = STRING: AEG Power Solutions GmbH
UPS-MIB::upsIdentModel.0 = STRING: Protect D.
UPS-MIB::upsIdentUPSSoftwareVersion.0 = STRING: n/a
UPS-MIB::upsIdentAgentSoftwareVersion.0 = STRING: CS121 v 4.42.2
UPS-MIB::upsIdentName.0 = STRING: CS121 SNMP/WEB Adapter
UPS-MIB::upsIdentAttachedDevices.0 = STRING: UPS protected devices
UPS-MIB::upsBatteryStatus.0 = INTEGER: batteryNormal(2)
UPS-MIB::upsSecondsOnBattery.0 = INTEGER: 0 seconds
UPS-MIB::upsEstimatedMinutesRemaining.0 = INTEGER: 75 minutes
UPS-MIB::upsEstimatedChargeRemaining.0 = INTEGER: 100 percent

Autre commande :

# snmpbulkget -c public -v 2c 192.168.56.21 system ifTable

Traducteur d’OID en nom compréhensible :

# snmptranslate -m ups-mib 1.3.6.1.2.1.33.1.2

Plus d’infos sur les MIB existantes sur le site oidview.com. Par exemple pour les MIB d’UPS voir ce lien direct.

Ces commandes servent surtout à vérifier le « background » de notre installation. Il faut installer un vrai système d’alertes comme Nagios ou Centreon. Ce dernier gère également la métrique. Un article sera prochainement consacré à celui-ci.

L’installation du daemon

Afin de monitorer un serveur Linux, on installe un service snmpd et ses dépendances. Cela permettra à notre serveur de monitoring de récupérer les données du serveur Linux.

C’est notre serveur de monitoring (ou le serveur ayant snmpwalk) qui fera la demande au serveur à surveiller de manière régulière. On appelle ça un « pull ».

# apt-get install snmpd

Éditer le fichier /etc/snmp/snmpd.conf pour modifier les points essentiels de la configuration :

# diff /etc/snmp/snmpd.conf.ori /etc/snmp/snmpd.conf 
15c15 
< agentAddress  udp:127.0.0.1:161 
--- 
> #agentAddress  udp:127.0.0.1:161 
18a19,28 
> # SECNAME SOURCE COMMUNITY nom de sécurité    réseau    communauté SNMP 
> com2sec    localnetwork    192.168.56.20/32    public 
> # groupe en ro v1 
> group    rogroup    v1    localnetwork 
> 
> # vue pour préciser ce qui est accessible pour le groupe (ici all) 
> ## on déclare la vue 
> view all included .1 80 
> ## on fait l'association avec le groupe 
> access rogroup "" any noauth exact all none none 
45,46c55,56 
< view   systemonly  included   .1.3.6.1.2.1.1 
< view   systemonly  included   .1.3.6.1.2.1.25.1 
--- 
> #view   systemonly  included   .1.3.6.1.2.1.1 
> #view   systemonly  included   .1.3.6.1.2.1.25.1 
51c61 
<  rocommunity public  default    -V systemonly 
--- 
> # rocommunity public  default    -V systemonly 
60c70 
<  rouser   authOnlyUser 
--- 
> # rouser   authOnlyUser

Si besoin, éditer /etc/default/snmpd et rajouter les IP qui doivent écouter à la fin de la ligne suivante :

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 192.168.56.21'

On redémarre le service snmpd et notre système est prêt

Il faut savoir qu’il existe aussi des traps SNMP, qui permettent de faire un « push ». C’est le serveur à surveiller qui va informer le serveur de monitoring d’un problème immédiatement au lieu d’attendre que le serveur de monitoring l’interroge.

Windows

Dans cet article, je ne verrai que le SNMP v2c, pas la version sécurisée SNMP v3.

Étape 1 facultatif

Pour windows Seven uniquement,il faut d’abord ajouter le composant windows dans le panneau de configuration :

Control Panel > Programs and Features. > "Turn Windows features on or off" > Windows Features > select "Simple Network Management Protocol (SNMP)"

Pour un windows serveur, on passe directement à l’étape suivante.

Étape 2 Firewall

On configure le firewall pour autoriser le port SNMP (161) en entrée :

Control Panel > System and Security > Windows Firewall > Advanced Settings

De là, on déroule « Windows Firewall with Advenceds Security » pour atteindre « Inbound Rules »

Dans le menu de droite :

"New Rules..." > Predefined Rules > SNMP service

On active la règle souhaitée selon le profil (Généralement la première « Domain »).

Étape 3 Activer le service SNMP

Il faut directement aller dans les services windows :

Manage computer > Service and Applications > Services > SNMP Agent > Enabled Automatic.

Pour plus d’infos :https://docs.microsoft.com/fr-FR/troubleshoot/windows-server/networking/configure-snmp-service

Ensuite, dans l’onglet Agent, on rempli le champ Contact et Location, on coche tous les services à monitorer.

Dans l’onglet Security :

• Dans Accpeted community names, on clique sur Add pour mettre en READ ONLY le community name « public »
• Dans Accept SNMP packets from these hosts, on ajoute l’IP de Centreon en cliquant sur Add
• On applique et on redémarre le service

Dans Centreon, il y a par défaut : l’espace disque, la RAM, le CPU. Voir pour d’autres via interrogation direct selon l’OID ou via scripts Nagios.

L’article Introduction SNMP sous Linux, Windows, etc est apparu en premier sur Mon linux.