losidar

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

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

Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.

Веб-мастера, плотно работающие с сайтами, не раз сталкивались с ситуациями, когда унифицированные настройки веб-сервера, на котором работает текущий проект, вполне себе устраивают большую часть пользователей сервера, но конкретно проекту веб-мастера подходят не полностью. При этом чаще всего, если проект размещён на shared-хостинге (о видах хостинга я писал ранее), писать в тех. поддержку хостера запрос на изменение нужных настроек не имеет смысла: в таких изменениях, скорее всего, будет отказано. Также не совсем рационально вносить изменения самостоятельно, если используется VDS или Dedicated с несколькими проектами на борту: новые настройки могут сломать старые проекты.

В этом случае на помощь веб-мастеру приходит файл дополнительной децентрализованной настройки веб-сервера. Называется он «.htaccess» (обратите внимание на точку в начале названия файла, её наличие для его корректной работы обязательно).

ВНИМАНИЕ! AHTUNG! WARNING! УВАГА! 注意!

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

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

Вольное определение.

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

Примерная схема работы.

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

Если директива из файла веб-сервером по какой-то причине не распознаётся, то работа веб-сервера с сайтом экстренно прерывается, и веб-сервер возвращает клиенту страницу со статусом 500 - «Внутренняя ошибка сервера» (Internal server error).

Что умеет этот файл?

Очень кратко по самым часто используемым возможностям.

1. Управлять ЧПУ.

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

http://экзампл.рф/index.php?a=view&m=13321&ex=mobile

и сделать её такой:

http://экзампл.рф/mobile/13321/

Пример на рабочем сайте:

2. Разграничение доступа к папкам.

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

#################

AuthName "Resticted area! PIKABU users only!"

AuthType Basic

AuthUserFile /home/u12345/example.ru/pass/.htpasswd

require valid-user

#################

3. Запрет на доступ к определённым файлам и запрет хотлинкинга.

Если, например, сайт генерирует файлы с отчётами или резервные копии и складывает их в какую-то папку, то через htaccess можно запретить доступ к таким файлам, чтобы скачивать их можно было только через FTP-доступ или просаматривать через серверную консоль. Также htacces позволяет запретить так называемый хотлинкинг, когда файлы с вашего сайта (к примеру, картинки) подключаются на страницах другого сайта.

Так запретим хотлинкинг картинок:

#################

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?экзампл.рф [NC]

RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

#################

4. Собственные страницы ошибок.

Стандартные страницы веб-сервера с ошибками (403 — Forbidden, 404 — Not Found и т. д.) просты и лаконичны. Но иногда хочется чуть сложнее и при этом красивее.

5. Перенаправление посетителя на сторонний ресурс, внутреннюю страницу или другой протокол при каких-то особых условиях.

Подключили SSL и нужно заставить всех пользователей ходить на ваш сайт именно по безопасному протоколу? Можно сделать так, что он сам этого не заметит:

#######################################

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

#######################################

6. Переопределение стартовой страницы сайта.

Для любителей назвать индексный файл this_file_starts_my_website_view.php

#######################################

DirectoryIndex this_file_starts_my_website_view.php

#######################################

7. Запрет доступа к всему сайту или определённым его страницам для определённого пользователя (или группы пользователей, объединённых общим признаком). А также разрешение доступа определённому пользователю к определённым областям сайта:

Резюмируя.

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

Файл также умеет:

- заставлять браузер кэшировать содержимое сайта на опеределённое время;

- архивировать передавыемые пользователю данные для сокращения потребляемого трафика;

- управлять роботами различных поисковых систем;

- изменять некоторые настройки используемых языковых интерпретаторов (php, perl, python и т.д.);

И многое-многое-многое-многое другое.

Тема весьма и весьма широкая, поэтому оставлю некоторые полезные ссылки для самостоятельного изучения.  Я постоянно использую их сам, т.к. весь объём этих данных в голове не укладывается.

http://www.htaccess.net.ru/ — про htaccess по-русски и в понятной форме изложения.

http://htaccess.ru/cms/ — стандартные файлы htaccess для некоторых распространённых CMS.

