Заметки любителя экспериментов

Позднее Ctrl + ↑

Реклама и AdBlock

Гениально, я считаю, жаль, что не каждый поймет: «нет смысла объяснять про adblock людям, которые каждый вечер по уши в телевизоре с рекламой каждые 20 минут»

Анонимайзеры и Content Security Policy

Продолжая мучить свой сервер, наткнулся на такой интересный «казус», который, впрочем, после некоторого размышления, стал вполне логичным.

Так как ранее была настроена связка nginx+Apache, но тогда я не стал настраивать модуль rpaf, который выдает «нормальный» адрес сервера в логах, а настроил только сейчас, то, конечно, пришлось его сразу тестировать. Для этого зашел на сайт HideMe, вбил адрес страницы, которая должна была показать мне адрес сервера, с которого я зашел (если модуль был настроен неправильно, то я увидел бы, скорее всего, адрес 127.0.0.1) и увидел... что стили оформления на сайте не работают. Это следствие использования CSP на моем сервере. Можно сказать, что это достаточно неприятно, но, если подумать, то мой сайт нигде не блокируется и никак не прячется, поэтому использовать анонимайзер при его посещении нет никакого смысла. Разве что только в том случае, если на каком-то предприятии по внутренним правилам запрещено посещать сайты и работникам не остается ничего, кроме как использовать анонимайзеры. Что, впрочем, крайне маловероятно :-)

Связка nginx+Apache

Немного почитав про эту связку, пришел к выводу, что стоит попробовать ее использовать. Установил nginx, перенастроил Apache таким образом, чтобы он работал только локально, затем настроил nginx таким образом, чтобы он все запросы отдавал Apache. Потом еще некоторое время пришлось повозиться с настройками nginx, но вуаля! Я добился-таки того, что все сайты, на которых я проводил тестирование своего сервера, выдали мне оценку «А+». Итак, что из «плюсов» мы имеем:

  • — возросла скорость загрузки сайта;
  • — уменьшилась нагрузка на Apache;
  • — статические данные теперь отдает nginx, динамические — формирует Apache;
  • — остались все «плюшки» .htaccess;
  • — возросла безопасность сервера.

Из «минусов»:

  • — теперь на сервере у меня два веб-сервера.

Чуть позже попробую конфигурацию с «голым» nginx, если его работа меня устроит, то, скорее всего, полностью перейду на него. Теперь что касается безопасности сервера (ну да, у меня маленький бзик на этот счет).

В связи с тем, что nginx, в отличие от Apache, поддерживает наборы шифрования ECDHE, появилась возможность их использовать. Также он поддерживает OCSP stapling, что позволяет немного ускорить загрузку страниц при работе через HTTPS.

Тестирование проводилось при помощи трех сайтов: SSL Analyzer от Comodo, Free SSL Server Test от High-Tech Bridge, ну и конечно незабвенный SSL Server Test от лаборатории Qualys SSL.

Первый ресурс позволяет провести быстрый тест наборов шифров и некоторых других параметров, он является самым быстрым из этих трех серверов. Удовлетворить его требования оказалось самым простым.

Затем тест проводился при помощи High-Tech Bridge. По скорость он является более медленным, но проверяет чуть больше параметров. В том числе на соответствие требованиям NIST (американский институт стандартов и технологий) и стандарта PCI DSS. Здесь пришлось немного попотеть, разыскивая наборы шифрования, которые, по его мнению, должны быть включены в список.

И под конец проверка шла при помощи Qualys SSL. Он является самым медленным из указанного списка, но выдает результаты практически по всем параметрам. Здесь пришлось поработать над несколькими пунктами, но и тут была одержана победа.

Если какие-то условия не удовлетворяли хотя бы один сайт, параметры редактировались и проверка начиналась заново. В итоге, все требования соблюдены:

  • — сервер работает только по протоколу TLS;
  • — слабые шифры удалены из списка;
  • — Perfect Forward Secrecy (PFS) работает со всеми более-менее новыми браузерами;
  • — поддерживаются HSTS и HPKP;
  • — поддерживается OCSP stapling;
  • — работает Content Security Policy;
  • — работает вся ранее настроенная в Apache защита от атак.

В общем все круто и я всем доволен :-) Кроме, разве что того момента, что теперь в этом плане мне делать нечего и скоро я опять начну скучать.

Повышение безопасности сервера при помощи заголовков

