Bla bla bla, boring and very long introduction that no ones cares about.
Install openfortivpn from Debian's repositories:
sudo apt install openfortivpn
Open a web browser and log in to your organization's fortinet SSL-VPN portal. Right click anywhere on the page, Inspect, and go to the Network tab in order to copy the SVPNCOOKIE= cookie.
Now open a terminal and run:
sudo openfortivpn --cookie SVPNCOOKIE=....
And voila!
Sometimes the connection may fail with the following error:
ERROR: Could not get VPN configuration (HTTP status code).
For some reason this often happens to me when I use Firefox to grab the cookie, however I have no problem with google-chrome. I haven't tested other browsers.
Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.
La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:
Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.
Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.
Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.
Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.
Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)
J'ai été client Free Mobile en 2012 mais cela n'a pas duré car au bout de 6 mois la qualité du réseau internet 3G s'est considérablement dégradée : les sites en https, Youtube et Google Play ne marchaient plus du tout. Ce problème est connu depuis toujours et survient lorsque l'abonné accroche une antenne Orange en itinérance, et c'est souvent le cas vu qu'il y a peu d'antennes Free Mobile.
J'ai récemment retenté l'expérience car mademoiselle utux, ma copine, avait besoin d'un forfait pas cher. J'ai sauté sur une vente privée à 3,99€ / mois pour le forfait normalement proposé à 19,99€ et dès réception de la carte SIM nous avons pu l'essayer. Il s'avère qu'en ville (Nantes) ça marche plutôt bien car y a beaucoup d'antennes Free Mobile, par contre en campagne c'est la galère, on passe toujours sur de l'itinérance Orange et donc internet ne fonctionne plus. Sur l'autoroute par exemple il est impossible de lire une vidéo Youtube et difficile de charger une carte sur Google Maps alors que mon téléphone sous Sosh n'a aucun problème (nous l'avons d'ailleurs utilisé comme point d'accès durant le voyage).
Free Mobile en 2016 c'est donc toujours du vent, du bluff renforcé par des publicités et des tarifs agressifs agrémentés de dénigrement de la concurrence. Et ce marketing est visiblement efficace car on trouve beaucoup de gens persuadés que si tu n'as pas 50GB de data dans ton forfait c'est que tu es un pigeon. Je n'utilise jamais plus de 500 Mo par mois même avec de la synchronisation ActiveSync (YunoHost + Z-Push) et la seule fois où j'ai atteint ma limite de consommation (3Go à l'époque, 5Go aujourd'hui) est quand j'ai passé 1 semaine sans connexion à internet fixe.
L'accord d'itinérance Free / Orange n'est pas éternel et le désengagement va d'ailleurs bientôt commencer. Lorsque les vannes seront totalement coupées tous ceux qui n'habitent pas en ville vont se retrouver en zone blanche et cela représente beaucoup de monde.
Tout a commencé avec des problèmes de lenteur sur notre connexion à internet au bureau. Un petit tour dans l'interface d'administration de la Freebox a montré une utilisation importante de la bande passante en upload même la nuit lorsque toutes les stations de travail sont éteintes. Heureusement derrière la Freebox il y a un routeur sous Linux par lequel tout le trafic passe, nous avons donc des outils plus poussés pour analyser ce qui transite.
iptraf a montré que le trafic n'était pas émis depuis une station de travail mais était généré en local (par le routeur lui-même) : était-il compromis ? Présence d'un rootkit ? Une petite vérification des processus avec ps et top semble indiquer que non, rien d'anormal. J'ai également vérifié à coup de md5sum que les binaires bash, ps, w, who, top n'avaient pas été altérés (en comparant avec une version sauvegardée il y a 1 mois).
Donc le routeur génère le trafic mais ne semble pas compromis, d'où vient donc le problème ? Sortons l'artillerie lourde : tcpdump. On sniffe 10secondes de trafic puis on récupère notre fichier pour l'ouvrir dans wireshark, c'est plus simple à lire. L'analyse montre un trafic composé exclusivement de paquets UDP / protocole Portmap. Une petite recherche rapide sur Google "high portmap trafic" me mène vers des articles d'Aout 2015 détaillant une forme de ddos basée sur portmap. C'est un ddos par amplification, c'est à dire que nous recevons des requêtes forgées qui font que nous générons ensuite des attaques vers d'autres serveurs. Or il se trouve que suite à un lourd historique (dette technique) la configuration du pare-feu était incorrecte et le port 111/UDP (portmap) du routeur était accessible depuis internet. La fermeture de ce port a mis fin aux attaques.
tcpdump / wireshark sont les meilleurs amis du sysadmin, et j'ai découvert également iptraf qui permet d'avoir une vue d'ensemble du trafic ce qui permet d'établir un premier diagnostic. Un pare-feu bien configuré est indispensable car même si des services ne sont pas utilisés ou sont censés répondre uniquement en local, des failles sont toujours possibles.