Настройка HTTPS на своём сайте за 5 минут
Привет, в продолжение к прошлому посту, когда у вас есть сайт работающий через HTTP, наверняка захочется настроить HTTPS, видео как раз об этом :)
Доброго времени суток всем, вопрос начинающего. Дома на Orange Pi 3 LTS пытаюсь сделать сервер для сайта (с целью потренироваться и потому что хочется). Стоит Ubuntu и пробовал установить Apache и Ngix.
Сделал в TP Link резервирование IP для компьютера на котором стоит сервер и виртуальный сервер с переадресацией на 80 порт.
Находясь внутри сети переходя по IP компьютера в браузере открывается стартовая страница сервера. Но пытаясь ввести внешний IP роутера страница не открывается.
Извне работает подключение к компьютеру по VNC по порту 5901 с помощью сервиса no-ip, но вот веб сервер почему-то не хочет работать ни с доменом сервиса no-ip, ни с динамическим внешним ip.
Буду рад совету, спасибо за ваше участие.
Доброго времени суток всем, вопрос начинающего. Дома на Orange Pi 3 LTS пытаюсь сделать сервер для сайта (с целью потренироваться и потому что хочется). Стоит Ubuntu и пробовал установить Apache и Ngix.
Сделал в TP Link резервирование IP для компьютера на котором стоит сервер и виртуальный сервер с переадресацией на 80 порт.
Находясь внутри сети переходя по IP компьютера в браузере открывается стартовая страница сервера. Но пытаясь ввести внешний IP роутера страница не открывается.
Извне работает подключение к компьютеру по VNC по порту 5901 с помощью сервиса no-ip, но вот веб сервер почему-то не хочет работать ни с доменом сервиса no-ip, ни с динамическим внешним ip.
Буду рад совету, спасибо за ваше участие.
Имеем сервер ubuntu 22.04 установленый на VMware Workstation, а так же сеть настроена в режиме моста.
(в низу будут ссылки на все сайты которые использовались)
Настройка ssh. Он по умолчанию установлен, осталось лишь настроить.
Я лишь поменял порт, отключил возможность зайти за суперпользователя,
ужесточил кол-во попыток ввода пароля и сделал максимум сесий 2.
Теперь включаю ufw и разрешаю подключиться к порту ssh по своему ip.
Не забываем перезапустить и открыть порты в роутере.
Теперь нужно установить и настроить nginx под существующий домен.
Теперь нужно сюда выводить elk стек.
В идеале было бы хорошо использовать elk-docker, но понимание как работать с docker уменя нет.
Ну вроде все, если возникли ошибки - пишите, возможно помогу
https://www.digitalocean.com/community/tutorials/how-to-use-... - настройка ssh
https://www.digitalocean.com/community/tutorials/ufw-essenti... - настройка ufw
https://www.digitalocean.com/community/tutorials/how-to-inst... - настройка nginx
https://www.digitalocean.com/community/tutorials/how-to-inst... - настройка elk
(выглядит как реклама digitalocean, но это лушее что я нашел)
Всем привет. Вопрос к коллегам
Может подскажите как можно решить.
Задача следующая.
Есть фрейм, который через себя прогоняет данные отпределенной странички.
Так же есть прямой адрес этой самой странички.
Нужно закрыть прямой адрес, но оставть возможность отображения странички через фрейм.
Резолв странички идет с локального компьютера пользователя по прямому адресу.
Соотвественно закрывая доступ по прямому адресу старнички в интернете мы так же ломаем ее прорисовку в фрэйме.
Я вот думал CORS выкрутиться, но пока не очень получается.
Может подскажите способ?
Здравствуй пикабу, пост без рейтинга, просто ищу помощи, потому что уже отчаялся разобраться сам.
Есть сайт на Wordpress и с ним форум на домен/forum, который работал много лет на апаче, но в связи с техническими причинами пришлось переехать на сервак с nginx, сайт на ВП поднялся без проблем, а вот форум на vBulletin не получается никак и нормальных живых форумов с поддержкой походу уже не осталось, есть те, кто мог бы помочь?..
С самого начал работы над Roxy-WI мы думали о максимальном упрощении жизни пользователя с помощью веб-интерфейса. Поэтому мы решили добавить в продукт возможность работы с WAF (Web Application Firewall), чтобы обеспечить защиту веб-сервисов от разного рода вредоносной активности. Естественно, всё то мы старались сделать максимально просто, чтобы даже начинающий пользователь смог без проблем всё настроить.
Введение: немного о WAF вообще и о ModSecurity в частности
Аббревиатура WAF (Web Application Firewall) дословно переводится на русский как “файервол для веб-приложений”. Так называют программные инструменты для защиты веб-приложений от атак и вредоносной активности: брутфорса, SQL-инъекций, XSS-атак, спам-активности в комментариях, попыток загрузки подозрительных файлов и многого другого (у разных WAF набор функций может различаться). Для распознавания злонамеренных действий в разных WAF используются разные технологии: от программно-аппаратных решений, завязанных на железо ― до облачных, в которых активно применяются искусственный интеллект и машинное обучение.
WAF ― это своего рода “пропускной пункт” для всех запросов, направляемых на веб-сервер. Вероятность зловредной активности снижается за счёт того, что запросы, не соответствующие заданным критериям, до сервера не доходят. Как правило, в случае получения такого запроса пользователь получает уведомление, на основании которого при необходимости может и дополнительно усилить меры безопасности. Анализ и фильтрация запросов происходят на основе заданных пользователем правил, называемых также политиками.
На основании применяемых политик все WAF можно разделить на две большие группы: запретительные (англ. blocklist и разрешительные (англ. allowlist). Запретительные, как и следует из названия, не пропускают запросы, которые не попадают под установленными критериями. Разрешительные же работают прямо противоположным образом: они пропускают только те запросы, которые пользователь включил в число дозволенных. Оба этих подхода имеют свои плюсы и минусы, обсуждение которых в задачи нашей статьи не входит. Отметим только, что в современном мире они редко используются в чистом виде: большинство современных WAF используют политики, основанные как на разрешительном, так и на запретительном принципе.
На рынке в настоящее время представлено много инструментов для защиты веб-приложений. Большинство наиболее эффективных WAF ― платные; зачастую они входят в комплекс услуг, предоставляемых облачными и хостинг-провайдерами. Интеграция таких инструментов с веб-приложениями и сервисами, как правило, не представляет никакого труда: большинство провайдеров предоставляют удобный веб-интерфейс, а иногда и API для интеграции. Всё это, как и было сказано выше ― решения коммерческие. Что касается решений с открытым исходным кодом, с помощью которых можно добавить функциональность WAF в собственный сервис, то здесь выбор не особо велик: ModSecurity, WebKnight, Naxsi, Shadow Daemon ― больше никаких известных названий на ум и не приходит.
Самым популярным и самым распространенным из них является, конечно же, ModSecurity ― свободно распространяемый WAF, созданный Иваном Ристичем в 2002 году и в настоящее время поддерживаемый компанией Trustwave SpiderLabs (см. официальный репозиторий на GitHub). Начинался он как модуль для веб-сервера Apache, но со временем проект расширился: появилась поддержка Nginx и HAProxy; впоследствии был выпущен ModSecuriy-модуль и для майкрософтовского веб-сервера IIS.
Начиная с версии 3 проект что ModSecurity по сути начал новую жизнь: внимание разработчиков переключилось с модулей на библиотеку libmodsecurity, с помощью которой стало возможным внедрять функциональность WAF в любые приложения и сервисы: балансировщики нагрузки, панели управления хостингом и другие. Библиотеку можно использовать в программах на C и C++ (в настоящее время ― только для OC семейства Linux); реализована также поддержка ModSecurity для программ на Python.
Продолжается поддержка модулей для Apache и для Nginx (это не совсем модуль в буквальном смысле слова; сами разработчики используют термин сonnector); имеется так же агент для HAProxy.
Именно ModSecurity используется в качестве WAF в Roxy-WI. Ниже мы покажем, как организована работа в нашем сервисе, но перед этим скажем несколько слов об общих принципах работы ModSecurity.
Как работает ModSecurity
Чтобы начать использовать ModSecurity, нужно составить набор правил. Такие наборы поставляются в готовом виде: в свободном доступе распространяется OWASP Core RuleSet (сокращенно OWASP CRS), который как раз и используется в Roxy-WI.
На основе этого набора правил можно защитить веб-приложение от наиболее распространенных атак, в том числе:
- брутфорса;
- shell-инъекций;
- фиксаций сессии;
- SQL-инъекций
- межсайтового скриптинга (XSS);
- локального и удаленного внедрения файлов;
- попыток эксплуатации уязвимостей серии Bashdoor/ShellShock.
Кроме того, на основе правил можно блокировать любую подозрительную деятельность пользователей приложения, а также выявлять и блокировать ботов.
Структуру и синтаксис правил в этой статье мы подробно разбирать не будем, а всех заинтересованных читателей отсылаем к официальной документации.
ModSecurity на основе правил OWASP CRS может работать в двух режимах. Первый режим ― автономный (используется по умолчанию в ModSecurity версий 2.x). Здесь всё просто: если какой-то запрос попадет под условия правила, то он будет заблокирован; при этом все остальные правила ModSecurity проверять не будет.
Второй режим называется режимом оценки аномалий (используется по умолчанию в ModSecurity версий 3): ModSecurity проверяет все правила и на основе проверки по каждому правилу присваивает проверяемому запросу/ответу определенное количество баллов. Полное совпадение запроса с условиями правила оценивается в 5 баллов, а полное совпадение ответа ― в 4. При достижении порогового количества баллов запрос считается атакой и блокируется.
Как всё сделано в Roxy-WI
Чтобы наглядно продемонстрировать, как всё работает, рассмотрим следующую схему:
Здесь всё просто: запрос поступает на бэкенд HAProxy с прописанным правилом, после чего передаётся WAF. Если запрос соответствует правилу, то он возвращается обратно, после чего пересылается на бэкенд-сервер. Если же запрос правилу не соответствует, WAF возвращает ошибку 401 или 404.
В нашей реализации возможности работы с ModSecurity через веб-интерфейс мы руководствовались перечисленными ниже принципами.
Во-первых, установка и подключение WAF должно быть максимально простыми. Чтобы установить WAF, достаточно одного нажатия кнопки:
По завершении установки в меню выбираем HAProxy → WAF, находим в списке нужный сервер и в выпадающем меню WAF Mode выбираем On:
Помимо привычных On и Off можно выбрать ещё и пункт DetectionOnly. В этом случае WAF будет работать только на обнаружение атак, не принимая при этом никаких действий по их обработке.
Во-вторых, мы хотели бы максимально облегчить пользователю работу по добавлению и редактированию правил. В Roxy-WI используется такая модель: по умолчанию устанавливается готовый набор OWASP CRS; некоторые правила из набор пользователь при необходимости может убрать (а потом в случае необходимости вернуть снова). Чтобы просмотреть список правил, нужно нажать на кнопку Open (графа Manage Rules в списке серверов). На скриншоте ниже показан фрагмент списка правил:
Здесь всё просто нужно исключить правило ― убираем чекбокс enabled, нужно вернуть ― ставим чекбокс обратно. Недавно была добавлена возможность просмотра правил: для этого нужно нажать на кнопку View. А вот редактировать правила через веб-интерфейс нельзя ― хотя бы потому, что пользователь (особенно неопытный) может наделать синтаксических ошибок. Да и цель у нас изначально другая: предоставить пользователю (в первую очередь ― пользователю начинающему, который может и не знать ничего о ModSecurity) базовый набор правил из коробки. Если возникает необходимость отредактировать правила, то это можно сделать непосредственно на сервере.
В-третьих, мы хотели бы предоставить пользователям возможность удобного просмотра логов ModSecurity и сбора метрик. Чтобы просмотреть логи, достаточно кликнуть по имени сервера в списке; логи в веб-интерфейсе отображаются так:
Как видно из скриншота, через веб-интерфейс можно выполнять поиск по логам, а также просматривать логи за определенный период времени.
Заключение
Как обычно, приглашаем всех попробовать ― и поработать с WAF через Roxy-WI. Любые замечания и предложения по улучшению приветствуются.
Наш сайт: https://roxy-wi.org/
Наш GitHub: https://github.com/hap-wi/roxy-wi
Наш телеграм-канал: https://t.me/haproxy_wi
Также приглашаем высказаться в комментариях всех, кто имел дело с ModSecurity и его интеграцией в собственные сервисы: возможно, ваш опыт окажется для нас полезным.
В планах у нас, кстати, WAF для Nginx. Как только всё будет сделано, мы расскажем о нём подробнее в одной из следующих статей.