J'ai un petit cubieboard sur lequel tourne une Debian Jessie.
J'ai r=C3=A9cemment souscrit =C3=A0 un abo VPN pour, notamment, avoir une I=
P fixe.
Mais avant de me brancher sur le net pour de vrai, je pense que la mise en =
place d'un pare-feu pourrait s'av=C3=A9rer utile.
Je me suis donc lancer dans la lecture de quelques articles donc un chapitr=
e du bouquin =C2=ABLe cahier de l'administrateur Debian=C2=BB traitant du s=
ujet et dans lequel les auteurs conseillent fwbuilder (https://packages.deb=
ian.org/jessie/fwbuilder).
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple =C3=A0 =
utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jet=C3=A9 un =C5=93il sur le script g=C3=A9n=C3=A9r=C3=A9=
, j'ai eu quelques surprises (pas de prise en compte de l'IPv6 alors que la=
d=C3=A9finition de mes interfaces comportait aussi de l'IPv6, pas de r=C3=
=A8gles de prise en charge d'une interface rajout=C3=A9e apr=C3=A8s la conf=
ig' de d=C3=A9part, ...).
Bref, comme je n'ai pas trop de temps =C3=A0 passer pour ma=C3=AEtriser fwb=
uilder, je pense me rabattre sur un set de r=C3=A8gles simple comme d=C3=A9=
crit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connect=C3=A9e sur mon r=C3=A9s=
eau local et sur le switch de mon FAI et une interface tun0 cr=C3=A9=C3=A9e=
via openvpn et connect=C3=A9e au net avec IP fixe pour laquelle je veux fi=
ltrer le trafic.
Ma question : pensez-vous que les r=C3=A8gles de l'article du wiki suffisen=
t ?
Je pense simplement y ajouter la r=C3=A8gle suivante pour autoriser le traf=
ic de mon r=C3=A9seau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Merci d'avance pour vos retours.
Et bonne soir=C3=A9e =C3=A0 tous qui me liront jusqu'ici.
J'ai un petit cubieboard sur lequel tourne une Debian Jessie.
J'ai récemment souscrit à un abo VPN pour, notamment, avoir une IP fixe.
Mais avant de me brancher sur le net pour de vrai, je pense que la mise en place d'un pare-feu pourrait s'avérer utile.
Je me suis donc lancer dans la lecture de quelques articles donc un chapitre du bouquin «Le cahier de l'administrateur Debian» traitant du sujet et dans lequel les auteurs conseillent fwbuilder (https://packages.debian.org/jessie/fwbuilder).
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple à utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jeté un œil sur le script généré, j'ai eu quelques surprises (pas de prise en compte de l'IPv6 alors que la définition de mes interfaces comportait aussi de l'IPv6, pas de règles de prise en charge d'une interface rajoutée après la config' de départ, ...).
Bref, comme je n'ai pas trop de temps à passer pour maîtriser fwbuilder, je pense me rabattre sur un set de règles simple comme décrit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connectée sur mon réseau local et sur le switch de mon FAI et une interface tun0 créée via openvpn et connectée au net avec IP fixe pour laquelle je veux filtrer le trafic.
Ma question : pensez-vous que les règles de l'article du wiki suffisent ?
Je pense simplement y ajouter la règle suivante pour autoriser le trafic de mon réseau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Merci d'avance pour vos retours.
Et bonne soirée à tous qui me liront jusqu'ici. [...]
Si la machine ne fait tourner *AUCUN* service un firewall n'est pas nécessaire. Et si l'ensemble du trafic passe par le VPN, une règle qui rejette tout le trafic vers l'IP publique _SAUF_ pour le port du VPN est suffisante.
-- Daniel
Le 05/12/2015 18:20, Jean-Marc a écrit :
salut la liste,
Bonsoir
J'ai un petit cubieboard sur lequel tourne une Debian Jessie.
J'ai récemment souscrit à un abo VPN pour, notamment, avoir une IP fixe.
Mais avant de me brancher sur le net pour de vrai, je pense que la mise en place d'un pare-feu pourrait s'avérer utile.
Je me suis donc lancer dans la lecture de quelques articles donc un chapitre du bouquin «Le cahier de l'administrateur Debian» traitant du sujet et dans lequel les auteurs conseillent fwbuilder (https://packages.debian.org/jessie/fwbuilder).
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple à utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jeté un œil sur le script généré, j'ai eu quelques surprises (pas de prise en compte de l'IPv6 alors que la définition de mes interfaces comportait aussi de l'IPv6, pas de règles de prise en charge d'une interface rajoutée après la config' de départ, ...).
Bref, comme je n'ai pas trop de temps à passer pour maîtriser fwbuilder, je pense me rabattre sur un set de règles simple comme décrit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connectée sur mon réseau local et sur le switch de mon FAI et une interface tun0 créée via openvpn et connectée au net avec IP fixe pour laquelle je veux filtrer le trafic.
Ma question : pensez-vous que les règles de l'article du wiki suffisent ?
Je pense simplement y ajouter la règle suivante pour autoriser le trafic de mon réseau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Merci d'avance pour vos retours.
Et bonne soirée à tous qui me liront jusqu'ici.
[...]
Si la machine ne fait tourner *AUCUN* service un firewall n'est pas
nécessaire. Et si l'ensemble du trafic passe par le VPN, une règle qui
rejette tout le trafic vers l'IP publique _SAUF_ pour le port du VPN est
suffisante.
J'ai un petit cubieboard sur lequel tourne une Debian Jessie.
J'ai récemment souscrit à un abo VPN pour, notamment, avoir une IP fixe.
Mais avant de me brancher sur le net pour de vrai, je pense que la mise en place d'un pare-feu pourrait s'avérer utile.
Je me suis donc lancer dans la lecture de quelques articles donc un chapitre du bouquin «Le cahier de l'administrateur Debian» traitant du sujet et dans lequel les auteurs conseillent fwbuilder (https://packages.debian.org/jessie/fwbuilder).
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple à utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jeté un œil sur le script généré, j'ai eu quelques surprises (pas de prise en compte de l'IPv6 alors que la définition de mes interfaces comportait aussi de l'IPv6, pas de règles de prise en charge d'une interface rajoutée après la config' de départ, ...).
Bref, comme je n'ai pas trop de temps à passer pour maîtriser fwbuilder, je pense me rabattre sur un set de règles simple comme décrit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connectée sur mon réseau local et sur le switch de mon FAI et une interface tun0 créée via openvpn et connectée au net avec IP fixe pour laquelle je veux filtrer le trafic.
Ma question : pensez-vous que les règles de l'article du wiki suffisent ?
Je pense simplement y ajouter la règle suivante pour autoriser le trafic de mon réseau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Merci d'avance pour vos retours.
Et bonne soirée à tous qui me liront jusqu'ici. [...]
Si la machine ne fait tourner *AUCUN* service un firewall n'est pas nécessaire. Et si l'ensemble du trafic passe par le VPN, une règle qui rejette tout le trafic vers l'IP publique _SAUF_ pour le port du VPN est suffisante.
J'ai récemment souscrit à un abo VPN pour, notamment, avoir une IP fixe.
Qu'est-ce qu'il ne faut pas faire pour avoir une adresse IP fixe...
Mais avant de me brancher sur le net pour de vrai, je pense que la mise en place d'un pare-feu pourrait s'avérer utile.
Bof. Pour quoi faire ?
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple à utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jeté un oeil sur le script généré, j'ai eu quelques surprises (pas de prise en compte de l'IPv6 alors que la définition de mes interfaces comportait aussi de l'IPv6,
Pas forcément nécessaire. Faut voir quel IPv6. Si c'est juste du link local (fe80::/10), pas besoin.
pas de règles de prise en charge d'une interface rajoutée après la config' de départ, ...).
L'informatique n'est pas encore de la magie.
Bref, comme je n'ai pas trop de temps à passer pour maîtriser fwbuilder, je pense me rabattre sur un set de règles simple comme décrit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connectée sur mon réseau local et sur le switch de mon FAI et une interface tun0 créée via openvpn et connectée au net avec IP fixe pour laquelle je veux filtrer le trafic.
Pas d'accord : deux interfaces différenciées, c'est déjà compliqué.
Ma question : pensez-vous que les règles de l'article du wiki suffisent ?
Suffisent pour quoi faire ? Elles autorisent des connexions entrantes sur des ports. Est-ce utile ? Au passage, il ne s'occupe pas plus de l'IPv6 que fwbuilder. Note : le commentaire concernant les types ICMP est stupide : les paquets ICMP qu'il vaut mieux ne pas bloquer ont déjà été acceptés grâce à leur état RELATED.
Je pense simplement y ajouter la règle suivante pour autoriser le trafic de mon réseau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Pourquoi s'embêter à filtrer sur la plage d'adresses ? L'interface suffit. Si un pirate arrive à s'introduire sur ton réseau local, nul doute qu'il prendra une adresse qui va bien dans la plage.
Le bidule doit-il faire office de routeur entre le LAN et le VPN ?
Jean-Marc a écrit :
J'ai récemment souscrit à un abo VPN pour, notamment, avoir une IP fixe.
Qu'est-ce qu'il ne faut pas faire pour avoir une adresse IP fixe...
Mais avant de me brancher sur le net pour de vrai, je pense que la mise
en place d'un pare-feu pourrait s'avérer utile.
Bof. Pour quoi faire ?
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple à
utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jeté un oeil sur le script généré, j'ai eu quelques
surprises (pas de prise en compte de l'IPv6 alors que la définition de
mes interfaces comportait aussi de l'IPv6,
Pas forcément nécessaire. Faut voir quel IPv6. Si c'est juste du link
local (fe80::/10), pas besoin.
pas de règles de prise en
charge d'une interface rajoutée après la config' de départ, ...).
L'informatique n'est pas encore de la magie.
Bref, comme je n'ai pas trop de temps à passer pour maîtriser
fwbuilder, je pense me rabattre sur un set de règles simple comme
décrit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connectée sur mon réseau
local et sur le switch de mon FAI et une interface tun0 créée via
openvpn et connectée au net avec IP fixe pour laquelle je veux filtrer
le trafic.
Pas d'accord : deux interfaces différenciées, c'est déjà compliqué.
Ma question : pensez-vous que les règles de l'article du wiki suffisent ?
Suffisent pour quoi faire ?
Elles autorisent des connexions entrantes sur des ports. Est-ce utile ?
Au passage, il ne s'occupe pas plus de l'IPv6 que fwbuilder.
Note : le commentaire concernant les types ICMP est stupide : les
paquets ICMP qu'il vaut mieux ne pas bloquer ont déjà été acceptés grâce
à leur état RELATED.
Je pense simplement y ajouter la règle suivante pour autoriser le
trafic de mon réseau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Pourquoi s'embêter à filtrer sur la plage d'adresses ? L'interface
suffit. Si un pirate arrive à s'introduire sur ton réseau local, nul
doute qu'il prendra une adresse qui va bien dans la plage.
Le bidule doit-il faire office de routeur entre le LAN et le VPN ?
J'ai récemment souscrit à un abo VPN pour, notamment, avoir une IP fixe.
Qu'est-ce qu'il ne faut pas faire pour avoir une adresse IP fixe...
Mais avant de me brancher sur le net pour de vrai, je pense que la mise en place d'un pare-feu pourrait s'avérer utile.
Bof. Pour quoi faire ?
J'ai donc installer fwbuilder et, de prime abord, il a l'air simple à utiliser, propose des config' sur base de templates, ...
Mais lorsque j'ai jeté un oeil sur le script généré, j'ai eu quelques surprises (pas de prise en compte de l'IPv6 alors que la définition de mes interfaces comportait aussi de l'IPv6,
Pas forcément nécessaire. Faut voir quel IPv6. Si c'est juste du link local (fe80::/10), pas besoin.
pas de règles de prise en charge d'une interface rajoutée après la config' de départ, ...).
L'informatique n'est pas encore de la magie.
Bref, comme je n'ai pas trop de temps à passer pour maîtriser fwbuilder, je pense me rabattre sur un set de règles simple comme décrit sur le wiki Debian ici : https://wiki.debian.org/iptables
Ma config' l'est aussi : une interface eth0 connectée sur mon réseau local et sur le switch de mon FAI et une interface tun0 créée via openvpn et connectée au net avec IP fixe pour laquelle je veux filtrer le trafic.
Pas d'accord : deux interfaces différenciées, c'est déjà compliqué.
Ma question : pensez-vous que les règles de l'article du wiki suffisent ?
Suffisent pour quoi faire ? Elles autorisent des connexions entrantes sur des ports. Est-ce utile ? Au passage, il ne s'occupe pas plus de l'IPv6 que fwbuilder. Note : le commentaire concernant les types ICMP est stupide : les paquets ICMP qu'il vaut mieux ne pas bloquer ont déjà été acceptés grâce à leur état RELATED.
Je pense simplement y ajouter la règle suivante pour autoriser le trafic de mon réseau local :
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Pourquoi s'embêter à filtrer sur la plage d'adresses ? L'interface suffit. Si un pirate arrive à s'introduire sur ton réseau local, nul doute qu'il prendra une adresse qui va bien dans la plage.
Le bidule doit-il faire office de routeur entre le LAN et le VPN ?
> Si la machine ne fait tourner *AUCUN* service un firewall n'est pas > nécessaire.
La machine fait tourner quelques services dont j'ai besoin en local.
Il est parfois possible, dans la configuration du service, de spécifier une interface ou adresse sur laquelle le service écoute. Ce qui permet la visibilité en local, mais pas ailleurs, sans la nécessité d'une règle de pare-feu donc (sauf si on veut filtrer en local).
Il y a eu un fil de discussion là-dessus sur cette même liste il y a quelques mois.
-- jm
Bonjour,
Le samedi 05 décembre 2015, Jean-Marc a écrit...
> Si la machine ne fait tourner *AUCUN* service un firewall n'est pas
> nécessaire.
La machine fait tourner quelques services dont j'ai besoin en local.
Il est parfois possible, dans la configuration du service, de spécifier
une interface ou adresse sur laquelle le service écoute. Ce qui permet
la visibilité en local, mais pas ailleurs, sans la nécessité d'une règle
de pare-feu donc (sauf si on veut filtrer en local).
Il y a eu un fil de discussion là-dessus sur cette même liste il y a
quelques mois.
> Si la machine ne fait tourner *AUCUN* service un firewall n'est pas > nécessaire.
La machine fait tourner quelques services dont j'ai besoin en local.
Il est parfois possible, dans la configuration du service, de spécifier une interface ou adresse sur laquelle le service écoute. Ce qui permet la visibilité en local, mais pas ailleurs, sans la nécessité d'une règle de pare-feu donc (sauf si on veut filtrer en local).
Il y a eu un fil de discussion là-dessus sur cette même liste il y a quelques mois.
-- jm
Pascal Hambourg
Jean-Michel OLTRA a écrit :
Il est parfois possible, dans la configuration du service, de spécifier une interface ou adresse sur laquelle le service écoute.
Malheureusement c'est quasiment toujours l'adresse, et pas l'interface. Même quand on spécifie une interface dans la configuration, en pratique cela revient à spécifier "l'adresse de cette interface". Or le modèle d'hôte "faible" (weak host model) appliqué par Linux permet d'utiliser l'adresse d'une interface sur n'importe quelle autre interface. On peut compter sur des effets de bords pour assurer la restriction (par exemple l'adresse n'est pas censée être routable depuis l'extérieur), mais cela revient à compter sur quelqu'un d'autre pour assurer sa sécurité. Certains services permettent aussi de spécifier les adresses sources autorisées, directement ou via le wrapper tcpd et /etc/host.allow|deny.
Au final, gérer globalement les autorisations via iptables est généralement plus radical (vraie gestion par interface réseau) et plus simple (toutes les autorisations d'accès centralisées au même endroit et gérées de la même façon).
Jean-Michel OLTRA a écrit :
Il est parfois possible, dans la configuration du service, de spécifier
une interface ou adresse sur laquelle le service écoute.
Malheureusement c'est quasiment toujours l'adresse, et pas l'interface.
Même quand on spécifie une interface dans la configuration, en pratique
cela revient à spécifier "l'adresse de cette interface". Or le modèle
d'hôte "faible" (weak host model) appliqué par Linux permet d'utiliser
l'adresse d'une interface sur n'importe quelle autre interface. On peut
compter sur des effets de bords pour assurer la restriction (par exemple
l'adresse n'est pas censée être routable depuis l'extérieur), mais cela
revient à compter sur quelqu'un d'autre pour assurer sa sécurité.
Certains services permettent aussi de spécifier les adresses sources
autorisées, directement ou via le wrapper tcpd et /etc/host.allow|deny.
Au final, gérer globalement les autorisations via iptables est
généralement plus radical (vraie gestion par interface réseau) et plus
simple (toutes les autorisations d'accès centralisées au même endroit et
gérées de la même façon).
Il est parfois possible, dans la configuration du service, de spécifier une interface ou adresse sur laquelle le service écoute.
Malheureusement c'est quasiment toujours l'adresse, et pas l'interface. Même quand on spécifie une interface dans la configuration, en pratique cela revient à spécifier "l'adresse de cette interface". Or le modèle d'hôte "faible" (weak host model) appliqué par Linux permet d'utiliser l'adresse d'une interface sur n'importe quelle autre interface. On peut compter sur des effets de bords pour assurer la restriction (par exemple l'adresse n'est pas censée être routable depuis l'extérieur), mais cela revient à compter sur quelqu'un d'autre pour assurer sa sécurité. Certains services permettent aussi de spécifier les adresses sources autorisées, directement ou via le wrapper tcpd et /etc/host.allow|deny.
Au final, gérer globalement les autorisations via iptables est généralement plus radical (vraie gestion par interface réseau) et plus simple (toutes les autorisations d'accès centralisées au même endroit et gérées de la même façon).
Pascal Hambourg
Jean-Marc a écrit :
Pour ne pas exposer les services qui tournent sur mon cubie au reste de la planète, par exemple.
D'accord.
mes interfaces comportait aussi de l'IPv6,
Il s'agit d'une IPv6 publique/globale pas d'une IP link-locale.
Donc si certains services écoutent en IPv6, le filtrage IPv6 est souhaitable, et pas seulement sur l'interface tun. A vérifier avec netstat. Autre possibilité que je me dois de mentionner à contrecoeur : si le bidule n'a pas besoin d'IPv6, le désactiver.
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Pourquoi s'embêter à filtrer sur la plage d'adresses ? L'interface suffit. Si un pirate arrive à s'introduire sur ton réseau local, nul doute qu'il prendra une adresse qui va bien dans la plage.
OK, donc accepter le trafic entrant sur eth0.
Après réflexion, je me dois de revenir sur ce point de ma réponse précédente. Il est légitime de se prémunir contre des connexions qui pourraient provenir de l'extérieur et relayées par la box internet sur le LAN, à la faveur d'une erreur de configuration par exemple.
Jean-Marc a écrit :
Pour ne pas exposer les services qui tournent sur mon cubie au reste de la planète, par exemple.
D'accord.
mes interfaces comportait aussi de l'IPv6,
Il s'agit d'une IPv6 publique/globale pas d'une IP link-locale.
Donc si certains services écoutent en IPv6, le filtrage IPv6 est
souhaitable, et pas seulement sur l'interface tun. A vérifier avec
netstat. Autre possibilité que je me dois de mentionner à contrecoeur :
si le bidule n'a pas besoin d'IPv6, le désactiver.
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Pourquoi s'embêter à filtrer sur la plage d'adresses ? L'interface
suffit. Si un pirate arrive à s'introduire sur ton réseau local, nul
doute qu'il prendra une adresse qui va bien dans la plage.
OK, donc accepter le trafic entrant sur eth0.
Après réflexion, je me dois de revenir sur ce point de ma réponse
précédente. Il est légitime de se prémunir contre des connexions qui
pourraient provenir de l'extérieur et relayées par la box internet sur
le LAN, à la faveur d'une erreur de configuration par exemple.
Pour ne pas exposer les services qui tournent sur mon cubie au reste de la planète, par exemple.
D'accord.
mes interfaces comportait aussi de l'IPv6,
Il s'agit d'une IPv6 publique/globale pas d'une IP link-locale.
Donc si certains services écoutent en IPv6, le filtrage IPv6 est souhaitable, et pas seulement sur l'interface tun. A vérifier avec netstat. Autre possibilité que je me dois de mentionner à contrecoeur : si le bidule n'a pas besoin d'IPv6, le désactiver.
-A INPUT -i eth0 -d 192.168.1.0/24 -j ACCEPT
Pourquoi s'embêter à filtrer sur la plage d'adresses ? L'interface suffit. Si un pirate arrive à s'introduire sur ton réseau local, nul doute qu'il prendra une adresse qui va bien dans la plage.
OK, donc accepter le trafic entrant sur eth0.
Après réflexion, je me dois de revenir sur ce point de ma réponse précédente. Il est légitime de se prémunir contre des connexions qui pourraient provenir de l'extérieur et relayées par la box internet sur le LAN, à la faveur d'une erreur de configuration par exemple.
Daniel Huhardeaux
Le 05/12/2015 21:18, Jean-Marc a écrit :
Sat, 5 Dec 2015 18:44:07 +0100 daniel huhardeaux écrivait :
Si la machine ne fait tourner *AUCUN* service un firewall n'est pas nécessaire.
La machine fait tourner quelques services dont j'ai besoin en local.
Et si l'ensemble du trafic passe par le VPN, une règle qui rejette tout le trafic vers l'IP publique _SAUF_ pour le port du VPN est suffisante.
Tu as un exemple ?
En supposant le VPN en udp:
iptables -A INPUT -i eth0 -p tcp -s 0.0.0.0 -d <mon ip publique> -j REJECT iptables -A INPUT -i eth0 -p udp -s 0.0.0.0 -d <mon ip publique> ! --dport <mon port VPN> -j REJECT
-- Daniel Huhardeaux + sip: + tootaiNET
Le 05/12/2015 21:18, Jean-Marc a écrit :
Sat, 5 Dec 2015 18:44:07 +0100
daniel huhardeaux <no-spam@tootai.net> écrivait :
Si la machine ne fait tourner *AUCUN* service un firewall n'est pas
nécessaire.
La machine fait tourner quelques services dont j'ai besoin en local.
Et si l'ensemble du trafic passe par le VPN, une règle qui
rejette tout le trafic vers l'IP publique _SAUF_ pour le port du VPN est
suffisante.
Tu as un exemple ?
En supposant le VPN en udp:
iptables -A INPUT -i eth0 -p tcp -s 0.0.0.0 -d <mon ip publique> -j REJECT
iptables -A INPUT -i eth0 -p udp -s 0.0.0.0 -d <mon ip publique> !
--dport <mon port VPN> -j REJECT
--
Daniel Huhardeaux
+33.368460088@tootai.net sip:820@sip.tootai.net
+48.222472472@tootai.net tootaiNET
