D'abord merci à Pasqual pour ses précieux conseils (masquerading).
Voici deux tites questions:
je cherche une source d'informations fiable qui listerait les types de
datagrames connus ou moins connus qu'il est bon de filtrer pour
restreindre la vulnérabilité d'un réseau.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux,
mais une cinquantaine de paquets par heure parviennent encore à ma
station looseDows sur des ports fermés. C'est du moins ce que me dit
un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que
j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de
Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de
sniffer une session sur un site qui produit habituellement des logs
dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de
réponse.
Résumé: la liaison internet est masqueradée et filtrée par le poste
linux, Kerio tourne sur un client dans le LAN et refuse des paquets à
destination de ports locaux fermés, venant d'internet.
Des conseils ? Ils seront forcément bons, alors d'avance, merci !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Anthony Fleury
googlio wrote:
Bonjour, Bonjour,
je cherche une source d'informations fiable qui listerait les types de datagrames connus ou moins connus qu'il est bon de filtrer pour restreindre la vulnérabilité d'un réseau.
Je ne vois pas de telles listes exister. Ca dépend totalement du reseau et de ce qui tourne dessus...
Résumé: la liaison internet est masqueradée et filtrée par le poste linux, Kerio tourne sur un client dans le LAN et refuse des paquets à destination de ports locaux fermés, venant d'internet.
Comment est-ce possible ? quelle est la configuration d'iptables ? En fait, ce qui arrive sur les ports de la machine qui a Kerio doit être de deux types : - Des connexions demandées par la machine elle-même (et donc souvent le port en question est ouvert...) - Des connexions dues à une translation de port faite par la machine linux (donc dans ce cas si tu ne veux pas cette connexion, tu ne la translates pas...)
Tout le reste n'est pas sensé passer.
-- Anthony Fleury "Il faut mieux avoir un dix à sa composition qu'un con à sa disposition."
googlio wrote:
Bonjour,
Bonjour,
je cherche une source d'informations fiable qui listerait les types de
datagrames connus ou moins connus qu'il est bon de filtrer pour
restreindre la vulnérabilité d'un réseau.
Je ne vois pas de telles listes exister. Ca dépend totalement du reseau et
de ce qui tourne dessus...
Résumé: la liaison internet est masqueradée et filtrée par le poste
linux, Kerio tourne sur un client dans le LAN et refuse des paquets à
destination de ports locaux fermés, venant d'internet.
Comment est-ce possible ? quelle est la configuration d'iptables ?
En fait, ce qui arrive sur les ports de la machine qui a Kerio doit être de
deux types :
- Des connexions demandées par la machine elle-même (et donc souvent le port
en question est ouvert...)
- Des connexions dues à une translation de port faite par la machine linux
(donc dans ce cas si tu ne veux pas cette connexion, tu ne la translates
pas...)
Tout le reste n'est pas sensé passer.
--
Anthony Fleury
"Il faut mieux avoir un dix à sa composition qu'un con à sa disposition."
je cherche une source d'informations fiable qui listerait les types de datagrames connus ou moins connus qu'il est bon de filtrer pour restreindre la vulnérabilité d'un réseau.
Je ne vois pas de telles listes exister. Ca dépend totalement du reseau et de ce qui tourne dessus...
Résumé: la liaison internet est masqueradée et filtrée par le poste linux, Kerio tourne sur un client dans le LAN et refuse des paquets à destination de ports locaux fermés, venant d'internet.
Comment est-ce possible ? quelle est la configuration d'iptables ? En fait, ce qui arrive sur les ports de la machine qui a Kerio doit être de deux types : - Des connexions demandées par la machine elle-même (et donc souvent le port en question est ouvert...) - Des connexions dues à une translation de port faite par la machine linux (donc dans ce cas si tu ne veux pas cette connexion, tu ne la translates pas...)
Tout le reste n'est pas sensé passer.
-- Anthony Fleury "Il faut mieux avoir un dix à sa composition qu'un con à sa disposition."
Dominique Blas
ooglio wrote:
[...]
je cherche une source d'informations fiable qui listerait les types de datagrames connus ou moins connus qu'il est bon de filtrer pour restreindre la vulnérabilité d'un réseau. Hum, c'est le egnre de question qui aurait davantage sa place dans
fr.comp.securite. Je fais donc copie.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux, mais une cinquantaine de paquets par heure parviennent encore à ma station looseDows sur des ports fermés. C'est du moins ce que me dit un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de sniffer une session sur un site qui produit habituellement des logs dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de réponse.
Je ne comprends pas comment des trames en provenance de l'extérieur peuvent encore parvenir à une machine du réseau local protégée par Netfilter.
Si je tente de comprendre je ne peux envisager que 2 choses : - configuration inadéquate du FW (pourtant pas compliqué de bloquer ce qui rentre, c'est le défaut) ; - Kerio hurle inopportunément au sujet de paquets légitimes ie au sujet de réponses aux requêtes formulées ; - présence d'un cheval de Troie.
Je penche fortement pour la deuxième raison. Il est dès lors facile de lancer un tcpdump et d'inspecter le contenu des paquets que Kerio annonce comme étant illégitimes.
Au préalable ne pas oublier de synchroniser les horloges !
db
-- email : usenet blas net
ooglio wrote:
[...]
je cherche une source d'informations fiable qui listerait les types de
datagrames connus ou moins connus qu'il est bon de filtrer pour
restreindre la vulnérabilité d'un réseau.
Hum, c'est le egnre de question qui aurait davantage sa place dans
fr.comp.securite.
Je fais donc copie.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux,
mais une cinquantaine de paquets par heure parviennent encore à ma
station looseDows sur des ports fermés. C'est du moins ce que me dit
un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que
j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de
Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de
sniffer une session sur un site qui produit habituellement des logs
dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de
réponse.
Je ne comprends pas comment des trames en provenance de l'extérieur
peuvent encore parvenir à une machine du réseau local protégée par
Netfilter.
Si je tente de comprendre je ne peux envisager que 2 choses :
- configuration inadéquate du FW (pourtant pas compliqué de
bloquer ce qui rentre, c'est le défaut) ;
- Kerio hurle inopportunément au sujet de paquets légitimes ie au sujet
de réponses aux requêtes formulées ;
- présence d'un cheval de Troie.
Je penche fortement pour la deuxième raison.
Il est dès lors facile de lancer un tcpdump et d'inspecter le contenu des
paquets que Kerio annonce comme étant illégitimes.
Au préalable ne pas oublier de synchroniser les horloges !
je cherche une source d'informations fiable qui listerait les types de datagrames connus ou moins connus qu'il est bon de filtrer pour restreindre la vulnérabilité d'un réseau. Hum, c'est le egnre de question qui aurait davantage sa place dans
fr.comp.securite. Je fais donc copie.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux, mais une cinquantaine de paquets par heure parviennent encore à ma station looseDows sur des ports fermés. C'est du moins ce que me dit un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de sniffer une session sur un site qui produit habituellement des logs dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de réponse.
Je ne comprends pas comment des trames en provenance de l'extérieur peuvent encore parvenir à une machine du réseau local protégée par Netfilter.
Si je tente de comprendre je ne peux envisager que 2 choses : - configuration inadéquate du FW (pourtant pas compliqué de bloquer ce qui rentre, c'est le défaut) ; - Kerio hurle inopportunément au sujet de paquets légitimes ie au sujet de réponses aux requêtes formulées ; - présence d'un cheval de Troie.
Je penche fortement pour la deuxième raison. Il est dès lors facile de lancer un tcpdump et d'inspecter le contenu des paquets que Kerio annonce comme étant illégitimes.
Au préalable ne pas oublier de synchroniser les horloges !
db
-- email : usenet blas net
Dominique Blas
googlio wrote:
Bonjour,
D'abord merci à Pasqual pour ses précieux conseils (masquerading).
Voici deux tites questions:
je cherche une source d'informations fiable qui listerait les types de datagrames connus ou moins connus qu'il est bon de filtrer pour restreindre la vulnérabilité d'un réseau. Hum, c'est le egnre de question qui aurait davantage sa place dans
fr.comp.securite. Je fais donc copie.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux, mais une cinquantaine de paquets par heure parviennent encore à ma station looseDows sur des ports fermés. C'est du moins ce que me dit un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de sniffer une session sur un site qui produit habituellement des logs dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de réponse.
Je ne comprends pas comment des trames en provenance de l'extérieur peuvent encore parvenir à une machine du réseau local protégée par Netfilter.
Si je tente de comprendre je ne peux envisager que 2 choses : configuration inadéquate du FW (pourtant pas compliqué de bloquer ce qui rentre, c'est le défaut) ; Kerio hurle inopportunément au sujet de paquets légitimes ie au sujet de réponses aux requêtes formulées.
Je penche forcément pour cette seconde raison. Il est dès lors facile de lancer un tcpdump et d'inspecter le contenu des paquets que Kerio annonce comme étant illégitimes.
Au préalable ne pas oublier de synchroniser les horloges !
db
-- email : usenet blas net
googlio wrote:
Bonjour,
D'abord merci à Pasqual pour ses précieux conseils (masquerading).
Voici deux tites questions:
je cherche une source d'informations fiable qui listerait les types de
datagrames connus ou moins connus qu'il est bon de filtrer pour
restreindre la vulnérabilité d'un réseau.
Hum, c'est le egnre de question qui aurait davantage sa place dans
fr.comp.securite.
Je fais donc copie.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux,
mais une cinquantaine de paquets par heure parviennent encore à ma
station looseDows sur des ports fermés. C'est du moins ce que me dit
un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que
j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de
Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de
sniffer une session sur un site qui produit habituellement des logs
dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de
réponse.
Je ne comprends pas comment des trames en provenance de l'extérieur
peuvent encore parvenir à une machine du réseau local protégée par
Netfilter.
Si je tente de comprendre je ne peux envisager que 2 choses :
configuration inadéquate du FW (pourtant pas compliqué de
bloquer ce qui rentre, c'est le défaut) ;
Kerio hurle inopportunément au sujet de paquets légitimes ie au sujet
de réponses aux requêtes formulées.
Je penche forcément pour cette seconde raison.
Il est dès lors facile de lancer un tcpdump et d'inspecter le contenu des
paquets que Kerio annonce comme étant illégitimes.
Au préalable ne pas oublier de synchroniser les horloges !
D'abord merci à Pasqual pour ses précieux conseils (masquerading).
Voici deux tites questions:
je cherche une source d'informations fiable qui listerait les types de datagrames connus ou moins connus qu'il est bon de filtrer pour restreindre la vulnérabilité d'un réseau. Hum, c'est le egnre de question qui aurait davantage sa place dans
fr.comp.securite. Je fais donc copie.
En fait, j'ai déjà un FW acceptable (iptables) sur mon serveur linux, mais une cinquantaine de paquets par heure parviennent encore à ma station looseDows sur des ports fermés. C'est du moins ce que me dit un deuxième firewall, Kerio, qui tourne sur ce poste en attendant que j'ai progressé. Le problème, c'est l'extrême pauvreté des logs de Kerio, qui ne renseignent pas sur les flags TCP. J'ai essayé de sniffer une session sur un site qui produit habituellement des logs dans Kerio, mais dans cet océan de trames, je n'ai pu trouver de réponse.
Je ne comprends pas comment des trames en provenance de l'extérieur peuvent encore parvenir à une machine du réseau local protégée par Netfilter.
Si je tente de comprendre je ne peux envisager que 2 choses : configuration inadéquate du FW (pourtant pas compliqué de bloquer ce qui rentre, c'est le défaut) ; Kerio hurle inopportunément au sujet de paquets légitimes ie au sujet de réponses aux requêtes formulées.
Je penche forcément pour cette seconde raison. Il est dès lors facile de lancer un tcpdump et d'inspecter le contenu des paquets que Kerio annonce comme étant illégitimes.
Au préalable ne pas oublier de synchroniser les horloges !
db
-- email : usenet blas net
Florent Clairambault
- Des connexions demandées par la machine elle-même (et donc souvent le port en question est ouvert...) - Des connexions dues à une translation de port faite par la machine linux (donc dans ce cas si tu ne veux pas cette connexion, tu ne la translates pas...)
Je suis tout à fait d'accord. En plus, il faut rester réaliste, les firewalls logiciels sont avant tout las pour nous prouver qu'ils sont nécessaires : "Vous avez vu, j'ai détecté ça, la preuve que je fonctionne bien."
Donc, à la limite, tu peux désactiver tous les modules de masq, ça serrait trés bête, mais bon, la paranoïa mène à certaines situations absurdes parfois. Tu peux limiter à mort le temps maximum d'ouverture des ports, mais ça peut devenir trés embêtant (genre avec moins de 30s, MSN se reconnecte tout le temps). D'autant plus que les ports ouverts à travers le masq ne sont utilisables que par le correspondant pour qui ils ont été ouverts normalement.
Mais le plus simple, c'est de prendre ton petit firewall et ethereal en mode capture en même temps. Dès que ton firewall se plaint, tu regardes ce qu'a trouver Ethereal. Si c'est à peu près toujours sur le même port, mets un filtre de capture. Tu peux analyser les paquets, et à mon avis, tu trouveras pas grand chose d'interressant, mais si c'est le cas, copies leur entête et parle en dans le forum. Enfin, Ethereal te décrit tellement bien les paquets, que faudrait vraiment que ce soit un exploit (histoire de renforcer ta paranoïa) trés spécifique pour pas comprendre par toi même ce qui se passe.
Je suis sur que tout le temps que vous passez à renforcer votre firewall vous pourrier le passer à faire des trucs bien plus interressants...
Florent
- Des connexions demandées par la machine elle-même (et donc souvent le
port
en question est ouvert...)
- Des connexions dues à une translation de port faite par la machine linux
(donc dans ce cas si tu ne veux pas cette connexion, tu ne la translates
pas...)
Je suis tout à fait d'accord. En plus, il faut rester réaliste, les
firewalls logiciels sont avant tout las pour nous prouver qu'ils sont
nécessaires : "Vous avez vu, j'ai détecté ça, la preuve que je fonctionne
bien."
Donc, à la limite, tu peux désactiver tous les modules de masq, ça serrait
trés bête, mais bon, la paranoïa mène à certaines situations absurdes
parfois.
Tu peux limiter à mort le temps maximum d'ouverture des ports, mais ça peut
devenir trés embêtant (genre avec moins de 30s, MSN se reconnecte tout le
temps). D'autant plus que les ports ouverts à travers le masq ne sont
utilisables que par le correspondant pour qui ils ont été ouverts
normalement.
Mais le plus simple, c'est de prendre ton petit firewall et ethereal en mode
capture en même temps. Dès que ton firewall se plaint, tu regardes ce qu'a
trouver Ethereal. Si c'est à peu près toujours sur le même port, mets un
filtre de capture.
Tu peux analyser les paquets, et à mon avis, tu trouveras pas grand chose
d'interressant, mais si c'est le cas, copies leur entête et parle en dans le
forum.
Enfin, Ethereal te décrit tellement bien les paquets, que faudrait vraiment
que ce soit un exploit (histoire de renforcer ta paranoïa) trés spécifique
pour pas comprendre par toi même ce qui se passe.
Je suis sur que tout le temps que vous passez à renforcer votre firewall
vous pourrier le passer à faire des trucs bien plus interressants...
- Des connexions demandées par la machine elle-même (et donc souvent le port en question est ouvert...) - Des connexions dues à une translation de port faite par la machine linux (donc dans ce cas si tu ne veux pas cette connexion, tu ne la translates pas...)
Je suis tout à fait d'accord. En plus, il faut rester réaliste, les firewalls logiciels sont avant tout las pour nous prouver qu'ils sont nécessaires : "Vous avez vu, j'ai détecté ça, la preuve que je fonctionne bien."
Donc, à la limite, tu peux désactiver tous les modules de masq, ça serrait trés bête, mais bon, la paranoïa mène à certaines situations absurdes parfois. Tu peux limiter à mort le temps maximum d'ouverture des ports, mais ça peut devenir trés embêtant (genre avec moins de 30s, MSN se reconnecte tout le temps). D'autant plus que les ports ouverts à travers le masq ne sont utilisables que par le correspondant pour qui ils ont été ouverts normalement.
Mais le plus simple, c'est de prendre ton petit firewall et ethereal en mode capture en même temps. Dès que ton firewall se plaint, tu regardes ce qu'a trouver Ethereal. Si c'est à peu près toujours sur le même port, mets un filtre de capture. Tu peux analyser les paquets, et à mon avis, tu trouveras pas grand chose d'interressant, mais si c'est le cas, copies leur entête et parle en dans le forum. Enfin, Ethereal te décrit tellement bien les paquets, que faudrait vraiment que ce soit un exploit (histoire de renforcer ta paranoïa) trés spécifique pour pas comprendre par toi même ce qui se passe.
Je suis sur que tout le temps que vous passez à renforcer votre firewall vous pourrier le passer à faire des trucs bien plus interressants...
Florent
Dominique Blas
Florent Clairambault wrote:
[...]
Je suis tout à fait d'accord. En plus, il faut rester réaliste, les firewalls logiciels Les firewalls ne sont que des logiciels !
db -- email : usenet blas net
Florent Clairambault wrote:
[...]
Je suis tout à fait d'accord. En plus, il faut rester réaliste, les
firewalls logiciels
Les firewalls ne sont que des logiciels !
