Jump to content

TSE et Botnet


esbo

Recommended Posts

Bonjour les Tech's,

voilà j'aimerais avoir plusieurs avis sur les bonnes pratiques à mettre en œuvre quand on fais du TSE sur un serveur hébergé chez un presta ou local.
je vous donne par exemple deux scénario récurrent:

 

1- une entreprise de 10 salarié, en TSE sur un w2012 (sans domaine) hébergé chez soyou ou peu importe,  persécuté par 1000 ou 2000 connexions journalière sous le login "administrator" et ou dans les logs Windows sécurité l'IP n'apparait pas. le directeur c'est Mr Picsou donc payer oui ! mais seulement quand tout est pété ! (classic).

 

2- une école de campagne avec zéro budget et ou le mot Linux fait poussé des boutons sur le front des enseignants. Avec à disposition des vieux coucou en Windows X qui ce connecte en TSE sur un serveur en 2008 ou 2012 ( avec un domaine mais pas de plan de sauvegarde) et une box (sfr,orange,etc) . avec les loi qui évolue tout est à faire, la protection des enfants (wifi, google image à filtré, données à protégé).

 

Des exemples je crois qu'on peu tous en donnée des milliers, d’où ce topic afin de voir comment on peu sécurisé tous ça.

si vous avez des astuces pratiques, softs libre, gratuit, payant, conseil allez y laché vous, vous sauverez quelque serveur ;)

 


 

 

Link to comment
Share on other sites

Salut!

Il y a 7 heures , esbo a déclaré:

1- une entreprise de 10 salarié, en TSE sur un w2012 (sans domaine) hébergé chez soyou ou peu importe,  persécuté par 1000 ou 2000 connexions journalière sous le login "administrator" et ou dans les logs Windows sécurité l'IP n'apparait pas. le directeur c'est Mr Picsou donc payer oui ! mais seulement quand tout est pété ! (classic).

Les attaques par bruteforce sont effectivement un gros problème. Il faut simplement bien comprendre que ces attaques se font "à l'aveugle" dans 99,999% des cas. A moins que le "pirate" n'ai vraiment ciblé ta boite et étudié la config, il part du principe que la configuration est standard. Il faut donc changer tout ca. Par exemple, le port 3389 peut être modifié, afin de faire du RDP sur un autre port. Le compte Administrateur du domaine ne doit peut être pas se nommer ainsi, mais par exemple "EsboNomClient". Ce nom de connexion sera déjà beaucoup plus dur à obtenir dans un dictionnaire de bruteforce. Ensuite, un mot de passe fort, genre une phrase mémorielle de 14 caractère avec des chiffres et caractères spéciaux, et déjà là t'es pas mal... Encore faut-il que tous les comptes du domaine qui peuvent faire du RDP soient aussi sécurisés!

 

Pour ce qui est des tentatives de bruteforce, un firewall évolué pourra bannir temporairement l'adresse IP d'où émane par exemple plus de 10 tentatives en moins 5 minutes. Ca permet de faire "décrocher" les bots.

 

Il y a 7 heures , esbo a déclaré:

2- une école de campagne avec zéro budget et ou le mot Linux fait poussé des boutons sur le front des enseignants. Avec à disposition des vieux coucou en Windows X qui ce connecte en TSE sur un serveur en 2008 ou 2012 ( avec un domaine mais pas de plan de sauvegarde) et une box (sfr,orange,etc) . avec les loi qui évolue tout est à faire, la protection des enfants (wifi, google image à filtré, données à protégé).

Je commence, personnellement, à être un peu plus virulent avec les écoles. Ils demandent toujours l'impossible financièrement, sous couvert de petits budgets. Ok, mais à côté tu vois des équipements de jeu ou d'activités qui sont complètement bidons. Pire, ils se font enfumés avec des sociétés qui leur refourguent des solutions d'impressions en contrat locatif à 5000€ sur 5 ans, sous couvert d'un coût faible à la page ensuite...

L'informatique ca coute cher. Donc s'ils veulent juste bricoler, ok. Mais dès que tu parle de serveur, de services publiés, etc, alors tu parle de sécurité, et donc d'argent.

La sécurité d'un serveur est la même en entreprise qu'en école, à partir du moment où ils se servent des mêmes produits.

 

Souvent j'essaye quand même de blinder la sécurité. Ils disposent souvent de plusieurs bâtiments, donc il est intéressant de leur proposer un NAS déporté dans un autre bâtiment que celui où est le serveur, et d'y faire les sauvegardes.

Link to comment
Share on other sites

dans la pratique en général j'ouvre dans le routeur un port (ex: 22222) vers le port 3389.
Je crée un compte sur le serveur que je passe en root et je désactive le compte administrateur.

pour les nomades un openvpn.



pour les solution hébergé c'est plus compliqué c'est base de registre serveur pour changer le port mais de toute façon il est exposé aux scan.
donc faut passé par vpn .

à force de jouer avec les regle pare feu j'ai réussi un jours à me bannir.... et là c'est tout de suite moins drôle.

Link to comment
Share on other sites

Oui la redirection de port sur le serveur est une bonne solution, même s'il sera exposé aux scan aussi au final...

Après, il faudra encore que l'attaquant trouve le service qu'il y a derrière ce port. Disons que ca contribue à réduire le risque.

 

