пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вопрос о балансировке нагрузки на WAN-линках встает довольно часто, и, к сожалению, в отличие от некоторых других вещей, которые можно настроить на оборудовании MikroTik быстро и безболезненно - в случае настройки Load Balancing придется немного постараться. Тема относительно сложная, наличие нескольких WAN-линков и задача по настройке балансировки нагрузки включает в себя настройку нескольких шлюзов и маршрутов по умолчанию, множество правил трансляции NAT и так далее.
Настройка маршрутизатора
Итак, в наличие у нас имеется один маршрутизатор MikroTik, который подключен к двум провайдерам - Тарс Телеком и Милайн на портах ether1 и ether2 соответственно, и локальной сетью на порту ether3. Трафик из локальной сети будет NATирован из обоих WAN портов и будет сбалансирован по нагрузке. Топология ниже:
Настраиваем локальные IP-адреса:
/ip address
add address=1.1.1.199/24 interface=ether1 comment="Tars"
add address=2.2.2.199/24 interface=ether2 comment="Meeline"
add address=192.168.1.1/24 interface=ether3 comment="LAN Gateway"
Настраиваем шлюзы по умолчанию:
/ip route
add dst-address=0.0.0.0/0 check-gateway=ping gateway=1.1.1.1,2.2.2.1
Настраиваем NAT на WAN портах для исходящего направления:
/ip firewall nat
add action=masquerade chain=srcnat comment="Tars" out-interface=ether1
add action=masquerade chain=srcnat comment="Meeline" out-interface=ether2
Если на данном этапе перестать настраивать роутер, то это будет являть собой пример настройки отказоустойчивости. Если один из линков “отвалится”, то вместо него будет использоваться второй. Однако, никакой балансировки нагрузки здесь нет и в помине, и, с экономической точки зрения, это является плохой идеей - вряд ли найдется компания, которая захочет платить абонентскую плату за второй канал и использовать его только в случае аварии.
Исходящая и входящая Mangle маркировка
Одной из типичных проблем при использовании более одного WAN-соединения является то, что пакеты принятые на одном WAN интерфейсе, могут тут же быть отправлены через другой WAN-интерфейс, что может, к примеру, сломать VPN-based сеть. Нам нужно чтобы пакеты “принадлежащие” одному и тому же соединению принимались и отправлялись через один и тот же WAN порт. В случае аварии у одного из провайдеров, все подключения на порту “умрут” и затем будут переподключены на другом WAN порту. Для этого необходимо промаркировать соединения:
/ip firewall mangle
add action=mark-connection chain=input comment="Tars Input" in-interface=ether1 new-connection-mark="Tars Input"
add action=mark-connection chain=input comment="Meeline Input" in-interface=ether2 new-connection-mark="Meeline Input"
Это поможет маршрутизатору отслеживать порт для каждого входящего подключения.
Теперь мы будем использовать отметку подключения для входящих пакетов для вызова отметки маршрутизации. Это отметка маршрутизации будет использована позднее на маршруте, который будет сообщать подключению через какой WAN-порт необходимо слать пакеты наружу.
add action=mark-routing chain=output comment="Tars Output" connection-mark="Tars Input" new-routing-mark="Out Tars"
add action=mark-routing chain=output comment="Meeline Output" connection-mark="Meeline Input" new-routing-mark="Meeline Telecom"
Помеченные подключения затем получают метку маршрута, так что роутер сможет маршрутизировать пакеты так, как нам необходимо. В следующем шаге мы настроим роутер таким образом, чтобы помеченные пакеты отправлялись наружу из корректного WAN-подключения.
Маркировка LAN маршрута
Понадобится также настроить несколько Mangle правил - они необходимы, чтобы сообщить роутеру о необходимости балансировки пакетов, которые отправляются из локальной сети. Сам механизм балансировки в этой статье не описывается, можно только сказать что происходить много операций хеширования - если же интересно копнуть глубже, то вы можете обратиться к официальной документации MikroTik. В соответствии с этими правилами маршрутизатор будет балансировать трафик приходящий на порт ether3 (LAN-порт), который направлен на любой нелокальный адрес в Интернете. Мы захватываем трафик в цепочке предварительной маршрутизации для перенаправления его на необходимый нам WAN-порт в соответствии с меткой маршрутизации.
Следующие команды балансируют трафик на LAN-интерфейсе через две группы:
add action=mark-routing chain=prerouting comment="LAN load balancing 2-0"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Tars" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/0
add action=mark-routing chain=prerouting comment="LAN load balancing 2-1"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Meeline" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/1
Настройка меток маршрутизации выше была выполнена точно такие же как и в предыдущем шаге и соответствуют тем маршрутам, которые будут созданы в следующем шаге.
Особые маршруты по умолчанию.
В данный момент у нас должны быть помечены соединения поступающие на WAN-порты и эти метки были использованы для создания меток маршрутизации. Балансировка нагрузки в LAN, описанная в предыдущем шаге, также создает метки маршрутизации в соответствии со следующим шагом, в котором будут созданы маршруты по умолчанию, которые будут захватывать трафик с данными метками маршрутизации.
/ip route
add distance=1 gateway=1.1.1.1 routing-mark="Out Tars"
add distance=1 gateway=2.2.2.1 routing-mark="Out Meeline"
Данные маршруты используются только при наличии необходимой метки маршрутизации. Непомеченные пакеты используют обычный маршрут по умолчанию.
Маршруты, относящиеся к Тарс Телеком получают метку подключения, которая вызывает метку маршрутизации. Эта метка маршрутизации совпадает с меткой в маршруте выше и обратный пакет выходит из того же интерфейса, на котором был получен изначальный пакет.
Заключение
Итого, какие шаги по настройке роутера были выполнены:
Маркировка новых подключений в WAN
Соединения с этой маркировкой получают метку маршрутизации
Исходящий из локальной сети трафик балансируется с теми же метками маршрутизации
Метки маршрутизации соответствуют маршрутам по умолчанию и отправляются из соответствующего интерфейса
Если количество WAN-линков более 2 - необходимо проделать такие же действия для остальных подключений.
Итого, теперь у вас настроена балансировка трафика для двух WAN-соединений.
Разработчики программного обеспечения должны держать много информации у себя в голове. Существует множество вопросов, которые нужно задать, когда речь заходит о создании веб-сайта или приложения: Какие технологии использовать? Как будет настроена структура? Какой функционал нам нужен? Как будет выглядеть пользовательский интерфейс? Особенно на рынке программного обеспечения, где производство приложений больше похоже на гонку за репутацией, чем на хорошо обдуманный процесс, один из важнейших вопросов, который часто остается на дне “Списка важных”: Как наш продукт будет защищен?
Если вы используете надежный, открытый фреймворк для создания своего продукта (и, если он доступен и пригоден, почему бы и нет?), тогда базовые проблемы безопасности, как атаки CSFR и кодирование пароля, могут быть уже решены за вас.
Тем не менее, быстро развивающимся разработчикам будет полезно освежить свои знания о стандартных угрозах, дабы избежать ошибок новичка. Обычно самое слабое место в безопасности вашего программного обеспечения - это вы.
А кто может заниматься взломом?. Есть этичный хакер – это тот, кто ищет возможные слабости в безопасности и приватно рассказывает их создателям проекта.
А чёрный хакер, которого так же зовут “Взломщик (cracker)” – это тот, кто использует эти слабости для вымогательства или собственного блага.
Эти два вида хакеров могут использовать одинаковый набор инструментов и, в общем, пытаются попасть в такие места, куда обычный пользователь не может попасть. Но белые хакеры делают это с разрешением, и в интересах усиления защиты, а не уничтожения её. Черные хакеры – плохие ребята.
Вот некоторые примеры наиболее распространённых атаках, которые используют слабости в защите: Внедрение SQL-кода и межсайтовый скриптинг XXS.
SQL атаки
SQL-инъекция (SQLi) - это тип инъекционной атаки, которая позволяет выполнять вредоносные SQL команды, для получения данных или вывода из строя приложения. По сути, злоумышленники могут отправлять команды SQL, которые влияют на ваше приложение, через некоторые входные данные на вашем сайте, например, поле поиска, которое извлекает результаты из вашей базы данных. Сайты, закодированные на PHP, могут быть особенно восприимчивы к ним, и успешная SQL-атака может быть разрушительной для программного обеспечения, которое полагается на базу данных (например, ваша таблица пользователей теперь представляет собой пустое место).
Вы можете проверить свой собственный сайт, чтобы увидеть, насколько он восприимчив к такого рода атакам. (Пожалуйста, тестируйте только те сайты, которыми вы владеете, так как запуск SQL-кодов там, где у вас нет разрешения на это, может быть незаконным в вашем регионе; и определенно, не очень смешно.) Следующие полезные нагрузки могут использоваться для тестов:
' OR 1='1 оценивается как константа true, и в случае успеха возвращает все строки в таблице
' AND 0='1 оценивается как константа false, и в случае успеха не возвращает строк.
К счастью, есть способы ослабить атаки SQL-кода, и все они сводятся к одной основной концепции: не доверяйте вводимым пользователем данным.
Смягчение последствий SQL-кодов.
Чтобы эффективно сдержать атаки, разработчики должны запретить пользователям успешно отправлять необработанные SQL-команды в любую часть сайта.
Некоторые фреймворки сделают большую часть тяжелой работы за вас. Например, Django реализует концепцию объектно-реляционного отображения, или ORM с использованием наборов запросов. Мы будем рассматривать их в качестве функций-оболочек, которые помогают вашему приложению запрашивать базу данных с помощью предопределенных методов, избегая использование необработанного SQL.
Однако возможность использовать фреймворк никогда не является гарантией. Когда мы имеем дело непосредственно с базой данных, существуют и другие методы, которые мы можем использовать, чтобы безопасно абстрагировать наши SQL-запросы от пользовательского ввода, хотя они различаются по эффективности. Они представлены по порядку от более к менее важному:
Подготовленные операторы с переменной привязкой (или параметризованные запросы)
Хранимые процедуры
Белый список или экранирование пользовательского ввода
Если вы хотите реализовать вышеприведенные методы, то эти шпаргалки - отличная отправная точка для более глубокого изучения. Достаточно сказать, что использование этих методов для получения данных вместо использования необработанных SQL-запросов помогает свести к минимуму вероятность того, что SQL будет обрабатываться любой частью вашего приложения, которая принимает входные данные от пользователей, тем самым смягчая атаки SQL-кодов.
Межсайтовые скриптовые атаки (XSS)
Если вы являетесь хакером, то JavaScript - это в значительной степени ваш лучший друг. Правильные команды будут делать все, что может сделать обычный пользователь (и даже некоторые вещи, которые он не должен делать) на веб-странице, иногда без какого-либо взаимодействия со стороны реального пользователя.
Межсайтовые скриптовые атаки, или XSS, происходят, когда код JavaScript вводится на веб-страницу и изменяет ее поведение. Его последствия могут варьироваться от появления неприятных шуток до более серьезных обходов аутентификации или кражи учетных данных.
XSS может происходить на сервере или на стороне клиента и, как правило, поставляется в трех вариантах: DOM (Document Object Model - объектная модель документа) на основе хранимых и отображаемых XSS. Различия сводятся к тому, где полезная нагрузка атаки вводится в приложение.
XSS на основе DOM
XSS на основе DOM возникает, когда полезная нагрузка JavaScript влияет на структуру, поведение или содержимое веб-страницы, загруженной пользователем в свой браузер. Они чаще всего выполняются через измененные URL-адреса, например, в фишинговых письмах.
Чтобы увидеть, насколько легко было бы для введенного JavaScript манипулировать страницей, мы можем создать рабочий пример с веб-страницей HTML. Попробуйте создать файл в локальной системе под названием xss-test.html (или любым другим) со следующим кодом HTML и JavaScript:
<html>
<head>
<title>My XSS Example</title>
</head>
<body>
<h1 id="greeting">Hello there!</h1>
<script>
var name = new URLSearchParams(document.location.search).get('name');
if (name !== 'null') {
document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
}
</script>
</h1>
</html>
На этой веб-странице будет отображаться заголовок "Hello!” если только он не получает параметр URL из строки запроса со значением name. Чтобы увидеть работу скрипта, откройте страницу в браузере с добавленным параметром URL, например:
file:///path/to/file/xss-test.html?name=Victoria
Наша небезопасная страница принимает значение параметра URL для имени и отображает его в DOM. Страница ожидает, что значение будет хорошей дружественной строкой, но что, если мы изменим его на что-то другое? Поскольку страница принадлежит нам и существует только в нашей локальной системе, мы можем тестировать ее сколько угодно. Что произойдет, если мы изменим параметр name, скажем, на:
<img+src+onerror=alert("pwned")>
Это всего лишь один пример, который демонстрирует, как может быть выполнена атака XSS. Смешные всплывающие оповещения могут быть забавными, но JavaScript может принести много вреда, в том числе помогая злоумышленникам украсть пароли и личную информацию.
Хранимые и отраженные XSS
Хранимые (stored) XSS возникают, когда полезная нагрузка атаки хранится на сервере, например, в базе данных. Атака влияет на жертву всякий раз, когда эти сохраненные данные извлекаются и отображаются в браузере.
Например, вместо того чтобы использовать строку URL-запроса, злоумышленник может обновить свою страницу профиля на социальном сайте, чтобы внедрить скрытый сценарий, скажем, в раздел “Обо мне”. Сценарий, неправильно сохраненный на сервере сайта, будет успешно выполняться всё время, пока другой пользователь просматривает профиль злоумышленника.
Одним из самых известных примеров этого является червь Samy, который практически захватил MySpace в 2005 году. Он распространялся путем отправки HTTP-запросов, которые копировали его на страницу профиля жертвы всякий раз, когда просматривался зараженный профиль. Всего за 20 часов он распространился на более чем миллион пользователей.
Отраженные (reflected) XSS аналогично возникают, когда введенные данные перемещаются на сервер, однако вредоносный код не сохраняется в базе данных. Вместо этого он немедленно возвращается в браузер веб-приложением.
Подобная атака может быть осуществлена путем заманивания жертвы для перехода по вредоносной ссылке, которая отправляет запрос на сервер уязвимого веб-сайта. Затем сервер отправит ответ злоумышленнику, а также жертве, что может привести к тому, что злоумышленник сможет получить пароли или совершить действия, которые якобы исходят от жертвы.
Ослабление XSS
Во всех этих случаях XSS могут быть сдержаны с помощью двух ключевых стратегий: проверка полей формы и предотвращение прямого ввода данных пользователем на веб-странице.
Проверка полей формы
Фреймворки снова могут нам помочь, когда речь заходит о том, чтобы убедиться, что представленные пользователем формы находятся в актуальном состоянии. Один из примеров - встроенные классы полей Django, которые предоставляют поля, проверяющие некоторые часто используемые типы, а также задают нормальные значения по умолчанию.
Например, поле электронной почты Django использует набор правил, чтобы определить, является ли предоставленный ввод действительным письмом. Если отправленная строка содержит символы, которые обычно не присутствуют в адресах электронной почты, или если она не имитирует общий формат адреса электронной почты, то Django не будет считать это поле допустимым и форма не будет отправлена.
Если вы не можете полагаться на фреймворк, можете реализовать вашу собственную проверку входных данных. Это можно сделать с помощью нескольких различных методов, включая преобразование типа, например, гарантируя, что число имеет тип int(); проверка минимальных и максимальных значений диапазона для чисел и длин строк; использование заранее определенного массива вариантов, который позволяет избежать произвольного ввода, например, месяцев года; и проверка данных на соответствие строгим регулярным формулировкам.
К счастью, нам не нужно начинать все с нуля. Помогут доступные ресурсы с открытым исходным кодом, такой как валидация репозитория регулярных выражений OWASP, который предоставляет шаблоны для сопоставления их с некоторыми распространенными формами данных. Многие языки программирования предлагают библиотеки проверки, специфичные для их синтаксиса, и мы можем найти множество таких библиотек на GitHub.
Хотя это и может показаться утомительным, правильно реализованная проверка ввода может защитить наше приложение от восприимчивости к XSS.
Предотвращение прямого ввода данных
Элементы приложения, которые непосредственно возвращают пользовательский ввод в браузер, при обычной проверке могут быть неочевидны. Мы можем определить области приложения, которые могут быть подвержены риску, изучив несколько вопросов:
Как происходит поток данных через приложение?
Что ожидает пользователь, когда он взаимодействует с этими входными данными?
Где на нашей странице появляются данные? Становятся ли они встроенными в строку или атрибут?
Вот некоторые примеры полезных нагрузок, с которыми мы можем поиграть, чтобы проверить входные данные на нашем сайте (опять же, только на нашем собственном сайте!). Успешное выполнение любого из этих образцов может указывать на возможную уязвимость к XSS из-за прямого ввода данных.
"><h1>test</h1>
'+alert(1)+'
"onmouserover="alert(1)
http://"onmouseover="alert(1)
Как правило, если вы можете обойти прямой ввод данных, сделайте это. Кроме того, убедитесь, что вы полностью понимаете эффективность выбранных методов; например, использование innerText вместо innerHTML в JavaScript гарантирует, что содержимое будет задано как обычный текст вместо (потенциально уязвимого) HTML.
Аккуратнее с вводом!
Разработчики программного обеспечения явно находятся в невыгодном положении, когда речь заходит о конкуренции с черными хакерами. Несмотря на всю проделанную работу по защитите каждого ввода, который потенциально может скомпрометировать наше приложение, злоумышленнику достаточно только найти тот, который мы пропустили. Это все равно что установить засовы на всех дверях, но оставить окно открытым!
Однако, научившись мыслить в том же ключе, что и злоумышленник, мы можем лучше подготовить наше программное обеспечение к противостоянию плохим парням. Как бы ни было интересно добавлять функции как можно быстрее, мы избежим большого количества долгов по кибербезопасности, если заранее продумаем поток нашего приложения, проследим за данными и обратим внимание на наши входные данные.
Миллиарды веб-приложений прямо сейчас обмениваются информацией: интернет-магазины подтверждают оплату, сервисы отправляют уведомления о бронировании, датчики передают сигналы. В идеале, о таких событиях хочется узнавать сразу. Если сервер свой, можно настроить мониторинг, но что делать, если это внешний сервис? В этом случае на помощь приходят вебхуки. Они позволяют различным системам обмениваться данными в реальном времени. В этой статье мы разберём, что такое вебхук, как он работает, где и зачем его использовать, а также как настроить.
Что такое вебхук
Вебхук — это инструмент для обмена данными между различными сервисами. Он помогает автоматизировать процессы и делает работу более эффективной.
Новым событием может быть любое важное действие в системе. Например:
Интернет-магазин: покупатель оформил заказ, оплата прошла успешно, товар передан в доставку.
Платежный сервис: успешная или неудачная транзакция.
Социальные сети: новый комментарий, лайк, подписка.
Сервисы автоматизации: изменение статуса задачи в Trello, новый лид в CRM.
Устройства умного дома: сработал датчик движения, дверь открылась.
Как работает вебхук?
Представь, что ты оформил заказ в интернет-магазине. Вместо того чтобы постоянно обновлять страницу в ожидании статуса доставки, ты просто получаешь уведомление: «Ваш заказ передан в службу доставки» или «Курьер уже в пути». Это и есть вебхук — магазин автоматически отправляет данные, как только происходит важное событие. В отличие от обычного API, где нужно запрашивать информацию самому, вебхук сообщает тебе новости.
Как вебхук передаёт информацию?
Когда происходит событие, вебхук отправляет HTTP-запрос на заранее указанный URL. В теле запроса передаются данные о событии в формате JSON или XML. Приложение, которое принимает вебхук, получает этот запрос и обрабатывает данные: обновляет статус заказа, отправляет письмо клиенту или выполняет другие действия.
В чём его отличие от API?
Вебхук и API используются для обмена данными между сервисами, но работают по-разному. И вот в чем разница:
Критерий
Вебхук
API
Кто запрашивает данные?
Сервер сам отправляет данные клиенту, когда происходит событие.
Клиент сам отправляет запрос к серверу, чтобы получить нужные данные.
Как часто обновляются данные?
Автоматически в реальном времени при наступлении события.
Только когда клиент запрашивает. Если он не спросит, данных не будет.
Нагрузка на сервер
Минимальная, так как запросы идут только при необходимости.
Высокая, если часто запрашивать данные.
Пример
Магазин получает уведомление о смене статуса заказа мгновенно.
Магазин запрашивает статус заказа каждую минуту.
Настраиваем вебхук в GitHub
Настройка вебхука зависит от сервиса, с которым ты работаешь, но общий процесс всегда похож. Давай разберёмся на примере GitHub — популярной платформы для размещения репозиториев.
1. Для начала надо создать сервис, который будет принимать данные. Это может быть простой API-сервер, который будет обрабатывать запросы по определённому адресу (например,
https://example.com/webhook
).
2. Далее настраиваем вебхук в GitHub. Для этого надо зайти в настройки репозитория, выбирать раздел «Webhooks» и добавить новый вебхук, указав URL, куда будет отправляться информация.
3. Выбираем события. Ты можешь указать, какие именно события будут отправлять данные. Например, уведомление о коммите, создании Pull Request и т. д.
4. Обработка полученных данных. Когда на твою ссылку поступит запрос от GitHub, сервер должен обработать данные и выполнить нужное действие, например, сохранить информацию в базе данных или отправить уведомление.
Проблемы с вебхуками
1. Нет гарантии доставки
Вебхуки отправляют данные один раз, и если сервер-получатель в этот момент недоступен, информация может потеряться. Например, если твой сервер упал на несколько минут, а вебхук был отправлен именно в это время, он просто не дойдёт. Некоторые сервисы повторяют отправку несколько раз с увеличением задержки (экспоненциальный бэкофф), но это зависит от конкретного провайдера. Чтобы избежать проблем, важно логировать все входящие вебхуки и уметь повторно обрабатывать данные.
2. Проблемы с безопасностью
Если URL вебхука станет попадет в сеть, злоумышленники могут отправлять поддельные запросы, имитируя события. Это может привести к утечке данных или выполнению нежелательных операций. Чтобы защититься, нужно использовать верификацию вебхуков. Например, можно передавать секретный ключ в заголовках запроса или проверять подпись HMAC. Также стоит ограничить доступ по IP-адресам, принимая запросы только от доверенных сервисов.
3. Отсутствует контроль над частотой запросов
Некоторые вебхуки могут отправляться слишком часто, особенно если речь идёт о сервисах с высоким трафиком. Например, если в интернет-магазине идут тысячи заказов в минуту, то сервер может просто не справиться с потоком входящих запросов. Решением может быть использование очередей сообщений или установленные ограничения на частоту обработки вебхуков.
4. Изменения в формате данных
Внешний сервис может обновить структуру передаваемых данных, и это сломает интеграцию. Например, раньше ты получал JSON с ключом "order_id", а после обновления API этот ключ стал называться "id". Если твой код не готов к таким изменениям, он просто перестанет работать. Чтобы избежать проблем, полезно следить за обновлениями API, валидировать входящие данные перед обработкой и использовать резервные стратегии (например, хранить копию старых данных).
5. Сложности отладки
Вебхуки срабатывают только при случившемся событии, поэтому их сложнее тестировать, чем обычные API-запросы. Например, если ты настраиваешь вебхук для платежной системы, тебе придётся ждать реальной транзакции, чтобы проверить его работу. Это неудобно, особенно на этапе разработки.
Подведем итоги
Вебхук — это автоматически сгенерированный HTTP-запрос, который отправляется сервером при наступлении события.
Вебхуки работают быстро и в одну сторону, без необходимости отправлять запросы вручную.
Они часто используются для уведомлений о важных событиях, например, об оплате счета или бронировании билета.
Главное отличие вебхука от API — вебхук срабатывает автоматически при событии, а API требует запроса со стороны клиента.
У вебхуков есть проблемы: возможная потеря данных при сбоях, уязвимости безопасности и сложности масштабирования при большом объёме событий.