http://www.opennet.ru/base/faq/htaccess_howto.txt.html — для олдфагов.

https://habrahabr.ru/post/154643/ — для профессионалов.

Если про что-то забыл, не ругайте сильно. Есть вопросы? Добро пожаловать в комментарии.

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

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

Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.

Как в большинстве хостингов, панель управления аккаунта у нас позволяет установить на нужный вам домен какое-либо приложение: CMS, галерею изображений, чат или что-то в подобном духе. Но набор приложений довольно ограничен и нужно приложение найдётся не всегда. Также бывает, что даже при наличии в списке нужного приложения, система не даёт выбрать нужную вам версию этого приложения. Тогда остаётся только один вариант: установить такой софт самостоятельно вручную.

Поэтому, очень часто приходится объяснять нашим пользователям, как самостоятельно установить ту или иную CMS на их хостинг-аккаунте на нужный им домен. Для человека неподготовленного процесс может показаться трудным, но поверьте, это одна из самых лёгких задач, с которой вы можете столкнуться в процессе создания собственного сайта.

Ввиду того, что лидирующие позиции на рынке CMS (как платных, так и бесплатных) уже несколько лет подряд занимает CMS WordPress, я расскажу вам, как установить именно её.

Хочу сразу сделать три ремарки:

1. Инструкция будет полезна в первую очередь тем, кто хочет освоить процесс установки CMS, но ни разу этим не занимался. Для более-менее опытных пользователей инструкция будет абсолютно бесполезна и даже скучной, т. к. новой информации вы для себя здесь не найдёте. Это моё вам предупреждение о том, что раскрытия каких-то великих тайн здесь вы не обнаружите.

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

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

Приступим.

1. Первым делом нам понадобится инсталлятор CMS. Скачивать его я рекомендую исключительно с сайтра разработчика. Тем более, что у них уже давно есть русифицированная версия WP.

2. Авторизуемся в панель хостинга и проходим в раздел «Файловый менеджер»

3. Закачиваем архив с инсталлятором на ваш аккаунт, в папку будущего сайта. В панели ISP это делается в два действия:

а) наводим курсор мыши на кнопку "Скачать" в верхнем меню. Из кнопки выпадет дополнительная кнопка "Закачать". Нажимаем на неё:

б) в появившейся форме нажмаем в поле "Локальный файл" и находим на своём компьютере скачанный архив WordPress. Затем нажимаем кнопку "Ok" и дожидаемся загрузки архива.

4. Архив на сервере. Теперь его нужно распаковать. Для этого единожды кликаем по архиву левой кнопкой мыши, затем наводим курсор мыши на кнопку "Копировать" в верхнем меню. Выпадет дополнительное меню, в котором будет кнопка "Извлечь". Нажимаем на неё:

5. В появившейся форме выбираем имя папки, в которую нужно распаковать архив CMS. Обычно имя папки полностью совпадает с именем вашего сайта. Нажмите кнопку "OK"

6. Архив инсталлятора wordpress организован таким образом, что все нужные для инсталляции файлы лежат внутри архива в выделенной папке. В нашем случае это есть некоторое неудобство, т. к. все эти файлы должны находится прямиком в папке будущего сайта, а не во вложенных папках. Поэтому, после успешной распаковки проходим в папку wordpress. Выделяем всё содержимое этой папки, а в верхнем меню нажимаем кнопку "Копировать":

7. В форме копирования выбираем папку, в которую хотим установить CMS (одноимённая домену и сайту), а чуть ниже ставим флаг напротив пункта "Перенести файлы". Нажимаем кнопку "OK":

8. После успешного переноса файлов в прямую директорию сайта, открываем сам сайт в браузере. Установщик CMS покажет вам информационную страницу. Ознакомьтесь с её содержимым и нажмите кнопку "Вперед":

9. На следующей странице инсталлятор попросит ввести данные для подключения к базе данных. Базу данных и её пользователя нужно создать. Это делается в хостинговой панели. Переходим в ней в раздел "Базы данных" и нажимаем кнопку "Создать" в верхнем горизонтальном меню раздела.