Для увеличения степени безопасности сервера понадобится добавить или удалить несколько заголовков, которые он отдает при запросе страниц. Я не буду подробно расписывать какой из них за что отвечает, ограничусь лишь кратким описанием.

  1. HTTP Strict Transport Security (HSTS) — позволяет форсировать HTTPS подключение.
  2. HTTP Public Key Pinning (HPKP)  — позволяет создать своеобразную «электронную подпись» для вашего сайта.
  3. X-Download-Options со значением «noopen» позволяет запретить открытие любых файлов с вашего сайта (например, документов в формате PDF), становится возможно только скачать их.
  4. X-Content-Type-Options со значением «nosniff» инструктирует Internet Explorer версии 8 не определять автоматически content-type, а использовать уже полученный.
  5. Еще один заголовок X-XSS-Protection со значением «1; mode=block» активирует встроенную защиту от XSS (Cross-Site Scripting, «межсайтовый скриптинг»).
  6. X-Frame-Options со значением «SAMEORIGIN» запрещает открывать страницы вашего сайта во фрейме на чужом сайте.
  7. Заголовок Set-Cookie должен указываться с параметрами HttpOnly и Secure. Это предотвратит XSS-атаки и защитит cookie от кражи при помощи скрипта javascript.
  8. В заголовке Server также должна быть указана минимальная информация о сервере. Например, просто Apache. Это не даст злоумышленнику получить дополнительную информацию о программном обеспечении, установленном на вашем сервере.
  9. По аналогичным причинам рекомендуется убрать заголовок X-Powered-By, если таковой присутствует.

И, как обычно, есть ресурсы, с помощью которых можно проверить насколько корректно вы указали эти заголовки. Первый из них — securityheaders.io, работает очень быстро, корректно указанные по его мнению заголовки выделяются зеленым цветом. Некоторые он не выделяет, но, думаю, что на них он просто не обращает внимание.

Второй ресурс — Redbot. В левой части страницы он показывает заголовки, которые он смог получить. В правой вкратце описывается действие заголовка, также значками выделяется корректность их указания. Стадия их получения почему-то немного затянута, на мой взгляд — около 1 минуты, будем надеяться, что это будет исправлено. Также есть возможность включить в запрос дополнительные параметры.

Если вы думаете, что я что-то пропустил, то пишите в комментариях.

Добавление в список HSTS Preloading

Как это ни странно, но время ожидания добавления в список HSTS Preloading после подачи заявки составило всего около 2-х недель. Возможно, что в Chrome добавление произошло и раньше, но я только вчера утром обновил Firefox на своем компьютере и чуть позже, в ходе внесения изменений в файл .htaccess, можно сказать случайно, запустил проверку на сайте ssllabs. Итогом стало то, что я заметил загоревшийся зеленым цветом Chrome в пункте HSTS Preloading. Порадовался этому факту и немного огорчился, что только один браузер включил меня в этот список. Психологически приготовился ждать еще какое-то время пока остальные тоже обновят его, но этот процесс особо не затянулся. Буквально через несколько часов я наблюдал картину, где все браузеры, кроме Tor, светились зеленым. Ну Tor меня особо никогда не интересовал — ну не верю я в его «неотслеживаемость» и прочие фишки, поэтому было некритично. Сегодня утром картина немного изменилась — информация по Tor стала недоступной. На текущий момент ситуация выглядит следующим образом:

Также наконец-то создал более-менее правильную политику Content Security Policy (CSP), которая позволила моему блогу нормально функционировать. Ранее проблема в ее включении заключалась в том, что картинки из сообщений просто исчезали, при этом я не получал никаких сообщений в Firebug. Также иногда сбивалась тема и переставали работать скрипты. Но, вроде как, разобрался и сейчас все функционирует нормально. Прогнал тестами через один из сервисов и был приятно удивлен, когда он выставил мне высшую оценку по безопасности, найдя все те технологии, которые я внедрил на свой сервер. Кстати, интерфейс у этого сервиса сильно напоминает ssllabs. Про него расскажу чуть позже.

Защита сайта при помощи HTTP Public Key Pinning (HPKP)

Данная технология призвана защитить посетителя вашего сайта от атаки типа MITM (Man in the middle, человек посередине). Иными словами посетитель может быть уверен, что данные, которые он получает, исходят с вашего сайта, а не с какого-то другого.

Суть технологии состоит в создании публичного ключа на основе сертификата, который установлен на вашем сайте. Соответственно, чтобы она работала, требуется валидный сертификат. Впрочем, она будет работать и на самоподписанных (self-signed) сертификатах. Полученный на основе вашего сертификата ключ добавляется в заголовок ответа вашего сервера, после чего браузер сравнивает полученный ключ с тем, который он вычисляет после получения данных о вашем сертификате.

