Reprise du message précédent :

épouse moi

J’suis pas sûr qu’O’gure laisse partir sa femme son multi comme ça

 
L'HV et les services pas sur le même bloc, c'est mandatory pour moi. Les faire causer entre elles (montages NFS, SQL) sur VPN c'est aussi mandatory, donc, au pire oui je peut virer l'accès pub du SQL et le serveur NFS. En revanche j'ai oubliée le front FTP.
En compactant un peu, le strict minimum c'est une VM front FTP/Web/Mail, une VM minecraft, une VM vocal ayant une IP publique, auxquels faut rajouter l'IP de l'HV (qui est lock), et un front VPN/captif/passerelle pour l'accès a l'infra et une infra test.
Soit 6 IP publiques. Je préfère que l'ip de l'HV ne soit pas sur le même pool ip que le reste de l'infra.
Se qui fait au final 5 adresses sur un /29 + 1 en rab et une adresse pour l'HV.
 
Ça me parait pas déconnant si je veux un truc un minimum sérieux, sécurisé et "extension proof".

Oggy m'a dit de le laisser tranquille. Y'a longtemps. Il aime pas les relations platoniques/épistolaire  

Je reste convaincu que tu pourrais mettre tout tes services sur un lan privé avec une seule machine qui fait du NAT en frontal. Voir même sur plusieurs LAN privés et/ou avec du VPN entre chaque machine pour les liens entre elles (NFS, SQL).
Mais je vois toujours pas le besoin (autre que la flemme ou la facilité, mais ça je comprend parfaitement ), d'avoir une IP publique sur le reverse proxy, sur le serveur minecraft, sur le VPN, ...  
A la limite, un NAT de test et un de "prod", + une pour l'HV.

On a enfin l'explication de ceci.

Au mieux tu peux tenir sur 1 IP, la version luxe c'est 3 IPs (Infra + VPN + Infra-Test) et la version autiste c'est tout ce qui est au dessus de 3.
Et puis cet entêtement à faire tourner tous ses services en VM, c'est so 90's

c'est à dire ? utiliser des containers ? (LXC, docker, what else ?)

Je pensais à docker,  oui

En direct de iceweasel 29.0 sur une debian qui n'a pas vécue en 2 ans passés \o/

kernel 3.13-1  

o_0;;;

Docker je suis moyennement fan, notament à cause de tous les mauvais usages qui peuvent en découler... Le "Hitler uses Docker" en liste quelques un par exemple https://www.youtube.com/watch?v=PivpCKEiQOQ
Après, du container (lxc, openvz dans le passé, des jail BSD) plutôt que de la VM pour tout les cas où une VM se justifie pas, totalement oui

 
Et la sécurité, c'est so 90's aussi ?
L'HA et la gestion des catastrophes aussi c'est so 90's ?
La recrudescence des problèmes ne fait qu'augmenter dans l'IT, c'est peut être pas qu'un soucis d'échelle, mais aussi un soucis de process non ?

