SME 7.x et freebox v4 - problèmes d'accès au net

[Old Lodge Skins]

Voilà...


[root@sme-server-7 ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 14986 packets, 14M bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- ppp+ * 0.0.0.0/0 0.0.0.0/0 tcp dpts:0:1023
0 0 DROP udp -- ppp+ * 0.0.0.0/0 0.0.0.0/0 udp dpts:0:1023
0 0 DROP tcp -- ppp+ * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02
0 0 DROP icmp -- ppp+ * 0.0.0.0/0 0.0.0.0/0 icmp type 8

Chain FORWARD (policy DROP 95 packets, 5772 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 8994 packets, 4616K bytes)
pkts bytes target prot opt in out source destination

Chain ForwardedTCP (0 references)
pkts bytes target prot opt in out source destination
0 0 ForwardedTCP_3345 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 denylog tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02

Chain ForwardedTCP_3345 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 192.168.1.249 tcp dpts:13000:13050
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 192.168.1.249 tcp dpt:443
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 192.168.1.249 tcp dpts:12035:12036
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 192.168.1.249 tcp dpt:12043

Chain ForwardedUDP (0 references)
pkts bytes target prot opt in out source destination
0 0 ForwardedUDP_3345 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 denylog udp -- * * 0.0.0.0/0 0.0.0.0/0

Chain ForwardedUDP_3345 (1 references)
pkts bytes target prot opt in out source destination

Chain InboundICMP (0 references)
pkts bytes target prot opt in out source destination
0 0 InboundICMP_3345 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 denylog icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain InboundICMP_3345 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 4
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 12
0 0 denylog all -- * * 0.0.0.0/0 0.0.0.0/0

Chain InboundTCP (0 references)
pkts bytes target prot opt in out source destination
0 0 InboundTCP_3345 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 denylog tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02

Chain InboundTCP_3345 (1 references)
pkts bytes target prot opt in out source destination
0 0 denylog all -- * * 0.0.0.0/0 !88.176.98.14
0 0 REJECT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:113 reject-with tcp-reset
0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:443
0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:3306
0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:995
0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:25
0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.176.98.14 tcp dpt:465

Chain InboundUDP (0 references)
pkts bytes target prot opt in out source destination
0 0 InboundUDP_3345 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 denylog udp -- * * 0.0.0.0/0 0.0.0.0/0

Chain InboundUDP_3345 (1 references)
pkts bytes target prot opt in out source destination
0 0 denylog all -- * * 0.0.0.0/0 !88.176.98.14

Chain PPPconn (0 references)
pkts bytes target prot opt in out source destination
0 0 PPPconn_1 all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PPPconn_1 (1 references)
pkts bytes target prot opt in out source destination

Chain denylog (10 references)
pkts bytes target prot opt in out source destination
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:137:139
0 0 ULOG all -- * * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix `denylog:' queue_threshold 1
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain gre-in (0 references)
pkts bytes target prot opt in out source destination
0 0 denylog all -- * * 0.0.0.0/0 !88.176.98.14
0 0 denylog all -- * * 0.0.0.0/0 0.0.0.0/0

Chain local_chk (0 references)
pkts bytes target prot opt in out source destination
0 0 local_chk_3345 all -- * * 0.0.0.0/0 0.0.0.0/0

Chain local_chk_3345 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0

Chain state_chk (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

[tomtom]

C'est gentil toutes ces recherches
Mais ça tombe bien dans chacun des liens que tu donnes il est clairement expliqué que les attaques sur le WPA sont par dictionnaire ou force brute.

http://www.wirelessdefence.org/Contents ... ckMain.htm

Breaking WPA:

Once the WPA handshake has been collected (see aireplay) we can perform a dictionary attack to determine the WPA-PSK (Pre-Shared-Key)

http://kismac.binaervarianz.de/

cypto support

* bruteforce attacks against LEAP, WPA and WEP
* weak scheduling attack against WEP
* Newsham 21-bit attack against WEP

http://www.wirelessdefence.org/Contents ... tyMain.htm

To perform the coWPAtty dictionary attack we need to supply the tool with a capture file that includes the TKIP four-way handshake, a dictionary file of passphrases to guess with and the SSID for the network.

http://www.wirelessdefence.org/Contents ... rcrack.htm

Breaking WPA:

Once the WPA handshake has been collected (see aireplay) we can perform a dictionary attack to determine the WPA-PSK (Pre-Shared-Key)

http://www.generation-nt.com/wifi-secur ... 824-1.html

Etape 4 :


On lance sur les packets capturés par Ethereal un logiciel de Bruteforce qui va générer une attaque par dictionnaire sur les packets chiffrés capturés précédemment. La durée de travail de ce logiciel varie suivant la complexité de la clé WPA mais également de la puissance de votre ordinateur. Ceci étant, cela prend en moyenne de quelques secondes à une minute...

Je connais très bien la sécurité du wifi et j'ai pratiqué beaucoup de tests.
Bon courage sur une clé de 20 caractères aléatoires, comme je l'ai dit tout à l'heure.

Tout cela n'enlève rien au fait que le wifi n'est absolument pas la panacée. D'abord, les débits sont pourris et la qualité souvent faible avec des pertes de connexion, ue grande sensibilité à l'environnement.
Ensuite, bon, la sécurité n'est pas parfaite. Mais elle est néanmoins correcte pour la sécurité d'un particulier qui n'a pas grand chose à cacher...

Je pompe le propos d'un membre d'un autre forum :

Je ne sais pas quel genre de réseau tu essaies de protéger. S'il s'agit d'un réseau particulièrement sensible ou que ta société a des motifs tangibles pour craindre l'espionnage industriel, installe un radius. S'il s'agit d'un réseau de taille moyenne et que ni la dst ni le mossad ni la nsa ne s'intéresse à vos activités de fabrication de boules à neige avec sacré coeur incorporé , alors je serais tenté de te dire que tu peux dormir sur tes deux oreilles avec juste du WPA et une bonne clé bien imbitable.

t.

[tomtom]

Chain local_chk_3345 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0

Ben voila...

Ton réseau "Green" autorisé à sortir était 192.169.0.0/24.
Maintenant, avec 192.168.1.0/24 ça ne marchera pas.

Modifie ton réseau en 192.168.0.0/24 ou alors reconfigure la SME pour avoir le green sur 192.168.1.0/24 si c'est possible.

Ce devrait aller mieux.

t.

[tomtom]

Ah remarque c'est peut-être ça... Car avant j'utilisais des 192.168.0.x en interne et chez ma soeur j'ai changé pour des 1.x car conflit avec sa freebox, en mode routeur elle, qui utilisait des 0.x... Je vais tester.

Quand ça ne marche plus, cherche ce que tu as changé

t.

[Old Lodge Skins]

Désolé... J'ai oublié de dire qu'à tout hasard, il y a quelques heures, j'ai remis ma SME sur son réglage d'avant (avant les emm****) c-a-d que j'ai 192.168.0.20 pour la SME, DHCP de 192.168.0.50 à 250.

[tomtom]

Oups...

Alors je vois pas, car la règle est bonne.

Lance un ethereal sur l'eth0 de la SME et tu fais un ping à partir de la station, tu nous donnes le resultat...


t.

[tomtom]

Ce qui m'interpelle un peu c'est que ta chaine FORWARD est vide.... ?

Un autre propriétaire de SME peut confirmer ça ?

t.

[jibe]

Désolé... J'ai oublié de dire qu'à tout hasard, il y a quelques heures, j'ai remis ma SME sur son réglage d'avant (avant les emm****) c-a-d que j'ai 192.168.0.20 pour la SME, DHCP de 192.168.0.50 à 250.

Cela veut dire quoi ? Que le problème reste entier ? (on finit par avoir du mal à suivre...)

Quand au Freebox (v4 et v5 que je connais), elles sont livrés en mode Bridge (modem) par défaut et il faut obligatoirement passer par la page web de config chez Free pour activer le mode routeur...

Bon, donc tomtom et Old Lodge Skins ont raison. J'étais persuadé du contraire, mais si tu es sûr de toi, moi je ne l'étais pas totalement

Et puis bon sang, ca marchait au poil avant que je ne sois coupé par Free et forcé de mettre une freebox!

Alors, tente de mettre un modem (si possible celui que tu avais avant) : ça confirmera que c'est bien la freebox. Ou ça indiquera qu'il ne s'agit que d'une coïncidence... En tous cas, ça permettra d'avancer un peu, parce que là, le mystère ne fait que s'épaissir !

Peux-tu ensuite nous faire un résumé de ce qui fonctionne et ce qui ne fonctionne pas ? On finit par s'y perdre dans tous ces posts... Quelque chose du genre :
- SME -> http internet Ok
- SME -> Ping des DNS de Free.fr -> Ok
- PC -> http SME ???
- PC -> ping SME ???
- PC -> http internet NOK
- etc. etc.

[jibe]

Bon, je suis comme Gaston, je tape avec des mouffles

Mais bon, je pense que malgré les deux posts de tomtom, mes remarques restent valables...

[jibe]

Ce qui m'interpelle un peu c'est que ta chaine FORWARD est vide.... ?

Un autre propriétaire de SME peut confirmer ça ?

t.

A priori, ce n'est effectivement pas bon. Cela dit, je ne me suis pas encore penché sur la formation des règles qui sont générées automatiquement à chaque modification de la configuration de SME. Il est donc logique que deux SME configurées différemment aient des règles différentes. Mais de là à ce que la chaine FORWARD soit vide ???

Dis-nous bien tout, Old Lodge Skins : qu'as-tu modifié sur ta SME lors de la mise en place de la FreeBox ? Qu'as-tu installé comme contribs ? Modifié comme templates ? etc.

[Old Lodge Skins]

Jibe, je ne peux pas remettre mon modem...
Si j'ai dû réclamer ma freebox, c'est justement parce que mon modem, qui allait très bien en free IP/ADSL, ne marche pas en free dégroupé!!

Entre le moment où j'ai été coupé, et celui où j'ai mis le serveur chez ma soeur (où j'ai eu des problèmes identiques) je n'ai rien installé de nouveau. J'ai juste tenté de modifier le paramétrage réseau de base (pour l'accès au net, passer de PPPoE à DHCP, ce genre de choses) et changé les adresses utilisées par la SME quand je me suis rendu compte que j'entrais en conflit avec sa freebox.
De toute façon comme contribs je n'ai pas grand-chose... sme7admin, snort, et c'est tout.

Le serveur a parfaitement accès au net. Ping, lynx, etc... Tout va bien lorsque je travaille en SSH directement sur lui. Y compris sur les DNS de free.
Les postes peuvent pinger le serveur, charger des pages hébergées par lui sans paramétrer de proxy. j'ai aussi accès au serveur POP local. SSHFS, FTP, ... Bref tout ce qui est sur mon réseau local est accessible.
Par contre impossible d'accéder à quoi que ce soit à l'éxtérieur; Pour des accès HTTP il faut définir la SME en proxy, et je n'accède pas à mon serveur POP externe. Quant au ping n'en parlons même pas...

petit extrait de ce que m'a donné tshark (ex-ethereal) pour tomtom - sur eth0, réseau interne donc (en pingant le serveur depuis un poste):

tshark -i eth0

0.000000 192.168.0.20 -> 192.168.0.250 SSH Encrypted response packet len=64
0.001085 192.168.0.250 -> 192.168.0.20 TCP 22366 > ssh [ACK] Seq=0 Ack=64 Win=2435 Len=0 TSV=70721104 TSER=1532507
0.095976 RPTInter_33:be:92 -> Broadcast ARP Who has 192.168.0.5? Tell 192.168.0.20
0.305654 192.168.0.250 -> 192.168.0.20 ICMP Echo (ping) request
0.305858 192.168.0.20 -> 192.168.0.250 ICMP Echo (ping) reply
1.095593 RPTInter_33:be:92 -> Broadcast ARP Who has 192.168.0.5? Tell 192.168.0.20
1.304468 192.168.0.250 -> 192.168.0.20 ICMP Echo (ping) request
1.304603 192.168.0.20 -> 192.168.0.250 ICMP Echo (ping) reply
2.304004 192.168.0.250 -> 192.168.0.20 ICMP Echo (ping) request
2.304129 192.168.0.20 -> 192.168.0.250 ICMP Echo (ping) reply
4.049491 192.168.0.250 -> 192.168.0.20 SSH Encrypted request packet len=48

192.168.0.5 est la carte réseau interne de mon portable que j'avais reconfigurée temporairement en IP fixe, elle est débranchée au moment de ce test.

[Gaston]

Ce qui m'interpelle un peu c'est que ta chaine FORWARD est vide.... ?

cela m'avait interpellé aussi, mais vu comment mon serveur est bricolé

Code: Tout sélectionner

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 state_chk  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 local_chk  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ForwardedTCP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x16/0x02
    0     0 ForwardedUDP  udp  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 denylog    all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
  754 49480 PPPconn    all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 denylog    all  --  *      *       224.0.0.0/4          0.0.0.0/0
    0     0 denylog    all  --  *      *       0.0.0.0/0            224.0.0.0/4
  754 49480 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

alorsje viens de vérifier : non c'est pas normal, l'OUTPUT non plus n'est pas standard pour le reste je sait pas (fatigué là).

Aussi, je propose que notre camarade prennent le temps de remettre TOUT à plat : il y a eu beaucoup d'informations échangées, de données qui ont changées également, personnellement je ne m'y retrouve plus et comme le dis TomTom on est pas loin de la config la plus simple que l'on puisse avec un SME + LAN

- passer par la console,
- faire une reconfiguration de la SME
- si ça reboot pas tout seul (et même dans ce cas là, un signal-event post upgradre, un signal-event reboot)
- établir une configuration réseau sans mélanges
- comme l'a suggéré Jibe, regarder comment ça se passe avec l'ancien modem (j'y crois pas le problème est sur le LAN pas côté WAN)
- mettre le routeur de côté et utiliser le switch c'est pas normal que ça ne marche pas (sauf si c'est un routeur déguisé en switch ) ou alors investir dans un cable croisé et virer cet élément perturbateur

on tourne en rond avec des infos incomplètes voir contradictoires. Un réseau n'est pas une succession de boites à chance : cela doit d'abord fonctionner sur le papier, après il y a des impondérables que l'on peut investiguer ... mais bon

G.
PS

Bon, je suis comme Gaston, je tape avec des mouffles

ben oui c'est de saison pff et vous avez eu le temps de faire deux posts avant que je retire les miennes

[Old Lodge Skins]

j'ai déjà essayé de le reconfigurer avant mais bon, par acquis de conscience je remets ça...

[Old Lodge Skins]

Après avoir reconfiguré le serveur, même chanson...

Au fait, un tshark -i eth0 alors que depuis un poste je tente de pinger free.fr me donne ceci...

0.936098 192.168.0.20 -> 192.168.0.250 SSH [TCP Previous segment lost] Encrypted response packet len=128
0.937700 192.168.0.20 -> 192.168.0.250 SSH [TCP Previous segment lost] Encrypted response packet len=128
0.938113 192.168.0.250 -> 192.168.0.20 TCP 2909 > ssh [ACK] Seq=144 Ack=222000 Win=1565 Len=0 TSV=71302952 TSER=627256
0.938630 192.168.0.20 -> 192.168.0.250 SSH [TCP Previous segment lost] Encrypted response packet len=128
0.939463 192.168.0.20 -> 192.168.0.250 SSH [TCP Previous segment lost] Encrypted response packet len=128
0.940295 192.168.0.20 -> 192.168.0.250 SSH [TCP Previous segment lost] Encrypted response packet len=128
0.940625 192.168.0.250 -> 192.168.0.20 TCP 2909 > ssh [ACK] Seq=144 Ack=222704 Win=1565 Len=0 TSV=71302953 TSER=627259

La suite demain, je suis claqué là. Merci à tous pour votre aide.

[jibe]

Alors, demain, essaie ce qui t'a été suggéré... Une reconfig seule peut très bien rester sans effet si le problème est ne serait-ce que dans les adresses choisies. Il peut aussi (cela s'est vu souvent) y avoir un problème de mise à jour de la config, c'est pour cela que Gaston t'a demandé certaines manips.

C'est toi qui as l'écran devant les yeux et le clavier sous les doigts. On ne peut que se fier à ce que tu nous dis, et se baser sur ce que tu veux bien faire comme tests. Qu'on y croie ou non, certaines manips sont à faire, ne serait-ce que pour confirmer qu'on a raison de ne pas y croire. Dans un cas comme le tien, on peut s'attendre à tout.

Suis donc pas à pas toutes les manips que t'a données Gaston (si tu ne peux vraiment pas investir moins de 5€ dans un câble croisé, essaie d'en emprunter un, de même qu'un vrai modem, puisque seule la Freebox a été changée) puis donne les résultats que je t'ai demandés. C'est le seul moyen d'avancer : pleurer que ça ne fonctionne pas, appeler à l'aide en affirmant que les causes proposées ne peuvent pas être les bonnes et que les tests demandés sont inutiles ou irréalisables ne peut aboutir à rien. Pas plus que de faire les manips à moitié...