Есть много руководств и howto по безопасности, в которых разъясняется, ЧТО надо делать:
закройте то, не ставьте это, уберите лишнее, это настройте вот так и т.д.
Но вот я пока не встречал howto, в котором разъяснялись бы концепты, подобные нижеследующим.
Исходные условия:
- ОС Linux (для определенности)
- В НАСТРОЙКЕ компонентов НЕТ ОШИБОК (администратора)
- физический доступ у нападающего отсутсвует
- системных аккаунтов атакующий не знает (т.е. локально/удаленно он не может залогиниться в shell)
- утечку информации через сетвой траффик не учитвать (чувствительные данные (пароли) не передаются или шифруются -
шифрованый трафик считаем нуязвимым)Интересуют так сказать "точки входа" с точки зрения "крупных компонентов системы".
Т.е. то что сервисы могут использовать какие-то библиотеки и в них есть уязвимости это понятно.
Я предлагаю рассматривать сервис просто как единый компонент для анализа ("как одну дырку в стене").
Больше интересуют потверждения постулируемой невзламываемости при отсутвии уязвимостей,
чем взламываемости при наличии оных.Итак меня, как админа, интересуют три следующих ситуации и пути (теоретические и практические)
УДАЛЕННОГО (через сеть) взлома.
Кто владеет знаниями или ссылками на соответствующие источники - прошу прокомментировать, правильны ли эти рассуждения.1. "Компьютер полностью изолированный firewall'ом"
Компьютер, подключен к сети, на нем могут присутсвовать некие работающие сервисы и
при помощи firewall полностью запрещен ВХОДЯЩИЙ И ИСХОДЯЩИЙ трафик
(например iptables -P DENY/DROP для всех цепочек или явными правилами DENY/DROP в PREROUTING/POSTROUTING).
Конечно его можно физически отключить от сети, но интересует именно когда он подключен.
Я считаю что удаленный взлом системы невозможен (нет путей проникновения, не на что воздействовать).
Теоретическая возможность появляется, только если есть грубая ошибка в сетевом коде ядра,
позволяющая обойти firewall, т.е. некий пакет будет проходить дальше на обработку, несмотря на запрет.
Только так появляется хотя-бы какая-то возможность воздействовать на что-то.
Такое маловероятно. Т.е. я считаю такую машину невзламываемой удаленно.2. "Маршрутизатор"
Компьютер, подключен к сети, он выполняет роль МАРШРУТИЗАТОРА, на нем могут присутсвовать некие
работающие сервисы и при помощи firewall полностью запрещен INPUT и OUTPUT трафик и разрешен только FORWARD.
Ситуация примерно как в первом варианте, но чуть хуже. Непосредственно воздействовать на
процессы (сервисы), работающие на машине невозможно, а можно только попытаться сконструировать
некие пакеты использующие уязвимости в сетевом коде ядра и только.
Если их там нет то и путей удаленного взлома маршрутизатора не существует.3. "Компьютер, предоставляющий сервис"
Компьютер, подключен к сети, на нем, для примера, работает SMTP-сервер tcp/25 и POP3-сервер tcp/110.
При помощи firewall закрыто все (и все протоколы и все порты) кроме вот этих двух TCP-портов.
Т.е. есть соответствующие ALLOW и ESTABLISHED.
В данной ситуации, кроме как на сетевой код ядра, можно воздествовать ТОЛЬКО на эти два сервера.
Т.е. если, теоретически, в этих сервисах нет уязвимостей, такую машину по прежнему нельзя взломать.
Практическая возможность взлома, повляется только при наличии уязвимостей в одном из сервисов.
Опять же, для собственной уверенности, в такой конфигурации, достаточно "контролировать" только эти пути взлома,
так как они единственные.
Правильны ли эти рассуждения и на что реально можно "расчитывать" в этих 3х вариантах.
Спсб.
Я в целом с рассуждениями согласен. Т.е. сейчас ПО как раз достигает такого уровня когда все крупные и серьезные ошибки найти можно только совершенно случайно, т.е. не путем долго и упорного анализа. А те мелкие дырочки которые то и дело находятся в результате анализа исходных кодов и общей структуры взаимодействий обычно не представляют сверх серьезной угрозы. Например исполнение коды на удаленной машине в с правами взломанного сервиса часто ни к чему не приводит при грамотной настройке безопасности, когда минимальная часть файлов доступна этому пользователю на запись. Конечно на предприятии где каждая минута простоя стоит больших денег, а потеря байта информации может обернуться крупными неприятностями это все весьма существенно, но в таких организациях и следить за безопасностью должны гораздо серьезней и все последние обновления безопасности и прочее должны вставать на систему уже через 10 секунд после их опубликования :) Не зря все чаще самой страшной атакой становиться DoS-атака, вот они могут быть весьма неприятны, но и в этом случае есть средства и методы.Но на мой взгляд острее стоит вопрос о внутренней безопасности, каким способом защищаться от угрозы изнутри. Раз появляются практически неуязвимые защиты для атак извне начинает все больше рости "промышленный шпионаж" изнутри. Из-за зацикливания на защите от угрозы извне происходят утечки данных изнутри компании. А вот это уже гораздо серьезней :(
А в чем собственно вопрос? :)
>[оверквотинг удален]
> Т.е. если, теоретически, в этих сервисах нет уязвимостей, такую машину
>по прежнему нельзя взломать.
> Практическая возможность взлома, повляется только при наличии уязвимостей в одном
>из сервисов.
> Опять же, для собственной уверенности, в такой конфигурации, достаточно "контролировать"
>только эти пути взлома,
> так как они единственные.
>Правильны ли эти рассуждения и на что реально можно "расчитывать" в этих
>3х вариантах.
>Спсб.На все, что угодно.
Во-первых, далеко не все админы тусуются на приватных [IRC, форумах] где есть эксплоиты иинформация о существующих уязвимостях, которые не[public].
Во-вторых, существуют личные контакты и заказные решения для взлома.
В-третьих, есть доверенные хосты, которые пользуются всем, что Вы описали.Посему, чисто теоретически, можно считать что взломать можно что угодно. Вопрос профессионализма атакующего, состоятельности заказчика и самомнения админа. :-))))
Очень "однобоко" рассмотрено...Что значит "взлом" с Ваших слов...несанкционированный доступ? Или ситуация, приводящая к сбою, нестабильности работы системы?
Вы рассмотриваете "взлом" только через уязвимость сервисов, ошибки в настройках и т.д.... - т.е. чисто технические аспекты, что несовсем корректно. Сегодня рассматривать безопасность нужно через призму рисков: конфиденциальность, целостность, доступность, управляемость... и исходя из этого и нужно искать уязвимые места.Как бы хорошо система не была защищена, всегда есть эти риски в той-или-иной степени... Например, перегрев оборудования (отсутствие необходимого охлаждения).... - в итоге у вас ВООБЩЕ ничего работать небудет (риск доступности и целостности)Насчет Ваших трех примеров: из того, что Вы привели - они недостаточно безопасны. Примеры рассмотрены только по риску конфиденциальности (несанкционированный доступ), но нерасмотрены стабильность, отказоустойчивость и управляемость системы. Возможна ситуация, когда сервисы будут работать нестабильно. Например, после применение обновлений в системе. Обновления необходимо применять, хотя бы для расширения функциональности, неговоря уже о накатывании заплаток... Так вот, возможна ситуация, когда обновления от разных брендов будут несовместимы (обновления Windows могут вносить изменения в работу компьютеров и программ, и тот-же firewall может быть неготов к таким изменениям, соответственно будет DROP-ть от них трафик).
"В НАСТРОЙКЕ компонентов НЕТ ОШИБОК (администратора)" - это вряд ли... ошибки есть всегда. Нет ничего идеального. Подчас сам администратор одна большая ошибка!