https://wiki.archlinux.org/title/Trusted_Platform_Module
TPM : Trusted Platform Module
C’est un crypto-processeur. Il y’a 2 versions : TPM 1.2 et TPM 2.0. Un démarrage en BIOS ne peut utiliser qu’un TPM 1.2 ; l’utilisation de la version 2.0 requiert un boot UEFI.
Voir si on a un TPM :
devmgmt.msc -> Périphériques de sécurité (Security Devices)
Centre de sécurité -> Sécurité des appareils
tpm.msc
sudo journalctl -k --grep=tpm
ou
sudo dmesg | grep -i tpm
https://www.lecoindunet.com/comprendre-notion-vlan-tagged-untagged-1629 http://www-igm.univ-mlv.fr/~dr/XPOSE2007/vlanparlegrandquinapascomprislesconsignes/Definition.html https://www.bicomm.fr/vlan-quest-ce-que-le-pvid/
Flux taggé : la trame ethernet contient une en-tête (tag) qui spécifie l’ID du VLAN (encapsulation 802.1Q)
Flux non-taggé : ne contient pas cette en-tête
Appareil taggeur : capable d’envoyer un flux taggé (tagged)
Appareil non-taggeur : envoie un flux non-taggé (untagged)
Les cartes réseaux de PC envoient par défaut un flux non-taggé, mais certaines sont capables de produire un flux taggé si l’OS est correctement configuré et que le pilote le supporte.
Voir exemple sous Linux plus loin.
Les switchs modernes, même non-gérés basiques, ont tendance à laisser passer intactes les trames taggées, même si ils ne les comprennent pas. Ceci explique que des appareils taggeurs derrière des switchs basiques soient en mesure de se connecter à différents VLANs.
Mais ceci a toutefois des répercussions sur la sécurité, car il n’y a plus de réelle isolation de port et tous les VLAN sont mélangés. Il est aussi probable que d’autres problèmes découlent de ce branchement, non recommandé.
Trafic entrant = ingress
Trafic sortant = egress
Port VLAN IDentifier : le numéro de VLAN dont seront taggées les trames Untagged entrant par ce port.
Ainsi, un pc relié à un port PVID 3 envoie une trame Untagged, qui se fait tagger au moment de son entrée dans le switch.
Le tag (ou absence de tag) avec lequel elle sortira du switch dépendra de la configuration du VLAN/port du port sortant (mais pas de son PVID).
Une trame circulant dans un switch VLAN-capable est systématiquement taggée ; soit la trame rentre taggée, et elle conserve son tag, soit la trame rentre Untagged et elle hérite du PVID du port.
L’appartenance à un VLAN ou un autre n’empêche pas le switch de savoir sur quel port est situé telle adresse MAC ou IP ; il sera toujours en mesure déterminer le trajet correcte d’une trame (mais pourra l’autoriser ou non).
Les switchs managés n’acceptent généralement la communication (administration, et même ping) que sur un seul VLAN. Par défaut, c’est le 1, mais il est paramétrable.
Ceci peut expliquer que les connexions réseaux fonctionnent correctement entre plusieurs ports différents, mais pas avec le switch ; il ignore simplement les requêtes si elles viennent du mauvais VLAN.
Les prises réseaux accessibles aux utilisateurs finaux sont à considérer comme non-fiables, car n’importe qui peut configurer son poste pour se connecter à un VLAN précis, comme celui d’admin.
On appelle ces ports “port access”, et l’idée est de leur mettre le PVID du VLAN endusers, de “untag” le trafic sortant avec ce VLAN, et de n’autoriser que le trafic de ce VLAN.
Les appareils sur ces ports
À l’inverse, les ports permettant de connecter plusieurs switchs doivent pouvoir faire transiter plusieurs VLAN différents. Ils ne doivent pas être accessibles à n’importe qui.
On appelle ces ports “ports trunk”, et
https://www.ksh-linux.info/reseaux/linux/vlan-debian
sudo apt install vlan
sudo modprobe 8021q
Je crois qu’il est nécessaire que la carte réseau parente (ou le pilote ?) supporte les fonctionnalités de VLAN.
J’ai effectué avec succès la manip sur différentes cartes réseau rj45 ou wifi, ainsi que sur un pont OpenVPN (à faire sur le client, en prenant l’interface tap comme parent ; pas besoin de manip au niveau du serveur ; mais je suppose qu’il est nécessaire que les cartes réseaux du serveur et du client supportent les VLANs).
On définit les caractéristiques du VLAN que l’on souhaite créer, et l’IP/masque à donner à l’interface (non nécessaire pour du DHCP) :
PARENT_IFACE=eth0
VLAN_ID=10
VLAN_IFACE=$PARENT_IFACE.$VLAN_ID
IP=10.0.0.1
MASK=24
BROADCAST=10.0.0.255
sudo ip link add link $PARENT_IFACE name $VLAN_IFACE type vlan id $VLAN_ID
L’interface est alors visible dans ifconfig -a ; elle aura la même adresse MAC que l’interface physique.
On l’active :
sudo ip link set dev $VLAN_IFACE up
On définit son IP/masque :
sudo ip addr add $IP/$MASK brd $BROADCAST dev $VLAN_IFACE
ou on peut demander du dhcp :
sudo dhclient -v $VLAN_IFACE
Pour voir le détail de l’interface vlan, notamment son id :
ip -d link show $VLAN_IFACE
Pour la supprimer :
sudo ip link del $VLAN_IFACE
Chaque port a une politique concernant chacun des VLAN, qui spécifie comment doit être traité le trafic taggé de ce VLAN lorsqu’il sort par ce port (trafic egress) :
Dans le cas où :
En effet, ce filtrage ne s’applique qu’en sortie. Les trames (non taggées) entrantes par ce port seront taggées 4 par le switch, elles auront le droit de sortir par les autres ports, et lors de la réception de la réponse, elles seront taggées d’un autre VLAN (car aucun autre port n’a le PVID 4 et aucun appareil n’est explicitement sur le VLAN 4), et elles auront le droit de ressortir par ce port, en tant que Untagged, et donc comprises par l’appareil d’origine.
On peut définir qu’un port n’accepte (entrant ou sortant ? ) que du trafic taggé, ou que du trafic non taggé, ou les 2.
Si activé, le switch drop tous les paquets taggés avec un VLAN auquel le port n’appartient pas.
Si activé, et qu’une authentification réseau 802.1x est présente, les utilisateurs qui se branchent mais n’ont pas de credentials valides seront envoyés sur le Guest VLAN (si le port est configuré pour l’accepter bien sûr).
Pour que le port accepte de transmettre même les trames appartenant à des VLAN inconnus.
-> à activer (éventuellement) pour les ports reliés à d’autres switchs, par les ports reliés à des équipements finaux
Si VLAN Trunk est activé mais Ingress check est activé aussi, je suppose que le Trunk ne fonctionne pas ?
openssl x509 -in ./cert -text -noout
Pour outrepasser les valeurs du fichier vars, on peut forcer les durées de certificat client avec :
export EASYRSA_CERT_EXPIRE=3650
(et pareil pour les autres variables )
Si fichier .crt :
cat monClient.crt | grep Validity -A 2
Fichier PEM : ??
cd pki/issued
find ./ -iname "*.crt" -exec grep Subject: {} \; -exec grep Validity -A 2 {} \; -exec echo "" \;
fichier .req
??
Sur PC : JOSM. Installer un plugin : Édition -> Préférences -> Greffons (besoin de redémarrer appli) Plugin “reverter” permet de défaire un changeset via son ID (vérifier conflits potentiels)
Sur Android : Vespucci
Il vaut mieux utiliser la clé “disused” plutôt que de supprimer le noeud ; surtout si les locaux n’ont pas changé ; ainsi on conserve l’historique, l’adresse etc. https://help.openstreetmap.org/questions/70903/ideditor-change-a-poibusiness-to-closed https://wiki.openstreetmap.org/wiki/Key:disused:*
Vespucci a un preset pour ça : éditer le noeud -> Preset -> Cycle de vie -> Set to disused
Lorsqu’on est sur place, il faut mentionner “survey” en tant que source https://wiki.openstreetmap.org/wiki/Key:source?uselang=en#General_sources_commonly_used_by_human_mappers
https://osmcha.org/ New filter -> Flagged : yes ; reason : review requested
Authentification OpenVPN contre un domaine Active Directory
sudo apt install openvpn-auth-ldap
server.conf:
client-cert-not-required
# Auth LDP (Active Directory)
plugin /usr/lib/openvpn/openvpn-auth-ldap.so "/etc/openvpn/auth/auth-AD.conf"
Créer le fichier d’authentification pour qu’OpenVPN puisse aller lire l’annuaire
sudo cp /usr/share/doc/openvpn-auth-ldap/examples/auth-ldap.conf /etc/openvpn/auth/auth-AD.conf
En voici une version minimale :
<LDAP>
# LDAP server URL
URL ldap://10.0.0.10:3268
BindDN "openvpnbinduser@mycompany.com"
Password mysweetsecretpassword123
Timeout 15
TLSEnable no
FollowReferrals yes
</LDAP>
<Authorization>
BaseDN "DC=paris,DC=myCompany,DC=com"
# User Search Filter
SearchFilter "(sAMAccountName=%u)"
# Require Group Membership
RequireGroup true
<Group>
# BaseDN must be the DN of the group containing VPN-allowed users
BaseDN "CN=VPN Users,OU=Groups,OU=IT,DC=paris,DC=myCompany,DC=com"
SearchFilter "(objectClass=group)"
MemberAttribute Member
</Group>
</Authorization>
Il est possible de spécifier la nécessité d’appartenance à un groupe directement dans le champ SearchFilter, comme ceci :
SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Users,OU=Groups,OU=IT,DC=paris,DC=myCompany,DC=com))"
RequireGroup false
Supprimer les lignes fournissant le certificat/clé du client.
Ajouter une ligne contenant auth-user-pass pour demander les identifiants à la connexion.
En cas d’erreur lors de la connexion d’un client, on aura le message :
PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-ldap.so
Sun Mar 14 11:54:21 2021 82.64.166.200:1194 TLS Auth Error: Auth Username/Password verification failed for peer
L’erreur peut venir de la connexion du serveur VPN à l’AD (l’identifiant client est donc impossible à vérifier), ou bien d’un identifiant incorrect (le couple user/pass est incorrect, ou bien l’identifiant n’existe pas).
Dans les logs, si on a le message :
LDAP bind failed: Invalid credentials (80090308: LdapErr: DSID-0C090453, comment: AcceptSecurityContext error, data 52e, v3839)
Unable to bind as user@domain.com
C’est que l’identifiant de bind (l’identifiant utilisé par le serveur VPN pour se connecter sur l’AD) est incorrect.
Si on a :
LDAP user "myuser" was not found.
c’est que l’identifiant client est invalide
Si on a :
LDAP bind failed: Invalid credentials
Incorrect password supplied for LDAP DN "CN=myUser,CN=Users,DC=paris,DC=mycompany,DC=com"
c’est que l’identifiant est OK, mais le mot de passe invalide
VGA version Télécharger le fichier .bz2 et dézipper le fichier .img. dd le fichier .img sur support USB Boot sur la clé USB Détéction manuelle des interfaces (via branchement du cable)
login : installer pass : opnsense (default) (possible de faire l’install en ssh ; ça écoute sur l’adresse 192.168.1.1)
change keymap fr.kbd install sur ada0 (vérifier que la taille correspond au disque physique) GPT/UEFI mode (cpdup dure un peu)
définir le pass root reboot
paramértage via web gui check update enable ssh ()
Créer un nouveau calendrier vide le ranger par exemple dans le dossier Calendrier (pas important)
Clic-droit dessus -> Partager -> Partager le calendrier (ne fonctionne qu’avec d’autres utilisateurs Exchange, voire du même tenant j’ai l’impression)
Choisir le(s) users qui doivent avoir accès au calendrier Cocher la case “Les destinatire peut ajouter, modifier et supprimer…” si besoin (ceci va modifier les autorisations nécessaires dans Propriétés -> Autorisations d’accès ; Soit “relecteur” si pas d’autorisation d’écriture, soit “éditeur” si RW )
Envoyer le mail
Les utilisateurs reçoivent un mail avec un bouton permettant d’ajouter le calendrier aux leurs
Les evenements sont alors synchronisés
Si les autorisations sont ajoutées après coup, il faut que les utilisateurs suppriment puis réajoutent le calendrier partagé. Le bouton du même mail peut être utilisé, les autorisations seront les actuelles.
Si la synchro avec un poste pose problème, il faut suprimer/réajouter le calendrier.
La synchro peut mettre qqs dizaines de secondes
“Envoyer le calendrier par courrier” : crée un fichier .ics qui sera envoyé en pièce-jointe. Aucune synchro
“Publier ce calendrier” : ouvre le webmail et permet de créer un lien vers le calendrier hébergé en ligne, soit au format html soit au format ics (genre https://hebergeur.com/calendar.raphael.ics ) Ce calendrier sera uniquement consultable, pas modifiable par les invités
https://tldp.org/LDP/tlk/dd/pci.html
Les bus PCI-e sont différents bus, qui sont reliés ensemble (par des ponts), et peuvent également être reliés à d’autres bus (par exemple le bus ISA).
Ces bus sont hiérarchisés : le complexe PCI-e racine “alimente” plusieurs bus PCI-e enfants.
Le lien vers le pont parent est appelé “upstream”, celui vers le pont/périphérique enfant “downstream”.
Le bus racine définit le départ de la hiérarchie. Chaque port sur le bus racine définit un domaine ; dans la plupart des machines, il n’y aura qu’un seul domaine (0000).
Un “endpoint” est un périphérique PCI (carte réseau, carte graph, controlleur SATA etc…). Un endpoint possède au moins 1 fonction (la fonction 0), et peut supporter jusqu’à 8 fonctions.
Un “lien” (link) représente la liaison entre 1 pont PCI-e et 1 (et 1 seul) périphérique, ou entre 2 ponts PCI-e.
La génération se définit par le nombre de transferts par seconde, par ligne : PCI-e 1.0 : 2.5 GT/s (soit 250 Mo/s) PCI-e 2.0 : 5 GT/s (soit 500 Mo/s) PCI-e 3.0 : 8 GT/s (soit 984 Mo/s) PCI-e 4.0 : 16 GT/s (soit 1969 Mo/s)
En plus de ça, il peut y avoir plusieurs lignes en parallèle : x1 pour 1 seule ligne, x4 pour 4 lignes, x8 pour 8 lignes et x16 pour 16 lignes.
pour lister les périphériques pci : lspci. L’adresse est sous la forme bus:device.fonction
Pour afficher les identifiants (pciids), utiliser -nn
Afficher le domaine des périphériques (masqué par défaut lorsqu’il vaut 0000 partout) : lspci -D
Pour lister le détail d’un périphérique (par exemple l’adresse 02:00.0) : lspci -s 02:00.0 ou lspci -s 2:0
Pour voir le détail des vitesses d’un port ou périphérique : sudo lspci -s 02:00.0 -vv | grep Speed
LnkCap : capacité max du périphérique (Speed : gen PCI-e ; Width : nombre de lignes).
LnkSta : statut actuel du périphérique. Dépend de la gen PCI-e de la carte-mère, et du pilote. Certains périphériques peuvent adapter leur vitesse à la volée (par exemple certaines cartes nvidia)
Lister tous les noms de périphériques et les vitesses : sudo lspci -vv | grep "[a-z0-9][a-z0-9]:[a-z0-9]\|Speed"
Afficher l’arbre PCI : lspci -t (plus lisible avec lspci -tv
Via dmidecode : dmidecode --type 9
Accessible en web interface sur l’ip du la machine/container, sur le port 9000 en http http://localhost:9090
L’ensemble des métriques est dispo ici :
http://localhost:9090/metrics
Par défaut (avec le fichier de conf fourni dans l’image docker), il se “monitore lui-même” avec un job “prometheus”
Possible de lui donner d’autres targets à interroger
http://localhost:9090/targets
Error Correction Code
nb de modules impairs
Notée avec un “E”, par exemple PC3-12800E.
Si des barrettes non-ECC sont insérées avec des barrettes ECC dans un PC, l’ECC sera désactivé.
Il faut que la carte-mère supporte l’ECC pour que la fonctionnalité soit activée.
Il peut être possible d’utiliser une barrette ECC dans une carte-mère non-ECC (sans le support de l’ECC).
Pour que l’ECC fonctionne, il faut qu’il soit supporté par :
Pour l’instant, l’ECC n’est pas reporté par memtest86+ .
Il l’est par memtest86 Passmark (dans System Information, et dans “RAM Config” sur l’écran de test).
sudo dmidecode -t 16
donnes des infos sur le controlleur mémoire, et notamment “Error Correction Type”.
“None” indique une absence de prise en charge de l’ECC (par la carte-mère ou le CPU ou la RAM)
Sinon “Single-bit ECC” ou “Multi-bit ECC”.
sudo dmidecode -t 17
donne des infos sur les barrettes mémoire, et notamment “Error Information Handle”
“Not Provided” semble signifier que l’ECC n’est pas activé.
Si “Total Width” est + grand que “Data Width” c’est qu’il y’a un chip pour l’ECC ; cela reflète l’état physique du module, mais pas l’activation effective de l’ECC.
EDAC (Error Detection And Correction)
sudo apt install edac-utils
sudo edac-util
sudo edac-util --status
lsmod | grep -i edac
Si l’ECC est activé, on peut voir “No Error” (je suppose que si une barrette est défectueuse, le message sera différent).
wmic MemoryChip get DataWidth,TotalWidth
wmic MemPhysical get MemoryErrorCorrection
Valeurs :
0 (0x0) Reserved
1 (0x1) Other
2 (0x2) Unknown
3 (0x3) None
4 (0x4) Parity
5 (0x5) Single-bit ECC
6 (0x6) Multi-bit ECC
7 (0x7) CRC
https://superuser.com/questions/893560/how-do-i-tell-if-my-memory-is-ecc-or-non-ecc
https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-physicalmemoryarray
La mémoire à registres est également nommée “registered”, “buffered” ou encore RDIMM. Typiquement PC3-12800R
À l’inverse, la mémoire sans registres est également nommée ““unregistered”, “unbuffered” ou encore UDIMM”. Typiquement PC3-12800U.
Le type de mémoire doit correspondre au type supprté par la carte-mère (registered ou registered).
La majorité des cartes-mères grand public nécessitent de la ram unregistered.
La mémoire format ordinateur portable est appelée SoDIMM (small outline).
Elle est aussi notée avec un S, par exemple PC3-12800S.
S : sodimm
R : registered
U : unbuffered
E : ECC
MT/S : megatransfers/seconds, parfois notée en MHz.
Memtest86+ v7 indique la vitesse effective sous l’intitulé “IMC”.
Memtest86+ v6 n’indique pas correctement les fréquences ou les timings ; il indique ceux qui seraient utilisés si la RAM fonctionnait aux performances maximales.
Memtest86+ v5.x indique les infos correctes une fois le test lancé. La fréquence indiquée est toutefois celle du bus (donc la moitié de la fréquence de la RAM).
sudo dmidecode -t 17
La ligne “Speed” donne la vitesse max théorique du module (pas toujours bien détecté).
La ligne “Configured Speed” donne la vitesse effective actuelle du module.
Standards : PC5-32000 to PC5-51200
XMP :
DDR3-800 = 800MT/s = PC3-6400 = 400 MHz (bus)
DDR3-1066 = 1066MT/s = PC3-8500 = 533 MHz (bus)
DDR3-1333 = 1333MT/s = PC3-10600 = 666MHz (bus)
DDR3-1600 = 1600MT/s = PC3-12800 = 800 MHz (bus)