root.bg

31 Oct 2018

Николай Николов Блог blog, english, root.bg 0 comments

root.bg вече и на английски език

Здравейте, От няколко дни в главата ми се върти схема да направя root.bg вече и на английски език.

Благодаря на Славена за идеята която ми даде!

Поради тази причина блога се държи нестабилно от понеделник до сега.

Като за начало ще преведа всички страници и постепенно след това ще преведа и публикациите малко по малко.

Това е!

26 Apr 2016

Николай Николов Howto letsencrypt, monit, nginx, root.bg, ssl 0 comments

Welcome LetsEncrypt

Привет,

Искам да съобщя, че от днес root.bg (и няколко под домейна ) използват валиден сертификат от Let’s Encrypt!! Welcome LetsEncrypt!

Накратко – LetsEncrypt предоставят напълно безплатно възможността, да имаме валиден SSL сертификат.

Инсталацията на letsencrypt става супер лесно :

beta:~# git clone https://github.com/letsencrypt/letsencrypt

beta:~# cd letsencrypt/

beta:~/letsencrypt# ./letsencrypt-auto --help

А след това следва и инсталацията на самите сертификати :

/root/.local/share/letsencrypt/bin/letsencrypt certonly --standalone -w /var/www/root.bg/ -d root.bg -d www.root.bg -d sky.root.bg -d music.root.bg -w /var/www/cdn.root.bg/ -d cdn.root.bg

За целта първо трябва да се спре уеб сървъра, докато трае самото инсталиране на сертификатите ( осъществява се обратна връзка от сървърите на 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

Още..

17 May 2015

Николай Николов Howto nginx, ocsp, root.bg, ssl, startssl 0 comments

nginx SSL security

Здравейте,

Днес ще споделя за един проблем със сайта с който с сблъсках снощи. Когато го разцъквах през 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-ването на вашият сайт или уеб сървър! 🙂

10 May 2015

Николай Николов Блог нов дизайн, howto, root.bg, themify 0 comments

Ново име, нов дизайн – root.bg

Здравейте,

Горд съм да споделя, че блога вече ново име, нов дизайн – root.bg и голямо желание от моя страна да го доразвивам все повече и повече! 🙂

Стария домейн friendbg.net (както nnikolov.net) продължава и ще продължава да работи за напред. Той редиректва към https://root.bg/blog където вече се намира личният ми блог.

Началната страница пък показва статиите на тема howto – тук смятам да наблегна много и да пиша все повече и повече howto публикации!

Темплейта отново е от приятелите ми от themify.me! Отново са си свършили перфектно работата, за което много им благодаря! 🙂

Надявам се с всичките тези промени все повече и повече хора да посещават и харесват сайта. Също така смятам и за напред да продължавам да помагам – обещавам!

Поздрави,

Николай

17 Mar 2014

Николай Николов Howto bind9, dns, root.bg, zone 0 comments

DNS Split zones

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

Това е.. 🙂

Последни коментари

Nikolay Nikolov: Здравей, Като се замисля, на еди�…
Nikolay Kabaivanov: Не се занимавай с преименуване - …
ivalina Nikova: Направихме резервация в хотел Ф�…
Aleksey Orlov: Debian Jessie е страхотна операционна …
Nikolay Nikolov: Тук възникна и лек проблем с лин�…
Nikolay Nikolov: @alkin:disqus , мен ако питаш, по-добре �…