Nikita

/**
 * Случайная выборка с учетом веса каждого элемента.
 * @param array $data Массив, в котором ищется случайный элемент
 * @param string $column Параметр массива, содержащий «вес» вероятности
 * @return int Индекс найденного элемента в массиве $data 
 */
function getRandomIndex($data, $column = 'ver') {
  $rand = mt_rand(1, array_sum(array_column($data, $column)));
  $cur = $prev = 0;
  for ($i = 0, $count = count($data); $i < $count; ++$i) {
    $prev += $i != 0 ? $data[$i-1][$column] : 0;
    $cur += $data[$i][$column];
    if ($rand > $prev && $rand <= $cur) {
      return $i;
    }
  }
  return -1;
}

// Использование
$games = [
	['name' => 'Игра 1', 'ver' => 2], // вероятность 2/15
	['name' => 'Игра 2', 'ver' => 0], // вероятность 0/15
	['name' => 'Игра 3', 'ver' => 1], // вероятность 1/15
	['name' => 'Игра 4', 'ver' => 4], // вероятность 4/15
	['name' => 'Игра 5', 'ver' => 8], // вероятность 8/15
];
$i = getRandomIndex($games);
echo $games[$i]['name'];

В параметре массива «ver» задается вероятность выпадения данного элемента таким образом, что вероятность выпадения каждого элемента равна ver/sum, где sum — сумма вероятностей в данном массиве (в примере это: 2 + 0 + 1 + 4 + 8 = 15).

После миллиона испытаний получено следующее количество выпадений:

• Игра 1 = 13.3958%
  
• Игра 2 = 0%
  
• Игра 3 = 6.671%
  
• Игра 4 = 26.6124%
  
• Игра 5 = 53.3208%
  

Что до сотой доли процента совпадает с заданной вероятностью в параметре «ver».

P. S. Суть алгоритма — имитация случайной выборки из массива, который заполнен элементами, которые дублируются с заданной частотой.

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

В общем случае разница во всех этих сервисах в том, на каком уровне TCP/IP они работают. Отсюда вытекает, что они могут и что позволяют.

1. Openvpn - работает на уровне L2 и L3, создает новое сетевое соединение, влияет на всю систему, можно пропустить весь трафик, нужны рутовые права.
   
2. Stunnel - работает на L4, L5. Это SSL, только для вполне указанных сервисов. Рутовых прав не требует, работает с конкретными портами и протоколами, можно подключаться через проксю.
   
3. IPSec - в принципе, как openvpn, только на L3. Чуть тяжелее в конфигурировании, зато более универсален. Можно подключаться с сетевых железок. А вообще, IPSec - целый фрейворк для конфигурирования различных шифрованных соединений
   
4. SSH в режиме туннеля - тот же самый openvpn, который не надо настраивать. Он использует те же самые алгоритмы, библиотеки и функции, что и openvpn. Рутовые права, создание новых интерфейсов при этом никто не отменял. Я бы сказал - разовое мероприятие.
   
5. SSH в режиме прокси - в принципе, аналог Stunnel. Также прикладной уровень, также SSL, также не нужно рутовых прав, также работает через проксю. Ну и нужно каждый раз заново запускать, тоже разовое мероприятие
   

В общем одни решения - SSL, другие - VPN. Через SSL общается конкретное приложение с другим конкретным. Через VPN могут общаться целые сети по любым протоколам.

Если интересно, вот здесь более детальное описание, правда на буржуйском.

Это SPA на React с server side rendering. Приложение рендерится и получает данные на стороне сервера. При переключении поста, срабатывает роутер, рендерится нужный пост, а из интернета подтягиваются только картинки. Скорость node тут не причем. Такие SPA принято называть изоморфными.

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).

Часть первая, добрая

1. Идете к юристу и оформляете правильную лицензию, в которой вы предоставляете право на использование вашего продукта. Жестко запретите модификацию кода CMS всеми, кроме вас. Оставьте за собой право модификации кода удаленно, в любое время без предварительных уведомлений. Оставьте за собой право отзыва или изменения лицензий без уведомлений и объяснений. Запретите перепродажу. В лицензии добавьте оговорку насчет статьи 273, что действия по модификации кода сайта являются санкционированными и неотъемлемой частью продукта.
2. Реализуете и обкатываете механизм автоматического лицензирования через интернет. Вешаете лицензионное соглашение на официальный сайт продукта.
3. Рассылаете всем нелицензионным пользователям "письмо счастья", в котором доходчиво объясняете, что их копия не лицензирована и т.д. Рекомендую вам разрешить использование своей CMS для некоммерческих организаций и домашних страничек без рекламы при наличии ссылки на сайт продукта. Предложите бесплатное обновление для некоммерческих пользователей.

Часть вторая, злая

