IPBan pour Windows Serveur.

Même s'il est préférable (et je vous le recommande) de ne pas exposer directement des serveurs sur internet, l'idéal est faire ça avec un reverse proxy, on n'a parfois pas le choix. Le confinement l'a démontré ou en urgence pas mal d'entreprises n'ont eu d'autres choix que d'exposer à la va-vite des serveurs RDP sur Internet à des fin de télétravail. La moindre des chose serait d'utiliser un VPN ou une passerelle RDP comme Guacamole, mais si ce n'est pas possible il faut sécuriser au maximum, RDP, pour ne citer que lui étant très vulnérable.

Je ne vais pas parler de ce qui est à faire sous Linux mais pour les serveurs Windows.

On a deux étapes :

  • Le firewall intégré
  • La protection des applications

Le firewall

Contrairement à une légende urbaine, le firewall intégré à Windows est solide, à condition toutefois de le configurer correctement et de n'exposer que ce qui est réellement utile.

Il y a 3 catégorie auxquelles on affecte les règles : Public, Private et Domain (équivalent Private si on est connecté à un domaine Active Directory).

Si on expose un Windows sur Internet la première chose à considérer est que l'interface exposée doit se trouver en mode Public :

PS C:\Users\Administrator> Get-NetConnectionProfile

Name             : Network 5
InterfaceAlias   : WAN
InterfaceIndex   : 3
NetworkCategory  : Private
IPv4Connectivity : Internet
IPv6Connectivity : Internet

Si ce n'est pas le cas, comme dans cet exemple on ajuste avec :

PS C:\> Set-NetConnectionProfile -InterfaceIndex 3 -NetworkCategory Public

Cette considération étant prise en compte, de base très peu de choses sont exposées en Public et on pourra ouvrir un port pour laisser passer un service. Et idéalement s'il s'agit de RDP on va restreindre cette exposition aux IP des clients... Idéalement, car dans la pratique peu de client disposent d'IP fixes et certains services doivent êtres accessibles de façon universelle.

L'interface du firewall de Windows datant du siècle dernier on pourra avantageusement se servir de eu se servir de WFC (récemment acquis par Malwarebytes) afin de le gérer plus facilement.

A ce stade on teste avec avec un scan externe afin de s'assurer que seul le ports utiles sont ouverts (Advanced port Scanner ou NMap par exemple)

Mails il va donc falloir renforcer cette sécurité par d'autres moyens !

Sous Windows il existe une seconde couche de défense moins connue : WFP (Windows Filtering Platform). Si WFP peut être très efficace, sa configuration est délicate et se passe en PowerShell, ce qui la rend peu accessible. Et c'est ici que va rentrer en action IPBan qui un peu à la manière de Fail2ban disponible sous Linux va nous permettre d'ajouter une ligne de défense supplémentaire.

IPBan

D'abord une petite précision, il existe deux versions d'IPBan :

  • Une version gratuite sans interface qui travaille uniquement avec un fichier de configuration XML qui donne mal au crane et surtout qui s'appuie uniquement sur le firewall de Windows.
  • Une version pro et payante qui dispose d'une interface et s'appuie sur WFP pour plus de réactivité. Cette interface peut être locale ou centralisée afin de gérer plusieurs serveurs.

C'est la version Pro à laquelle on va s'intéresser ici. Son cout annuel n'est pas prohibitif ($ 29.00 pour un serveur et $ 99.00 pour tous vos serveurs) si on le compare à d'autres produits qui en font moins pour bien plus cher. Cerise sur la gâteau, le support par mail ou sur Discord est vraiment très réactif !

La fonction de base d'IPBan est d'interdire l'accès à une IP après x tentatives infructueuses de connexion. 

De base il va surveiller les applications suivantes grâce aux Events de Windows, mais égaiement aux logs des applications :

  • OpenSSH
  • Microsoft Exchange
  • SmarterMail
  • MailEnable
  • Apache Tomcat
  • RDP
  • Microsoft SQL
  • MySQL
  • Postgre SQL
  • PhpMyAdmin
  • VNC
  • RRAS
  • SVN

Mais ce n'est pas limitatif et l'administrateur peut également ajouter ses propres surveillances en lui demandant d'aller scanner events et logs. Le GitHub de l'éditeur héberge d'ailleurs un certain nombre d'intégrations personnalisée qui vous faciliteront la tache, en voici un exemple pour surveiller le serveur FTP de Filezilla :

<LogFile>
	<Source>Filezilla</Source>
	<PathAndMask>C:\Program Files (x86)\FileZilla Server\Logs</PathAndMask>
	<FailedLoginRegex>
		<![CDATA[
			(?<timestamp>[^\s]+)\s.*\s\[FTP\sSession\s[0-9]+\s(?<ipaddress>[^\]]+)\]\sUSER\s(?<username>[^\n]+)\n.*\sspecify\sthe\spassword[^\n]*\n.*\sPASS\s[^\n]*\n.*\s(?<log>Login\s(?:or\spassword\s)?incorrect)[^\n]*
		]]>
	</FailedLoginRegex>
	<FailedLoginRegexTimestampFormat></FailedLoginRegexTimestampFormat>
	<SuccessfulLoginRegex>
		<![CDATA[
			(?<timestamp>[^\s]+)\s.*\s\[FTP\sSession\s[0-9]+\s(?<ipaddress>[^\]]+)\]\sPASS\s[^\n]*\n.*\[FTP\sSession\s[0-9]+\s[^\s]+\s(?<username>[^\]]+)\].*Login\ssuccessful[^\n]*
		]]>
	</SuccessfulLoginRegex>
	<SuccessfulLoginRegexTimestampFormat></SuccessfulLoginRegexTimestampFormat>
	<PlatformRegex>Windows</PlatformRegex>
	<PingInterval>10000</PingInterval>
	<MaxFileSize>0</MaxFileSize>
	<FailedLoginThreshold>0</FailedLoginThreshold>
</LogFile>

Au delà de ce blocage d'IP via WFP, il est également possible de :

  • Visualiser facilement les connections valides
  • Gérer des listes blanches et noires
  • Vous notifier
  • Bloquer ou autoriser les connections en provenance de certains pays (GeoIP)
  • Bloquer certains ASN
  • Bloquer des listes d'IP de réputation douteuse en s'abonant à des listes partagées.
  • Se synchroniser avec le reverse proxy de Cloudflare
  • ...

En conclusion c'est l'outil indispensable pour qui doit exposer un serveur directement sur Internet !

IPv6 @ Scaleway...

Depuis plus de 20 ans tout le monde parle d'IPv6, mais dans la pratique ce n'est pas encore l'euphorie au niveau de l'adoption. En France, une fois n'es pas coutume, on est un peu en avance, Free en tête qui a passé tout son réseau fibre en IPv6. En fait du 4rd pleinement documenté dans le RFC 7600. Dans la pratique c'est du tunneling (donc 2 clients qui discutent en IPv4 le font par un tunnel direct au dessus de leur IPv6, ca ne passe par une passerelle).  Par contre à ce que j'ai pu lire la sortie IPv4 vers le reste du monde ce fait via des 'Border Relay 4rd' ou du NAT64+. Et là si ces équipement ne sont pas suffisamment dimensionnés ça peut créer un goulot d'étranglement.

Il y a quelques temps je me suis aperçu que l'un de nos serveurs hébergé chez Scaleway présentait en soirée une importance latence, voire des lags pour les clients Free, ce qui est un comble car Free et Scaleway font partie de la même boutique !

Il semble donc qu'il y ait un entonnoir au niveau de la passerelle de sortie vers l'IPv6. Je ne connais pas les détails de l'infrastructure Free, mais je me suis dit qu'en rendant mon serveur accessible en IPv6 je pourrais contourner le problème, et que de toutes façons il était temps que je passe ma part d'IPv6 !

Sauf que ce n'est pas si simple, d'une par je n'ai jamais pratiqué, et d'autre par la documentation fournie par Scaleway est obsolète.

Chez Scaleway j'ai deux types d'approche, des serveurs loués (Dédibox) et une infra avec les propres serveurs installés dans une baie louée (Dédirack). Mon serveur étant une VM sous Windows 2019 sur un serveur Dédibox je me suis basé sur la documentation officielle qui fait référence à la fourniture d'un DUID (sur la console Online) après avoir demandé un bloc IPv6 et passé le serveur en SLAAC. Au vu des captures d'écrans cette doc doit dater de l'époque Windows NT (siècle dernier), j'espère qu'ils vont  la mettre à jour, aussi je mets les copies d'écran de la version actuelle ici : 1 | 2 .

Cette documentation mets en avant l'utilisation du DUID en modifiant une clé de registre de Windows. Hors changer le DUID dans l'implémentation Windows est devenu impossible comme l’expliquent ces deux articles parmi tant d’autres 1 | 2.

Le DUID change maintenant à chaque reboot en se basant sur l'adresse MAC de l’interface. C'est maintenant le comportement normal et attendu. Cette doc n'a donc plus lieu d'être dans sa version actuelle !

