Brouillons d'un g33k

Categories

01 Jan 0001, 00:00

https://unix.stackexchange.com/questions/307994/compute-bcrypt-hash-from-command-line

sudo apt install python3-bcrypt

python -c ‘import bcrypt, getpass; print(bcrypt.hashpw(getpass.getpass().encode(), bcrypt.gensalt()).decode())’

01 Jan 0001, 00:00

Orga générale

Plusieurs serveurs DNS racines gérés par différentes entités (Verisign, NASA, ICANN, universités américaines etc) https://www.iana.org/domains/root/servers

Un serveur DNS stocke en dur les IP de ces serveurs dans le fichier /usr/share/dns/root.hints (par défaut sous Debian en tout cas). C’est le début de la récursivité.

On ne peut interroger directement les serveur racines pour résoudre un nom de domaine. Ceux-ci vont simplement nous rediriger vers le serveur qui gère le TLD demandé.

Exemple : on demande au serveur racine A (IP : 198.41.0.4) de résoudre l’adresse “memo.raphaelguetta.fr” :
dig @198.41.0.4 memo.raphaelguetta.fr
Il nous répond simplement :
fr. 172800 IN NS f.ext.nic.fr.
soit “voici le serveur qui gère le .fr, va lui demander”.

On lui demande donc de résoudre, à nouveau :
dig @f.ext.nic.fr. memo.raphaelguetta.fr
et il nous répond :
raphaelguetta.fr. 3600 IN NS ns103.ovh.net.
soit “voici le serveur qui gère la zone DNS de raphaelguetta.fr, va lui demander”

On redemande donc :
dig @ns103.ovh.net. memo.raphaelguetta.fr
et on obtient enfin la réponse des serveurs OVH, qui sont effectivement ceux que j’utilise pour configurer mes (sous-)domaines :
memo.raphaelguetta.fr. 86400 IN A 82.64.166.200

Configuration

Config dans /etc/bind/.

Fichiers pré-remplis :
named.conf avec seulement includes
named.conf.options pour les options (attention, 1 seul groupe options { }; est autorisé, on ne peut pas le splitter dans différents fichiers)
named.conf.default-zones définit le fichier contenant les IP des serveurs racines (/usr/share/dns/root.hints) ; ainsi que les zones concernant localhost (DNS et rDNS)

Fichier pour une personnalisation du serveur :
named.conf.local
Par défaut, il est vide ; il set à définir des zones DNS custom.
Supposons que je souhaite définir, en local, un zone DNS sur le TLD .bidouille (qui n’existe pas officiellement) Je rentre dans ce fichier

zone "bidouille" {
        type master;
        file "/etc/bind/zones/db.bidouille";
};

Ainsi je définis que mon serveur DNS est “maître” (il fait autorité pour le TLD .bidouille, ce qui est nécessaire, car aucun autre serveur ne connaîtra ce TLD) Je définis que sa zone sera définie dans le fichier “/etc/bind/zones/db.bidouille”

Docker

version: '3'

services:

  bind9:
    image: internetsystemsconsortium/bind9:9.18
    restart: always
    container_name: bind9
    stdin_open: true
    tty: true
    ports:
      - 53:53/tcp
      - 53:53/udp
# For RNDC :
      - "127.0.0.1:953:953/tcp"
    volumes:
    volumes:
      - ./config/zones:/etc/bind/zones
      - ./config/named.conf.local:/etc/bind/named.conf.local
      - ./config/named.conf.options:/etc/bind/named.conf.options
      - ./cache/:/var/cache/bind/
      - ./lib/:/var/lib/bind/
      - ./log/:/var/log/

Connectivité des autres réseaux

Par défaut, bind n’accepte de répondre qu’aux requêtes qui proviennent du même hôte ou du même réseau.
Comme il esy dockerisé, il faut l’autoriser à résoudre depuis + de sources. Pour ceci, dans le bloc d’options, ajouter

