Bonjour,
Voilà je viens d'acquérir Apple Remote Desktop 3 pour administrer des
clients sur internet mais le souci c'est que ARD les reconnais comme
des clients VNC ce qui m'empeche de faire quoi que ce soit dessus
(envoyer des fichiers, des messages, etc...)! Pourtan tout est
configuré nickel autant chez moi que chez eux. De plus ce sont des ordi
avec Tiger 10.4.6 et chez moi le version s'affiche même pas...
Une idée?
Merci!
--
"Earth is 98% full ... please delete anyone you can."
In article <1hhe2b3.wjp3zv1mr4og0N%, (Nicolas MICHEL) wrote:
Donc on est bien d'accord. Un FW ne sert à protéger ni ce qui est ouvert, ni ce qui est fermé, mais ce qui est "ouvert mais" ou ce qui est "fermé mais" :)
voilà, mais on parle bien d'un firewall de base, pas d'un firewall applicatif (d'application).
La faille php en question pourrait aussi faire autre chose que d'ouvrir un backdor. Mais c'est une bonne raison quand-même. Bloquer les ports inutilisés permet d'éviter un usage à l'inssu de ton plein gré.
le php c'est un exemple, tu peux faire pareil avec tous les démons qui sortent par des ports connus à l'avance (mysqld, ntpd,...).
Sauf que ça ne réponds pas à ma question, en fait. Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Par exemple quand un type se présente depuis l'extérieur de ton réseau avec une IP interne (spoofing). Comme on restreint les services interne avec des plages IP, bernique. En fait c'est la seule règle usuelle que je conaisse mais je sais qu'il y en a d'autres, comme s'abonner à une blacklist d'IP, ou bloquer les paquets IP fragmentés. J'ai une assez bonne doc pour IPtables, mais pas pour IPFW. C'est là l'objet de ma question :)
si tu veux mon avis, pour le commun des mortels ce sont des risques bien légers. Très souvent le problème vient de l'intérieur :)
patpro
-- http://www.patpro.net/
In article <1hhe2b3.wjp3zv1mr4og0N%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:
Donc on est bien d'accord. Un FW ne sert à protéger ni ce qui est
ouvert, ni ce qui est fermé, mais ce qui est "ouvert mais" ou ce qui est
"fermé mais" :)
voilà, mais on parle bien d'un firewall de base, pas d'un firewall
applicatif (d'application).
La faille php en question pourrait aussi faire autre chose que d'ouvrir
un backdor. Mais c'est une bonne raison quand-même. Bloquer les ports
inutilisés permet d'éviter un usage à l'inssu de ton plein gré.
le php c'est un exemple, tu peux faire pareil avec tous les démons qui
sortent par des ports connus à l'avance (mysqld, ntpd,...).
Sauf que ça ne réponds pas à ma question, en fait.
Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Par exemple quand un type se présente depuis l'extérieur de ton réseau
avec une IP interne (spoofing). Comme on restreint les services interne
avec des plages IP, bernique. En fait c'est la seule règle usuelle que
je conaisse mais je sais qu'il y en a d'autres, comme s'abonner à une
blacklist d'IP, ou bloquer les paquets IP fragmentés.
J'ai une assez bonne doc pour IPtables, mais pas pour IPFW.
C'est là l'objet de ma question :)
si tu veux mon avis, pour le commun des mortels ce sont des risques bien
légers. Très souvent le problème vient de l'intérieur :)
In article <1hhe2b3.wjp3zv1mr4og0N%, (Nicolas MICHEL) wrote:
Donc on est bien d'accord. Un FW ne sert à protéger ni ce qui est ouvert, ni ce qui est fermé, mais ce qui est "ouvert mais" ou ce qui est "fermé mais" :)
voilà, mais on parle bien d'un firewall de base, pas d'un firewall applicatif (d'application).
La faille php en question pourrait aussi faire autre chose que d'ouvrir un backdor. Mais c'est une bonne raison quand-même. Bloquer les ports inutilisés permet d'éviter un usage à l'inssu de ton plein gré.
le php c'est un exemple, tu peux faire pareil avec tous les démons qui sortent par des ports connus à l'avance (mysqld, ntpd,...).
Sauf que ça ne réponds pas à ma question, en fait. Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Par exemple quand un type se présente depuis l'extérieur de ton réseau avec une IP interne (spoofing). Comme on restreint les services interne avec des plages IP, bernique. En fait c'est la seule règle usuelle que je conaisse mais je sais qu'il y en a d'autres, comme s'abonner à une blacklist d'IP, ou bloquer les paquets IP fragmentés. J'ai une assez bonne doc pour IPtables, mais pas pour IPFW. C'est là l'objet de ma question :)
si tu veux mon avis, pour le commun des mortels ce sont des risques bien légers. Très souvent le problème vient de l'intérieur :)
patpro
-- http://www.patpro.net/
patpro ~ Patrick Proniewski
In article <1hhe21p.177gghz1o8r9vkN%, (FiLH) wrote:
Comme ça, même si un neuneu fait du php comme un cochon et qu'un hacker parvient à poster sur le serveur un script ou un programme et qu'il arrive a le lancer, le programme est incapable de se connecter à l'extérieur (et donc il ne peut pas poster du spam, hacker d'autres machine, servir de bounce...)
Heu... et comment ils postent les scripts php ? Mais c'est presque une idée.. :)
les utilisateurs ? sur leur compte ftp en général :) pour les failles de php, ou des scripts php mal codés, on peut pas toujours tout verrouiller.
patpro
-- http://www.patpro.net/
In article <1hhe21p.177gghz1o8r9vkN%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
Comme ça, même si un neuneu fait du php comme un cochon et qu'un hacker
parvient à poster sur le serveur un script ou un programme et qu'il
arrive a le lancer, le programme est incapable de se connecter à
l'extérieur (et donc il ne peut pas poster du spam, hacker d'autres
machine, servir de bounce...)
Heu... et comment ils postent les scripts php ? Mais c'est presque une
idée.. :)
les utilisateurs ? sur leur compte ftp en général :)
pour les failles de php, ou des scripts php mal codés, on peut pas
toujours tout verrouiller.
In article <1hhe21p.177gghz1o8r9vkN%, (FiLH) wrote:
Comme ça, même si un neuneu fait du php comme un cochon et qu'un hacker parvient à poster sur le serveur un script ou un programme et qu'il arrive a le lancer, le programme est incapable de se connecter à l'extérieur (et donc il ne peut pas poster du spam, hacker d'autres machine, servir de bounce...)
Heu... et comment ils postent les scripts php ? Mais c'est presque une idée.. :)
les utilisateurs ? sur leur compte ftp en général :) pour les failles de php, ou des scripts php mal codés, on peut pas toujours tout verrouiller.
patpro
-- http://www.patpro.net/
Nicolas.MICHEL
patpro ~ Patrick Proniewski wrote:
voilà, mais on parle bien d'un firewall de base, pas d'un firewall applicatif (d'application).
Oui.
le php c'est un exemple, tu peux faire pareil avec tous les démons qui sortent par des ports connus à l'avance (mysqld, ntpd,...).
S'il y a des failles de sécurité je comprends. Sinon je vois mal comment tu peux demander à mysqld d'ouvrir le port 80.
Sauf que ça ne réponds pas à ma question, en fait. Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Est-tu normand ? ;-)
Bon, pas grave, si un jour je trouve une bonne doc je vous en ferai profiter.
si tu veux mon avis, pour le commun des mortels ce sont des risques bien légers. Très souvent le problème vient de l'intérieur :)
Ici on est attaqué environ 20 fois par an, sans parler des virus. Sur nos PC windows on a évité déjà quelques worms avec de simples règles IP. Donc oui, les problèmes peuvent venir de l'intérieur, mais pas que.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
voilà, mais on parle bien d'un firewall de base, pas d'un firewall
applicatif (d'application).
Oui.
le php c'est un exemple, tu peux faire pareil avec tous les démons qui
sortent par des ports connus à l'avance (mysqld, ntpd,...).
S'il y a des failles de sécurité je comprends.
Sinon je vois mal comment tu peux demander à mysqld d'ouvrir le port 80.
Sauf que ça ne réponds pas à ma question, en fait.
Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Est-tu normand ? ;-)
Bon, pas grave, si un jour je trouve une bonne doc je vous en ferai
profiter.
si tu veux mon avis, pour le commun des mortels ce sont des risques bien
légers. Très souvent le problème vient de l'intérieur :)
Ici on est attaqué environ 20 fois par an, sans parler des virus.
Sur nos PC windows on a évité déjà quelques worms avec de simples règles
IP. Donc oui, les problèmes peuvent venir de l'intérieur, mais pas que.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
voilà, mais on parle bien d'un firewall de base, pas d'un firewall applicatif (d'application).
Oui.
le php c'est un exemple, tu peux faire pareil avec tous les démons qui sortent par des ports connus à l'avance (mysqld, ntpd,...).
S'il y a des failles de sécurité je comprends. Sinon je vois mal comment tu peux demander à mysqld d'ouvrir le port 80.
Sauf que ça ne réponds pas à ma question, en fait. Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Est-tu normand ? ;-)
Bon, pas grave, si un jour je trouve une bonne doc je vous en ferai profiter.
si tu veux mon avis, pour le commun des mortels ce sont des risques bien légers. Très souvent le problème vient de l'intérieur :)
Ici on est attaqué environ 20 fois par an, sans parler des virus. Sur nos PC windows on a évité déjà quelques worms avec de simples règles IP. Donc oui, les problèmes peuvent venir de l'intérieur, mais pas que.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
patpro ~ patrick proniewski
In article <1hhe837.vi9z0kjb3mcmN%, (Nicolas MICHEL) wrote:
S'il y a des failles de sécurité je comprends. Sinon je vois mal comment tu peux demander à mysqld d'ouvrir le port 80.
dès l'instant ou ton démon à des problèmes du genre buffer overflow, tu peux t'attendre à le voir faire à peut prêt n'importe quoi. Par ailleurs, il est exclu que mysql ouvre le port 80, à moins de faire tourner mysql en root et qu'aucun autre process n'utilise déjà le port 80 :)
Sauf que ça ne réponds pas à ma question, en fait. Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Est-tu normand ? ;-)
ha ! tu veux donc qu'on te donne les commandes IPFW à coller sur ta machine ? man ipfw ;)
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw .html> et pomme-f uid
patpro
-- http://www.patpro.net/
In article <1hhe837.vi9z0kjb3mcmN%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:
S'il y a des failles de sécurité je comprends.
Sinon je vois mal comment tu peux demander à mysqld d'ouvrir le port 80.
dès l'instant ou ton démon à des problèmes du genre buffer overflow, tu
peux t'attendre à le voir faire à peut prêt n'importe quoi. Par
ailleurs, il est exclu que mysql ouvre le port 80, à moins de faire
tourner mysql en root et qu'aucun autre process n'utilise déjà le port
80 :)
Sauf que ça ne réponds pas à ma question, en fait.
Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Est-tu normand ? ;-)
ha ! tu veux donc qu'on te donne les commandes IPFW à coller sur ta
machine ? man ipfw ;)
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw
.html> et pomme-f uid
In article <1hhe837.vi9z0kjb3mcmN%, (Nicolas MICHEL) wrote:
S'il y a des failles de sécurité je comprends. Sinon je vois mal comment tu peux demander à mysqld d'ouvrir le port 80.
dès l'instant ou ton démon à des problèmes du genre buffer overflow, tu peux t'attendre à le voir faire à peut prêt n'importe quoi. Par ailleurs, il est exclu que mysql ouvre le port 80, à moins de faire tourner mysql en root et qu'aucun autre process n'utilise déjà le port 80 :)
Sauf que ça ne réponds pas à ma question, en fait. Ce que je demandais c'est quelles sont les règles à mettre en plus.
ce sont des rêgles à mettre en plus.
Est-tu normand ? ;-)
ha ! tu veux donc qu'on te donne les commandes IPFW à coller sur ta machine ? man ipfw ;)
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw .html> et pomme-f uid
patpro
-- http://www.patpro.net/
Nicolas.MICHEL
patpro ~ patrick proniewski wrote:
Est-tu normand ? ;-)
ha ! tu veux donc qu'on te donne les commandes IPFW à coller sur ta machine ? man ipfw ;)
Sauf que ça ne t'indiques pas quoi faire mais juste comment :)
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw .html> et pomme-f uid
Cool ! Merci :)
Je lirai ça lundi avec beaucoup d'intérêt. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Est-tu normand ? ;-)
ha ! tu veux donc qu'on te donne les commandes IPFW à coller sur ta
machine ? man ipfw ;)
Sauf que ça ne t'indiques pas quoi faire mais juste comment :)
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw
.html> et pomme-f uid
Cool !
Merci :)
Je lirai ça lundi avec beaucoup d'intérêt.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