10. В форме создания БД заполняем поля, помеченные красной звёздочкой. Обязательно запоминаем или куда-нибудь сохраняем внесённые на этой странице данные, они нам понадобятся. Затем нажимаем кнопку "Ok".

11. Возвращаемся на страницу инсталлятора CMS и заполняем все поля в соответствии с именем созданной только что базы данных, именем её пользователя и его паролем. Эти данные вы только что запомнили, или записали. В поле "Сервер базы данных" вносим "localhost" без кавычек, а поле "Префикс таблиц" оставляем без изменений. Нажимаем кнопку «Отправить» внизу страницы:

12. Если всё было сделано верно, то вы увидите подтверждающую страницу. Нажимаем на ней кнопку "Запустить установку":

13. На следующей странице нужно заполнить некоторые данные о самом сайте, а также об административном пользователе CMS. После чего нажать на кнопку "Установить WordPress":

14. Об успешной установке вам сообщит такая страница:

15. Поздравляю, теперь ваш сайт работает на CMS WordPress. Стартовая страница выглядит примерно так:

Собственно, на этом установка WP завершена. И это самое начало работы с вашим новым сайтом. Два следующих пункта — это начало администрирования сайта.

16. Для управления сайтом, нужно зайти в административную часть сайта. Для этого добавляем в адресной строке вашего браузера к доменному имени адрес админ. части: wp-login.php или wp-admin и нажимаем кнопку "Enter" на клавиатуре. На открывшейся странице вводим логин и пароль, который задавали на шаге 13, и нажимаем кнопку "Войти".

17. Готово. Вы попали в админ. часть вашего сайта под управлением CMS WordPress. Продуктивной работы!

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

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

Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.

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

Но, приступим. Как уже догадались самые внимательные, сегодня поговорим о CMS. Начнём с вольного определения.

CMS (по-буржуйски - «си-эм-эс», в просторечии - «це-[ме||эм]-эска») - Content Managment System - Система Управления Содержимым (контенотом) - это некая программулина, которая помогает (чаще всего помогает, но иногда и наоборот) владельцу сайта в редактировании материалов на сайте, его наполнении, оформлении и т. д. То есть, это специальное программное обеспечение, призванное упростить жизнь владельца сайта, путём автоматизации части процессов, связанных с работой человека на своём сайте.

Немного истории. Лет пятнадцать назад мало кто слышал о софте, который бы помогал создавать и редактировать сайты. БОльшая часть сайтов в то время писалась «на коленке», с использованием простейших текстовых редакторов. Тогда было «круто», если ты знаешь HTML и CSS. Шибко продвинутые пользователи умели писать простенькие скриптики на javascript, которые некоторым образом оживляли сайт. Очень большой крутостью считалось наличие на сайте какой-нибудь «гостевой книги», которую тебе написал «один хакер — близкий знакомый бывшего одноклассника вон того парня с параллельного потока».

Мои глаза! МОИ ГЛАЗА!!!

Но пока ты изучал html и css, чтобы сделать более красивым текст твоей домашней странички, осваивал первые полупрофессиональные графические редакторы, чтобы создать для фона твоего сайта «классную гифку с изображением мерцающего звёздного неба», технологи двигались семимильными шагами. Стали появляться разнообразные оффлайновые конструкторы сайтов, типа FrontPage (линк) от Microsoft или DreamWeaver (линк) от Macromedia. Они позволяли довольно быстро создать сайт средней сложности на своём компьютере в визуальном редакторе, не залезая во все эти премудрости кода. Такие редакторы, кстати, до сих пор существуют на рынке, и порой приходится отвечать на вопросы пользователей нашего хостинга, касающиеся работы в таких редакторах.

Чуть позже стали популяризироваться онлайновые системы управления содержимым (контентом). Те самые CMS — content managment system. В отличие от оффлайновых визуальных сайтовых редакторов, они имеют несколько иной принцип работы: cms должна быть установлена на хостинг, где будет работать, и только потом с её помощью можно создавать сайт. То есть, нужно взять инсталлятор cms, положить его на хостинг-аккаунт, где она будет работать, и выполнить установку. А затем, работая через эту CMS, создавать нужный тебе сайт, наполнять его содержимым и, при необходимости, вносить правки в это содержимое.

