Messages récents

Pages: [1] 2 3 4 5 6 ... 10
1
C'est la même que pour openDNS:
- la geoIP se fait sur un serveur de type "répartition de charge" (Google et Cloudfare) et non sur le serveur DNS lui-même (l'IP du DNS est donc celui de la répartition de charge qui est en fait une répartition selon le pays par geoIP)
- en soit, un serveur DNS est incapable de répondre selon ton geoIP

Mais la 1ere solution demande des serveurs supplémentaires (autant de serveurs DNS qu'il faut de politiques différentes en DNS et le serveur qui répartit selon ton geoIP), et donc des ressources: openDNS avait jeté l'éponge sans aucun préavis, Quad9 peut se permettre de perdre de l'argent sur un mois (ils sont déjà sur une astreinte journalière de 1000€/jour et ils ont décidé que c'est moins chère que la solution à la Google et à la Cloudfare mais intenable sur le long terme).

Enfin, du blocage pur par IP ou geoIP du demandeur de requête DNS, un serveur DNS sait le gérer de base.
2
Le truc qui m'étonne un peu dans leur argumentation, c'est que d'un côté ils justifient leur décision en expliquant qu'ils ne peuvent pas appliquer de filtrage pour la France seulement, à cause des limites de la géolocalisation des IP. Et d'un autre côté ils répondent... En bloquant la Franche par géolocalisation des IP ?
3
Après, OpenDNS (qui a aussi son sujet dans ce forum), c'est au tour de Quad9 de quitter la France, du côté de ses serveurs DNS.

Dans ce cas, il y a un préavis d'un mois, et Quad9 espère gagner en appel. Mais il y a 0 chance, en fait, vu les statistiques de la Justice française quand il y a un ayant droit en face.

Next (entre autres) en parle: https://next.ink/263502/dns-quad9-quitte-la-france-apres-avoir-ete-condamnee-face-a-bein-pour-defaut-de-blocage/
4
Oui, je vais upgrader la version de SMF du forum.
Je vais tenter de continuer à bloquer uniquement le trafic malveillant.

Je pense que j'étais surtout mal équipé en scripts. J'étais habitué à des attaques DDOS avec des attaquants qui présentent des user-agent aléatoires (quand on regardait le trafic d'une même IP, l'user-agent changeait à chaque requête). Je ne regardais pas le volume par user-agent. Quelle erreur de ma part...

J'ai analysé les log du 22 octobre en les classant par user-agent, en répartissant les requêtes IPv4 et IPv6. Un taux trop faible ou trop élevé d'IPv6 : On sait que ce ne sont pas des utilisateurs derrière ces user-agent (au moins en grande partie).

Ci-dessous j'ai mis en vert le trafic qui est majoritairement humain. En rouge ou orange, les robots qui se présente tel que. On a des lignes avec un user-agent qui se présente comme un navigateur, mais on sait clairement que c'est faux avec le taux d'IPv6.

Les ralentissements des derniers jours, c'est la faute de AionBot, un robot d'exploration web principalement utilisé pour l'entraînement de modèles d'intelligence artificielle ou la veille concurrentielle.
C'est très simple à bloquer, mais je n'avais pas remarqué le volume de ses requêtes.
D'autres personnes remontent un comportement agressif de ce robot, il interroge des serveurs sans consulter le robots.txt et sans fournir de page d'explication ou de contact d'abus.


(cliquez sur la miniature ci-dessous - le document est au format PDF)
5
Logiciels Logiciels / PHP - CVE-2026-109618 / CVE-2026-109619
« Dernier message par thenico le Hier à 23:33:05 »
E-Mail reçu de Stormshield (filiale d'Airbus et spécialiste de la sécurité informatique (pare-feu, EDR et crypto)) aujourd'hui vers 19h.
On peut légitimement se poser des questions sur les ressources attribués à la MCO sur ce service qui est critique car stockant les configurations pare-feux des clients (identifiants inclus).
6
Orange 5G/4G Orange / Panne mobile Orange 21/10/2026
« Dernier message par Pegasus38 le Hier à 23:11:39 »
Attention 5G+ c'est pas la 5G SA
7
SFR Actus SFR Altice / Faille WiFI WPS NBV6AC
« Dernier message par Thornhill le Hier à 22:25:04 »
Bonjour,

La NB6VAC est vulnérable à la faille broadcom_wps_monitor révélée par Quentin Kaiser, qui touche de nombreuses Box (Orange Belgique/Pologne, SFR, Proximus) ou routeurs anciens :

https://github.com/qkaiser/broadcom-wps
https://quentinkaiser.be/security/2026/10/16/one-parser-two-bugs/

Je n'ai pas trouvé de communication de SFR à ce sujet, certains opérateurs, faute de maintenance firmware, ont désactivé le module wps-monitor, par exemple Proximus :

https://x.com/proximus/status/2112873648264454366?s=20

Alors, je sais bien que la situation de SFR est compliquée, mais je trouve ça grave pour un opérateur national de laisser une faille pareille sans correctif sur une box connectée à son réseau.
8


    Merci beaucoup pour ton retour et pour cette question qui tape en plein dans le mille !

    Tu as parfaitement cerné le sujet : la cible principale n'est pas la DSI d'une grande entreprise qui dispose déjà d'un Active Directory complet, d'un inventaire centralisé et d'outils de supervision en place.

    La valise s'adresse précisément à ceux qui interviennent sur des parcs qu'ils n'administrent pas au quotidien ou dont la documentation est inexistante :

        Les prestataires informatiques / MSP en phase d'audit d'entrée (Avant-vente / Onboarding) :
        Quand un technicien arrive chez un nouveau prospect ou client PME (10 à 50 postes), il ne peut pas installer d'agents logiciels partout sans contrat ni identifiants. La valise permet en 5 minutes de cartographier le parc, repérer les équipements critiques et générer un rapport PDF propre pour justifier les préconisations.

        Les visites de maintenance récurrentes chez les PME / TPE / Mairies :
        Pour les petits clients qui n'ont pas de contrat de télésurveillance 24/7, le prestataire passe une fois par mois ou par trimestre. La valise garde la « mémoire » de chaque client et lui dit immédiatement : « Attention, le NAS de sauvegarde ou la caméra IP présente lors de ta visite du 10 juillet ne répond plus aujourd'hui ».

        Les environnements fermés ou sensibles (Zéro Cloud) :
        Les sites industriels, cabinets médicaux, notaires ou collectivités qui refusent (ou dont les règles interdisent) d'envoyer la cartographie de leur réseau vers un Cloud tiers. Tout reste confiné dans le boîtier.

    Est-ce que ce type de cas d'usage te paraît cohérent avec ce que tu observes sur le terrain ? Selon toi, y a-t-il d'autres profils d'intervenants auxquels cela pourrait servir ?

9
Bouygues Telecom Remplacer la Bbox par un routeur / Config OpenWRT derrière ONT Bouygues
« Dernier message par nico1881 le Hier à 21:31:26 »
A propos de la différence entre wan.100 et wan-100:

wan.100 est une syntaxe pour déclarer un VLAN 100 sur l'interface 'wan'. Elle ne nécessite pas de définition d'interface supplémentaire. Exemple sur l'interface eth0:

config interface 'wan'
    option device 'eth0.100'
    option proto 'dhcp'
    option vendorid 'BYGTELIAD'
    option peerdns '0'

De la même façon pour utiliser le VLAN ID 42 sur l'interface eth4 la syntaxe est eth4.42
C'est la syntaxe Linux par défault pour forcer un VLAN ID sur un NIC.

Une autre façon de faire est de déclarer une interface virtuelle de type 8021q (un VLAN) sur le VLAN ID 100, en l'appelant par exemple 'wan-100' (zonzon marcherait tout aussi bien), et de pointer le device associé au réseau WAN vers cette interface 'wan-100'. Exemple sur l'interface eth0:

config device
    option name 'eth0-100'  <- Le nom du device virtuel
    option type '8021q'
    option ifname 'eth0'    <- Le device réel
    option vid '100'

config interface 'wan'
    option device 'eth0-100'    <- Le nom du device virtuel
    option proto 'dhcp'
    option vendorid 'BYGTELIAD'
    option peerdns '0'

Je trouve ça plus propre d'avoir un device virtuel dédié pour décrire le VLAN 100 mais c'est bien une question de préférence, les deux fonctionnent.

Pour la partie IPv6 le plus simple est d'utiliser un alias pour indiquer qu'il s'agit du même device, puis d'indiquer les options IPv6 qui vont bien. La syntaxe pour un alias est @interface où interface est celle indiquée pour le WAN en IPv4.

config interface 'wan6'
    option device '@wan'
    option proto 'dhcpv6'
    option reqaddress 'try'
    option reqprefix 'auto:1'
    option norelease '1'
10
Je reviens vers vous suite au problème rencontré, après intervention d'un technicien il y avait visiblement de la poussière sur ma jarretière au niveau du PM de ma rue qui a obstrué mon réseau c'est revenu juste après son passage :)
Pages: [1] 2 3 4 5 6 ... 10