Re: [FRnOG] [FRnog] [tech] Trunk SIP CS OXE +GD card configuration direct rtp sur asterisk 1.6.2.24 sortie opérateur

[David Ponzone]

Ce n'est pas à ton asterisk de décider où envoyer le RTP, c'est à l'OXE de lui 
indiquer dans le SDP.

David Ponzone



> Le 4 mars 2016 à 20:40, christophe abesse  a écrit :
> 
> Bonsoir,
> 
> 
> La communauté
> 
> Je viens à vous car j'ai un petit souci avec un CS Type OXE R10 qui
> s'enregistre bien sur mon proxy sip
> 
> configuration sip
> 
> [x] ;oxe r10 Test
> type=friend
> host=x
> disallow=all
> allow=alaw
> allow=ulaw
> call-limit=120
> canreinvite=yes
> directmedia=yes
> directrtpsetup=yes
> dtmfmode=rfc2833
> qualify=yes
> nat=yes
> context=fromX
> 
> 
> schéma logique :
> 
> Proxy privé - mpls Routeur coeur backbone - CE client - OXE -GD CARD donc
> pas de nat entre eux.
> 
> 
> Le proxy ping l'oxe et la gd card est dans le même subnet
> et inversement point à point donc pas de
> 
> Je vois bien depuis mon proxy en effectuant un rtp debug ceci
> 
> cette ip correspond à la gd card (soit la carte dsp) qui est censée gérer
> le routage des flux rtp
> 
> Sent RTP packet to 10.10.10.10:32556 (type 08, seq 038691, ts
> 201837040, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038692, ts
> 201837200, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038693, ts
> 201837360, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038694, ts
> 201837520, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038695, ts
> 201837680, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038696, ts
> 201837840, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038697, ts
> 201838000, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038698, ts
> 201838160, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038699, ts
> 201838320, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038700, ts
> 201838480, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038701, ts
> 201838640, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038702, ts
> 201838800, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038703, ts
> 201838960, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038704, ts
> 201839120, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038705, ts
> 201839280, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038706, ts
> 201839440, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038707, ts
> 201839600, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038708, ts
> 201839760, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038709, ts
> 201839920, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038710, ts
> 201840080, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038711, ts
> 201840240, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038712, ts
> 201840400, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038713, ts
> 201840560, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038714, ts
> 201840720, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038715, ts
> 201840880, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038716, ts
> 201841040, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038717, ts
> 201841200, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038718, ts
> 201841360, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038719, ts
> 201841520, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038720, ts
> 201841680, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038721, ts
> 201841840, len 000160)
> Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038722, ts
> 201842000, len 000160)
> 
> 
> Mais je constate que mon prx envoi toute la signalisation ainsi que les
> flux rtp à la CS qui ne sait comment l’interpréter donc il drop.
> 
> Typiquement le pb semble propre à l'alcatel et cela semble ne peut se
> corriger.
> 
> Donc je cherche à modifier des choses sur mon asterisk de sorte à dire tu
> parles à la CS niveau 100 à 200 puis le rtp tu l'envoi à une autre ip
> 
> Malheureusement j'ai lorsque l'on était sur un Nat publique c'était pire,
> en effet, je redirigé les flux avec un range de 2 à 4 mais cela
> matché pas.
> 
> Je ne veux pas investir sur un SBC car c'est vraiement couteux et ne veut
> pas installer un serveur asterisk propre au client afin de faire la
> correspondance.
> 
> Puis je utiliser mon proxy et modifier certain champs sur le sipdotconf
> pour corriger cela.
> 
> La conf du sip.conf en début de rédaction et la dernière conf
> 
> 
> Merci pour vos lumières
> 
> Bon week-end
> 
> Christophe ABESSE
> 
> 

[FRnOG] [FRnog] [tech] Trunk SIP CS OXE +GD card configuration direct rtp sur asterisk 1.6.2.24 sortie opérateur

[christophe abesse]

Bonsoir,


La communauté