Итак, что нам требуется:

  1. Какой-либо установленный для сайта сертификат.
  2. Консоль для получения публичного ключа.

Кстати, не так давно для нормального функционирования этой технологии требовался всего лишь один ключ, сейчас же нужно указывать два или более ключей. На мой взгляд двух будет достаточно, от этого и будем отталкиваться. Второй ключ является «резервным», этот момент я не совсем понимаю, но не будем отступать от требований.

Действовал я по следующей схеме:

  • — получаем сертификат на сайте Let’s Encrypt для двух сайтов: example.com и www.example.com;
  • — так как я использую вариант без www, то ключ, полученный на базе первого будет основным, на базе второго — резервным;
  • — генерируем ключи для обоих сертификатов;
  • — добавляем нужные инструкции в файл /etc/httpd2/conf/sites-available/default-http.conf.

О получении сертификата рассказывать не буду, достаточно почитать главную страницу сайта. Допустим, вы его получили и установили на свой сайт. Теперь требуется создать ключи при помощи следующей команды:

openssl x509 -noout -in certificate.pem -pubkey | openssl rsa -pubin -outform der | \
openssl dgst -sha256 -binary | base64

где certificate.pem — полный путь к сертфикату.

После выполнения команды вы получите нечто подобное:

LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=

Это и есть нужный вам ключ. Повторяем команду для второго сертификата и добавляем данные в файл конфигурации сайта:

Header set Public-Key-Pins "pin-sha256=\"pin1\"; pin-sha256=\"pin2\"; max-age=time"

где:

  • pin1 — основной ключ для данного сайта. В моем случае example.com;
  • pin2 — резервный ключ для сайта. То есть www.example.com;
  • time — время действия ключа в секундах.

Опциональный параметр includeSubDomains указывает на то, что ключи действительны также для поддоменов. Еще один необязательный параметр report-uri указывает на адрес, куда должны отправляться отчеты об ошибках в формате JSON. Его я, возможно, добавлю на сайт, но пока что считаю его ненужным для себя.

Какие тут есть нюансы? Если вы неправильно настроите HPKP, ваш сайт станет недоступен. Можно также настроить отправку отчетов в случае каких-либо ошибок. Для этого немного меняем заголовок (или просто добавляем еще одной строкой):

Header set Public-Key-Pins-Report-Only "pin-sha256=\"pin1\"; pin-sha256=\"pin2\"; max-age=time"

Внедрение HTTP Strict Transport Security (HSTS) на свой сайт

Сначала небольшая выдержка из википедии:

«HSTS (сокр. от англ. HTTP Strict Transport Security) — механизм, активирующий форсированное защищённое соединение через протокол HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP-протокола. Механизм использует особый заголовок Strict-Transport-Security для принудительного использования браузером протокола HTTPS даже в случае перехода по ссылкам с явным указанием протокола HTTP. Механизм специфицирован в RFC6797 в ноябре 2012 года.

HSTS помогает предотвратить часть атак, направленных на перехват соединения между пользователем и веб-сайтом, в частности атаку с понижением степени защиты и воровство кук.

Дополнительную защиту https-соединений предоставляют методы Certificate pinning (хранение списка разрешенных для домена сертификатов или CA в исходных текстах браузера) и HTTP Public Key Pinning (англ.). Они предотвращают множество возможностей подмены tls-сертификатов https-сервера.»

Для внедрения этой технологии нам понадобится несколько вещей:

  1. Наличие валидного сертификата (можно бесплатно получить на сайте Let’s Encrypt)
  2. Уверенность в том, что будет использоваться только https протокол, включая все ваши субдомены.
  3. Полное перенаправление с http-версий сайтов на https.

Если что-то из этого по каким-то причинам вам не подходит, то эта технология вам не нужна.

Так как у меня используется «старенький» Apache версии 2.2, то и настраивать, соответственно, мы будет его. Для включения HSTS нам нужно добавить в файл /etc/httpd2/conf/sites-available/default_https.conf следующие строки:

<IfModule ssl_module>
    <VirtualHost *:443>
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
   </VirtualHost>
</IfModule>

Первые и последние две строки — стандартные для данного файла, если они имеются, то добавлять их не нужно. Нас больше всего интересует третья строчка.

