Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
imaginons une structure "classique":
Internet---FW linux---LAN
Pour l'exemple, le FW est basique: en gros, seulement de la
masquerade (ou a peine plus evolue).
Le FW peut laisser la possibilite de sortir en dport 25 pour
utiliser le smtp du FAI ou n'importe quel autre smtp. Le FW
autorise le LAN a faire des requetes DNS (pas de dnsmasq, ni
de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP
pour envoyer du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des
listes d'adresses a spammer et le mail a envoyer, puis font leur requetes
MX, puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les
requetes DNS de type MX, ca permet d'eviter d'arroser l'internet entier
de courrier non sollicite, le temps de corriger le probleme.
(Bien, sur, cette methode vient en complement de tout le reste (AV,
FW perso sur les machines, lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
je crois que l'on peut faire du pattern-matching avec iptables, mais
quelle pattern me detecte a coup sur et uniquement les requetes MX?
Ethereal me montre en octet 67 et 68 0x00 0x0f, est-ce discriminant?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux iptables), je m'interrogeais sur la possibilite de filtrer certains flux specifiques. [interdire les flux DNS MX]
Bon, suite aux reponses, j'en retiens:
1. Le fait de filtrer les requetes DNS MX ne parait pas interessant. Il faut interdire le tpc 25 en dport.
2. Au sujet du filtrage par pattern d'iptables, personne n'a une idee? (pour le flux DNS MX ou n'importe quoi) un genre de iptables -A CHAIN -m match --byte 23 = 0x08 --byte 124 = 0x00 -j RULE etc..
voir meme: iptables -A CHAIN -m match --bit 23 = 1 -j RULE .. -- Kevin
Le 04-08-2005, Kevin Denis <kevin@nowhere.invalid> a écrit :
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
[interdire les flux DNS MX]
Bon, suite aux reponses, j'en retiens:
1. Le fait de filtrer les requetes DNS MX ne parait pas interessant. Il
faut interdire le tpc 25 en dport.
2. Au sujet du filtrage par pattern d'iptables, personne n'a une idee?
(pour le flux DNS MX ou n'importe quoi)
un genre de
iptables -A CHAIN -m match --byte 23 = 0x08 --byte 124 = 0x00 -j RULE etc..
voir meme:
iptables -A CHAIN -m match --bit 23 = 1 -j RULE ..
--
Kevin
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux iptables), je m'interrogeais sur la possibilite de filtrer certains flux specifiques. [interdire les flux DNS MX]
Bon, suite aux reponses, j'en retiens:
1. Le fait de filtrer les requetes DNS MX ne parait pas interessant. Il faut interdire le tpc 25 en dport.
2. Au sujet du filtrage par pattern d'iptables, personne n'a une idee? (pour le flux DNS MX ou n'importe quoi) un genre de iptables -A CHAIN -m match --byte 23 = 0x08 --byte 124 = 0x00 -j RULE etc..
voir meme: iptables -A CHAIN -m match --bit 23 = 1 -j RULE .. -- Kevin
Kevin Denis
Le 04-08-2005, Kevin Denis a écrit :
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux iptables), je m'interrogeais sur la possibilite de filtrer certains flux specifiques. [flux DNS MX]
Bon, apres lecture des posts, j'en retiens que:
1. Le filtrage des requetes MX apparait comme largement superflu. Le filtrage par SMTP en destination fait le boulot, et ca suffit. Ok, restons la dessus.
2. Techniquement, est-ce qu'iptables peut faire du pattern matching? un genre de: iptables -A CHAIN -m match --byte 23=0x0A -j JUMP j'ai regarde rapidement l7-filter, est-ce plus approprie?
-- Kevin
Le 04-08-2005, Kevin Denis <kevin@nowhere.invalid> a écrit :
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques. [flux DNS MX]
Bon, apres lecture des posts, j'en retiens que:
1. Le filtrage des requetes MX apparait comme largement superflu. Le
filtrage par SMTP en destination fait le boulot, et ca suffit. Ok,
restons la dessus.
2. Techniquement, est-ce qu'iptables peut faire du pattern matching?
un genre de:
iptables -A CHAIN -m match --byte 23=0x0A -j JUMP
j'ai regarde rapidement l7-filter, est-ce plus approprie?
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux iptables), je m'interrogeais sur la possibilite de filtrer certains flux specifiques. [flux DNS MX]
Bon, apres lecture des posts, j'en retiens que:
1. Le filtrage des requetes MX apparait comme largement superflu. Le filtrage par SMTP en destination fait le boulot, et ca suffit. Ok, restons la dessus.
2. Techniquement, est-ce qu'iptables peut faire du pattern matching? un genre de: iptables -A CHAIN -m match --byte 23=0x0A -j JUMP j'ai regarde rapidement l7-filter, est-ce plus approprie?
-- Kevin
Kevin Denis
Le 05-08-2005, Dominique Blas a écrit :
Il n'y a AUCUNE RAISON, dans une entreprise classique, pour qu'un poste interne expédie DIRECTEMENT et des requêtes DNS
hurler ne cachera pas l'ineptie de ce commentaire. Quelle difference
entre une requete DNS directe ou indirecte? (attention, je ne parle pas d'un port 53 ouvert en dst qui autorise n'importe quel tunnel trivial, mais bien d'un port 53 ouvert uniquement vers les DNS du FAI, des DNS duement autorises, ou ferme avec comme seule possibilite d'utiliser le DNS cache local qui est le seul a avoir le droit de sortir)
et des flux SMTP !
Il semblerait qu'un consensus regne autour de ce point.
Par ailleurs il est conseillé de << blinder >> son DNS afin d'éviter que de malins cheveaux de Troie et autres spywares n'abusent des canaux DNS cachés.
blinder son DNS. Mais bien sur. Est-ce que tu sais au moins de quoi tu parles? Donne moi un exemple _concret_ de mise en place d'un DNS blinde qui m'interdise de faire (au hasard) du chat over DNS [1]?
Je veux du concret, hein, pas de phrases en l'air du genre "il vaut mieux" j'ai lu que, yaka, faukon, etc..
<snip le blabla qui brasse de l'air pour pas grand chose>
[1] exemple de chat unidirectionnel simple a lancer et extremement dur a interdire:
soit le pseudo serveur dns.pl: #! /usr/bin/perl
use strict; use Socket;
my $adresse_srv = ""; my $port_srv = 53; my $protocole_srv = "udp";
my $proto = getprotobyname ($protocole_srv); $proto = getprotobynumber ($protocole_srv) unless defined ($proto); die "Protocole : $!n" unless (defined ($proto));
my $port = $port_srv if ($port_srv !~ /D/); $port = getservbyname ($port_srv, $proto) unless (defined ($port)); die "Service : $!n" unless (defined ($port));
socket SOCK, PF_INET, SOCK_DGRAM, $proto or die "socket: $!n"; bind (SOCK, sockaddr_in ($port,$adr)) or die "bind : $!n";
while (1) { my $chaine; my $emetteur = recv SOCK, $chaine, 1024, 0 or last; ($port, $adr) = unpack_sockaddr_in $emetteur; print "Message depuis ". inet_ntoa ($adr) .", port $portn"; print $chaine; }
Il suffit que ce pseudo serveur DNS soit lance et reference comme servant une zone, au hasard gloup.dyndns.org
N'importe qui sur l'internet peut me dire bonjour en tapant: host bonjour.gloup.dyndns.org depuis un terminal, une barre d'adresse d'un navigateur web ou n'importe quoi. J'ai bien son message qui arrive chez moi.
Maintenant, parle moi de <<blinder>> le DNS pour empecher un zozo de ton reseau d'envoyer de l'info par ce biais. Ca, ca m'interesse.
PS: pour realiser un veritable chat, il suffit que le client envoie des requetes avec un numero de sequence[2]. Le serveur affiche le message. Le serveur repond en utilisant les 4 octets servant a donner l'adresse IP. (les 3 premiers octets envoient de l'info, le 4e sert au controle)
[2]: pour etre sur d'avoir des requetes DNS differentes, sinon un DNS sur le chemin resservira la reponse precedente. [3]: qui veut le chat_server_dns.pl et chat_client_dns.pl ?
-- Kevin
Le 05-08-2005, Dominique Blas <db@internet.invalid> a écrit :
Il n'y a AUCUNE RAISON, dans une entreprise classique, pour qu'un poste
interne expédie DIRECTEMENT et des requêtes DNS
hurler ne cachera pas l'ineptie de ce commentaire. Quelle difference
entre une requete DNS directe ou indirecte?
(attention, je ne parle pas d'un port 53 ouvert en dst qui autorise
n'importe quel tunnel trivial, mais bien d'un port 53 ouvert uniquement
vers les DNS du FAI, des DNS duement autorises, ou ferme avec comme
seule possibilite d'utiliser le DNS cache local qui est le seul a avoir
le droit de sortir)
et des flux SMTP !
Il semblerait qu'un consensus regne autour de ce point.
Par ailleurs il est conseillé de << blinder >> son DNS afin d'éviter que
de malins cheveaux de Troie et autres spywares n'abusent des canaux DNS
cachés.
blinder son DNS. Mais bien sur. Est-ce que tu sais au moins de quoi
tu parles? Donne moi un exemple _concret_ de mise en place d'un DNS
blinde qui m'interdise de faire (au hasard) du chat over DNS [1]?
Je veux du concret, hein, pas de phrases en l'air du genre "il vaut mieux"
j'ai lu que, yaka, faukon, etc..
<snip le blabla qui brasse de l'air pour pas grand chose>
[1] exemple de chat unidirectionnel simple a lancer et extremement dur
a interdire:
soit le pseudo serveur dns.pl:
#! /usr/bin/perl
use strict;
use Socket;
my $adresse_srv = "";
my $port_srv = 53;
my $protocole_srv = "udp";
my $proto = getprotobyname ($protocole_srv);
$proto = getprotobynumber ($protocole_srv) unless defined ($proto);
die "Protocole : $!n" unless (defined ($proto));
my $port = $port_srv if ($port_srv !~ /D/);
$port = getservbyname ($port_srv, $proto) unless (defined ($port));
die "Service : $!n" unless (defined ($port));
socket SOCK, PF_INET, SOCK_DGRAM, $proto or die "socket: $!n";
bind (SOCK, sockaddr_in ($port,$adr)) or die "bind : $!n";
while (1) {
my $chaine;
my $emetteur = recv SOCK, $chaine, 1024, 0 or last;
($port, $adr) = unpack_sockaddr_in $emetteur;
print "Message depuis ". inet_ntoa ($adr) .", port $portn";
print $chaine;
}
Il suffit que ce pseudo serveur DNS soit lance et reference comme
servant une zone, au hasard gloup.dyndns.org
N'importe qui sur l'internet peut me dire bonjour en tapant:
host bonjour.gloup.dyndns.org
depuis un terminal, une barre d'adresse d'un navigateur web ou
n'importe quoi. J'ai bien son message qui arrive chez moi.
Maintenant, parle moi de <<blinder>> le DNS pour empecher un zozo
de ton reseau d'envoyer de l'info par ce biais.
Ca, ca m'interesse.
PS: pour realiser un veritable chat, il suffit que le client
envoie des requetes avec un numero de sequence[2]. Le serveur affiche
le message. Le serveur repond en utilisant les 4 octets servant a
donner l'adresse IP. (les 3 premiers octets envoient de l'info, le
4e sert au controle)
[2]: pour etre sur d'avoir des requetes DNS differentes, sinon un
DNS sur le chemin resservira la reponse precedente.
[3]: qui veut le chat_server_dns.pl et chat_client_dns.pl ?
Il n'y a AUCUNE RAISON, dans une entreprise classique, pour qu'un poste interne expédie DIRECTEMENT et des requêtes DNS
hurler ne cachera pas l'ineptie de ce commentaire. Quelle difference
entre une requete DNS directe ou indirecte? (attention, je ne parle pas d'un port 53 ouvert en dst qui autorise n'importe quel tunnel trivial, mais bien d'un port 53 ouvert uniquement vers les DNS du FAI, des DNS duement autorises, ou ferme avec comme seule possibilite d'utiliser le DNS cache local qui est le seul a avoir le droit de sortir)
et des flux SMTP !
Il semblerait qu'un consensus regne autour de ce point.
Par ailleurs il est conseillé de << blinder >> son DNS afin d'éviter que de malins cheveaux de Troie et autres spywares n'abusent des canaux DNS cachés.
blinder son DNS. Mais bien sur. Est-ce que tu sais au moins de quoi tu parles? Donne moi un exemple _concret_ de mise en place d'un DNS blinde qui m'interdise de faire (au hasard) du chat over DNS [1]?
Je veux du concret, hein, pas de phrases en l'air du genre "il vaut mieux" j'ai lu que, yaka, faukon, etc..
<snip le blabla qui brasse de l'air pour pas grand chose>
[1] exemple de chat unidirectionnel simple a lancer et extremement dur a interdire:
soit le pseudo serveur dns.pl: #! /usr/bin/perl
use strict; use Socket;
my $adresse_srv = ""; my $port_srv = 53; my $protocole_srv = "udp";
my $proto = getprotobyname ($protocole_srv); $proto = getprotobynumber ($protocole_srv) unless defined ($proto); die "Protocole : $!n" unless (defined ($proto));
my $port = $port_srv if ($port_srv !~ /D/); $port = getservbyname ($port_srv, $proto) unless (defined ($port)); die "Service : $!n" unless (defined ($port));
socket SOCK, PF_INET, SOCK_DGRAM, $proto or die "socket: $!n"; bind (SOCK, sockaddr_in ($port,$adr)) or die "bind : $!n";
while (1) { my $chaine; my $emetteur = recv SOCK, $chaine, 1024, 0 or last; ($port, $adr) = unpack_sockaddr_in $emetteur; print "Message depuis ". inet_ntoa ($adr) .", port $portn"; print $chaine; }
Il suffit que ce pseudo serveur DNS soit lance et reference comme servant une zone, au hasard gloup.dyndns.org
N'importe qui sur l'internet peut me dire bonjour en tapant: host bonjour.gloup.dyndns.org depuis un terminal, une barre d'adresse d'un navigateur web ou n'importe quoi. J'ai bien son message qui arrive chez moi.
Maintenant, parle moi de <<blinder>> le DNS pour empecher un zozo de ton reseau d'envoyer de l'info par ce biais. Ca, ca m'interesse.
PS: pour realiser un veritable chat, il suffit que le client envoie des requetes avec un numero de sequence[2]. Le serveur affiche le message. Le serveur repond en utilisant les 4 octets servant a donner l'adresse IP. (les 3 premiers octets envoient de l'info, le 4e sert au controle)
[2]: pour etre sur d'avoir des requetes DNS differentes, sinon un DNS sur le chemin resservira la reponse precedente. [3]: qui veut le chat_server_dns.pl et chat_client_dns.pl ?