En fait pour obtenir une IPv6 sous Windows il n'y a rien de plus à faire que d'activer le stack IPv6 de Windows par défaut (client DHCP) (après avoir demandé un bloc IPv6 /48). Et c'est tout, l'obtention de l'IPv6 se fait via le serveur DHCPv6 de l'infrastructure Scaleway (il est également possible de renseigner une adresse prise dans le bloc).

Alors, pourquoi toute cette galère depuis des mois ?

Je me suis obstiné sur l'utilisation du DUID que la documentation mets en avant ! Normal j'ai appris à lire. Et d’autres sites y font référence. Ensuite il se trouve que cette machine avait un firewall plutôt blindé, et comme elle n'utilisait pas d'IPv6 auparavant tous les entrées Core Networking IPv6 étaient désactivées, donc les échanges avec le DHCPv6 et RA ne pouvaient pas se faire correctement. Je les ai réactivés dès lors que j’ai compris que la première option était obsolète.

A aucun moment le support Scaleway n'a su me dire qu'il ne fallait pas poursuivre dans la voie du DUID, ce qui aurait évité une perte de temps de toutes parts ! Le ticket de support n’est surement pas remonté auprès des bonnes personne et la culture Windows pas très présente, et meme si je les comprends il est impossible aujourd'hui d'ignorer le monde Microsoft !

Par contre de base Windows génère une IPv6 aléatoire, ce qui peut être utile sur un client mais gênante sur un serveur, on désactive en PS:

  Set-NetIPv6Protocol -RandomizeIdentifiers Disabled

Ou :

  netsh interface ipv6 set global randomizeidentifiers=disabled store=active
  netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
  netsh interface ipv6 set privacy state=disabled store=active
  netsh interface ipv6 set privacy state=disabled store=persistent

On peut également désactiver l'utilisation d'une IPv6 temporaire :

  Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

Voilà, en espérant que Scaleway clarifie son article car si le passage de l'utilisation d'un DUID à du full DHCPv6 facilite largement la tâche, encore faut-il l'expliquer ! Je n'ai pas testé sous Linux, mais sous pfsense ou OPNsense la procédure est relativement identique.

Et dans un Dédirack ?

On aurait pu penser au vu de la console Online qui affiche sur une même pages les infos réseau de mon Dédirack (IPv4) et de mon bloc IPv6 /48 que ce bloc soit également utilisable dans la baie Dédirack. Mais non, après avoir lourdement insisté auprès du support j'ai enfin eu la réponse :

Pour faire de l'IPv6 dans un Dédirack (offre housing de Scaleway), il faut demander au support un bloc /48 et ensuite le gérer en statique à sa convenance. Ca ne s'invente pas.

Et ça fonctionne ? Et bien non, car il aura fallu plusieurs jours et plusieurs personnes pour que l'on s'aperçoive que quelqu'un ne sais pas faire de copié/collé chez eux (ou un farceur ?), et que dans le bloc /48 que l'on m'a fourni il y avait un C00D qu'il fallait lire C00C !

Et sur l'offre Elastic Metal ?

Je n'ai pas encore testé, mais j'y ai installé un serveur ESXi et je crois savoir que la procédure est encore différente.

Sources et liens

 

Chat's & Business

Petit à petit les messageries de type chat se sont imposées en entreprise, mais également entre les entreprises. Le but étant de garder le contact, de proposer / obtenir des réponses rapides et surtout de délester le mail souvent surchargé et parfois traité qu'une seule fois par jour, un peu comme le facteur qui jadis passait le matin... Au fil de ces dernières années certaines ont bien évoluées, tandis que d'autres s'imposaient par la force. Chacun ses préférences, mais je vais essayer de faire le tour de la question.

Attention, le seule option qui m'intéresse ici dans ces applications c'est le chat !

Je vais en retenir seulement quelques une, certaines sont à réserver à la sphère privée même si on les retrouve souvent en usage professionnel :

  • Messenger Facebook (Meta) : Usage privé, à proscrire en entre pro. Idem pour celle d'Instagram !
  • WhatsApp (Meta) : Usage privé. Je déteste quand un client me contacte par ce biais là. Je le ressent comme une intrusion. Il n'en reste pas moins que si l'on dispose que d'un seul numéro de mobile c'est inévitable. Il existe également une version business orientée B2C.
  • Google Chat : Le renouveau, et mon préféré !
  • Microsoft Teams : Imposé au forceps, lourd et confus.
  • Slack : Bien, mais couteux !
  • Telegram : Usage geek (et mafieux ?). L'entreprise n'est pas la cible. Par contre Telegram est beaucoup utilisé pour des groupes de discutions thématiques, usage auquel il est adapté et ou il se pose en concurrence avec les forums.
  • Signal : A réserver à un usage ou l'on recherche un maximum de confidentialité. Probablement le meilleur sur ce point. Pas d'intégration web.
  • Olvid : Il parait qu'il faut laisser cette application à nos gouvernants, la PM l'ayant imposé. Curieux pour un produit finalement pas si Français, avec un actionnariat luxembourgeois et un hébergement chez AWS...

A noter qu'avec le RCS les SMS peuvent s'apparenter à des messageries Chat. Tout comme l'a fait Apple avec iMessage, et ça sera encore plus le cas avec l'adoption par ce dernier du protocole RCS.

Je ne vais pas toutes les traiter car de mon point de vue certains n'ont pas leur place en entreprise ou en B2B. Soit parce que je les estime destiné à un usage privé, ce qui permet de poser des limites, soit parce que trop spécifiques. Les trois dont je vais parler disposent de clients mobile et desktop, mais également d'une version web qui permet de les intégrer à un agrégateur d'applications web comme WebCalatog (que je recommande), SideKick ou encore Ferdium (il en existe d'autres). Ces utilitaires permettent de rassemble en un seul endroit tous les chat's...

Microsoft Teams

Après avoir saboté MSN Messenger et cannibalisée Skype, Microsoft a fini par imposer Teams en profitant du confinement et surtout en l'incluant gratuitement dans toutes les offres 365. La méthode est plus que discutable et les différentes autorités de régulation se sont emparées du dossier suite à une plainte de Slack. Il n'en reste pas moins que Teams est devenu omniprésent et que le ver est dans la pomme. Même si beaucoup l'utilisent que pour du chat ou des réunions en visio, Teams va beaucoup plus loin en termes de fonctionnalités, certes utiles dans une multinationale, mais au point de rapidement perdre les utilisateurs. C'est mon cas et je n'utilise que le chat pour communiquer avec des contacts dont c'est le seul canal possible.

Teams a été conçu pour de très grandes entreprises et les échanges entre des utilisateurs de tenants différents sont limités et nécessitent une approbation. Essayez donc de faire glisser un document dans une conversation avec un contact externe. Impossible en a décidé Microsoft, pas plus que vous ne verrez les photos de profil de vos contacts externes. C'est comme ça, by design, simplement parce que ce n'est pas la cible. A destination des marchés SMB, Microsoft avait lancé il y a quelques années Kaizala, une sorte de clone de WhatsApp. Vous ne connaissez pas, normal, car rapidement retirée.

Bref, vous l'aurez compris je déteste Teams, mais je suis contraint de l'utiliser.

Slack

Comment justifier une licence de 6 à 12 € par mois et par utilisateur quand l'entreprise dispose déjà de Teams gratuitement ? Slack est un produit très intéressant et bien ficelé, jadis il était utilisable dans sa formule gratuite, hélas de plus en plus restrictive (3 mois d'historique seulement), ce qui me pousse à l'abandonner. Slack n'est toutefois pas exempt de défaut, et dans bien des facettes n'est pas vraiment adapté à l'utilisation facile inter entreprise. Slack c'est SalesForce, la cible principale n'est pas non plus les petites entreprises. Adieu Slack, je t'aimais bien, avant !

Google Chat

Et puis il y a le cas du (méchant) Google. Après des années d'errances (Hangouts) et de produits mal ficelés, je dois dire que je trouve l'actuelle version de Google Chat très séduisante. Elle n'impose pas de restrictions de communication entre les utilisateurs, qu'il s'agisse d'un simple compte Google personnel et gratuit ou d'un compte Google Workspace d'entreprise. L'interopérabilité est totale et l'interface claire et simple pour le chat, mais également des espaces de travail comme le propose Microsoft, mais de façon simple, intuitive et surtout légère. On peut dire qu'ils reviennent de loin, mais hélas Teams a entre temps cueilli le marché et j'y ai peu de contacts.

Alternatives ?

On ne vas pas ressortir ICQ et tout ce qui fonctionne sur la base IRC ou Jabber, voire Trillian. En intra entreprises certains pourront opter pour ce qui est proposé par Synology ou d'autres applications en auto hébergement, mais pas adapté au B2B. Il est également possible d'opter pour Discord, au départ dédié au gamers, certains l'utilisent en mode professionnel. Tout comme Zoom qui nous rappelle le confinement !

Les suisses proposent également Threema qui semble un beau produit destiné tant aux particuliers qu'au entreprise et qui préserve la confidentialité et la vie privé. Mais personne en connait en France !

Il n'en reste pas moins que le marché ne propose rien d'universel. La CE travaille à imposer une interopérabilité entre les messageries, à l'instar de ce qui existe pour le mail ou la téléphonie. Mais je doute fort de voir des résultats rapides et pour un bout de temps on sera encore contraints d'utiliser plusieurs clients.

 

