В предыдущей части мы договорились до того, что не экспортируемые имена ядра Linux могут использоваться в коде собственных модулей ядра с тем же успехом, что и экспортируемые. Одним из таких имён в ядре является селекторная таблица всех системных вызовов Linux. Собственно, это и есть основной интерфейс любых приложений к сервисам ядра. Теперь мы рассмотрим как можно модифицировать оригинальный обработчик любого системного вызова, подменить его, или внести разнообразие в его выполнение в соответствии с собственным видением.
INVENTED @invented
User
Делаем доступным все символы ядра Linux. Часть 1
11 min
30KСостояние дел
Это обсуждение относится к ядру операционной системы Linux, и представляет интерес для разработчиков модулей ядра, драйверов под эту операционную систему. Для всех прочих эти заметки вряд ли представляют интерес.
+13
Захват пакетов в Linux на скорости десятки миллионов пакетов в секунду без использования сторонних библиотек
8 min
87KМоя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.
Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.
Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.
Хороший списочек проблем? Итак, мы их все геройски попробуем решить!
Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.
Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.
Хороший списочек проблем? Итак, мы их все геройски попробуем решить!
+111
Анти-руткит для Userland-RootKit Azazel «на коленке»
3 min
11KВот шикарная новость от пользователя ValdikSS — Новый Userland-RootKit Azazel. Позволю себе процитировать первый абзац:
Таким образом, в рутките используется штатная возможность подгружать через
Возможно вы слышали про руткиты Jynx и Jynx2. Это так называемые userland-руткиты, они используют возможность переменной LD_PRELOAD, которая позволяет подгружать любые библиотеки до того, как будет запущена программа. Они уже относительно старые, но все еще хорошо работают.
2 дня назад, Github-пользователь Chokepoint выложил rootkit Azazel. Он основан на исходном коде Jynx и имеет много новых фич:
Антиотладочные механизмы
Скрытие от unhide, lsof, ps, ldd
Скрытие файлов и директорий
Скрытие удаленных подключений
Скрытие процессов
Скрытие логинов
Скрытие от локального сниффинга трафика через PCAP
2 бекдора с полноценными шеллами (с PTY):
— Crypthook accept()-бекдор
— Обычный accept()-бекдор
PAM-бекдор для аутентификации под любым пользователем
Очистка логов utmp/wtmp для PTY
Обфускация строк скомпилированной библиотеки через xor.
Таким образом, в рутките используется штатная возможность подгружать через
LD_PRELOAD
любую библиотеку. Встаёт вопрос, а можно ли это как-то контролировать?+27
Перехват функций ядра Linux с использованием исключений (kprobes своими руками)
8 min
14KTutorial
Перехват функций ядра является базовым методом, позволяющим переопределять (дополнять) различные его механизмы. Исходя из того, что за исключением небольших архитектурно-зависимых частей, ядро Linux почти полностью написано на языке C, можно утверждать, что для осуществления встраивания в большинство из компонентов ядра, достаточно иметь возможность перехвата соответствующих функций ЯВУ, реализующих ту или иную логику.
Данная статья является практическим обобщением представленных ранее статей:
Далее будет рассмотрено каким образом использование данных материалов может быть применимо в обеспечении возможности перехвата функций ядра Linux.
Данная статья является практическим обобщением представленных ранее статей:
- Управляемый PageFault в ядре Linux
- Кошерный способ модификации защищённых от записи областей ядра Linux
Далее будет рассмотрено каким образом использование данных материалов может быть применимо в обеспечении возможности перехвата функций ядра Linux.
+43
Идентификация загружаемых модулей ядра Linux [ч.1]: исходные тексты
4 min
13KВ этом посте я расскажу о своих поисках признаков того, как можно определить, что из некоторых файлов исходных текстов собирается загружаемый модуль ядра Linux (LKM), а не обычный исполняемый файл.
Допустим, что информации о назначении исходников нет или её пытаются преднамеренно скрыть.
Upd: Объём кода > 4 Гб и надо оперативно выделить только те исходники, которые реализуют модули ядра.
При сборке исходных текстов определён символ препроцессора __KERNEL__.
Допустим, что информации о назначении исходников нет или её пытаются преднамеренно скрыть.
Upd: Объём кода > 4 Гб и надо оперативно выделить только те исходники, которые реализуют модули ядра.
#01 __KERNEL__
При сборке исходных текстов определён символ препроцессора __KERNEL__.
+25
Простая маскировка модуля ядра Linux с применением DKOM
5 min
11KTutorial
Как известно, задача сокрытия модуля ядра от вездесущих «глаз» пользователя может иметь множество приложений. В данной статье рассматривается применение DKOM (Direct Kernel Object Manipulation) — одной из техник, позволяющий осуществить сокрытие информации посредством модицикации внутренних структур ядра.
Далее будут рассмотрены особенности применения данной техники с целью сокрытия видимых признаков наличия модуля в системе и, как следствие, невозможности его выгрузки.
Далее будут рассмотрены особенности применения данной техники с целью сокрытия видимых признаков наличия модуля в системе и, как следствие, невозможности его выгрузки.
+35
Встраивание в ядро Linux: перехват функций
9 min
17KПерехват функций ядра является базовым методом, позволяющим переопределять/дополнять различные его механизмы. Исходя из того, что ядро Linux почти полностью написано на языке C, за исключением небольших архитектурно-зависимых частей, можно утверждать, что для осуществления встраивания в большинство из компонентов ядра достаточно иметь возможность перехвата соответствующих функций.
Данная статья является продолжением анонсированного ранее цикла, посвящённого частным вопросам реализации наложенных средств защиты и, в частности, встраиванию в программные системы.
Данная статья является продолжением анонсированного ранее цикла, посвящённого частным вопросам реализации наложенных средств защиты и, в частности, встраиванию в программные системы.
+21
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Works in
- Date of birth
- Registered
- Activity