Connectivité des autres conteneurs Docker

Si le serveur hôte s’utilise lui-même comme resolver dans /etc/resolv/conf, il faut qu’il s’appelle sur 127.0.0.1 ; s’il utilise son IP externe (par exemple 192.168.1.10 ), les conteneurs ne pourront probablement pas faire de résolution DNS.

Ceci semble venir du fait que les conteneurs récupèrent le resolveur interne de Docker (127.0.0.11), qui va lui-même récupérer les informations du resolv.conf de l’hôte. Et si il est défini en IP externe, cela ne fonctionne pas.

RNDC

Remote Name Daemon Control
port 953

Cache

01 Jan 0001, 00:00

Diskpart

select disk 8 uniqueid disk # pour lister

uniqueid disk AEF364B5 # pour changer

01 Jan 0001, 00:00

Fait avec la version v 2.7.0 , avec un vault avec 4 ports ethernet.

Pour reset, si on accès à l’interface web : Diagnostic -> Factory defaults

Config initiale

Wizard

Pour se connecter :
192.168.1.1
admin / pfsense

On suit le wizard.
Pas l’obligation de définir des DNS

Si l’interface WAN est connectée à un réseau local (et non directement à internet), ET qu’on souhaite accéder

Config réseau basique

La config réseau est prévue pour être faite depuis le port LAN ; c’est la seule qui a des règles de pare-feu qui laissent passer le trafic arrivant sur ce port.
Elle a aussi une règle “Anti-lockout” qui autorise la connexion http(s) et SSH vers le pare-feu.

Par défaut, sans configuration, OPT1 et OPT2 n’ont aucune règle et le trafic est donc bloqué.

Interfaces -> Assignement
pour créer une interface (configuration réseau) associé à un port. Le port peut être un port physique, ou un bridge (défini dans l’onglet Bridges) Il crée par défaut WAN -> LAN -> OPT1 -> OPT2 -> OPT3 mais on peut changer les noms

Interface -> Iface_name
pour configurer le réseau de l’interface :

  • DHCP, IP statique, PPP, L2TP etc…
  • adresse IP et netmask
    Penser à cocher la case au tout début “Enable interface”

DNS

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver.html

PfSense viens avec unbound, un resolver DNS qui peut aussi agir comme forwarder DNS.
il vient aussi avec dnsmasq, un forwarder DNS.

À l’installation, unbound est actif par défaut en tant que resolver. Cela signifie qu’il va contacter directement les serveurs DNS racines pour obtenir les correspondances domaine -> IP.

En mode forward, il transmet la requête au(x) serveur(s) défini(s) dans System > General Setup. Ces serveurs peuvent être remplacés par ceux fournis par le DHCP, si l’option correspondante est activée (cas par défaut).
La doc PfSense indique que ce mode peut être + adapté pour les connexions multi-WAN.

Config

Services -> DNS Resolver ou Services -> DNS Forwarder

Le resolver est activé par défaut sur toutes les interfaces ; mais si on ajoute une interface, il faut “Save” puis “Apply changes” (même sans aucune modification) pour que la résolution DNS se fasse sur la nouvelle interface.

DHCP

Il me semble qu’il n’y a pas besoin de créer des règles spécifiques pour autoriser le DHCP. Soit PfSense le fait de manière transparente lorsque le DHCP est activé sur une interface, soit le DHCP utilise l’adresse de broadcast. Mais ça n’est pas nécessaire de l’autoriser explicitement.

IPv4

Services -> DHCP Server
Le serveur DHCP peut être activé, indépendemment, pour chaque interface ayant une adresse IP.

IPv6

Je souhaite le désactiver.

Services -> DHCPv6 Server & RA

pour désactiver le serveur DHCP en IPv6 sur l’interface LAN désactiver aussi Router Advertisement

Bridges

