Reprise du message précédent :

+
- est-ce que tu peux te permettre de te faire pirater ton serveur, et servir de robot à DDoS, serveur de relais de spam, ou hébergeur de pédo-porno ?
Bien sur, ici on est sur HFR, tout le monde est un génie de l'informatique capable de sécuriser tout et n'importe quoi rien qu'en fronçant les sourcils... Mais pensez-y quand même.

Ah ben là tu m'intéresses l0g4n parce que effectivement je ne m'étais pas posé la question sous cet angle là...
 
Quelles sont les bonnes pratiques pour éviter les risques ?
fail2ban, maj les applis régulièrement pour combler les failles de sécurité,...?

Ah oui vu comme ca ça m intéresse plus trop...

C'est devenu mon métier la sécu, mais j'faisait du prosélytisme avant
Mais sur un ptit serveur perso :
1) Le mail, c'est compliqué, mais faut SURTOUT s'assurer de ne pas être un open relay (en gros, si un mail n'est pas destiné au serveur local ET qu'il a été reçu sans authentification, il doit être refusé)
2) Y'a pleins de solutions pour sécuriser SSH (changer de port, fail2ban, ...) mais le plus efficace c'est : pas de connexion par mot de passe, uniquement par clé. Le fail2ban, y'a des bots qui le contourne en se partageant les forcebrute sur des pools d'IP source. Le changement de port, ça résiste pas à un scan...
3) Tout ce qui est douteux d'un point de vue sécu (une appli choppée sur un github, un truc un peu vieux...), c'est soit derrière une authent frontale de confiance (un simple htpasswd apache), soit accessible uniquement via tunnel SSH/VPN
4) Toujours un pare feux ACTIF. Y'a firewall-cmd sous certains linux récent qu'est accessible, y'a des appliances de pare-feux gratuites très bien (certaines opensources, ...).
5) Mises à jour auto, au moins celles de sécu, régulièrement si c'est pas possible (et on se tient au courant : heartbleed ça a touché même les plus simples des serveurs persos...).
6) TLS everywhere : SSH/RDP versus telnet/rlogin/rsh (on rigole pas dans le fond), HTTPs versus HTTP, SMTPs, LDAPs ou LDAP over TLS, ... (en plus, ça permet d'apprendre à monter une petite CA SSH en 3 commandes, de déployer du letsencrypt, ...).

Avec ça t'a la base. Et t'apprend plein de choses. Après, si tu veux faire plus, ça devient de l'apprentissage des métiers de la sécu (évaluation des risques, quelle sécurité est en place, elle m'apporte quoi réellement, est-ce qu'elle reste bien en place, comment je détecte une attaque sur mes services, comment je détecte une intrusion/compromission/fuite de donnée, quels droits j'ai, quels devoirs j'ai, qu'est-ce que j'ai pas le droit de faire, ...).

EDIT : pour SSH, ça s'applique à RDP aussi.

Je vais partir sur plus simple....j'ai pas beaucoup de temps en ce moment pour apprendre et surtout mettre mon serveur en sécurité.....merci à vous pour vos conseils!

Bon bah j'ai les trucs de base en terme de sécu...vaut mieux étant donné mon ancien taf xD

Tu bosses où maintenant ?

D'ailleurs au passage, le forum hfr vient de passer en SSL let's encrypt non ?
Je m'en suis rendu compte cet aprèm.

 
Ça fait une quinzaine de jours à peu près.

Un vendeur de viande issus de la fusion récente de deux SS2I aux noms semblables

Après ça reste quand même un peu le cas "idéal".
Pour casser un mot de passe ssh suffisament grand et complexe, même en restant sur du port 22 avec failtoban, je doute que ça soit réellement réalisable.
 
Je n'ai "que" cette sécurité sur mon serveur @home et mon dédié et ce depuis de nombreuses années, et je n'ai jamais eu de pb d'intrusion.
Pour casser un mot de passe long avec 3 tentatives, même avec un pool d'ip il faut y aller et avoir sacrément de la chance...  
Pour une entreprise, ou quelqu'un de bien visible à l’internationale, je ne dis pas ça me semble nécessaire de bloquer avec une connexion par clef, mais pour un particulier à la visée au mieux régionale, je ne pense pas que cela puisse intéresser une équipe de hacker de ce niveau là vu le coup d'une telle attaque.
 
APrès je suis d'accord qu'il vaut mieux être parano que pas assez sécurisé, mais ça me semble quand même un peu extrême à l'échelle d'un particulier.  

Pour moi tout ça c'est le minimum, et ça permet d'apprendre plein de choses

En entreprise, tu penses bien qu'on devrait être à des kilomètres de ça

Ah mais c'est très formateur on est d'accord.

Mais perso c'est juste que la clef ssh pour se connecter, ça me bloquerait pour plein d'usage, bref c'est le côté contraignant.
Idem en changeant de port tu peux te retrouvé bloqué à ne pas pouvoir passer dans plein de lieu ou seuls les ports standards sont ouverts en sortie.

vpn sur 443 avec port sharing
 
XaT

Toujours la même problématique : trouver l'équilibre entre la sécurité absolue et la réalité des besoins.
 
Genre t'as un serveur qui crashe, t'es à l'autre bout du monde avec juste un smartphone, t'es content de pouvoir faire un ssh et taper ton mot de passe...
Désactiver l'accès root n'est pas une mauvaise idée, créer un autre user avec un nom à la con (pas admin ou quelque chose de trop évident), avec un pass un peu long c'est quand même ultra sécure. Si c'est pété, c'est que ça aurait été pareil avec une clé (man in the middle qui écoute le pass vs la clé c'est pas très différent).
 