Здесь мы подходим к тому моменту, когда каждый, кто хоть раз работал в какой-то CMS, понимал, что она работает не совсем так, как ему хотелось бы. Чего-то в ней чего-то не хватает, или наоборот, есть лишний функционал. Кого-то не устраивал язык, на которой написана нужная ему CMS, кто-то негодовал относительно использования внутри CMS не той СУБД (например postgresql вместо mysql, или наоборот). Поэтому, каждый уважающий себя программист в то время считал за обязанность создать свою собственную CMS. В которой «всё удобно, работает, как надо, и при этом движок использует самый правильный софт».

Из-за этого на текущий момент мы видим большое разнообразие CMS: платные и бесплатные, сложные и очень сложные, с поддержкой разработчиков и без оной. Текуший рыно CMS позволяет выбрать программный продукт на абсолютно на любой вкус. Потом, если не понравилась, выбрать другую. И так до бесконечности. Или написать собственную ;)

Основной функционал, который предлагает CMS — это, собственно, наполнение сайта содержимым и управление этим содержимым. Например: создание и редактирование страниц сайта, управление меню сайта, изменение тем оформления сайта. Таков базовый набор практически любой системы управления.

Как пользоваться CMS? Для начала, её нужно установить. Для этого вам понадобится инсталлятор и место, куда вы будете её ставить.

Скачать инсталлятор CMS можно на сайте её разработчика. Кстати, настоятельно не рекомендую использовать сборку, скачанную не с сайта разработчика, т. к. это может привести к печальным последствиям в виде утери важной информации или внезапной полной потерей контроля над сайтом.

Процесс установки сейчас описывать не буду. Про установку на примере одной из самых популярных CMS будет пост-инструкция с кучей картинок.

После установки нужно зайти в административную часть CMS, и работать с ней из этой админки. Любые ваши работы с сайтом теперь будут происходить отсюда. Оформление и дизайн, меню и страницы, картинки и тексты, статьи и ссылки - всё это создаётся, изменяется, удаляется, восстанавливается из админки CMS.

То есть, работа с CMS всё же предполагает наличие у работника:

- каких-то общих знаний в сайтостроении;

- действующего логина и пароля для пользователя CMS с правами на редактирование материалов сайта;

- постоянного доступа в интернет.

Какую CMS использовать? Если вы задаёте такой вопрос, то мой ответ: никакую. Не сочтите за грубость. Выбор CMS — это сугубо личное дело. Примерно, как с религией. Вся суть вопроса лежит в плоскости удобства использования. Любая система управления имеет свои плюсы и минусы. Какие-то системы крайне удобны в использовании, но при этом обладают скудным функционалом. Какие-то наоборот: при должном уровне оснащения движка системы, использование всего этого оснащения — довольно трудоёмкий для неподготовленного пользователя процесс.

Поэтому выбор CMS я лично всегда оставляю только за пользователем. К сожалению, в этом вопросе нельзя положиться на мнение другого человека. Придётся самостоятельно опробовать много различных вариантов, пока лично для себя не найдёшь идеальный вариант.

Есть какие-то вопросы по теме? Добро пожаловать в комментарии.

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

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

Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.

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

Но, с самого начала. Что такое DDoS-атака? По традиции, вольное определение в условиях моей работы. DDoS — это атака на хостинг-сервер, целью которой является вывод из рабочего состояния какого-либо веб-сайта или сервиса, размещённого на атакуемом сервере.

Аббревиатура DDoS означает Distributed Denial of Service (распределённый отказ в обслуживании). «Распределённый» означает, что атака ведётся с большого числа компьютеров и других устройств, имеющих доступ в Сеть.

Почему я не ограничиваю атакующих только компьютерами? В моей практике были случаи, когда атакующие был определёны, как МФУ, например HP. Это, собственно говоря, уже не вызывает удивления, т. к. почти любое современное устройство имеет собственную ОС, набор протоколов в ней, командную строку и, в общем-то, весь необходимый функционал для управления устройством, как непосредственно с самого устройства, так и удалённо.