https://docs.netgate.com/pfsense/en/latest/bridges/index.html
https://provya.net/?d=2019/10/01/09/26/04-pfsense-faire-un-pont-reseau-bridging-entre-deux-interfaces

Permet de créer un pont (switch) entre 2/plusieurs interfaces. Il faut s’attendre à des performances + faibles que celles d’un switch.
Peut poser problème pour certaines fonctionnalités, comme les portails captifs.

Pour les gérer, Interfaces -> Assignments puis onglet Bridges

Ordre de création :

  • Assigner chaque port (igbX) à 1 interface (avec des noms par défaut comme WAN, LAN, OPT1, OPT2) ; penser à cocher la case “Enable interface” ; choisir “None” en configuration IP
  • créer le bridge en y assignant 1 ou plusieurs des interfaces précédemment créées -> BRIDGE0
  • assigner BRIDGE0 à une nouvelle interface (par défaut OPT3, mais je l’appelle ici BRLAN)
  • configurer BRLAN en “Enabled” et avec une configuration IP

Il faut suivre l’ordre inverse si on souhaite supprimer le bridge.

Vérifier l’adresse MAC du bridge, notamment après redémarrage ? Il est possible qu’elle soit aléatoire. Ceci peut empêcher Windows de se rendre compte qu’il s’agit du même réseau, et donc demander à définir si c’est un réseau privé, public etc.
Pour éviter ceci, on peut définir manuellement cette adresse MAC.

Il faut penser à cocher “Enable interface” pour le bridge, mais aussi pour chaque port/interface inclus dans le bridge.

Par défaut, les appareils connectés à deux ports différents d’un bridge ne peuvent pas communiquer ensemble. Pour autoriser cette connexion, il faut aller dans :
System -> Advanced puis onglet “System Tunables” et trouver (créer si elle n’existe pas) l’option
net.link.bridge.pfil_member
et la passer à 0.
Après “Apply changes”, les appareils devraient pouvoir communiquer ensemble.
Une autre méthode qui fonctionne pour autoriser cette connexion, mais qui n’est probablement pas conseillé, est de rajouter une règle firewall, sur au moins 1 des interfaces sous-jacente, autorisant la connexion depuis “BRLAN net”.

Pour autoriser la communication de ces 2 clients avec le routeur et les autres réseaux, il faut aussi ajouter au moins une règle de pare-feu dans l’onglet “BRLAN”, avec “BRLAN net” en IP source.

Interfaces group ??

LAN vs WAN

Si une “IPv4 Upstream gateway” est définie dans le menu Interfaces -> nom_de_l’interface , alors le réseau est considéré come WAN.
Sinon, il est considéré comme LAN.

https://docs.netgate.com/pfsense/en/latest/interfaces/wanvslan.html

La sélection de cette passerelle ne définit pas la capacité réelle au trafic de sortir par une passerelle ; il y a une passerelle par défaut définie dans System -> Routing, et on peut aussi y définir une passerelle pour une interface spécifique, sans qu’elle ne soit forcément considérée comme WAN.

Firewall

https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html

Le filtrage s’applique uniquement aux paquets entrants.
La présence d’une table d’état permet aux appareils de répondre à une requête entrante, même s’ils n’auraient pas eu l’autorisation d’initier cette communication spontanément.

Règles

L’onglet correspondant à chacune des interfaces contient des règles qui s’appliquent aux paquets qui entrent par cette interface.
La vérification s’arrête à la première règle qui correspond.
Une absence de règle entraîne un blocage.

Pour une interface LAN, si on veut autoriser la connexion aux autres réseaux et internet, sans aucun filtrage, il faut au minimum une règle :

  • Pass
  • IPv4 (ou IPv6)
  • Protocol : any
  • Source : “LAN net” (ou “any”)
  • Destination : any

Faire ça sur les différentes interfaces permet une communication entre les réseaux.
Si le trafic semble bloqué malgré une règle “Pass”, penser à vérifier le pare-feu sur le poste client.

