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 !