>Cистемные логи анализируются. Так как специфика решаемых задач на
платформе сильно разнится, то и анализ логов разнится. >Обнаружить
вторжение можно только путём очень тщательной ручной работы. Snort всего лишь
автоматизирует малую часть работы. В >случае вторжения в систему внедряется
руткит. Обнаружение руткитов задача далеко не простая. Нельзя COB
вставлять в базовый >пакет. Это лишняя сущность. Например, у меня есть
сервер базы данных, доступ к которому извне отсутствует. Всё общение сводится
>только к запросам к базе данных и получением от неё ответов. В таком
случае COB будет бесполезен, избыточен и более того даже >вреден.
СОВ для того и создавались, чтобы
отслеживать состояние системы в динамике. При нормальном подходе именно СОВ
должна отслеживать внедрение руткитов. Не хочется использовать СОВ -
пожалуйста, не используйте. Модуль ядра - он на то и модуль, чтобы
использовать его по мере необходимости.
>Антивирусный демон не нужен хотя бы из-за того, что дополнительным
объектом атаки станет больше. Теперь злоумышленнику >достаточно просто
найти уязвимость в данном демоне и вуаля - он сможет делать всё что
хочет. Кроме этого, все Ваши идеи очень >резко снизят
производительность. Для нагруженных серверов это критично. Это вообще критично
для всех. В конце концов спрятанные в >ядре руткиты вероятнее всего
будут просто недоступны этому демону. Если же демон будет в ядре, то это
такаааааааааая дырка в >безопасности, что проще админу будет повесится, или
поставить винду, или просто взять коммерческий юникс без этой самой дырки
>ввиде непонятного демона. Если демон будет заниматься анализом логов в
режиме онлайн, то он будет потреблять всевозможные >ресурсы ОС : файловые
дескрипторы, процессорное время, занимать оперативную память и тд
Если я понял вас правильно, то антивирусы совсем не нужны. Я считаю, что
нужны. Пусть человек, пользующийся системой, сам выбирает, нужно ему это или
нет, но надо всё же хотя бы предоставить возможность выбора. По поводу
производительности. Linux используется не только на персоналках, но и на
мощных серверах, кластерах, суперкомпьютерах. Linux уже давно занимает прочное
положение на рынке серверов, а сервера используются в самых разных
направлениях. Есть не только закрытые сервера баз данных, как в вашем случае,
но и бастионы, причём не всегда стоящие по периметру локальной сети. Теперь я
вас процитирую: "демон в ядре". Что вы имели в виду? Насколько я знаю,
процессы могут обращаться к ядру, ядро может управлять процессами. Демону в
ядре делать нечего.
>Создавайте, никто Вам лично этого не запрещает. Но
переписывать из-за Вас миллионы строк кода никто не будет. Вообще в списках
>рассылки kernel.org была такая идея и предложение. Но так человек хотя бы
аргументировал свою позицию, приводя примеры упрощения >кода. Видимо Вы не
в курсе, про количество ошибок из-за которых "плюсанутый" компилятор не
соберет ядро. Вас также не смущает то, >что будет работать RTTI, что классы
даются не бесплатно, и ядро разбухнет. Разбухнут все модули. В результате
разработчики будут >заняты оптимизацией ядра больше, нежели написанием
патчей и закрытию багов. Е
Я никого не прошу переписывать миллионы
строк кода. Ребята из Debian не стали всовывать в ядро Linux понравившийся им
код из FreeBSD, а взяли окружение Debian и ядро FreeBSD. С Hurd, наверно,
будет то же самое. Объектно-ориентированное программирование создавалось с
определёнными целями, почему бы не использовать это для создания ядра? Я
слышал об операционках на Java, занявших свою узкую нишу. Про научные
разработки. Дейкстра со своими студентами в своё время создал THE. Я думаю,
студентам от этого была большая польза. Ребята хотя бы кодить нормально
научились. Ещё один пример. BSD появилась не где-нибудь а в университете, и
это ответвление UNIX оказало большое влияние на развитие других операционных
систем.
Спасибо за критику, было
интересно.
Maxim Sakharov AKA
msugar,
Kemerovo,
Russia,
|