Недавно я вспоминал свой опыт
работы с операционками. Пришёл к выводу, что системные логи
почти не анализируются, сисадмины зачастую сами пишут скрипты
для добычи нужной им информации. Syslog есть, анализа мало.
Вспомнил, что когда-то вроде бы что-то такое было написано о
системах обнаружения вторжений. Я слышал о Snort, стал
выяснять, набрёл на название OSSEC. Эта система с открытыми
исходниками, есть вариант под Linux, обладает всеми свойствами
системы обнаружения вторжений (СОВ). Можно было бы вставлять
её в базовый набор пакетов. Но можно сделать и поинтереснее.
Cистемные логи анализируются. Так как специфика решаемых задач на
платформе сильно разнится, то и анализ логов разнится. Обнаружить
вторжение можно только путём очень тщательной ручной работы. Snort
всего лишь автоматизирует малую часть работы. В случае вторжения в
систему внедряется руткит. Обнаружение руткитов задача далеко не
простая. Нельзя COB вставлять в базовый пакет. Это лишняя сущность.
Например, у меня есть сервер базы данных, доступ к которому извне
отсутствует. Всё общение сводится только к запросам к базе данных и
получением от неё ответов. В таком случае COB будет бесполезен,
избыточен и более того даже вреден.
СОВ бывают сетевые и
узловые (хостовые). Функции сетевой СОВ почти полностью
берёт на себя iptables, который является теперь модулем ядра. Считаю,
что код узловой СОВ тоже должен быть модулем ядра и быть
таким же обязательным, как iptables. В Википедии описаны
следующие функции СОВ: анализ системных вызовов, логов
приложений, модификаций файлов. Я бы добавил сюда ещё
анализ состояния процессов и межпроцессных коммуникаций.
Анализом логов приложений (для обнаружения атак,
растянутых во времени) должен заниматься отдельный демон,
остальное можно сделать в модуле ядра. Если возникают
непонятные ситуации при анализе модификаций файлов,
состояния процессов и межпроцессных коммуникаций, то
вызывается антивирусный демон. Антивирусы давно выросли из
своего названия, можно было бы назвать это средством
борьбы с чужеродным кодом (СБЧК).
Антивирусный демон не нужен хотя бы из-за того, что дополнительным
объектом атаки станет больше. Теперь злоумышленнику достаточно
просто найти уязвимость в данном демоне и вуаля - он сможет делать
всё что хочет. Кроме этого, все Ваши идеи очень резко снизят
производительность. Для нагруженных серверов это критично. Это
вообще критично для всех. В конце концов спрятанные в ядре руткиты
вероятнее всего будут просто недоступны этому демону. Если же демон
будет в ядре, то это такаааааааааая дырка в безопасности, что проще
админу будет повесится, или поставить винду, или просто взять
коммерческий юникс без этой самой дырки ввиде непонятного демона.
Если демон будет заниматься анализом логов в режиме онлайн, то он
будет потреблять всевозможные ресурсы ОС : файловые дескрипторы,
процессорное время, занимать оперативную память и тд
Ядро Linux пишется на C. Хотя ядро —
это, по сути, набор объектов (пользователи, файлы,
процессы, потоки, сигналы и т. д.). Debian уже сейчас,
кроме ядра Linux, предлагает для использования ядро FreeBSD, на
подходе Hurd. Можно было бы создать
объектно-ориентированное ядро на C++, это, как
минимум, интересная научная разработка.
Создавайте, никто Вам лично этого не запрещает. Но переписывать
из-за Вас миллионы строк кода никто не будет. Вообще в списках
рассылки kernel.org была такая идея и предложение. Но так человек
хотя бы аргументировал свою позицию, приводя примеры упрощения кода.
Видимо Вы не в курсе, про количество ошибок из-за которых
"плюсанутый" компилятор не соберет ядро. Вас также не смущает то,
что будет работать RTTI, что классы даются не бесплатно, и ядро
разбухнет. Разбухнут все модули. В результате разработчики будут
заняты оптимизацией ядра больше, нежели написанием патчей и закрытию
багов. Е
Вернёмся к анализу
логов. Это, фактически, история работы системы. Если
сохранять как можно больше информации о системе, то это
можно использовать не только для анализа причин, по которым
система пришла в текущее состояние, но и для обучения
компьютера, он мог бы приспосабливаться к изменяющимся
условиям работы (естественно, с разрешения пользователя). А
это, фактически, искусственный интеллект в приложении к
компьютерам стандартной архитектуры. Меняться и
приспосабливаться должно не только внутреннее состояние
системы, но и интерфейс. Ну и, такие компьютеры должны
обмениваться полученным опытом друг с другом, Интернет-то
под боком.
Давайте обменяемся мнениями, подключим
специалистов по системному программированию и операционным
системам. К сожалению, у меня нет таких знакомых.
Сформулируем как надо и обратимся к специалистам Debian по ядру, а
может, и к Линусу Торвальдсу с Эндрю Мортоном.
Maxim
Sakharov AKA msugar,
Kemerovo,
Russia,
Не надо тратить время разработчиков на то, что уже неоднократно
разжёвывалось.
С Уважением, Валов Василий
|