sebdangerfield.me.uk Report : Visit Site

Technical data of the sebdangerfield.me.uk

Geo IP provides you such as latitude, longitude and ISP (Internet Service Provider) etc. informations. Our GeoIP service found where is host sebdangerfield.me.uk. Currently, hosted in United Kingdom and its service provider is Linode LLC .

the related websites

forums.moneysavingexpert.com beigeuk.com typeonline.co.uk primarysite-kidszone.co.uk bps.org.uk tivysideadvertiser.co.uk snowhilltradesaddlery.co.uk ikea.com stiffandtrevillion.com boltoncollege.ac.uk richardhodgson.com 

HTTP Header Analysis

HTTP Header information is a part of HTTP protocol that a user's browser sends to called nginx containing the details of what the browser wants and will accept back from the web server.

DNS

HtmlToText

web & software development… | an attempt to remember what i've done web & software development… an attempt to remember what i've done search main menu skip to primary content skip to secondary content home web development software contact me post navigation ← older posts using puppet trusted facts posted on june 28, 2015 by seb dangerfield reply how to improve the security around holding private information in puppet. what are trusted facts: by default when puppet runs on a node, facter will discover system information and other custom values and report them back to the puppet master as facts, however you have no guarantee the node is telling the truth, the facts are self-reporting. this may not be such an issue with certain facts, i.e. kernelversion or swapfree , as if these are reported incorrectly it will probably just result in the puppet run failng and not be of any real security concern. however if you’re using the roles/profiles pattern and you store sensitive/private information in your puppet code or hiera files (such as private keys) then if the role or tier facts were to be changed this could easily lead to data leakage and one server receiving the private information of another. trusted facts however are extracted from the node’s certificate, which can prove that the ca checked and approved them and prevents them been overridden. why should i use them: suppose you have the following (very simple) setup, with web accessible servers sharing a puppet master. each server sits in it’s own subnet and is firewalled off from the other subnets. the two web servers can not talk via internal networks directly to each other. if the the private key for the x509 cert used for the https connection on the so called “secure server” is stored within hiera and installed by puppet, then if someone with malicious intent was able to compromise the “corporate site” server and gain root access they could easily change the role fact over to the same as the “secure server” and subsequently gain access to the private key. simple server layout topology, each server in own subnet with fw preventing the two frontend servers communicating with each other. if you were using trusted facts however this would not be possible as the role would be baked into the nodes certificate and as a result would require the puppet master to sign a new cert before giving up any private information. now you may argue that it requires root access (or at least access to the puppet user account) to make this work. and if root access has been gained then it’s already game over. well not entirely, because you only have root access to the one server, and this server doesn’t hold anything confidential (still bad obviously but could be a lot worse), there is also no easy way to pivot off this machine to target others. but using puppet you could easily pull down all the private info about any other machines in other networks (sharing the same puppet master) without even gaining any access to them let alone privileged access (and you don’t need find vulnerabilities in puppet). how to use trusted facts: on the puppet master if using open source < v4.0 you will need to enable trusted_node_data within your puppet.conf file. pe has this enabled by default. [master] ... trusted_node_data = true ... then when bringing up new nodes for the first time, before launching the first puppet run add a new section in the csr_attributes.yaml setting your facts, for example: # /etc/puppet/csr_attributes.yaml extension_requests: "1.3.6.1.4.1.34380.1.1.100": "secure-site" "1.3.6.1.4.1.34380.1.1.101": "prod" these facts will then be added into the certificate signed by the puppet ca (as long as the puppet ca approves them). the “1.3.6.1.4.1.34380.1.1.100” bit is an oid, you cannot use a string here unless it is a registered oid because as part of x509 spec this will be mapped to an oid if it’s not one already. puppet 3.4 – 3.8 registered a few basic ones within the ppregcertext oid range: puppet 3.8 ppregcertext oids . however puppet 4 has now introduced a much more compressive list of oids: puppet 4+ ppregcertext oids . note: i have picked the oids "1.3.6.1.4.1.34380.1.1.100" and "1.3.6.1.4.1.34380.1.1.100" arbitrarily, simply using the ppregcertext oid range and bumping up the last number to way beyond what puppet are currently using. so the example above for puppet 4 could be simplified to: extension_requests: pp_role: "secure-site" pp_environment: "prod" within your puppet code the trusted facts are available through the $trusted hash, but to make them more friendly, and usable by your hiera structure you can set global variables to equal those of your trusted ones: if you add the following to your initial point of entry .pp file (e.g. default.pp or entry.pp ): $role = $trusted['extensions']['1.3.6.1.4.1.34380.1.1.100'] $tier = $trusted['extensions']['1.3.6.1.4.1.34380.1.1.101'] you can then use the $role and $tier variables in your hiera hierarchy just as you would with normal facts. :hierarchy: - "%{::environment}/hiera/role_%{::role}/tier_%{::tier}" - "%{::environment}/hiera/role_%{::role}" - "%{::environment}/hiera/osfamily/%{::os_family}" - "%{::environment}/hiera/virtual/%{::virtual}" - "%{::environment}/hiera/common" approving puppet csr extensions unfortunately puppets build in cert list command does not have the ability to show csr extension_requests. so you’ll need check these manually, this could easily be done by using openssl: openssl req -noout -text -in .pem seeing it all in action to help show this in action i have created docker images, puppet master, corporate site and secure site ones. there is a vagrant template to enable launching these quickly. you will need to have the following installed: docker vagrant librarian puppet then simply clone the the pug-puppet repo onto your machine, and pull in the puppet modules: git clone https://github.com/sedan07/pug-puppet.git librarian-puppet install then the vagrant repo : git clone https://github.com/sedan07/pug-vagrant.git copy the config.yaml.dist file to config.yaml and change the puppet_repo_dir line to point to the pug-puppet dir you created above. now you can launch the containers: vagrant up pug-puppet-master vagrant up pug-web-http vagrant up pug-web-https launch a shell in the containers using the docker exec command: docker exec -it pug-web-http /bin/bash from within either of the web servers try launching a puppet run: puppet agent -t and see what happens. then try overriding one of the facts like the role by setting it as an external fact : echo "role=secure-site" > /etc/facter/facts.d/role.txt the pug-puppet repo contains 3 branches: master (trusted facts enabled and enforced) migration (allows nodes with no trusted data in their cert to still connect, but certs with trusted data must always use those facts) not_trusted (standard no-trusted-facts way of doing things) the migration branch mentioned above shows a simple way to allow you to migrate your servers from not using trusted facts over to using them a few at a time, without breaking all the non-migrated ones. on a side note: you should use eyaml (or similar) for storing your private information securely at rest in puppet. as well as making sure only personnel who actually need to day-to-day access to your puppet/hiera repo that holds your secrets have access. posted in devops , linux , server | tagged facter , how to , puppet | leave a reply securing a private docker registry posted on february 4, 2015 by seb dangerfield reply so when i researched this a few weeks back most of the guidance i found suggested using basic auth. now nothing wrong with this method as such, it works after all. however if you’re running a registry for more than one user you obviously don’t want to have just one username/password to access it. this then means having a way to add new users easily to it + “bot” users for your servers and so on. however there is actually a much better way, usin