AutoDiscover & AutoConfig IMAP/SMTP

En 2020, pour m'occuper pendant le confinement, j'avais écrit un article sur la configuration automatique des clients POP/IMAP. Ca fonctionnait sur Thunderbird, mais pas sur les clients Microsoft... Bon, les clients Microsoft il y en a de plusieurs sorte (Courrier, Outlook nouveau, ancien, 365, jadis Express et j'en passe) et la chose n'est (volontairement ?) pas simple. On va oublier les versions 365 qui même si elles supportent IMAP le font mal et ne sont pas vraiment destinés à cet usage mais plus à du MAPI.

Pour cet article j'ai monté un serveur Cloudron. Ce projet gère très bien le mail dans sa version de base gratuite. Hélas il ne gère pas la configuration des clients, ce qui est regrettable car il pourrait très facilement intégrer ce qui suit afin d'être totalement dans la philosophie du projet intégré !

Il existe plusieurs façons de faire de l'AutoDiscovery ou de l'AutoConfig

La méthode RFC 6186

Elle se base sur des enregistrements DNS :

_imap._tcp 300 IN SRV 0 0 0 .
_imaps._tcp 300 IN SRV 0 1 993 mail.domain.tld.
_pop3._tcp 300 IN SRV 0 0 0 .
_pop3s._tcp 300 IN SRV 10 1 995 mail.domain.tld.
_submission._tcp 300 IN SRV 0 0 0 .
_submissions._tcp 300 IN SRV 0 1 587 mail.domain.tld.

Normalisée mais visiblement trop simple est abandonnée. Encore que certaines versions d'Outlook utiliseraient ça. Etrange.

La méthode Thunderbird 

Thunderbird va chercher les paramètres dans un fichier XML sur l'url :

http://autoconfig.domain.tld/mail/config-v1.1.xml

La méthode Outlook

Outlook cherche l’enregistrement DNS de type SRV :

_autodiscover._tcp.domain.tld 3600 IN SRV 10 10 443 autodiscover.domain.tld.

qui va lui donner l'adresse ou interroger le fichier XML, donc un CNAME qui pointe sur le serveur web qui héberger le fichier XML, ce qui au final donnera une requête sur

https://autodiscover.domain.tld/AutoDiscover/AutoDiscover.xml

Simple ! Attention à bien respecter la casse du mot AutoDiscover... Et ne pas oublier que dans le cas Microsoft on travaille en HTTPS. Dans certains cas on pourrait faire pointer ça sur n'importe quelle url, mais il semblerait que certaines versions d'Outlook (et il y en a !) cherchent une url qui commence par autodiscover...

Un site pour les rassembler

Dans la méthode qui va suivre on va utiliser un seul site capable de répondre aux url autoconfig et autodiscover, on renseignera donc ces enregistrement dans le dns :

_autodiscover._tcp.domain.tld 1800 IN SRV 10 10 443 autodiscover.domain.tld.
autoconfig 1800 IN CNAME web_server.domain.tld.
autodiscover 1080 IN CNAME web_server.domain.tld.

Ensuite on crée un site web capable de répondre à ces deux url pour l'ensemble des domaines de messagerie pour lesquels on souhaite proposer ce service. Le site doit répondre en HTTP et HTTPS, mais surtout sans redirection automatique HTTP vers HTTPS. Pour cet exemple j'ai utilisé un serveur web NGINX avec du PHP.

On va utiliser ce code que j'ai trouvé ici, je l'ai utilisé tel que en adaptant les enregistrements DNS et les redirections pour NGINX que l'on verra après le code. On copie donc ce code PHP dans autoconfig-mail.php :

<?php
 
/*
By David Mercereau
Licence Beerware
*/
 
function extract_domain($domain) {
    if(preg_match("/(?P<domain>[a-z0-9][a-z0-9\-]{1,63}\.[a-z\.]{2,6})$/i", $domain, $matches)) {
        return $matches['domain'];
    } else {
        return $domain;
    }
}
 
$domain = extract_domain($_SERVER['SERVER_NAME']);
$mailServeur='mail.'.$domain;
 
if (preg_match('/^\/mail\/config-v1\.1\.xml/', $_SERVER['REQUEST_URI'])) {
    header('Content-Type: text/xml');
    header('Content-Type: application/xml');
    ?>
<clientConfig version="1.1">
    <emailProvider id="<?= $domain ?>">
      <domain><?= $domain ?></domain>
      <displayName><?= $domain ?></displayName>
      <displayShortName><?= $domain ?></displayShortName>
      <incomingServer type="imap">
         <hostname><?= $mailServeur ?></hostname>
         <port>143</port>
         <socketType>STARTTLS</socketType>
         <username>%EMAILADDRESS%</username>
         <authentication>password-cleartext</authentication>
      </incomingServer>
      <outgoingServer type="smtp">
         <hostname><?= $mailServeur ?></hostname>
         <port>587</port>
         <socketType>STARTTLS</socketType>
         <username>%EMAILADDRESS%</username>
         <authentication>password-cleartext</authentication>
      </outgoingServer>
      <documentation url="https://webmail.<?= $domain ?>">
          <descr lang="fr">Connexion Webmail</descr>
          <descr lang="en">Webmail connexion</descr>
      </documentation>
      <documentation url="http://projet.retzo.net/projects/hebergement/wiki">
        <descr lang="fr">Documentation</descr>
        <descr lang="en">Generic settings page</descr>
      </documentation>
    </emailProvider>
</clientConfig>
    <?php
} else {
    // Outlook
    //get raw POST data so we can extract the email address
    $data = file_get_contents("php://input");
    preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $data, $matches);
 
    //set Content-Type
    header('Content-Type: text/xml');
    header('Content-Type: application/xml');
    echo '<?xml version="1.0" encoding="utf-8" ?>'; 
    ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
   <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
       <Account>
           <AccountType>email</AccountType>
           <Action>settings</Action>
           <Protocol>
               <Type>IMAP</Type>
               <Server><?= $mailServeur ?></Server>
               <Port>993</Port>
               <DomainRequired>off</DomainRequired>
               <LoginName><?php echo $matches[1]; ?></LoginName>
               <SPA>off</SPA>
               <SSL>on</SSL>
               <AuthRequired>on</AuthRequired>
           </Protocol>
           <Protocol>
               <Type>POP3</Type>
               <Server><?= $mailServeur ?></Server>
               <Port>995</Port>
               <DomainRequired>off</DomainRequired>
               <LoginName><?php echo $matches[1]; ?></LoginName>
               <SPA>off</SPA>
               <SSL>on</SSL>
               <AuthRequired>on</AuthRequired>
           </Protocol>
           <Protocol>
               <Type>SMTP</Type>
               <Server><?= $mailServeur ?></Server>
               <Port>587</Port>
               <DomainRequired>off</DomainRequired>
               <LoginName><?php echo $matches[1]; ?></LoginName>
               <SPA>off</SPA>
               <Encryption>TLS</Encryption>
               <AuthRequired>on</AuthRequired>
               <UsePOPAuth>off</UsePOPAuth>
               <SMTPLast>off</SMTPLast>
           </Protocol>
       </Account>
   </Response>
</Autodiscover>
    <?php
}
 
?>

Ensuite dans configuration NGINX on ajoute les redirections suivantes qui va permettre de servir la bonne version XML selon que la requête utilise la méthode Outlook ou Thunderbird (attention à la casse...) :

location /AutoDiscover {
  rewrite ^/AutoDiscover/AutoDiscover.xml /autoconfig-mail.php;
}
location /mail {
  rewrite ^/mail/config-v1.1.xml /autoconfig-mail.php;
}

Sources


https://github.com/gronke/email-autodiscover
https://github.com/SpicyWeb-de/isp-mailConfig

RustDesk

Au fil des ans TeamViewer s’est imposé dans l'IT. Au départ pseudo gratuit ce produit offre maintenant de plus en plus de fonctionnalités (souvent inutiles) et son cout augmente d’années en années. On pourrait imaginer le remplacer par AnyDesk, mais hélas leur politique est quasiment identique et ce serait reculer pour mieux sauter.

Pendant le confinement certains en ont eu assez de se faire “raquetter”. Si le mot vous parait fort, constatez simplement les augmentations successives dont la dernière de 20% que rien ne justifie à mes yeux, l'éditeur se justifiant quant à lui par l'ajout de fonctionnalités qui me sont inutiles. Entendons nous bien, tout a un prix et tout travail ou service mérite une rémunération, mais tout doit rester dans la nuance, même quand on se retrouve dans une position de domination, ce qui est d'ailleurs le cas pour d'autres, comme Microsoft et ses dernières augmentations au niveau 365 ou Azure...

Bref, c'est donc ainsi qu'une petite équipe de développeurs a créé RustDesk. RustDesk offre les mêmes fonctionnalités de base dans le cadre de l’open source. Je teste Rustdesk depuis près d’un an et j’estime que l’heure est venue de franchir le pas.

RustDesk est disponible sous différentes distributions Linux, MacOS, Windows, Android et IOS.

