OVH Community, votre nouvel espace communautaire.

iptables et ip6tables


Nowwhat
02/12/2015, 01h33
Citation Envoyé par captainadmin
Je suis complètement d'accord avec toi AnonymousCoward, le cas mysql est le plus pertinent, si tu as une infra multi serveur tu ouvriras le port 3306 et augmenteras le risque d'attaque sur un des services les plus critiques.
Toujours ok, mais est ce qu'on dépasse pas un peu (largement) l’utilisation 'simple ' d'un serveur ?
Dans ce cas précis, mon serveur MySQL parlera que avec le 'dialecte' SSL avec le type (mon serveur aussi) en face et je verrouille la porte 3306 pour qu'il ne reçoit que des données de mon (mes) autre(s) serveur(s).

La question d’origine est "fail2ban, les IPv4 ... et IPv6 alors ?"
Désolé, kmchen, le sujet est partie un peu HS.

Citation Envoyé par captainadmin
J'ajouterai que le firewall ne sert pas que à bloquer des ports mais aussi à filtrer du trafic non souhaité comme le scan de port, le broadcast, le flood icmp, j'en passe et des meilleurs.
Ce que j'ai dit ici : #10

Citation Envoyé par captainadmin
....mais les plateformes sont souvent plus complexe que cela et vu la complexité d'un firewall, il ne faut pas négliger ce point.
C'est exactement ça. Trop souvent on focus sur 'bloquer' les portes 'INPUT' (non-servis), l'usage plus correct de 'iptables' est comme t'as dit: filtrer les portes qu'on utilise.

Citation Envoyé par captainadmin
..... ou d'un port qui ne devait servir que pour une requête en local. Quand je vois ce que certains laisse trainer comme requête
autorisé depuis l'exterieur, je me dis qu'il faut faire très attention a ce qu'on laisse ouvert.
Correct. Je suis très fan de la famille 'netstat'

captainadmin
01/12/2015, 23h14
Hello,

Je suis complètement d'accord avec toi AnonymousCoward, le cas mysql est le plus pertinent, si tu as une infra multi serveur tu ouvriras le port 3306 et augmenteras le risque d'attaque sur un des services les plus critiques.

J'ajouterai que le firewall ne sert pas que à bloquer des ports mais aussi à filtrer du trafic non souhaité comme le scan de port, le broadcast, le flood icmp, j'en passe et des meilleurs.

Tu peux te dire que tu as confiance en ton appli, que si l'intrusion a eu lieu tout est perdu, mais les plateformes sont souvent plus complexe que cela et vu la complexité d'un firewall, il ne faut pas négliger ce point.
On est jamais à l'abri d'un oubli, d'un fail2ban qui plante ou d'un port qui ne devait servir que pour une requète en local. Quand je vois ce que certains laisse trainer comme requete autorisé depuis l'exterieur, je me dis qu'il faut faire très attention a ce qu'on laisse ouvert.

Bonne journée
http://www.captainadmin.com

Nowwhat
01/12/2015, 21h40
Dans l'ensemble, je suis d'accord avec toutes ces avancements, ...
Mais ...
Citation Envoyé par AnonymousCoward
- Il est très vite fait d'avoir un service installé genre mysql ou un serveur FTP ....
Ces services, justement sont TOUS, par défaut 'bound' à 'localhost' (127.0.01 ou ::1).
A l'admin de faire ce connerie monumentale d’attacher MySQL à un IP 'externe'.
Je sais très bien qu'on peut aussi prendre l'auto route à l'envers, mais le bon conducteur ne va pas tenter ça.
L'idiot, lui ......

FTP : il existe mieux depuis des années.

Citation Envoyé par AnonymousCoward
- Les serveurs OVH, à la livraison, incluent un service DNS activé pour accélérer la résolution des noms de domaine.
Oula ...
'bind', pour nommer un, n'est est présent en tant que 'esclave', et écoute que sur 'localhost' - ça change si l'admin désire activer son serveur DNS en tant que maître DNS d'un domaine, bien sur, mais de la à 'jouer le DNS pour la planète entier'.....

Garder ces applications à jour (et les programmes) et suivre les consignes comme indiqué dans le JT (par exemple) et tout va bien..