Pour OpenVPN, c'est très bien, à la seule condition de sécuriser le VPN par des certificats (j'ai fait des articles là dessus).

Link to comment
Share on other sites

Il y a 5 heures , Anzo a déclaré:

Dans un monde idéal, tu ne veux pas avoir de port RDP ouvert sur le WAN tout simplement.

 

Créer un tunnel VPN sécurisé et ensuite se connecter à distance, en RDP, reste la pratique la plus sécuritaire .

Oui et non :)

 

Effectivement, ne rien publier en WAN directement, et obliger à monter un VPN pour les accès divers, c'est une solution sécurisée.

Après, l'utilisation de VPN pose des problèmes. Par exemple, ca ne fonctionnera pas toujours, selon le lieux d'où on se connecte (restriction sur firewall).

De plus, monter un VPN demande des compétences (pas simplement monter un tunnel qui fonctionne, mais maitriser les flux réseau sortants et entrants).

Monter un VPN à l'arrache, sous OpenVPN par exemple, c'est à la portée de tout le monde. Le sécuriser correctement, c'est déjà plus chaud.

Et sans utiliser un VPN, un RDS bien sécurisé par certificat, en suivant les bonnes pratiques recommandées par Microsoft, c'est au moins aussi sécurisé, et beaucoup moins lourd.

N'oubliez pas aussi qu'un tunnel VPN, ca veut dire interconnecter deux réseaux. Faire du RDP sécurisé, c'est juste déporter un affichage. Ca change pas mal de choses... ;)

Link to comment
Share on other sites

Sur 04/02/2017 at 08:47 , Pyrithe a déclaré:

 un RDS bien sécurisé par certificat, en suivant les bonnes pratiques recommandées par Microsoft, c'est au moins aussi sécurisé, et beaucoup moins lourd.

 


Si vous avez de bonne sources en français de préférence je suis preneur, car oui le VPN est contraignent notamment dans les infra d'entreprise géré par exemple par des municipalités.

Link to comment
Share on other sites

Il y a 10 heures , esbo a déclaré:


Si vous avez de bonne sources en français de préférence je suis preneur, car oui le VPN est contraignent notamment dans les infra d'entreprise géré par exemple par des municipalités.

Il  a des centaines, des milliers de sources sur internet concernant ce genre de sujet très fréquemment abordé.

Si tu as des soucis en essayant de mettre cette solution en place, je t'invite à revenir poser des questions sur le forum.

Mais il n'existe pas une seule façon de faire. A mon avis, il faut étudier le sujet dans sa globalité, puis trouver la solution la plus adaptée à son infrastructure.

Même si, au final, la base reste la même, il y a quand même quelques détails qui seront à adapter.

 

Il existe de très bons bouquins, perso j'y ai régulièrement recours.

Ensuite, il y a des milliers de bonnes références sur le net, il faut juste faire un peu de recherche.

Quand à la langue, malheureusement, comprendre un minimum la langue de Shakespeare est une qualité indispensable pour un bon tech, car on se rend vite compte qu'on trouve 20% des sources techniques en Français, pour 80% en anglais... 

 

Link to comment
Share on other sites

Je vous trouve très prompt à refuser l'option du vpn sous seul raison que c'est "compliqué" ou "contraignant". Si je partage votre opinion que ce n'est pas la solution la plus simple, cela reste néanmoins l'option la plus sécuritaire.

 

Je crois qu'une partie de notre travail, en tant qu'informaticien, n'est pas seulement de proposer des solutions que nous sommes en mesure de déployer, mais de proposer au client, quitte à devoir faire appel à un tiers parti, des solutions (et non juste une seule) qui peuvent répondre à ses besoins convenablement.

 

Vaut mieux offrir à son client la possibilité d'implanter un VPN et que celui-ci refuse que de ne pas lui proposer et se le faire reprocher. Je sais pas pour vous, mais ça m'est déjà arrivé de me faire dire "pourquoi tu m'as pas proposé ça". Même si je savais que le client aurait dit non, j'aurais quand même du lui proposer ne serait-ce que pour me protéger.

 

Ne pas proposer toutes les solutions possibles au client pose plus de risque que d'avantage, à mon avis.

Link to comment
Share on other sites

 @Anzo Si je suis d'accord avec toi sur le fond, je le suis moins sur ce cas précis.

Par exemple pour faire du RDP, et uniquement ca, proposer de monter un VPN plutôt qu'un accès RDP sécurisé, ce n'est simplement pas adapté.

Un VPN sert à joindre réseau. Tu aura accès aux ressources du LAN, partages, réseaux, etc, comme si ton pc était dans le LAN.

Si le but est de faire du RDP sur un serveur pour utiliser une appli par exemple, sans autre besoin, alors, nul besoin de mettre en place un VPN...

Link to comment
Share on other sites

Vous avez raison, néanmoins l'idée de base est de faire quelque procédure, de pouvoir partagé avec les stagiaire par exemple ou tout simplement des personnes qui souhaite en savoir plus, un aide mémoire.
j'ai déjà eu le cas aussi du : Mais pourquoi tu m'en à pas parler.... RRRrrr

 

et coté soft comme par exemple ipban sous linux, vous avez un équivalent ?

Link to comment
Share on other sites

×
×
  • Create New...