Я планирую опубликовать серию сообщений в блоге с рассказом о самом интересном, что появилось в новой версии продукта. Сейчас вы можете почитать на сайте .
В этом сообщении я расскажу о новом модуле "" и о том, что принципиально меняется с появлением этого модуля.
Я так давно искал пути создания инструмента, который помог бы нам принципиально усилить безопасность веб-приложений, разработанных клиентами. И "Проактивная защита" стала продолжением многолетней работы компании поиску решений и обеспечению безопасности интернет-проектов. Пожалуй, впервые нам удалось настолько существенно усилить защищенность сайтов и снизить зависимость клиентов от наиболее частых ошибок веб-разработчиков.
"Проактивная защита" - это принципиально новый подход к концепции веб-безопасности, при котором меняется само понятие реакции веб-приложения на попытки вторжения. Новый модуль "Проактивная защита" включает в себя:
* Проактивный фильтр (Web Application Firewall), обеспечивающий защиту от большинства известных атак на веб-приложения. Проактивный фильтр распознает опасные угрозы и блокирует вторжения на сайт. Это наиболее эффективный способ защиты от возможных ошибок, допущенных при реализации интернет-проекта (XSS, SQL Injection, PHP Including и ряда других);
* технологию одноразовых паролей (One Time Password - OTP) реализована на базе электронных ключей Aladdin eToken PASS для обеспеч аутентиф польз-ля при доступе на сайт, которая позволяет быть однозначно уверенным, что на сайте авторизуется именно тот человек, которому выдали брелок;
* панель безопасности с оценкой уровней безопасности веб-проекта;
* защиту авторизованных сессий с хранением сессий в базе данных и регулярной сменой идентификатора, привязкой к IP;
* контроль активности, который позволяет защититься от ряда категорий DDoS атак на веб-приложение и выделить автоматизированные скрипты и заблокировать их работу на установленное время;
* журнал вторжений, в котором ведется запись попыток внедрения SQL, атак через XSS и внедрения PHP;
* защиту административных разделов по IP с простым интерфейсом, который позволяет указать список IP-адресов или диапазоны адресов, с которых можно управлять сайтом;
* стоп-листы для блокировки доступа пользователей к сайту;
* контроль целостности, который проверяет скрипт контроля целостности системы на наличие изменений;
* Шифрование канала передачи через SSL
* рекомендации по настройке системы безопасности.
Новый модуль "Проактивная защита" включен во все редакции продуктов "1С-Битрикс: Управление сайтом", кроме редакции "Старт"), а также в продукт "1С-Битрикс: Корпоративный портал". Для клиентов модуль уже доступен через систему обновлений .
Я рекомендую клиентам и партнерам обновить сайты и установить себе Стандартный или Высокий уровень безопасности.
Прежде чем рассказать подробнее о возможностях модуля, несколько слов о проблематике и истории развития вопроса.
[spoiler]
Проблематика
Производственный цикл у нас по выпуску нового функционала для продуктов состоит из следующих этапов:
1. Тестирование разработчиками на внутренних серверах с разными базами данных, операционных систем, версиями PHP и т.п.
2. Отдел тестирования проверят на соответствие бизнес-функциональности и наличие ошибок
3. Отдел безопасности проверят на наличие уязвимостей
4. Начало бета-тестирования партнерам и клиентами
Большинство разработчиков в нашей компании работает уже по 5-8 лет и можно сказать, что ребята очень хорошо обучены и натренированы в вопросах безопасности. Т.е. как тезис я бы сказал, что мы располагаем наиболее квалифицированными веб-разработчиками с прекрасными знаниями вопросов безопасности.
Но, несмотря на это, отдел безопасности регулярно находит потенциальные уязвимости и возвращает модули на доработку.
Мы с Юрой Тушинским, техническим директором, как-то обсуждали эту ситуацию. Почему тезис "обучение веб-разработчиков безопасности" не дает полной уверенности в качестве разработки?
Ответ довольно просто формулируется - разная психология. Разработчик думает как решить бизнес-задачу быстро, эффективно, сделать производительно, удобно для пользователя, совместимо и другие аналогичные аспекты. Хакер думает совсем в другом векторе: как сломать, как подменить данные, что сделать с плохой обработкой ошибок, как злоупотребить....
Юра рассказывал, что он сам после 3 недель работы по теме безопасности потом не может начать нормально программировать довольно долго, голова думает совсем не о разработке...
Получается, что обычный цикл производства программного продукта обязательно должен включать в себя специалиста по безопасности, который думает только о том, как сломать продукт и обойти защиту. На основании этого вывода начиная с версии 4.0 в нашей компании появился отдел безопасности и нам удалось поднять качество производства в вопросах безопасности на очень высокий уровень.
Но это у нас в компании, мы все же специализируемся на разработке продукта. А что же происходит в компаниях веб-разработчиков? Я знаю сегодня всего пару компаний, у которых в штате есть специалист, разбирающийся в безопасности. Но при этом, он не работает как безопасник, а только изредка подключается к проектам для проверки безопасности, а основное время он работает обычным веб-разработчиком.
Следовательно, можно предположить, что в разработках на базе продукта теоретически должны быть потенциальные уязвимости. И это не потому, что веб-разработчики плохие. Это потому, что так устроена жизнь, отличается психология.
Еще одна проблема - на безопасность клиенты никогда не дают деньги. А если клиенты и дают деньги, то компаниям сложно найти специалистов и содержать их на нерегулярных контрактах.
Напомню статью по этой проблематике Алексея Лукацкого -
В общем, получается - безопасность через незнание.
1:100
Стоит отметить, что веб-разработчику требуется очень много времени и системное обучение, чтобы стать хорошим специалистом по разработке безопасных веб-приложений. Причем достигает он высокого уровня, только если его приложения проходят критическое тестирование на безопасность.
А вот хакеру не требуется долгого обучения, чтобы воспользоваться классическими и самыми массовыми уязвимостями веб-приложений, такими как XSS, SQL Injection, PHP Including... И проверить свои знания он может с легкостью на любом сайте. Более того, есть инструменты для автоматизированного поиска уязвимостей на сайтах.
Я бы охарактеризовал соотношение квалифицированных веб-разработчиков к хакерам как 1:100. Опять же, не поймите это как укор. Так получается, что рядовой веб-разработчик начинает глубоко вникать в вопросы безопасности только когда впервые сталкивается с проблемами.
Безусловно, к угрозам безопасности необходимо относить не только веб-приложений, но и угрозы безопасности Информационной среды. Подробнее я писал на нашем сайте:
Поиск решений
1. Безопасность среды разработки.
Учитывая положение вещей мы старались сделать Bitrix FrameWork максимально устойчивым и проверенным по безопасности.
API функции делались безопасными, стандартные инструменты по работе с переменными многократно проверялись и страховали разработчика от большинства типовых ошибок. Потенциально опасные действия собирались в классы и экранировали веб-разработчиков от необходимости думать о безопасности. Так работа с файлами, которая несет в себе массу угроз, собрана в отдельные классы, многократно контролируемые по безопасности. Политика безопасности групп пользователей защищала пароли и запоминанемые хэш функции от похищения. Привязки авторизованных сессии к IP, единая авторизация на всех проектах, трехуровневая система разграничения прав, CAPTCHA и масса других решений.
Все это было и есть в продукте. И я думаю, что нам удалось всеми этими действиями очень сильно поднять уровень защищенности и качество разработки приложений написанных на базе Bitrix Framework.
Но это не дает 100% защиты. Веб-разработчик теоретически может проигнорировать рекомендованные функции, взять переменную прямо из запроса, без обработки вставить в запрос к базе данных и получить одновременно и SQL Injection и эксплуатируемый XSS. И тогда все усилия оказываются напрасными, человеческий фактор сводит на нет усилия.
2. Аудит безопасности
Как вариант мы некоторое время рассматривали направление платных аудитов безопасности.
Наш отдел безопасности выполнял аудит безопасности по запросам крупных клиентов и партнеров. Очень интересная практика и ценнейшие данные для анализа!
Но невозможно проверить такое большое количество сайтов, бизнес-логики и решений партнеров. На одном клиенте можно было "застрять" на 1-2 месяца и даже не проверить все, а параллельно разработчики выпускают новые доработки и их опять нужно проверять
Мощности по проверке у нас незначительные, это не основная для нас деятельность. Наращивать объем оказания услуг нет возможности.
В итоге, услуга аудит-безопасности не получила широкого тиражирования и была снята с продажи.
Мы решили изменить направление развития по теме безопасности. И стали искать решения, которые могли бы помочь всем партнерам и клиентам в равной степени.
Проактивная защита
Такое длинное вступление я сделал, чтобы вы лучше поняли, почему мы выбрали направление по разработке модуля и какие мы ставим перед собой задачи, в чем мы надеемся помогать веб-разработчикам и клиентам.
Для себя мы определили модуль "Проактивной защиты" как комплекс технических решений по обеспечению безопасности продукта и разработанных веб-приложений, включающий несколько уровней защиты от большинства известных атак на веб-приложения, существенно повышающий уровень безопасности интернет-проектов.
"Проактивная защита" является важным дополнением к стандартной политике безопасности продукта. Выше я перечислил состав модуля.
Проактивная защита: панель безопасности и оценка уровня безопасности
Несмотря на сложность темы безопасности, мы ставили перед собой задачу сделать функционал модуля доступным для работы обычными пользователям. Нам кажется важным, чтобы клиенты и партнеры понимали, что происходит на сайте и каким уровнем защищенности они располагают.
Мы реализовали панель безопасности на которой все возможности модуля сгруппированы в уровни: Начальный, Стандартный, Высокий, Повышенный
Начальный уровень безопасности получают проекты на базе Bitrix Framework без установленного модуля Проактивной защиты. Это был тема большой дискуссии внутри компании, почему так называть и почему такой уровень. И все же мы решили, что так как партнеры не проверяют свои разработки на безопасность, клиенты иногда не устанавливают обновления продукта, мы будем ставить Начальный уровень безопасности.
Стандартный уровень безопасности получают проекты с включенными элементами проактивной защиты:
Проактивный фильтр (Web Application FireWall) на весь сайт без исключений, включен Контроль активности, ведется журнал вторжений. Уровень безопасности для группы Администраторы должен быть установлен в Повышенный.
Напомню, какие параметры там устанавливаются:
* Время жизни сессии (минут)
* Маска сети для привязки сессии к IP
* Максимальное количество компьютеров на которых может быть одновременно быть запомнена авторизация
* Маска сети для привязки сохраненной авторизации
* Срок хранения авторизации, запомненной на компьютере пользователя (минут)
* Срок действия контрольного слова для восстановления пароля (минут)
* Минимальная длина пароля
* Пароль должен содержать латинские символы верхнего регистра (A-Z)
* Пароль должен содержать латинские символы нижнего регистра (a-z)
* Пароль должен содержать цифры (0-9)
* Пароль должен содержать знаки пунктуации (,.<>/?;:'"[]{}\|`~!@#$%^&*()-_+=)
* Количество попыток ввода пароля до показа CAPTCHA (защита от перебора)
Все эти правила устанавливаются в настройках группы пользователей и включаются в ядро продукта.
Мы так же посчитали важным, чтобы на сайте был включен параметр "Использовать CAPTCHA при регистрации". Режим вывода ошибок (error_reporting) был установлен в Только ошибки, чтобы не раскрывать информацию о конфигурации системы.
В дальнейшем мы планируем в уровне Стандартный добавить проверку на наличие рекомендованных и не установленных обновлений продукта, защиту редиректов от фишинга.
Высокий уровень безопасности получают проекты выполнившие требования Стандартный плюс:
* включившие Журналирование событий главного модуля
* установившие Защиту административной части по IP
* включивших Хранение сессий в базе данных
* и Смену идентификатора сессий
В дальнейшем, в уровень Высокий попадут проверки включенного SSL сертификата для авторизации и работы с продуктом.
Повышенный уровень безопасности можно будет получить, включив в дополнение к Высокому уровню защиту одноразовыми пароля (OTP) для администраторов, Контроль целостности и еще ряд параметров (уточняются).
Теперь немного подробнее о функционале.
Проактивный фильтр (Web Application Firewall)
Проактивный фильтр (Web Application Firewall*) - обеспечивает защиту от большинства известных атак на веб-приложения. В потоке внешних запросов пользователей проактивный фильтр распознает большинство опасных угроз и блокирует вторжения на сайт.
Проактивный фильтр (Web Application Firewall) – наиболее эффективный способ защиты от возможных ошибок безопасности, допущенных при реализации интернет-проекта (XSS, SQL Injection, PHP Including и ряда других).
По данной теме рекомендую посмотреть следующие ссылки:
Чаще всего такие решение разрабатываются и устанавливаются выше веб-приложения в виде аппаратных устройств или модулей для веб-сервера, как например ModSecurity. Но в большинстве своем это требует сложного администрирования, не позволяет работать на уровне приложения, зачастую делает само приложение неработоспособным... Так же это невозможно подключить на виртуальном хостинге.
Мы доработали концепцию и нашли вариант включения Web Application Firewall непосредственно в продукт. Фактически, фильтр проверяет на каждом хите все данные, которые могут поступить на сайт через переменные GET, POST, куки, серверные переменные. Возможно несколько видов реакции на попытку вторжения:
1 Сделать данные безопасными
2 Очистить опасные данные
3 Добавить IP-адрес атакующего в стоп-лист на ХХ минут.
Сделать данные безопасными означает, что данные будут модифицированы. Например "select" будет заменен на "sel ect", а "<script>" на "<sc ript>". Ну не понимайте буквально, но, в общем, примерно так
По умолчанию сайт будет менять данные, чтобы вызвать наименьшее неудобство для пользователей. Обратите внимание, что некоторые действия пользователей, не представляющие угрозы, тоже могут выглядеть подозрительно и вызывать ложное срабатывание фильтра. По нашим расчетам, число ложных сработок будет минимальным. Пока идет обкатка и фильтр дорабатывается, например сегодня была доработка фильтра для англоязычных клиентов. На этой неделе мы выпустили уже два обновления фильтра, усилив защиту и уменьшив число ложных срабатываний. В дальнейшем обновления фильтра будут выходить регулярно по технологии SiteUpdate.
Рекомендуется включить Проактивный фильтр для стандартного уровня.
Журнал вторжений
В случае если Проактивный фильтр срабатывает, в системном журнале появляется запись в одной из трех категорий безопасности.
Сегодня мы выделяем три категории атак:
* Попытка внедрения SQL
* Попытка атаки через XSS
* Попытка внедрения PHP
За неделю на нашем сайте фильтр сработал больше 5000 раз!
Большинство записей в журнале относится к роботам, которые автоматическим образом ищут уязвимости на сайте. Но часть записей показывает, что идет ручной поиск XSS или SQL уязвимостей.
Попалось несколько и ложных срабатываний. Я уже отмечал выше, что выпускаются улучшение фильтра, надеемся исключить неверные срабатывания фильтра.
Одноразовые пароли
Модуль Проактивной защиты позволяет включить поддержку одноразовых паролей и использовать таковые выборочно для любых пользователей на сайте.
Данная технология позволяет быть однозначно уверенным, что на сайте авторизуется именно тот человек, которому вы выдали брелок. Похищение и перехват паролей теряет смысл, так как пароль одноразовый. Человек не может передать пароль другому человеку и при этом продолжить сам пользоваться входом, так как брелок физический и дает уникальные одноразовые пароли только при нажатии.
Система авторизации с использованием одноразовых паролей (One-Time Password - OTP) разработана в рамках инициативы .
Реализация основана на алгоритме HMAC и хэш-функции SHA-1. Для расчета значения OTP принимаются два входных параметра - секретный ключ (начальное значение для генератора) и текущее значение счетчика (количество необходимых циклов генерации). Начальное значение хранится как в самом устройстве, так и на сайте после инициализации устройства. Счетчик в устройстве увеличивается при каждой генерации OTP, на сервере - при каждой удачной аутентификации по OTP.
Партия устройств OTP поставляется с зашифрованным файлом, содержащим начальные значения (секретные ключи) для всех устройств партии, связанного с серийным номером устройства (печатается на корпусе устройства).
В случае нарушения синхронизации счетчика генерации в устройстве и на сервере, её можно легко восстановить - привести значение на сервере в соответствие значению, хранящемуся в устройстве. Для этого администратор системы или сам пользователь (при наличии соответствующих разрешений) должен сгенерировать два последовательных значения одноразовых паролей (OTP) и ввести их в форму на сайте.
Система дополняет стандартную систему авторизации и позволяет значительно усилить систему безопасности интернет-проекта. Для включения системы необходимо использовать аппаратное устройство (например, ) или использовать соответствующее программное обеспечение, реализующее . Система одноразовых паролей рекомендуется к использованию администраторам сайтов для повышения уровня безопасности.
Как пользоваться
При включении системы одноразового пароля, этот пользователь сможет авторизоваться только с использованием своего имени (login) и составного пароля, состоящего из пароля и одноразового пароля устройства (6 цифр). Одноразовый пароль (см. 2 на рисунке) вводится в поле "Пароль" стандартной формы авторизации на сайте сразу после обычного пароля (см. 1 на рисунке) без пробелов.
Расширенная аутентификация с одноразовым паролем начнет работать после ввода секретного ключа и двух последовательно сгенерированных одноразовых паролей, полученных с устройства.
Инициализация
При инициализации или повторной синхронизации устройства с пользователем необходимо заполнить два последовательно сгенерированных одноразовых пароля, полученных с устройства.
Обратите внимание, что в настройках одноразовый защиты можно указать "Размер окна проверки паролей". По умолчанию указано 10. Это означает, что если ваш ребенок нажмет на кнопку брелка и получит больше 10 паролей, вам придется идти к администратору сайта и опять проводить инициализацию.
Мы отнесли поддержка OTP к категории Повышенная защита. Я так же не исключаю, что в скором времени будут найдены или написаны приложения для мобильных телефонов реализующие OTP в более простом варианте использования.
Ограничение доступа к административной части по IP
Очень часто компании строго регламентируют сети, которые считают безопасными и из которых разрешают сотрудникам администрировать сайт.
Мы разработали специальный простой интерфейс, который позволяет вам указать список IP адресов или диапазоны адресов из которых можно управлять сайтом. Система проверяет, чтобы вы не закрыли себе доступ в момент установки блокировки. Но вообще при желании вы можете допустить и такую ошибку
на этот случай загляните в настройки модуля Проактивной защиты. Там вы найдете путь к файлу-флажку запрета блокировки по IP. Для каждого проекта это уникальное имя файла.Настроив такой вариант вы сможете просто и очень эффективно защитить папку /bitrix/admin/ от доступа извне ваших сетей.
Настройка требуется для получения уровня безопасности Высокий.
Защита сессий
Большинство атак направлены на похищение авторизованной сессии пользователей и в особенности администраторов.
Выше я отмечал, что мы в базовой поставке защищаем сессии следующими способами:
* Время жизни сессии (минут)
* Маска сети для привязки сессии к IP
Настраивается это в группах пользователей в политике безопасности.
Привязка сессии к IP или подсети пользователя делает похищение сессии крайне проблематичным. Но не всегда такие строгие настройки удается ввести.
Мы реализовали еще два инструмента защиты сессий.
Защита сессий: Хранение в базе данных
Хранение данных сессий в таблице модуля позволяет избежать чтения этих данных через скрипты других виртуальных серверов, исключив ошибки конфигурирования виртуального хостинга, ошибки настройки прав доступа во временных каталогах и ряд других проблем настройки операционной среды. Кроме того, это разгружает файловую систему, перенося нагрузку на сервер базы данных.
Рекомендуется включить для высокого уровня.
Защита сессий: Смена идентификатора
У каждой сессии есть идентификатор который передается при каждом запросе к серверу в куках.
При включении смены идентификатор сессии пользователя начнет изменятся через заданный промежуток времени. Это создает дополнительную нагрузку на сервер, но позволяет сделать похищение делает похищение авторизованной сессии неэффективным.
Механизм пробный и уникальный. На нашем сайте я включил его и пока надежность не вызвала нареканий.
Необходимо включить для высокого уровня.
Оба механизма защиты сессий в сочетании со стандартными возможностями позволят надежно защитить авторизованную сессию администратора.
Контроль активности
Данный инструментарий внесен в модуль Проактивной защиты из модуля Веб-аналитики. Так случилось, что часть инструментов появилась в продукте там, где могла быть реализована. Сегодня эти инструменты плавно переводятся в модуль Проактивной защиты.
Сайты зачастую подвергаются DDoS атакам, по ним ходят интенсивные автоматизированные роботы, которые извлекают контент, спамят и всячески подстраиваются под посетителей...
Пока их активность не очень высока, на них не обращают внимание. Но вот с активными уже нужно бороться. И как раз для этого предназначен контроль активности.
В параметрах Контроля активности вы можете установить порог нормальной для человека активности. У нас по умолчанию стоит порок в 15 хитов на 10 секунд. Проверенная временем характеристика позволяет выделить автоматизированные скрипты и заблокировать их работу на установленное время.
В течение времени блокировки пользователю будет выдаваться 503 ответ сервер, т.е. сервер занят и не может обрабатывать запросы. Все остальные пользователи смогут работать с сайтом совершенно нормально.
Данная характеристика подобрана таким образом, что поисковые роботы под нее не попадают.
Стоит обратить внимание, что в случае срабатывания системы Контроль активности в журнал событий будет добавлена соответствующая запись. Вы сможет увидеть кто и по каким причинам был заблокирован.
Не все составляющие модуля я описал. Итак статья получилась очень большой.
Подробнее о модуле вы можете и установить на своем сайте.
Ценная вещь. Серьезно.
Но обязательно почитаю. Спасибо, Сергей, за подробное описание.
Допустим робот интенсивно дергает сайт на наличие уязвимостей. Делает инъекции, xss и прочее. Помимо потенциальной опасности он создает существенную нагрузку.
Так вот, после того как он (робот) добавился в стоп-лист, где его отсекать будут? На каком уровне системы? И не будет ли он создавать все ту же дополнительную нагрузку?
Я к тому что динамический стоп-лист это конечно здорово, но если робот делал по несколько хитов в секунду, то он и после бана будет делать те же несколько хитов в секунду. А это ощутимая нагрузка.
Не проще ли подумать в сторону "динамического" htaccess, где бы прописывалось:
Deny from ******
И этот файлик бы подрубался в самом начале (так как в стандартный .htaccess внедриться нельзя (кстати, а почему бы и нет?).
Просто в моем понимании самых злостных спамеров надо банить на уровне htaccess, чтобы их посылал куда подальше сам сервер, а не скрипт на сервере.
Так вот, после того как он (робот) добавился в стоп-лист, где его отсекать будут? На каком уровне системы? И не будет ли он создавать все ту же дополнительную нагрузку?
Пользователь блокируется в самом начале работы продукта, по сути, еще до ядра. Нагрузки не будет, базе не подключается для блокирования.
Deny from ******
И этот файлик бы подрубался в самом начале (так как в стандартный .htaccess внедриться нельзя (кстати, а почему бы и нет?).
Ну по сути так и есть. Но перекладывать на Apache мы не считаем возможным, да и не всегда это возможно на хостинге.
Просто если какого-то конкурента начнут ддосить (а обычно ддос - это инструмент конкурентной борьбы), то ему уже будет по ровну на распрекрасный модуль проактивной защиты, ибо до него не достучится уже никто - ни хакер, ни сам администратор..
Антон, на уровне сервера от масштабного DDos уже поздно защищаться. Есть комплексные решения для провайдеров. И зачастую эффективно можно защититься только на уровне вышестоящего провайдера. Мы в эту область не полезем. Ну совсем не наше.
Такую защиту могут обеспечить датацентры. Очень специфическая область.
Где-то видел более изящное решение - проверка капчи.
Правда там использовалось из-за тяжелых AJAX-интерфейсов для защиты от лишней нагрузки на сервер.
Кстати, у меня по статистике, твари рвутся с infobox.ru.
Но не далее как вчера я редактировал шаблон из админской панели (Малый бизнес, последние стабильные обновления) и не мог понять, почему не работают js-скрипты . Оказалось, что <sc ript>(без пробелов) заменился на <sc ript>(с пробелом) и <li nk (аналогично)- на <li nk
Причем, это случилось 1-2 раза, остальные 8 раз все сохранилось нормально и системы появлеиня ошибки я не понял. Зато, теперь понятно откуда она такая взялась
А еще некоторое пожелание к настройкам - сделайте возможность создания нескольких правил, например:
1. в течении 10сек сделано более 15 хитов - блокировать на 60 сек
2. в течении 600сек сделано более 100хитов - блокировать на 120сек
3. в течении 3600сек сделано более 1000 хитов - блокировать на 24часа (или даже создать правило для стоплиста)
1 и 2 - это скорее всего слишком активные посетители, которым практически не интересно содержимое сайта, а вот 3 правило - это бот, который просто выкачивает сайт, создавая лишнюю нагрузку
и сейчас можно отсеивать только первых или только вторых, а желательно обе группы