1. После введения новой лицензии, но до уведомления всех письмами счастья, удаленно зашиваете код, который будет выводить html-комментарий о том, что данная копия не имеет лицензии т.д. и т.п. Там же должна быть ссылка на ваш сайт, где можно лицензировать продукт. Данный шаг не будет препятствовать работе с сайтом.
2. Рассылаете письма счастья.
3. Ждете, пока пройдет срок, в течение которого компании должны лицензировать свои версии.
4. Вместе с юристом выбираете компанию, на которую вы подадите в суд за нелицензионное использование своей CMS и у которой точно выиграете дело. Судитесь. Выигрываете. Далее на сайте проекта вешаете официальную информацию о судебном разбирательстве и решении в пользу истца. Делаете огласку истории, публикуете ее на всяких Спарках/Хабрах/Цукербергах и прочих ресурсах.
5. Через месяцок рассылаете новые письма счастья с уведомлением о том, что бывает с теми, кто отказался. Ссылку на результаты разбирательства приводите.
Плюс, можете вывесить список сайтов у себя, где нелегально используется ваша CMS.

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

Часть третья, плохая

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

Фреймворки, библиотеки и плагины для верстки сайта.

1. Bootstrap - самый популярный HTML, CSS, и JS фреймворк в мире для разработки отзывчивых, mobile-first проектов в вебе.

2. slick - Адаптивный слайдер для сайта

3. Owl Carousel 2 - красивый, отзывчивый карусельный слайдер

4. Fotorama - плагин для создания галереи на сайте

5. MagnificPopup - плагин для создания модальных окон

6. FancyBox - построениe всплывающих окон

7. Mmenu - мобильное меню


8. bxSlider - отзывчивый jQuery-слайдер для контента


9. Fullscreen Slit Slider - слайдер с интересной анимацией

10. parallax.js - эффект Parallax

Первая 10-ка

Поскольку резолвинг DNS происходит корректно, промышленно готовых вариантов остаётся три:

1. Провайдерский DPI: наверняка он уже есть у всех провайдеров в том или ином виде.
Логически DPI обычно включается в разрыв линка между ядром и NAT.
Физически зачастую тоже.
Кроме обычных шейпинга и подсчёта трафика per-subscriber, там реализован набор ALG (Application Layer Gateway), которые представляют из себя, фактически, прозрачные прокси для типичных протоколов: HTTP, FTP, DNS и т.д.
Как правило, ALG умеют не только реагировать на определённые значения полей, но и вмешиваться в процесс передачи данных.
Количество ALG зависит от навороченности DPI; в Procera даже World of Warcraft есть )
Ну а уж подмена HTTP-страницы - пожалуй, самая используемая функция HTTP ALG.

2. Наколенное решение раз:
Описано у none7
Завести у себя в сети сервер с ip-адресами, совпадающими с Ip-адресами Вконтакта (ну, или NAT'ить все запросы к нему на сервер-заглушку, что примерно то же самое) - вполне себе решение, если надо заблокировать сервис целиком, а не отдельные страницы на нём.
Но если вдруг ваши политики наберутся дурости у наших, и список блокируемых ресурсов начнёт расти, провайдеры взвоют этот вариант поддерживать )

3. Наколенное решение два:
На самом деле, в России есть свой список блокируемых ресурсов (т.н. список Роскомнадзора) с сотнями тысяч URL.

Выяснилось, что таким количеством записей множество провайдерских DPI попросту давится, поэтому эта задача зачастую решается следующим образом: заводятся отдельные серверы, подключаемые непосредственно к провайдерским BR (Border router'ам).

Задачи серверов:
- заглотить список блокируемых ресурсов, выдрать оттуда имена доменов и разрезолвить их в ip-адреса; адресов получается несколько десятков тысяч
- полученные адреса через OSPF или BGP сливаются в BR. BR - он большой, спокойно держит BGP Full View, поэтому 10-20-50k лишних префиксов для него - капля в море

Получается, что весь трафик в сторону ip-адресов, на которых находится хотя бы одна заблокированная страница, теперь льётся на эти серверы.
Казалось бы, фиг какой сервер всё это переварит, но их можно плодить десятками: срабатывает ECMP/Load Balancing на уровне маршрутизации, и трафик размазывается между серверами примерно поровну.

На самих серверах Linux, а в Linux - squid в transparent mode и iptables )
Соответственно:
- tcp port 80 силами iptables отправляется в сквид, где каждый запрошенный абонентом URL ищется в списке блокированных ресурсов
- в tcp port 443 проверяется SNI чтобы понять, пропускать трафик дальше, или резать к такой-то матери
- весь остальной трафик (и пинги, угу) пропускается насквозь без изменения

Любой CI (Jenkins, CodeShip, Teamcity, etc) + инструмент для деплоя (Deployer, Rocketeer, Capistrano, Bash, etc).