RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Richard REY (Rexy) on 2017-08-26 11:55 | [forum:486820] |
Bonjour, Merci pour ces retours, Voici ce que l'on va tenter... https://adullact.net/forum/forum.php?thread_id=319236&forum_id=1739&group_id=450 |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-20 13:05 | [forum:486754] |
Pour info, la modif que j'ai appliqué dans mon watchdog pour gérer les mises en veilles des appareils nomades est à partir de la ligne 120 : # Ajout 1 ligne + modif condition du if suivant arp_check=`/usr/sbin/arping -b -I$INTIF -s$PRIVATE_IP -c4 -w4 $active_ip | grep -c "Unicast reply"` # If not we disconnect this user. if [ $cmp_user_ok -eq 0 ] && [ $(expr $arp_check) -lt 1 ]; then Si cela peut aider quelqu'un... avec les appareils nomades sur un réseau privé et maîtrisé of course |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-20 12:46 | [forum:486753] |
Pareil pour les tablettes. Dès que Chrome passe en tache de fond ou que la tablette passe en veille ecran, elle ne lance la page still_connected.php que toutes les 5 minutes. Je passe donc le watchdog à 6 minutes dans le cron. Je pense que l'on a trouvé une solution pour les réseaux privés. Reste les publics... |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-20 09:47 | [forum:486751] |
Bonjour, Effectivement, je n'avais pas pensé aux lieux publics.... la machine reste allumée ou en veille. Mais bon, on ne peut pas empêcher un utilisateur de s'en aller sans se déconnecter (enfin, je crois... A creuser....). Votre méthode laisse aussi 3 minutes de latence pour qu'un autre utilisateur profite de la session du précédent. Bref, après avoir mis des traces, je me suis aperçu que quand Safari est réduit dans le dock, la page still_connected.php est appelée toutes les 5 minutes précisément et toutes les minutes quand il a le focus à l'écran. Du coup, dans l'immédiat, je passe le lancement du watchdog à 6 minutes dans le cron. Cela solutionnera mon problème. Reste à tester si cela suffit pour les tablettes android. Il faudrait peut-être prévoir de pouvoir changer la fréquence du watchdog dans l'acc, non ? |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Tom HOUDAYER on 2017-08-19 20:24 | [forum:486748] |
Bon enfaite la méthode en requêtant les données NetFlow n'est pas si bien que ça. Il faut une à quelques minutes pour que les paquets soient visibles via nfdump. Si vous voulez essayé, la commande est : nfdump -q -R /var/log/nfsen/profiles-data/live/alcasar_netflow/ -t $(date +'%Y/%m/%d.%H:%M:%S' -d'3 minutes ago') -s srcip 2>/dev/null | grep -c "\s$active_ip\s". |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Tom HOUDAYER on 2017-08-19 19:19 | [forum:486747] |
Bonjour, Je ne suis pas celui qui maitrise au mieux le sujet, mais je ne pense pas qu'il y ait vraiment une solution parfaite. Pour moi, le mieux serait d'en proposer plusieurs (ex : status.php, ping, autre?...) et de laisser l'administrateur les activer ou non. Bien que la solution actuelle est contraignante, elle permet de déconnecter un utilisateur que se contente de fermer sa session sur un PC public. Or, comme le PC est toujours actif sur le réseau, vos solutions ne déconnecteront pas l'utilisateur. J'ai du mal à représenter les ressources nécessaires pour vos solutions. Celle de Olivier me parait mieux. Parce que dans l'autre, le fichier ip.txt risque de se remplir assez vite sur un grand réseau. Il faudrait faire un essai sur un réseau relativement grand, histoire de voir que le script fonctionnement encore sans prendre toutes les ressources lorsque 100 machines regardent un flux vidéo (par exemple). Étant donné qu'une des fonctionnalités principales d'ALCASAR est l'imputabilité, est-ce qu'il ne suffirait pas de vérifier s'il y a des traces de l'utilisateur dans les 3 dernières minutes grâce à nfdump ? Ceci me semble plus économe et donc plus préférable. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-19 09:47 | [forum:486743] |
Infos supplémentaires : Le service supplémentaire (ou un cron car tcpdump n'a pas de daemon) pourrait être lancé par exemple comme ceci pour deux utilisateurs connectés: "nohup tcpdump -i $INTIF -l -n ip src host host1 or src host host2 and not host 192.168.182.1 ❙ alcasar-filtering.sh" Il doit pouvoir être redémarré à chaque fois qu'un utilisateur se connecte (via alcasar-conup.sh) ou se déconnecte (via alcasar-condown.sh), ou à disparu (via alcasar-watchdog.sh) ainsi que dans la page sertvices de l'acc! alcasar-filtering est en charge d'ecrire qu'une seule ligne (la plus récente écoute) pour chaque @ip host |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-19 07:52 | [forum:486742] |
Bonjour, Je demande à Tom, Rexy et 3abtux (qui maîtrisent le sujet) si la rapide réflexion suivante est judicieuse: Le plus propre, c'est un service supplémentaire dans l'alcasar (alcasar-listening par exemple) qui est un script bash (alcasar-listening.sh par exemple) et qui tourne en permanence, gérable par l'acc (start, stop, restart). Il interroge le chilli à son lancement pour connaitre les machines sur lesquelles un utilisateur est loggué (/usr/sbin/chilli_query list |grep -v "\.0\.0\.0" puis teste si la session est à 1 et le nom de l'utilisateur n'est pas une @MAC). Puis qui lance un tcpdump avec les options "host machine1 or host machine2 or host machine3 and not host alcasar.localdomain...." sur l'interface INTIF. Le tcpdump met déjà un timestamp avec l'heure. Il faut ensuite récupérer la sortie par un pipe redirigé vers un script bash "alcasar-filtre-listening.sh" par exemple qui se charge de n'écrire qu'une seule ligne par machine dans le fichier /var/tmp/havp/current_users.txt (la trace la plus récente avec son timestamp) Ce fichier est ensuite lu toutes les 3 minutes par le watchdog qui vérifie que la machine sur laquelle est loggué un utilisateur a été vue il y a moins de 3 minutes... Sinon, il supprime la ligne adéquate dans "current_users.txt" et déconnecte l'utilisateur. Le service doit être relancé à chaque fois qu'un utilisateur se loggue ou se déloggue dans alcasar-conup.sh et alcasar-condown.sh afin de gérer la suppression ou l'ajout de la ligne contenant l'@IP de l'utilisateur via le paramètre "host" de tcpdump. Du coup, plus besoin d'arping ni que la fenêtre de status soit ouverte ! Reste un problème : Dans le watchdog, il y a également le test d'usurpation. Si les machines ne répondent pas à l'arping, il y aura ce problème aussi car tcpdump n'affiche pas les @MAC.... Hope that helps |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Francois Raoult on 2017-08-18 16:58 | [forum:486739] |
Oui intéressant. En effet ma crainte est que toutes les machines ne répondent pas à l'arping. Avec tcpdump, il y a deux solutions : - Soit autant de process tcpdump (filtrés par grep) que d'IP dans le current_user. Mais effectivement ça risque de nécessiter une bête de course s'il y a beaucoup de machine... - Soit un seul process en tâche de fond, et on procède ainsi : 1. Lancement d'un tcpdump (n'écoutant que sur l'interface LAN/Public "INTIF") qui écrit les IP sources dans un fichier, en y ajoutant un timestamp afin d'obtenir sur chaque ligne IP.IP.IP.IP=timestamp : sudo tcpdump -l -n -i INTIF | grep -P "IP \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" -o | awk '{printf("%s=", $2); system("date +%s")}' >> ip.txt 2. Script qui "nettoie" régulièrement (toutes les minutes ? toutes les 2 minutes ? Toutes les 30 secondes ?... En fonction je pense du nombre de clients) le fichier pour supprimer les IP en double et ne conserver ainsi que les versions avec le timestamp le plus récent : tac ip.txt | sort -u -t"=" -k1,1 > ip-filtered.txt && cat ip2.txt > ip.txt && rm ip-filtered.txt (attention : il est nécessaire d'écrire dans un second fichier puis de reporter ce fichier dans le premier via le cat ... > ... Si on se contente d'envoyer la sortie du sort vers le fichier d'origine ip.txt, celui-ci finit par devenir vide. Si on fait un mv au lieu d'un cat ... > ..., le tcpdump | grep n'est plus capable d'écrire dans le fichier. Je suppose que le mv change l'inode et que le tcpdump se retrouve à écrire dans un inode qui n'existe plus....) 3. Script analysant toutes les 3 minutes maximum (comme le fait le watchdog) le fichier (ici ip.txt) pour associer IP => timestamp. Puis n'écrire dans current_user que les IP ayant envoyé des paquets il y a moins de 3 minutes **ET** que l'IP était déjà autorisée (déjà précédemment dans current_user... attention le watchdog efface ce fichier régulièrement puisqu'il est sensé être reconstruit par status.php qui n'est sensé être appelé que par les clients déjà autorisés/identifiés... Donc il faut mémoriser ailleurs cette liste d'IP autorisés) (les étapes 2 et 3 peuvent n'en former qu'une s'il n'y a pas trop de machines clientes envoyant trop de paquets et que le fichier ip.txt ne risque pas de grossir comme un malade en l'espace de 3 minutes...) J'ai aussi tenté d'envoyer directement la sortie du tcpdump | grep via un pipe dans un script qui vérifierait si l'IP est autorisé et écrirait ainsi le current_user directement, mais du coup ça fait lancer ledit script à chaque paquet (ou "groupe" de paquets, j'ai remarqué que la sortie de tcpdump ralentissait fortement et n'affichait que des "groupes" de ligne dès qu'il y avait un pipe sur sa sortie...) et du coup je ne suis pas persuadé que ce soit beaucoup plus optimisé par rapport à simplement écrire dans un fichier-tampon, nettoyé et analysé uniquement toute les X minutes... |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-18 14:57 | [forum:486738] |
J'avance sur le sujet des déconnexions intempestives : Comme les machines n'écrivent pas suffisamment vite dans le fichier current_users, j'ai complété le test dans le watchdog avec des arping... Je dis "des" car un seul ne suffit pas. Après étude, il apparaît que les tablettes entrée de gamme sous android répondent quelque fois à 2 arping sur 4. Le ping met parfois plus de 1000 millisecondes à revenir !!! Du coup, la modif est : si pas de ligne écrite dans current_users et AUCUN retour arping (alors que j'en lance 4), alors le watchdog déconnecte l'utilisateur. Ce qui permet de ne pas déconnecter les machines dont le navigateur n'a pas le focus, ni si elles sont en veille, car elles sont toujours vivantes, au niveau du réseau. Pour l'instant, ça tient.... Wait and see... |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-17 20:56 | [forum:486733] |
précédemment,c'était des arping qui verifiaient la présence des machines, mais toutes ne répondent visiblement pas. Quant aux tcpdump, cela semble un peu gourmand non? meme avec un pipe sur un grep... a tester. j'ai un site avec 250 machines clientes... va me falloir une bête de course! |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Francois Raoult on 2017-08-17 18:19 | [forum:486732] |
>> "Sous Android 5.1.1 sur tablette : Plus de problème de déconnexion intempestives entre 3 et 6 minutes sur youtube. Les utilisateurs lançaient l'appli youtube et donc chrome passait en arrière plan, ce qui occasionnait les coupures." C'est à mon avis le gros point faible d'alcasar... Lors de l'utilisation du un téléphone, tablette, etc... Le navigateur passe en arrière plan, la page status.php n'est donc plus active... et l'utilisateur finit forcément par se faire déconnecter... De mon côté, j'essaye de réfléchir à une solution... - Venant du serveur : tester si les IP listées dans le fichier current_users sont toujours connectées... (mais tous les terminaux ne répondent pas forcément aux ping ?) - Ou au contraire, en interceptant le trafic (tcpdump ?) : si le trafic vient d'un utilisateur présent dans current_users... bah c'est qu'il est toujours connecté et tout se passe comme si c'était le navigateur qui traitait toujours la page status.php. (mais alors on a un ou plusieurs process tcpdump qui tournent en permanence ?) J'hésite encore sur la meilleure (ou moins pire) solution... Et j'essaye de me demande si ça ne créé pas de vulnérabilité... |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-17 17:23 | [forum:486730] |
Bonjour Tom, après ajout de redirurl dans /etc/chilli.conf + redémarrage du service chilli: Pas vu de problème avec Edge, IE11, Firefox et chrome sur PC et Mac. En revanche, toujours le même problème avec Safari sous Mac. Il doit effectivement se mettre en pause... quand il n'a pas le focus à l'écran. Sous Android 5.1.1 sur tablette : Plus de problème de déconnexion intempestives entre 3 et 6 minutes sur youtube. Les utilisateurs lançaient l'appli youtube et donc chrome passait en arrière plan, ce qui occasionnait les coupures. Ils leurs suffisaient de lancer youtube via chrome, directement sur la page web. Je les ai sensibilisés. On continue les tests. Merci pour les infos. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-17 09:21 | [forum:486719] |
Bonjour Tom, merci, j'ai appliqué la modif et je lance mes utilisateurs sur les tests. Je vous tiens au courant. Pour la part, je. n´ai pas été coupé pendant plus d'une heure sur firefox. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Tom HOUDAYER on 2017-08-16 18:42 | [forum:486716] |
Bonjour, Après quelques recherches dans le code de CoovaChilli, je pense avoir trouvé la solution. Il suffit d'ajouter une ligne "redirurl" dans le fichier e configuration ("/etc/chilli.conf"). Pouvez-vous me confirmer que ça marche de votre côté ? |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Olivier C on 2017-08-09 19:54 | [forum:486682] |
bonjour, je n'utilisais pas cette fonctionnalité jusqu'en 3.0.1 car la page par defaut des navigateurs s'ouvraient bien après authentification. Depuis la 3.0.1, comme je n'ai plus de fenetre status mais un onglet qui s'ouvre et que la page par defaut dans les navigateurs ne s'ouvrent plus, j'ai été obligé de mettre une page par défaut dans les groupes. je n'ai pas eu le temps de tester complètement la 3.0.1 et les suivantes. je suis maintenant en 3.0.4 et les utilisateurs me remontent seulement maintenant le problème. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Corentin Joubert on 2017-08-09 15:29 | [forum:486681] |
Bonjour, cette fonctionnalité était utiliser en version 2.9.2 et il n'y avait aucun soucis |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : jean-sebastien Hesry on 2017-08-09 15:19 | [forum:486680] |
Bonjour, désolé non je n'utilisai pas cette fonction avant. Cordialement. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Tom HOUDAYER on 2017-08-09 15:11 | [forum:486679] |
Merci Jean-Sebastien, le problème vient bien des URL de redirection affectées à un utilisateur/groupe. Dans ce cas, CoovaChilli redirige directement l'utilisateur sans repasser par intercept.php (qui se charge normalement d'ouvrir status.php). Ce problème existe-t-il seulement depuis les dernières versions d'ALCASAR ? Ou vous n'utilisiez pas cette fonctionnalité avant ? |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : jean-sebastien Hesry on 2017-08-09 13:41 | [forum:486678] |
En faisant mes divers test j'ai remarquer un autre petit bug. Quand je modifie un user le champs mot de passe et remis a zéro donc si on retape pas le mot de passe il passe en champ vide. Ces un peu pénible que lorsque qu'on fait une modif on doit retapez le mot de passe en tous qu'à je trouve mais je suis peu être le seul à le penser. En tous cas merci pour cette Appliance qui marche relativement bien et pour le suivi qui vous effectuer régulièrement et qui en fait son intérêt. Merci. Cordialement. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : jean-sebastien Hesry on 2017-08-09 12:51 | [forum:486677] |
Bonjour, j'avais mis à tous mes utilisateurs un URL DE REDIRECTION(HTTP:\\www.google.fr) et effectivement après que mes Users se connectent la page de status s'efface et ils allaient directement sur Google. Il semblerai que si je supprime la redirection sa fonctionne. je continu mon test. Merci pour les pistes de réponses. Cordialement. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Corentin Joubert on 2017-08-09 12:33 | [forum:486676] |
je suis rediriger vers http://www.challans.fr car c'est la page que nous avons mis par défaut pour les utilisateurs je travail sous Windows 10 avec Firefox 45esr mais j'ai exactement le même problème avec androïde et d'autre pc. |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Tom HOUDAYER on 2017-08-09 12:11 | [forum:486675] |
Vous êtes donc redirigé vers la page initialement requêtée (ou "www.euronews.com" par défaut) ? Quel navigateur et système d'exploitation utilisez-vous ? |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Corentin Joubert on 2017-08-09 11:49 | [forum:486674] |
Quand je saisi les infos de connexion la page status.php ne se lance pas |
RE: alcasar 3.1.4 deconnection [ Répondre ] Par : Tom HOUDAYER on 2017-08-09 11:42 | [forum:486673] |
Bonjour Corentin, Effectivement, il est normal que les utilisateurs se fassent déconnecter si la page status.php n'est pas ouverte. Que se passe-t-il lors de la soumission du formulaire de connexion ? |
Messages plus anciens |