Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 16/09/2019 à 12:57, G2PC a écrit : Bonjour, Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me semble de ce fait inutile de l'autoriser dans ma configuration Iptables ? Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le multicast, tu n'as pas besoin de l'autoriser. Par contre, je trouve deux types de règles via mes recherches, et, je ne suis pas très sur de la bonne façon de l'interdire. Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et n'autorises que ce dont tu as besoin, n'est-ce pas ? # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? IGMP n'est pas le multicast, ce n'est que le protocole de gestion du multicast. Tous les flux multicast ne font pas forcément l'objet d'un abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi en multicast. Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux fois avant de bloquer du trafic multicast. Certains flux multicast sont indispensables au bon fonctionnement d'IPv6.
Re: Dnsmasq: interdire /etc/hosts aux requètes provenant d'un VLAN particulier
Le 16/09/2019 à 08:26, Olivier a écrit : Ma question n'était sans doute pas très bien formulée. Elle ne portait pas sur la façon de router le DNS, mais d'avoir plusieurs résolutions locales différenciées. Si, c'était très clair (excepté le titre qui n'est pas terrible). Ce que tu veux faire s'appelle du "split DNS". Dans BIND 9, cela correspondrait à des "vues" (views). Malheureusement je ne connais pas bien dnsmasq et ignore s'il possède une fonctionnalité équivalente.
Faut t'il bloquer le Multicast - IGMP avec Iptables
Bonjour, Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me semble de ce fait inutile de l'autoriser dans ma configuration Iptables ? Par contre, je trouve deux types de règles via mes recherches, et, je ne suis pas très sur de la bonne façon de l'interdire. Je proposerais éventuellement cette approche, mais, pouvez vous me confirmer que bloquer ainsi le multicast est fonctionnel et cohérent ? # DROP le Multicast : # Ce système est plus efficace que l'unicast pour diffuser des contenus simultanément vers une large audience. (Audio, Vidéo.) -A INPUT -m pkttype --pkt-type multicast -j DROP -A FORWARD -m pkttype --pkt-type multicast -j DROP -A OUTPUT -m pkttype --pkt-type multicast -j DROP # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? # Si nécessaire, tenter de logger tout paquet igmp sans spécifier de source pour voir ce que ça donne dans "/var/log/syslog". # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix "IGMP: " # L'IGMP est un protocole standard utilisé par la suite de protocoles TCP/IP pour la multidiffusion dynamique, le multicast. -A INPUT -p igmp -j DROP -A FORWARD -p igmp -j DROP -A OUTPUT -p igmp -j DROP Merci,
Re: HOSTALIASES ne fonctionne pas sur debian?
Salut,
>$ export HOSTALIASES=~/.hosts
>$ echo 127.0.0.1 wow> $HOSTALIASES
>$ ping wow
>ping: wow: Aucune adresse associée avec le nom de l'hôte
>
Il me semble que ping n'utilise pas gethostbyname mais getaddrinfo:
bash$ sudo ltrace ping google.com
__cxa_atexit(0x5574d608c060, 0, 0x5574d6092328, 0) = 0
cap_get_proc(0x7f1acd5be718, 1, 3, 32) = 0x5574d71af294
cap_init(0x5574d71af294, 0x5574d71af29c, 0x5574d71af290, 0x7f1acd4fcd17)
= 0x5574d71af2c4
cap_get_flag(0x5574d71af294, 12, 1, 0x7fff8da6a454) = 0
cap_set_flag(0x5574d71af2c4, 1, 1, 0x5574d60923e0) = 0
cap_get_flag(0x5574d71af294, 13, 1, 0x7fff8da6a454) = 0
cap_set_flag(0x5574d71af2c4, 1, 1, 0x5574d60923e4) = 0
cap_set_proc(0x5574d71af2c4, 1, 0x3000, 4096)= 0
prctl(8, 1, 0x3000, 0x7f1acd4fcd47) = 0
getuid() = 0
setuid(0)= 0
prctl(8, 0, 0x3000, 0) = 0
cap_free(0x5574d71af2c4, 0, 0x3000, 0x7f1acd4fd0aa) = 0
cap_free(0x5574d71af294, 1, 0, 0x5574d71af010) = 0
getuid() = 0
geteuid()= 0
setlocale(LC_ALL, "")=
"LC_CTYPE=en_US.UTF-8;LC_NUMERIC="...
bindtextdomain("iputils", "/usr/share/locale") = "/usr/share/locale"
textdomain("iputils")= "iputils"
strlen("ping") = 4
getopt(2, 0x7fff8da6a5f8, "h?4bRT:6F:N:aABc:dDfi:I:l:Lm:M:n"...) = -1
cap_get_proc(13, 1, 1, 0)= 0x5574d71af2c4
cap_get_flag(0x5574d71af2c4, 13, 1, 0x7fff8da6a454) = 0
cap_set_flag(0x5574d71af2c4, 0, 1, 0x7fff8da6a44c) = 0
cap_set_proc(0x5574d71af2c4, 0, 8192, 0) = 0
cap_free(0x5574d71af2c4, 0x5574d71af2cc, 8192, 0x7f1acd4fcd47) = 0
__errno_location() = 0x7f1acd3def80
socket(2, 2, 1) = -1
socket(2, 3, 1) = 3
__errno_location() = 0x7f1acd3def80
socket(10, 2, 58)= -1
socket(10, 3, 58)= 4
cap_get_proc(13, 0, 58, 0x7f1acd4fdac7) = 0x5574d71af2c4
cap_get_flag(0x5574d71af2c4, 13, 1, 0x7fff8da6a454) = 0
cap_set_flag(0x5574d71af2c4, 0, 1, 0x7fff8da6a44c) = 0
cap_set_proc(0x5574d71af2c4, 0, 0, 0)= 0
cap_free(0x5574d71af2c4, 0x5574d71af2cc, 0, 0x7f1acd4fcd47) = 0
getaddrinfo("google.com", nil, 0x7fff8da6a4b0, 0x7fff8da6a498) = 0
inet_aton("google.com", { 0 }) = 0
...
Par ailleurs, getaddrinfo est plus simple à utiliser que gethostbyname
: ça te retourne les resolutions avec tous les type de familles ; et il
ne faut pas oublier ce buffer overflow (aka "GHOST") :
https://www.qualys.com/2015/01/27/cve-2015-0235/GHOST-CVE-2015-0235.txt
--
Nisar JAGABAR
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/
Re: sur Jessie lors de la lecture de vidéo avec VLC il y as des traîner verte dans l'image
Le lundi 16 septembre 2019 01:10:02 UTC+2, Martin Vézina a écrit : > J'ai le même problème su 2 ordi et mon ami as le problème sur > c'est 2 ordi aussi > > > > C'est probablement une mise à jour récente. C'est la première > fois de puis la sortie de Debian Jessie. En fessent une recherche > sur le net, j'ai vue ce type de problème signaler sur Stretch. A une époque, utiliser les codecs supplémentaires (libavcodec-extra) posait des problèmes lors des mises-à-jour qui réinstallaient systématiquement à la place les codecs normaux (libavcodec). Il fallait alors réinstaller les codecs supplémentaires à la main. Je ne sais plus quand ça a cessé (Stretch? Buster?). D'autre part les versions de vlc et libavcodec* dans Stretch sont elles-mêmes assez vieilles... Enfin, j'ai le sentiment (ce n'est qu'une impression) qu'utiliser les veilles versions de Debian pendant leur prise-en-charge LTS pose quelques problèmes. Je me dit que si c'est ce que je voulais faire, je testerais plutôt Centos. Et sinon, dans un cas d'utilisation normale, à moins que tu n'aies identifié des causes réelles qui justifient de rester en Debian 8 (Jessie), j'aurais tendance à te dire de passer en 9 (Stretch) d'abord, de vérifier que la migration s'est bien passée et de passer en Debian 10 (Buster).
Re: Dnsmasq: interdire /etc/hosts aux requètes provenant d'un VLAN particulier
Ma question n'était sans doute pas très bien formulée. Elle ne portait pas sur la façon de router le DNS, mais d'avoir plusieurs résolutions locales différenciées. Exemple: Pour le LAN1, host1 vaut 192.168.1.1 Pour le LAN2, host2 vaut 176.16.1.2 Une machine du LAN1 ne doit pas pouvoir résoudre host2. Une machine du LAN2 ne doit pas pouvoir résoudre host1. Évidemment, host1 est une ressource privée du réseau pour laquelle, je n'ai pas de FQDN de type host1.exemple.fr. Je gère ces ressources privées en éditant simplement un ou deux fichiers de types /etc/hosts. En d'autres termes, ma question porte sur la configuration de Dnsmasq qui par construction, reçoit des requètes DNS, consulte des fichiers de types /etc/hosts et relaie vers un serveur DNS tiers les requètes pour lesquelles il n'a pas de réponse locale. Dans la mesure du possible, j'essaie d'éviter d'avoir deux instances de Dnsmasq. Le ven. 13 sept. 2019 à 16:20, Basile Starynkevitch < bas...@starynkevitch.net> a écrit : > > On 9/13/19 4:18 PM, Olivier wrote: > > Bonjour, > > Une question toute simple: > j'ai une machine sous Debian Stretch avec deux interfaces eth0 et eth0.123 > Comment faire pour qu' > 1. aux requètes reçues via eth0, Dnsmasq réponde en consultant un fichier > /etc/hosts puis le serveur 1.1.1.1 > 2. aux requètes reçues via eth0.123, Dnsmasq réponde en consultant un > fichier /etc/hosts123 puis le serveur 8.8.8.8. > > > CA s'appelle une DeM-Militarized Zone. > > > Googler sur *debian DMZ * > > voir aussi iptables > > > -- > Basile STARYNKEVITCH == http://starynkevitch.net/Basile > opinions are mine only - les opinions sont seulement miennes > Bourg La Reine, France; > (mobile phone: cf my web page / voir ma page web...) > >
