On Wed, 03 May 2006 13:45:39 +0000, Stephane Catteau wrote:
Cela dit, ce sont des requêtes simples à filtrer. Deux serveurs NTP sont suffisants, même chose pour les requêtes DNS, et il n'y a besoin que d'un serveur SMTP. Pour pouvoir exploiter l'une de ces portes de sortie, l'attaquant devra d'abord avoir compromis le serveur qui se trouve à l'autre bout, ce qui limite grandement leur intérêt.
Si j'ai un flux autorisé depuis une machine compromise vers un serveur SMTP quelconque, je peux considérer que je saurais me faire remonter de l'info sans hacker le serveur SMTP. En m'envoyant des mails ...
Idem avec un serveur DNS, en faisant des requêtes qui vont bien sur un domaine contrôlé par l'attaquant. Laborieux mais faisable. En revanche ça risque d'être moins facile avec un serveur NTP. ;-)
On Wed, 03 May 2006 13:45:39 +0000, Stephane Catteau wrote:
Cela dit, ce sont des requêtes simples à filtrer. Deux serveurs NTP
sont suffisants, même chose pour les requêtes DNS, et il n'y a besoin
que d'un serveur SMTP. Pour pouvoir exploiter l'une de ces portes de
sortie, l'attaquant devra d'abord avoir compromis le serveur qui se trouve
à l'autre bout, ce qui limite grandement leur intérêt.
Si j'ai un flux autorisé depuis une machine compromise vers un serveur
SMTP quelconque, je peux considérer que je saurais me faire remonter de
l'info sans hacker le serveur SMTP. En m'envoyant des mails ...
Idem avec un serveur DNS, en faisant des requêtes qui vont bien sur un
domaine contrôlé par l'attaquant. Laborieux mais faisable. En revanche
ça risque d'être moins facile avec un serveur NTP. ;-)
On Wed, 03 May 2006 13:45:39 +0000, Stephane Catteau wrote:
Cela dit, ce sont des requêtes simples à filtrer. Deux serveurs NTP sont suffisants, même chose pour les requêtes DNS, et il n'y a besoin que d'un serveur SMTP. Pour pouvoir exploiter l'une de ces portes de sortie, l'attaquant devra d'abord avoir compromis le serveur qui se trouve à l'autre bout, ce qui limite grandement leur intérêt.
Si j'ai un flux autorisé depuis une machine compromise vers un serveur SMTP quelconque, je peux considérer que je saurais me faire remonter de l'info sans hacker le serveur SMTP. En m'envoyant des mails ...
Idem avec un serveur DNS, en faisant des requêtes qui vont bien sur un domaine contrôlé par l'attaquant. Laborieux mais faisable. En revanche ça risque d'être moins facile avec un serveur NTP. ;-)
Kevin Denis
Le 03-05-2006, Pascal Hambourg a écrit :
Aussi je vois un inconvénient au pont filtrant : s'il n'a pas d'adresse IP, il ne peut pas faire de REJECT avec envoi d'un ICMP Destination Unreachable quelconque mais seulement du filtrage "tout ou rien" ACCEPT/DROP.
Depuis un pont filtrant, je ne vois pas techniquement le probleme:
si le paquet a pour destination A.B.C.D port xx, dropper le paquet et renvoyer un paquet ayant comme source A.B.C.D a l'initiateur de la connexion.
-- Kevin
Le 03-05-2006, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Aussi je vois un inconvénient au pont filtrant : s'il n'a pas d'adresse
IP, il ne peut pas faire de REJECT avec envoi d'un ICMP Destination
Unreachable quelconque mais seulement du filtrage "tout ou rien"
ACCEPT/DROP.
Depuis un pont filtrant, je ne vois pas techniquement le probleme:
si le paquet a pour destination A.B.C.D port xx, dropper le paquet
et renvoyer un paquet ayant comme source A.B.C.D a l'initiateur de
la connexion.
Aussi je vois un inconvénient au pont filtrant : s'il n'a pas d'adresse IP, il ne peut pas faire de REJECT avec envoi d'un ICMP Destination Unreachable quelconque mais seulement du filtrage "tout ou rien" ACCEPT/DROP.
Depuis un pont filtrant, je ne vois pas techniquement le probleme:
si le paquet a pour destination A.B.C.D port xx, dropper le paquet et renvoyer un paquet ayant comme source A.B.C.D a l'initiateur de la connexion.
-- Kevin
Eric Lalitte
"Malebe" wrote in message news:
Bon après réflexion, voici mon plan d'attaque: Je vais investir dans une soekris net4801 pour le nat/ipfilter Je vais peut etre re-investir dans une net4801 pour Squid/squidGuard (pauvres gamins..) mais la je me pose la question des 128 Mbyte SDRAM seront-elles suffisantes ??? (ceci dit, je ne vais pas stocker le cache, c'est juste un filtrage de contenu) Pour le reste j'y vois assez clair.
Je ne pense pas, du moins ça dépend de la taille des fichiers de filtrage que tu veux utiliser. Nous avons testé avec un net4801 et ça ramait pas mal, nous avons simplement réduit fortement les règles de filtrage et ça devient très correct.
Si tu as le courage d'attendre, nous sortons une distribution basée sur debian qui sera embarquée sur un soekris net4801 avec tous les outils système et réseau nécessaires à un hébergement, d'ici le mois de juillet.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Malebe" <malebe@anti.spam> wrote in message
news:slrne5i2ab.u5.malebe@kipix.geodata.name
Bon après réflexion, voici mon plan d'attaque:
Je vais investir dans une soekris net4801 pour le nat/ipfilter
Je vais peut etre re-investir dans une net4801 pour Squid/squidGuard (pauvres
gamins..)
mais la je me pose la question des 128 Mbyte SDRAM seront-elles suffisantes ???
(ceci dit, je ne vais pas stocker le cache, c'est juste un filtrage de contenu)
Pour le reste j'y vois assez clair.
Je ne pense pas, du moins ça dépend de la taille des fichiers de
filtrage que tu veux utiliser.
Nous avons testé avec un net4801 et ça ramait pas mal, nous avons
simplement réduit fortement les règles de filtrage et ça devient très
correct.
Si tu as le courage d'attendre, nous sortons une distribution basée sur
debian qui sera embarquée sur un soekris net4801 avec tous les outils
système et réseau nécessaires à un hébergement, d'ici le mois de
juillet.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Bon après réflexion, voici mon plan d'attaque: Je vais investir dans une soekris net4801 pour le nat/ipfilter Je vais peut etre re-investir dans une net4801 pour Squid/squidGuard (pauvres gamins..) mais la je me pose la question des 128 Mbyte SDRAM seront-elles suffisantes ??? (ceci dit, je ne vais pas stocker le cache, c'est juste un filtrage de contenu) Pour le reste j'y vois assez clair.
Je ne pense pas, du moins ça dépend de la taille des fichiers de filtrage que tu veux utiliser. Nous avons testé avec un net4801 et ça ramait pas mal, nous avons simplement réduit fortement les règles de filtrage et ça devient très correct.
Si tu as le courage d'attendre, nous sortons une distribution basée sur debian qui sera embarquée sur un soekris net4801 avec tous les outils système et réseau nécessaires à un hébergement, d'ici le mois de juillet.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Stephane Catteau
Nicob n'était pas loin de dire :
Cela dit, ce sont des requêtes simples à filtrer. Deux serveurs NTP sont suffisants, même chose pour les requêtes DNS, et il n'y a besoin que d'un serveur SMTP. Pour pouvoir exploiter l'une de ces portes de sortie, l'attaquant devra d'abord avoir compromis le serveur qui se trouve à l'autre bout, ce qui limite grandement leur intérêt.
Si j'ai un flux autorisé depuis une machine compromise vers un serveur SMTP quelconque, je peux considérer que je saurais me faire remonter de l'info sans hacker le serveur SMTP. En m'envoyant des mails ...
Vi vi, on se relit, on rajoute un truc que l'on avait oublié, et on oublie de se relire après, du coup on dit des bétises :-( En l'occurence le port 25 n'est pas ouvert en grand, mais vers les seuls MX du domaine sur lequel on envoie les mails, si tant est que l'on décide de les envoyer. Evidement, éviter comme la peste les grands FAI/FSI. Le risque persiste, mais les chances pour que l'attaquant ait un compte mail derrière le même MX que nous sont suffisement minces pour le limiter.
Nicob n'était pas loin de dire :
Cela dit, ce sont des requêtes simples à filtrer. Deux serveurs NTP
sont suffisants, même chose pour les requêtes DNS, et il n'y a besoin
que d'un serveur SMTP. Pour pouvoir exploiter l'une de ces portes de
sortie, l'attaquant devra d'abord avoir compromis le serveur qui se trouve
à l'autre bout, ce qui limite grandement leur intérêt.
Si j'ai un flux autorisé depuis une machine compromise vers un serveur
SMTP quelconque, je peux considérer que je saurais me faire remonter de
l'info sans hacker le serveur SMTP. En m'envoyant des mails ...
Vi vi, on se relit, on rajoute un truc que l'on avait oublié, et on
oublie de se relire après, du coup on dit des bétises :-(
En l'occurence le port 25 n'est pas ouvert en grand, mais vers les
seuls MX du domaine sur lequel on envoie les mails, si tant est que
l'on décide de les envoyer. Evidement, éviter comme la peste les grands
FAI/FSI. Le risque persiste, mais les chances pour que l'attaquant ait
un compte mail derrière le même MX que nous sont suffisement minces
pour le limiter.
Cela dit, ce sont des requêtes simples à filtrer. Deux serveurs NTP sont suffisants, même chose pour les requêtes DNS, et il n'y a besoin que d'un serveur SMTP. Pour pouvoir exploiter l'une de ces portes de sortie, l'attaquant devra d'abord avoir compromis le serveur qui se trouve à l'autre bout, ce qui limite grandement leur intérêt.
Si j'ai un flux autorisé depuis une machine compromise vers un serveur SMTP quelconque, je peux considérer que je saurais me faire remonter de l'info sans hacker le serveur SMTP. En m'envoyant des mails ...
Vi vi, on se relit, on rajoute un truc que l'on avait oublié, et on oublie de se relire après, du coup on dit des bétises :-( En l'occurence le port 25 n'est pas ouvert en grand, mais vers les seuls MX du domaine sur lequel on envoie les mails, si tant est que l'on décide de les envoyer. Evidement, éviter comme la peste les grands FAI/FSI. Le risque persiste, mais les chances pour que l'attaquant ait un compte mail derrière le même MX que nous sont suffisement minces pour le limiter.
