По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Периметр сети в традиционном понимании исчез. Доступ к приложениям и цифровым ресурсам организации происходит из разных мест вне стен офиса и контроль за этими доступами становится серьезной проблемой. Дни, когда можно было защитить границы сети, давно прошли. Настало время для новых стратегий безопасности с нулевым доверием - Zero Trust.
Когда цифровым активам компании приходится преодолевать большие расстояния по небезопасным путям Интернета, ставки настолько высоки, что нельзя доверять ничему и никому. Поэтому следует использовать модель сети с нулевым доверием, чтобы постоянно ограничивать доступ всех пользователей ко всем сетевым ресурсам.
В сетях с нулевым доверием любая попытка доступа к ресурсу ограничивается пользователем или устройством, независимо от того, имели ли они ранее доступ к одному и тому же ресурсу. Чтобы получить доступ к ресурсам любой пользователь или устройство всегда должны проходить процесс аутентификации и верификации, даже если они физически находятся в организации. Эти проверки должны быть быстрыми, чтобы политики безопасности не снижали производительность приложений и работу пользователей.
Zero-trust vs. VPN
Модель сети с нулевым доверием заменяет модель VPN, традиционно используемую компаниями для удаленного доступа своих сотрудников к цифровым ресурсам. VPN заменяется, поскольку они имеют основной недостаток, который могут устранить сети с нулевым доверием. В VPN любая уязвимость, которое происходит в зашифрованном канале, соединяющем пользователя с сетью организации, предоставляет потенциальным злоумышленникам неограниченный доступ ко всем ресурсам компании, подключенным к сети.
В старых локальных инфраструктурах VPN работали хорошо, но они создают больше проблем, чем решений в облачных или смешанных инфраструктурах.
Сети с нулевым доверием устраняют этот недостаток VPN, но добавляют потенциальный недостаток: они могут привести к дополнительной сложности с точки зрения реализации и обслуживания, поскольку полномочия должны быть обновлены для всех пользователей, устройств и ресурсов. Это требует дополнительной работы, но взамен ИТ-отделы получают больший контроль над ресурсами и уменьшается плоскость атаки.
К счастью, преимуществами сети с нулевым доверием можно пользоваться без дополнительных усилий по обслуживанию и развертыванию благодаря инструментам, которые автоматизируют и помогают в задачах администрирования сети. Описанные ниже инструменты помогают применять политики нулевого доверия с минимальными усилиями и затратами.
1. Perimeter 81
Perimeter 81 предлагает два подхода к управлению приложениями и сетями организации и обеспечению их безопасности как в облачных, так и локальных средах. Оба подхода начинаются с предложения сетей с нулевым доверием в качестве услуги. Для этого в Perimeter 81 используется программно-определяемая архитектура периметра, которая обеспечивает большую гибкость для новых пользователей и обеспечивает большую видимость сети. Кроме того, сервис совместим с основными поставщиками облачной инфраструктуры.
Доступ к приложениям с нулевым доверием основан на предположении, что каждая компания имеет критически важные приложения и службы, доступ к которым большинству пользователей не требуется. Сервис позволяет создавать политики для конкретных пользователей в зависимости от их ролей, устройств, местоположений и других идентификаторов.
При этом Zero Trust Network Access определяет сегментацию сети организации по зонам доверия, что позволяет создавать пределы доверия, контролирующие поток данных с высоким уровнем детализации. Доверенные зоны состоят из наборов элементов инфраструктуры с ресурсами, которые работают на одном уровне доверия и обеспечивают аналогичную функциональность. Это уменьшает количество каналов связи и минимизирует возможность возникновения угроз.
Служба доступа к сети с нулевым доверием Perimeter 81 обеспечивает полное и централизованное представление сети организации, обеспечивая наименее привилегированный доступ для каждого ресурса. Его функции безопасности соответствуют модели SASE компании Gartner, поскольку безопасность и управление сетью унифицированы на единой платформе.
Две услуги Perimeter 81 включены в схему ценообразования с широким спектром опций. Эти возможности варьируются от базового плана с необходимыми компонентами для обеспечения безопасности сети и управления ею до корпоративного плана, который может неограниченно масштабироваться и обеспечивает специальную поддержку 24/7.
2. ZScaler Private Access
ZScaler Private Access (ZPA) - это облачная сетевая служба с нулевым доверием, которая управляет доступом к частным приложениям организации независимо от того, находятся ли они в собственном центре обработки данных или в общедоступном облаке. Благодаря ZPA приложения полностью невидимы для неавторизованных пользователей.
В ZPA связь между приложениями и пользователями осуществляется в соответствии со стратегией «наизнанку». Вместо расширения сети для подключения пользователей (как это должно быть сделано при использовании VPN), пользователи никогда не находятся внутри сети. Этот подход существенно минимизирует риски, избегая распространения вредоносных программ и рисков перемещения внутри периметра. Кроме того, сфера применения ZPA не ограничивается веб-приложениями, а относится к любому частному приложению.
ZPA использует технологию микро-туннелей, которая позволяет сетевым администраторам сегментировать сеть по приложениям, устраняя необходимость сегментации в сети с помощью межсетевого экрана или списками управления доступом (ACL). В микро-туннелях используется шифрование TLS и пользовательские закрытые ключи, которые усиливают безопасность при доступе к корпоративным приложениям.
Благодаря усовершенствованным API и ML (машинное обучение), ZPA позволяет ИТ-отделам автоматизировать механизмы нулевого доверия, обнаруживая приложения и создавая для них политики доступа, а также автоматически создавая сегментацию для каждой отдельной рабочей нагрузки приложения.
3. Cloudflare Access
Сетевая служба нулевого доверия Cloudflare поддерживается частной сетью с точками доступа, распределенными по всему миру. Это позволяет ИТ-отделам обеспечивать высокоскоростной и безопасный доступ ко всем ресурсам организации - устройствам, сетям и приложениям.
Сервис Cloudflare заменяет традиционные, ориентированные на сеть периметры безопасности, используя вместо этого безопасный доступ на близком расстоянии, обеспечивающий оптимальную скорость распределенных рабочих групп.
Доступ Cloudflare с нулевым доверием управляет общими приложениями в организации, проверяя подлинность пользователей через собственную глобальную сеть. Это позволяет ИТ-менеджерам регистрировать каждое событие и каждую попытку доступа к ресурсу. Кроме того, это упрощает поддержку пользователей и добавление новых пользователей.
С помощью Cloudflare Access организация может поддерживать свои идентификационные данные, поставщиков защиты, состояние устройств, требования к местоположению каждого приложения и даже существующую облачную инфраструктуру. Для контроля идентичности Cloudflare интегрируется с Azure AD, Okta, Ping и устройством с Tanium, Crowdstrike и Carbon Black.
Cloudflare предлагает бесплатную версию своего сервиса, которая предоставляет основные инструменты и позволяет защитить до 50 пользователей и приложений. Для большего числа пользователей или приложений, а также чтобы воспользоваться другми преимуществами, вроде круглосуточной поддержки по телефону и чату, следует выбрать платные версии.
4. Wandera
Сетевое решение Wandera Private Access с нулевым доверием обеспечивает быстрый, простой и безопасный удаленный доступ к приложениям организации, независимо от того, работают ли они в SaaS или развернуты внутри организации. Сервис отличается своей простотой, процедурами установки, которые могут быть выполнены за считанные минуты и не требуют специализированного оборудования, сертификатов или масштабирования.
Wandera Private Access предлагает гибкость распределенным рабочим группам, работающим на разнородных платформах, с управляемыми или личными устройствами (BYOD). Решение обеспечивает видимость доступа к приложениям в реальном времени, идентификацию теневых ИТ-отделов и автоматическое ограничение доступа с зараженных или небезопасных устройств благодаря политике доступа на базе учета рисков.
С помощью Wandera Private Access можно реализовать модели безопасности, ориентированные на идентификацию, гарантируя, что только авторизованные пользователи смогут подключаться к приложениям организации. Использование микротуннелей на основе приложений связывает пользователей только с приложениями, к которым они имеют право доступа. Применение политики безопасности остается согласованным во всех инфраструктурах, будь то облачные приложения, центры обработки данных или приложения SaaS.
Система защиты Wandera работает от интеллектуального механизма обнаружения угроз под названием MI: RIAM. Этот двигатель ежедневно снабжается информацией, предоставляемой 425 миллионами мобильных датчиков, что обеспечивает защиту от самого широкого спектра известных угроз и угроз нулевого дня.
5. Okta
Okta предлагает модель безопасности с нулевым доверием, которая охватывает широкий спектр услуг, включая защиту приложений, серверов и API; унифицированный и безопасный доступ пользователей к интерактивным и облачным приложениям; адаптивная, контекстно-зависимая, многофакторная аутентификация и автоматическое отключение для уменьшения рисков для бесхозных учетных записей.
Универсальная служба каталогов Okta обеспечивает единое консолидированное представление каждого пользователя в организации. Благодаря интеграции групп пользователей с AD и LDAP, а также связям с системами HR, приложениями SaaS и сторонними поставщиками удостоверений, Okta Universal Directory интегрирует всех типов пользователей, будь то сотрудники компании, партнеры, подрядчики или клиенты.
Okta выделяется своей службой защиты API, поскольку API рассматриваются как новая форма теневых ИТ. Управление доступом к API Okta сокращает время планирования и применения политик на основе XML до нескольких минут, облегчая ввод новых API и интеграцию с партнерами для использования API. Механизм политики Okta позволяет внедрять передовые практики в области безопасности API, легко интегрируясь с фреймворками идентификации вроде OAuth. Политики авторизации API создаются на основе приложений, пользовательского контекста и членства в группах для обеспечения доступа к каждому API только нужных пользователей.
Интеграционная сеть Okta позволяет избежать блокировки поставщиков, предоставляя организациям свободу выбора из более чем 7000 встроенных интеграций с облачными и готовыми системами.
6. CrowdStrike Falcon
Решение CrowdStrike Falcon Identity Protection с нулевым доверием быстро останавливает нарушения безопасности из-за скомпрометированных учётных записей, защищая учетные записи всех пользователей, расположений и приложений в организации с помощью политики нулевого доверия.
Программа Falcon Identity Protection направлена на сокращение затрат и рисков и повышение окупаемости инвестиций используемых инструментов за счет снижения требований к инженерным ресурсам и устранения избыточных процессов обеспечения безопасности.
Унифицированный контроль всех учетных записей упрощает реализацию стратегий условного доступа и адаптивной аутентификации, а также обеспечивает более высокий уровень обслуживания пользователей и более широкий охват многофакторной аутентификации (MFA) даже для устаревших систем.
Решение для удаленного доступа CrowdStrike обеспечивает полную видимость активности аутентификации всех учетных записей и конечных точек, предоставляя, среди прочего, данные о местоположении, источнике/назначении, типе входа (учетная запись человека или службы). В свою очередь, он защищает сеть от инсайдерских угроз, таких как устаревшие привилегированные учетные записи, неправильно назначенные учетные записи служб, ненормальное поведение и полномочия, скомпрометированные атаками продвижения внутри периметра.
Благодаря интеграции с существующими решениями по обеспечению безопасности развертывание Falcon Identity Protection осуществляется в минимальные сроки и без усилий. Помимо прямой интеграции с решениями безопасности для критически важных активов, таких как CyberArk и Axonius, CrowdStrike предлагает высокопроизводительные API, которые позволяют компаниям интегрировать практически с любой системой.
Заключение
Новая норма, похоже, останется, и ИТ-администраторам нужно привыкнуть к ней. Удаленная работа будет оставаться повседневной реальностью, и сети организации больше никогда не будут иметь четко определенных границ.
В этом контексте ИТ-администраторы должны как можно скорее внедрить сетевые и прикладные решения с нулевым доверием, если они не хотят подвергать риску самые ценные цифровые активы своих организаций.
В семиуровневой модели OSI на различных уровнях имеются разные типы адресов. На канальном это MAC-адрес, а на сетевом это IP-адрес. И для того чтобы установить соответствие между этими адресами используется протокол Address Resolution Protocol – ARP. Именно о нем мы поговорим в этой статье.
Адресация
Адреса 2-го уровня используются для локальных передач между устройствами, которые связаны напрямую. Адреса 3-го уровня используются устройств, которые подключены косвенно в межсетевой среде. Каждая сеть использует адресацию для идентификации и группировки устройств, чтобы передачи прошла успешно. Протокол Ethernet использует MAC-адреса, которые привязаны к сетевой карте.
Чтобы устройства могли общаться друг с другом, когда они не находятся в одной сети MAC-адрес должен быть сопоставлен с IP-адресом. Для этого сопоставления используются следующие протоколы:
Address Resolution Protocol (ARP)
Reverse ARP (RARP)
Serial Line ARP (SLARP)
Inverse ARP (InARP)
Address Resolution Protocol
Устройству 3го уровня необходим протокол ARP для сопоставления IP-адреса с MAC-адресом, для отправки IP пакетов. Прежде чем устройство отправит данные на другое устройство, оно заглянет в свой кеш ARP где хранятся все сопоставления IP и MAC адресов, чтобы узнать, есть ли MAC-адрес и соответствующий IP-адрес для устройства, которому идет отправка. Если записи нет, то устройство-источник отправляет широковещательное сообщение каждому устройству в сети чтобы узнать устройству с каким MAC-адресом принадлежит указанный IP-адрес. Все устройства сравнивают IP-адрес с их собственным и только устройство с соответствующим IP-адресом отвечает на отправляющее устройство пакетом, содержащим свой MAC-адрес. Исходное устройство добавляет MAC-адрес устройства назначения в свою таблицу ARP для дальнейшего использования, создает пакет с новыми данными и переходит к передаче.
Проще всего работу ARP иллюстрирует эта картинка:
Первый компьютер отправляет broadcast сообщение всем в широковещательном домене с запросом “У кого IP-адрес 10.10.10.2? Если у тебя, то сообщи свой MAC-адрес” и на что компьютер с этим адресом сообщает ему свой MAC.
Когда устройство назначения находится в удаленной сети, устройства третьего уровня одно за другим, повторяют тот же процесс, за исключением того, что отправляющее устройство отправляет ARP-запрос для MAC-адреса шлюза по умолчанию. После того, как адрес будет получен и шлюз по умолчанию получит пакет, шлюз по умолчанию передает IP-адрес получателя по связанным с ним сетям. Устройство уровня 3 в сети где находится устройство назначения использует ARP для получения MAC-адреса устройства назначения и доставки пакета.
Кэширование ARP
Поскольку сопоставление IP-адресов с MAC-адресами происходит на каждом хопе в сети для каждой дейтаграммы, отправленной в другую сеть, производительность сети может быть снижена. Чтобы свести к минимуму трансляции и ограничить расточительное использование сетевых ресурсов, было реализовано кэширование протокола ARP.
Кэширование ARP - это способ хранения IP-адресов и связанных c ними MAC-адресов данных в памяти в течение определенного периода времени, по мере изучения адресов. Это минимизирует использование ценных сетевых ресурсов для трансляции по одному и тому же адресу каждый раз, когда отправляются данные. Записи кэша должны поддерживаться, потому что информация может устаревать, поэтому очень важно, чтобы записи кэша устанавливались с истечением срока действия. Каждое устройство в сети обновляет свои таблицы по мере передачи адресов.
Статические и динамические записи в кеше ARP
Существуют записи статического ARP-кэша и записи динамического ARP-кэша. Статические записи настраиваются вручную и сохраняются в таблице кеша на постоянной основе. Статические записи лучше всего подходят для устройств, которым необходимо регулярно общаться с другими устройствами, обычно в одной и той же сети. Динамические записи хранятся в течение определенного периода времени, а затем удаляются.
Для статической маршрутизации администратор должен вручную вводить IP-адреса, маски подсети, шлюзы и соответствующие MAC-адреса для каждого интерфейса каждого устройства в таблицу. Статическая маршрутизация обеспечивает больший контроль, но для поддержания таблицы требуется больше работы. Таблица должна обновляться каждый раз, когда маршруты добавляются или изменяются.
Динамическая маршрутизация использует протоколы, которые позволяют устройствам в сети обмениваться информацией таблицы маршрутизации друг с другом. Таблица строится и изменяется автоматически. Никакие административные задачи не требуются, если не добавлен лимит времени, поэтому динамическая маршрутизация более эффективна, чем статическая маршрутизация.
Устройства, которые не используют ARP
Когда сеть делится на два сегмента, мост соединяет сегменты и фильтрует трафик на каждый сегмент на основе MAC-адресов. Мост создает свою собственную таблицу адресов, которая использует только MAC-адреса, в отличие от маршрутизатора, который имеет кэш ARP адресов, который содержит как IP-адреса, так и соответствующие MAC-адреса.
Пассивные хабы - это устройства центрального соединения, которые физически соединяют другие устройства в сети. Они отправляют сообщения всем портам на устройства и работают на уровне 1, но не поддерживают таблицу адресов.
Коммутаторы уровня 2 определяют, какой порт подключен к устройству, к которому адресовано сообщение, и отправлять сообщение только этому порту, в отличие от хаба, который отправляет сообщение всем его портам. Однако коммутаторы уровня 3 - это маршрутизаторы, которые создают кеш ARP (таблица).
Inverse ARP
Inverse ARP (InARP), который по умолчанию включен в сетях ATM, строит запись карты ATM и необходим для отправки одноадресных пакетов на сервер (или агент ретрансляции) на другом конце соединения. Обратный ARP поддерживается только для типа инкапсуляции aal5snap. Для многоточечных интерфейсов IP-адрес может быть получен с использованием других типов инкапсуляции, поскольку используются широковещательные пакеты.
Reverse ARP
Reverse ARP (RARP) - работает так же, как и протокол ARP, за исключением того, что пакет запроса RARP запрашивает IP-адрес вместо MAC-адреса. RARP часто используется бездисковыми рабочими станциями, потому что этот тип устройства не имеет способа хранить IP-адреса для использования при их загрузке. Единственный адрес, который известен - это MAC-адрес, поскольку он выжигается в сетевой карте. Для RARP требуется сервер RARP в том же сегменте сети, что и интерфейс устройства.
Proxy ARP
Прокси-ARP был реализован для включения устройств, которые разделены на физические сегменты сети, подключенные маршрутизатором в той же IP-сети или подсети для сопоставления адресов IP и MAC. Когда устройства не находятся в одной сети канала передачи данных (2-го уровня), но находятся в одной и той же IP-сети, они пытаются передавать данные друг другу, как если бы они находились в локальной сети. Однако маршрутизатор, который отделяет устройства, не будет отправлять широковещательное сообщение, поскольку маршрутизаторы не передают широковещательные сообщения аппаратного уровня. Поэтому адреса не могут быть сопоставлены.
Прокси-сервер ARP включен по умолчанию, поэтому «прокси-маршрутизатор», который находится между локальными сетями, отвечает своим MAC-адресом, как если бы это был маршрутизатор, к которому адресована широковещательная передача. Когда отправляющее устройство получает MAC-адрес прокси-маршрутизатора, он отправляет данные на прокси-маршрутизатор, который по очереди отправляет данные на указанное устройство.
Proxy ARP вызывается следующими условиями:
IP-адрес назначения не находится в той же физической сети (LAN), на которой получен запрос.
Сетевое устройство имеет один или несколько маршрутов к IP-адресу назначения.
Все маршруты к IP-адресу назначения проходят через интерфейсы, отличные от тех, на которых получен запрос.
Когда proxy ARP отключен, устройство отвечает на запросы ARP, полученные на его интерфейсе, только если IP-адрес назначения совпадает с его IP-адресом или если целевой IP-адрес в ARP-запросе имеет статически настроенный псевдоним ARP.
Serial Line Address Resolution Protocol
Serial Line ARP (SLARP) используется для последовательных интерфейсов, которые используют инкапсуляцию High Link Level Link Control (HDLC). В дополнение к TFTP-серверу может потребоваться сервер SLARP, промежуточное (промежуточное) устройство и другое устройство, предоставляющее услугу SLARP. Если интерфейс напрямую не подключен к серверу, промежуточное устройство требуется для пересылки запросов сопоставления адреса на сервер. В противном случае требуется напрямую подключенное устройство с сервисом SLARP.
Одной из основных задач, с которой сталкивается администратор IP-АТС, является её защита от внешних вторжений. Как правило, все IP-АТС закрываются от внешней сети по средствам NAT-ирования и порт-форвардинга, но даже в этом случае, сервер может оставаться незащищенным от порт-сканеров, в частности, открытых SIP-портов 5060 и 5061.
В сегодняшней статье рассмотрим механизмы внутренней защиты IP-АТС Asterisk, доступные в web-интерфейсе Elastix 4. Инструменты, о которых пойдёт речь получили общее название Firewall
Итак, для того, чтобы попасть в модуль, переходим по следующему пути: Security → Firewall, перед нами открывается доступный функционал:
Рассмотрим каждую вкладку
Firewall Rules
В данной вкладке, настраиваются правила разрешающие или запрещающие прохождение трафика к IP-интерфейсам вашей IP-АТС. По умолчанию, Firewall выключен и первое, что необходимо сделать – это активировать его, нажав Activate Firewall. С этого момента, Elastix Firewall , будет контролировать ваши IPTables и все настройки, которые были сделаны вручную до этого – аннулируются.
После активации Firewall, перед нами откроется нумерованный список правил для всех портов, которые может использовать Elastix, а также возможность добавления собственного правила - Add Rule
В качестве примера покажем правило, запрещающее подключаться к нашей IP-АТС по протоколу SIP из некоторой подсети. Допустим мы в логах обнаружили слишком частые запросы из подсети 31.54.0.0/24. Для того, чтобы заблокировать доступ для этой сети, выбираем правило №4 (SIP) и редактируем его следующим образом:
Таким же образом можно заблокировать, например, протоколы, которые вы не используете (часто IAX, MGCP). Также, будет полезно ограничить возможность доступа к web-интерфейсу для всех, кроме администраторов Elastix по таким протоколам как HTTP(порт 80/8080/8088), HTTPS(порт 443), SSH(порт 22), Telnet (порт 23)
Define Ports
В данной вкладке можно настроить номера портов, которые впоследствии можно применить в правилах. Например, как правило, HTTP может использовать два порта 80 и 8080, в интерфейсе же мы видим только порт 80. Добавим его, для этого нажимаем View → Edit добавляем запись 8080 и кликаем Save. Можно добавить только ещё один номер порта.
Port Knocking Interfaces
Ещё один механизм защиты, позволяющий получать доступ к выбранным интерфейсам вашей IP-АТС, только после последовательности подключений к специальным портам. По умолчанию, порт, который вы хотите защитить, будет закрытым, пока на него не поступит последовательность пактов, которая заставит его открыться.
Port Knocking Users
Данная вкладка позволяет настроить механизм Port-Knocking для определенных пользователей и соответствующих портов.