URL analysis for sebdangerfield.me.uk

http://www.sebdangerfield.me.uk/2011/12/
http://www.sebdangerfield.me.uk/2010/11/
http://www.sebdangerfield.me.uk/2011/04/
http://www.sebdangerfield.me.uk/tag/javascript/
http://www.sebdangerfield.me.uk/2012/12/nginx-and-php-fpm-bash-script-for-deleting-old-vhosts/#comments
http://www.sebdangerfield.me.uk/tag/apache/
http://www.sebdangerfield.me.uk/2014/01/angularjs-protractor-app-already-bootstrapped-error/
http://www.sebdangerfield.me.uk/category/speed/
http://www.sebdangerfield.me.uk/tag/games/
http://www.sebdangerfield.me.uk/2012/10/nss-error-8023-using-aws-sdk-for-php/
http://www.sebdangerfield.me.uk/#secondary
http://www.sebdangerfield.me.uk/sdinteractivechartplugin
http://www.sebdangerfield.me.uk/author/sebdanger/
http://www.sebdangerfield.me.uk/tag/server-2/
http://www.sebdangerfield.me.uk/tag/openssl/
codeclub.org.uk
old.wsaf.org.uk
jamestoyer.me.uk
wsaf10.wsaf.org.uk
beka.me.uk

