pcdwarf

Devrais-je bloquer ICMP ?

 Sans catégorie  Commentaires fermés sur Devrais-je bloquer ICMP ?
Sep 112019
 

Non !! Non et Non ! Surtout pas.

Le problème

De nombreux administrateurs réseau estiment que le protocole ICMP représente un risque pour la sécurité et qu’il doit donc toujours être bloquée au niveau du pare-feu. Il est vrai que ICMP est associée à certains problèmes de sécurité et qu’un grand nombre d’entre eux devraient être bloqués. Mais ce n’est pas une raison pour bloquer tout le trafic ICMP !

En effet, ICMP a de nombreuses caractéristiques importantes ; certaines sont utiles pour le dépannage, tandis que d’autres sont essentielles pour le bon fonctionnement d’un réseau. Sans être exhaustif, voici les détails de certains des trafics ICMP importants que vous devriez connaître, et envisager d’autoriser à travers votre réseau.

Demande d’écho et réponse à l’écho

IPv4 – Demande d’écho (Type8, Code0) et réponse d’écho (Type0, Code0)
IPv6 – Demande d’écho (Type128, Code0) et réponse d’écho (Type129, Code0)

Nous connaissons tous ceux-là – ping est l’un des premiers outils de dépannage que nous apprenons tous. Oui, si vous l’activez, cela signifie que votre hôte est maintenant détectable. Et alors ? Ne l’était-il pas déjà ? votre serveur web n’écoutait-il pas déjà sur le port 80 ? Bien sûr, bloquez les pings si vous le voulez vraiment à votre frontière vers votre DMZ (et encore…) mais bloquer le ping à l’intérieur de votre réseau ne vous apportera pas grand-chose, sauf un dépannage plus difficile (« Pouvez-vous pinger votre passerelle par défaut ? », « Non, mais je ne peux jamais, donc cela ne me dit rien ! »). Par ailleurs, notez que pour une immence majorité d’administrateurs et de prestataires, une IP qui ne réponds pas au ping est réputée libre et affectable à quelqu’un d’autre…. Ne vous plaignez pas si des conflits d’adresses IP apparaissent.

N’oubliez pas que vous pouvez également autoriser cela avec une direction donnée à l’esprit ; vous pouvez décider de laisser les demandes d’écho sortir de votre réseau vers Internet, et les réponses d’écho d’Internet vers votre réseau, mais pas vice versa.

Fragmentation requise (IPv4) / paquet trop grand (IPv6)

IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)

Ceux là sont importants. TRÈS importants. VRAIMENT TRES importants. Ils sont un composant essentiel de Path MTU Discovery (PMTUD), qui est une partie essentielle de TCP qui permet à deux hôtes d’ajuster leur taille maximale de segment TCP (MSS) à une valeur qui s’adaptera dans le plus petit MTU le long du chemin des liens entre les deux hôtes. Si deux hôtes ont un MTU plus petit que leur propre lien local sur le chemin entre eux, et n’ont aucun moyen de le découvrir, le trafic est silencieusement occulté ; en d’autres termes, « ca va être la merde ».

Les paquets IPv4 avec le bit DF (c’est la plupart d’entre eux !), ou les paquets IPv6 qui sont trop grands pour qu’un routeur puisse les transmettre à travers une interface (rappelez-vous qu’il n’y a pas de fragmentation par les routeurs dans IPv6), auront pour résultat que le routeur drop le paquet et génère une erreur ICMP « Fragmentation Required / Packet Too Big » vers la source et qui contient aussi le MTU du lien trop petit. Si cette erreur ne parvient pas à l’expéditeur, l’expéditeur interprétera simplement l’absence de ACK du récepteur comme une congestion/perte et il fera une retransmission, qui sera bien sûr également perdue. Ce type de comportement est difficile à dépanner car bien sûr, les poignées de main TCP fonctionnent bien, car il s’agit de petits paquets, mais la session semble se bloquer dès qu’une transmission de données en masse a lieu.

RFC 4821 a été développé pour aider les hôtes à contourner ce problème en utilisant « Packetization Layer Path MTU Discovery » (PLPMTUD), qui découvre le chemin MTU en augmentant progressivement le MSS pour essayer de trouver une valeur appropriée pour ce chemin. Cela supprime la dépendance à ICMP, et est disponible dans la plupart des piles réseau d’OS, mais n’est pas aussi efficace que d’apprendre directement ce que le MTU maximum devrait être. Alors s’il vous plaît, laissez passer ces messages ICMP. C’est vraiment important.

Temps dépassé

IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)

Traceroute est un outil très utile pour dépanner les connexions réseau entre deux hôtes, détaillant chaque saut sur le chemin. Il le fait en envoyant un paquet avec un TTL de 1 pour que le premier saut renvoie un message Time Exceeded (incluant son propre IP source), puis en envoyant un paquet avec un TTL de 2, et ainsi de suite, pour découvrir chaque saut sur le chemin.