Что происходит во время такой атаки? Некоторое количество устройств (от нескольких десятков до нескольких миллионов) с определённой частотой направляет запрос к какому-либо сайту. Какой запрос? Да, в общем-то, любой. Например, если действительно говорить об атаке сайта, устройства запрашивают у этого сайта главную страницу.

Ну и что ж в этом такого страшного? Обращения к сайтам есть всегда. Ничего страшного в самом обращении к сайту нет. Беда кроется в количестве таких обращений. Хорошо настроенный хостинг-сервер, поддерживающий 1500-2000 сайтов, комфортно работает в диапазоне 0-4000 пакетов в секунду. В случае с DdoS эти цифры возрастают в сотни раз, и сервер начинает «тормозить» или «умирает».

Попробую пояснить. Представьте, что сервер — это станция метро. В вестибюле станции есть некоторое количество входов и выходов — это каналы связи нашего сервера с Сетью. В обычном режиме станция обслуживает N-ое количество входящих пассажиров (сетевых пакетов с обращениями к серверу) в секунду. В часы пик количество становится довольно большим, и перед входом на станцию скапливается некоторое количество людей. Примерно такая же ситуация при работе сервера под большой нагрузкой. А теперь представьте, что станция находится рядом со спортивным или концертным комплексом. Когда мероприятие закончилось, на станцию хлынул огромный поток людей. Толпа стоит перед входом, движение очень медленное. Все негодуют и ругают власть.

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

Под ёмкостью атаки подразумевается суммарный объём данных, которые направляют атакующие устройства на атакуемый сервер.

В качестве примера: несколько лет назад, когда я работал в другой хостинг-компании, ёмкость одной из атак составила 50 Гб/с. На тот момент суммарная пропускная способность всех каналов той компании была в 5 раз меньше, то есть выделенный ЦОДом канал связи для всех серверов этого хостера был около 10 Гб/с. Соответственно, всё сервера, стоявшие в том ЦОД стали недоступны из внешней сети.

Работа серверов в обычном режиме (визуализация).

Как проводится такая атака? Очень грубая схема: есть некоторый набор устройств, имеющих доступ в глобальную Сеть. Компьютеры, смартфоны, МФУ, чайники, холодильники и т. д. Они взломаны злоумышленником. Но владельцы этих устройств об этом не знают и, скорее всего, никогда не узнают. Такое устройство в IT-сфере называют «зомби». Группа таких зомбированных устройств называется «бот-нет». Вирус, размещённый на устройстве, никак себя не выдаст, т. к. в противном случае бот-нет потеряет бойца. Как только зомбированное устройство получает инструкции для атаке, оно начинает действовать. Как я уже говорил ранее, например, запрашивать главную страницу атакуемого сайта.

Работа серверов под DdoS-атакой (визуализация)

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

Как защищаться от DdoS? К сожалению, никак. Безусловно, есть сервисы, которые предоставляют защиту от такого рода атак. Но они зачастую не дают каких-то гарантий, и защитить от атак ёмкостью более 1 Тб/с (а сейчас атаки постепенно переходят именно на такой уровень) и 80-100 млн пакетов в секунду уже мало кто сможет. Услуги таких сервисов обычно стоят довольно больших денег и, соответственно, нет большого смысла в защите сайта, размещённого на шаред-хостинге.

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

В завершении хотелось бы обратиться к тем, кто использует любой платный хостинг. Если вдруг ваш сайт перестал работать, а на ваш вопрос «WTF?!» тех. поддержка говорит «Извините за неудобства, нас атакуют», потерпите немного. Поверьте, они делают всё возможное, чтобы как можно быстрее возобновить работу сервера. Это в их же интересах.

И я вас умоляю: не просите «ПРЕДУПРЕЖДАТЬ О ТАКИХ ВЕЩАХ ЗАРАНЕЕ». Это всё равно, что предупреждать вас о том, что вы простудитесь. Рано или поздно такое произойдёт, но в чаще всего предугадать такую ситуацию просто невозможно.

Спасибо, что прочли. Есть вопросы? Жду в комментариях.

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

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

Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.

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