Whois Information

Whois is a protocol that is access to registering information. You can reach when the website was registered, when it will be expire, what is contact details of the site with the following informations. In a nutshell, it includes these informations;

Domain name:
sebdangerfield.me.uk

Registrant:
Seb Dangerfield

Registrant type:
Unknown

Registrant's address:
99 West Hill Road
London
SW18 5HR
United Kingdom

Data validation:
Nominet was not able to match the registrant's name and/or address against a 3rd party source on 02-Jul-2016

Registrar:
Gandi [Tag = GANDI]
URL: http://www.gandi.net

Relevant dates:
Registered on: 15-Apr-2010
Expiry date: 15-Apr-2018
Last updated: 29-Jul-2017

Registration status:
Registered until expiry date.

Name servers:
ns-1364.awsdns-42.org
ns-1808.awsdns-34.co.uk 205.251.199.16
ns-439.awsdns-54.com
ns-590.awsdns-09.net

WHOIS lookup made at 02:47:31 30-Sep-2017

--
This WHOIS information is provided for free by Nominet UK the central registry
for .uk domain names. This information and the .uk WHOIS are:

Copyright Nominet UK 1996 - 2017.

You may not access the .uk WHOIS or use any data from it except as permitted
by the terms of use available in full at http://www.nominet.uk/whoisterms,
which includes restrictions on: (A) use of the data for advertising, or its
repackaging, recompilation, redistribution or reuse (B) obscuring, removing
or hiding any or all of this notice and (C) exceeding query rate or volume
limits. The data is provided on an 'as-is' basis and may lag behind the
register. Access may be withdrawn or restricted at any time.

  REFERRER http://www.nominet.org.uk

  REGISTRAR Nominet UK

SERVERS

  SERVER uk.whois-servers.net

  ARGS sebdangerfield.me.uk

  PORT 43

  TYPE domain

OWNER

  ORGANIZATION Seb Dangerfield

TYPE
Unknown

ADDRESS
99 West Hill Road
London
SW18 5HR
United Kingdom
Data validation:
Nominet was not able to match the registrant's name and/or address against a 3rd party source on 02-Jul-2016

DOMAIN

  SPONSOR Gandi [Tag = GANDI]

  CREATED 2010-04-15

  CHANGED 2017-07-29

STATUS
Registered until expiry date.

NSERVER

  NS-1364.AWSDNS-42.ORG 205.251.197.84

  NS-1808.AWSDNS-34.CO.UK 205.251.199.16

  NS-439.AWSDNS-54.COM 205.251.193.183

  NS-590.AWSDNS-09.NET 205.251.194.78

  NAME sebdangerfield.me.uk

DISCLAIMER
This WHOIS information is provided for free by Nominet UK the central registry
for .uk domain names. This information and the .uk WHOIS are:
Copyright Nominet UK 1996 - 2017.
You may not access the .uk WHOIS or use any data from it except as permitted
by the terms of use available in full at http://www.nominet.uk/whoisterms,
which includes restrictions on: (A) use of the data for advertising, or its
repackaging, recompilation, redistribution or reuse (B) obscuring, removing
or hiding any or all of this notice and (C) exceeding query rate or volume
limits. The data is provided on an 'as-is' basis and may lag behind the
register. Access may be withdrawn or restricted at any time.

  REGISTERED yes

Mistakes

The following list shows you to spelling mistakes possible of the internet users for the website searched .