Il existe plusieurs façons d’utiliser RustDesk :

Version isolée sans serveur

La plus simple et totalement gratuite, mais qui présente quelques inconvénients :

  • Pas de chiffrement, cela veut dire que toutes les infos circulent en clair (pas sécure pour les clients, mauvaise pratique).
  • Lenteurs possibles car ça utilise les serveurs publics, ce qui reste limité.
  • Pas de carnet d’adresse synchronisé entre les devices clients. Et là ça bloque car comme beaucoup de monde j'utilise un PC fixe au bureau et un laptop quand je me déplace, sur lequel je souhaite retrouver mon environnement de travail. Ils auraient pu envisager une synchronisation de type "drive", mais cela aurait posé des questions de sécurité car en plus de synchroniser les identifiants il faut stocker des mots de passe.

Version gratuite avec serveur

Toujours gratuit (en dehors du cout d'un serveur VPS (qui peut être mutualisé)), et on résous la question du chiffrement :

  • Le serveur sert de relais (amélioration de la vitesse) et de serveur de chiffrement afin de sécuriser les liens.

Version payante avec serveur privé

La totale qui va couter quelques euros (10 € / mois pour deux utilisateurs, ou 20 € /mois pour 20 utilisateurs + le serveur), mais à mon sens indispensable dans un cadre professionnel

  • Le serveur offre une console qui permet de lister les clients installés et éventuellement les partager
    • Seul l’admin peut activer les partages à ce stade. Partager fait remonter les ID pour un autre utilisateur, mais le mot de passe associé au device reste nécessaire.
  • Avoir des logs, qui se connecte à quoi (dispo pour chaque utilisateur), transferts de fichiers.
  • Changer l’ID d’un client
  • Utiliser un carnet d’adresse qui sera synchronisé entre les clients de chaque utilisateur, mais non accessible à l’admin.
  • Appliquer des stratégies
  • Et d'autres fonctionnalités à venir car le projet est en constante évolution....

Il n'existe pour l'instant pas de version Cloud et je n'ai pas le sentiment que ce soit dans l'ordre des priorités de l'équipe.

Installation

Je me place ici dans le cadre de la version serveur après avoir acquis une licence.

L'installation du serveur se fait sous Linux ou dans un container Docker. La procédure est décrite ici et je ne vais pas la reprendre. J'ai choisit Docker pour la facilité d'un Compose...

Coté client, contrairement à TeamViewer qui fonctionne uniquement avec une infrastructure cloud, RustDesk fonctionne avec une infrastructure privée si l’on veut disposer de toutes ses fonctionnalités. Quand on installe le client il va donc falloir configurer les informations liées au serveur. Ce device sera alors uniquement accessible par des clients également configurés pour ce serveur (tout au moins pour l’instant car il y a des évolutions en cours).

Pour configurer le client afin qu’il soit reconnu par le serveur on a plusieurs solutions :

  • Soit on installe l’exe normalement et on copie la config dans ID / Relay server
Qfi0TWlxGWrUdfqdsfVENxxxxxxxxxxxxxxxxxxxxxxxqfsqdfN3boJye

  • Soit on renomme l’exe d’installation afin d’y intégrer la clé, ce qui va donner quelque chose du genre:
rustdesk-licensed-Qfi0TWlxGWrUkR5Vxxxxxxxdfsdfsdfsdfye.exe
  • Soit on crée un script de déploiement et ainsi appliquer la configuration après l’installation dans le cadre d’un script PowerShell, on dispose alors de ces trois commandes, et on verra plus bas ce à quoi peut ressembler un script de déploiement  :

Se connecter

En général quand on utilise ce genre de produit, souvent pour de l'assistance client ou de la gestion de serveurs, il y a deux types d'installations :

  • Le device client, le mien, sur lequel après avoir configuré le serveur (chapitre précédent), je vais me connecter avec l'identifiant fournit par l'administrateur du serveur : 
  • Le device distant auquel on va affecter (ou pas) un utilisateur

Affecter un device à un utilisateur

Si on affecte un device à un utilisateur, cet utilisateur (et uniquement lui) verra ce device distant monter dans son logiciel client. Il pourra également l’ajouter à son carnet d’adresse personnel. Si on ne l'affecte pas, tous les utilisateurs le verront, pourront l'ajouter à leur carnet d'adresse et s'y connecter (sous réserve de disposer du mot de passe préalablement défini).

Des fonctionnalités de groupe et de partage de groupe sont également prévues. Il est ainsi possible de partager les devises affectés à un groupe à un autre utilisateur. A noter que pour l'instant groupe = utilisateur et que l'on ne peut pas directement affecter des devices à un groupe isolé. La solution consiste donc à créer un utilisateur virtuel qui partagera ses devices avec d'autres utilisateurs. Par exemple j'ai créé un utilisateur virtuel Société A qui partage ses devices avec les deux personnes chargés de la maintenance de Société A. Ca consomme une licence utilisateur mais je n'ai pas trouvé mieux pour l'instant.

Il existe plusieurs façons pour y parvenir :

  • En se connectant avec son user/password (mais c’est une très mauvaise idée que de faire ça sur le PC d’un client)
  • En l’associant dans l’interface d’administrateur (mais seul l’admin peut le faire)
  • En utilisant l’API sur le client dans le cadre d’un déploiement vie un script

Pour ça il faut un token. Les tokens qui permettent l’accès à l’API sont délivrés par l’admin.

PS C:\Program Files\RustDesk>.\RustDesk.exe  –assign –token "rapi_xxxxxxxxdyw==" –user_name “admin” | more

La console

Chaque utilisateur peut voir la liste de ses devices, l’état de la connexion ainsi que diverses infos (par exemple :

ip: 82.65.xxx.xxx;
version: 1.2.3;
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2.53GHz, 4/4 cores; mem: 8GB

Un log est également disponible tant pour les connections que pour les transferts de fichiers. Cette console est destinée à évoluer pour plus de fonctionnalités.

L'administrateur peut quant à lui, outre gérer utilisateurs et devices, affecter des stratégies aux utilisateurs et devices :

Script PowerShell d’installation

On ne dispose pour l'instant pas de .msi et ce script est un peu simpliste (il en existe pour d'autres O/S ici). Pour faire simple je conseille d’ouvrir une session PS en mode admin. Mais il est également possible de faire une élévation dans le script (voir à la fin). Pour l’instant attention à indiquer la version de l'exe sur la bonne ligne…

Version client isolé

$rustdesk_pw="mot_de_passe_permanent"
$ErrorActionPreference= 'silentlycontinue'

################################### Please Do Not Edit Below This Line #########################################

If (!(Test-Path C:\Temp))
{
    New-Item -ItemType Directory -Force -Path C:\Temp > null
}

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

cd C:\Temp
Invoke-WebRequest "https://github.com/rustdesk/rustdesk/releases/download/1.2.3/rustdesk-1.2.3-x86_64.exe" -Outfile "rustdesk.exe"
Start-Process .\rustdesk.exe --silent-install # -wait
$ServiceName = 'Rustdesk'
$arrService = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue
if ($arrService -eq $null)
{
    Start-Sleep -seconds 20
}
cd $env:ProgramFiles\RustDesk\
$rustdesk_id = (.\RustDesk.exe --get-id | out-host)

.\RustDesk.exe --password $rustdesk_pw | out-host

Version "mes machines"

################################# VARIABLES #######################################
$rustdesk_pw="PasswordPermanent"  # Celui du device distant
$rustdesk_token="MonTocken"
$rustdesk_cfg="Qfi0TWlxxxxxxxxxxxxxxxxxxxxxxxxxxN3boJye" # Clé de configuration
$ErrorActionPreference= 'silentlycontinue'
################################### SCRIPT ########################################

If (!(Test-Path C:\Temp))
{
    New-Item -ItemType Directory -Force -Path C:\Temp > null
}
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
cd C:\Temp
Invoke-WebRequest "https://github.com/rustdesk/rustdesk/releases/download/1.2.3/rustdesk-1.2.3-x86_64.exe" -Outfile "rustdesk.exe" # Changer la version le cas échéant

Start-Process .\rustdesk.exe --silent-install # -wait
$ServiceName = 'Rustdesk'
$arrService = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue

if ($arrService -eq $null)
{
    Start-Sleep -seconds 20
}
cd $env:ProgramFiles\RustDesk\
$rustdesk_id = (.\RustDesk.exe --get-id | out-host)

.\RustDesk.exe --config $rustdesk_cfg | out-host
.\RustDesk.exe --password $rustdesk_pw | out-host
Start-Sleep -Seconds 5
.\RustDesk.exe --assign --token $rustdesk_token --user_name manu | out-host

Elévation (le cas échéant à ajouter au début du script)

if (-Not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) {
        Start-Process PowerShell -Verb RunAs -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
        Exit;
    }
}

Le cas des serveurs Windows et du RDP