Инструкция Header set позволяет вставить заголовок в ответ сервера. В данном случае заголовок «Strict-Transport-Security». В скобках за ним расположены параметры этого заголовка:

  • max-age — время в секундах, которое будет действовать этот заголовок. Если быть точнее, то это время, в течение которого сайт будет доступен по протоколу HTTPS. Не рекомендуется устанавливать его менее 18 недель;
  • includeSubDomains — указывается, если действие заголовка распространяется также на поддомены. Не является обязательным;
  • preload — параметр, позволяющий указывать, что ваш сайт никогда не будет доступен по незащищенному протоколу. Не является обязательным. Про него будет чуть ниже.

Итак, данные мы добавили, теперь нужно перезагрузить файлы конфигурации:

# service httpd2 condreload

Наличие заголовка в ответе сервера можно проверить, например, на этом сайте. Среди прочих вы должны увидеть такую строчку:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Идем на сайт ssllabs, вводим адрес своего сайта с указанием https и тестируем, что у нас получилось. Тест занимает некоторое время, его вполне хватит на то, чтобы, например, налить себе чашечку кофе.

По итогу мы должны увидеть такие строчки:

Эту вы увидите в шапке отчета
Эту строчку вы увидите в шапке отчета
Эта будет находиться ближе к концу отчета
Эта будет находиться ближе к концу отчета

Если вы их видите, значит все в порядке. В противном случае ищите ошибку.

И, наконец, про параметр preload. Существует так называемый «preload list», в котором перечислены все домены, использующие технологию HSTS. Своего рода список «избранных» :-) При желании вы можете подать заявку на включение вашего домена в этот список, но на скорый ответ не рассчитывайте. Список обновляется с выпуском каждой версии браузера Chrome, поэтому может пройти несколько месяцев, прежде, чем вы увидите, что ваш домен добавлен в него. Для подачи заявки нужно выполнить несколько требований, указанных на главной странице сайта, поэтому рекомендую прочитать ее внимательно. Значение имеет даже регистр параметров заголовка. В случае критической ошибки после нажатия на кнопку «Check status and eligibility» фон страницы станет красным, в случае некритической — желтым, если же все верно — зеленым. На этой же странице указано, что нужно делать, чтобы удалить свой домен из этого списка.

В принципе, это все, что вам нужно знать об этой технологии защиты вашего сайта. Надеюсь, что этот текст вам помог.

Выбор CMS для блога

После обрушения своего предыдущего блога на Wordpress было принято решение сменить движок. Wordpress был достаточно громоздким, установка любого из плагинов, даже ориентированных на ускорение работы сайта, еще больше нагружали и замедляли его. Хотелось чего-то попроще, побыстрее. И заодно совсем разделить поддомены своего сайта.

Из требований, предъявляемых мной к CMS:

  • — блог;
  • — фотогалерея (не обязательно);
  • — статические страницы;
  • — наличие бесплатной версии CMS;
  • — наличие хоть какие-то плагинов. либо, при их отсутствии, достаточный встроенный функционал CMS;
  • — наличие хоть каких-то тем оформления (шаблонов) — для выбора и установки, либо как пример для создания своей темы;
  • — предпочтительно использование bootstrap;
  • — достаточно высокая скорость работы сайта в целом.

Требования достаточно широки, но CMS, удовлетворяющих им, все равно маловато. Ниже приведу какие CMS я посмотрел, попробовал и что мне не понравилось в них. Он не полон, некоторые все равно не попали в список. Видимо, они мне вообще не приглянулись :-)

Alto CMS

  • — мало готовых шаблонов оформления; только один в bootstrap; только 4 бесплатных;
  • — мало плагинов;
  • — невысокая скорость работы по результатам gtmetrix;
  • — установка не производилась.

Cogear

  • — оффсайт закрыт;
  • — невозможно найти дистрибутив и модули;
  • — блого-социальная сеть.

Contao

  • — нет бесплатных тем оформления;
  • — большое количество расширений;
  • — высокая скорость работы;
  • — установка не производилась.

Cotonti

  • — неплохое оформление;
  • — нет русского языка;
  • — установка не производилась.

DataLifeEngine

  • — платная, более 3000 рублей;
  • — неплохо оформление;
  • — нет информации о каких-либо дополнениях или шаблонах;
  • — не устанавливалась.

Drupal

  • — большое количество дополнений и шаблонов;
  • — неудобная админка.

ImageCMS Corporate

  • — нет бесплатных шаблонов.

Host CMS

  • — ориентированность на интернет-магазин.