Je viens à vous car j'ai un petit souci avec un CS Type OXE R10 qui
s'enregistre bien sur mon proxy sip

configuration sip

[x] ;oxe r10 Test
type=friend
host=x
disallow=all
allow=alaw
allow=ulaw
call-limit=120
canreinvite=yes
directmedia=yes
directrtpsetup=yes
dtmfmode=rfc2833
qualify=yes
nat=yes
context=fromX


schéma logique :

Proxy privé - mpls Routeur coeur backbone - CE client - OXE -GD CARD donc
pas de nat entre eux.


Le proxy ping l'oxe et la gd card est dans le même subnet
et inversement point à point donc pas de

Je vois bien depuis mon proxy en effectuant un rtp debug ceci

cette ip correspond à la gd card (soit la carte dsp) qui est censée gérer
le routage des flux rtp

Sent RTP packet to 10.10.10.10:32556 (type 08, seq 038691, ts
201837040, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038692, ts
201837200, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038693, ts
201837360, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038694, ts
201837520, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038695, ts
201837680, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038696, ts
201837840, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038697, ts
201838000, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038698, ts
201838160, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038699, ts
201838320, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038700, ts
201838480, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038701, ts
201838640, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038702, ts
201838800, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038703, ts
201838960, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038704, ts
201839120, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038705, ts
201839280, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038706, ts
201839440, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038707, ts
201839600, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038708, ts
201839760, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038709, ts
201839920, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038710, ts
201840080, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038711, ts
201840240, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038712, ts
201840400, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038713, ts
201840560, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038714, ts
201840720, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038715, ts
201840880, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038716, ts
201841040, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038717, ts
201841200, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038718, ts
201841360, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038719, ts
201841520, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038720, ts
201841680, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038721, ts
201841840, len 000160)
Sent RTP packet to  10.10.10.10:32556 (type 08, seq 038722, ts
201842000, len 000160)


Mais je constate que mon prx envoi toute la signalisation ainsi que les
flux rtp à la CS qui ne sait comment l’interpréter donc il drop.

Typiquement le pb semble propre à l'alcatel et cela semble ne peut se
corriger.

Donc je cherche à modifier des choses sur mon asterisk de sorte à dire tu
parles à la CS niveau 100 à 200 puis le rtp tu l'envoi à une autre ip

Malheureusement j'ai lorsque l'on était sur un Nat publique c'était pire,
en effet, je redirigé les flux avec un range de 2 à 4 mais cela
matché pas.

Je ne veux pas investir sur un SBC car c'est vraiement couteux et ne veut
pas installer un serveur asterisk propre au client afin de faire la
correspondance.

Puis je utiliser mon proxy et modifier certain champs sur le sipdotconf
pour corriger cela.

La conf du sip.conf en début de rédaction et la dernière conf


Merci pour vos lumières

Bon week-end

Christophe ABESSE

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[Pierre Emeriaud]

> Je n'ai pas analysé ça particulièrement, mais il ne semble pas y avoir
> une origine géographique particulière.

En fait, en regardant de plus près, le brésil semble ressortir pas mal.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Sylvain Vallerot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 04/03/2016 14:30, Jérôme Nicolle wrote:
> Salut Radu,
> Le 04/03/2016 14:02, Radu-Adrian Feurdean a écrit :
>> De toute facon, avec seulement un seul /22, difficile de faire le boulot
>> de distribution d'adresses aux end-users,

Oui pour les LIR qui font le boulot de distribution pour les EndUsers la limite 
du 
/22 n'a aucune pertinence. En fait elle n'a de pertinence que tant qu'on 
confond le
LIR avec le End User, ce qui en soit est un une mauvaise réponse imposée aux 
LIRs
pour impacter les End Users.

Une nouvelle policy doit être très claire sur le fait que ce sont les 
assignations
par End User qui sont limitées.


> Du point de vue de la charge de travail pour le RIPE NCC, la situation
> est alors contre-productive, puisque les LIR ne peuvent plus jouer leur
> rôle de gestionnaire délégué.