Si on installe RustDesk sur un serveur Windows va se retrouver face à deux possibilités, activer ou pas le partage de session RDP (une problématique identique existe avec TeamViewer qui a choisit de fournir deux ID, cela concerne principalement les administrateurs de serveurs, qu’ils soient premise ou cloud) :

  • Non activé : RustDesk va proposer une ouverture de session, il est possible d’enregistrer le mot de passe dans le client, et cette ouverture de session déconnectera l’éventuel utilisateur connecté en RDP.
  • Activé : Dans ce cas RustDesk partage la connexion RDP active et si on déconnecte la session RDP ça déconnecte la session RustDesk (qui peut toutefois se reconnecter s’il dispose des identifiants Windows.
    • Il existe toutefois un problème, dans ce mode rien ne permet actuellement de choisir la session sur laquelle va s’opérer le partage, il y a donc un risque de se concerter sur la session d’un utilisateur actif dans le cas d’un serveur de bureaux virtuels. (ticket ouvert en cours).

Conclusion

RustDesk est constante évolution et j'y reviendrait certainement ici. En attendant j'ai déployé une trentaine de devices sans observer de problèmes particulier si je compare à mon classique TeamViewer.

EDIT 10/12/2023

J'avais demandé une option afin de simplifier la mise en œuvre et ne pas associer des installations distantes et non contrôlées de façon permanentent à mon serveur. Sur le client on installe simplement Rustdesk de façon interactive, ou on l'installer avec le script simplifié qui permet seulement de définir un mot de passe permanent.

Il est maintenait possible, dans une infrastructure avec un serveur Pro de se connecter à un client isolé tout en bénéficiant du chiffrage du serveur en saisissant son ID@public :

Ainsi la machine sera contrôlée et chiffrée de façon temporaire par le serveur, sans pour autant l'enregistrer de faon permanente dans celui ci. Il sera toutefois possible de l'ajouter à son carnet d'adresse et de lui affecter une étiquette, mais pas de la partager avec d'autres utilisateurs du serveur. Autre avantage, s'autres intervenant pourront se connecter à cette machine, même s'ils ne fort pas partie du périmètre du serveur.

 

 

RDP & Guacamole

Et non, je ne suis hélas pas parti en vacances au Mexique déguster du guacamole arrosé de téquila ! Mais j'ai trouvé la solution que je cherchait depuis longtemps pour sécuriser les accès RDP. Comme chacun le sait il n'est vraiment pas conseillé de laisser ouvert sur internet le port RDP qui est plutôt vulnérable. Hélas pensant le confinement beaucoup de clients ont du mettre en place des solutions dans l'urgence et dans bien des cas il était impossible de verrouiller au minimum ce port sur une IP fixe....

Bien sur Microsoft a une solution (RDP Gateway), couteuse et complexe, donc pas adaptée à de petites entreprises dont les couts IT explosent déjà. Je restait donc en éveil à la recherche d'une solution quand je suis tombé sur le projet open-source Guacamole en HTML5. Et surprise, celui ci fonctionne vraiment bien ! Le principe est simple et reprends celui des autres projets, une machine va servir de proxy afin d'exposer le RDP (mais aussi SSH, Telnet et VNC).

Installation

S'il est possible d'installer Guacamole en natif comme c'est très bien expliqué ici, après avoir testé différentes options, par facilité je vais faire ça sous Docker en utilisant ce projet.

Je vais donc monter une VM Linux Ubuntu et y configurer Docker et Docker Compose. Pour cette partie je vous laisse chercher, d'autres expliquent mieux que moi.

Pour déployer Guacamole on a besoin de 3 services :

  • GUACD : Le cœur de Guacamole qui va servir à connecter les différents services (RDP, SSH, etc...)
  • PostgreSQL : Une base de donnée (qui peut être également MySQL ou encore l'utilisation d'une base externe)
  • Guacamole : Le composant FrontEnd qui va gérer les connections, les services et les utilisateurs.

Docker Compose

L'auteur de l'intégration a eu la bonne idée de nous fournir un script d'installation. On va donc l'utiliser et on se servira de Docker Compose plus tard afin d'ajuster la configuration.

sudo git clone "https://github.com/boschkundendienst/guacamole-docker-compose.git"
cd guacamole-docker-compose
./prepare.sh
sudo docker-compose up -d

Si tout se passe bien on peut se connecter sur https://ip_serveur:8443/guacamole. Le nom d'utilisateur par défaut est guacadmin avec mot de passe guacadmin. La première chose à faire est bien sur de le changer.

On pourra facilement configurer un serveur RDP et s'y connecter pour avoir les premières impressions. Je trouve que le rendu RDP en HTML5 est fluide, même en regardant des vidéos sur YouTube à une bonne résolution. Attention à ne pas perdre de vue que c'est le serveur Guacamole qui doit encaisser le trafic entrant et sortant. Selon l'usage et le nombre de clients il faudra donc le dimensionner correctement.

Je ne vais pas m'étendre sur les différentes options, l'interface et claire, la documentation également et d'autres en parlent très bien.

Sécurisation

Il n'est bien sur pas question d'exposer ce serveur directement sur internet et je vais tester deux solutions de reverse proxy, je commence par éditer le fichier docker-compose.yml afin de supprimer le proxy Nginx préinstallé histoire de ne pas empiler les proxys. J'ajuste également en 8080:8080 pour une utilisation en direct et REMOTE_IP_VALVE_ENABLED: 'true'  pour activer le proxy externe et WEBAPP_CONTEXT: 'ROOT' afin que Guacamole soit accessible en racine :

version: '2.0'
networks:
  guacnetwork_compose:
    driver: bridge

services:
  # guacd
  guacd:
    container_name: guacd_compose
    image: guacamole/guacd
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./drive:/drive:rw
    - ./record:/record:rw
  # postgres
  postgres:
    container_name: postgres_guacamole_compose
    environment:
      PGDATA: /var/lib/postgresql/data/guacamole
      POSTGRES_DB: guacamole_db
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: postgres:15.2-alpine
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./init:/docker-entrypoint-initdb.d:z
    - ./data:/var/lib/postgresql/data:Z

  guacamole:
    container_name: guacamole_compose
    depends_on:
    - guacd
    - postgres
    environment:
      REMOTE_IP_VALVE_ENABLED: 'true'   # On active ici l'utilisation via un proxy externe
      WEBAPP_CONTEXT: 'ROOT'
      GUACD_HOSTNAME: guacd
      POSTGRES_DATABASE: guacamole_db
      POSTGRES_HOSTNAME: postgres
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: guacamole/guacamole
    volumes:
    - ./custom/server.xml:/home/administrator/guacamole-docker-compose/server.xml
    links:
    - guacd
    networks:
      guacnetwork_compose:
    ports:
    - 8080:8080
    restart: always

Je relance docker :

administrator@guacamole:~/guacamole-docker-compose$ sudo docker-compose up -d

En local je me connecte maintenant en http://ip_serveur:8080 sans SSL car le SSL sera géré par le proxy.

Option 1 : pfsense

J'ai un pfsense installé avec HAProxy et Acme pour gérer les certificats Lets'Encrypt, je vais donc me servir de ca pour publier le service. Sur HAProxy on configure le BackEnd et le FronteEnd qui lui utilisera le certificat préalablement créé avec Acme. Dans ma configuration je partage l'IP avec plusieurs sites et ce qui est important c'est d'activer l'option forwardfor qui permettra de transférer les adresses sources à Guacamole.

Je mets ici le code de configuration qui sera utile à ceux qui n'utilisent pas HAProxy sous pfsense qui lui dispose d'une interface graphique. Comme on peut le constater le HTTP to HTTPS se fait au niveau du HAProxy et c'est lui également qui redirigera les requetés HTTTP vers HTTPS et mon serveur sera accessible sur https://guacamole.mondomaine.tld :

global
  maxconn     10000
  stats socket /tmp/haproxy.socket level admin  expose-fd listeners
  uid     80
  gid     80
  nbproc      1
  nbthread      1
  hard-stop-after   15m
  chroot        /tmp/haproxy_chroot
  daemon
  tune.ssl.default-dh-param 1024
  server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
  bind 127.0.0.1:2200 name localstats
  mode http
  stats enable
  stats admin if TRUE
  stats show-legends
  stats uri /haproxy/haproxy_stats.php?haproxystats=1
  timeout client 5000
  timeout connect 5000
  timeout server 5000

frontend Shared_WAN-merged
  bind      x.x.x.x:443 (IP WAN) name x.x.x.x:443 (IP WAN)   ssl crt-list /var/etc/haproxy/Shared_WAN.crt_list  
  mode      http
  log       global
  option    http-keep-alive
  option    forwardfor
  acl https ssl_fc
  http-request set-header   X-Forwarded-Proto http if !https
  http-request set-header   X-Forwarded-Proto https if https
  timeout client    30000
  acl     Admin var(txn.txnhost)      -m str -i admin.domain.tld
  acl     guacamole var(txn.txnhost)  -m str -i guacamole.domain.tld
  http-request set-var(txn.txnhost) hdr(host)
  use_backend Admin_ipvANY  if  Admin 
  use_backend Guacamole_8443_ipvANY  if  guacamole 

frontend http-to-https
  bind            x.x.x.x:80 (IP WAN) name x.x.x.x:80 (IP WAN)
  mode            http
  log             global
  option          http-keep-alive
  timeout client  30000
  http-request redirect code 301 location https://%[hdr(host)]%[path]  

backend Admin_ipvANY
  mode     http
  id       100
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   admin 192.168.55.44:80 id 101  

backend Guacamole_8443_ipvANY
  mode     http
  id       102
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   guacamole 192.168.66.55:8080 id 101

Option 2 : CloudFlared

Cette option est encore plus simple pour ceux qui disposent d'un domaine chez Cloudflare. On va utiliser les possibilités offertes gratuitement par Cloudflared et ajouter une couche de sécurité supplémentaire.

On commence par créer un tunnel CloudFlared avec une instance Docker supplémentaire (le code est fournit par le site de configuration Zero Trust de Cloudflare)

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoiZjk0YjdkZTBiMzFmYWNkNjZlshhsgfhsfghsgfhgfhssgfhsfgzRiMC00MmNlLWJjMghsfghsghsgfhsgfhsgfhsgmpaR00tyyretu(-yenebybvewWXpGaUxUazVNell0TnpRek56WXhNMlkxWXpFeiJ9

Ensuite une fois que le tunnel est monté

On va publier et pointant sur l'ip privée et le port de notre serveur, cela va automatiquement créer l'entrée DNS dans CloudFlare et gérer la problématique du certificat. Ll sera accessible en SSL. :

Ensuite on va ajouter une couche de sécurité supplémentaire en créant une application de type SelfHosted à laquelle on affecte une policie qui impose un code supplémentaire lors d'une connexion. Ce code sera envoyé sur le mail de l'utilisateur sur une adresse individuelle ou un domaine spécifique. Ce n'est pas tout à fait du MFA, mais on considère que si l'utilisateur reçoit bien le code sur son mail professionnel, il s'agit bien de lui et on peut lui permettre de saisir son login / password pour accéder au service :

C'est la méthode la plus simple et de nombreuses option sont exploitables, de même qu'il est possible d'utiliser de nombreux providers externes d'authentification :

Lorsqu'il souhaite se connecter, l'utilisateur tombe sur un portail que l'on peu personnaliser aux couleurs de l'entreprise.

Voilà, et surtout maintenant on retrouve bien les IP publiques dans le log de Guacamole :

Il n'y a plus qu'a ajuster les différentes options de Guacamole et pour ça la documentation est très bien faite. Et bien sur si on se sert de Guacamole pour exposer des serveurs RDP accessibles sur l'internet on prendra soin de restreindre leur usage à l'IP publique du serveur Guacamole, ou mieux de faire transiter ce flux par un tunnel (Wireguard, Tailscale ou Zerotier par exemple que l'on peu facilement installer sur les deux serveurs).

Tailscale Access Controls

J'ai souvent parlé de Zerotier que j'utilise au quotidien, mais qui dans sa version gratuite comporte quelques limitations en terme de contrôle d'accès dans un environnement mixant du site-to-site et des clients isolés. J'ai donc voulut voir ce que proposait Tailscale, qui est un VPN managé relativement similaire reposant sur Wireguard. Tous deux offrent des fonctionnalités gratuites et payantes. Si payer ne doit pas être un problème dans un environnement de production, c'est un peu différent en mode home lab.... d'autant plus que certaines fonctionnalités de la version gratuite ne se retrouvent que dans la version Premium à $18 /mois/utilisateur.

La version gratuite des Tailscale est plutôt généreuse, elle propose 100 nodes et 3 utilisateurs (à condition de disposer d'un "custom domain" (je vais utiliser des comptes Microsoft 365, mais plusieurs autres possibilités sont disponibles : SSO Identity Providers). On peut donc disposer de 3 comptes sur un même domaine. Je parle de comptes car nativement (et normalement) le contrôle d'accès se fait sur l'utilisateur. Manque de chance j'ai besoin de gérer 4 utilisateurs, et je ne suis pas prêt à payer 4 x $18, ce qui me ferait plus de $ 800 par an !

J'ai donc cherché à contourner et je vais finalement gérer mes autorisations à partir des machines Tailscale que j'ai approuvées (mode NFS pour ceux qui se souviennent). Dans cet usage je ne cherche pas faire communiquer les clients Tailscale entre eux mais à leur permettre d'accéder à des ressources situées sur différents subnets sur lesquels je souhaite restreindre les possibilités.

Pour la suite on considère que le réseaux Tailscale est configuré avec les nodes qui servent à joindre les subnets.

Je vais créer deux utilisateurs :

[email protected]
[email protected]

Le premier compte qui sera également le mien va également me permettre de configurer et approuver les machines clientes.

Le second servira à connecter mes utilisateurs et je pourrais approuver leurs machines. Ce compte étant protégé en MFA, il nécessitera une validation de ma part. Une fois la machine connectée, je désactive l'expiration de la clé et on passe au contrôle s'accès :

{
  "acls": [
    {"action": "accept", "src": ["[email protected]"], "dst": ["*:*"]}, // Ici l'admin dispose de tous les droits
    
    // Autorisation par machines
    {
      "action": "accept",
      "src": ["azura", "lydia"],      // Ici deux clients Tailscale
      "dst": [
        "pipa:25,53",                 // On autorise le host qui supporte le DNS si on veut utiliser les noms courts...
        "mixa:80,443,445,3389",
        "nona:80,443,445,1443,3389",  // Ports autorisés

        "lab-1:*",

        "192.168.2.12:80,443,9100,5001,3389", // Par IP + ports
        "192.168.6.0/24:*",                   // Par subnet
      ],
    },
  ],
  "hosts": {
    "azura": "100.1.2.3",        // Client Tailscale
    "lydia": "100.5.2.3",        // Client Tailscale

    "mixa":  "192.168.1.4",      // Host on subnet
    "nona":  "192.168.2.8",      // Host on subnet
    "pipa":  "192.168.2.1",      // Host on subnet

    "lab-1": "192.168.6.0/24", // subnet
  },

}

Dans l'ordre :

  1. J'autorise l'admin à tout voir.
  2. Ensuite j'autorise les machines azura et lydia à accéder uniquement aux hosts que j'aurais défini avec une restriction sur certains ports. C'est possible en définissant les hosts plus loin ou en se servant directement des adresses IP. L'ICMP (ping) est ouvert automatiquement vers les destinations autorisées.
  3. Je défini les clients et serveurs.

Voilà. Je n'ai pas creusé toutes les possibilité offertes par le contrôle d'accès proposé par Tailscale, la liste est longue et le documentation plutôt bien faire. Idées bienvenues !

VMWare ESXi sur Nuc 9 & SSD firmware...

Comme je vous en avait parlé ici, j'ai remplacé mon serveur ESXi HP ML350p par un Nuc 9. Depuis plus de 6 mois ça fonctionne très bien.

Dans ce Nuc j'ai installé deux SSD NVMe Samsung 980 Pro. Les performance sont au top, mais voilà que plusieurs utilisateurs se plaignent que leurs SSD s'usent prématurément et finissent par passer en R/O. C'est d'autant plus fâcheux que sous ESX on ne dispose de rien pour surveiller les disques sur un NUC, celui ci ne remontant pas de données IPML comme le ferait un vrai serveur. Après avoir fait un peu la sourde oreille, Samsung a fini par sortir la mise à jour idoine.

Sous Windows il est très facile de mettre à jour (ou de migrer) un SSD, il suffit de lancer Samsung Magician et le tour est joué ! Sous VMWare ESXi rien de tout ça et il va falloir le faire à la mano. Heureusement pour cela Samsung fournit également les firmawares sous la forme d'une ISO, il suffit, en principe, de le griller sur une clé USB et de booter avec et de faire la mise à jour. Mais ça c'est la théorie. Dans la pratique j'ai appris à mes dépends que cette clé basée sur un vieux Linux était incapable de booter sur du matériel moderne, et quand elle boote certains disent même qu'elle ne reconnait que les claviers PS2... Allons donc !

Après quelques recherches j'ai découvert qu'il existait un contournement possible mis en pratique par la communauté Linux, mais nullement supportée par Samsung qui doit considérer que ses SSD sont destinés uniquement à l'environnement Windows, tout comme VMWare qui a sa liste de hardware supporté...

L'astuce consiste à booter sous Linux, un Live CD Ubuntu. Facile, non pas si simple car ce live CD ne voulait lui non plus pas booter. Le bios de ce Nuc n'étant pas de toute fraicheur j'en profite pour le mettre à jour sans plus de succès.

J'ai fini par trouver que pour booter sous Ubuntu il fallait désactiver TPM et SGX. Ca ne s'invente pas mais j'ai fini par pouvoir booter mon Ubuntu Live.

Une fois sur le desktop de mon Ubuntu je copie l'ISO de mise à jour (Samsung_SSD_980_PRO_5B2QGXA7.iso) que j'ai au préalable préparée sur une autre clé USB vers le répertoire Home et je monte le volume. Ensuite toujours depuis l'interface graphique j'extrait le fichier initrd un répertoire (/home/samsung par exemple). Ensuite je vais jusqu'à /home/samsung/initrd/root/fumagician et je peux lancer la mise à jour de mes SSD :

sudo ./fumagicien

Je fais la mise à jour de mes deux SSD et je relance le Nuc. Attention, le bon numéro de version n'apparaitra qu'âpres le prochain redémarrage. Donc même si c'est un peu fastidieux, je vous conseille de relancer le Live CD pour vérifier. De même si vous avez d'autres machines à mettre à jour, vous pouvez sauvegarder fumagician sur une clé pour éviter l'étape de l'extraction. 

Il existe une autre méthode en CLI pour les barbus, elle demandera toutefois de connecter le Live CE au réseau si on veut éviter l'étape de la clé USB, mais in fine ça revient au même :

wget https://semiconductor.samsung.com/resources/software-resources/Samsung_SSD_980_PRO_5B2QGXA7.iso
apt-get -y install gzip unzip wget cpio
mkdir /mnt/iso
sudo mount -o loop ./Samsung_SSD_980_PRO_5B2QGXA7.iso /mnt/iso/
mkdir /tmp/fwupdate
cd /tmp/fwupdate
gzip -dc /mnt/iso/initrd | cpio -idv --no-absolute-filenames
cd root/fumagician/
sudo ./fumagician

Voilà comment occuper (perdre) un après-midi d'hiver !

Attention toutefois, si vous avez créé un volume RAID, ce qui est discutable avec des SSD, il semblerait que vous ne puissiez les voir sans repasser le bios en AHCI.

Sources

 

Microsoft mon amour !

Et non, ce n'est pas une déclaration ! J'ai longtemps été in love avec Microsoft, mais comme on le sait, les histoires d'amour finissent souvent mal ! Blague à part, en imposant d'abord Exchange dans les entreprises, Microsoft telle une pieuvre avait bien préparé le terrain afin que celles-ci migrent vers Exchange Online, une des briques de la méga suite 365. Le résultat est qu'aujourd'hui la domination est quasi totale, domination que les autres acteurs ont bien du mal à concurrencer. Bien ou pas, ce n'est pas l'objet de cet article, par contre cette domination devrait imposer un devoir d'exemplarité, et force est de constater que ce n'est pas toujours le cas, loin s'en faut !

En devenant l'acteur majeur de la messagerie d'entreprise, Microsoft est également devenu un acteur majeur du spam. Face à cette déferlante certains acteurs moins conséquents n'ont d'autre choix que d'imposer régulièrement le blocage des adresses IP de Microsoft, une pratique certes discutable, mais également adoptée par Microsoft lui même pour son service grand public Hotmail (comme on peut le lire 1 | 2 | 3 )

Dans la pratique on se retrouve avec une messagerie professionnelle incapable d'envoyer des messages vers certaines destinations, @free.fr et @orange.fr par exemple, mais pas que. La situation peut se débloquer toute seule et alors les messages prennent du retard, ou sont simplement renvoyés à l'expéditeur via un NDR.

L'un de nos collègue, Marc, a eu l'opportunité d’échanger avec le responsable de la messagerie chez Free et il lui a posé la question :

Pensez vous qu’il puisse être envisageable d’exploiter d’autres mécanismes permettant un filtrage avec une granularité plus fine (genre trio DKIM, SPF, DMARC) ?

    • Non, pas à ce jour et probablement pas dans un futur proche.
    • Le premier problème est que la situation dans laquelle vous êtes ne concerne qu'Office365 et aucun autre hébergeur de messagerie. Il y a bien des problèmes avec Gmail mais les solutions techniques mises en place chez eux n'ont rien à voir avec celles d'Office365 et les dommages collatéraux en sont drastiquement réduits.
    • Le second problème est que si nous devions basculer sur une réputation par domaine en nous basant sur les signatures DKIM, il nous faudrait également prendre en compte les sceaux ARC (signature de l'intermédiaire technique) et qu'ici, il y a un sceau ARC sur microsoft.com sur les mails sortant d'Office365 et qu'il y a un risque conséquent pour que ce soit toute la plateforme Office365 qui se retrouve bloquée.
    • Le troisième problème est que nous avons pu constater ces dernières années des campagnes de spams expédiées au travers de comptes compromis. Sur certaines journées en décembre dernier, c'est plus de 1500 domaines qui participaient ainsi aux envois rien que pour Office365. Il est délicat de mettre en place une whiteliste concernant un domaine ou un compte car cela revient à retirer toutes nos protections alors que nous gérons pas ce domaine ou ce compte.

Dans ces conditions et puisque Microsoft ne réagit pas plus, il faut trouver un contournement qui va nous permettre de rerouter les messages destinés aux domaines qui pratiquent de tels blocages. D’aucuns diront que continuer à utiliser en 2022 un compte de messagerie chez un FAI n’est pas une bonne idée, mais peu importe, dans le cadre d’une relation commerciale on ne commence pas par expliquer la vie au client, mais à entretenir la relation avec lui et ainsi lui apporter des solution viable. On est tous d'accord, on ne devrait pas avoir à apporter une telle solution !

Contournement

Sur Microsoft 365, Exchange Online plus précisément, nous allons utiliser une règle et un connecteur pour dérouter les messages destinés au domaine free.fr  et orange.fr vers un serveur SMTP externe qui va servir de relais. S’il existe bien des services de relai SMTP sur Internet, ces services nécessitent soit une authentification, soit une restriction sur une adresse IP. Problème, il n’est pas possible de s’authentifier sur un connecteur sortant, et Microsoft utilise une multitude d’adresses IP sur ses serveurs SMTP.

*.protection.outlook.com : 40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 52.238.78.88/32, 104.47.0.0/17

Il va donc nous falloir monter un serveur SMTP externe sur lequel on va autoriser le relai depuis ces blocks d’adresses IP. Il existe toutefois un petit risque que d’autres administrateurs trouvent la faille et se servent de notre serveur. Ce risque est faible, et au pire on changera notre adresse IP.

Le relai

Ou relais, une fois de plus les anglais font plus simple avec relay, smtp-relay. Bref, pour monter un tel serveur il existe certainement plusieurs produits possibles, pour peu que ces logiciels soient capable de gérer de multiples plages d’adresses IP sources à relayer. J’ai utilisé HMailServer sous Windows car je le connais bien, mais on doit pouvoir faire ça sous Linux à moindre frais. Quant à la restriction au niveau des IP sources, ça peut aussi se faire au niveau du firewall.

Dans HMailServer (IP Ranges) on va déclarer nos adresses IP autorisés sans authentification, celle des serveur Microsoft 365 :

On répète ça pour chaque plage d’IP et ensuite de la même façon on va déclarer nos relais autorisés, les mêmes IP :

C'est un peu fastidieux et ce serait plus simple de déclarer 107.47.0.0/17, mais ici c’est ainsi.

Ensuite on s’assurera que notre serveur est correctement installé (il n’accepte rien d’autre) et est correctement déclaré et configuré (SPF, reverse IP, etc...) pour les domaines pour lesquels il devra assurer le transit. On fait un Telnet sur mx1.free.fr afin de s’assurer que l’on peut bien les joindre et  que notre IP publique n'est pas elle aussi blacklistée.

A ce stade on se connecte à l’administration Exchange de Microsoft 365 dans laquelle on va faire en sorte que tous les mails à destination de Free et Orange devront transiter via l’IP de notre serveur relai.

Exchange Online

Pour ce faire on va commencer par créer un connecteur qui s'appliquera aux messages sortant d'Exchange Online vers ce qui s'appelle ici Organisation Partenaire :

Le choix suivant est important :

  1. Soit on décide que ce connecteur s'applique à tous les messages à destination de Free et Orange, auquel cas on configure simplement ces domaines. C'est la solution la plus simple pour un tenant qui ne gère qu'un seul domaine.
  2. Soit on décide que ce connecteur ne s'applique qu'au messages qui ont été redirigés par une règle. On utilisera cette option dans le cas ou on souhaite rediriger uniquement certains mails, expéditeurs ou domaines sources, qui seront le fruit d'une règle à créer.

Ensuite se pose la question de la validation du connecteur ou l'on utilisera une adresse @free.fr par exemple. Dans la pratique validé ou pas le connecteur fonctionne tout de même....

Si l'on a fait le choix 2 il va nous falloir créer une règle pour que cela fonctionne. Dans cette règle on va demander à ce que :

  • le destinataire soit sur le domaine free.fr
  • le domaine de l'expéditeur
  • Et enfin que ce trafic transite via le connecteur précédemment créé.

Cela va nous permettre de ne dérouter vers notre MTA premise uniquement les domaines sources qui y seront configurés. Ce cas est spécifique à des tenant "partagés" ou plusieurs domaines coexistent, mais cela peut également permettre d'utiliser plusieurs serveurs relais en fonction des domaines sources.

Il est bien sur possible de faire ceci en PowerShell, vous trouverez les détails dans cet excellent article.

Synology mon amour....

J'utilise des NAS Synology à titre professionnel depuis plus de 10 ans avec une plutôt bonne expérience. J'en ai par exemple de gros qui fonctionnent encore très bien mais par exemple un RS3411xs de 2011 mérite d'être changé préventivement...

Je commande donc un RS3621RPxs et 6 disques Western Digital Ultrastar HC530, un modèle que j'avais utilisé avec succès il y a deux mois dans un RS820RP+. Disque de classe entreprise. Et là c'est le flop, dans ce dernier NAS il apparaissent comme disques non vérifiés et impossible de les monter en SHR, alors que ce disque est compatible avec le RS820RP+ !

Me voici donc partit à la recherche d'informations, le constat est des plus simples et probablement surtout mercantile. Synology vend maintenant ses propres disques en apposant leur étiquette sur des disques Toshiba, et les disques concurrents encore présent dans les listes de compatibilité sont de plus en plus rares. Rien de bien neuf sous le soleil, HPE, Dell et d'autres ont les mêmes pratiques. Saut que Synology nous avait d'une part habitué à pouvoir utiliser n'importe quel disque, le credo des fabricants de NAS, et surtout que les disques estampillés Synology sont peu disponibles et coutent souvent jusqu'à 30/40 % plus cher. Scandaleux, et les groupes d'utilisateurs ne se privent pas pour le dire et orienter les clients vers d'autres solutions.

Bref, j'ai donc 6 disque de 16 TO sur les bras. On va voir qu'il existe des contournements, mais pour des questions légales et de responsabilité vis à vis de mon client, je ne peux pas me permettre d'utiliser ces disque en production sensible. Donc Synology à gagné, et je repasse une commande de 6 disques Synology que je vais monter en stockage de VM. Quant aux 6 premiers je vais les utiliser dans un second groupe dédié à des sauvegardes secondaires en utilisant un contournement.

Synology

Dans la terminologie de Synology, il existe 3 classes de disques :

  • Compatible : Les disques compatibles ont été testés par Synology et sont certifiés pour fonctionner sans limitation.
  • Incompatible : les disques incompatibles sont « mis sur liste noire » par Synology et ne peuvent pas être utilisés (les disques SMR sont inclus dans ce lot). Rien que du normal.
  • Non vérifié : un disque qui n'a pas été testé par Synology est défini comme un lecteur non vérifié. Ca ne veut pas dire qu'il n'est pas 100% compatible, et ici c'est bien plus contestable.

Les disques non vérifiés sont utilisables dans un état non pris en charge avec les contraintes suivantes :

  • L'état d'un disque non vérifié peut apparaître comme non vérifié dans le gestionnaire de stockage de DSM.
  • Des avertissements s'afficheront lors de la sélection de lecteurs non vérifiés pour créer un pool de stockage.
  • Il est parfois impossible de créer des volumes de type SHR avec des disques non vérifiés.
  • Les pools de stockage contenant des lecteurs non vérifiés peuvent afficher un état de danger pouvant faire peur.
  • DSM peut envoyer des notifications d'avertissement lorsque des lecteurs non vérifiés sont en cours d'utilisation.
  • Les informations sur le lecteur telles que l'état de l'allocation, le nombre de secteurs défectueux, la température, le numéro de série, 4K natif peuvent ne pas être affichées.
  • La prise en charge de Synology sera limitée si le problème de prise en charge peut être lié au lecteur non vérifié (la décision de refuser la prise en charge reste à la discrétion de Synology)
  • L'utilisation de disques non vérifiés n'a aucun effet sur la garantie matérielle de Synology

Bien sur cette liste n'est pas exhaustive et malheureusement Synology est resté vague sur le fonctionnement de leur classification de disques et de SSD. Par exemple…

  • Les disques approuvés comme compatibles pour un modèle de NAS peuvent être non vérifiés pour un autre modèle.
  • Les disques approuvés comme compatibles peuvent voir leur classification changée en incompatible ou non vérifié sans préavis par Synology.
  • La compatibilité du lecteur est liée à la version du micrologiciel du lecteur.
  • Le test des disques nouvellement sortis est souvent retardé de plusieurs mois.
  • Le résultat de ces classifications de disques est que l'achat de disques compatibles est souvent limité à des disques rares dans le commerce, avec des micrologiciels obsolètes, qui sont soit indisponibles à la vente, soit en nombre insuffisant, auprès de fournisseurs non éprouvés, à des coûts non compétitifs.

De manière réaliste, un disque SATA de classe NAS/Enterprise utilisant la technologie CMR devrait convenir. Bien sur tout cela vaut pour les SSD...

Contournements

Dans tous les cas, et quelque soient les disques utilisés, on commence toujours par monter un volume et stresser les disques avant une mise en production, en faisant par exemple de gros transferts de données pendant quelques jours... Et si ça se passe mal on n'hésite pas à renvoyer les disques.

Si ça se passe bien on peut envisager deux contournements, l'un va faire croire que le disque a été vérifié, et l'autre que l'on ne s'occupe pas de vérifications... Et rien ne dit que de futures mises à jour ne rendront pas ce contournement obsolète.

Attention : S'agissant de modifications de fichiers système, vous savez et comprenez ce que vous faites, je décline toute forme de responsabilité, tout comme les personnes qui ont trouvé ces hacks et les ont divulgués sur les forums cités en sources (non, ce n'es pas moi qui ait trouvé !).

Cette mise en garde étant posée, j'ai trouvé deux possibilités :

Première option, ajout du disque dans la liste de compatibilité

On active SSH, on se connecte au NAS et on fait :

sudo-i

Qui va vous redemander le mot de passe pour cette élévation. Enduite on va dans le répertoire idoine :

cd /var/lib/disk-compatibility

Et on repère les fichiers *_host.db et *_host.db.new qu'il faudra éditer, par exemple dans mon cas rs3621rpxs_host_v7.db et rs3621rpxs_host_v7.db.new. Attention, tout ça peut évoluer avec le temps et les révisions. Avant d'éditer, je vous conseille de faire une copie de sauvegarde de l'original et de chercher les information de vos disques avec :

sudo smartctl -i /dev/sdc

Qui devrait retourner quelque chose du genre !

Model Family:     Ultrastar
Device Model:     WDC  WUH721816ALE6L4
Serial Number:    3WJAK3BJ
LU WWN Device Id: 5 000cca 284e0faf1
Firmware Version: PCGNW232
User Capacity:    16,000,900,661,248 bytes [16.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   Unknown(0x0ffc) (unknown minor revision code: 0x009c)
SATA Version is:  SATA >3.2 (0x1ff), 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Oct 18 19:04:29 2022 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Ensuite on édite avec VI et ça devrait donner quelque chose de ce genre :

{"model":"WUH721816ALE6L4","firmware":"PCGNW232","rec_intvl”:[1]},

Et si on est pas sur, le mieux est d'aller lire, si on en dispose, ces informations dans un fichier pour un autre NAS ou le disque est indiqué compatible (notamment la dernière information en fin de ligne).

Seconde option, ne pas vérifier la compatibilité

Attention : Il y a de grandes chances que cette manipulation saute lors des mises à jour. Il faut donc la refaire à chaque fois, et toujours en partant du fichier original qui contient d'autres informations qui peuvent évoluer. (Je viens d'en faire les frais lors de l'application de 7.1.1-42962 Update 4, mais c'est probablement le cas de chaque mise à jour).

J'aurais tendance à préférer cette option bien plus simple. Mais ça sous entend que nos disque soient testés et non incompatibles. On passe toujours par SSH et on va éditer ce fichier :

/etc.defaults/synoinfo.conf

Et dans ce fichier on va passer cette ligne de yes à no.

support_disk_compatibility="no"

On peut bien sur éditer le fichier directement avec VI, mais pour ceux qui ne seraient pas à l'aise avec ce dinosaure, je conseille de commencer par faire une copie de sauvegarde de ce fichier dans un partage, de sauvegarder cette copie ailleurs et ensuite de l'éditer avec son éditeur préféré, puis d'aller remplacer le fichier original :

sudo cp /etc.defaults/synoinfo.conf /volume2/Backups/

On édite, et :

sudo cp /volume2/Backups/synoinfo.conf /etc.defaults

On sauvegarde et on redémarre le NAS et nos disques ne devrait plus s'afficher en rouge. Cependant ça ne joue pas sur les unités d'extension.

Conclusion

Synology nous enfume mais ils font de bons produits et je n'ai pas envie de vous dire qu'il va falloir changer de crèmerie. D'autant plus que d'autres fabricants seront surement tentés de faire de même. Pour autant je me poserait la question lors de mes prochains investissement ou conseils.

Dans l'absolu que ces avertissements soient présents, pour de louables raisons, est une bonne chose. Il serait par contre raisonnable que l'utilisateur informé puisse les supprimer, notamment quand un disque est largement reconnue par la communauté. Mais il y a également les mauvaises raisons, comme pour les extensions mémoire ou une barrette Crucial à 100 € fonctionnera parfaitement là ou Synology nous en demande près de 400 ! On pourrait également parler de la collecte de données, pas pire que d'autres...

Une alternative consistera à intégrer du logiciel Open Source (FreeNAS, TrueNAS, etc.) dans des serveurs recyclés disposant d'un bon support disque (HPE par exemple) que l'on trouve à des tarifs intéressant sur le marché du reconditionné. Ca fait du NAS dédié stockage pas cher et fiable. Je précise stockage, car contrairement à ce que veulent nous faire croire les fabricants, il faut, à mon sens, oublier l'idée d'installer tout et n'importe quoi sur un NAS, mais c'est là un autre débat....

Sources