Pour les bridges, il est nécessaire de configurer les règles sur l’interface du bridge, mais les ports/interfaces sous-jacents n’ont pas besoin de règles de pare-feu (sauf pour communication inter-clients sur des ports différents, voir paragraphe “Bridges)”.

États (states) et désactivation d’une règle

Lorsqu’une connexion est établie entre 2 hôtes, le firewall enregistre l’état de cette connexion dans une table d’état. On peut la consulter dans Diagnostics -> States (ou States Summary).

Lorsqu’un blocage est demandé (par ajout de règle Block ou suppression de règle Pass), cette connexion (état) pré-existante est maintenue, même après appui sur “Apply changes” !

Pour réellement actualiser le filtrage, il est nécessaire de supprimer les états préexistants. Pour ceci, sur la règle de firewall, la croix tout à droite permet de supprimer les états liés à cette règle.
On peut également reset l’ensemble des états dans Diagnostics -> States -> Reset States ; si on fait ça, il faut faire Ctrl - F5 pour retrouver l’interface webadmin.

Penser à bien faire cette manip lorsqu’on teste le bon fonctionnement des nouvelles règles.

L’ajout d’une règle autorisant une connexion ou la suppression d’une règle demandant un blocage n’ont pas cette mécanique ; elles sont actives dès le clic sur “Apply changes” car il n’y a pas d’état “connexion bloquée”.

Réseau de destination

https://docs.netgate.com/pfsense/en/latest/bridges/index.html

Si un réseau est sélectionné en “destination” lors de la création d’une règle, cette règle s’appliquera aux paquets dont ce réseau est la destination finale ; si le paquet transite par ce réseau sans chercher à le joindre directement, il ne sea pas bloqué. On peut donc bloquer l’accès au réseau upstream de notre passerelle, sans que cela ne gêne l’accès à internet.

Désactivation complète du pare-feu

En cas de besoin, on peut désactiver complètement le pare-feu via SSH.
Pour ceci, après s’être loggé, on choisit l’option 8 (Shell) et on entre :
pfctl -d
On peut ensuite le réactiver avec
pfctl -e

Isoler un réseau local en laissant l’accès à internet

Une approche pour ça est de bloquer toutes les connexions aux réseaux privés (RFC1918) puis d’autoriser l’accès à tous les réseaux.
Les clients pourront donc communiquer avec les réseaux publics (internet), mais avec aucun autre réseau privé.
Il faut aussi penser à autoriser la connexion au serveur DNS, si nécessaire (typiquement le routeur PfSense lui-même), afin que les clients puissent résoudre les domaines.

Pour ceci, dans Firewall -> Alias, je rajoute un alias de type Network, nommé “RFC1918” et contenant 3 réseaux : 10.0.0.0/8 , 172.16.0.0/12 et 192.168.0.0/16.

Ensuite, dans les règles de filtrage du (V)LAN :

  • Pass ; IPv4 UDP ; source “LAN net” port *; dest. “LAN address” port 53
  • Block ; IPv4 proto * ; source * port * ; dest “RFC1918” port *
  • Pass ; IPv4 proto * ; source “LAN net” port * ; dest * port *

Ainsi les clients peuvent contacter le server DNS sur l’adresse locale du routeur, port 53, mais toutes les autres requêtes vers une IP type réseau local sont refusées. Enfin l’accès au reste des réseaux (donc “internet”) est autorisé.
On peut bien sûr rajouter d’autres règles “Pass” avant la règle “Block” si nécessaire (client NTP etc).
On peut également choisir d’autoriser, en dernière règle, uniquement certains ports (HTTP(S), IMAP, SMTP, SSH etc).

À noter que ces règles ne jouent pas sur la possibilité des clients de ce réseau à communiquer entre eux, car ceci se passe avant le passage dans le routeur ; et ce même si 2 clients sont branchés sur 2 ports différents du routeur configurés ensemble en bridge (voir paragraphe ur les bridges).

