The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Предложен механизм уведомления о попытках взлома ядра Linux, opennews (??), 23-Дек-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


33. "Предложен механизм уведомления о попытках взлома ядра Linux"  +/
Сообщение от lucentcode (ok), 24-Дек-13, 01:43 
Идея интересная. Но лишний код в ядре - это как-то не правильно. Ядро и так объёмное. Может, можно вынести основную часть данного функционала в юзерспейс?
Ответить | Правка | Наверх | Cообщить модератору

34. "Предложен механизм уведомления о попытках взлома ядра Linux"  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 24-Дек-13, 01:56 
данный функционал просто не нужен. Есть всевозможные аудиты (пишут кого и при каком действии отфутболили) которых вполне достаточно для фиксации попыток взлома.
Ответить | Правка | Наверх | Cообщить модератору

38. "Предложен механизм уведомления о попытках взлома ядра Linux"  +/
Сообщение от pavlinux (ok), 24-Дек-13, 02:29 
> данный функционал просто не нужен. Есть всевозможные аудиты (пишут кого и при
> каком действии отфутболили) которых вполне достаточно для фиксации попыток взлома.

echo "%d%d, 0x42a75ed3,$(pidof spambot)" > /proc/`pidof apache2`/smaps
echo - это попытка взлома?

Ответить | Правка | Наверх | Cообщить модератору

40. "Предложен механизм уведомления о попытках взлома ядра Linux"  +/
Сообщение от lucentcode (ok), 24-Дек-13, 02:30 
> данный функционал просто не нужен. Есть всевозможные аудиты (пишут кого и при
> каком действии отфутболили) которых вполне достаточно для фиксации попыток взлома.

Тоже верно. Нечего засорять ядро. Так в него могут много чего запихать.


Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

75. "Предложен механизм уведомления о попытках взлома ядра Linux"  +/
Сообщение от Andrey Mitrofanov (?), 24-Дек-13, 11:46 
>> данный функционал просто не нужен.
> Тоже верно. Нечего засорять ядро.

Ну, пусть сделают  trace point-ы, неактивные по умолчанию и практически бесплатные _в _смысле производительности, а к ним ещё auditd, fail2ban или [k]analize какой -- включающий исторожащий следовую полосу. Для тех, кому надо.

Но да, tracepoint-ы - часть API, для некоторых, и поддерживать конкретные пойнты (=много всех этих) "всегда в будущем", эти некоторые могут не согласиться. А API для перечисления-обнарпужения именно этих t-p -- так прочсто подарок именно тем самым кракерам.

Зовите академиков и Шнайера!

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру