Вряд ли можно найти менеджера, который ни разу не попадал под цунами из срочных задач. В такой ситуации последней каплей могут стать рутинные активности — не самые сложные, но достаточно важные.
Меня зовут Марат и я QA Lead в команде тестирования бизнес-инициатив Россельхозбанка по АБС Центра финансовых технологий. В этой статье я поделюсь опытом преодоления трудностей в моей работе, и инструментами, которые действительно помогают, когда задачи накрывают с головой. Примеры будут касаться в первую очередь QA-менеджмента, но я уверен, что некоторые решения могут быть применимы к самым разным областям и окажутся полезны многим.
Оперативное управление загрузкой команды при поддержке бота
Мне, как тимлиду, необходимо обладать полной информацией о том, чем сейчас заняты разработчики, и какая загрузка планируется у них в ближайшее время. В теории это не так уж сложно, однако на практике с завидным постоянством в дело вмешиваются внешние силы: от срочной поставки вендора и обновлений в правовой базе до непредвиденных больничных и новых задач по проекту. Очевидное решение в такой ситуации – ежедневные созвоны для обновления статуса, но нам этот вариант не подошел. И вот почему.
Затратно по времени – и чем больше в команде человек, тем больше времени занимает обновление статуса от каждого.
Риски по таймингу: звонок может совпасть с другой встречей, присутствие на которой тоже будет необходимо.
Смещение фокуса: коллективное обсуждение критической проблемы запросто может перерасти в брейнсторминг и обсуждение интересных, но менее приоритетных задач по проекту.
Неочевидным, но эффективным решением для меня стало написание бота для Telegram. Бот написан на Python. И вот как он помогает менеджерить команду: у нас оговорено время Х, к которому сотрудники проверяют почту, смотрят свои поставки, списываются при необходимости с аналитиком/разработчиком. Далее каждый отправляет боту сообщение формата: [Идентификатор задачи] – [Вид работы] – [Сколько времени планирую сегодня потратить на задачу]. Бот возвращает ошибку, если сообщение отбивается об некорректное оформление, либо подтверждает верный ввод.
Затем весь массив данных на лету интегрируется в Google-формы и закидывает их построчно в таблицу на первый лист. Одновременно с этим на другом листе формируется простая и понятная сводная таблица в разрезе сотрудника и его задач на текущий день.
Что дало такое решение? В первую очередь колоссальный выигрыш по времени. При этом задачи распределять стало существенно проще: всегда можно посмотреть, кто свободен, а у кого сильный загруз и ему самому требуется помощь. При этом пресловутый тимбилдинг никуда не делся: мы еженедельно созваниваемся и обсуждаем новости и вопросы, которые возникают в процессе работы. Это позволяет не быть «оторванными» от команды.
Рассинхрон с командой разработки, и чем тут поможет JIRA
Случается, что сроки по задаче перенеслись, а информация об этом дошла не до всех. В результате люди делают лишнюю работу или не успевают сделать нужное. В этой ситуации очень эффективным инструментом для этого (и для многих других ситуаций) становится JIRA. Project automation в JIRA отлично отлавливает изменения в критичных для планирования полях задач по разработке и отправляет уведомление на почту. В этот инструмент можно зашить очень многое и степень его применения гораздо шире, чем может показаться. Например, можно улучшать культуру ведения дефектов – автоматизировать рассылку по дефектам, которые заведены вашей командой, при соблюдении определенных условий. У меня это:
В теме дефекта не указан идентификатор бизнес-инициативы.
Дефект по воркфлоу находится «На исправлении», а исполнителем по нему является тестировщик (и прочие подобные).
Описание дефекта не содержит ключевых словоформ про шаги, ожидаемый/фактический результаты и так далее.
Также при помощи питоновских библиотек Plotly и Pandas мне удалось подружить свою поделку на Python с нашим проектом в JIRA. Данные автоматически затягиваются, модифицируются, где требуется, и формируются в график задач с длительностями, исполнителями и прочими данными, появляющимися при наведении курсора. Получается так:
Отдельно хочу остановиться на важности регулярного заполнения полей. В JIRA для этого есть массовое изменение — bulkchange – но оно все-таки достаточно неудобное и долгое, особенно в случаях, когда вам нужно ставить в разных местах разные значения. В таких ситуациях крайне рекомендую прибегнуть к помощи скриптов. Я их создавал на Python: одно нажатие приводит к заполнению определенных полей по самым различным задачам и занимает секунды вместо минут (колоссальная экономия!).
И еще пару слов о JIRA. Безусловно, есть много готовых решений, позволяющих нарезать и получать задачи через отдельную платформу, но тогда их приходится держать где-то еще, в стороне от багтрекинговой системы, по сути – плодить сущности. Мне существенно удобнее мониторить такого рода задачи на джировском дашборде одновременно с задачами по реализации бизнес-инициатив. И для этого я тоже написал скрипт. Он позволяет создавать поручения в отдельном проекте JIRA: либо единичное, либо сразу на всю команду. Таким образом в одном месте получилось аккумулировать как приближение дедлайнов по развитийным задачам, так и по различного рода поручениям – от сбора статистики до заполнения отчетов. Дополнительным плюсом в данном случае является возможность гибко настроить проект под свои нужды – например, статусную модель или отдельные поля.
Excel как универсальный инструмент
И к самому простому решению. Перепробовав с десяток приложений для тайм-менеджмента, я в итоге остановился на Excel. Он хорош далеко не для всего, но полностью списывать со счетов инструмент еще рано. Его очевидным плюсом является полная адаптивность: можно все настроить под свои потребности. Например, накрутить условное форматирование на заливку ячеек, сделать колонку для вспомогательных меток, добавить комментарий в нужной ячейке или написать макрос.
Принцип моей работы с Excel (который у меня выступает в роли расширенного планера) элементарный – если активность завершена, то напротив нее ставится пометка в текущем дне, а утром столбец за вчерашний день скрывается.
В случае непредвиденных падений автосохраненная копия в любом случае будет, но я взял за привычку периодически кидать сохраненный файл себе в почту – правило сортирует его в отдельную папку, и эти письма никогда мне не мешают (в любой непонятной ситуации – перестрахуйся).
Подводя итоги, могу сказать, что время можно и нужно пытаться выигрывать. Для этого не обязательно полностью перестраивать производственный процесс, иногда достаточно поменять или автоматизировать процессы, до которых ты в силах дотянуться. Для меня такой подход работает и приносит хорошие результаты. Надеюсь и вам мои лайфхаки пригодятся.
Всем привет! В нашем блоге мы уже рассказывали о том, что на форуме Positive Hack Days 11 работала специальная зона Payment Village, где любой желающий мог поискать уязвимые места в онлайн-банке, банкоматах (если вдруг пропустили, читайте подробный райтап) и POS-терминалах. Конкурс по обнаружению уязвимостей в онлайн-банке не новый, однако в последние годы его немного потеснили активности по этичному хакингу других финансовых систем. В 2022 году мы решили исправить эту несправедливость и создали новую банковскую платформу, применив накопленный за все это время опыт. Участникам предлагалось найти типовые банковские уязвимости и зарепортить их нам. По сценарию конкурса можно было играть либо за «белых шляп» (участвовать в программе bug bounty онлайн-банка), либо за «черных шляп» (стараться украсть из банка как можно больше денег).
В первую очередь мы оценивали критичность каждого найденного бага, затем подсчитывали общее количество уязвимостей, которое участник нашел во время исследования банковской системы. Награда в 50 тысяч рублей по традиции присуждалась тому, кто обнаружил самые опасные бреши, — в этом году победителем стал catferq. Он отыскал наибольшее число заложенных нами уязвимостей, среди которых были два критических бага, а также один баг, о наличии которого не подозревали даже мы :). Кроме catferq были награждены и другие участники, обнаружившие уязвимости с менее высоким уровнем риска: hundred303, null1337undefined, kab5fa2hs, HackathonDev и c0rv4x. Благодарим всех, кто принял участие в нашем конкурсе: было очень интересно читать ваши репорты и отзывы по улучшению активности.
Немного про онлайн-банк
В этом году мы решили не использовать предыдущие наработки, а создать для конкурса новый сервис с нуля. За эту задачку со звездочкой взялся один из самых молодых специалистов нашей команды по исследованию безопасности банковских систем — он работал над этим проектом под наставничеством более опытных коллег. Наш онлайн-банк состоял из фронтенд- и бэкенд-частей, а также автоматизированной банковской системы (АБС). Вместе с базой данных (postgres) и хранилищем куки (redis) он был поднят в нескольких связанных друг с другом контейнерах. Кстати, банк до сих пор доступен — можете поизучать его прямо сейчас.
Для участия в конкурсе требовалось пройти несложную регистрацию, которая по нашей задумке уже содержала недоработки (об этом расскажем по ходу статьи). Сдать репорты можно было через специальную форму, которая открывалась с помощью клика по жучку на главной странице.
Чтобы обнаружить уязвимости, которые мы заложили в онлайн-банк, участникам требовалось проявить смекалку и применить все свои пентестерские навыки.
Недоработки авторизации и парольной политики онлайн-банка
Начнем разбор заданий с входной точки для любого злоумышленника — формы входа в личный кабинет.
Брутфорс формы входа
При регистрации внимательные участники могли заметить:
слабую парольную политику онлайн-банка;
IP-адрес атакующего, пробовавшего взломать аккаунты методом перебора паролей, не блокировался.
Рассмотрим этот кейс на примере одного из аккаунтов и попробуем подобрать пароль к учетной записи User1234. Несмотря на большое число попыток ввода неверного пароля, мы каждый раз получаем сообщение invalid username or password:
А теперь попробуем ввести верный пароль:
Как видите, ответ изменился: система на пять минут заблокировала вход в аккаунт. На самом деле блокировка произошла во время одной из попыток ввода неверного пароля. Помимо того, что система не запрещает перебирать данные аккаунтов (хотя и пытается скрыть это под сообщением invalid username or password), у участников была еще возможность подобрать пароли от известных им аккаунтов по словарям. Например, в футере главной страницы онлайн-банка были указаны контакты администраторов (имя пользователя и адрес электронной почты), с которыми, по легенде конкурса, могли связаться участники. Как вариант, можно было попробовать перебрать пароль одного из администраторов по словарю rockyou.
Результаты задания на PHDays 11: ни один из участников не смог обнаружить данную уязвимость.
Брутфорс CVV
Отсутствие в системе защиты от перебора пароля открывало для участников еще одну возможность для атаки — брутфорс CVV на банковских картах. Чтобы получить PAN карт, содержащихся в системе, участники могли воспользоваться уязвимостью с раскрытием карточных данных. Для ее эксплуатации необходимо было взять данные карты из системы и зайти с их помощью в онлайн-банк:
Получаем стандартный ответ о неверно введенных данных, запускаем перебор CVV и видим, как во время одного из запросов код ответа поменялся с 200 на 302. Остановимся детальнее на этом запросе-ответе.
Так система ведет себя только в одном из тысячи вариантов, что позволяет сделать вывод о том, что таким способом можно было подобрать CVV известных нам банковских карт.
Результаты задания на PHDays 11: ни один из участников не смог обнаружить эту уязвимость.
Брутфорс одноразового кода
При входе в личный кабинет участники по желанию могли включить двухфакторную аутентификацию. В этом случае при вводе правильных логина и пароля сервер просил дополнительно подтвердить вход с помощью одноразового кода (OTP):
Одноразовый код приходил участникам в Telegram-аккаунт, который они указывали при регистрации.
Верификация аккаунта и получение ОТР для входа:
Попробовав ввести неверный пароль, получаем от сервера ответ, что одноразовый пароль неверен.
Опытным путем выясняем, что OTP сменяется онлайн-банком один раз за тысячу попыток ввода.
И на этом этапе участникам конкурса стоило насторожиться: код состоял из четырех цифр. Это дает ненулевой шанс на угадывание требуемого для ввода одноразового кода. Отметим, что в реальных банковских системах установлены более строгие, хотя и не всегда достаточные с точки зрения ИБ ограничения на отправку одноразовых паролей.
Вспомним немного курс университетской (или школьной) математики. Каков шанс угадать четырехзначное число с десяти тысячи попыток при условии, что число меняется каждую тысячу попыток? Ответ: 1—(0,9)10 ~ 0,6513, где 0,9 — вероятность того, что за итерацию, пока будет доступно одно число, его не получится угадать.
Если нет желания углубляться в математику, придумывать свои скрипты на Python (или каком-то другом языке), а хочется сразу начать процесс перебора цифр, можно воспользоваться популярной утилитой для тестирования веб-уязвимостей Burp Suite. Изучив, как сервер отвечает в случае успешной проверки данных входа (логина, пароля или OTP), выставляем в параметрах Intruder регулярное выражение на ответ и запускаем атаку полным перебором.
Как видно на скриншоте, таким способом удалось угадать одноразовый код (не подглядывая в СМС с паролем!) с восьмого захода, или на 7317-й попытке.
Результаты задания на PHDays 11: двое участников обнаружили эту уязвимость и отправили нам отчет о ней. Интересно, что мы не заметили по логам, чтобы кто-то из участников в дальнейшем эксплуатировал ее для получения доступа к аккаунтам. По нашей задумке участники должны были провести брутфорс пароля одного из администраторов (его пароль угадывался по словарю перебора паролей Rockyou), а после попробовать попасть в аккаунт администратора, используя эту уязвимость.
Недостатки бизнес-логики в OTP
Одним из этапов привязки Telegram-аккаунта для получения одноразовых паролей была его верификация. Участникам требовалось ввести специальный код, подтверждающий данные об аккаунте в системе. Любопытные хакеры начали бы размышлять так: «у нас есть два Telegram-аккаунта, если нам потребуется привязать второй вместо первого либо просто отвязать первый от конкретного личного кабинета, что с ним будет в системе? Теоретически его должны удалить». Но так ли это? Пробуем привязать его в другом личном кабинете. И — о чудо! — система не требует его верифицировать, а сразу добавляет его.
К чему может привести этот недостаток системы? Потенциальный злоумышленник может без верификации закрепить за своим личным кабинетом Telegram-аккаунт легитимного пользователя, тем самым лишив последнего возможности вновь привязать собственный аккаунт к своему личному кабинету для двухфакторной аутентификации. Кроме того, эта ошибка бизнес-логики в ходе комплексной атаки может привести к тому, что клиент банка не сможет воспользоваться двухфакторной аутентификацией со своего доверенного аккаунта. Также теперь злоумышленникам не нужно бороться с одноразовым кодом, а достаточно подобрать учетные данные жертвы. Вдобавок к этому данная уязвимость дает злоумышленникам возможность провести CSRF-атаку и привязать свой «потерявшийся» в системе аккаунт к профилю жертвы, заблокировав ей доступ к собственному личному кабинету. Все это делает пользовательский аккаунт уязвимым для атак злоумышленников.
Результаты задания на PHDays 11: только один участник прислал отчет об этой уязвимости.
Раскрытие маскированных данных по имени пользователя
Еще одной уязвимостью, заложенной в онлайн-банк, была утечка информации о карточных данных. Участники могли использовать утекшие данные для брутфорса CVV карты и для эксплуатации уязвимостей, связанных с кредитами.
Денежные переводы можно совершить по номеру банковской карты или по имени пользователя в системе. Первый способ знаком каждому из нас, а вот второй нечасто используется для перевода денег. Рассмотрим его детальнее.
Сделаем перевод одному из пользователей по имени:
5572443375087227 — номер рублевой карты пользователя, который совершает перевод другому пользователю по его имени в системе;
8531606207370870 — номер долларовой карты пользователя, который совершает перевод другому пользователю по его имени в системе.
Система успешно провела транзакцию:
Проверив, что делает фронтенд для получения этих данных, увидим, что в запросе на получение транзакций указывается параметр hidecard со значением true. В ответ сервер присылает «правильные» (с точки зрения ИБ) данные с маскированным номером карты.
Повторяем запрос, но вместо true в параметре hidecard выставляем значение false:
На скриншоте выделена информация, которую можно получить, оформив перевод по имени одного из пользователей. Если бы это была реальная банковская система, возможность получить номер карты являлась бы не только прямым нарушением требований PCI DSS[1], но и лазейкой, позволяющей злоумышленнику при небольших усилиях совершать мошеннические платежи. Также в данном задании это помогло бы участникам реализовать один из возможных сценариев в рамках комплексного вектора атаки, когда несколько простых уязвимостей используются вместе для достижения большего эффекта.
Результаты задания на PHDays 11: четыре участника направили отчеты об этой уязвимости.
Ошибки округления
Другая интересная ошибка, которую мы добавляем в наш конкурс уже не в первый раз, — этоошибка округления. Допустим, если курс доллара к рублю составляет 1:60, то за 60 рублей мы получим один доллар. А что, если мы попробуем перевести 36 копеек в центы? Сумма будет меньше стоимости одного цента, однако банк не может списать 36 копеек, начислив 0 центов. Он округлит сумму до 0,01 доллара. Таким образом за меньшую цену можно получить ту же сумму, но в валюте. При этом при переводе обратно можно вернуть 0,60 рубля. Сумма нехитрого заработка составит 60 − 36 = 24 копейки.
В нашем онлайн-банке мы немного упростили эту уязвимость, чтобы участники смогли заметить ее и воспользоваться.
Номер рублевой карты пользователя — 7047169154995669, номер долларовой карты пользователя — 9384411725418749.
Курсы валют в банке:
Начальный баланс банковских карт:
Переведем, например, 100 рублей с рублевой карты на долларовую по текущему курсу.
Перевод прошел успешно. Обратим внимание на изменения в балансах карт:
Уже на данном этапе заметна уязвимость: при переводе 100 рублей по заявленному курсу в процессинге банка получилось следующее число: 1,257861… Однако центы — это сотые доллара, а не тысячные, из-за чего система округлила результат в большую сторону, как и требуется по правилам арифметики. Получилось — 1,26. Таким образом мы получили лишними целых 0,003 доллара.
Продемонстрируем серьезность данной уязвимости, попробовав на ней заработать. Для этого сделаем перевод в обратную сторону — на рублевую карту:
По актуальному курсу это будет 1,26 х 79,5 = 100,17 рубля! Изменившийся баланс карт подтверждает это:
На долларовой карте мы вернулись к исходному значению, однако баланс рублевой карты стал больше первоначального. Пара нехитрых манипуляций позволила заработать 17 копеек. Представьте, какие последствия грозят банку, если он оставит такую лазейку для злоумышленников в реальной жизни.
Результаты задания на PHDays 11: данную уязвимость обнаружили пять участников. Более того, один из них предоставил скрипт, автоматизирующий процесс заработка денег при эксплуатации этой уязвимости. Благо разработчики системы ДБО, то есть мы, не мешали ему разными одноразовыми паролями и капчами😁. За счет автоматизации он украл скромные 500 рублей, чтобы наглядно показать нам возможность эксплуатации уязвимости. Хотя если бы это была реальная банковская система и настоящие злоумышленники, созданный скрипт помог похитить миллионы.
Оформление кредитов
Недостатки бизнес-логики при выдаче кредитов на одну карту
Как видно из ответа сервера, в онлайн-банке есть ограничение по количеству кредитов, оформленных на одну карту, — не более трех. Однако Logger Burp Suite показывает, что нам все-таки удалось получить четыре кредита на одну и ту же карту.
Первый запрос на оформление кредита:
Последний запрос на оформление кредита:
Скрины подтверждают, что у онлайн-банка отсутствует заявленное ограничение на выдачу максимум трех кредитов.
Результаты задания на PHDays 11: отчет об этой ошибке не отправил ни один из участников, хотя по логам системы ДБО мы увидели, что троим из них встретилась эта недоработка.
Insecure direct object reference (IDOR)
При оформлении кредита в качестве карты списания средств разрешается указать карту другого пользователя. Это может привести к тому, что со счета злоумышленника деньги списываться не будут. Получить номер карты можно путем эксплуатации уязвимости с утечкой карточных данных пользователей.
Доступные карты:
Операция по списанию денежных средств с карты другого пользователя:
Результаты задания на PHDays 11: репорты об этой уязвимости прислали два участника.
Обход ограничения по количеству кредитов
Во время исследования системы участники могли заметить, что реквизиты одной и той же карты для списания по кредиту можно указать только четыре раза. Это значит, что пользователь, у которого есть две карты, может взять максимум восемь кредитов (это следует из вышеописанной ошибки бизнес-логики). Эти ограничения можно легко обойти, используя предыдущую уязвимость в этом же сервисе. Вот как это выглядит:
На скриншоте видно, что количество списываемых кредитов по карте достигло максимума. То же самое происходит и со второй картой.
Теперь попробуем обойти теоретический предел с помощью IDOR:
У нас получилось обойти лимит по количеству кредитов, указав банковскую карту другого пользователя (ее номер мы получили, проэксплуатировав уязвимость, связанную с раскрытием карточных данных по имени пользователя). Сообщение от сервера подтверждает, что открыто девять заявок на кредит, а не восемь. Ниже скриншот одной из последних заявок.
Результаты задания на PHDays 11: участники, которые обнаружили предыдущую уязвимость, к сожалению, не обратили внимание на описанное ограничение и не попробовали его обойти. Мы, со своей стороны, также не выявили тех, кто мог бы незаметно для нас использовать эту недоработку.
Отказ в обслуживании
Еще одной брешью в функционале кредитов было проведение DoS-атак (Denial of Service, отказ в обслуживании). Участникам был доступен кредитный калькулятор, который позволял рассчитывать количество и время платежей по выбранной программе. Рассмотрим, как можно было выявить DoS.
Сначала отправляем стандартный запрос с расчетом на ближайшее время:
Кажется, время ответа нормальное и ничего не предвещает беды. Но давайте поиграем с параметрами period и end_time. Сначала изменяем параметр end_time с 2023-го на 2070 год.
Как видите, прибавление годов увеличивает время ответа сервера. Теперь поменяем в параметре period 1 день на 1 час.
Время ответа сервера тоже кратно увеличилось — это позволяет сделать вывод, что в этом функционале есть DoS.
Отметим, что мы предусмотрели ограничение по количеству отправляемых запросов к данному функционалу, так как любой участник конкурса во время тестирования мог случайно сгенерировать множество таких запросов. Это могло привести к перегрузке системы, что помешало бы остальным участникам свободно исследовать другие ее элементы и подсистемы. Поэтому мы выставили ограничение: не более трех запросов с дальнейшей блокировкой пользователя на несколько минут.
Результаты задания на PHDays 11: мы получили всего один отчет об этой уязвимости, хотя в первую ночь соревнований зафиксировали высокую нагрузку на систему. Она была вызвана тем, что многие участники пытались эксплуатировать эту уязвимость.
RCE-уязвимость (Remote сode execution)
Сложно переоценить опасность уязвимости, касающейся выполнения произвольного кода в таких критичных системах, как онлайн-банкинг. Однако периодически и такие бреши встречаются. Мы использовали одну из нашумевших уязвимостей конца 2021 года — CVE-2021-44228, или Log4Shell, разместив в составе банка уязвимую версию пакета Log4j.
В погоне за элегантным сценарием полной компрометации банковской системы через веб-уязвимость мы не заметили некоторые ошибки при компиляции сервиса. Таким образом, появилось два способа выполнения произвольного кода, один из которых был доступен в течение ограниченного промежутка времени в самом начале конкурса (спасибо Apache и его дефолтному DEBUG-журналированию внутри самого себя 🤬). В обоих случаях для эксплуатации уязвимости необходимо было использовать PoC с GitHub.
Официальный способ
Рассмотрим постоянный способ получить реверс-шелл, эксплуатируя Log4Shell. Для этого требуется захватить один из аккаунтов администраторов, так как через их панель можно удалить любого пользователя из системы. Захватить аккаунт можно в ходе одной из комбинаций простых атак на банковскую систему, а сам запрос на удаление выглядит следующим образом:
Проэксплуатируем Log4j через параметр username: вставляем полезную нагрузку в параметр и получаем:
Эксплуатация прошла успешно:
Результаты задания на PHDays 11: ни один из участников не дошел до этапа эксплуатации этой уязвимости, так как им не удалось захватить аккаунт администратора.
Неофициальный способ
Этот способ предложил один из участников уже после завершения конкурса, поэтому мы не могли не рассказать о нем в своей статье. Он использовал сканер, который и обнаружил эту уязвимость, подставив полезную нагрузку в куки одного из запросов. Как выяснилось позже, данный способ работал с любым запросом к системе. Мы были очень удивлены тем, что никто во время конкурса не нащупал эту брешь и не зарепортил ее.
Для начала запускаем скрипт:
В BurpSuite Repeater отправляем любой запрос, который получаем от фронтенда. В данном случае это /sharedData/admins. Делаем инжект в куки запроса со своим IP-адресом, предварительно запустив сервер у себя для получения реверс-шелла:
Профит! У нас есть реверс-шелл в узле с бэкенда банка 🙂
Успешная эксплуатация уязвимости:
Стоит отметить, что данный способ работает всего один раз. Apache журналирует это событие с пометкой, что при его повторении оно не будет еще раз залогировано (невалидная куки). То есть воспользоваться данной уязвимостью участники конкурса могли лишь единожды с момента запуска сервиса.
Уязвимости CSRF
Еще одним слабым местом в онлайн-банке была возможность проводить атаки CSRF. Внимательные читатели наверняка уже заметили, что в описанных ранее запросах ни в каком виде не использовался CSRF-токен. Так, например, участники конкурса могли сгенерировать серию запросов с любого сайта, который посетил пользователь, к онлайн-банку, чтобы от его лица получать данные о его банковских картах и переводить деньги с его карт себе. В системе было множество возможностей, аналогичных этой.
Результаты задания на PHDays 11: лишь один участник сообщил об этом недостатке безопасности.
Возможные сценарии атак, или В чем полезность конкурса
Создавая Payment Village на Positive Hack Days, мы преследовали цель не только обратить внимание на потенциальные уязвимости в банковских системах, но и помочь как атакующим, так и защитникам осознать возможные последствия кибератак на банковские системы. Как злоумышленники могут воспользоваться найденными IDOR в кредитах, ошибкой округления в межвалютных переводах, слабой парольной политикой или неправильно реализованной двухфакторной аутентификацией? Сценарии атак могут быть такими:
Возможность перебора паролей при входе позволяет атакующим получить пароль одного из администраторов.
Уязвимость бизнес-логики в OTP дает атакующим возможность угадать одноразовый пароль. С его помощью они могут зайти в аккаунт одного из администраторов. В дальнейшем злоумышленники могут не ограничиваться лишь только удалением пользователей, как мы описывали ранее в статье, но и, к примеру, воспользоваться Log4Shell для проникновения в инфраструктуру банка.
Грамотное применение ошибки округления, а также автоматизация валютных переводов между своими картами может сделать злоумышленников богачами (участников нашего конкурса так уж точно 🤑).
Ошибка в бизнес-логике в OTP и CSRF-уязвимость позволяют атакующим сменить данные в ходе атаки на двухфакторную аутентификацию и привязать свой Telegram-аккаунт к личному кабинету легитимного пользователя без какой-либо верификации. Отсюда следует, что жертва не сможет самостоятельно войти в свой личный кабинет — это можно будет сделать, только обратившись за помощью к представителям банка.
Заключение
Несмотря на то что конкурс мы проводим уже несколько лет, некоторые задания этого года показались участникам нестандартными, а порой и не совсем очевидными. Многие участники искали стандартные веб-уязвимости, не приняв во внимание, что наш конкурс в первую очередь нацелен на демонстрацию уязвимости банков. Все это мы взяли на заметку и обязательно используем при подготовке очередного конкурса в следующем году, чтобы сделать его еще интереснее и привлечь как можно больше участников!
Конкурс по поиску уязвимостей в онлайн-банке доступен для повторного прохождения, хотя уже и без наград. В августе 2022 года банковская платформа получила два обновления, в рамках которых мы добавили новые уязвимости. Теперь любой желающий может прокачивать свои пентестерские навыки круглогодично на нашей площадке 😊.
Больше о Payment Village можно узнать в Telegram. До встречи на следующем форуме Positive Hack Days!
Автор в Telegram:@geralt_iz_rivii
[1]Payment card industry data security standard (PCI DSS) (с англ. «стандарт безопасности индустрии платежных карт») — это стандарт безопасности данных платежных карт, учрежденный международными платежными системами Visa, MasterCard, American Express, JCB и Discover.
Привет, Хабр! На связи Рустем, IBM Senior DevOps Engineer & Integration Architect. Сегодня я хотел бы поговорить о сетевой безопасности. DevOps инженеру необходимо разбираться в сетях не хуже специализированного нетворк инженера. В этом же нам поможет Kali Linux и его инструментарий.
Kali Linux уже давно является дистрибутивом Linux для профессионалов в области безопасности. Kali Linux имеет большую коллекцию ориентированных на безопасность инструментов для пентестеров, специалистов по цифровой криминалистике, реверс-инженеров и других специалистов, которые хотят выполнять задачи, связанные с безопасностью, в среде Linux. В любое время, когда вы хотите выполнить тестирование безопасности, вы должны иметь возможность контролировать то, что вы делаете. Один из хороших способов сделать это — просмотреть сетевой трафик. У вас должна быть возможность перехватывать сетевые сообщения, чтобы вы могли анализировать происходящее и узнавать “the truth of communication”. Это может помочь вам решить множество проблем, с которыми вы можете столкнуться.
Источником правды, когда дело доходит до связи с одного компьютера на другой, является сеть. “Applications can lie” — Приложения могут лгать (или просто не сообщать вам, что было бы ложью по упущению). Когда один компьютер отправляет сообщение другому, единственным местом, где вы можете гарантировать получение правды, является сеть. Есть пара вещей, которые нужно знать, прежде чем мы начнем. Сетевые интерфейсы созданы для фильтрации, чтобы не перегружать принимающую операционную систему. Они делают это, проверяя адрес управления доступом к среде (MAC) в пункте назначения фрейма. Фрейм представляет собой набор заголовков уровня 2 для связи в локальной физической сети. Если MAC-адрес назначения совпадает с адресом, связанным с сетевым интерфейсом (физическим адресом), соответствующий пакет перенаправляется в операционную систему. Однако не весь трафик является одноадресным. Иногда по сети отправляются широковещательные(broadcast) сообщения, в том числе когда другой системе необходимо знать, какой MAC-адрес принадлежит указанному адресу интернет-протокола (IP). Эти бродкастовые сообщения также пересылаются в операционную систему для обработки операционной системой. Все остальное отбрасывается сетевым интерфейсом, потому что оно не имеет значения.
Мы, безусловно, можем выполнять захват пакетов в сообщениях, отправленных нам, чтобы мы могли видеть информацию, которая удаляется интерфейсом и операционной системой. Однако полезнее просматривать все сообщения, которые могут пройти через интерфейс. В те времена, когда для передачи сообщений из одной системы в другую использовались концентраторы, все сообщения в сети проходили через все системы. Сегодня мы используем коммутаторы (или беспроводные средства связи, выполняющие аналогичную функцию). Это означает, что на наш сетевой интерфейс отправляются только сообщения, предназначенные для нашей системы, и бродкастовые сообщения. Тем не менее, есть способы получить больше сообщений, которые можно сделать в сети, поэтому нам нужно перевести наш интерфейс в беспорядочный режим(promiscuous mode). Это говорит интерфейсу прекратить фильтровать проходящие сообщения и отправить все в операционную систему для обработки.
К счастью, tcpdump, программа, которую мы собираемся использовать для перехвата трафика, переведет интерфейс в правильный для нас режим. Как только это будет сделано, он начнет вытягивать все фреймы и отображать их. Хотя tcpdump часто называют программой захвата пакетов, технически то, что мы видим, является фреймом. Фрейм включает в себя заголовки уровня 2. Пакет — это имя блока данных протокола для уровня 3, на котором живет IP. Поскольку мы можем видеть заголовки уровня 2, это фрейм, но для простоты термин «пакет» часто используется для всего пакета.
К счастью, перехватить трафик на сетевом интерфейсе несложно. Мы просто запускаем tcpdump
Когда мы захватим достаточно трафика (или только что закончили захват трафика), нам нужно остановить tcpdump, нажав Ctrl-C.
Проблема с tcpdump заключается в том, что для его выполнения требуются права администратора. Он должен возиться с сетевым интерфейсом, а затем извлечь все содержимое фрейма/пакета из операционной системы, чтобы отобразить его вам. В большинстве систем Linux вы можете получить временные административные разрешения с помощью sudo. Это позволяет программе, которую вы указываете sudo для запуска, выполняться с повышенными разрешениями на время выполнения программы. Вот как вы получите необходимые разрешения в Kali Linux, если они понадобятся.
Некоторые системы имеют несколько сетевых интерфейсов. tcpdump использует интерфейс по умолчанию. Это означает, что существует единственный интерфейс, через который отправляются все сообщения, если не указан другой интерфейс. Если нам нужно захватить другой интерфейс, мы просто сообщаем tcpdump, какой интерфейс мы хотим захватить, используя -i <имя_интерфейса>. Например, мы можем использовать эту команду для захвата интерфейса eth0, который является обычным интерфейсом в моих системах:
Возможно, нам потребуется определить интерфейсы. Мы можем сделать это, запустив либо ifconfig, либо, в некоторых более современных системах, ip a. Результаты сообщат нам IP-адрес, связанный с каждым интерфейсом, что должно помочь нам определить интерфейс, который мы хотим захватить.
Умение перехватывать пакеты является важным навыком. В дополнение к возможности видеть, что происходит во время любого тестирования безопасности, сеть является источником правды, когда речь идет о взаимодействии с любым удаленным приложением. Мы будем точно видеть, что отправлено или получено, независимо от того, что может показывать вам приложение. Также важно выполнять любые действия по устранению неполадок на уровне сети. Когда нам нужно захватить пакеты, tcpdump — хороший инструмент в вашем арсенале.
Хотя tcpdump отлично подходит как утилита для захвата пакетов общего назначения, вы также можете использовать программу tshark. Это программа командной строки, которая устанавливается вместе с Wireshark. Он делает то же самое, что и Wireshark, но с некоторыми дополнительными преимуществами. Однако сначала давайте посмотрим, как просто использовать tshark для захвата пакетов в стандартный вывод, чтобы вы могли увидеть, как это выглядит. Как и в случае с tcpdump, вам потребуются права администратора для захвата пакетов. Это можно сделать с помощью службы, которую можно установить в системе, чтобы позволить обычным пользователям перехватывать пакеты, или вы можете использовать команду sudo для получения повышенных привилегий во время запуска tshark. В нашем случае мы уже являемся пользователем root, поэтому нам не нужно повышать какие-либо привилегии. Мы можем просто запустить tshark, как вы видите здесь:
Как и в случае с tcpdump, если вам нужно указать интерфейс, вы можете использовать свич — i:
То, что мы увидели — это то, что мы увидим в том же выводе tcpdump. Могут быть небольшие отличия, но основная информация имеется. У нас есть информация об источнике и получателе, но с tshark мы получаем небольшую заметку о том, что содержит пакет, точно так же, как мы видим в информационном поле в Wireshark. Например, если бы мы собирали трафик для порта 443 (что, как мы увидим, будет выполняться в следующей команде), мы бы увидели информацию о хэндшейке, когда оно происходит во время настройки шифрования с использованием TLS. Как только соединение будет установлено, tshark сообщит вам, что каждый перехваченный пакет содержит данные приложения, потому что это все, что ему может быть известно. Он не может прочитать информацию внутри пакета, потому что он зашифрован. Это позволяет вам видеть, как происходит хэндшейк и когда зашифрованные данные передаются между клиентом и сервером. Мы не можем точно видеть, что происходит, но мы будем знать, что шифрование успешно установлено.
Как и в случае с tcpdump, tshark позволяет использовать фильтры пакетов Berkeley, поэтому язык, используемый для фильтрации перехвата, такой же, как мы использовали ранее. Это позволяет нам контролировать то, что мы захватываем. В контексте того, что мы только что сделали, это фильтр отображения, потому что ничего не сохраняется; все отображается на терминале. Вы можете заметить, что мы не получаем много подробностей… только основную информацию о заголовке и немного информации о том, что, по мнению tshark, содержит пакет. Мы можем увеличить уровень детализации, хотя это отличается от того, как это делается с помощью tcpdump. Если мы попытаться использовать ту же технику с tshark, но мы получим уже другой тип вывода, как вы можете видеть из результатов этой команды:
Вместо данных перехвата пакетов он просто содержит информацию о версии. Поэтому мы должны использовать заглавную букву V, чтобы получить детали, как вы можете видеть с помощью этой команды:
Это позволяет нам увидеть весь дамп пакета, включая шестнадцатеричный дамп полезной нагрузки. Мы также можем записывать пакеты в файл с помощью tshark с ключом -w (так же, как мы бы делали с tcpdump). Как и раньше, нам нужно указать имя файла, который мы хотим сохранить:
Расширение файла здесь .pcap, хотя это просто для удобства операционных систем, которые используют расширения файлов для прикрепления файлов данных к программам. Вы можете использовать любое расширение файла, а затем открыть файл, выполнив поиск в такой программе, как например Wireshark.
Поскольку tshark поставляется с Wireshark, он просматривает пакет таким же образом. Отличительной особенностью Wireshark является модульность пакетов. Мы начинаем с чего-то вроде IP-пакета или TCP-сегмента и можем детализировать отдельные элементы данных. Например, если мы хотим посмотреть исходный адрес IP-пакета, то мы должны использовать ip.src в своем языке фильтрации в Wireshark. Например, можно сказать, что ip.src == 4.2.2.1, и Wireshark будет сопоставлять все пакеты, исходный IPv4-адрес которых равен 4.2.2.1.
Мы можем использовать этот набор полей и в tshark. Существует большое количество полей, поэтому, если вы хотите увидеть, что можно использовать,то вы можете посетить https://www.wireshark.org/docs/dfref/, где вы найдете всю доступную информацию в списке.
Чтобы отображать только определенные поля в tshark, мы сообщаем программе, что собираемся установить собственный вывод на экран. Мы будем использовать свич -Tfields. Однако затем нам нужно указать поля, которые мы хотим отобразить на выходе. Мы могли бы сделать что-то простое, например просто показать исходный IP-адрес, как вы можете видеть здесь:
Однако это не особенно полезно. Просто просмотр исходного адреса мало что нам говорит, хотя он может дать вам возможность захватывать IP-адреса, которые вы можете использовать другими способами. Там, где синтаксический анализ вывода tcpdump может быть сложным, когда мы используем tshark, у нас есть контроль над тем, что мы видим. Если мы хотим увидеть немного больше, мы просто продолжаем добавлять -e в командную строку с дополнительными полями, которые мы хотим показать. Мы можем отобразить как исходный, так и конечный адреса с помощью этой команды:
Это немного лучше, хотя это все еще не намного. Вы, вероятно, хотите посмотреть на дополнительные детали. Это могут быть как IP-адреса, так и порты TCP, если они являются сегментами TCP. Возможно, лучший способ отобразить это — сохранить вместе адреса и порты, то есть адрес источника и порт, затем адрес назначения и порт. Поскольку мы указываем все поле от протокола вниз, это легко сделать:
По умолчанию мы получаем разделитель табуляции между полями, но это можно изменить. Мы можем указать выходные функции, используя -E, а затем символ, который мы хотим использовать. В случае с например запятой мы будем использовать следующую команду:
Умение перехватывать пакеты является важным навыком. В дополнение к возможности видеть, что происходит во время любого тестирования безопасности, сеть является источником правды, когда речь идет о взаимодействии с любым удаленным приложением. Вы будете точно видеть, что отправлено или получено, независимо от того, что может показывать вам приложение. Программа Wireshark — отличный инструмент для захвата и анализа пакетов. Пакет Wireshark включает утилиту командной строки tshark, которую можно использовать для захвата пакетов (которые затем можно сохранить и открыть позже в Wireshark для более глубокого анализа). tshark использует ту же философию и дизайн вывода, что и Wireshark, поэтому, если вы выполняете подробный захват, вывод будет выглядеть как простой текстовый дамп того, что вы видите в Wireshark. Кроме того, он делает много того же, что и tcpdump.
В заключение рекомендую обратить внимание на открытый урок, на котором разберем swap в Linux: что такое и зачем нужен, как он работает, какие данные в него уходят, за что отвечает параметр swappiness. В результате занятия у участников появится понимание структуры кеша в Lnux. Зарегистрироваться можно по ссылке.
Привет! Меня зовут Антон Седов, я DevOps-инженер и работаю в команде AGIMA. Мы с ребятами решили рассказать, как настраиваем Zero Trust Network Access через опенсорс-плагин Calico. Статей об этом не очень много, а у нас накопился опыт, которым хочется поделиться. Тут найдете полезную базовую информацию — на случай, если вообще про Calico не слышали. А если слышали — узнаете, как его настроить.
Что такое DevSecOps
В 2013 году методология DevOps начала объединять два мира: разработки ПО и его эксплуатации. Появились специалисты, которые хорошо понимали и программистов, и сисадминов. Они придумывали (или заимствовали) методологии и инструменты, которые автоматизировали решение типовых проблем в жизненном цикле ПО. Это позволило программистам не отвлекаться от написания кода, а системным инженерам — тюнить окружение для этого кода. Получилось неплохо.
Практики DevOps получили широкое распространение, многие проблемы разработки и эксплуатации получили свои Best Practice. Сейчас даже в маленьких командах процесс деплоя приложения настраивает отдельный специалист.
Девопсы по сей день продолжают искать способы сделать мир ПО лучше средствами автоматизации. В последнее время появилась амбициозная мысль: к мирам программистов и админов добавить третий — безопасников. Угроза для любого проекта, даже небольшого, — хакеры. Чтобы эффективнее им противостоять, рождается DevSecOps.
В сфере сетевой безопасности уже много хороших идей и инструментов, которые можно внедрять в нашу культуру и получать большой профит. Один из них — модель безопасности Zero Trust. Ее придумал Джон Киндерваг в 2010 году. А ее суть сводится к простой мысли: «Никому не доверяй, всегда проверяй».
Это логичное продолжение предыдущей и до сих пор доминирующей парадигмы безопасного периметра: «Не доверяй незнакомцам» или «Доверяй, но проверяй». Отныне все пользователи и ресурсы несут потенциальную угрозу причинения вреда нашему продукту.
Как устроен Zero Trust
Вершиной признания модели нулевого доверия стала публикация Белым домом меморандума о переводе всей критичной инфраструктуры государства на Zero Trust (ZT). Для решения этой задачи вокруг модели ZT национальный институт стандартов и технологий США (NIST) выстраивает архитектуру (Zero Trust Architecture или ZTA). Работа добралась до стадии предварительного проекта. Уже можно ознакомиться с тем, какие информационные системы мы будем строить в будущем.
В большой и сложной модели ZT выделились компоненты:
пользователи Zero Trust;
данные Zero Trust;
сети Zero Trust;
нагрузка Zero Trust;
устройства Zero Trust.
Каждый компонент — это точка фокуса вокруг уязвимого места любой сети и набор рекомендаций, как с ней работать. В этой статье сфокусируемся только на одном компоненте — сетях с нулевым доверием (Zero Trust Network Access или ZTNA).
Принципы Zero Trust Network Access
Четко сформулированных принципов ZTNA пока нет, но большинство аналитиков сходятся примерно в таких пунктах:
постоянный мониторинг и валидация сети;
присвоение наименьших возможных привилегий в сети;
нулевой дефолтный доступ к любому ресурсу в сети;
явное описание доступных коммуникаций в сети с помощью политик безопасности;
микросегментация сети (помните, нет более безопасного периметра);
мультифакторная авторизация.
Реализация всех пунктов в рамках сети любого предприятия превращается в сложнейшую задачу, решение которой пока только формируется. Но нам, девопсам, повезло: мы в своих проектах часто работаем с малыми сетями с небольшим числом узлов, управляемых одной технологией. И чаще всего в качестве такой системообразующей технологии используем Kubernetes. Для этой технологии задача построения ZTNA решаема уже сейчас.
Подходы к настройке ZTNA
Одна из стратегий решения задачи — использование Service Mesh. Эта технология — программный слой инфраструктуры, контролирующий сетевой трафик. На высоком уровне абстракции похоже на паттерн Middleware, присутствующий в большинстве фреймворков и любимый программистами.
Перехватываем весь трафик, анализируем его, блокируем ненужное, модифицируем по необходимости и пропускаем нужное. Внутри меши реализованы с использованием паттерна Sidecar. У разных Service Mesh работа проходит между третьим (сетевым) и четвертым (транспортным) уровнем OSI и/или на седьмом (прикладном). Мешей для k8s достаточно много: Istio, Linkerd, Consul. И все хорошо справляются с построением ZTNA.
Меши как технология разрабатывалась для приложений на микросервисной архитектуре и для проектов, где число под не исчисляется сотнями, могут оказаться оверхедом. Поэтому есть еще одна стратегия — это использование CNI (Container Network Interface) плагинов.
CNI — это набор спецификаций и библиотек для организации сетей на основе Linux-контейнеров. Плагины, написанные по спецификации, могут брать на себя полностью задачу по выделению ресурсов для построения сетей при появлении контейнера и освобождения ресурсов при его удалении. CNI используют Kubernetes, OpenShift, Amazon ECS, Apache Mesos и другие.
Для Kubernetes огромную популярность получил проект Calico. Он работает на третьем уровне OSI, может целиком взять на себя задачу построения сети внутри кластера, выдает отличную производительность и может решать большее число задач, чем мог бы Service Mesh.
Как построить ZTNA на основе Calico: шаг 0
Первым делом устанавливаем сам плагин. Для этого нужен простой конфиг.
# Устанавливаем Calico на k8s-кластер $ curl https://docs.projectcalico.org/manifests/calico-typha.yaml -o calico.yaml $ kubectl apply -f calico.yaml # Убеждаемся, что Calico установилось нормально $ kubectl get pods --all-namespaces | grep calico
Чтобы взаимодействовать с Calico, разработчики предоставили нам инструмент Сalicoctl. Ставим и его. Для удобства вызова инструмента лучше сразу сделать алиас. Перезапускаем шелл и проверяем, что Calicoctl работает.
Важным инструментом обеспечения безопасности в сети являются сетевые политики. Они позволяют гибко настраивать все аспекты обмена пакетами между хостами в вашей сети. У Kubernetes есть свой набор политик, которые можно применять к неймспейсам, управлять трафиком между подами, разрешать и блокировать трафик согласно правилам по протоколам, именованным портам или номерам портов. Calico имплементирует все политики «Кубера» и дополняет их своими.
Политики Calico имеют примерно тот же функционал, что и «куберовские». Но они немного удобнее и более гибкие. С ними появляется возможность управлять трафиком глобально с помощью GlobalNetworkPolicy — особого ресурса Calico, который создает корневую политику для всех сетевых соединений в кластере. Комбинировать оба набора политик можно как вам угодно.
Структура политик очень проста, интуитивно понятна и легко читается. Основные сущности, с которыми мы в них работаем, это неймспейсы, селекторы и правила. Все они отлично описаны в документации Calico. Это очень гибкие инструменты. Они позволяют описать любой трафик как внутри кластера, так и коммуникации с внешним опасным миром.
Как построить ZTNA на основе Calico: шаг 1
Теперь у нас есть все знания и инструменты, необходимые для наведения порядка в стиле ZTNA. Следующий шаг — воплощение Zero Trust: запрещаем весь трафик. Мы ведь никому не доверяем.
$ calicoctl apply -f - < default-traffic-block.yaml # Проверяем, что политика применилась $ calicoctl get gnp
Как всегда, есть нюансы. Если применить этот конфиг на боевом кластере, всё сломается, так как честно блокируется весь трафик, включая DNS. Поды «потеряют» друг друга. Разработчики предлагают нам чуть другой конфиг, который открывает подам 53 порт. Похоже, это хороший компромисс, а не отступление от принципов ZTNA, где каждому ресурсу нужно прописывать вручную политики безопасности. Будем считать это следованием принципу Don’t Repeat Yourself из мира разработки.
Этот шаг надо провести итерационно со всеми подами всех проектов в кластере. Сначала выявить назначение пода с всеми внешними и внутренними интеграциями. Затем для каждой интеграции:
выяснить протокол и порт, по которой она живет;
написать NetworkPolicy для Ingress (входящего трафика) и для Egress (исходящего трафика).
Рассмотрим этот алгоритм на примере веб-приложения. Я привык при работе везде, где это возможно, получать какую-то визуальную информацию о работоспособности системы. Даже если это информация ошибки в консоли браузера или логах сервера. Поэтому давайте начнем разрешать трафик с фронтовой поды.
Отступление! Для написания политик важно, как ваши поды организованы в неймспейсы. А еще наличие лейблов у ваших подов. Мы выбрали для себя схему организовывать поды по признаку окружения: develop, staging, production. Также к каждому поду добавляется лейбл role с описанием функции, которой он выполняет (front, back, database и т. д.). Какую схему именования неймспейсов выбрать не принципиально, но важно, что без этого массовые операции типа присваивания политик безопасности будут затруднены.
На фронте у нас SPA, который раздает nginx. Значит, логично открыть http-порты. Вот так может выглядеть примерный конфиг:
Открываем браузер, проверяем. Заработало? Вряд ли. У нас точно нет.
Загвоздка простая: перед фронтом стоит Ingress Controller, которому мы тоже весь трафик отрубили. Дублируем конфиг меняя неймспейс на namespace: ingress-nginх, а селектор — на name == ‘ingress-nginx’. Вот теперь заработало.
Дальше видим сообщения об ошибке от SPA о том, что бэкенд молчит. Открываем бэкенд — он жалуется на базу данных, Redis и так далее. Работа с этими задачами ничем не отличается от работы с фронтом, и конфиги будут очень похожими.
Конечно, приведенные примеры простые. У Calico есть еще много более продвинутых способов решения задачи построения ZTNA. Но для них придется проштудировать доки Calico и, может быть, «Кубера», если вы еще не добрались там до политик безопасности.
Приятный бонус от использования K8s и Calico — в очень хорошей переносимости между проектами. Написав один раз конфиги, мы можем переиспользовать их и не решать эту задачу снова и снова.
Вместо послесловия
Индустрии понадобилось 12 лет, чтобы согласиться на такой уровень паранойи. Слишком много громких утечек персональных данных и резонансных взломов прошло в последнее время. И при этом с распространением облаков и контейнеризации, всё меньше мы контролируем инструменты, с которыми работаем.
Вспомните, как долго сетевые инженеры сопротивлялись внедрению докера в рабочие процессы. Уже не мы конфигурируем операционную систему, не мы ставим там критически важные для работы пакеты. Со временем это успокоилось, появлялись образы, создаваемые вендорами, сканеры, проверяющие образы слой за слоем. Мы сами научились создавать свои образы.
Однако теперь образы крутятся в «кубере», который может стать вектором атаки. «Кубер» может работать в облаке, которое тоже может быть уязвимо. При этом вся ответственность за проект целиком на нас. Исходя из всего этого, мы считаем, что модель Zero Trust позволяет нам значительно снизить риск оказаться жертвой атаки для наших клиентов и внедряем ее в наши процессы девопса.
Рассказывайте в комментариях, как вы обеспечиваете безопасность проектов. Если есть вопросы — задавайте. Буду рад ответить.
Несмотря на появление многочисленных мессенджеров, именно рассылка по email на сегодняшний день является наиболее недорогим способом отправки информации, а учитывая то, что электронные письма поддерживают вложения в виде файлов и встраивание HTML-скриптов, именно email крайне часто используется для рассылки спама. Помимо очевидных рисков для информационной безопасности предприятия, спам также создает значительную нагрузку на почтовый сервер, а в случае попадания его в почтовый ящик пользователя, он начинает занимать место в хранилище данных почтового сервера, а деловое письмо может попросту затеряться в бесполезном спаме. Для фильтрации спама в Carbonio используется SpamAssassin — одно из наиболее продвинутых решений для фильтрации почты, однако при неправильной настройке SpamAssassin может принести вред — заблокировать важное письмо или пропустить потенциально опасный email. В данной статье мы расскажем о том, как администратор может настроить SpamAssassin.
Данная инструкция может быть применена как к коммерческой версии Carbonio, так и к бесплатной Carbonio Community Edition.
SpamAssassin устанавливается вместе с Carbonio и включен по умолчанию. Он начинает фильтровать входящую почту сразу же на основании встроенных в него словарей. Принцип работы SpamAssassin прост — каждое входящее почтовое сообщение подвергается целой серии проверок и при прохождении каждой из них письму присваиваются спам-баллы. К примеру, если письмо начинается со слова Dear, SpamAssassin автоматически добавляет ему один спам-балл. То же самое происходит в случаях, когда письмо содержит и другие характерные для спам-рассылок признаки. Существуют и проверки, при прохождении которых спам-баллы вычитаются. Однако изначально SpamAssassin нацелен на распознавание англоязычного спама и для того, чтобы он работал с русскоязычными сообщениями необходимо “обучить” его, а также добавить русскоязычные словари.
На данный момент русскоязычные словари для SpamAssassin разрабатываются и поддерживаются компанией Wentor. Скачать их можно по данной ссылке.
Установка данных словарей производится следующим образом. Необходимо скопировать скачанный файл в папку /opt/zextras/data/spamassassin/rules. Цифра 99 в начале файла означает приоритет использования данного словаря. Благодаря этой цифре проверки из русскоязычного словаря будут использоваться в первую очередь.
После этого добавьте в файл /opt/zextras/conf/salocal.cf.in строчку с упоминанием данного словаря.
include /opt/zextras/data/spamassassin/rules/99_wentor.cf
Перезапустите сервер, чтобы внесенные изменения вступили в силу.
Правила можно писать и самому. Для их добавления отредактируйте файл nano /opt/zextras/data/spamassassin/localrules/local.cf и добавьте в них подобные регулярные выражения.
1. Для проверки заголовков писем используйте header
describe HEADER_SUSPICIOUS Bad Word in the Subject
Здесь мы создаем правило HEADER_SUSPICIOUS, которое проверяет наличие в теме письма слов “распродажа” и “ограниченное”, характерных для спам-рассылок. Также мы указываем, сколько спам-баллов получит письмо с такими словами, а также описание правила
2. Для проверки тела письма используйте body
body BODY_SUSPICIOUS /, скидка/i
score BODY_SUSPICIOUS 1.5
describe BODY_SUSPICIOUS Bad Word in the Body
Здесь мы создаем правило BODY_SUSPICIOUS, которое проверяет наличие в теле письма слова скидка, характерное для спам-рассылок. Также мы указываем, сколько спам-баллов получит письмо, провалившее данную проверку.
Однако русскоязычные словари и составленные самостоятельно проверки для SpamAssassin хоть и являются действенным способом для фильтрации спама, они не могут гарантировать полное отсутствие нежелательных писем. Именно поэтому требуется также провести тренировку в SpamAssassin.
SpamAssassin поддерживает Байесовское машинное обучение, то есть ему можно вручную указывать на те письма, которые он ошибочно принял за спам, а также те письма, которые он ошибочно не распознал как спам. На основе этих писем он автоматически формирует алгоритмы, которые будут использоваться впоследствии для фильтрации спама.
Контролировать данный процесс можно при помощи служебных почтовых ящиков spam и ham. Они создаются при установке Carbonio, а их имена намерено обфусцируются случайным набором букв и цифр. Письма, попавшие в спам и перемещенные пользователем в другую почтовую папку, автоматически перенаправляются в почтовый ящик ham, а письма, которые попали в почтовую папку и затем были перемещены пользователем в спам, перенаправляются на почтовый ящик spam.
Процесс обучения заключается в том, чтобы поместить в соответствующие почтовые ящики письма, которые заведомо являются спамом и которые заведомо им не являются. Нормальным количеством считается загрузка 200 писем в каждый из служебных почтовых ящиков. Для импорта писем вы можете воспользоваться нашей инструкцией по загрузке данных из Outlook в Carbonio.
Отметим, что в служебные почтовые ящики попадают также и те письма, которые пользователь пометил как спам или удалил из папки со спамом, в почтовом клиенте, подключенном по IMAP.
Правила, которые формируются в результате обучения SpamAssassin можно резервировать. Делается это при помощи команды вида /opt/zextras/common/bin/sa-learn —dbpath /opt/zextras/data/amavisd/.spamassassin —backup >> /tmp/sa.db. После выполнения данной операции все правила будут сохранены в файл /tmp/sa.db. Восстанавливается резервная копия с помощью той же утилиты /opt/zimbra/common/bin/sa-learn —dbpath /opt/zimbra/data/amavisd/.spamassassin —restore /tmp/sa.db. После восстановления резервной копии необходимо перезапустить Carbonio.
Прохождение проверок SpamAssassin фиксируется в логах Carbonio, а также в полях электронного письма. Для того, чтобы просмотреть информацию о прохождении проверки на спам в полях письма, выберите его в веб-клиенте Carbonio и просмотрите содержимое его полей при помощи опции “Показать оригинал”.
В открывшемся окне поля с наименованиями X-Spam-Flag, X-Spam-Score, X-Spam-Level и X-Spam-Status будет указана подробная информация о результатах проверки SpamAssassin.
Основным объектом настройки в SpamAssassin является порог баллов, при которых SpamAssassin признает письмо спамом. Данных порогов два. При достижении первого, который обычно ниже, письмо помечается как спам и отправляется в папку “Спам” адресата. При достижении второго, который обычно значительно выше, письмо помечается как спам и попросту удаляется.
Регулировать данные пороги можно из командной строки. Для изменения верхнего порога используется команда carbonio prov mcf zimbraSpamKillPercent 75. Для изменения нижнего порога carbonio prov mcf zimbraSpamTagPercent 20. Также имеется возможность изменить подпись, которая добавляется в тему письма, распознанного как спам, например carbonio prov mcf zimbraSpamSubjectTag «!!!SPAM!!!».
Обратите внимание на то, что пороги регулируются в процентах, а спам-баллы начисляются в абсолютных цифрах. Для того, чтобы перевести проценты в спам-баллы просто умножьте их на 0,2. В нашем случае пороги задаются в размере 4 и 15 спам-баллов.
Carbonio также поддерживает черные и белые списки, причем как на уровне пользователя, так и на уровне домена. Пополнить их можно при помощи следующих команд:
Для пополнения белого списка пользователя zextras@domain.ru пользователем ham@domain2.ru
carbonio prov ma zextras@domain.ru +amavisWhitelistSender ham@domain2.ru
Для исключения из белого списка пользователя zextras@domain.ru пользователя ham@domain2.ru
Отметим, что антиспам, наравне с антивирусом является одним из основных потребителей системных ресурсов. Поэтому, если вы используете внешний сервер для фильтрации спама, вы можете отключить его при помощи команды carbonio prov ms mail.domain.ru -zimbraServiceEnabled antispam. Включить антиспам вновь можно при помощи команды carbonio prov ms mail.domain.ru +zimbraServiceEnabled antispam.
По вопросам тестирования, приобретения, предоставления лицензии и консультаций обращаться на почту sales@svzcloud.ru к эксклюзивному партнеру Zextras.