Citation Envoyé par AnonymousCoward
- Fail2ban ou équivalents ne permettent pas de protéger tous les services.
fail2ban (presque 6K IPv4 bloques en ce moment ) ne 'protège' que tes tentatives authentification répétitives auprès mes CMS (et OPO, IMAP, certains requêtes classiques et bidon coté serveur web (comme w00tw00t etc), DNS, etc
Je ne le vois pas vraiment comme outil de sécurité de mon serveur.

Coté IPv6 : t'as raison - je bloque direct le /56 par IPv6.

Citation Envoyé par AnonymousCoward
Quand OVH ferme un serveur parce-qu'il sert de relais pour en attaquer d'autres, j'approuve totalement.
+1

Citation Envoyé par AnonymousCoward
- Il y a beaucoup de hacks de scripts PHP qui se font ...
UN des mes critères pour sélectionner un 'plugin' ou 'extension' d'un CMS est : il est sur ? (le 'jolie' ou 'utile' sont MOINS important).
Bien sur, je vais parcourir le script pour voir comment il fonctionne ...

C'est vrai, un script PHP à la con va peut être 'seulement' farcir le serveur Mail avec des mails 'spam', sachant qu'il tourne sur l’identité (ou sous-identité) du serveur web il n'a pas le droit exécuter grand chose. Pour moi, le fait qu'un tiers arrive à exécuter quelque chose (pas mes scripts, mes CES scripts) sur MON serveur, je considère mon serveur est à deux doigts de se faire hacker complétement ....
Compter sur le fait que le hackeur n'est qu'un pauvre imbécile, je ne compte pas là dessus.

J'avoue, le doc d'Apache, de Bind, SSH (OpenSSL), postfix, c'est lourd - c'est longue.
Et totalement indispensable.
Heureusement, ces docs sont écrit et amélioré pendant des dizaines d'années, par des centaines des milliers de personnes.
J'y croix donc dans ces appliations. Le seule danger est et reste : l'ignorance du admin.
Et par ce que je suis 'vieux', j'adhère au : "quand on connait pas, on touche pas".
Notre serveur est quand même placé DANS l'internet, l'endroit ou il n'y pas de règles qui nous protège quand on foire son coup.


PS : merci pour ton analyse.

AnonymousCoward
01/12/2015, 18h45
Voilà pourquoi je pense qu'il est indispensable d'avoir un pare-feu qui filtre l'entrant ET le sortant :

- Il est très vite fait d'avoir un service installé genre mysql ou un serveur FTP qui écoute sur toutes les adresses IP (INADDR_ANY) et/ou qui ne sache pas brider les adresses IP autorisées à s'y connecter. En fait, la plupart des services ne sait pas faire ce genre de choses. Et là, on se fait pirater.

- Les serveurs OVH, à la livraison, incluent un service DNS activé pour accélérer la résolution des noms de domaine. Ne pas filtrer les accès à ce service DNS vous fera participer à des dénis de service distribué (DDOS) par amplification et votre serveur sera désactivé.
"when you leave a DNS resolver wide open, God kills a kitten"

- Fail2ban ou équivalents ne permettent pas de protéger tous les services. Et, quoiqu'il arrive, le filtrage par adresse IP est une voie sans-issue. Même hotmail/outlook n'arrive plus à gérer le filtrage des IPv4 sur les serveurs et c'est pourquoi ils ne filtrent plus que des /32 individuelles mais des sous-réseaux complets genre des /26.
Avec IPv6 et ses 128 bits d'adresses, vous imaginez la puissance de malade qu'il faudra pour espérer filtrer les adresses individuelles ? Ou même en ne filtrant que des /64 ? Avec des /64, juste 4 milliards de fois ce que même hotmail n'arrive plus à faire aujourd'hui.

- Ne pas mettre en place de pare-feu sortant permet que votre serveur aide à attaquer d'autres serveurs dès lors que n'importe-quelle script PHP à la c... se sera fait hacker. C'est complètement irresponsable envers les autres propriétaires de serveurs.
Quand OVH ferme un serveur parce-qu'il sert de relais pour en attaquer d'autres, j'approuve totalement.

- Il y a beaucoup de hacks de scripts PHP qui se font de manière automatisée et où l'attaquant ne cherche pas à faire une escalade de privilèges avec un exploit local, où il ne cherche pas à devenir root. Dans ce genre de cas, il ne peut pas désactiver le pare-feu.

--
AnonymousCoward

Nowwhat
30/11/2015, 20h59
Citation Envoyé par kmchen
....
Nowwhat:
Veux tu dire qu'iptables est inefficace ? Comment procèdes tu dans ce cas pour protéger ton serveur ?
Que penses tu de snort
Il existe cette idée qu'il faut utiliser "le parefeu" car sinon, ça craint.
Or : négatif.
Avec un postfix bien paramétré (portes 25/465/587/...)
Courier (ou dovecot) : portes 110, POPS, IMAP, IMAPS, etc
Serveur web, portes 80 et 443.
SSH : porte 22
DNS porte 53
NTP : porte ....
Etc
C'est CES portes sur laquelle un hackeur pourrait attaquer.
Pas sur une porte (exemple) '990' non servi.
Il faut donc filtres (ou bloquer pour avoir la sécurité maximum) CES portes, et pas les portes qui n'ont pas de services 'attaché' (car ça ne sers à rien).

Effectivement, mon "fail2ban" utilise mes iptables (et ip6tables) pour stopper les 'tentatives inutiles'.

Moi même, je ne n'occupe pas de 'iptables, je ne l'ai jamais fait.

Le problème souvent est que les gens gèrent tellement mal leur serveur (très souvent des scripts PHP mal au point), qu'il bloquent même tout le 'OUTPUT' car une fois un hackeur a accès au services (car un service est mal paramétré) un tâche qui tourne sur le serveur, dépose pas le hackeur, va communiquer avec la monde extérieur.
Mais dans ce cas, c'est déjà trop tard de toute façon : le hackeur est entrée, ce n'est qu'une question de temps il sera 'root' puis il virera toutes les règles 'parafeu' ....

kmchen
30/11/2015, 14h55
Merci pour vos réponses.

Ayant effectivement une IPV6 sur ce serveur je vais me contenter de bloquer ipv6tables en attendant d'avoir un peu plus de temps pour me consacrer à l'étude, plutôt exotérique je trouve, des ipv6

Nowwhat:
protéger des trous noirs avec des bouclie
Veux tu dire qu'iptables est inefficace ? Comment procèdes tu dans ce cas pour protéger ton serveur ?
Que penses tu de snort

SIP-Online
22/11/2015, 22h24
La fin est proche uniquement pour ce qui est de la fin du stock d'adresse IPv4, mais pas sur son utilisation, surtout en France, que beaucoup de serveurs n'ont pas de zone AAAA et de services web configurer efficacement pour recevoir par exemple des requêtes sur le port 80/443.

J'espère juste qu'il y aura un successeur de l'IPv6, car c'est une horreur de mémoriser une telle adresse IP.
Amusez-vous à faire vos tests avec cet outil, vous serez étonnés du peu de sites compatibles en IPv6 : http://ipv6-test.com/validate.php
PS : Ne cherchez pas sur mes sites ou infogérance, ils sont tous compatible en IPv6 (Web/Mail).

captainadmin
22/11/2015, 18h14
Hello,

Il faut faire les serveurs et les sites ipv6 ready, car l'usage arrive et surtout la fin des ipv4 est proche.
Ce qu'il y a de mieux a faire c'est de mettre ipv4 et ipv6 en parallèle pour assurer le service des 2 protocoles.

De mémoire, il y a aussi un gros avantage a faire de l'ipv6, c'est que google référence mieux les sites qui sont prêt pour recevoir ce trafic.

Bref il ne faut pas se limiter lorsque le futur est si proche de se démocratiser ...

Bon courage pour la suite
http://www.captainadmin.com

fritz2cat
19/11/2015, 22h47
enfin lol mon FAI (Scarlet) ne propose pas IPv6 chez moi, et vu depuis l'extérieur c'est IPv4 "only"...
Code:
# dig scarlet.be aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;scarlet.be.                    IN      AAAA

# dig www.scarlet.be aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.scarlet.be.                        IN      AAAA


# dig scarlet.be ns
;; ANSWER SECTION:
scarlet.be.             14400   IN      NS      ns2.scartech.be.
scarlet.be.             14400   IN      NS      ns3.scartech.be.
scarlet.be.             14400   IN      NS      ns1.scartech.be.

# for i in 1 2 3; do dig ns$i.scartech.be aaaa; done
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ns1.scartech.be aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.scartech.be.               IN      AAAA

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ns2.scartech.be aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ns3.scartech.be aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Nowwhat
19/11/2015, 21h48
Citation Envoyé par fritz2cat
Merci pour le lien !
Belgique 51% soyons chauvins
Effectivement.

Le IPv4 fonctionne tellement mal la bas qu'ils ont du chercher autre chose ?
Oublié d'acheter des pacs d'IPv4 en réserve ?

Bref, suis natif de Pays Bas, et là, c'est le drame .....

fritz2cat
19/11/2015, 21h00
Merci pour le lien !
Belgique 51% soyons chauvins

AnonymousCoward
19/11/2015, 20h37
Il y a des avantages et des inconvénients à passer à IPv6.

Je me contenterais de faire la liste de quelques avantages :
- Simplification dramatique des applications P2P. Que ce soit de transfert de fichiers ou de communication comme Skype, des jeux vidéo en réseau.
- Permet de faire passer des applications / usages que le NAT empêchait ou gênait (comme le FTP, le SIP).
- Meilleure gestion de la qualité de service.
- Meilleure gestion de la MTU.
- Les paquets IPv6 sont traités plus rapidement par les routeurs que les paquets IPv4.
- On pourrait enfin envisager d'avoir des services / serveurs sur les machines reliées par téléphonie mobile. en 4G, par exemple. Je ne connais pas d'opérateur de téléphonie en France sans (CG)NAT sur les accès data.
- Meilleure gestion du multicast, que ce soit pour les fournisseurs de vidéo ou pour les logiciels de communication/vidéo-conférence.
- En IPv4, accéder à un service (comme un site web) hébergé sur ton accès derrière du NAT depuis des clients derrière le même NAT était problématique. IPv6 supprime ce problème. C'est mieux pour l'auto-hébergement.

Pour un serveur web, je ne pense pas que l'avantage soit énorme. Eventuellement, pour héberger plusieurs sites en https et qu'ils soient accessibles à IE6. (suis-je odieux !)

Ce qui est certain, c'est que l'usage d'IPv6 est en plein boom. http://stats.labs.apnic.net/ipv6

--
AnonymousCoward

Nowwhat
19/11/2015, 16h46
Bonjour,

Dès-activer IPv6 est encore pour quelques jours 'une solution'.
Soit: paramètre ip6tables pour qu'il bloque tout (INPUT et OUTPUT).
Mais sache une chose: les logiciels les plus connus, comme 'bind', 'postfix', 'apache2', etc sont déjà prêt depuis des années.
Par exemple: je vois sur mon serveur presque autant de connections 'postfix' purement IPv6 - de plus, postfix va, par défaut, tenter une connexion IPv6 avant de tenter une connexion IPv4 (sauf, bien sur, si tu paramètre postfix d'ignorer le IPv6).

Bien sur, si t'as pas de IPv6 (OVH en donne quelques million par serveur ) activé sur ton serveur, inutile de créer des règles parafeu.

Et même : pourquoi s'en inquiéter ?
An tant que admin, on gère nos services, et ils ont presque tout l'option de travail en mode "IPv4 uniquement", mode IPv6 uniquement ou en mode mixte.

Cependant, je te conseille de "apprendre" ce IPv6 - ça va devenir indispensable.


PS : edit : si t'as deux minutes ..... faut que tu m'explique un truc.
J'utilise Debian 8.2 - 64 bits et boulons, et j'ai donc aussi ce iptables.
Or, je m'occupe pas de lui ... il n'y pas des règles .... la policy, il est par défaut sur "ACCEPT".
(Bon, ok, fail2ban s'amuse grave avec iptables , c'est vrai - mais moi, je ne le touche pas)

Me dit pas que t'es fan de "fermer des portes qui ne sont pas asservi" [autrement dit : protéger des trous noirs avec des bouclier ....).

kmchen
19/11/2015, 16h25
Bonjour,

En révisant l'iptables d'un serveur je m'aperçois qu'il ne sert à rien de créer un firewall si on ne le fait pas également en IPV6. Quelle est la nécessité pour un serveur WEB de gérer ipv6 actuellement ? Si je désactive IPV6 afin de ne pas avoir à tout faire en double les service de mon serveur seront-ils restreints ?

Merci pour vos réponses