Копытов Иван: заметки с тегом домен

Продление домена

Thu, 04 Apr 2019 10:31:25 +0700

Вчера утром пришло очередное напоминание об окончании срока регистрации домена. И, хотя до него оставалось еще около трех недель, решил не откладывать и продлить срок регистрации.
Для начала зашел на сайт «основного» регистратора, посмотрел цену — 899 рублей. В памяти всплыло, что где-то видел дешевле. Зашел на сайт партнерского регистратора, где первоначально регистрировал домен. И верно, цена в полтора раза ниже — 599 рублей. Деньги лишними не бывают, поэтому будет продлевать тут :-) Выбираю пополнение баланса, в качестве метода пополнения — списание с банковской карты. Подтверждаю пополнение, получаю смс о списании денег. В личном кабинете выбираю продление, деньги списываются со счета, текущий баланс становится равным 1 рублю. Следом падает еще одна смс и письмо на почтовый ящик. Поначалу подумал, что это подтверждение о продлении. Открываю смс, а в ней информация об отказе в приеме платежа и возврате средств. Странно... Открываю письмо — оно от системы Яндекс.Деньги. В письме текст, говорящий что что-то пошло не так, поэтому деньги они мне возвращают. Да ёпрст! Возвращаюсь в личный кабинет — там то же самое, что и в письме от Яндекса. Блjad! Открываю список доменов, а мой продлен до 2020 года. Не понял! Подождал несколько часов, проверил снова — продлен. По подсказке в одном чате смотрю результаты whois — тоже продлен. Хм...
Насколько я понял, деньги поступили на лицевой счет регистратора, я успел оплатить продление, списав деньги со счета в личном кабинете. Затем что-то пошло не так и Яндекс вернул всю сумму, которую я успел перевести. По итогу, домен продлен, денег на это не потрачено. Но для полной уверенности нужно дождаться 23 апреля и посмотреть не изменится ли ситуация.

Перенос домена

Fri, 28 Apr 2017 15:17:34 +0700

Никогда не задавался такой целью, да и необходимости такой никогда не было. В процессе оплаты одного из сайтов СТМ выяснилось, что домен зарегистрирован у одного регистратора, а сам хостинг располагается у другого. Картина достаточно «печальная». Почитав правила, стало понятно, что без заявления, заверенного у нотариуса, перенос никто делать не будет. Так как владельцем домена является генеральный директор, то понятно, что времени у нее на посещение нотариуса нет. Печаль...
Вбиваем в поиск запрос на перенос домена от этого регистратора. И тут же натыкаемся на информацию о том, что никакие заявления уже не нужны. Идем в личный кабинет, выполняем все действия по инструкции. Тут меня ждал первый облом — для получения кода переноса требуется верифицировать персональные данные. Подаю заявку, мне отвечают «ждите сутки». Да не вопрос, подожду!
На следующий день приходит письмо, что аккаунт проверен, можно продолжать. Снова иду в личный кабинет, запрашиваю код. Второй облом — необходимо внести данные для смены регистратора. Указанные в профиле данные не годятся. Ладно, забиваю свой номер телефона и email. Подтверждаю оба, снова запрашиваю код. Среди прочих вариантов выбираю отправить его на электронную почту. Третий облом — состояние домена не позволяет получить код. Эт еще почему? Повторяю процедуру запроса, на этот раз все получается. Видимо, еще выполнялось сохранение данных для переноса. С кодом в зубах, а точней, в письме, иду в личный кабинет регистратора, к которому нужно перенести домен. Уже понимая, что сам не найду, сразу открываю справку, где процедура переноса, как оказалось, расписана очень подробно и даже с картинками (вот за это я его тоже люблю! в смысле регистратора). Снова действуем по инструкции, вбиваем код переноса и выполняем еще парочку подтверждений. В конце получаю письмо с уведомлением, что процесс переноса может занять до 5-ти рабочих дней. А мне что? Мне торопиться некуда.
В общем, вот такой вот маленький квест получился. Перенос домена от одного регистратора к другому — процедура хоть и простая, но в процессе у вас запрашивается куча подтверждений. Ну и, конечно, лучше всего 100 раз проверить что, куда и откуда. А то ведь бывало, что щелкнешь не туда, нажмешь не ту кнопочку и все, ты попал. Хорошо еще, если на небольшую сумму :-)

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

Tue, 16 Aug 2016 22:24:24 +0700

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

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

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

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

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

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

— получаем сертификат на сайте 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) на свой сайт

Tue, 16 Aug 2016 11:56:05 +0700

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

«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-сервера.»

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

Наличие валидного сертификата (можно бесплатно получить на сайте Let’s Encrypt)
Уверенность в том, что будет использоваться только https протокол, включая все ваши субдомены.
Полное перенаправление с 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» фон страницы станет красным, в случае некритической — желтым, если же все верно — зеленым. На этой же странице указано, что нужно делать, чтобы удалить свой домен из этого списка.

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