Rappelez-vous quand vous l’avez déjà lancé et que vous obtenez un ou deux sauts qui ne peuvent pas être découverts au milieu de votre trace ? Ou pire encore, vous essayez de tracer l’itinéraire jusqu’à un hôte et tous les sauts ne peuvent être découverts. C’est ennuyeux, n’est-ce pas ? C’est parce que la personne qui exécute ces routeurs (ou votre pare-feu local) a décidé de bloquer les messages ICMP Time Exceeded. Ne sois pas comme ça, d’accord ?

NPD et SLAAC (IPv6)

Sollicitation de routeur (RS) (Type133, Code0)
Publicité sur le routeur (RA) (Type134, Code0)
Sollicitation de voisins (N.-É.) (Type135, Code0)
Publicité de voisinage (NA) (Type136, Code0)
Rediriger (Type137, Code0)

Alors qu’IPv4 utilisait le protocole de résolution d’adresse (ARP) pour les mappages des couches 2 à 3, IPv6 adopte une approche différente, sous la forme du protocole de découverte des voisins (NDP). NDP offre de nombreuses fonctions, y compris la découverte de routeurs, la découverte de préfixes, la résolution d’adresses, et bien d’autres encore. En plus du NDP, l’AutoConfiguration d’adresse sans état (SLAAC) permet à un hôte d’être configuré dynamiquement sur le réseau, selon un concept similaire à DHCP (bien que DHCPv6 existe pour un contrôle plus fin)

Pour le reste, il n’est pas indispensable de les laisser passer et même souhaitable d’en bloquer une grande partie. Mais ces cinq types ICMP ci dessus devraient TOUJOURS être autorisés dans votre réseau pour qu’il puisse fonctionner correctement.

Un mot sur la limitation de trafic.

Bien que les messages ICMP comme ceux couverts sur cette page puissent être très utiles, rappelez-vous que la génération de tous ces messages prend du temps CPU sur vos routeurs, et génère du trafic. Vous attendez-vous vraiment à recevoir 1000 pings par seconde à travers votre pare-feu dans une situation normale ? Serait-ce considéré comme un trafic légitime si vous le voyiez ? Non, probablement pas. Limitez tous ces types de trafic ICMP comme bon vous semble pour votre réseau ; c’est une bonne ligne de défense qui ne doit pas être ignorée.

Lire, Rechercher, Comprendre

Étant donné que le fait que les discussions sur « bloquer ou de ne pas bloquer ICMP » semble toujours entraîner de la confusion, de la colère et des désaccords fanatiques, n’hésitez pas à lire vous-même sur le sujet. Prenez le temps de le comprendre le plus complètement possible ; il y a beaucoup de liens tout au long de cette page seulement. Vous pourrez ensuite vous faire votre propre opinion et faire un choix éclairé sur ce qui convient le mieux à votre réseau.

Article traduit et légèrement modifié d’un article en anglais provenant de http://shouldiblockicmp.com/

Créer un lanceur systemD (equiv rc.local) sous debian stretch

 Sans catégorie  Commentaires fermés sur Créer un lanceur systemD (equiv rc.local) sous debian stretch
Avr 082019
 

1 – Créer un fichier Service

/etc/systemd/system/monpetitnomde.service

2 – Dans ce fichier, on met le code qui suit

[Unit] 
Description=Texte de description du service
ConditionPathExists=/full/path/of/script.sh

[Service]
Type=forking
ExecStart=/full/path/of/script.sh start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

3 – Créer ensuite le script avec chmod+x

4 – Enfin, ajouter au systeme avec

systemctl enable monpetitnomde

Remarques

cette config executera ça une seule fois au boot au moment ou on passse en mode multi-user. C’est l’équivalent du script rc.local de l’ancien système

Important : Si on veut lancer des démons, il vaut mieux faire plusisuers services car 1) c’est plus modulaire et surtout le process de boot va forker et tout lancer en parallèle ce qui accélère énormément sur les machine multi-cpu

option dhcp119 – Search Domains

 Sans catégorie  Commentaires fermés sur option dhcp119 – Search Domains
Fév 022019
 

Je voulais passer plusieurs domaines de recherche dans l’option dhcp 119. Après plusieurs essais, mon client dhcp me dit toujours « suspect value in domain_search option – discarded »

Je cherche un peu sur le net, et il s’avère qu’il y a une syntaxe
rigolotte décrite dans la RFC3397

ci dessous un encodeur fait à l’arrache pour générer la chaine en hexadécimal correspondant a une liste

#include <stdio.h>