SSH

System -> Advanced

Routes

Dans Status -> Routes, on voit la table de routage
Flags (ceux de netcat) :
U = up, route utilisable
H : host ; la route concerne un hôte unique (si absence du flag, ça concerne un réseau)
S : static : ajoutée manuellement
G : gateway, la route requiert une passerelle intermédiaire pour être atteinte

AES-NI

Pour l’activer, aller dans system -> Advanced -> Misc. et activer l’option “Cryptographic Hardware”

https://docs.netgate.com/pfsense/en/latest/hardware/cryptographic-accelerators.html

Privilégier les ciphers aes-gcm ?
https://www.reddit.com/r/PFSENSE/comments/k9h4tg/no_hardware_crypto_acceleration_is_my_only_option/

Divers

System -> General Setup
pour y gérer

  • serveur DNS initial
  • theme sombre

VLAN

interfaces -> Assignments puis onglet “VLANs”

Port parent ?

L’interface apparaît alors dnas le menu interfaces. on peut la configurer (adresse IP etc)

01 Jan 0001, 00:00

Chercher dans /sys/class/hwmon le dossier qui corespond au cpu ; pour ça, regarder le nom dans :
cat /sys/class/hwmon/hwmon*/name et chercher coretemp

Une fois l’ID identifié (par exemple 3), trouver chaque coeur dans cat /sys/class/hwmon/hwmon3/temp*_label par exemple 2, 3, 4 et 5

dans conky : ${hwmon 3 temp 2} ${hwmon 3 temp 3} ${hwmon 3 temp 4} ${hwmon 3 temp 5}

01 Jan 0001, 00:00

Pour transférer un jeu du store Epic d’une installation Windows à une autre, il faut :

  • copier le dossier du jeu (généralement C:\Program Files\Epic Games\GameName )
    • repérer l’identifiant du jeu stocké dans le dossier caché .egstore (spécifique à chaque installation)
  • copier le fichier Manifest avec l’identifiant repéré précedémment (fichier .ITEM) dans C:\ProgramData\Epic\EpicGamesLauncher\Data\Manifests\
  • il faut également déclarer le jeu installé en copiant/collant la section adaptée du fichier C:\ProgramData\Epic\UnrealEngineLauncher\LauncherInstalled.dat

01 Jan 0001, 00:00

Cloner les owner/groups/permissions d’une arborescence

cd /path/to/source/ time getfacl -R ./ > /root/perms.acl cd /path/to/destination/ time setfacl –restore=/root/perms.acl –test

Si tout est ok setfacl –restore=/root/perms.acl

01 Jan 0001, 00:00

Fichier de config :

Lancement manuel :
ddclient –verbose

voir le délai du daemon :
ps aux | grep ddclient

Cache

ddclient utilise un fichier de cache, où il stocke en local la dernière IP configurée pour le DNS dynamique :
/var/cache/ddclient/ddclient.cache

Si l’IP associée a été changée autrement (par exemple via l’interface web du fournisseur DNS), ddcelint ne s’en rendra pas compte.
Il faut alors supprimer le cache pour le force à réintéerroger le serveur :
rm /var/cache/ddclient/ddclient.cache

01 Jan 0001, 00:00

Driver Verifier peut rendre le pc complètement inutilisable, au point de ne plus pouvoir accéder à cmd pour le désactiver.

Pour le désactiver en hors-ligne, trouver les2 eclés suivantes et les supprimer/renommer : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

(en offline, CurrentControlSet sera probablement ControlSet001)

https://www.reddit.com/r/techsupport/comments/o6a6ph/how_do_i_disable_driver_verifier_bsod_loop/ https://superuser.com/questions/1006441/how-to-disable-driver-verifier-on-windows-10/1006537#1006537

01 Jan 0001, 00:00

dmidecode

sudo dmidecode

Types : -t memory speed :