По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Фаервол на Микротике основан на базе принципов iptables в Linux позволяет фильтровать входящий и исходящий трафик по определенным правилам. В статье мы хотим рассказать про ключевые компоненты Firewall, дизайне и реализации этого инструмента. Погнали!
Общее представление
Основная идея любого фаервола это определение того, что разрешено и запрет всего остального. Так работают все современные инструменты фильтрации. При наличии фаервола, сеть можно разделить на ненадежные, полу - надежные и надежные.
Firewall Chains
Цепочки (последовательности) фаерволов сопоставляют по своим правилам входящий и исходящий с интерфейса трафик. После того, как трафик попал под определенное правило («сматчился»), вы можете совершать определенные манипуляции с ним: разрешить, блокировать, отклонить, внести в лог запись и так далее. В Mikrotik есть следующие флаги: Input, Output и Forward.
Input Chain
Input матчит входящий на интерфейсы маршрутизатора трафик. Условно говоря – это прилетающие на роутера IP - пакеты. Обычная практика – дропать пакеты, прилетающие на WAN, направленные на сканирование портов, попытки взлома и прочие. Помимо этого, многие блокируют входящий трафик изнутри локальной сети (например, допуск к Winbox или SSH должен быть только с определенного VLAN – остальные дропаются).
Всегда используйте VLAN – это базовое разграничение, которое позволит вам обеспечить современные стандарты безопасности.
Output Chain
Как можно догадаться по названию, данный инструмент направлен на фильтрацию исходящего от роутера трафика. Здесь можно блокировать запросы, исходящие непосредственно с роутера: например, DNS или ICMP запрос с роутера.
Forward Chain
Самое интересное – данный инструмент «матчит» трафик проходящий через Mikrotik с одного интерфейса на другой. Пример: пакет, отправленный с хоста внутри LAN через маршрутизатор в сторону провайдера. Пакет прилетает на внутренний интерфейс, а выходит через WAN.
Firewall Actions
Правила на фаерволе могут делать множество вещей, основные из которых: accept (принять), drop (сбросить) и отклонить (reject).
Accept
Данное правило позволяет просто «пропустить» проходящий через фаервол трафик. Никакой модификации или изменения маршрута – пакету будет позволено продолжить свой изначальный путь.
Reject
Фаервол может легко отклонить (сделать reject) пакетов, которые попадут под определенное правило. При этом, источнику такого пакета будет отправлено уведомление о соответствующей блокировке.
В данном методе есть один весомый минус: в случае, если злоумышленник попробует «сканировать» порты или совершить другой вид атаки – отправленные в его сторону REJECT сообщения лишь помогут ему в злодеяниях. Поэтому, в целях безопасности, мы рекомендуем использовать DROP.
Drop
Данное правило «дропает» пакет без отправления уведомления об этом источнику. Этот метод наиболее безопасен на этапе защиты своего Mikrotik от сканирования портов и прочих атак.
Firewall Rules
Правила Firewall определяют пакеты, которые будут обработаны на уровне фаервола, а какие будут отброшены. Каждое правило – это комбинация параметров IP – адресации (источник/получатель пакета), цепочек (chains), действий (actions), интерфейсов и прочих опций. Как мы говорили ранее – хорошо настроенный фаервол пропустит только необходимый для бизнеса трафика, дав запрет на пропуск всего остального потока трафика. Указывая набор разрешающих правил, всегда замыкайте их на конце строчкой «DENY ALL» (запретить все).
Chains
Каждое создаваемое правило назначается определенной цепочке (chain). После определения принадлежности к цепочке, пакеты проходят проверку через последовательность правил в порядке убывания (сверху вниз).
Порядок правил в фаерволе играет важную роль! Поэтому, от последовательности проверки зависит эффективность фильтрации.
Actions
Правило отрабатывает по одному из основных действий: принять (accept), отклонить (reject) и отбросить (drop). Выше мы подробнее рассказывали про каждое из указанных действий.
Адресация
Нашему правилу можно сказать, по какому критерию проводить блокировку: это может быть протокол, IP – адрес (это может быть как хост с /32 маской, так и целая подсеть с /24, например). Помимо этого, критерием могут быть физические или логические интерфейсы (eth/GRE).
Комментарии
Создавая правила комментируйте их. Это важно, как и при программировании – код без комментариев очень сложно анализировать и понимать в будущем.
Советы
Хотим так же поделиться парой полезных советов по настройке Firewall:
Разрешайте только необходимый для работы трафик - да, это сложно. Но методом проб и ошибок мы рекомендуем добиться той настройки фаервола, в рамках которой все ваши подключения будут ясны и понятны.
Подключения только с определенного пула адресов - это может быть удаленный офис, IP – адреса ЦОД или VPN адресация. Тут нужно быть особенно бдительным.
В конце правил всегда используйте «deny all» - после того, как вы выполнили первую и вторую рекомендации и весь тип трафика по протоколам, адресации, источникам (в том числе L7, например) четко определен – в конце цепочки добавьте правило запрета всего. Это будет означать, дословно: «Все, что не разрешено - запрещено».
Атакуйте свою сеть! - да, да, вы не ослышались. Конечно, без фанатизма :) Мы предлагаем периодически сканировать порты на вашем фаерволе. Например, это можно делать с помощью утилиты исследования сети Nmap.
Любое крупное приложение должно сопровождаться несколькими наборами тестов, с помощью которых можно проверить его стабильность и производительность.
Существует большое количество различных тестов, каждый из которых имеет свое назначение и охватывает определенные аспекты приложения. Именно поэтому, когда вы тестируете свое приложение, вы должны убедиться, что ваш набор тестов сбалансирован и охватывает все аспекты.
Однако есть один тип тестов, который разработчики часто предпочитают другим, и поэтому им часто злоупотребляют. Этот «сквозное тестирование» (E2E - end-to-end testing).
Что такое сквозное тестирование?
Для тех, кто только начал штурмовать мир тестирования программного обеспечения, E2E-тестирование - это проверка вашего приложения от начала до конца вместе со всеми его зависимостями.
При проведении E2E-тестировании вы создаете среду, которая будет идентична той, которую будут использовать реальные пользователи приложения. А затем вы тестируете все действия, которые могут выполнять пользователи в вашем приложении.
С помощью сквозного тестирования вы проверяете весь рабочий поток целиком, например, вход на веб-сайт или покупку товара в интернет-магазине.
Если вы будете злоупотреблять E2Е-тестирование, то вы перевернете пирамиду тестирования. Я в такой ситуации был. В одном из своих проектов я планировал охватить большую часть приложения Е2Е-тестами или, что еще хуже, воспользоваться лишь один Е2Е-тест. К счастью, я передумал. Так вот, теперь я хочу поделиться с вами тем, что заставило меня передумать.
Почему не нужно пренебрегать пирамидой тестирования?
Хаотично написанные тесты сначала могут показаться вполне пригодными, но в конце концов они таковыми не окажутся.
Мы пишем тесты для того, чтобы выиграть больше времени, и мы делаем это с помощью методы и средства автоматизации тестирования. Конечно, можно было бы самостоятельно открывать приложения и тестировать их вручную. Если бы это нужно было сделать однократно, то проблем не было бы. Но так бывает крайне редко.
Программное обеспечение постоянно обновляется. Поэтому необходимо проводить регулярные тестирования для того, чтобы оставаться в курсе последних событий. Вы, конечно, можете ежедневно запускать все тесты вручную при каждом обновлении приложения. Но если вы один раз напишите набор тестов, а затем будете его запускать каждый раз, когда нужно будет протестировать какой-то из аспектов приложения, то вы сэкономите много времени.
У каждого теста есть свое назначение. Если вы будете использовать их не по назначению, то они могут вам больше навредить, чем помочь. Это связано с тем, что в итоге вы потратите больше времени на то, чтобы написать эти тесты, и на их сопровождение, чем на разработку самого приложения. Иными словами, вы останетесь без одного из самых больших преимуществ автоматизированного тестирования.
Хорошее начало – придерживаться пирамиды тестирования. Она поможет вам определить правильный баланс в тестированиях. Эта пирамида является отраслевым стандартом и используется с середины 2000-х годов по сей день, так как все еще считается эффективной.
Значит ли это, что разработчики никогда не пренебрегают этой пирамидой? Не совсем. Иногда пирамида бывает перевернутой, где большую часть тестов составляют Е2Е, а иногда она бывает похожа на песочные часы, где очень много юнит- и Е2Е-тестов, но с очень мало интеграционных тестов.
Три уровня пирамиды тестирования
Как правило, пирамида тестирования имеет три уровня: юнит-тесты, интеграционные тесты и сквозные тесты.
Юнит-тесты
Юнит-тесты, или модульные тесты, делают акцент на самых маленьких единицах кода, таких как функции и классы.
Они короткие и не зависят ни от каких-либо внешних пакетов, библиотек и классов. В противном случае, в ход идет имитированная реализация.
Если юнит-тест дает сбой, то найти причину проблемы не так сложно. Они также имеют небольшой диапазон тестирования, что делает их простыми в написании, быстрыми в работе и легкими в сопровождении.
Интеграционные тесты
Интеграционные тесты делают акцент на взаимодействии между двумя отдельными объектами. Как правило, они работают медленнее, потому что они требуют более серьезной настройки.
Если интеграционные тесты проваливаются, то найти проблему немного сложнее, так как диапазон ошибок больше.
Они также более сложные в написании и сопровождении, в основном потому, что они требуют более продвинутое имитирование и расширенную область тестирования.
Сквозные тесты
И наконец, сквозные тесты, или E2E-тесты. Они делают акцент на рабочих потоках, от самых простых до самых сложных. Эти тесты можно рассматривать как многоэтапные интеграционные тесты.
Они самые медленные, потому что они подразумевают сборку, развертывание, запуск браузера и выполнение действий внутри приложения.
Если сквозные тесты проваливаются, то найти проблему часто бывает очень сложно, потому что диапазон ошибок увеличивается до всего приложения. В принципе, по пути могло сломаться все что угодно.
Это, безоговорочно, самый сложный тип тестов для написания и сопровождения (из трех типов, которые рассмотрели здесь) из-за огромного диапазона тестирования и из-за того, что они охватывают все приложение.
Надеюсь, теперь вы понимаете, почему пирамида тестирования была спроектирована именно таким образом. Снизу-вверх каждый уровень тестирования говорит о снижении скорости и увеличении диапазона и сложности и усложнении сопровождения.
Именно поэтому важно не забывать о том, что E2E-тестирование не может полностью заменить другие методы – оно лишь предназначено для расширения их возможностей. Назначение Е2Е-тестирования четко определено, и тесты не должны выходить за его границы.
В идеале тесты должны выявлять ошибки настолько близко к корню пирамиды, насколько возможно. Е2Е-тест предназначен для проверки кнопок, форм, изменений, ссылок, внешних процессов и вообще всех функций рабочего потока.
Тестирование с кодом VS codeless-тестирование
В целом, существует два типа тестирования: ручное и автоматизированное тестирование. Это значит, что мы можем проводить тестирования либо вручную, либо с помощью сценариев.
Чаще используют именно второй метод. Но и автоматизированное тестирование можно разделить на две части: тестирование с кодом и codeless-тестирование.
Тестирование с кодом
Когда вы проводите тестирование с кодом, вы используете фреймворки, которые могут автоматизировать браузеры. Один из самых популярных инструментов – это Selenium, но я больше предпочитаю использовать в своих проектах Cypress (только для JavaScript). И тем не менее, работают они практически одинаково.
По сути, с помощью таких инструментов вы моделируете веб-браузеры и даете им указания для выполнения различные действия в вашем целевом приложении. После чего вы проверяете, отреагировало ли ваше приложение на соответствующие действия.
Это простой пример имитации, взятый из документации Cypress. Я привел его, чтобы вы могли лучше понять, как работает этот инструмент:
Давайте посмотрим, что тут происходит:
Допустим, пользователь посещает сайт
https://example.cypress.io
Когда она нажимает на ссылку с пометкой type, URL-адрес должен добавить /commands/actions
Если он вводит «fake@email.com» в поле ввода .action-email, тогда ввод .action-email принимает значение «fake@email.com».
Codeless-тестирование
В ситуации с codeless-тестированием вы используете фреймворки на базе искусственного интеллекта, которые запоминают ваши действия. И основываясь на некоторой дополнительной информации, они проверяют, отвечает ли ваше целевое приложение на действия должным образом.
Эти инструменты часто выглядят как малокодовые платформы для разработки, где вы перемещаете различные панели. Один из таких инструментов – TestCraft, codeless-решение, разработанное на платформе Selenium.
Как правило, эти инструменты стоят дороже из-за того, то такие функции, как создание, сопровождение и запуск тестов выполняются с помощью простого перемещения панелей, а также из-за того, что для проведения тесто не нужно уметь писать программный код. Но я упомянул здесь про TestCraft, потому что у них есть бесплатная версия, которая включает в себя практически все.
Конечно, если речь идет о скорости и деньгах, то codeless-решение может оказаться вам больше по душе, но они все еще достаточно новые. Поэтому они пока не могут иметь ту сложность наборов тестов, которой можно достичь, написав код самостоятельно.
Если в целевом приложении есть очень сложные рабочие потоки, которые включают в себя несколько подвижных частей, то вам больше подойдет классический вариант тестирования. Но если сложных потоков нет, то вы можете воспользоваться codeless-решением.
Подведение итогов
Написание тестов – обязательное требование для любого приложения. Если вы будете следовать всем правилам и писать наборы тестов исходя из их типов, то они только улучшат ваше приложение, а также их будет довольно просто написать и сопровождать.
Использовать сквозные тесты, как и любые другие, следует только для того, для чего они предназначены. Они предназначены для тестирования рабочего потока приложения от начала и до конца путем воспроизведения реальных пользовательских сценариев. Но помните, что большинство ошибок следует выявлять как можно ближе к корню.
В этой статье расскажем как отправлять различные СМС сообщения пользователям, позвонившим в контакт-центр Октелл и запросившим такую информацию: информация по текущим тарифам, инструкции по смене тарифа или подписки и прочее.
Настройки в личном кабинете системы «Ростелеком СМС Реклама»
«Ростелеком СМС Реклама» позволяет отправлять СМС, используя простой API. После заключения договора и получения доступа к личному кабинету, необходимо настроить этот самый API. Для это в личном кабинете нажимаем на свой логин в правом верхнем углу и выбираем раздел «Общие настройки»:
Откроется окно настроек профиля. Здесь нажимаем кнопку «API-рассылки»:
Откроется список всех настроенных на данный момент подключений (если они уже настроены). Существующее подключение невозможно редактировать, пока оно работает. Вы можете только посмотреть его, приостановить или завершить, если в этом есть необходимость. Нажимаем кнопку «Настроить подключение»:
В открывшемся окне настроим параметры для нашего подключения.
Здесь необходимо задать следующие настройки:
Тип рассылки - в нашем случае, это HTTP. Октелл будет присылать POST-запросы.
Название рассылки – любое произвольное название.
Время жизни СМС – можно задать время от 1 до 24 часов. Если по истечение этого времени СМС не будет доставлена, отправка отменяется.
IP-адрес клиента – здесь нужно указать «белый» IP, с которого будут приходить запросы. Если адреса нет в списке, авторизация не пройдет и СМС отправляться не будут.
После нажатия кнопки «Продолжить» статус рассылки изменится на «Подготовка», здесь нужно нажать кнопку «Сохранить» и ожидать результата.
На этой странице, кроме параметров самой рассылки, так же приведены параметры для подключения: URL, login и пароль. Эти параметры всегда можно посмотреть на странице “API-рассылки”, выбрав нужное подключение из списка.
Так же необходимо создать и согласовать короткое имя, которое будет отображаться в поле «Отправитель» при получении СМС. Это нужно сделать в разделе «Ресурсы» - «Имена отправителей». Этот параметр понадобится нам далее.
Этих настроек достаточно, чтобы можно было отправлять СМС посредством API. Теперь переходим к настройке системы Октелл.
Настройка системы Октелл
Все пояснения по взаимодействию с API Ростелекома изложены в инструкции «HTTP API для отправки сообщений (JSON)».
POST-запрос отправляется на URL, указанный в настройках подключения в личном кабинете. Каждый запрос должен пройти авторизацию. Авторизация происходит по методу HTTP Basic Auth, логин/пароль для авторизации так же указаны в личном кабинете в настройках подключения.
Для отправки сообщения в самом запросе нам нужны три значения:
MSISDN – это номер адресата. В формате 7 и 10-значный федеральный номер, (например: 79091234567)
Shortcode – имя отправителя, созданное в личном кабинете ранее
Text – непосредственно сам текст сообщения. Для переноса строки в тексте следует использовать последовательность символов
, иначе сообщение не отправится.
Итак, для отправки СМС я создал отдельный сценарий. Входным параметром для него является значение сессионной переменной.
Далее, в самом сценарии, в зависимости от значения этой переменной, подставляется соответствующий текст для тела сообщения:
Рассмотрим сценарий детальнее.
Проверка и корректировка АОН
На первом этапе проверяем АОН. Так как у нас звонки приходят с двух разных транков, на одном из них АОН выдается в формате 79091234567, а на другом 89091234567. Для использования в запросе мы должны использовать формат с 7-кой в начале номера, и то, что не соответствует данному формату, нам нужно преобразовать:
При входе мы сравниваем АОН с числом 8 000 000 00 00. Если АОН меньше этого числа, он проходит без изменений и мы присваиваем его значение переменной msisdn, которую будем использовать далее в POST-запросе. Иначе нам необходимо вычесть из АОНа число 1 000 000 00 00, и уже получившееся значение поместить в переменную msisdn:
Подготовка текста сообщения
На данном этапе текст сообщения в моей задаче выбирается из нескольких статичных шаблонов. В последующем текст будет изменяться под каждого конкретного абонента (отсылаем информацию по его тарифу, услугам и прочее), но сейчас этот функционал еще не готов на стороне биллинговой системы. В любом случае, текст сообщения выбирается исходя из значения сессионной переменной, значение которой было присвоено в предыдущем сценарии после того, как абонент выбрал какой-либо пункт IVR нажатием соответствующей кнопки. Выбранный текст сохраняется в переменной smstext, которую мы будем использовать далее в запросе:
Отправка запроса
После того, как у нас есть значения всех переменных, мы переходим непосредственно к отправке самого POST-запроса (предварительно все ветви сходятся в элементе «уведомление», которое выводит текст сформированного сообщения и номер абонента. Это элемент отладки и на работу сценария никак не влияет). Запрос будет сформирован и отправлен с помощью инструмента WEB-запрос:
Здесь используем следующие параметры:
URL – адрес, указанный для отправки в параметрах соединения в личном кабинете
Базовая авторизация – не использовать. В документации заявлено, что это поле позволяет использовать необходимый нам метод HTTP Basic Auth, однако на деле, при включении данной опции, авторизация у Ростелекома не проходит.
Метод – POST
Тип контента - application/json (нужно написать вручную)
Тип запроса – аргумент
Запрос – использован вот такой текст: '{"msisdn": ' + [msisdn] + ',"shortcode": "имя из ЛК","text": "' + [smstext] + ' "} '
Где:[msisdn] – имя переменной, где хранится номер телефона, на который отправляем смс, "имя из ЛК" – короткое имя, которые мы настроили в личном кабинете, [smstext] – переменная, где хранится текст самого сообщения.
В самом Октеле это должно выглядеть так (красный шрифт – статический текст, синий – переменные):
Вернемся к окну «Инспектор объектов» (параметры объекта «WEB-запрос»).
Дополнительные заголовки – посредством этого поля мы выполним авторизацию. Для этого установим здесь значение:
Authorization:Basic YTJwdGVzdF9zaWJpcjphMnB0ZXXX, где YTJwdGVzdF9zaWJpcjphMnB0ZXXX – это login:pass в base64. Для получения этой строчки выписываем свои логин: пароль и переводим кодируем их в base64 на любом подходящем интернет-ресурсе, например www.base64decode.org
Ответ в переменную – укажем переменную, где будет сохраняться ответ на наш запрос. Нужно, чтобы в дальнейшем с помощью инструмента «Парсер» посмотреть результат запроса.
Элемент «Парсер» настроим так, как указано на картинке ниже:
Тег «status» информирует о результате запроса. Если пришло «OK» - значит, запрос принят, сообщение отправлено. Если пришло «error» - значит, произошла какая-то ошибка. В этом случае, в поле «reason» будет указана ошибка, которую можно расшифровать, используя документацию:
Это основные настройки, которые позволяют отправлять СМС через систему «Ростелеком СМС Реклама» из платформы Октелл