La description :tutoriels, astuces et tests autour de linux, docker, kubernetes, prometheus, saltstack......
Classement Alexa Global: # 7,247,918
Server:nginx/1.10.3... X-Powered-By:NodeBB
L'adresse IP principale: 54.38.241.37,Votre serveur United States,Rahway
ISP:Merck and Co. Inc. TLD:fr Code postal:us
Ce rapport est mis à jour en 17-Oct-2018
Created Date:
2011-07-01
Changed Date:
2017-06-02
Expires Date:
2018-01-06
Données techniques du binbash.fr
Geo IP vous fournit comme la latitude, la longitude et l'ISP (Internet Service Provider) etc. informations.
Notre service GeoIP a trouvé l'hôte binbash.fr.Actuellement, hébergé dans United States et son fournisseur de services est Merck and Co. Inc. .
Les informations d'en-tête HTTP font partie du protocole HTTP que le navigateur d'un utilisateur envoie à appelé nginx/1.10.3 contenant les détails de ce que le navigateur veut et acceptera de nouveau du serveur Web.
MX preference = 1, mail exchanger = redirect.ovh.net.
HtmlToText
navigation s'inscrire se connecter recherche recherche catégories récent mots-clés populaire groupes your browser does not seem to support javascript. as a result, your viewing experience will be diminished, and you may not be able to execute some actions. please download a browser that supports javascript, or enable it if it's disabled (i.e. noscript). catégories annonces annonces du site 0 sujets 0 messages pas de nouveau message le bistrot discussions libres 0 sujets 0 messages pas de nouveau message technos linux, docker, kubernetes… 35 sujets 39 messages pré-requis il vous faudra : un vault un salt se connecter en ssh avec une clé publique signée par vault vault ssh secrets engine la première étape est d’activer le “ssh secrets engine” de votre vault. c’est grâce à lui que vous pourrez signer plus tard votre clé publique ssh et ensuite vous connecter sur l’ensemble de serveurs associés à l’autorité de certification derrière cette signature. ce n’est pas clair ? bon. se connecter avec vault ssh, comment ça marche ? rien de très compliqué, la documentation est plutôt claire. monter le ssh secrets engine : ❯ vault secrets enable -path=ssh ssh successfully mounted 'ssh' at 'ssh'! il faut maintenant installer l’autorité de certification qui signera les clés ssh. soit vous avez déjà un ca que vous pouvez injecter, soit vous demandez à vault de vous en générer un. pour l’exemple, je pars sur cette solution : ❯ vault write ssh/config/ca generate_signing_key=true key value --- ----- public_key ssh-rsa aaaab3nzac1yc2ea... il faut maintenant distribuer la clé publique de notre ca sur les serveurs à cibler par cette méthode d’authentification. pour récupérer cette clé, la documentation propose deux solutions : via curl : curl -o /etc/ssh/trusted-user-ca-keys.pem http://mon_vault:8200/v1/ssh-client-signer/public_key via le cli vault : vault read -field=public_key ssh-client-signer/config/ca > /etc/ssh/trusted-user-ca-keys.pem l’idée est donc de créer le fichier /etc/ssh/trusted-user-ca-keys.pem qui contiendra la clé publique sur vos serveurs. il faut ensuite rajouter dans votre sshd_config l’option suivante et redémarrer le service ssh : # /etc/ssh/sshd_config # ... trustedusercakeys /etc/ssh/trusted-user-ca-keys.pem il faut ensuite créer un rôle que vous allez ensuite utiliser pour signer votre clé ssh. par exemple : ❯ vault write ssh/roles/remi -<<"eoh" { "allow_user_certificates": true, "allowed_users": "*", "default_extensions": [ { "permit-pty": "", "permit-port-forwarding": "" } ], "key_type": "ca", "default_user": "remi", "ttl": "12h", "max_ttl": "24h" } eoh success! data written to: ssh/roles/remi avec ce rôle, je vais pouvoir générer une clé signée, valide pour 12h et me connecter avec le user remi uniquement. attention au max_ttl : si vous n’indiquez rien dans votre rôle, c’est celui par défaut qui sera utilisé. si vous voulez un ttl supérieur, ca ne fonctionnera pas ! j’en rajoute un identique en remplaçant le default_user par root. je dois maintenant rajouter une policy et la lier à mon user pour pouvoir signer ma clé. je rajoute la policy ssh-remi suivante dans un fichier ssh-remi.hcl: path "ssh/sign/root" { capabilities = [ "update" ] } path "ssh/sign/remi" { capabilities = [ "update" ] } puis : vault policy write ssh-remi ssh-remi.hcl success! uploaded policy: ssh-remi que je lie ensuite à mon compte (à adapter en fonction de votre méthode d’authentification et de vos policies) : vault write auth/userpass/users/remi policies="default,remi,ssh-remi" success! data written to: auth/userpass/users/remi signature de la clé et connexion ! tout est prêt côté vault et sur vos serveurs. avant de vous connecter il faut signer votre clé publique ssh. cette étape sera à refaire à l’expiration de cette clé, dans mon exemple, toutes les 12h. pour signer ma clé, je dois me connecter à mon vault : ❯ vault login -method=userpass username=remi success! you are now authenticated. the token information displayed below is already stored in the token helper. you do not need to run "vault login" again. future vault requests will automatically use this token. key value --- ----- token c8e token_accessor 4745 token_duration 8h token_renewable true token_policies [default remi ssh-remi] token_meta_username remi vérifiez que votre policy ssh se trouve bien dans vos policies. ici j’ai rajouté ssh-remi que je retrouve bien dans mon token. je peux maintenant (enfin) signer ma clé ssh : ❯ vault write -field=signed_key ssh/sign/remi public_key=@$home/.ssh/id_rsa.pub > signed-remi.pub \o/ si on regarde dans le détail : ❯ ssh-keygen -lf signed-remi.pub signed-remi.pub: type: ssh-rsa-cert-v01@openssh.com user certificate public key: rsa-cert sha256:koc21 signing ca: rsa sha256:1oa key id: "vault-userpass-remi-928" serial: 7658 valid: from 2018-05-23t22:07:03 to 2018-05-24t10:07:33 principals: remi critical options: (none) extensions: permit-port-forwarding permit-pty je peux me connecter sur mon serveur avec cette clé : ❯ ssh -i signed-remi.pub remi@mon_serveur automatiser la signature et la connexion histoire de simplifier tout ça, voici le lien vers un petit script à adapter selon votre besoin pour vous connecter à un serveur et éventuellement faire la signature de votre clé publique ssh. c’est ici. connecter salt à vault on va commencer avec quelques manips à faire côté vault. l’idée est de créer un approle qui est la méthode à utiliser pour connecter une appli, un service à vault. on pourra ensuite renseigner les identifiants dans la configuration de salt et ainsi autoriser salt a profiter de vault en fonction de la policy utilisée. approle je me base de nouveau sur la documentation pour créer mon nouvel approle : si ce n’est pas déjà activé, on active cette méthode d’authentification : ❯ vault auth enable approle rajoutez un rôle salt et adaptez à votre besoin cet exemple : ❯ vault write auth/approle/role/salt \ secret_id_ttl=0 \ token_ttl=10m \ token_max_ttl=15m \ secret_id_num_uses=0 \ policies="default,salt" \ period=0 \ token_num_uses=0 \ bind_secret_id=true } il est possible de rajouter d’autre contrainte comme brider l’utilisation de cet approle à une adresse ip ou à un réseau. plus de détails dans la documentation de l’api. on va maintenant créer la policy salt. deux choses à prévoir : salt va générer des token pour ses minions, il faut donc donner ce droit, puis, c’est le but de cet article, les droits pour créer et mettre à jour les mots de passe des serveurs. ce qui donne ici : path "pass_servers/*" { capabilities = ["create", "read", "update"] } path "auth/token/create" { capabilities = ["create", "update"] } stockez ces règles dans un fichier et appliquez les. exemple : ❯ vault policy write salt /root/vault_k8s/salt_policies.hcl success! uploaded policy: salt on va récupérer les informations nécessaires à salt pour la connexion sur le vault : ❯ vault read auth/approle/role/salt/role-id role_id db02de05-fa39-4855-059b-67221c5c2f63 ❯ vault write -f auth/approle/role/salt/secret-id secret_id 6a174c20-f6de-a53c-74d2-6018fcceff64 secret_id_accessor c454f7e5-996e-7230-6074-6ef26b7bcf86 attention la commande write -f génère un secret_id à chaque appel. configuration de salt sur votre salt master, rajoutez un fichier dans /etc/salt/master.d avec pour contenu : vault-home: driver: vault vault: url: https://mon_vault verify: true auth: method: approle role_id: db02de05-fa39-4855-059b-67221c5c2f63 secret_id: 6a174c20-f6de-a53c-74d2-6018fcceff64 policies: - salt peer_run: .*: - vault.generate_token si votre vault à un certificat autosigné, il faudra l’installer sur votre serveur salt ou passer l’option verify à false. relancez le service salt-master et salt-minion. tests vous devriez pouvoir créer et lire des secrets depuis salt. pour faire un test rapide, voici comment écrire un secret : ❯ salt 'mon_serveur' vault.write_secret pass_servers/test pass=coincoin mon_serveur: true et pour lire ce secret : ❯ salt 'mon_serveur' vault.read_secret pass_servers/test m
Whois est un protocole qui permet d'accéder aux informations d'enregistrement.Vous pouvez atteindre quand le site Web a été enregistré, quand il va expirer, quelles sont les coordonnées du site avec les informations suivantes. En un mot, il comprend ces informations;
%% %% This is the AFNIC Whois server. %% %% complete date format : DD/MM/YYYY %% short date format : DD/MM %% version : FRNIC-2.5 %% %% Rights restricted by copyright. %% See https://www.afnic.fr/en/products-and-services/services/whois/whois-special-notice/ %% %% Use '-h' option to obtain more information about this service. %% %% [2600:3c03:0000:0000:f03c:91ff:feae:779d REQUEST] >> binbash.fr %% %% RL Net [##########] - RL IP [#########.] %%
nic-hdl: ANO00-FRNIC type: PERSON contact: Ano Nymous remarks: -------------- WARNING -------------- remarks: While the registrar knows him/her, remarks: this person chose to restrict access remarks: to his/her personal data. So PLEASE, remarks: don't send emails to Ano Nymous. This remarks: address is bogus and there is no hope remarks: of a reply. remarks: -------------- WARNING -------------- registrar: OVH changed: 01/06/2017 anonymous@anonymous anonymous: YES obsoleted: NO eligstatus: ok eligdate: 01/06/2017 10:25:05 source: FRNIC
TYPE domain RegrInfo DISCLAIMER % % This is the AFNIC Whois server. % % complete date format : DD/MM/YYYY % short date format : DD/MM % version : FRNIC-2.5 % % Rights restricted by copyright. % See https://www.afnic.fr/en/products-and-services/services/whois/whois-special-notice/ % % Use '-h' option to obtain more information about this service. % % [2600:3c03:0000:0000:f03c:91ff:feae:779d REQUEST] >> binbash.fr % % RL Net [##########] - RL IP [#########.] %
REMARKS -------------- WARNING -------------- While the registrar knows him/her, this person chose to restrict access to his/her personal data. So PLEASE, don't send emails to Ano Nymous. This address is bogus and there is no hope of a reply. -------------- WARNING --------------
Nous utilisons des cookies pour personnaliser votre expérience sur notre site. En poursuivant votre navigation, vous acceptez cette utilisation. Apprendre encore plus
binbash.fr rapport :
Visitez le site