La sécurité en filant des IPs publiques à toutes tes machines VS en les planquants sur des LANs privés derrière un pare-feux (deux différents en cascade si t'es un peu tatillon) ?
L'HA avec une seule machine de chaque mais "tel service sera dispo si une autre machine se viande" ?

 
Le nat et le forwarding n'à jamais été efficace pour protéger une machine, un pare-feux en cascade non plus : tu expose un service, forcément que le service est faible. Tu va pas coller un site web publique derrière un pare-feu, l'intérêt est proche du néant absolu : le port 80 sera ouvert, si la machine sur son IP publique n'a rien d'autre d'ouvert, oukilé le problème ? Edit : en cas de pépin, seul le front web tombe, tu le relance sur une autre machine soit en changeant le DNS (long en principe) soit en relançant une vm sur le même pool.
Si tu fait un proxy/Nat/forward, t'expose le service de nat et donc une partie de ton réseau d'entreprise privé au publique : là c'est plus grave que de se faire péter un apache jailé en chroot sur une machine.
 
Edit bis : Les container restent de la jail améliorée avec une isolation au niveau kernel et des mécanismes d'isolation mémoire assez branlant. Il n'y a pas de notion de gestion de ressources qu'on retrouve dans une instance de VM.

 
le gens qui font de la vraie prod vs les autres ...
 

bonjour,

 
Vraie prod pour la commun des mortels = VMs
 
Après ya « ceux dans le cloud » avec des soft fabriqués dans cette optique et qui ont des besoins élastiques importants : les containers peuvent être très utiles (bien que souvent placés sur des VMs )
 
Bref, on est pas près de voir le combo metal+virtu disparaître. Au contraire, les usages vont vers metal+virtu+containers.

Tout à fait, mais rien ne t'empêche de les faire avec un pare-feux ayant un minimum plus d'intelligence qu'un iptable, qui sera capable de détecter une attaque sur les couches hautes.

Jamais entendu parler de pare-feu applicatif ? Typiquement pour du http/https (ça colle parfaitement à la situation exposée), mais il en existe pour d'autres protocoles/applications.

Oui, enfin, ça, ton hyperviseur doit pouvoir le faire tout seul non ? Allez, avec un peu de scripting

On parlais d'un dédié pour minecraft, ou du réseau de ta boite
Alors oui, si tu te fait démonter ton nat, l'attaquant à la main sur ton traffic. Et c'est tout. De l'autre côté, il trouve... Exactement ce qu'il aurait trouvé en frontal sinon.

Euh... Pas au même niveau, évidement, d'ailleurs ça me semble logique, mais tu peux pas dire qu'il n'y en a pas. Tu peux limiter les utilisations mémoire, le nombre de threads CPU alloués, les temps CPU du scheduler, l'utilisation swap... Et tu peux même aller plus loin : limiter le nombre de descripteurs de fichiers autorisés, ...

Question: c'est ridicule en 2016 de faire un blog sur des sujets techniques (style OSA) ? (oui je sais j'ai que ça à foutre de ma vie)

 
Le problème d'un blog purement perso c'est qu'il sera lu que si tu postes régulièrement. On est saturé « d'endroits » à surveiller. Si t'es en mode que « de temps en temps » je te conseille peut être d'aller voir du côté de Medium http://medium.com/

non, pas mon point de vue.
c'est toujours intéressant.

 
Méh, iptable célebieng !
 

 
Pas possible pour du minecraft, faut aller protéger des coms hors "well known"
 

 
Ben oui, mais tu me dis qu'avoir de l'HA, c'pas possible avec mon archi, alors que si.  
 

 
On parle d'un POC, un loisir pour moi passer le temps parce que je ne bosse plus, j'ai quand même le droit de me faire plaisir non ?
Je préfère qu'il ai la main sur un frontal, quitte a lui laisser en honey pot et l'isoler du reste de l'infra en mode IP "àlabourin" plutôt qu'il ai la main sur un nat, et tout le traffic, une limitation BP en mode IP est toujours plus efficace qu'en mode soft nat : une histoire de PPS a gérer.
 

 
Sauf que des cgroups, et du scripting cgroup, j'en ai suffisamment bouffer pour gérer/booster de la stack IB (entre autre) et gérer du PCI-e pour pas en plus me faire chier a devoir gérer un container complet, surtout que comme dit au dessus, du java, dans une jvm, pour la profiler hum, pour du http, smtp, pop, imap, passe encore, mais minecraft (je pense pas que ça ai jamais été fait de profiler une jvm minecraft en plus, ça serait une première).

Tootafé, mais ça fait pas le café
Même si avec firewalld, on s'approche d'un truc de plus en plus propre

Et c'est pas étonant. Pour le mail, le web, même tes sessions SSL à la limite, ça me semble pas si déconnant

La HA avec un seul serveur physique, ça reste du lol, désolé

Évidement, et puis quand bien même, c'est pas à moi de te dire ce que t'a le droit ou pas de faire
Mais du coup, parler du réseau de l'entreprise, ça fait bizarre à lire au milieu de la conversation

A la limite, c'est le seul argument convaincant que je vois pour avoir une IP publique/service et par machine.

C'est pas pour autant que y'a pas de notions de gestion de ressources. Et puis bon, pour poser 3 limites de ram/swap/nombre de cores attribués, t'a peut être pas besoin de faire un profiling non plus

J’ai pourtant lu à plusieurs reprises que le bidule de BSD est bien mieux torché

MystX, même en mode loisirs elle file mal à la tête

Sur ce je retourne à mes vacances

