Outils pour utilisateurs

Outils du site


blog

SSH - l'homme du milieu man-in-the-middle attack - MITM

Voir http://www.phcomp.co.uk/Tutorials/Unix-And-Linux/ssh-check-server-fingerprint.html

/var/log/auth.log
Jan 13 18:08:07 ACME sshd[19573]: Invalid user  from 10.227.01.32
Jan 13 18:08:07 ACME sshd[19573]: input_userauth_request: invalid user  [preauth]
Jan 13 18:08:07 ACME sshd[19573]: Failed none for invalid user  from 10.227.01.32 port 38493 ssh2

Pb

Au début tout commence avec une connexion impossible et une erreur dans /var/log/auth.log Le nom de l'utilisateur n’apparaît pas.

Serveur

for file in *sa_key.pub
  do   ssh-keygen -lf $file
done
1024 82:45:ef:2d:a7:c1:38:30:64:3d:27:5f:07:2d:49:bb ssh_host_dsa_key.pub (DSA)
256 60:1d:11:ae:14:13:91:a6:d6:0c:0b:19:ff:ae:38:50 ssh_host_ecdsa_key.pub (ECDSA)
2048 42:51:fd:3f:d8:5e:ff:0f:7b:b4:ec:00:2b:4f:41:af ssh_host_rsa_key.pub (RSA)

Client

ssh localhost
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is 60:1d:11:ae:14:13:91:a6:d6:0c:0b:19:ff:ae:38:50.
Are you sure you want to continue connecting (yes/no)?
~/.ssh/known_hosts
|1|L/bOL2nijC7tH8OmD3g4wDylRDk=|w2fAVJ4hqgexkcNn1kcQWkWJMwY= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBgwV9MaQTOLDDCtn0hRMZQN9398Z4ciwN+mCKN+ZQ47FgXO/ObM5JRUIdZ68th9whxhaGItdAXjFUTpxhUHgyk=
/etc/ssh/ssh_host_ecdsa_key.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBgwV9MaQTOLDDCtn0hRMZQN9398Z4ciwN+mCKN+ZQ47FgXO/ObM5JRUIdZ68th9whxhaGItdAXjFUTpxhUHgyk= root@debian2

Avec WinScp

Sur le serveur
#ssh-keygen -E md5 -lf /etc/ssh/ssh_host_ed25519_key.pub
awk '{print $2}' /etc/ssh/ssh_host_ed25519_key.pub | base64 -d | md5sum -b
3284028e26ac8b5eec88ce6d978d8e14 *-
Sur le client

Voir : winscp-mitm.png (FIXME)

FIXME: info manquante

2025/03/24 15:06

SNMPd - Configuration et ajout d'IODs perso

Source : http://blog.gamb.fr/index.php?post/2012/10/23/Installation-et-configuration-de-snmpd

Quand la supervision doit récupérer des valeurs systèmes, il y a autant de solutions que d’administrateurs. On peut déployer un agent, ouvrir tous les ports, passer par une page web, faire du ssh, etc. Le moyen le plus simple et efficace est de passer par le protocole SNMP. Il est donc nécessaire d'installer et de configurer un démon SNMP sur vos serveurs. Nous allons rapidement configurer le démon puis nous allons nous attarder sur l'ajout d'OID perso.

Installation

Le démon SNMP est disponible pour quasiment toutes les distributions Linux, je l'avais même installé sur un Solaris 10. Sur un système Red Hat, il suffit de lancer une commande YUM.

yum install net-snmp
chkconfig snmpd on
service snmpd start

Si vous avez des iptables, pensez à ajouter une règle pour autoriser vos machines de supervision. Pour cela, éditer les règles Iptables :

vim /etc/sysconfig/iptables

Et ajouter la règle :

-A INPUT -p udp -s <ip_serveur_supervision> --dport 161 -j ACCEPT

Puis relancer Iptables :

service iptables restart

Configuration

Globalement, le fichier de configuration snmpd est constitué de quatre parties : Les machines autorisées à interroger SNMPd, les droits de lecture/écriture, les vues de la MIB et enfin les accès machines/vues. On édite le fichier :

vim /etc/snmp/snmpd.conf

Premièrement, on va autoriser notre serveur de supervision ainsi que localhost. On ne déclare qu'une seule communauté de sécurité (com2sec) :

com2sec supervision      127.0.0.1                    public
com2sec supervision      <ip_serveur_supervision> public

On va donner des droits à cette communauté de sécurité sous forme de groupes, dans notre cas de la simple lecture :

group   ReadOnly        v2c             supervision

J'ai pour habitude d'autoriser les requêtes en V1 et V2 du protocole SNMP mais vous pouvez activer seulement la V2.

On va ensuite déclarer des vues, c'est à dire des branches de la MIB qui seront consultables. Certains utilisent .1 pour rendre tout l'arbre consultable, pour ma part je préfère n'ouvrir que ce que j'ai besoin :

view    systemInfo      included        .1.3.6.1.4.1.2021.10

Dans cet exemple, on expose que le load average de la machine. N'hésitez pas à faire un snmpwalk pour trouver l'OID des objets que vous souhaitez exposer. (Penser à tout autoriser pour le walk : view systemInfo all .1).

Pour conclure, on va associer les vues aux groupes d'accès (celui où on dit si c'est en lecture ou en écriture) :

access  ReadOnly        ""              any     noauth          exact   systemInfo      none    none

Voila de façon très macroscopique les points importants de la configuration. Plutôt que de m'attarder sur cette partie, je vous fourni un modèle de configuration minimale dans la suite.

Modèle de fichier de configuration

Voici un fichier de conf mini-minimale, je vous conseille de vous faire un fichier équivalent avec les OID communs à tous vos serveurs.

/etc/snmp/snmpd.conf
#
# Fichier de conf minimale SNMPd
#

# Parametres globaux
syslocation <mon_serveur>.<mon_domaine>
syscontact <admin>@<mon_domaine>

# Declaration des machines autorisees
#       Nom             Source          Communaute
com2sec supervision      127.0.0.1           public
com2sec supervision      <ip_serveur_supervision>   public

# Declaration des groupes d'acces
#       Nom             Version         Com2sec
group   ReadOnly        v2c            supervision
group   ReadOnly        v1              supervision

# Declaration des vues
#       Nom             Incl/Excl       Subtree         Masque (optionnel)
view    systemInfo      included        .1.3.6.1.4.1.2021.10

# Association Group et View
#       GroupName       Contexte        Version SecLevel        Prefix  Read            Write   Notif
access  ReadOnly        ""              any     noauth          exact   systemInfo      none    none

# OID perso

Vous constatez à la fin que j'ai prévu une zone pour les OID perso, et oui on peut étendre la MIB suivant nos besoins ! Très pratique pour monitorer des valeurs systèmes spécifiques.

Exécuter ses propres scripts

Il est possible d'étendre la MIB de plusieurs façons. Certains logiciels ajoutent leur OID via un agentx, par exemple cyrus-imap propose cela dans ses versions les plus récentes. Mais des fois, pour des besoins très spécifiques, on aimerait récupérer la sortie d'un script. La chose est faisable très simplement avec snmpd.

Plusieurs directives peuvent être utilisées dans le fichier de conf : pass, exec et extend. Visiblement, le net-snmp disponible sur les RHEL6, ne permet d’utiliser que extend, mais la syntaxe est identique à exec. Pass a un comportement différent, un script n'est pas égale à un OID mais à un ensemble, peut être pratique pour les scripts qui sortent plusieurs lignes de résultat.

Ici, on va mettre en œuvre extend pour exécuter un script sur le serveur supervisé et récupérer la valeur avec snmpget.

On édite le fichier de configuration principal :

vim /etc/snmp/snmpd.conf

A la fin de fichier, on ajoute un appel à notre script :

extend  <oid_perso>   <nom_script_friendlyuser>     <chemin_script>/<script> <args>

Comment choisir un OID perso ? Il y a une branche de la MIB dédiée à cela, elle est préfixé ucdavis (un truc du genre) et son équivalent en numérique est : .1.3.6.1.4.1.2021

Il suffit donc de choisir un suffixe pour votre script. Sur vos nombreux serveurs, faites en sorte de ne pas avoir des scripts qui répondent sur le même OID alors qu'ils ne font pas la même chose, ça sera plus simple à gérer.

Exemple : Récupérer les infos d'un volume groupe LVM

Pour illustrer la puissance des OID perso, on va essayer de récupérer quelques infos concernant un volume group. Premièrement, dans un shell, essayons de trouver la commande qui va bien :

vgdisplay -s VolGroup00

Ce qui renvoi :

"VolGroup00" 136.12 GiB [75.97 GiB used / 60.16 GiB free]

Pour notre exemple, ça sera suffisant, on édite donc le fichier de conf snmp :

vim /etc/snmp/snmpd.conf

On ajoute une vue pour notre OID perso :

view    systemInfo      included        .1.3.6.1.4.1.2021.900

Et on ajoute, à la fin du fichier, la ligne suivante :

extend .1.3.6.1.4.1.2021.900    stats_vg0       /sbin/vgdisplay -s

J'ai choisi l'OID de façon arbitraire et avec une grosse valeur pour éviter d'éventuels conflits. De même, ayez le réflexe de toujours mettre le chemin complet des binaires.

On redémarre notre snmpd :

service snmpd restart

Maintenant, on test avec snmpwalk le résultat :

snmpwalk -c public -v2c localhost .1.3.6.1.4.1.2021.900

Et voici le résultat :

UCD-SNMP-MIB::ucdavis.900.1.0 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.2.1.2.9.115.116.97.116.115.95.118.103.48 = STRING: "/sbin/vgdisplay"
UCD-SNMP-MIB::ucdavis.900.2.1.3.9.115.116.97.116.115.95.118.103.48 = STRING: "-s"
UCD-SNMP-MIB::ucdavis.900.2.1.4.9.115.116.97.116.115.95.118.103.48 = ""
UCD-SNMP-MIB::ucdavis.900.2.1.5.9.115.116.97.116.115.95.118.103.48 = INTEGER: 5
UCD-SNMP-MIB::ucdavis.900.2.1.6.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.2.1.7.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.2.1.20.9.115.116.97.116.115.95.118.103.48 = INTEGER: 4
UCD-SNMP-MIB::ucdavis.900.2.1.21.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.3.1.1.9.115.116.97.116.115.95.118.103.48 = STRING: "  \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"
UCD-SNMP-MIB::ucdavis.900.3.1.2.9.115.116.97.116.115.95.118.103.48 = STRING: "  \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"
UCD-SNMP-MIB::ucdavis.900.3.1.3.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.3.1.4.9.115.116.97.116.115.95.118.103.48 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.900.4.1.2.9.115.116.97.116.115.95.118.103.48.1 = STRING: "  \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"

On constate qu'il s'agit d'un arbre, votre outil de supervision n'a besoin que de la valeur de résultat, on modifie donc notre commande snmpwalk pour ne garder que le nécessaire :

snmpwalk -OQnv -c public -v2c localhost .1.3.6.1.4.1.2021.900.4.1.2.9.115.116.97.116.115.95.118.103.48.1 | tr -d "\""

Ce qui nous donne comme résultat :

\VolGroup00\ 136.12 GiB [75.97 GiB used / 60.16 GiB free]

Conclusion

SNMP peut servir pour toute la supervision, pas besoin d'ouvrir plus de port, d'installer des agents dédiés (nrpe, agent zabbix, etc). Pour les taches un peu plus complexes, déployer un script qui fait le boulot de collecte et de formatage sur votre serveur à superviser et récupérer simplement la valeur via SNMP. Pour info, dans les “data input methods” de Cacti, j'appelle directement une commande snmpget comme celle ci :

snmpget -OQnv -c <snmp_community> -v2c <hostname> <oid_perso> | tr -d "\""
2025/03/24 15:06

Snap snapd le gestionnaire de paquet multi distro

Voir :

Voir aussi :

Install de Snap

sudo apt update
sudo apt install snapd
 
## get the latest snapd
# sudo snap install snapd
 
sudo snap install core

Test

snap install hello-world

Config proxy

sudo -E snap set system proxy.http="$http_proxy"
sudo -E snap set system proxy.https="$https_proxy"

Sous Ubuntu 18.04

# snap list
Name                  Version         Rev   Tracking  Publisher    Notes
core                  16-2.35.5       5742  stable    canonical✓   core
gnome-3-26-1604       3.26.0          74    stable/…  canonical✓   -
gnome-calculator      3.30.1          260   stable/…  canonical✓   -
gnome-characters      3.30.0          139   stable/…  canonical✓   -
gnome-logs            3.30.0          45    stable/…  canonical✓   -
gnome-system-monitor  3.30.0          57    stable/…  canonical✓   -
gtk-common-themes     0.1-4-g88bc1b2  818   stable/…  canonical✓   -
rocketchat-desktop    2.7.0           4     stable    rocketchat✓  -