Yep.


> Concernant le retour des PI, j'opterais pour la clarification du statut
> "End User", tout en maintenant la relation via un LIR sponsor.[..]
> Il payerait une somme annuelle forfaitaire moins élevée qu'une
> cotisation de LIR, via son sponsor. Dans les 200€/an dont 50€ pour le
> sponsor et le reste pour le LIR me paraîtrait juste.

AMHA 50 €/an est une somme dérisoire pour le LIR s'il fait son boulot de 
délégation et de suivi et uniquement celui-là (sans autres services liés) 
puisqu'il va être confronté à des frais de personnel conséquents.

Mais je crois qu'il est prématuré de rentrer dans ces considérations
financières, et si tu le fais il faut garder en mémoire le financement 
du Ripe et de la charge de travail associée à ta proposition. Si les
détenteurs de /22 se mettent à payer 150€ au Ripe au lieu de 1400€/an
les revenus du Ripe s'évanouissent alors que sa charge de travail est
en train d'exploser : plus de dossiers, plus de contrôles...


> Les blocs PI ne sont pas transférables à une autre organisation, ils ne
> peuvent que revenir au RIPE si l'organisation perd son statut de end-user.

C'est déjà le cas à priori.


> Bon, c'est encore un peu brouillon, mais ça donne quelques pistes pour
> un cadre un peu plus robuste. Qu'en pensez-vous ? On pousse ça sur ap-wg ?

Trop tôt.

En particulier il faut clarifier le statut des assignations à venir
pour tous les détenteurs d'allocations. C'est seulement ainsi qu'on 
aura une justice ente les LIRs et une incitation à migrer en v6. 

Toutes les futures assignations d'IPv4 au-delà du /24 d'infrastructure
de base doivent avoir un coût significatif.

Ca va poser un problème de contrôle pour les gros détenteurs historiques,
et un problème d'un autre ordre pour ceux qui viennent d'investir dans un
bloc allocated sur le market.

Et il faut que tous les blocs routés soient correctement déclarés.
Les blocs non routés et non déclarés doivent être récupérés par le Ripe
pour éviter les fraudes.

Cordialement,
Sylvain


- -- 
Gixe  - Association 1901  - conseil, hébergement, opérateur pour tous
SIREN 450 404 769-   http://www.gixe.net-cont...@gixe.net
venez nous voir sur IRC geeknode #gixe - tél: 0950315474 - 0686383868
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlbZqWwACgkQJBGsD8mtnRFV/gD/aio1YKvAhhR7fS+ktAffM9N4
TFC31SMbUZr/YMyGZUsA/R+p/PDLe3MbQhGBTAb9X2bJcSTizyMYkLDMIyM7cayq
=bqAV
-END PGP SIGNATURE-


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Radu-Adrian Feurdean]

On Fri, Mar 4, 2016, at 14:46, Jerome SCHEVINGT wrote:
>  Une société A dispose de deux PI dont un pas réellement utilisé 
> (mais annoncé)

Et si la societe A rendait le PI non utilise ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Radu-Adrian Feurdean]

On Fri, Mar 4, 2016, at 14:30, Jérôme Nicolle wrote:
> Seulement dans la rédaction actuelle de la 2015-05, je vois deux
> problèmes :
> 
> - Elle n'est en rien incitative quant à IPv6, puisqu'il n'y a pas de
> condition de déploiement pour l'obtention d'un autre bloc

C'est vrai, il n'y a rien eu dans la v1 (qui n'a pas reuni le support
necessaire pour passer).
J'essaye de corriger dans la v2, mais les echos ne sont pas tres
encourageants. Details en prive.

> - La périodicité fixe est arbitraire, elle ne correspondra pas forcement
> à la vitesse de croissance d'un opérateur. Il me parait plus pertinent
> de revenir au principe de justification des allocations.

