Je viens de terminer mes règles pour PF. Pourriez-vous y jeter un oeil, au cas où j'aurais laissé de gros trous ? Merci.
Le routeur qui utilise PF est aussi utilisé comme serveur pour différents réseaux de peer-to-peer, d'où les ports ouverts.
Il a 3 interfaces réseau :
- une reliée à l'internet ($extif)
- une reliée au LAN câblé ($intif)
- une reliée à un point d'accès wireless ($wirelessif).
On autorise tout le trafic venant du LAN mais on interdit les mails sortants du WLAN (protection spam).
# Normalize packets, and reassemble fragmented ones.
scrub in all
# NAT for LAN and WLAN.
nat on $intif from $intif:network to any -> $extif
nat on $wirelessif from $wirelessif:network to any -> $extif
set block-policy return
######### Filtering rules ##########################
# Default deny policy.
block all
#####
# Traffic to/from loopback is allowed without restriction.
pass quick on lo0 all
#####
# Drop spoofing attemps.
block drop in quick on $extif from <nonroutable> to any
block drop out quick on $extif from any to <nonroutable>
#####
# Allow access to the upper-definied TCP and UDP services.
pass in quick on $extif inet proto tcp from any to ($extif) \
port $tcpserv flags S/SA synproxy state
pass in quick on $extif inet proto udp from any to ($extif) \
port $udpserv keep state
##### LAN
# Allow all incoming/responding traffic from the LAN (trusted).
pass in quick on $intif from $int_if:network to any keep state
# Allow all outgoing traffic to the LAN.
pass out quick on $intif from any to $intif:network keep state
##### WLAN
# Block sending mails from to WLAN (spam threat).
block in quick on $wirelessif from $wirelessif:network to any \
inet proto tcp port 25
pass in quick on $wirelessif from $wirelessif:network to any keep state
pass out quick on $wirelessif from any to $wirelessif:network keep state
#####
# Block access from the WLAN to the LAN.
block in quick on $wirelessif from $wirelessif:network \
to $intif:network
#####
# Allow external connections from our networks to the Internet.
pass out quick on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
# NAT for LAN and WLAN. nat on $intif from $intif:network to any -> $extif nat on $wirelessif from $wirelessif:network to any -> $extif
Si tu as une ip dynamique il vaut mieux mettre les parenthèses à ton interface externe. Comme ça par exemple :
nat on $ext_if from $int_if:network to any -> ($ext_if)
-- Serge
olivier.pernet
Merci de votre aide, et désolé pour les 5 messages, j'ai posté à partir de Google Groups qui ne répondait pas après l'envoi du message... Une question à propos de ce que disait Michel toutefois : Si j'ai bien compris, il faudrait ajouter quelque chose pour bloquer les paquets entrants qui portent mon adresse IP publique comme source ? Comme ça block in drop quick from ($extif) to any
Mais j'ai peur que comme ça, tout le trafic entrant soit bloqué, non ?
Olivier
Merci de votre aide, et désolé pour les 5 messages, j'ai posté à
partir de Google Groups qui ne répondait pas après l'envoi du
message...
Une question à propos de ce que disait Michel toutefois :
Si j'ai bien compris, il faudrait ajouter quelque chose pour bloquer
les paquets entrants qui portent mon adresse IP publique comme source
? Comme ça
block in drop quick from ($extif) to any
Mais j'ai peur que comme ça, tout le trafic entrant soit bloqué, non ?
Merci de votre aide, et désolé pour les 5 messages, j'ai posté à partir de Google Groups qui ne répondait pas après l'envoi du message... Une question à propos de ce que disait Michel toutefois : Si j'ai bien compris, il faudrait ajouter quelque chose pour bloquer les paquets entrants qui portent mon adresse IP publique comme source ? Comme ça block in drop quick from ($extif) to any
Mais j'ai peur que comme ça, tout le trafic entrant soit bloqué, non ?
Olivier
manu
Michel Parlebas wrote:
- tous les icmp sont rejetés, ce qui n'est pas une bonne chose.
Ah oui, c'est même carrement heretique. Une machine disposant de connectivité IP doit pouvoir envoyer et recevoir des paquets ICMP.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Michel Parlebas <mpaRETIRER_CECI@modulabbs.net> wrote:
- tous les icmp sont rejetés, ce qui n'est pas une bonne chose.
Ah oui, c'est même carrement heretique. Une machine disposant de
connectivité IP doit pouvoir envoyer et recevoir des paquets ICMP.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
- tous les icmp sont rejetés, ce qui n'est pas une bonne chose.
Ah oui, c'est même carrement heretique. Une machine disposant de connectivité IP doit pouvoir envoyer et recevoir des paquets ICMP.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Arana
Michel Parlebas wrote:
- tous les icmp sont rejetés, ce qui n'est pas une bonne chose.
Ah oui, c'est même carrement heretique. Une machine disposant de connectivité IP doit pouvoir envoyer et recevoir des paquets ICMP.
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast par exemple, tu risque de noyer ton réseau. bon après ce n'est qu'une question de choix : moi je prefere faire un ping avec un telnet, je m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum un service à tourner avec son port accessible (ex: openssh sur 8080). un simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
si ça répond pas : soit la machine est out, soit le service à planté, auquel faut se déplacer :)
Michel Parlebas <mpaRETIRER_CECI@modulabbs.net> wrote:
- tous les icmp sont rejetés, ce qui n'est pas une bonne chose.
Ah oui, c'est même carrement heretique. Une machine disposant de
connectivité IP doit pouvoir envoyer et recevoir des paquets ICMP.
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos
j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de
bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast
par exemple, tu risque de noyer ton réseau. bon après ce n'est qu'une
question de choix : moi je prefere faire un ping avec un telnet, je
m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum
un service à tourner avec son port accessible (ex: openssh sur 8080). un
simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
si ça répond pas : soit la machine est out, soit le service à planté,
auquel faut se déplacer :)
- tous les icmp sont rejetés, ce qui n'est pas une bonne chose.
Ah oui, c'est même carrement heretique. Une machine disposant de connectivité IP doit pouvoir envoyer et recevoir des paquets ICMP.
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast par exemple, tu risque de noyer ton réseau. bon après ce n'est qu'une question de choix : moi je prefere faire un ping avec un telnet, je m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum un service à tourner avec son port accessible (ex: openssh sur 8080). un simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
si ça répond pas : soit la machine est out, soit le service à planté, auquel faut se déplacer :)
manu
Sebastien Arana wrote:
[filtrer ICMP est heretique]
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast par exemple, tu risque de noyer ton réseau.
Attaque dite du smurf. Le problème c'est surtout d'empecher les pings en broadcast de se propager d'un sous réseau à l'autre. A l'interieur d'un sous réseau donné, la capacité de decouvrir toutes les machines d'un ping en broadcast n'est pas dénué d'interet. Et puis ca ne permet pas d'attaque spécifique: si l'assayant est sur le sous réseau cible, il peux déjà noyer le réseau sous les broadcast ethernet, il n'y a pas besoin de faire des broadcast ICMP pour ca.
bon après ce n'est qu'une question de choix : moi je prefere faire un ping avec un telnet, je m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum un service à tourner avec son port accessible (ex: openssh sur 8080). un simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
ICMP ne sert pas qu'à faire des pings. Que tu filtres les pings ca n'est pas tellement un problème.
Le vrai problème, c'est qu'en filtrant tout ICMP, ta configuration anihile les mecanismes de découverte du PMTU de de gestion de la congestion au niveau IP. On arrive à s'en sortir avec TCP et le MSS clamping, mais ca reste du bricollage.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Arana <seb.arana@free.fr> wrote:
[filtrer ICMP est heretique]
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos
j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de
bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast
par exemple, tu risque de noyer ton réseau.
Attaque dite du smurf. Le problème c'est surtout d'empecher les pings en
broadcast de se propager d'un sous réseau à l'autre. A l'interieur d'un
sous réseau donné, la capacité de decouvrir toutes les machines d'un
ping en broadcast n'est pas dénué d'interet. Et puis ca ne permet pas
d'attaque spécifique: si l'assayant est sur le sous réseau cible, il
peux déjà noyer le réseau sous les broadcast ethernet, il n'y a pas
besoin de faire des broadcast ICMP pour ca.
bon après ce n'est qu'une
question de choix : moi je prefere faire un ping avec un telnet, je
m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum
un service à tourner avec son port accessible (ex: openssh sur 8080). un
simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
ICMP ne sert pas qu'à faire des pings. Que tu filtres les pings ca n'est
pas tellement un problème.
Le vrai problème, c'est qu'en filtrant tout ICMP, ta configuration
anihile les mecanismes de découverte du PMTU de de gestion de la
congestion au niveau IP. On arrive à s'en sortir avec TCP et le MSS
clamping, mais ca reste du bricollage.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast par exemple, tu risque de noyer ton réseau.
Attaque dite du smurf. Le problème c'est surtout d'empecher les pings en broadcast de se propager d'un sous réseau à l'autre. A l'interieur d'un sous réseau donné, la capacité de decouvrir toutes les machines d'un ping en broadcast n'est pas dénué d'interet. Et puis ca ne permet pas d'attaque spécifique: si l'assayant est sur le sous réseau cible, il peux déjà noyer le réseau sous les broadcast ethernet, il n'y a pas besoin de faire des broadcast ICMP pour ca.
bon après ce n'est qu'une question de choix : moi je prefere faire un ping avec un telnet, je m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum un service à tourner avec son port accessible (ex: openssh sur 8080). un simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
ICMP ne sert pas qu'à faire des pings. Que tu filtres les pings ca n'est pas tellement un problème.
Le vrai problème, c'est qu'en filtrant tout ICMP, ta configuration anihile les mecanismes de découverte du PMTU de de gestion de la congestion au niveau IP. On arrive à s'en sortir avec TCP et le MSS clamping, mais ca reste du bricollage.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Arana
Sebastien Arana wrote:
[filtrer ICMP est heretique]
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast par exemple, tu risque de noyer ton réseau.
Attaque dite du smurf. Le problème c'est surtout d'empecher les pings en broadcast de se propager d'un sous réseau à l'autre. A l'interieur d'un sous réseau donné, la capacité de decouvrir toutes les machines d'un ping en broadcast n'est pas dénué d'interet. Et puis ca ne permet pas d'attaque spécifique: si l'assayant est sur le sous réseau cible, il peux déjà noyer le réseau sous les broadcast ethernet, il n'y a pas besoin de faire des broadcast ICMP pour ca.
bon après ce n'est qu'une question de choix : moi je prefere faire un ping avec un telnet, je m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum un service à tourner avec son port accessible (ex: openssh sur 8080). un simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
ICMP ne sert pas qu'à faire des pings. Que tu filtres les pings ca n'est pas tellement un problème.
Le vrai problème, c'est qu'en filtrant tout ICMP, ta configuration anihile les mecanismes de découverte du PMTU de de gestion de la congestion au niveau IP. On arrive à s'en sortir avec TCP et le MSS clamping, mais ca reste du bricollage.
hmmm :) ça fait plaisir de voir qu'il y a des gens qui connaissent bien les protos réseau :) c'est cool. (ps: au passage j'ai vu ton bouquin sur 'les cachiers de l'admin BSD', c'est un des rares dans les commerces, je t'en félicite ! j'ai encore rien vu d'autre sur BSD dans les grandes surfaces ou les FNACS que je connais).
Bon oui, si je part de ton principe de la gestion de congestion au niveau IP. tu pars du principe que la machine recoit un datagramme ICMP lui disant 'aya ! stop, moi routeur XXX j'ai le buffer qui sature, change ta route ou va plus doucement'. c'est bien ça ? ou bien que notre machine elle même doit pouvoir envoyer ce type paquet à un routeur.
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour voir si je peux avec ipfilter eviter ce genre d'attaque. ps : http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16
si vous avez des conseils, je suis tout ouïe.
Sebastien Arana <seb.arana@free.fr> wrote:
[filtrer ICMP est heretique]
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos
j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de
bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast
par exemple, tu risque de noyer ton réseau.
Attaque dite du smurf. Le problème c'est surtout d'empecher les pings en
broadcast de se propager d'un sous réseau à l'autre. A l'interieur d'un
sous réseau donné, la capacité de decouvrir toutes les machines d'un
ping en broadcast n'est pas dénué d'interet. Et puis ca ne permet pas
d'attaque spécifique: si l'assayant est sur le sous réseau cible, il
peux déjà noyer le réseau sous les broadcast ethernet, il n'y a pas
besoin de faire des broadcast ICMP pour ca.
bon après ce n'est qu'une
question de choix : moi je prefere faire un ping avec un telnet, je
m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum
un service à tourner avec son port accessible (ex: openssh sur 8080). un
simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
ICMP ne sert pas qu'à faire des pings. Que tu filtres les pings ca n'est
pas tellement un problème.
Le vrai problème, c'est qu'en filtrant tout ICMP, ta configuration
anihile les mecanismes de découverte du PMTU de de gestion de la
congestion au niveau IP. On arrive à s'en sortir avec TCP et le MSS
clamping, mais ca reste du bricollage.
hmmm :) ça fait plaisir de voir qu'il y a des gens qui connaissent bien
les protos réseau :) c'est cool. (ps: au passage j'ai vu ton bouquin sur
'les cachiers de l'admin BSD', c'est un des rares dans les commerces, je
t'en félicite ! j'ai encore rien vu d'autre sur BSD dans les grandes
surfaces ou les FNACS que je connais).
Bon oui, si je part de ton principe de la gestion de congestion au
niveau IP. tu pars du principe que la machine recoit un datagramme ICMP
lui disant 'aya ! stop, moi routeur XXX j'ai le buffer qui sature,
change ta route ou va plus doucement'. c'est bien ça ? ou bien que notre
machine elle même doit pouvoir envoyer ce type paquet à un routeur.
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour
voir si je peux avec ipfilter eviter ce genre d'attaque. ps :
http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16
hérétique ? je pense pas, tu peux l'activer avec proto ICMP, mais persos j'évite le ICMP moi aussi pour divers pb. si tu l'active, oublie pas de bien configurer la chose pour qu'il ne reponde pas à des ICMP broadcast par exemple, tu risque de noyer ton réseau.
Attaque dite du smurf. Le problème c'est surtout d'empecher les pings en broadcast de se propager d'un sous réseau à l'autre. A l'interieur d'un sous réseau donné, la capacité de decouvrir toutes les machines d'un ping en broadcast n'est pas dénué d'interet. Et puis ca ne permet pas d'attaque spécifique: si l'assayant est sur le sous réseau cible, il peux déjà noyer le réseau sous les broadcast ethernet, il n'y a pas besoin de faire des broadcast ICMP pour ca.
bon après ce n'est qu'une question de choix : moi je prefere faire un ping avec un telnet, je m'explique : mon ipf bloque les ICMP, soit, mais j'autorise au minimum un service à tourner avec son port accessible (ex: openssh sur 8080). un simple "telnet [IP] 8080" me permet de tester la connectivité du monstre.
ICMP ne sert pas qu'à faire des pings. Que tu filtres les pings ca n'est pas tellement un problème.
Le vrai problème, c'est qu'en filtrant tout ICMP, ta configuration anihile les mecanismes de découverte du PMTU de de gestion de la congestion au niveau IP. On arrive à s'en sortir avec TCP et le MSS clamping, mais ca reste du bricollage.
hmmm :) ça fait plaisir de voir qu'il y a des gens qui connaissent bien les protos réseau :) c'est cool. (ps: au passage j'ai vu ton bouquin sur 'les cachiers de l'admin BSD', c'est un des rares dans les commerces, je t'en félicite ! j'ai encore rien vu d'autre sur BSD dans les grandes surfaces ou les FNACS que je connais).
Bon oui, si je part de ton principe de la gestion de congestion au niveau IP. tu pars du principe que la machine recoit un datagramme ICMP lui disant 'aya ! stop, moi routeur XXX j'ai le buffer qui sature, change ta route ou va plus doucement'. c'est bien ça ? ou bien que notre machine elle même doit pouvoir envoyer ce type paquet à un routeur.
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour voir si je peux avec ipfilter eviter ce genre d'attaque. ps : http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16
si vous avez des conseils, je suis tout ouïe.
manu
Sebastien Arana wrote:
Bon oui, si je part de ton principe de la gestion de congestion au niveau IP. tu pars du principe que la machine recoit un datagramme ICMP lui disant 'aya ! stop, moi routeur XXX j'ai le buffer qui sature, change ta route ou va plus doucement'. c'est bien ça ? ou bien que notre machine elle même doit pouvoir envoyer ce type paquet à un routeur.
Oui, c'est le paquet ICMP source quench. Note que la decouverte du PMTU est aussi vachement importante. C'est elle qui te casse la baraque sur les paquets trop gros quand tu es en ADSL ou derriere un VPN.
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour voir si je peux avec ipfilter eviter ce genre d'attaque. ps : http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16 si vous avez des conseils, je suis tout ouïe.
Avec IPfilter c'est simple: les regles keep state autorisent implicitement le traffic ICMP en sens inverse relatif à ce qu'on autorise.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Arana <seb.arana@free.fr> wrote:
Bon oui, si je part de ton principe de la gestion de congestion au
niveau IP. tu pars du principe que la machine recoit un datagramme ICMP
lui disant 'aya ! stop, moi routeur XXX j'ai le buffer qui sature,
change ta route ou va plus doucement'. c'est bien ça ? ou bien que notre
machine elle même doit pouvoir envoyer ce type paquet à un routeur.
Oui, c'est le paquet ICMP source quench.
Note que la decouverte du PMTU est aussi vachement importante. C'est
elle qui te casse la baraque sur les paquets trop gros quand tu es en
ADSL ou derriere un VPN.
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour
voir si je peux avec ipfilter eviter ce genre d'attaque. ps :
http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16
si vous avez des conseils, je suis tout ouïe.
Avec IPfilter c'est simple: les regles keep state autorisent
implicitement le traffic ICMP en sens inverse relatif à ce qu'on
autorise.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Bon oui, si je part de ton principe de la gestion de congestion au niveau IP. tu pars du principe que la machine recoit un datagramme ICMP lui disant 'aya ! stop, moi routeur XXX j'ai le buffer qui sature, change ta route ou va plus doucement'. c'est bien ça ? ou bien que notre machine elle même doit pouvoir envoyer ce type paquet à un routeur.
Oui, c'est le paquet ICMP source quench. Note que la decouverte du PMTU est aussi vachement importante. C'est elle qui te casse la baraque sur les paquets trop gros quand tu es en ADSL ou derriere un VPN.
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour voir si je peux avec ipfilter eviter ce genre d'attaque. ps : http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16 si vous avez des conseils, je suis tout ouïe.
Avec IPfilter c'est simple: les regles keep state autorisent implicitement le traffic ICMP en sens inverse relatif à ce qu'on autorise.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Arana
Sebastien Arana wrote:
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour voir si je peux avec ipfilter eviter ce genre d'attaque. ps : http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16 si vous avez des conseils, je suis tout ouïe.
Avec IPfilter c'est simple: les regles keep state autorisent implicitement le traffic ICMP en sens inverse relatif à ce qu'on autorise.
je prends note :)
sans mise à jour de mon fichier ipf.conf, voici les 4 règles appliquées actuellement dans ipfilter (c'est assez drastique, lol)
pass in log first quick proto tcp from any to any port = 8080 keep state block return-rst in quick proto tcp all block in all block out all
8080 c'est mon openssh (ben ouais c'est pas du http :) ) en fait le principe est le suivant : un scanner ne detecte qu'un port ouvert : le 8080, en lisant la bannière il voit juste DragonSSH, et detecte qu'il n'utilise que le proto 2 de ssh, donc si un jour il y a une faille sur mon openssh, j'ai un peu plus de temps que la moyenne pour appliquer un patch ou effectuer la mise à jour (m'enfin bon).
par contre comme j'ai modifié les TTL et les windows size par sysctl, lors de son OS finger print, retina detecte un windows 2003 (grâce à la règle block return-rst in quick proto tcp all). sans cette règle, retina arrive à detecter le freebsd 5.2 (il est fort ce machin, avec un seul port ! balèze). Nmap lui bloque car il n'y a pas assez de port ouvert.
Pour la configuration de mon sysctl, au niveau ip voici les options chargées à froid lors du reboot machine :
si vous avez une option supplémentaire qui pourrait améliorer encore la pile réseau ou le kernel en lui même je suis prenneur !
merci encore à toi pour les infos :) Bonne journée !
Seb
Sebastien Arana <seb.arana@free.fr> wrote:
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour
voir si je peux avec ipfilter eviter ce genre d'attaque. ps :
http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16
si vous avez des conseils, je suis tout ouïe.
Avec IPfilter c'est simple: les regles keep state autorisent
implicitement le traffic ICMP en sens inverse relatif à ce qu'on
autorise.
je prends note :)
sans mise à jour de mon fichier ipf.conf, voici les 4 règles appliquées
actuellement dans ipfilter (c'est assez drastique, lol)
pass in log first quick proto tcp from any to any port = 8080 keep state
block return-rst in quick proto tcp all
block in all
block out all
8080 c'est mon openssh (ben ouais c'est pas du http :) )
en fait le principe est le suivant : un scanner ne detecte qu'un port
ouvert : le 8080, en lisant la bannière il voit juste DragonSSH, et
detecte qu'il n'utilise que le proto 2 de ssh, donc si un jour il y a
une faille sur mon openssh, j'ai un peu plus de temps que la moyenne
pour appliquer un patch ou effectuer la mise à jour (m'enfin bon).
par contre comme j'ai modifié les TTL et les windows size par sysctl,
lors de son OS finger print, retina detecte un windows 2003 (grâce à la
règle block return-rst in quick proto tcp all). sans cette règle, retina
arrive à detecter le freebsd 5.2 (il est fort ce machin, avec un seul
port ! balèze). Nmap lui bloque car il n'y a pas assez de port ouvert.
Pour la configuration de mon sysctl, au niveau ip voici les options
chargées à froid lors du reboot machine :
je vais tenter d'appliquer un filtrage sur le type de paquet ICMP pour voir si je peux avec ipfilter eviter ce genre d'attaque. ps : http://www.obfuscation.org/ipf/ipf-howto.html#TOC_16 si vous avez des conseils, je suis tout ouïe.
Avec IPfilter c'est simple: les regles keep state autorisent implicitement le traffic ICMP en sens inverse relatif à ce qu'on autorise.
je prends note :)
sans mise à jour de mon fichier ipf.conf, voici les 4 règles appliquées actuellement dans ipfilter (c'est assez drastique, lol)
pass in log first quick proto tcp from any to any port = 8080 keep state block return-rst in quick proto tcp all block in all block out all
8080 c'est mon openssh (ben ouais c'est pas du http :) ) en fait le principe est le suivant : un scanner ne detecte qu'un port ouvert : le 8080, en lisant la bannière il voit juste DragonSSH, et detecte qu'il n'utilise que le proto 2 de ssh, donc si un jour il y a une faille sur mon openssh, j'ai un peu plus de temps que la moyenne pour appliquer un patch ou effectuer la mise à jour (m'enfin bon).
par contre comme j'ai modifié les TTL et les windows size par sysctl, lors de son OS finger print, retina detecte un windows 2003 (grâce à la règle block return-rst in quick proto tcp all). sans cette règle, retina arrive à detecter le freebsd 5.2 (il est fort ce machin, avec un seul port ! balèze). Nmap lui bloque car il n'y a pas assez de port ouvert.
Pour la configuration de mon sysctl, au niveau ip voici les options chargées à froid lors du reboot machine :
si vous avez une option supplémentaire qui pourrait améliorer encore la pile réseau ou le kernel en lui même je suis prenneur !
merci encore à toi pour les infos :) Bonne journée !
Seb
manu
Sebastien Arana wrote:
par contre comme j'ai modifié les TTL et les windows size par sysctl, lors de son OS finger print, retina detecte un windows 2003 (grâce à la règle block return-rst in quick proto tcp all). sans cette règle, retina arrive à detecter le freebsd 5.2 (il est fort ce machin, avec un seul port ! balèze). Nmap lui bloque car il n'y a pas assez de port ouvert.
Ah oui mais c'est ballot: maintenant que tu l'as dit il suffit de faire une recherche sur Google pour le savoir. La sécurité par obscurité ca marche que si on ne dit rien! :)
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Sebastien Arana <seb.arana@free.fr> wrote:
par contre comme j'ai modifié les TTL et les windows size par sysctl,
lors de son OS finger print, retina detecte un windows 2003 (grâce à la
règle block return-rst in quick proto tcp all). sans cette règle, retina
arrive à detecter le freebsd 5.2 (il est fort ce machin, avec un seul
port ! balèze). Nmap lui bloque car il n'y a pas assez de port ouvert.
Ah oui mais c'est ballot: maintenant que tu l'as dit il suffit de faire
une recherche sur Google pour le savoir. La sécurité par obscurité ca
marche que si on ne dit rien! :)
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
par contre comme j'ai modifié les TTL et les windows size par sysctl, lors de son OS finger print, retina detecte un windows 2003 (grâce à la règle block return-rst in quick proto tcp all). sans cette règle, retina arrive à detecter le freebsd 5.2 (il est fort ce machin, avec un seul port ! balèze). Nmap lui bloque car il n'y a pas assez de port ouvert.
Ah oui mais c'est ballot: maintenant que tu l'as dit il suffit de faire une recherche sur Google pour le savoir. La sécurité par obscurité ca marche que si on ne dit rien! :)
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