Итак, первый и самый простой способ получить сертификат для своего сайта — купить его. Для этого можно обратиться в любой центр по выпуску сертификатов и заказать сертификат у них, предоставив в процессе заказа информацию, по которой будет проведена проверка. В зависимости от целей и амбиций вы можете выбрать платный сертификат с различными типами проверки данных:

D — сертификаты с проверкой домена. При регистрации такого сертификата производится только проверка доменного имени. Это самый простой в оформлении и дешевый тип SSL сертификатов. Купить такой SSL сертификат может любая организация и любое физическое лицо. При заказе сертификата необходимо указывать "E-mail адрес для подтверждения" в сертифицируемом домене: на этот адрес будет приходить письмо для подтверждения "владения доменом". То есть, если оформляется сертификат на домен pikabu.ru, то серт. центр предоставит выбор из нескольких ящиков, который можно будет указать в проверочных данных, например info@pikabu.ru, admin@pikabu.ru и другие. Указанный адрес должен обязательно существовать, все письма с инструкциями сертификационного центра будут высылаться на этот E-mail. При этом оформление сертификатов на домены, в имени которых содержатся намёки на банк, финансы и прочие подозрения на "фишинг" невозможно. Если нужен сертификат для домена кредитной организации, то оформление такого сертификата только с проверкой организации. Сайт с таким сертификатом будет показывать в адресной строке браузера «зелёный замочек» (у разных браузеров по-разному).

D+O — сертификаты с проверкой домена и организации. В этом случае происходит не только проверка доменного имени, но и принадлежность домена к указанной организации. При посещении сайта защищенного таким сертификатом в адресной строке браузера будет показываться название организации. Перед оформлением необходимо убедиться, что доменное имя было зарегистрировано на организацию, а не на физическое лицо, например, на директора или системного администратора компании. Помимо этого, для некоторых видов сертификатов, необходимо будет заполнить форму с реквизитами организации, для проверки их сертификационным центром.

IDN (Internationalized Domain Names) — поддержка национальных доменов. Поддержка доменов не с латинскими символами. Если у вас домен например в зоне .рф, то такой вид сертификатов — ваш выбор.

EV (Extended Validation) — расширенная проверка. Такие сертификаты получают самое высокое доверие со стороны браузеров. Для этого вида сертификатов проводится полная проверка организации, включая обязательное заполнение форм с данными компании, заверяемых подписью и печатью. Но столь «сложное» оформление даёт самый высокий уровень доверия, чему свидетельствует "зеленая адресная строка" в браузере посетителя сайта, которая говорит о том, что сайт прошёл серьёзную проверку и все данные передаваемые между посетителем и сайтом надёжно защищены.

WildCard — поддержка субдоменов. Wildcard сертификат можно использовать на всех субдоменах (поддоменах) доменного имени. Один такой сертификат будет действителен на доменах www.pikabu.ru, test.pikabu.ru, accounts.pikabu.ru и т.д. без каких либо ограничений на количество субдоменов.

SGC (Server Gated Cryptography) — высокий уровень шифрования. Сертификаты с поддержкой принудительно высокого уровня шифрования обеспечивают максимально высокий уровень шифрования вне зависимости от типов и версий браузеров клиентов. Если пользователь использует старую версию браузера, поддерживающую только 40 или 56 битное шифрование, то при использовании SGC-сертификата соединение все равно будет использовать 128(и более) битное шифрование.

SAN/UCC (United Communications Certificate) — мульти-доменные сертификаты. SAN SSL-сертификаты, так же известные как Единые сертификаты связи (UCC) идеальны для продуктов Microsoft Exchange, а так же для защиты мульти-доменных проектов. Такие сертификаты защищают все описанные в заявке домены, субдомены, локальные имена используя лишь 1 сертификат.

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

