пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня в статье мы хотим рассказать про то, как создавать Meet Me Conference в Cisco Unified Communications Manager (CUCM) . Эта функция позволяет подключить несколько телефонов в одну виртуальную комнату для проведения конференции.
/p>
Настройка Meet Me
Сначала на странице CUCM Administration переходим во вкладку Call Routing → Meet-me Number/Pattern и нажимаем Add New.
Тут в строке Directory Number or Pattern указываем номер или паттерн для конференции. Этот номер должен быть уникальным.
После этого необходимо добавить кнопку Meet-Me конференции в Phone Button Template для тех телефонов, которые будут участвовать в конференциях (про настройку Phone Button Template и Softkey Template можно прочитать в этой статье).
Для этого переходим во вкладку Device → Device Settings → Phone Button Template и выбираем уже существующий шаблон, который используется телефоном, либо создаем новый. В открывшемся окне в поле Button Information из выпадающего меню нужно выбрать Meet Me Conference, на той позиции, на которой будет отображаться кнопка. После чего нажимаем Save.
Если был создан новый шаблон, то переходим во вкладку Device → Phone, находим нужный телефон и в поле Phone Button Profile выбираем созданный шаблон.
После этого на экране появится кнопка для конференции. Далее необходимо нажать на нее и ввести созданный нами номер конференции, после чего телефон подключится к комнате. Аналогичные действия необходимо провести на других телефонах, которые будут участвовать в конференции. Если необходимо провести несколько конференций одновременно, то нужно создать несколько номеров для них.
Информация о миллионах людей может стать доступной преступникам из-за уязвимости в системе. В 2024 году Роскомнадзор
зафиксировал
135 случаев утечек баз данных, в них содержалось более 710 млн записей о россиянах. Однако благодаря работе «белых» хакеров
было обнаружено
более 6000 уязвимостей в российских IТ-системах. Этичный хакинг — это взлом компьютерных систем с целью выявления и устранения уязвимостей. В отличие от обычных хакеров, действующих с преступными намерениями, «белые» хакеры помогают организациям укреплять их кибербезопасность. Давайте подробнее рассмотрим, как стать этичным хакером, какие навыки нужны и сколько они зарабатывают.
Кто такой «белый» хакер
«Белый» хакер (или пентестер) — специалист по кибербезопасности, который с разрешения владельцев систем проводит тестирование на проникновение (пентестинг) для обнаружения и устранения слабых мест. Они работают как в штате компаний, так и на фрилансе, участвуя в программах вознаграждений за найденные уязвимости (bug bounty).
Как стать этичным хакером?
Прежде чем погрузиться в изучение этичного хакинга, убедитесь, что эта сфера действительно вызывает у вас интерес. Для начала можно воспользоваться бесплатными ресурсами. Загляните на GitHub в раздел
Awesome Ethical Hacking Resources
. Здесь собраны книги, курсы, сайты и YouTube-каналы, подходящие для новичков. Если вы решили, что хотите связать свою карьеру с профессией «белого» хакера, можно перейти к платным онлайн-курсам, рассмотреть магистратуру по кибербезопасности или продолжить самообучение.
Найдите сообщество единомышленников. На старте пути особенно сложно, если рядом нет людей, способных подсказать направление развития. Легко потеряться в обилии информации, хватаясь за всё подряд. Со временем стоит найти сообщество или наставников, которые помогут структурировать процесс обучения. Курсы и университеты часто дают возможность окружить себя людьми с похожими целями, что может стать отличным мотиватором. Поддержка коллег и совместное развитие внутри команды способны существенно ускорить ваш прогресс.
Какие навыки нужны «белому» хакеру?
Чтобы стать успешным в этом направлении, необходимо обладать широким спектром навыков в кибербезопасности. В зависимости от компании или проекта требования могут различаться, но вот основные из них:
Понимание основных операционных систем: Linux, Windows, iOS и Android. Хакер должен понимать их внутреннее устройство, уязвимости и способы защиты. Например, в Linux важно знать команды и системные журналы, а в Windows разбираться в настройках Active Directory.
Знание языков программирования. Чаще всего это Python для автоматизации задач и анализа трафика, PHP для работы с серверной частью приложений, JavaScript для поиска ошибок в клиентской части и C/C++ для работы с системным программным обеспечением.
Умение работать с разными типами уязвимостей: программные баги, ошибки конфигурации и слабые места сетевых протоколов. Это требует глубокого понимания протоколов HTTP, TCP и DNS и работы сетевых служб Proxy, VPN и Active Directory.
Навыки пентестинга — от этапа разведки и сканирования до составления отчётов. Здесь пригодится работа с инструментами Metasploit, Nmap и Wireshark.
Владение английским языком. Поскольку большинство учебных материалов, полезных книг, статей и форумов написаны на английском, знание языка поможет находить полезную информацию и общаться с другими специалистами по всему миру.
Пентестер: чем он отличается от хакера
Пентестер действует строго в рамках закона. Его основная задача — находить слабые места в системах безопасности. Однако между пентестером и хакером есть несколько ключевых различий.
Во-первых, разработчики знают о действиях пентестера. Его работа всегда согласована с заказчиком: либо через специальный договор, либо в рамках программы Bug Bounty. Это позволяет работать прозрачно и законно.
Во-вторых, пентестер только выявляет уязвимости, но не использует их. Например, если он обнаружил брешь в системе хранения данных, то сообщает о ней разработчикам, указывая на риск и предлагая способы устранения. Но если он решит проверить брешь, скачав конфиденциальные данные, это будет расценено как нарушение закона. Задача пентестера — выявить проблему, но не действовать как злоумышленник.
Кроме того, заработок пентестера полностью легален. Оплата за работу поступает в рамках договора или через программы Bug Bounty, поэтому никаких проблем с налоговыми органами не возникает.
Основное отличие пентестера от хакера заключается в наборе правил, которые он соблюдает. Вся его деятельность проходит в рамках согласованных программ и ограничивается контрактом. Поскольку пентестинг включает элементы взлома, процесс тщательно регламентирован и проводится с соблюдением всех юридических норм.
Где «белые» хакеры находят заказы?
Крупные компании, такие как Google, Meta (владеет Facebook, Instagram и Threads, признана в России экстремистской организацией и запрещена), Apple и PayPal, проводят собственные программы bug bounty, привлекая специалистов для поиска уязвимостей в их продуктах. Кроме того, существуют специальные платформы, где компании размещают задания для «белых» хакеров:
HackerOne: одна из крупнейших платформ для bug bounty программ.
Bugcrowd: платформа, соединяющая исследователей безопасности с организациями, ищущими специалистов для тестирования своих систем.
SafeHats и Synack: популярные ресурсы для поиска заказов в области кибербезопасности.
Сколько зарабатывают «белые» хакеры?
На
hh.ru
по запросу «Пентестер» в январе 2025 года можно найти 51 вакансию. Начинающие специалисты могут рассчитывать на зарплату от 80?000 рублей в месяц. Доход «белых» хакеров варьируется от 120 000 до 250 000 рублей в месяц.
В международной практике доходы «белых» хакеров значительно выше. В США средняя годовая зарплата составляет около $100?000, в Канаде — около $80?000. Кроме того, участие в программах bug bounty может приносить дополнительные доходы: за найденные уязвимости компании выплачивают вознаграждения, которые в некоторых случаях достигают сотен тысяч долларов.
Итог
Быть специалистом по информационной безопасности, который защищает системы от злоумышленников, ищет уязвимости и легально взламывает их, — звучит заманчиво, не правда ли? Этичный хакинг — перспективное и интересное направление, сочетающее технические навыки с высоким уровнем ответственности и этики.
В программировании понятие «состояние» (state) относится к состоянию системы, компонента или приложения в какой-то определенный момент времени.
Приведем простой пример. Допустим, вы совершаете покупки на amazon.com, и будь то факт того, что вы вошли в данный момент на сайт, или есть ли какие-то товары в вашей корзине, это все является примерами состояния.
Состояние – это данные, которые хранятся и используются для отслеживания текущего статуса приложения. Именно понимание и управление состоянием играет решающую роль в создании интерактивных и динамических веб-приложений.
Понятие «состояние» относится к многим компонентам архитектуры. Шаблоны проектирования (например, REST или GraphQL), протоколы (например, HTTP и TCP), межсетевые экраны и функции могут как сохранять состояние, так и не делать этого. Однако основной принцип «состояния» (независимо от компонента, к которому оно привязывается) остается прежним.
В этой статье мы расскажем, что такое состояние. Кроме того, мы объясним, что такое stateful и stateless-архитектуры, а также их плюсы и минусы.
Что такое stateful-архитектура?
Представьте, что вы идете в пиццерию, чтобы пообедать. В этом ресторане работает только один официант, и он подробно записывает всю информацию о вас: номер вашего стола, ваш заказ, ваши предпочтения на основе предыдущих заказов (тип корочки, который вам нравится, или начинки, на которые у вас аллергия) и т.д.
Иллюстрация: официант принимает заказ в пиццерии
Вся информация, которую официант записывает в блокнот, и есть состояние клиента. Доступ к этой информации имеет только официант, который вас обслуживает. Если вы хотите внести какие-то изменения в свой заказ или проверить готовность заказа, вам нужно обратиться к тому же официанту. Ну и поскольку официант всего один, это не является проблемой.
А теперь представьте, что в ресторане стало больше посетителей. Вашему официанту приходится обслуживать и других гостей, поэтому на работу вызывают дополнительных официантов. И в данной ситуации вы хотите проверить статус вашего заказа и внести в него небольшое изменение – обычную корочку вместо сырной. А единственный официант, который может вас обслужить, - не тот, который принял ваш заказ.
Иллюстрация: другой официант не может изменить заказ клиента
У этого официанта нет информации о вашем заказе, то есть о вашем состоянии. И по понятным причинам он не сможет проверить статус вашего заказа или внести в него изменения. Ресторан, где сообщать о готовности заказа или вносить в него изменения могут только официанты, принявшие этот заказ, придерживается архитектуры с сохранением состояния (stateful).
Подобным образом stateful-приложение будет иметь сервер, который будет запоминать данные клиентов (то есть их состояния). Все будущие запросы будут перенаправляться через балансировщик нагрузки (придерживаясь при этом механизма «липких сессий» (Sticky Sessions)) на тот же сервер. Таким образом, сервер всегда будет знать все о клиенте.
На схеме ниже показаны два разных пользователя, и они оба хотят получить доступ к веб-серверу через балансировщик нагрузки. Так как состояние приложения сохраняется на сервере, пользователи при каждом запросе должны направляться на один и тот же сервер, чтобы сохранять состояние.
Схема: как работает stateful-приложение
Sticky sessions (липкие сессии) – это настройка, позволяющая балансировщику нагрузки раз за разом направлять запросы пользователя на один и тот же внутренний сервер на протяжении всей сессии. В этом и заключается ее отличие от обычной балансировки нагрузки, при которой запросы пользователя направляются на любой доступный сервер по циклическому алгоритму или по какому-то другому шаблону распределения нагрузки.
В чем же проблема stateful-архитектуры? Представьте себе ресторан, который работает таким образом. Несмотря на то, что это такой вариант может оказаться вполне идеальным и простым в реализации для небольшого семейного ресторана с небольшим количеством посетителей, его
нельзя назвать отказоустойчивым
и масштабируемым
.
Что будет, если у официанта, который принял у клиента заказ, возникнет ЧП и ему придется уйти? Вся информация по заказу так и останется у этого официанта. Это подрывает качество обслуживания клиентов, так как любой новый официант, который придет, чтобы заменить старого, не будет ничего знать о предыдущих заказах. Такая структура не является отказоустойчивой.
Кроме того, распределение запросов таким образом, что клиент может обращаться только к одному и тому же официанту, подразумевает, что нагрузка на официантов распределяется неравномерно. Кто-то будет завален заказами, особенно если он обслуживает какого-нибудь требовательного клиента, который постоянно меняет или добавляет что-то в свой заказ. А кому-то будет нечем заняться, и при этом они не смогут вмешиваться и помогать другим официантам. И опять-таки, такая структура не является масштабируемой.
Точно так же хранение данных о состоянии разных клиентов на разных серверах нельзя назвать отказоустойчивым и масштабируемым. Если произойдет сбой сервера, то все данные о состоянии будут утеряны. Так что, если пользователь вошел в систему и собирается оформить большой заказ, например, на amazon.com, ему придется снова пройти этап аутентификации, и при этом его корзина окажется пустой. Покупателю придётся снова входить в систему и заново заполнять корзину, и это явно испортит его впечатление от использования сайта.
Кроме того, добиться масштабируемости в час пик, например, в Черную пятницу, при использовании stateful-структуры будет не так просто. Структура будет автоматически масштабироваться, добавляя новые серверы, но, так как работает механизм «липких сессий», клиенты будут направляться на одни и те же серверы, что может привести к их перегрузке, что, в свою очередь, приведет к увеличению времени отклика, и это плохо скажется на взаимодействии с пользователем.
Многие из этих проблем может решить stateless-архитектура.
Что такое stateless-архитектура?
Stateless-архитектура – это термин, который в какой-то степени сбивает с толку, так как подразумевает, что система не фиксирует состояние. Но тем не менее такой тип архитектуры вовсе не означает, что информация о состоянии нигде не сохраняется. Это лишь значит, что информация о состоянии хранится вне сервера. Так что, понятие «stateless» может применяться только к серверу.
Вернемся к примеру с рестораном. В данном случае можно сказать, что официанты в этом ресторане имеют крайне плохую память. Они не помнят старых клиентов и тем более не помнят, что вы заказывали ранее и какая пицца вам нравится. Они просто принимают заказы клиентов в отдельной системе, скажем, на компьютере, к которому есть доступ у всех официантов. После чего они могут обратиться к компьютеру, чтобы получить более подробную информацию о заказе и внести в него необходимые изменения.
Иллюстрация: «забывчивый» официант принимает заказ, а затем обращается к компьютеру, чтобы получить больше информации о заказе
Сохраняя «состояние» заказа клиента в централизованной системе, которая доступна всем официантам, любой из них может обслужить любого клиента.
В рамках stateless-архитектуры HTTP-запросы от клиентов могут отправляться на любой из серверов.
Как правило, состояние хранится в отдельной базе данных, которая доступна для всех серверов. Таким образом, вы получаете отказоустойчивую и масштабируемую архитектуру, так как при необходимости вы можете удалять или добавлять серверы, не влияя при этом на данные о состоянии.
Кроме того, нагрузка будет равномерно распределяться по всем серверам, так как балансировщику нагрузки не нужно придерживаться схемы липких сессий для направления одних и тех же клиентов на одни и те же сервера.
На схеме ниже продемонстрированы два разных пользователя, которые пытаются получить доступ к веб-серверу через балансировщик нагрузки. Так как состояние приложения хранится отдельно от серверов, пользователи могут быть направлены на любой из них. После чего сервер запросит информацию о состоянии из внешней базы данных, которая доступна для всех серверов.
Иллюстрация: схема stateless-архитектуры
В большинстве случаев данные о состоянии хранятся в кэше, например, в Redis – внутреннем хранилище данных. В отличие от хранения на диске, хранение данных в оперативной памяти требует меньше времени на такие операции, как чтение и запись.
Объединяем все вместе
В этой статье описывается, как работают веб-приложения с сохранением и без сохранения состояния, а также их недостатки. Однако принципы stateful и stateless-архитектуры могут применяться не только к веб-приложениям.
Если мы в качестве примера посмотрим на сетевые протоколы, то увидим, что, например, HTTP – это протокол без сохранения состояния. Это значит, что каждый HTTP-запрос от клиента к серверу является
независимым
и
не содержит информации о предыдущих запросах
или их содержимом. Сервер обрабатывает каждый запрос как отдельную транзакцию и по определению не сохраняет информацию о состоянии клиента между запросами.
Состояние может храниться либо на серверах (stateful-архитектура), либо в отдельной базе данных вне серверов (stateless-архитектура). Сам по себе HTTP-протокол не сохраняет состояние.
В отличие от HTTP, который не сохраняет состояние, TCP-протокол устанавливает соединение и сохраняет состояние. Он устанавливает соединение между двумя устройствами (как правило, это клиент и сервер) и поддерживает непрерывный канал связи до тех пор, пока соединение не будет завершено.
Та же логика может применяться и к межсетевым экранам – они могут как сохранять состояние, так и не делать этого.
В AWS группа безопасности – это виртуальный брандмауэр, который контролирует входящий и исходящий трафик виртуальных машин или облачных экземпляров. Группы безопасности сохраняют состояние. Когда вы пропускаете определенный входящий трафик, соответствующий исходящий трафик пропускается автоматически. Иными словами, отслеживается состояние соединения.
Для управления входящим и исходящим трафиком в AWS на уровне подсети используются Списки управления сетевым доступом (NACL - Network Access Control Lists), которые не сохраняют состояние. Отсутствие фиксации состояния говорит о том, что вы должны явно определить правила как для входящего, так и для исходящего трафика.
В отличие от групп безопасности, где при пропуске входящего трафика исходящий трафик пропускается автоматически, NACL требуют определить отдельные правила для входящего и исходящего трафика.
Функции и шаблоны проектирования тоже могут сохранять или не сохранять состояние.
Основная идея, которая лежит в основе чего-то, что сохраняет состояние, заключается в том, что это что-то обладает идеальной памятью или знает все о предыдущих вызовах и запросах. А вот то, что не сохраняет состояние, ничего не запоминает и не обладает знаниями о предыдущих вызовах или запросах.
Надеюсь, что теперь вы стали лучше понимать, как работают stateful и stateless-приложения, и сможете решить, какой вариант вам больше подходит.