Justification des allocations, c'est la chose qui ne passera pas
malhereusement. Mais tu peux toujours essayer pour te convaincre par tes
propres moyens :)
C'est une histoire ou a une epoque certains arrivaient a justifier des
quantites quasiment illimites, contre les petits de bonne foi pour
lesquels c'etait la galere faute de savoir "embellir" les chiffres.

> Concernant le retour des PI, j'opterais pour la clarification du statut
> "End User", tout en maintenant la relation via un LIR sponsor. Ceci pour
> deux raisons :
> 
> - Un end-user n'est pas délégataire de la gestion de la ressource
> - Le RIPE NCC ne pourrait probablement pas encaisser la charge
> administrative
> 
> Un end-user choisirait un LIR sponsor pour monter sa demande. Il fourni
> une preuve d'identité et les moyens de contact, et s'engage à maintenir
> ses contacts et annoncer les ressources demandées.
> 
> Il peut initier une demande de changement de LIR sponsor auprès du RIPE
> via son sponsor cible, sans que le LIR précédent ne puisse s'y opposer.

+1
Comme c'etait (ou au moins ca devait l'etre) avant.

> Il payerait une somme annuelle forfaitaire moins élevée qu'une
> cotisation de LIR, via son sponsor. Dans les 200€/an dont 50€ pour le
> sponsor et le reste pour le LIR me paraîtrait juste.

Actuellement 50EUR/an par bloc PI facture au sponsor, qui lui de
debrouille avec son client selon le contrat qu'il doit forcement avoir
(pre-requis cote RIPE NCC).

> La déclaration initiale et le changement de LIR sponsor seraient
> facturés en one-shot (500€ ?)

+1

> Un LIR existant souhaitant revenir au statut end-user pourrait voir son
> /22 converti en PI s'il en justifie tout l'usage, sinon il serait
> tronqué en un /24 ou /23. L'espace ainsi libéré serait assigné en PI à
> d'autres end-users. Inutile de tronquer l'allocation IPv6 par contre, il
> me semble.

+1, mais j'ai de doutes sur le nombre de pseudo-LIRs qui vont faire ca
(AMHA pas beaucoup).

> Les blocs PI ne sont pas transférables à une autre organisation, ils ne
> peuvent que revenir au RIPE si l'organisation perd son statut de
> end-user.

Je suis personellement d'accord, mais:
https://www.ripe.net/participate/policies/proposals/2014-02

> Le statut de end-user se perd par non-paiement de la cotisation au LIR
> sponsor, qui a la responsabilité d'obtenir une confirmation de cessation
> de l'activité (achat, liquidation, LRAR sans retour… en tenant compte
> des spécificités de chaque pays) et la transmettre au RIPE pour faire
> supprimer les objets.

+ controles aleatoires (mais globalement recurrentes) par RIPE NCC.
Faut s'attendre que certains profitent du depot de bilan de leur client
pour utiliser les PI attaches pour leurs propres besoins.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Jerome SCHEVINGT]

Le 04/03/2016 14:30, Jérôme Nicolle a écrit :

Les blocs PI ne sont pas transférables à une autre organisation, ils ne
peuvent que revenir au RIPE si l'organisation perd son statut de end-user.


Quid des Fusions ?

Et aucun transfert qui serait plus "légitime" ?

un exemple:
Une société A dispose de deux PI dont un pas réellement utilisé 
(mais annoncé)


cette société soutient une autre société B mais avec qui elle n'a 
pas forcement de lien

d'actionnariat et souhaite lui transférer le PI

Si on pense que la société A va rendre son PI en espérant que la société 
B puisse en récupérer

un, c'est un peu croire au père noël ;)





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Jérôme Nicolle]

Salut Radu,

Le 04/03/2016 14:02, Radu-Adrian Feurdean a écrit :
> De toute facon, avec seulement un seul /22, difficile de faire le boulot
> de distribution d'adresses aux end-users, d'ou la 2015-05, pour laquelle
> une deuxieme version sortira bientot.