Install un paquet

sudo snap find notepad
# snap info notepad-plus-plus
sudo snap install notepad-plus-plus
sudo snap install --classic notepadqq

Mise à jour

sudo snap refresh --list
sudo snap refresh

Lancer une application

$ snap list
Name               Version  Rev    Tracking       Publisher   Notes
core               16-2.48  10444  latest/stable  canonical✓ core
pycharm-community  2020.3   222    latest/stable  jetbrains✓ classic

$ snap run pycharm-community &

Redémarrer un service

snap stop multipass
snap start multipass

Logs

journalctl --unit 'snap.multipass*'

Autres

Autre

snap install core
sudo snap refresh core

Remove

apt-get -y autoremove --purge snapd snap-confine snapd ubuntu-core-launcher squashfs-tools

Accès à /etc /var … (mais toujours pas /tmp)

snap install --devmode gedit
snap connect vlc:removable-media
2025/03/24 15:06

signify-openbsd

Liens :

Une alternative à GPG (que pour signer).

C'est fait pour signer des petits fichiers/paquets

Pour des grands fichiers l'idée et de faire un sha256sum et de signer ce fichier de hash.

Dans le dépôt testing

apt-get install signify-openbsd
-p : Public key
-s : Secret key
-m : Message
-x : Signature

-G : Generate key pair
-S : Sign
-V : Verify

Générer une paire de clef

signify-openbsd -G -n -p key.pub -s key.sec

Signer

signify-openbsd -S -s key.sec -m message.txt

Vérifier la signature

signify-openbsd -V -p key.pub -m message.txt

Exemple

find . -type f -exec sha512sum {} \; > sha512sum
signify-openbsd -S -s ../key.sec -m sha512sum
2025/03/24 15:06

Serveur NFS v3 et montage client

Préférez la version 4. Voir NFSv4

Voir :

  • rclone serv

Sur le serveur

/etc/exports
/data/plop                  machine1(async,rw,no_root_squash)
exportfs -rv

Si besion

chmod 1777 /data/plop

Sur le client

/etc/fstab
serveurnfs:/data/plop         /import/plop          nfs     defaults,_netdev,nfsvers=3      0 0

rw,bg,hard,rsize=32768,wsize=32768,tcp,vers=3,timeo=600

mkdir -p /import/plop
mount /import/plop

Mount options

nocto: Suppress the retrieval of new attributes when creating a file.
noac: Disable all forms of attribute caching entirely. This extracts a significant performance penalty but it allows two different NFS clients to get reasonable results when both clients are actively writing to a common export on the server.
noacl: Disables Access Control List (ACL) processing.

vers=4.1: NFS v4.1 should be used instead of v4.0 because there is a Linux NFS client bug in v4.0 that can cause significant problems due to stale data.

nofail: Don't halt boot process waiting for this mount to become available

lookupcache=positive: Tells the NFS client to honor positive cache results but invalidates any negative cache results. Negative cache results cause problems with Git. Specifically, a git push can fail to register uniformly across all NFS clients. The negative cache causes the clients to 'remember' that the files did not exist previously.

Test

Supervision

Voir aussi :

Le plus simple pour monitorer NFS étant de créer un fichier de le l'effacer https://docs.netapp.com/us-en/ontap/nfs-config/test-access-client-systems-task.html

stat -f (system call statfs(2)
If the NFS mount is “stale”, then stat -f returns immediately but with a size of -1. The check detects that and results in a warning state.

mount -l | grep nfs
grep nfs /proc/mounts
nfsstat
nfsstat --mounts
mountpoint -q /mnt/foo
findmnt -rno SOURCE,TARGET "$1"
lsof -b
ss -a|grep :nfs
mountpoint="/mnt/testnfs"
#read -t1 < <(stat -t "$mountpoint" 2>&-)
read -r -t1 < <(stat -t "$mountpoint" 2>&-)
if [ -z "$REPLY" ] ; then
  echo "NFS mount stale. Removing..."
fi
2025/03/24 15:06
blog.txt · Dernière modification : de 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki