Nouvelle configuration de sécurité


  • Administrateur

    Bonjour,

    Je met à contribution la communauté pour avoir des infos afin de mieux préparer les futurs parefeu composant le réseau.
    Merci de me lister les ports ou protocoles que vous utilisez pour vos activités au niveau des serveurs.
    Précisez moi avec le tableau suivant :

    Port : xxxxx (FTP par exemple)
    Protocole : TCP/UDP
    Accès public : OUI/NON
    Besoin de protection : OUI/NON
    Type de protection : pps (paquets par secondes), Mb/s (bande passante), SYN FLOOD (paquets tronqués) etc…

    Merci pour vos retours.
    Les ports dont nous n'aurions pas connaissance seront bloqués définitivement.



  • Les VPS sont sur le même réseau ?


  • Administrateur

    Oui.
    Le but étant d'optimiser les protections sur les ports les plus utilisés.



  • SSH :
    Port : 22 (Oui, pour ceux qui ne changent pas leur ports)
    Protocole : TCP
    Accès public : NON
    Besoin de protection : OUI
    Type de protection : Lecture d'Headers, comparaison (Style a la fail2ban, mais en NetFlow lookup's dans ce cadre-ci > http://shack.da-projekt.eu/di-8ZU1.jpg) + limite a 2mb/s par IP

    Counter-Strike : source
    Port : 27015:27050
    Protocole : TCP/UDP
    Accès public : OUI
    Besoin de protection : OUI
    Type de protection : SYN FLOOD + limite a 4 ou 5 mb/s par IP

    TS3 :
    Voice :
    Port : 9987:9995
    Protocole : UDP
    Accès public : OUI
    Besoin de protection : OUI
    Type de protection : Toujours une petite limite de BP par IP, sa ne fais jamais de mal.
    Query :
    Port : 10011
    Protocole : TCP
    Accès public : NON
    Besoin de protection : OUI
    Type de protection : Je dirais qui faut l'interdire de l'extérieur complétement vu le peu de personne l'utilisant a part avec un bot local.

    San Andreas : Multi-Player :

    Port : 7777
    Protocole : UDP
    Accès public : OUI
    Besoin de protection : OUI
    Type de protection : Petite limite de BP par IP.

    SQL :

    Port : 3306
    Protocole : TCP
    Accès public : NON
    Besoin de protection : OUI
    Type de protection : Selon les besoins, certains en ont besoin du a leur mysql-client, mais c'est rare. Donc, un DROP complet ou une seul IP autorisée dans l'ACL... a voir ;)

    (Liste peu exhaustive)



  • Port : SSH (22)
    Protocole : TCP
    Accès public : non
    Besoin de protection : oui
    Type de protection : nombre de connections d'ips différentes par minute

    Port : SMTP (25 )
    Protocole : TCP
    Accès public : oui
    Besoin de protection : oui
    Type de protection : nombre de connections d'ips différentes par minute

    Port : SMTPS (465)
    Protocole : TCP
    Accès public : non
    Besoin de protection : non
    Type de protection : nombre de connections d'ips différentes par minute

    Port : IMAPS (993)
    Protocole : TCP
    Accès public : non
    Besoin de protection : oui
    Type de protection : nombre de connections d'ips différentes par minute

    Port : Sieve (2000 & 4190)
    Protocole : TCP
    Accès public : non
    Besoin de protection : oui
    Type de protection : nombre de connections d'ips différentes par minute

    Port : LDAPS (636)
    Protocole : TCP
    Accès public : non
    Besoin de protection : oui
    Type de protection : nombre de connections par minute

    Port : XMPP (5222, 5269, 5280)
    Protocole : TCP
    Accès public : oui
    Besoin de protection : non
    Type de protection :

    Port : HTTP & HTTPS
    Protocole : TCP
    Accès public : oui
    Besoin de protection : oui
    Type de protection : requêtes/minutes

    • certains besoins futurs:

    Port : NFSv4 (2049)
    Protocole : TCP
    Accès public : non
    Besoin de protection : oui
    Type de protection : nombre de connections par minute



  • @spykeer:

    SSH :
    Port : 22 (Oui, pour ceux qui ne changent pas leur ports)
    Protocole : TCP
    Accès public : NON
    Besoin de protection : OUI
    Type de protection : Lecture d'Headers, comparaison (Style a la fail2ban, mais en NetFlow lookup's dans ce cadre-ci > http://shack.da-projekt.eu/di-8ZU1.jpg) + limite a 2mb/s par IP

    Du rsync a 2 mb/s ? Pas cool…
    Il faut 1 semaine pour faire un backup d'un serveur !
    @spykeer:

    Counter-Strike : source
    Port : 27015:27050
    Protocole : TCP/UDP
    Accès public : OUI
    Besoin de protection : OUI
    Type de protection : SYN FLOOD + limite a 4 ou 5 mb/s par IP

    TS3 :
    Voice :
    Port : 9987:9995
    Protocole : UDP
    Accès public : OUI
    Besoin de protection : OUI
    Type de protection : Toujours une petite limite de BP par IP, sa ne fais jamais de mal.
    Query :
    Port : 10011
    Protocole : TCP
    Accès public : NON
    Besoin de protection : OUI
    Type de protection : Je dirais qui faut l'interdire de l'extérieur complétement vu le peu de personne l'utilisant a part avec un bot local.

    San Andreas : Multi-Player :

    Port : 7777
    Protocole : UDP
    Accès public : OUI
    Besoin de protection : OUI
    Type de protection : Petite limite de BP par IP.

    SQL :

    Port : 3306
    Protocole : TCP
    Accès public : NON
    Besoin de protection : OUI
    Type de protection : Selon les besoins, certains en ont besoin du a leur mysql-client, mais c'est rare. Donc, un DROP complet ou une seul IP autorisée dans l'ACL… a voir ;)

    Si drop il y a, plus de réplication et plus de supervision ! pas cool :/



  • Du rsync a 2 mb/s ? Pas cool…
    Il faut 1 semaine pour faire un backup d'un serveur !

    Pareil, je ne suis pas trop pour un bridage du débit par IP.



  • @caaptusss:

    Les ports dont nous n'aurions pas connaissance seront bloqués définitivement.

    Si je comprends bien, les ports disponibles le seront par liste blanche? On marche sur la tête là, non? :shock:


  • Administrateur

    Non, pour l'instant, je laisse tout ouvert, mais j'applique des protections adapté en global pour certaines applications, histoire de protéger mieux les applications de nos clients face aux attaques.
    On a par contre décidé de fermer certains ports tel que ceux de l'IRC (les ports par défaut).



  • Salut,

    je sais pas si j'ai bien compris, mais on va avoir des ports bridés sur nos serveurs dédies ?

    si actuellement j'utilise que le 28960 et que dans 1 mois j'ai besoin du 28961 et qu'il est bloqué on fais comment ?

    sa me laisse perplexe cette idée, sa devient de plus en plus bridés non ?

    excusez moi si j'ai mal compris le post



  • Houlà c'est quoi cette histoire.. J'ouvre des nouveaux ports régulièrement selon mes besoins !!

    J'aurais aimé etre au courant du blocage du port 6667 avant que ça arrive également, le chat de mon lobby était indisponible pendant 24h (je n'étais pas à disposition pour mettre à jour le client).

    TCP :
    8067, 8001, 7001, 9001, 15000, 1980.

    UDP :

    • les habituels pour apache, ssh, …

    Tous en accès public, je ne comprend pas très bien ce que tu entend par "besoin de protection".

    Je suis sur que j'en oublie, et j'en aurais besoin de plus en TCP au fur et à mesure que mon lobby acceuille des fonctions supplémentaires. C'est pas très super cette histoire...



  • Tout a fais d'accord, on perd l’idée de serveur dédiés si on commence a bridés partout :s

    En attendant un éclairement sur cette histoire :)


  • Administrateur

    Si je viens en parler sur le forum, c'est justement pour en débattre :)
    Le réseau commence à se faire connaitre, et nous commençons à être confronté aux aléas habituels concernant les attaques et tentatives diverses et variés.

    Pour IRC, on aurait en effet pu s'y prendre plus tôt, et le bloquer dès le lancement du réseau et pas à l'arrache comme ça. C'est un oublis de notre part, colmaté dans l'urgence face à des flood UDP massif en IRC.

    Pour le reste, à ce jour rien n'est bloqué, et rien ne le sera. Nous souhaitons juste appliquer des protections (et non des bridages) sur certains ports pour protéger par exemple votre SSH ou vos ports de jeu.

    Je vous donne un exemple très concret. Si vous voulez qu'on limite les scan SSH, on va par exemple limiter le nombre de session par IP simultannés sur le port SSH. (c'est une idée à tester).
    Pour les ports de serveurs de jeux, on va par exemple limiter le nombre de paquets par seconde histoire de ne plus se faire flooder gratuitement.

    Bref, ce sont des pistes sur lequel je souhaite échanger avec vous tous (nos clients) afin de pouvoir protéger au mieux vos activités, et limiter l'impact au maximum lorsque ça floode ou autre.

    C'est ça aussi, un hébergeur qui discute avec ses clients :)



  • Ok c'est un peu plus clair :)

    Il y a un moyen simple sous linux de connaitre le nombre de packet envoyé par un port par sec/minute ?

    Parce que j'ai aucune idée de l'ordre de grandeur sur mes serveurs..



  • Ah ok, donc finalement on est dans l'esprit blacklist et non whitelist.
    Limiter le nombre de sessions SSH par IP pourquoi pas, mais faudra quand même pas viser trop bas car il m'est déjà arrivé d'avoir une petite dizaine de connexions. Mais est-ce que ça apporte vraiment quelque chose par rapport à un fail2ban correctement configuré?
    Après des protections spécifiques pour les jeux ou certaines applis, ça j'imagine que tu es le mieux placé pour savoir si +/- tout le monde fait tourner un serveur Minecraft (vu comme j'en entends parler souvent j'ai presque l'impression d'être le seul ici à pas avoir un serveur minecraft… ou en tout cas à n'y avoir jamais joué :mrgreen: ). Mais après avec la diversification des clients je me demande si ça restera gérable tout plein de protections +/- sur mesure. De mon côté en tout cas, je n'ai pas d'appli qui nécessite une protection particulière pour le moment.



  • Un petit tuto officiel sur comment sécuriser son serveur sous linux et windows pourrait être pas mal aussi. Tout ceux qui ont un dédié ne sont pas forcément des professionnel en gestion de serveur (moi le premier, j'ai suivi pas mal de tuto pour sécuriser un minimum mon serveur mais y a sûrement moyen d'améliorer le truc, sans partir dans des truc de paranoïaque), du coup si un maximum de serveur étaient relativement sécurisé (je sais pas si c'est le cas ou pas actuellement) ça te simplifierait peut-être un peu la tache caaptusss.



  • @fate:

    Un petit tuto officiel sur comment sécuriser son serveur sous linux et windows pourrait être pas mal aussi. Tout ceux qui ont un dédié ne sont pas forcément des professionnel en gestion de serveur (moi le premier, j'ai suivi pas mal de tuto pour sécuriser un minimum mon serveur mais y a sûrement moyen d'améliorer le truc, sans partir dans des truc de paranoïaque), du coup si un maximum de serveur étaient relativement sécurisé (je sais pas si c'est le cas ou pas actuellement) ça te simplifierait peut-être un peu la tache caaptusss.

    +1



  • Google les amis il y à tout ce que vous voulez …

    http://www.alsacreations.com/tuto/lire/ … ables.html
    http://www.tutoriels-video.fr/securiser … -rkhunter/

    Si vous ne comprenez vraiment rien alors faites le faire .



  • Il y a un moyen simple sous linux de connaitre le nombre de packet envoyé par un port par sec/minute ?

    http://www.aboutdebian.com/monitor.htm
    http://bandwidthd.sourceforge.net/

    C'est déjà dans les dépots debian :)



  • Niveau Minecraft on utilise de 25500 à 25565, pour les serveurs en eux-même, les ports 26500 jusqu'à 26665 pour les LiveMap et autres c***.

    Drop des packets serait intéressant, niveau attaque, mais j'ai bien peur que étant hébergeur, ca fasse un peu mal…

    A voir en action, mais pas ce mois ci, j'ai eu ce qui me fallait (lol).

    Ensuite, je suis Spykeer, sur les ports des serveurs de jeux, mais je rajouterai jusqu'à 64 ports (en plus ou en moins du port de base de CSS etc...), car difficile de mettre plus de 64 serveurs sur un i7 (en comptant des serveurs de 10 slots)...

    A voir, à creuser.



  • Moi j'ai trois serveur minecraft mais aucun sur les ports que tu indiques :mrgreen: (port 1,2 et 3 et map 8100,8200 et 8300)
    Mais c'est clair que serveur Minecraft pour flood et attaque DDOS ya pas mieux, donc un bridage ne serait pas inutile.


Se connecter pour répondre
 

Il semble que votre connexion ait été perdue, veuillez patienter pendant que nous vous re-connectons.