Du point de vue de la charge de travail pour le RIPE NCC, la situation
est alors contre-productive, puisque les LIR ne peuvent plus jouer leur
rôle de gestionnaire délégué.

Seulement dans la rédaction actuelle de la 2015-05, je vois deux problèmes :

- Elle n'est en rien incitative quant à IPv6, puisqu'il n'y a pas de
condition de déploiement pour l'obtention d'un autre bloc

- La périodicité fixe est arbitraire, elle ne correspondra pas forcement
à la vitesse de croissance d'un opérateur. Il me parait plus pertinent
de revenir au principe de justification des allocations.


Concernant le retour des PI, j'opterais pour la clarification du statut
"End User", tout en maintenant la relation via un LIR sponsor. Ceci pour
deux raisons :

- Un end-user n'est pas délégataire de la gestion de la ressource
- Le RIPE NCC ne pourrait probablement pas encaisser la charge
administrative

Un end-user choisirait un LIR sponsor pour monter sa demande. Il fourni
une preuve d'identité et les moyens de contact, et s'engage à maintenir
ses contacts et annoncer les ressources demandées.

Il peut initier une demande de changement de LIR sponsor auprès du RIPE
via son sponsor cible, sans que le LIR précédent ne puisse s'y opposer.

Il payerait une somme annuelle forfaitaire moins élevée qu'une
cotisation de LIR, via son sponsor. Dans les 200€/an dont 50€ pour le
sponsor et le reste pour le LIR me paraîtrait juste.

La déclaration initiale et le changement de LIR sponsor seraient
facturés en one-shot (500€ ?)

Un LIR existant souhaitant revenir au statut end-user pourrait voir son
/22 converti en PI s'il en justifie tout l'usage, sinon il serait
tronqué en un /24 ou /23. L'espace ainsi libéré serait assigné en PI à
d'autres end-users. Inutile de tronquer l'allocation IPv6 par contre, il
me semble.

Les blocs PI ne sont pas transférables à une autre organisation, ils ne
peuvent que revenir au RIPE si l'organisation perd son statut de end-user.

Les end-users actuels sont invités à basculer sur le nouveau contrat,
sans frais autre que la facturation annuelle. Si plusieurs blocs sont à
transférer, ils doivent être justifiés à nouveau.

Le statut de end-user se perd par non-paiement de la cotisation au LIR
sponsor, qui a la responsabilité d'obtenir une confirmation de cessation
de l'activité (achat, liquidation, LRAR sans retour… en tenant compte
des spécificités de chaque pays) et la transmettre au RIPE pour faire
supprimer les objets.


Bon, c'est encore un peu brouillon, mais ça donne quelques pistes pour
un cadre un peu plus robuste. Qu'en pensez-vous ? On pousse ça sur ap-wg ?

@+


-- 
Jérôme Nicolle
06 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Radu-Adrian Feurdean]

On Fri, Mar 4, 2016, at 08:27, Clement Cavadore wrote:

> Franchement, pas sûr de l'intérêt, c'est même dangereux car ils s'en
> cognent des policies & co, ils veulent juste leurs IP.

L'interet c'est de ne pas griller l'espace restant sur a peine quelques
clients.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Radu-Adrian Feurdean]

On Fri, Mar 4, 2016, at 12:34, Denis Fondras wrote:
> Etant un LIR du "last-/8", je ne peux malheureusement pas faire mon travail de
> distribution dans de bonnes conditions. J'ai épuisé mon /22 donc je ne peux 
> que
> conseiller à mes clients de passer LIR même s'ils n'ont besoin que d'un /24 et
> de refiler le surplus à quelqu'un d'autre.

C'est exactement ca, et tu n'est pas le seul a le faire. Il y a plein
d'autres partout dans le "RIPE-land".
C'est aussi (mais pas que) pour ce raison que le nombre de LIRs a
explose depuis environ un an et demi - 2 ans. Avec comme (seule)
consequence positive la baisse de la cotisation annuelle et le surplus
de 2015 (redistribue comme remise sur la cotisation).

