За целта първо трябва да се спре уеб сървъра, докато трае самото инсталиране на сертификатите ( осъществява се обратна връзка от сървърите на letsencrypt.org към моите домейни ) – отнема около 20~30 секунди.
Ако всичко е ОК трябва да видим и следното съобщение :
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/root.bg/fullchain.pem. Your cert will expire
on 2016-07-25. To obtain a new version of the certificate in the
future, simply run Let's Encrypt again.
- If you like Let's Encrypt, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Днес ще споделя за един проблем със сайта с който с сблъсках снощи. Когато го разцъквах през google chrome от телефона, горе катинарчето пред https беше станало оранжево, а не както съм свикнал досега да го виждам – зелено. Цъкайки на него ми излезе съобщение, че използвам SHA-1 hash криптиран алгоритъм, и че google ме съветва да го обновя до SHA-2, защото вече не било надежно.
Разбрах че използвам SHA-1 версия на Intermediate SSL от StartSSL го смених с правилния и проблема ми се реши.
Обаче с този проблем, аз започнах да ровя и открих, че има начин да направя така нареченото nginx SSL security – или да защитя още повече сайта си, както и да вдигна неговия performance.
Попаднах на този блог , където е описано стъпка по стъпка как да стане това.
В крайна сметка аз постигнах даже по-голям резултат от този на човека от блога 🙂
И накратко: уверих се че не използвам SSL протокол SSLv2 и SSLv3 – тъй като те са подлежими на хакерски атаки, а само TLSv1 TLSv1.1 TLSv1.2.
Също така активирах Online Certificate Status Protocol (OCSP) и резултата беше на лице:
nikolay@vostro ~ $ echo QUIT | openssl s_client -connect root.bg:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: 90AF6A3A945A0BD890EA125673DF43B43A28DAE7
Produced At: May 17 00:28:58 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7AE13EE8A0C42A2CB428CBE7A605461940E2A1E9
Issuer Key Hash: 90AF6A3A945A0BD890EA125673DF43B43A28DAE7
Serial Number: 83772FFC083846C3481DE580B765B566
Cert Status: good
This Update: May 17 00:28:58 2015 GMT
Next Update: May 21 00:28:58 2015 GMT
nikolay@vostro ~ $
За да работи OCSP трябва да имаме CA Bundle от SSL провайдера ни. Тъй като аз използвам StartSSL , ето и моя /etc/ssl/private/ca-bunde2.pem.
И не на последно място , започнах да използвам и Diffie-Hellman parameter for DHE ciphersuites, като в моя случай генерирах 4096 битов ключ (генерира се за около 1 час).
Полезен линк за защита на вашият nginx конфиг е този от mozilla, където чрез генератор може да се избират версии, модели и различни уеб сървъри.
И накрая, ето така изглежда nginx виртуалният хост на root.bg вече :
server {
listen 87.97.157.122:80;
server_name root.bg www.root.bg;
return 301 https://root.bg$request_uri;
}
server {
listen 87.97.157.122:443 ssl spdy;
server_name root.bg www.root.bg;
ssl on;
ssl_certificate /etc/nginx/ssl/root.bg.crt;
ssl_certificate_key /etc/nginx/ssl/root.bg.key;
ssl_session_timeout 5m;
ssl_session_cache shared:NginxCache123:50m;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /etc/ssl/private/ca-certs2.pem;
resolver 8.8.8.8;
large_client_header_buffers 8 32k;
gzip_vary on;
etag on;
real_ip_header X-Forwarded-For;
access_log /var/log/nginx/root.bg.access.log rt_cache;
error_log /var/log/nginx/root.bg.error.log;
root /var/www/root.bg/;
gunzip on;
charset utf-8;
gzip_static on;
client_max_body_size 1000m;
client_body_buffer_size 128k;
index index.php;
rewrite ^/([^/]+?)-sitemap([0-9]+)?\.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
include /etc/nginx/firewall_params;
include common/wpfc-rootbg.conf;
include common/wpcommon-rootbg.conf;
include common/locations-rootbg.conf;
add_header X-Cache $upstream_cache_status;
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options "nosniff";
add_header P3P "Can I help you? Contact me via https://root.bg/contacts/, CP=CAO ADMa DEVa IND PHY ONL UNI COM LOC";
}
Дано тази статия Ви бъде полезна в secure-ването на вашият сайт или уеб сървър! 🙂
Началната страница пък показва статиите на тема howto – тук смятам да наблегна много и да пиша все повече и повече howto публикации!
Темплейта отново е от приятелите ми от themify.me! Отново са си свършили перфектно работата, за което много им благодаря! 🙂
Надявам се с всичките тези промени все повече и повече хора да посещават и харесват сайта. Също така смятам и за напред да продължавам да помагам – обещавам!
DNS Split zones може да се използва в много случаи, но в моя го използвам моите 2 офис сървъра да виждат хостовете си локално, вместо всеки един от тях да вижда другия с реалното си айпи.
Ето и пример за това:
root@dobrich:~# hostname
office.dobrich.root.bg
root@dobrich:~# host web
web.dobrich.root.bg has address 192.168.1.20
root@dobrich:~# host web.varna.root.bg
web.varna.root.bg has address 84.84.84.84
root@dobrich:~# host 192.168.1.20
20.1.168.192.in-addr.arpa domain name pointer web.dobrich.root.bg.
root@dobrich:~# host 192.168.2.20
Host 20.2.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
root@dobrich:~# host prodweb
prodweb.dobrich.root.bg is an alias for web.dobrich.root.bg.
web.dobrich.root.bg has address 192.168.1.20
root@varna:~# hostname
varna.root.bg
root@varna:~# host web
web.varna.root.bg has address 192.168.2.20
По този начин от Dobrich виждаме хостовете които отговарят за зоната dobrich.root.bg, а от varna виждаме само хостовете които отговарят за varna.root.bg. Ако от единия искаме да достъпим другия, то го правим вписвайки целия хостнейм (които отговаря на външното айпи)
Така дефакто постигаме така нареченият DNS split zones.
Ето и как дефакто става номера:
Махаме този ред от /etc/bind/named.conf: include “/etc/bind/named.conf.default-zones”;
В сървъра Dobrich нашият /etc/bind/named.conf.local трябва да изглежда така:
acl dobrich {
192.168.1.0/24;
127.0.0.1;
};
acl varna {
84.84.84.84;
};
view "dobrich-view" {
match-clients { jfk; };
// recursion yes;
zone "." IN {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone 1.168.192.in-addr.arpa {
type master;
file "/etc/bind/db.192.168.1";
allow-transfer {
192.168.1.29;
84.84.84.84;
};
};
zone "dobrich.root.bg" {
type master;
file "/etc/bind/dobrich.root.bg";
allow-transfer {
192.168.1.0/24;
84.84.84.84;
};
};
};
view "varna-view" {
match-clients { varna; };
// recursion no;
zone "." IN {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "varna.root.bg" {
type master;
file "/etc/bind/varna.root.bg";
allow-transfer {
192.168.1.0/24;
84.84.84.84;
};
};
zone 2.168.192.in-addr.arpa {
type master;
file "/etc/bind/db.192.168.2";
allow-transfer {
192.168.1.0/24;
84.84.84.84;
};
};
};
include "/etc/bind/rndc.key";
server 192.168.1.0/24 {
keys {
rndc-key;
};
};
В сървъра Varna нашият /etc/bind/named.conf.local трябва да изглежда така:
acl dobrich {
44.44.44.44;
};
acl varna {
192.168.2.0/24;
127.0.0.1;
};
view "dobrich-view" {
match-clients { dobrich; };
// recursion yes;
zone "." IN {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone 1.168.192.in-addr.arpa {
type slave;
file "/etc/bind/db.192.168.1";
masters { 44.44.44.44; };
allow-notify { 44.44.44.44; };
};
zone "dobrich.root.bg" {
type slave;
file "/etc/bind/dobrich.root.bg";
masters { 44.44.44.44; };
allow-notify { 44.44.44.44; };
};
};
view "varna-view" {
match-clients { varna; };
// recursion no;
zone "." IN {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "varna.root.bg" {
type slave;
file "/etc/bind/varna.root.bg";
masters { 44.44.44.44; };
allow-notify { 44.44.44.44; };
};
zone 2.168.192.in-addr.arpa {
type slave;
file "/etc/bind/db.192.168.2";
masters { 44.44.44.44; };
allow-notify { 44.44.44.44; };
};
};
Тук цялата работа върши опцията “acl” като в нея се посочва от кои айпи адреси да се има достъп до коя зона.
В поста съм писал фалшиви публични айпи адреси : 44.44.44.44 и 84.84.84.84 с цел сигурност.
44.44.44.44 = dobrich.root.bg
84.84.84.84 = varna.root.bg