MaxSite CMS

  • — непонятно пока что там с плагинами и шаблонами;
  • — пробовал, не сильно понравилась.

MosquitoBloodyMary

  • — движок, основанный на файлах;
  • — мало что умеет;
  • — нет шаблонов.

ReloadCMS

  • — мало плагинов и шаблонов.

Nibbleblog

  • — мало функционала для блога;
  • — возможность создать свою тему;
  • — вроде неплохая документация.

Эгея

  • — почти нет функционала, кроме блога;
  • — неудобное форматирование текста;
  • — убрали боковые колонки.

Micron

  • — очень минималистичный блог;
  • — небольшое количество функций;
  • — поддержка Bootstrap;
  • — почти вся модернизация только через редактирование файлов движка, очень неудобно!
  • — нет админки.

Movable Type

  • — платная.

UMI.CMS

  • — платная.

GetSimple CMS

  • — не нравится;
  • — мало бесплатных тем.

LiveStreet CMS

  • — очень низкая скорость сайта (проверить!);
  • — социальная сеть.

AmiroCMS

  • — в бесплатной версии доступны только два любых модуля одновременно.

DIAFAN.CMS

  • — интернет-магазин.

e107

  • — bootstrap движок;
  • — статическая заглавная страница, новости, галерея, файлы;
  • — неплохая админка, но немного перегружена;
  • — вроде как есть плагин для блогов, но скачать пока не удалось.

b2evolution

  • — всего три модуля, внешне очень схожих: блог, фотогалерея, страницы;
  • — это же и является «минусом».

SysBox

  • — админка работает только в Internet Explorer.

TextPattern

  • — чудовищная админка.

Concrete5

  • — выдает ошибку при установке на этапе заполнения БД.

SilverStripe

  • — при попытке установки модуля блога перестала работать.

Status-X

  • — не нравится мне такой дизайн.

ScriptoCMS

  • — ошибки при установке;
  • — достаточно подозрительные настройки php в .htaccess.

Chyrp

  • — не понравился дизайн от слова «вообще».

По итогу я остановился пока что все-таки на «Эгее». Очень простой дизайн, возможность создания своей темы оформления (в том числе и на bootstrap) и т. д. и т. п. Очень, правда, опечалил тот момент, что пока я занимался подбором CMS для своего блога, автор «Эгеи» выпустил новую версию, в которой были убраны боковые колонки, в которые у меня было что выводить. Остались только заголовок и подвал.

Anchor CMS

Попробовал поставить Anchor CMS. Сразу после установки нашлось несколько «минусов», которые последовательно, по мере обнаружения, начали снижать мою оценку о ней.

На этапе установки предлагается выбрать язык. Доступен только английский. Он же становится языком по умолчанию для всего сайта. Переводов на другие языки просто нет. Если вы хотите установить, например, русский, вам нужно делать это еще на этапе установки, потому что часть слов располагается в базе данных и простым переводом файлов в каталоге language темы не обойтись.

Хорошо, вы осуществили перевод уже после установки CMS, как в файлах, так и в базе, но сайт все равно остается на английском языке. В админке нет возможности переключать язык, это нужно сделать вручную, указав в файле конфигурации «ru_RU». Только тогда русский язык будет использоваться на сайте. Но даже и после этого не все хорошо. Админка начинает «плыть» в плане оформления: кнопки, текст переносятся на другую строку, что нарушает эстетичность оформления. Тут можно сделать выбор: или корректный перевод или придется сильно сокращать слова в переводе. Я лично предпочитаю первый вариант.

После написания первого же сообщения (на самом деле, второго, но не суть важно) выявился еще один «минус». Несмотря на то, что в переводе есть такой текст «Просто пишите» (имеется в виду посты блога), оформление на главной странице в итоге «хромает». Например, нет разделения на абзацы, которые есть в сообщении, которое вы набрали. Такие вещи как жирный текст, наклонный и т. п. даже не стал проверять.

В правом верхнем углу главной страницы есть кнопка меню, после нажатия на которую в верху страницы открывается просто огромный блок с поиском и выбором по категориям. Если честно, то мне даже страшно стало после того, как я представил себе как все это будет выглядеть, если категорий сообщений будет достаточно много. Этот блок тогда займет всю страницу или даже больше. Неужели нельзя было сделать это либо выпадающим списком, либо вынести в боковую колонку.

В общем и целом, мнение об этой CMS сложилось достаточно отрицательное, она все еще «сырая.»

 59   2016   запись   первая   тест