Каждый платный сертификат подразумевает наличии страховки. Страховка покрывает финансовые риски посетителя сайта. Например, сертификат гарантирует страховое возмещение в размере $10000. Значит, если на домене установлен такой сертификат, и посетитель сайта домена в результате операций сайте понёс какие-либо финансовые убытки из-за взлома ключа сертификата, то такие убытки будут покрыты сертифкационным центром вплоть до $10000. На практике же лично мне не известно ни одного случая, когда такое возмещение было бы выплачено. И дело не в том, что SSL настолько суровая технология, что взломать ключи, а, следовательно, подсмотреть шифрованный трафик, невозможно. Скорее очень сложно доказать, что это произошло. Даже когда пару лет назад была анонсирована катастрофическая уязвимость в протоколе SSL, которая получила название «HeartBleed», информации о каких-то возмещениях не было.

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

Второй способ получить сертификат чуть более сложный. Его можно сгенерировать самостоятельно. Для его воплощения потребуется как минимум командная строка любой unix-системы, пара часов «курения» интернетов по запросам "Генерируем SSL сертификат самостоятельно", а затем пара несложных команд в командной строке.

В результате будет получен набор файлов, которые в последствии можно использовать для подключения сертификата на домен сайта.

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

Это будет происходить из-за того, что бразуры имеют собственную базу сертификационных центров, сертификатам которых они доверяют. Выпущенный же самостоятельно сертификат так и называется «самоподписанный сертификат». Сертифкационным центром в этом случае выступает компьютер, на котором выпущен сертификат. Соответственно, доверия этому компьютеру у браузера нет. Поэтому бразуер будет выводит сообщение об отсутствии проверки сертификата. Такие сертифткаты лично я рекомендовал бы использовать только для собственных нужд, а в Сети всё-таки пользоваться сертификатами от доверенных серт. центров.

Но что делать, если платить даже 10 северо-американских рублей за сертификат не хочется, но душа требует работать с вашим публичным проектом по зашифрованному каналу? До недавнего времени делать было нечего. Таким образом мы плавно подошли к последнему варианту.

Способ третий. Немного издалека.

Пару лет назад группа интернет-компаний скооперировалась и создала свой собственный лунапарк сертификационный центр, который занимается выпуском бесплатных сертификатов для всех желающих. Центр называется «Let's Encrypt». Каждый выпускаемый ими сертификат проходит проверку типа D, действует в течение 90 дней, а по истечении этого периода может быть бесплатно перевыпущен. Количество перевыпусков не ограничено.

Именно такой сертификат от Let's Encrypt я советую почти всем, кто столкнулся с необходимостью использовать SSL.

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

Не сочтите за рекламу. Проект не получает никакой финансовой выгоды из выпуска таких сертификатов. Группа компаний лишь ратует за безопасный интернет.

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

картинка кнопок Let's Encrypt в панели isp

Перевыпуск производится автоматически, поэтому, однажды выпустив такой сертификат, можно вообще забыть о небезопасном соединении со своим проектом. Останется только перевести сайт домена на работу с безопасным протоколом https.

Небольшой бонус. Какой сертификат мне выбрать для своего проекта? Здесь всё достаточно просто.

Всё зависит от того, для чего именно вам нужен сертификат? Большинству пользователей сейчас подойдёт бесплатный сертификат от Let's Encrypt.

Если вам нужен сертифткат для сайта финаснсового учреждения, то нужно задуматься о платном сертификате с уровнем проверки минимум D+O.

Все остальные сертификаты это:

1. Ваши амбиции - зелёная адресная строка в браузере не более, чем понты

2. Финансовые возможности.

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

Всем спасибо за внимание. Если есть какие-то вопросы - добро пожаловать в комментарии.

P.S.:

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

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

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

Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.

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

Сегодня кратко расскажу про SSL.

По традиции, начнём с вольного определения. SSL (Secure Sockets Layer) – это специальный протокол, используя который, данные от узла к узлу Cети передаются в зашифрованном виде. И работет он так, что расшифровать данные может только их целевой получатель.

И, опять же, по традиции, небольшая ремарка. То, с чем работает современный интернет, в большинстве случаев – это TLS, наследник SSL. Но все по привычке называют его SSL, как полицию до сих пор именуют милицией. По сути своей, функции исполняет те же, но лучше (я надеюсь).

Зачем оно нужно?

Еще на заре массового распространения глобальной сети, умные люди видели её огромный потенциал. То есть, использование интернета не только в целях распространения научных (публичных) знаний, но и в качестве среды для обмена личной информацией, секретными данными и т. д.

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

