Brouillons d'un g33k

Categories

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

Présentation

DKIM (DomainKey Identified Mail) permet de signer les messages expédiés par un serveur SMTP. Pour ceci, une paire de clé doit être générée, la clé publique est ensuite publiée via DNS, la clé privée est fournie au serveur SMTP.
À la réception d’un message signé via DKIM, un serveur mail va se référer à l’entête “DKIM-Signature” pour identifier le domaine et le selecteur, puis va chercher la clé publique sur les enregistrements DNS afin de vérifier la signature.

Configuration du DNS

https://help.returnpath.com/hc/fr/articles/222481088-Aper%C3%A7u-du-DNS-record-pour-la-signature-DKIM

C’est une entrée de type “TXT” (mentionnée de type DKIM chez OVH), appliquée à “selecteur._domainkey.domain.com” (selecteur et domain doivent être adaptés).
Le champ fonctionne sur un principe clé=valeur ; on retrouve les champs suivants :

  • v= : version. DKIM1
  • k= : type de clé. “rsa”
  • p= : clé publique
  • t= : ? (t=s) ; il semble que ce champ puisse poser problème dans le cas d’utilisation de sous-domaines

Analyse de la signature

https://help.returnpath.com/hc/fr/articles/222438487-Informations-d-ent%C3%AAte-de-la-signature-DKIM

Dans les entêtes d’un mail. Entête “DKIM-Signature”

Balises obligatoires :

  • v= : version. Actulemment, c’est 1
  • a= : algo pour générer la signature. Ca sera quasi toujours rsa-sha256
  • d= : pour identifier le domaine responsable de la signature
  • s= : sélecteur ; avec le domaine, permet de trouver l’emplacement de la clé publique dans le DNS
  • h= : liste d’entetes qui seront utilisées pour créer la signature (et sont donc authentifiées) ; par exemple “h=To:From:Subject;”
  • b= : hachage de la valeur “h” ; c’est généralement ceci que l’on appelle “signature DKIM”
  • bh= : hachage du corps du message

Balises optionnelles :

  • t= : horodatage du message
  • x= : horodatage de l’expiration de la signature. Doit être postérieure à “t”

ARC (Authenticatd Received Chain)

https://www.dmarcanalyzer.com/fr/arc-est-ici/

Permet de résoudre des situations où SPF ou DKIM ne fonctionnent plus (typiquement lorsqu’il y’a un transfert de mail, soit via forward automatique, soit lors d’un transfert via une mailing-list).
En gros, lorsqu’un serveur de transfert reçoit un mail avec un résultat DMARC valide, il “encapsule” ce résultat dans une en-tête ARC. Il peut ensuite retransmettre l’ensemble (message + entête ARC) au destinataire suivant (qui peut être un autre intermédiaire, ou bien le destinataire final).

Si DMARC échoue, mais que l’ensemble de la chaîne ARC est valide, un serveur peut choisir de valider le mesage quand même.

En-têtes ARC :
ARC-Authentication-Results (AAR) : regroupe les infos d’authentification du mail d’origine (SPF, DKIM, DMARC)
ARC-Message-Signature (AMS) : une signature (comme pour DKIM) pour certifier le contenu de l’ensemble du message (excepté l’ARC-Seal)
ARC-Seal (AS) : une signature (comme pour DKIM) de l’ensemble de la chaîne des ARC-Seal

Chaque certification ARC est assortie d’un numéro d’instance (i) commençant à 1. Il peut y avoir plusieurs certifications ARC successives.

Gestion via Office 365

https://security.microsoft.com/dkimv2

Nécessite de paramétrer les entrées DNS (probablement du CNAME)

01 Jan 0001, 00:00

dmidecode

sudo dmidecode

Types : -t memory speed :

01 Jan 0001, 00:00

docker info

curl 127.0.0.1:9323/metrics

host.docker.internal

01 Jan 0001, 00:00

Impossible trouver archives

sudo dpkg –remove –force-remove-reinstreq vyprvpn

https://debian-facile.org/viewtopic.php?id=16439

Lister tous les paquets installés issus d’une suite précise

suite=sid
dpkg -l | awk '/^.i/ {print $2}' | xargs apt-cache policy | awk '/^[a-z0-9.\-]+:/ {pkg=$1}; /\*\*\*/ {OFS="\t"; ver=$2; getline; print pkg,ver,$2,$3}'|grep -v /var/lib/dpkg/status| sed -e 's/://'|awk '{printf "%-40s %-36s %-36s %-16s \n",$1,$2,$3, $4}' | grep -i ${suite}/

# Pour avoir uniquement les noms, on ajoute
 | awk '{print $1}'