De toute facon, avec seulement un seul /22, difficile de faire le boulot
de distribution d'adresses aux end-users, d'ou la 2015-05, pour laquelle
une deuxieme version sortira bientot.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

[Denis Fondras]

On Thu, Mar 03, 2016 at 09:33:43PM +0100, Sylvain Vallerot wrote:
> Je ne suis pas favorable au retour des PI. Les PI ce sont des ressources
> assignées directement par le Ripe aux EndUsers, ça me semble représenter
> une charge de travail inutile pour le Ripce NCC, alors que les LIR sont
> là pour ça.
> 

Etant un LIR du "last-/8", je ne peux malheureusement pas faire mon travail de
distribution dans de bonnes conditions. J'ai épuisé mon /22 donc je ne peux que
conseiller à mes clients de passer LIR même s'ils n'ont besoin que d'un /24 et
de refiler le surplus à quelqu'un d'autre.

Denis


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] Re: [FRnOG] [TECH] blocklist.de

[Pierre Emeriaud]

Le 4 mars 2016 à 09:34, ay pierre  a écrit :
> Salut a tous pourriez vous m'expliquer le principe de fail2ban?

Google over SMTP. Pas mal, pas mal. Y'a une rfc à sortir là pour le
mois prochain.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[Jérôme BERTHIER]

Le 04/03/2016 09:47, ay pierre a écrit :

mais il faut  serveur linux pour pouvoir crée les regle

Si tu veux un HIDS multi-OS, regardes OSSEC.

Tu peux appliquer des réponses actives :
http://ossec.github.io/docs/manual/ar/index.html

ça reste beaucoup plus outillé pour le monde Unix cela dit.

A+

--
Jérôme BERTHIER


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[Laurent]

Le 04/03/2016 09:47, ay pierre a écrit :
> mais il faut  serveur linux pour pouvoir crée les regle

Ah oui : à ma connaissance, ça ne tourne que sous *nix


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[ay pierre]

mais il faut  serveur linux pour pouvoir crée les regle

Le 4 mars 2016 à 09:37, neo futur  a écrit :
> 2016-03-04 3:34 GMT-05:00 ay pierre :
>> Salut a tous pourriez vous m'expliquer le principe de fail2ban?
> tu fais des regles pour bannir automatiquement une ip qui fait un truc mal
> * bruteforsce ssh - drop
> * scan de port abusif -> drop
> * whatever you want to refuse -> drop
>
>>
>> Le 4 mars 2016 à 09:14, Pierre Emeriaud  a écrit :
 Leur page http://www.blocklist.de/en/index.html confirme ce que je voyais 
 en analysant le fichier  http://lists.blocklist.de/lists/all.txt : entre 
 mercredi 2 à environ 1000 PST (soit 1800 GMT) et maintenant jeudi 3 2200 
 PST (soit vendredi 4 0600 GMT) j'ai constaté que leur liste a grossi de 
 ~25000 entrées à ~6 entrées.
>>>
>>> J'ai constaté une grosse augmentation du trafic malicieux sur mes
>>> honeypots depuis quelques jours. Je blackliste environ 2 à 3x plus
>>> d'ip par jour qu'avant.
>>>
>>> Je n'ai pas analysé ça particulièrement, mais il ne semble pas y avoir
>>> une origine géographique particulière.
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
>
>
> --
> Cordialement
>---
>  William Waisse
>   http://waisse.org | http://neoskills.com | http://ww7.pe |
> https://careers.stackoverflow.com/neofutur
> "Computers are like air conditionners. They work better when you close 
> windows."
> "You have enemies? Good. That means you've stood up for something in your 
> life."
> "First they ignore you, then they laugh at you, then they fight you,
> then you win"


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[Laurent]