Яркий пример, который вы самостоятельно можете пронаблюдать — это движение данных от вашего компьютера к какому-либо сайту, например на yandex.ru (не сочтите за рекламу, но, судя по всему, ICMP и UDP на сервере pikabu.ru закрыт, поэтому трассировка до него просто не доходит, а хочется продемонстрировать целостный результат). Сделать это можно при помощи встроенной в любую сетевую ОС утилиты трассировки.

Например, на windows:

Или на unix:

Так вот, на каждом узле этой цепочки данные, которые вы передаёте на удалённый узел, или данные передаваемые вам с удалённого узла, могут быть просмотрены. И наверняка вы не хотели бы, чтобы эта возможность существовала, если речь идёт об интимной переписке с вашей половинкой. А уж про секретные данные какой-нибудь спец. службы и говорить не приходится.

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

Так в феврале 1995-го свет увидел SSL 2.0 (первая его версия так и осталась в бета-тесте и никогда не была опубликована).

Крайняя версия протокола выпущена в 2008-м. А в данный момент (с января 2016) в процессе разработки находится обновление, которое сейчас доступно только в виде черновиков.

Как это работает?

Попробую кратко небольшую вводную.

Есть определённая схема, по которой компьютеры обмениваются информацией через сеть. Для совместимости передачи данных между любыми системами, схема передачи эталонизирована. И имеет название «Модель OSI» Она состоит из нескольких уровней.

В модели есть транспортный уровень. Который отвечает за доставку данных. На текущий момент монопольное положение на этом уровне занял сетевой протокол — TCP/IP. Через который мы все с вами ходим в Сеть. Это основоплагающий протокол, который является стандартным для передачи данных в современных компьютерных сетях. Он также включает в себя около двух сотен других протоколов, в том числе часто используемые протоколы прикладного уровня, такие как HTTP, FTP, SMTP и т. д.

Итак, простым языком, как происходит шифрование данных.

Если вы открываете какой-то сайт, то сервер передаёт по HTTP (прикладной протокол) данные на наш компьютер. Условно, эта передача данных выглядит так:

Данные в этом случае передаются «как есть», то есть любой желающий при возможности сможет перехватить их и увидеть, что именно вы передаёте. Будь то фотографии, текстовые данные, видеопоток. Да вообще, что угодно.

Если же сайт использует SSL, то данные кладутся в специальную коробочку, перемешиваются, а затем передаются вам в этой коробочке. Так получается HTTPS (как http, только лучше):

При этом если передаваемые вам данные будут кем-то как-то перехвачены, этот кто-то не сможет их никак интерпретировать, т. к. видеть он будет мешанину из бинарных данных.

Чуть более сложным языком: как это получается?

Соединение между вашим компьютером и сервером с сайтом производится в несколько этапов:

1. Ваш компьютер (клиент) устанавливает соединение с сервером и запрашивает защищенное подключение.

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

3. Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

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

5. Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:

— Клиент генерирует случайную цифровую последовательность

— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер

— Сервер расшифровывает полученную последовательность при помощи закрытого ключа

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

Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

Для чего это может понадобиться мне лично?

Почти все мы используем социальные сети. Электронную почту. Сайты с авторизацией. Он-лайн магазины, в которых оплачиваем покупки пластиковыми картами.

Теперь представьте, что данные, которые вы вводите в форме на сайте будут передаваться с вашего компьютера на сервер для их последующей обработки в открытом виде. Если кто-то получит доступ к любому из промежуточных узлов передачи данных, то он сможет увидеть эти данные. Например, сотрудники вашего интернет-провайдера имеют доступ к маршутизаторам, через которые ходят данные от вас во внешнюю сеть и обратно. Соответственно, весь ваш траффик у них может быть как на ладони. И если речь о логине и пароле от вконтактика, то, может быть, и невелика потеря. Но если это, например, номер вашей пластиковой карты и её CVV-код? Можно остаться и без кровно заработанных.

Поэтому передача данных в Сети через шифрованные протоколы очень важна и нужна.

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

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