Ouais enfin faut remettre ça dans le contexte de son besoin.
Amha à titre perso c'est plus simple de maintenir 6 container que 6 VMs.

Maintenant pour la remarque, t'as aussi du container qui arrive en prod assez méchamment (les dev adorent...), surtout quand ton cloud OS est capable de prendre en charge de manière quasi transparente de la VM ou du container.

Anyway au final les archis c'est généralement un cloud OS (#hypeword) qui va s'occuper de faire tourner des VMs qui vont elles même s'occuper de faire tourner des services de manière isolées, ca marche bien et ca pallie les manquements des container (particulièrement au niveau gestion des ressources).

+1, thx OpenStack.

+1, le trafic et la visibilité générée quand tu publies une fois toutes les deux semaines est ridicule (source: j'en ai fait l’expérience).
Au final y'a que quand tu traites de sujets "communs" (comment installer xy sur yz ou fixer tel problème assez rependu) que tu arrives à vraiment générer du trafic et de la VU, tout ce qui est un peu plus pointu est très très peu consulté en comparaison...

 
pf vs iptables y'a même pas débat, suffit de regarder une conf pour un même besoin (un peu péchu) pour se rendre compte que iptables est à la traine.
nftables par contre c'est sexy et je comprend pas pourquoi on continue d'utiliser iptables alors que depuis 3.13 nftables est dispo.

Il dit qu'il voit pas le rapport si tu ponds proprement ton archi + containers.
C'est quoi, du FUD ?

Je vois pas le rapport non plus et vu le besoin décrit ça me fait doucement glousser.

Amha de compétences et de transformation rapide plus qu'autre chose mais je comprends le fond du raisonnement.

Parce que nftables n'est pas compatible systemd ?

 
  Thx Xen Orchestra

comme tu dis, pour du/des dev's' ... dans ce cas là, je suis d'accord ...les 'containers' (docker ou autres) j'ai rien contre ... mais à ce jour, sur de la prod ( industrie, grands comptes ...) c'est pas encore ça ...par contre, dev, test, recette, ça fait son trou ...

 
C'est un problème de moyens en adéquation avec les demandes/besoins. Donc, du process. On s'en fou un peut que le process soit basé sur des compétences humaines, ou ai besoin d'être en mutation rapide.
 
Pour le reste : les container sont bien ... Pour du dev, en "hard" j'ai pas confiance, et c'est carrément merdique de devoir toucher a du binaire pour gérer des besoins en hard. L'export du binaire sur un CPU avec une IPC différente, une gestion des appels kernel différentes, ou même le cas tout con : passer d'un CPU qui gère le GC a merveille vers un CPU qui gère pas le GC/machine avec 4 core VS machine avec 20 cores (notion de gestion mémoire totalement différente) donc container se viande lamentablement.
 
Actuellement, ma limite reste metal+VM, je n'irai pas au dessus en matière d'isolation "infra" (pour le reste, chroot/BSD jail/Jail classique me vont parfaitement, mais je maitrise le soft et j'ai pas une gestion hasardeuse/comportement non reproductible en masse a gérer.)
 
nftable/pf OK, une sandbox BSD like pour jail + portail captif pour protéger le VPN, le reste : open bar sans firewall (où alors des règles vraiment classique), OSEF, un front web est pas censé avoir du SSH ouvert sur port publique, les ports publique ne servent qu'a servir du publique.
Mon IP publique ne sera censée avoir aucune interface de gestion.
Le front se fait ouvrir en deux par un script kiddie ? Pas grave, je lui laisse en honey pot et je réouvre le service a coté sans oublier d'avoir patcher. Les risques de se faire ouvrir pour un défaut de clé sont quasi nuls, pour une faille "connue" : faut patcher et maintenir a jour, et la 0-day ben c'est la tuile et t'aura beau avoir une mitige type firewalling, sur du publique, c'est forcément ton front qui se fait attaquer, donc le pare-feu est inutile.

bonjour,

--> http://www.pcworld.com/article/310 [...] d-mac.html
Vous trouvez pas que ça pue ?

J'utilise des containers, sur de la "vraie prod" Et ça a tendance à plutot bien fonctionner

non

 
Merci.

 
C'est pas un peu le juste retour après bash sur windows ?

j'aime bien bash, syndrome de Stockholm surement