Le 04/03/2016 09:37, neo futur a écrit :
> 2016-03-04 3:34 GMT-05:00 ay pierre :
>> Salut a tous pourriez vous m'expliquer le principe de fail2ban?
> tu fais des regles pour bannir automatiquement une ip qui fait un truc mal
> * bruteforsce ssh - drop
> * scan de port abusif -> drop
> * whatever you want to refuse -> drop

C'est ça.
Ça analyse tes logs pour déterminer le nombre de "fail" , et au bout
d'un certain nombre, déterminé par la conf, ça crée une règle qui /drop/
les paquets provenant de cette ip pour un certain temps, déterminé par
la conf également.
le paramétrage se fait par /jail/, qui correspondent à un certain type
d'attaque.
C'est plutôt efficace.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[neo futur]

2016-03-04 3:34 GMT-05:00 ay pierre :
> Salut a tous pourriez vous m'expliquer le principe de fail2ban?
tu fais des regles pour bannir automatiquement une ip qui fait un truc mal
* bruteforsce ssh - drop
* scan de port abusif -> drop
* whatever you want to refuse -> drop

>
> Le 4 mars 2016 à 09:14, Pierre Emeriaud  a écrit :
>>> Leur page http://www.blocklist.de/en/index.html confirme ce que je voyais 
>>> en analysant le fichier  http://lists.blocklist.de/lists/all.txt : entre 
>>> mercredi 2 à environ 1000 PST (soit 1800 GMT) et maintenant jeudi 3 2200 
>>> PST (soit vendredi 4 0600 GMT) j'ai constaté que leur liste a grossi de 
>>> ~25000 entrées à ~6 entrées.
>>
>> J'ai constaté une grosse augmentation du trafic malicieux sur mes
>> honeypots depuis quelques jours. Je blackliste environ 2 à 3x plus
>> d'ip par jour qu'avant.
>>
>> Je n'ai pas analysé ça particulièrement, mais il ne semble pas y avoir
>> une origine géographique particulière.
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



-- 
Cordialement
   ---
 William Waisse
  http://waisse.org | http://neoskills.com | http://ww7.pe |
https://careers.stackoverflow.com/neofutur
"Computers are like air conditionners. They work better when you close windows."
"You have enemies? Good. That means you've stood up for something in your life."
"First they ignore you, then they laugh at you, then they fight you,
then you win"


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[ay pierre]

Salut a tous pourriez vous m'expliquer le principe de fail2ban?

Le 4 mars 2016 à 09:14, Pierre Emeriaud  a écrit :
>> Leur page http://www.blocklist.de/en/index.html confirme ce que je voyais en 
>> analysant le fichier  http://lists.blocklist.de/lists/all.txt : entre 
>> mercredi 2 à environ 1000 PST (soit 1800 GMT) et maintenant jeudi 3 2200 PST 
>> (soit vendredi 4 0600 GMT) j'ai constaté que leur liste a grossi de ~25000 
>> entrées à ~6 entrées.
>
> J'ai constaté une grosse augmentation du trafic malicieux sur mes
> honeypots depuis quelques jours. Je blackliste environ 2 à 3x plus
> d'ip par jour qu'avant.
>
> Je n'ai pas analysé ça particulièrement, mais il ne semble pas y avoir
> une origine géographique particulière.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] blocklist.de

[Pierre Emeriaud]

> Leur page http://www.blocklist.de/en/index.html confirme ce que je voyais en 
> analysant le fichier  http://lists.blocklist.de/lists/all.txt : entre 
> mercredi 2 à environ 1000 PST (soit 1800 GMT) et maintenant jeudi 3 2200 PST 
> (soit vendredi 4 0600 GMT) j'ai constaté que leur liste a grossi de ~25000 
> entrées à ~6 entrées.

J'ai constaté une grosse augmentation du trafic malicieux sur mes
honeypots depuis quelques jours. Je blackliste environ 2 à 3x plus
d'ip par jour qu'avant.

Je n'ai pas analysé ça particulièrement, mais il ne semble pas y avoir
une origine géographique particulière.


---
Liste de diffusion du FRnOG
http://www.frnog.org/