La clé c'est pratique je trouve surtout pour faire des opérations automatisées serveur-serveur, genre backups via rsync (avec des comptes utilisateurs aux droits restreints à ce qu'ils doivent faire bien sûr).
 
Après il faut aussi relativiser, les OS ne sont pas nativement des passoires, les applications ont souvent un paramétrage par défaut restrictif ou une explication très claire du genre "changez le pass admin" sur la page d'accueil tant que ça n'est pas fait...
Ca demande un peu d'attention, de lecture de tutos, mais ça n'est pas très difficile d'éviter les grosses erreurs notamment si on reste sur les applications basiques : ssh, apache...

 

 
Merci pour ces informations, c'est globalement ce que j'applique sur mes serveurs, sauf pour ce qui est du firewall.
Qu'appelle tu actif ? iptables ne suffit pas ? Actuellement j'ai uniquement des règles qui bloquent tout sauf ce que j'ai ouvert spécialement (en ipv4 et ipv6)
 
D'ailleurs ce qui peche dans fail2ban c'est aussi qu'il n'est pas compatible ipv6 et les kimsufi sont aussi accessibles en ipv6...
 

Sinon je venais ici, parce qu'enfin j'ai tout basculé de mon Ks1 a mon Ks2 en promo donc j'ai résilié le Ks1, mais je vois que les Ks1 sont bcp plus facile a trouver que cet été ou j'ai vraiment galéré car jamais dispo...

IPtables, si il est correctement utilisé, il suffit. Une appliance dédiée, c'est bien si t'a un serveur de virtu et que tu veux te simplifier la vie sur les VMs : tu met tout derrière un UTM ou un truc du genre et c'est marre
Et "actif", c'est parceque j'en connais plein qui ont un iptables, mais comme ça :

 
Et ça, bah ça sert à rien.

Question de noob mais le firewall il sert à quelque chose si tous les ports sont fermés ?

C'est justement le firewall qui ferme les ports.
Du coup je comprends pas la question.

Exemple bête pour un serveur, mais t'as aucun service qui utilise TCP/UDP sur ta machine, tu n'as aucun port ouvert. Donc aucune connexion entrante possible non ?

Déjà une machine comme ça, c'est assez rare
Mais si t'a aucun port qui écoute, effectivement, t'es pas mal en sécurité.
Après, t'a les risques de recevoir un paquet forgé qui provoque un truc niveau noyaux/driver/stack réseau, mais c'est pas avec un pare-feux local que tu t'en protègera

Ok, merci

Petite question concernant les anti DDoS Game, ça vaut vraiment le coup de filtrer son trafic UDP ?  Comme l'impression que c'est trop sensible ce truck...

Car je m'explique quant je filtre le port UDP de Teamspeak 3 il arrive que par moment celui ci ce met à ping et hache toute les conversations, je n'ai pas eu le choix que d'enlever le filtrage du port. Concernant les deux serveurs de jeux sur la même machine RAS avec un filtre à part une fois ou mes clients se sont fait jetés sans raison.

 
tu peux rajouter aussi, apprendre à configurer correctement ses services pour pas qu'ils écoutent sur 0.0.0.0.

Alors, oui et non. Oui parceque c'est important et que tout le monde devrait le faire (surtout pour les sgdb). Non parceque si tu configure bien ton pare-feux, tu limite pas mal le risque à moindre complexité.

Too late...  
Ils avaient vu large avec 48h  

15h30 y'avait déjà plus rien

A 16:30 j'ai pu créer un bon de commande pourtant. Ils devaient en avoir un paquet.

Ah ouais ?
Ptet' plusieurs vagues alors.

J'ai mis 55mn à en obtenir un.... à coup de F5/refresh      

Vous inquiétez pas, il y aura plein de serveurs dispos quand la Hadopi va durcir ses règles et s'intéresser aux serveurs dédiés ...

Tant qu'ils coupent que l'accès internet du serveur....

 
c'est la question que je me posais justement , les serveurs dédiés sont épargnés par la surveillance ? même ceux hébergé en france ?

Pour l'instant oui, mais l'année prochaine va falloir migrer au Canada

Je ne retrouve pas l'info, mais en attendant ils sont conscients du "problème", ce qui risque de faire évoluer la riposte graduée.
https://www.nextinpact.com/news/105 [...] dedies.htm

On va pas s’enflammer

Petite question j ai loue un serveur pendant le black friday ... (-30%) Et quelle surprise en découvrant ma facture ... Je suis facturé plein pot ! Il y a t il ici d autre personnes dans le même cas ?

La promo était uniquement sur la première facture