int main(void) {

    const char * StrToEncode = "lan chez.moi.net ailleurs.com";

    const char * ptrA = StrToEncode;
    const char * ptrB = StrToEncode;

    printf("\nSTART\n");

    printf("Chaine initiale : '%s'\n", StrToEncode);
    printf("Chaine resultat : '0x");

    while (1) {
        int cpt=0;
        const char * ptrB=ptrA;

        while (1) {
            if ( *ptrA =='\0' ) break;
            if ( *ptrA =='.' ) break;
            if ( *ptrA ==' ' ) break;
            cpt++;
            ptrA++;
        }

        printf("%02x", cpt);

        while ( ptrB != ptrA ) {
            printf("%02x", *ptrB);
            ptrB++;
        }

        if ( *ptrA ==' ' ) printf("00");        //separateur
        if ( *ptrA =='\0' ) { printf("00'\n");  break; }   //Fin de chaine

        ptrA++;
    }

    printf("END\n");
    return 0;
}

ATtiny13a

 Sans catégorie  Commentaires fermés sur ATtiny13a
Nov 192017
 

Le microcontrôleur ATtiny13a est un AVR minimaliste à très faible cout (trouvable à moins de 0.30€ pièce). Ce boitier 8 broches ne nécessite aucun composant externe et est donc très pratique pour réaliser des fonctions simples nécessitant usuellement plusieurs composants discrets (monostable, PWM, ce genre de choses)

Citation : Diplomatie

 Sans catégorie  Commentaires fermés sur Citation : Diplomatie
Fév 032017
 

Quand un diplomate dit ‘oui’, cela signifie ‘peut-être’ ; quand il dit ‘peut-être’, cela veut dire ‘non’ ; et quand il dit ‘non’, ce n’est pas un diplomate.

H. L. Mencken

Client OpenVpn sur routeur Mikrotik

 Sans catégorie  Commentaires fermés sur Client OpenVpn sur routeur Mikrotik
Jan 162017
 

Petites mises au point

Mikrotik ne permet pas toutes ce que openVPN permet usuellement.
Pour faire simple :

  • Mode TCP obligatoire (même pas réglable)
  • Utiliser exclusivment le mode IP (mode ethernet au comportement plus qu’étrange si on tente du bridging donc, si c’est pour finir par faire du L3 dessus, c’est sans intéret)
  • Il y a une seule instance du serveur (On ne peut pas en mettre polusieurs sur plusieurs ports avec des conf différentes
  • Utilisation du mode d’authentification « user/password » (presque) obligatoire

Donc.

Etape1 : Générer les certificats.
C’est plus simple en SSH

/certificate
add ca-template key-usage=key-cert-sign,crl-sign days-valid=3650 key-size=4096
country=FR organization=orgName common-name=CA+orgName

ça, ça crée juste un template (cert request avec tout les params)
A noter que ca-template est en fait un nom tout à fait libre. C’est juste un identifiant. Mais c’est plus parlant de mettre un nom qui correspond à ce qu’on va faire et d’y integrer le mot clé « template » pour bien piger que c’est pas un certificat fini.

(auto) Signature
sign ca-template name=CA+orgName
A noter que le champs name est en fait libre. C’est juste un identifiant. Mais c’est plus parlant de le rendre égal au common-name.
Comme il n’y a aucun ca spécifié, il crée un autosigné.

set trusted=yes
Tada! Ce certif est desormais un CA.

export-certificate CA+orgName
Le certificat CA est exporté sous forme de fichier (section /files)
Il y en aura besoin pour le client openVPN

Création d’un Certif serveur pour OpenVpn

add name=server-template key-usage=digital-signature,key-encipherment,data-encipherment,crl-sign,tls-server,tls-client days-valid=3650 key-size=2048
country=FR organization=orgName common-name=OvpnServer

Idem, le champs name est en fait libre. C’est juste un identifiant.

sign server-template name=OvpnServer ca=CA+orgName

Re-Idem, le champs name est en fait libre. Mais c’est plus parlant de le rendre égal au common-name.
la signature se fait avec la clé du CA spécifié. (Il faut que cette clé ait l’attribut key-cert-sign, ce qu’on a fait plus haut)

Configuration du serveur OpenVpn
/ppp profile
add change-tcp-mss=yes name=default_ovpn use-compression=no use-encryption=yes use-mpls=no
/interface ovpn-server server
set certificate=OvpnServer cipher=aes256 default-profile=default_ovpn enabled=yes keepalive-timeout=30 max-mtu=1400

Configuration du client OpenVpn

Installer le client openvpn sur la machine.

Aller dans le dossier de configuration (Il n’y a pas de GUI config)
Y déposer le fichier CA.crt créé plus haut.

créer un fichier texte monvpn.ovpn

client
dev tun
proto tcp
remote 89.83.98.218 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca nomdufichier.crt ///// a modifier
auth-user-pass login.txt
tun-mtu 1400
mssfix
route-nopull
route 10.25.0.0 255.255.0.0 ///// a modifier : Réseau auquel le client accède
cipher AES-256-CBC
verb 4

créer un fichier texte login.txt

myusername
mekmitasdigoat

Cliquez sur connecter,
C’est fini