https://wiki.debian.org/fr/NetworkConfiguration

Une autre bonne lecture

Si tu le souhaites il doit y avoir des pentesters qui pourraient essayer de pénétrer ton serveur en recherche de failles et te les présenter

Justement je pense une fois mon serveur mis en place et sécurise sois faire moi même quelques pentest ( même si je débute donc je suis un peu nul ) sois demande je suis sur qu'il y en a qui se feront à Malin plaisir et défoncer ma sécurité

Savoir qui s'y connais et qui est juste un script kiddie, c'est pas si évident que ça ;)

en tout cas s'il y a des volontaires je suis preneur histoire de savoir un peu quels failles il peut y avoir

J'ai pas lu toutes les réponses mais disons qu'il y a des réflexes basiques qui évitent les trois quarts des emmerdes imaginables pour un serveur lambda:

- Fermer tous les ports, n'ouvrir que ceux qui sont indispensables pour fournir le(s) service(s) voulus (avec une règle iptables qui va bien, qui DROP directement tout ce qui n'a pas lieu d'être acheminé vers le système)
- Dans le cas de serveurs de connexion distante (classique et incontournable exemple: sshd), se prémunir des attaques de type bruteforce / dictionnaire visant à deviner le mot de passe du compte root (ou d'un autre compte, quand on en connait le login). Les outils comme fail2ban sont là pour ça (sinon, tu peux aussi gérer ce cas directement depuis ton parefeu en général)
- Proscrire l’exécution de logiciels en tant que root quand ça n'est pas nécessaire, afin de limiter la casse en cas de problème de sécurité dans un des services lancés (par exemple ton serveur Minecraft... dédie-lui un utilisateur, colle un screen ou tmux derrière une session ouverte depuis cet user, et donne-lui le moins de droits possibles -même en lecture- sur le filesystem du serveur)

Ajoute à ça une sécurité correcte au niveau de ta box d'opérateur si tu hostes chez toi (malheureusement tout n'est pas sous ton contrôle, à moins de changer le firmware du routeur), et c'est déjà un bon départ.

Après il y a évidemment des techniques plus avancées que ça mais les livres, guides en ligne et recommandations d'organismes comme l'ANSSI répondront mieux que moi sur le sujet (il y a de très bons bouquins chez Eyrolles concernant la sécurité informatique, j'en ai lu quelques uns et je ne suis pas déçu).

Oui j'ai acheté un livre sur le hacking ( hacker's guide ) et il est bien pratique car il apprendre en plus a securiser.
Apres je prefere toujours vous demander on sais jamais vous savez surement des trucs en plus

Donc en tout cas merci à vous je vais avoir du boulot

Huhu je viens de constater que je l'ai aussi mais je ne l'ai pas encore avalé celui-là

hahaha je ne suis que au debut mais vu ce que j'ai pu lire je commence à avoir peur
je me sens de moins en moins en securité

Tu peux aussi changer le port SSH par défaut (22 -> autre). Et désactiver l'authentification par mot de passe, uniquement par clés.

+1 pour ces deux conseils, c'est que je fais d'ailleurs (marrant que j'aie pas pensé à mentionner ça ). Enfin pour le port de connexion SSH, je garde le 22 en LAN par commodité (histoire d'économiser un paramètre de ligne de commande pour me connecter depuis chez moi ou sur mon VPN) mais mes règles NAT qui redirigent vers les différentes machines en SSH ont des ports tordus.

L'auth par clé uniquement, c'est cool parce que j'ai l'accès physique à la machine, par contre dans le cas d'un truc hosté ailleurs faut bien prévoir des backups de clés

@Lazao Tu mets un port non standard pour le SMTP aussi ?

+ Pour le HTTP c'est bien mignon mais je me vois pas donner des URLs du type http://example.com/truc.txt .

Pour le firewall ça amène plus d'emmerdes qu'autre chose. Surtout que c'est pas vraiment utile. Pourquoi irait-on bloquer un port sur lequel rien n'écoute dans tout les cas?
C'est utile quand on veut autoriser certains clients à accéder à certains services uniquement.

Perso je désactive iptables partout sauf si c'est pour du routage

@JamyGourmand Le firewall est utile quand tu veux contrôler les services qui sont accessibles sur ta machine.

Tu peux avoir un service qui tourne juste pour une utilisation locale, mais qui est mal configuré et qui écoute sur ton IP publique plutôt que sur la boucle locale. Le firewall te permet de par exemple, tout bloquer par défaut et autoriser explicitement une liste de ports (c'est ce que je fais). Ça te permet de pas avoir de doute, et d'avoir un seul endroit sur lequel tu contrôles ce qui est accessible depuis l'extérieur ou pas.

@vava Pour ça il y a les binds, si ce n'est pas possible avec l'application et que c'est l'objectif alors on peut utiliser un firewall.

De tête y a aucun serveur (que ce soit http,ssh,ftp,...) qui me vienne à l'esprit qui ne soit pas capable d'écouter sur une interface donnée. Utiliser un firewall pour ça alors que c'est possible de le faire avec l'application c'est overkill (et moche )

Franchement le point central de contrôle est quand même pratique.

On peut aussi vouloir empêcher les utilisateurs de faire tourner leurs propres services sur l'interface publique (du moins en empêcher l'accès), ça évite aussi qu'en cas d'intrusion au niveau user, on puisse faire écouter un programme sur l'interface publique.

╭
┊ Lazao, le 31 août 2014 à 07:33:35
┊ https://www.jeuxvideo.com/forums/1-38-7821335-2-0-1-0-securiser-son-serveur.htm#message_7821482
┊
┊ Fail2Ban
┊ Portsentry
┊ Iptables en béton armé
┊
┊ Ne laisser aucun port usuel pour les services standards (ftp, http...)
╰

"nmap -sV -A hostname" et qui fait quoi sur quel port (+ plein d'infos sympas).

Cela dit, ici peut intervenir portsentry ( http://www.deblan.tv/post/455/detection-de-scan-serveur ) mais tu te rend comptes que des centaines de scans par jours sont faits, et pas toujours pas de méchantes personnes

╭
┊ JamyGourmand, le 31 août 2014 à 12:33:54
┊ https://www.jeuxvideo.com/forums/1-38-7821335-2-0-1-0-securiser-son-serveur.htm#message_7821495
┊
┊ Pour le firewall ça amène plus d'emmerdes qu'autre chose. Surtout que c'est pas vraiment utile. Pourquoi irait-on bloquer un port sur lequel rien n'écoute dans tout les cas?
┊ C'est utile quand on veut autoriser certains clients à accéder à certains services uniquement.
┊
┊ Perso je désactive iptables partout sauf si c'est pour du routage
╰

Le NAT, tu le fais comment ? Le ping/sys flood, tu les gères comment ?

vdd +1

"Perso je désactive iptables partout sauf si c'est pour du routage"

Sauf que l'utilisation d'iptables qui est prônée sur ce topic c'est n'autoriser que quelques ports alors que dans tout les cas les autres ne servent à rien vu que rien n'écoute dessus.

Sur un serveur dans ce genre de cas les seuls comptes user sont des comptes root en général.

Enfin bref faut pas le prendre au pied de la lettre, j'ai pas du que iptables était inutile c'est un outil formidable mais ce qui est dit sur le topic là c'est clairement pas adapté/inutile

Et faire du NAT en 2014

Même avec le déploiement (foireux) de l'IPV6, il est tout à fait normal d'avoir un sous réseau IPV4 avec du frontend IPV6 avec du NAT derrière. Par ailleurs, rien d'oldschool à faire du NAT et je ne comprends vraiment pas ta remarque.

"Sur un serveur dans ce genre de cas les seuls comptes user sont des comptes root en général.", si tu configures correctement tes services, tu cloisonnes tes services (utilisateurs, chroot, voire des VM).

deblan.fr $ wc -l /etc/passwd
162 /etc/passwd