Закрепление в системе

[b3]

Не знаю есть ли смысл общаться на эту тему в открытом форуме вам, но все же хотелось бы увидеть ваши наработки или идеи по закреплению в системе после получения шела/рута.

ЗЫ Только что лазил по конфигам апача и пришла идея прятать бэки в папке /icons/ которая алиас у апача:

#    Alias /icons/ "/usr/share/apache2/icons/"
<Directory "/usr/share/apache2/icons">
        Options Indexes MultiViews
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

но данный алиас может работать не для всех доменов на сервере, ПХП код исполняется, но запись в диру только от рута.

[yesday]

Ну, начнём с того, что ни один способ не гарантирует 100% закрепления (при наличии толковых админов, конечно).
Ядерный руткит - попробуй найди под последние ядра
Юзермодный руткит - первое что сделает любой толковый админ при малейшем палеве - это проверит /etc/{ld.so*,modules} и т.п. + /proc/modules
Пересборка бинарей - на rpm-based дистрибах rpm -V ... мигом вас спалит, для deb-based всё немного проще, по-умолчанию пакеты верифицировать в них нельзя.

Как мне кажется, наиболее надёжный способ - сборка своей РПМки/дебки с патченым SSH (к примеру). Тогда сервак сойдёт только после переустановки ОС/апгрейда пакета. От апгрейда пакета может спасти высокий номер версии (чтобы пакетный менеджер думал что у нас стоит самая распоследняя версия, и не трогал).

[chupakabra]

Ядерный руткит - попробуй найди под последние ядра

Последние ядра ничем особо выдающимся не отличаются от 2.6.*. Имея мозг и прямые руки, хотя бы можно доделать любой пабликовый LKM-руткит.

Как мне кажется, наиболее надёжный способ - сборка своей РПМки/дебки с патченым SSH (к примеру). Тогда сервак сойдёт только после переустановки ОС/апгрейда пакета. От апгрейда пакета может спасти высокий номер версии (чтобы пакетный менеджер думал что у нас стоит самая распоследняя версия, и не трогал).

Хороший способ

[yesday]

Сообщение от chupakabra

Последние ядра ничем особо выдающимся не отличаются от 2.6.*. Имея мозг и прямые руки, хотя бы можно доделать любой пабликовый LKM-руткит.

Тру. Но я на собственном опыте испытал - 2.6.18 и ниже - всё ок.
После .18 разработчики заныкали адрес syscall_table_entry так, что фиг найдёшь (это что касается перехвата системных вызовов).
Если просто бекдор в ядро встроить - то тут да, поле непаханое.

Ещё как вариант - пересобрать initrd и встроить какойнить dropbear+busybox прям в него. После ближайшего ребута - вуаля, логинься-работай, и без палева.

[SynQ]

Чтобы юзать LKM (серьезный) нужно самому разбираться в коде ядра. Если к кому-то в руки попадет свежий лкм-руткит, то он недолго будет сохранять актуальность, ибо нужна постоянная доработка.

Нестабильный kernel API - это головняк для всех драйверописателей, но в тоже время хорошо влияет на безопасность ядра, если его обновлять.

[yesday]

Сообщение от SynQ

Чтобы юзать LKM (серьезный) нужно самому разбираться в коде ядра. Если к кому-то в руки попадет свежий лкм-руткит, то он недолго будет сохранять актуальность, ибо нужна постоянная доработка.

Что понимать под "серьёзный LKM"? Принцип то везде один.
Проблем то по большому счёту - две.
1. Собрать LKM (все же помнят анекдот про "вирус для Линукс"?)
2. Вовремя обновить модуль, когда в системе обновится ядро.

теория mode on

Решение первой проблемы - прямые руки и чуть понимания как работают модули ядра в linux.
Со вторым чуть сложнее, но тоже реализуемо - берём все боль-мень актуальные дистрибутивы (Fedora 13-16, RHEL/CentOS 5,6 , Debian 5,6), смотрим, какие ядра идут с дистрибами. Рожаем гденить у себя виртуалку, и на ней ставим все возможные ядра, под каждое собираем свой модуль. Далее, следим за обновлением дистрибутивных ядер - и вовремя апдейтим модуль (в сам модуль можно встроить перехват события "ставится новое ядро, версия такая-то", и по этому событию стягивать откуда надо наш модуль).

теория mode off

В реальности - всё зависит от целей. Ответив на вопрос "Зачем мне закрепляться в системе" -- метод придёт сам собой.

[16bit]

возможно,SynQ имел ввиду сложности отладки.
есть некоторые нюансы,которые обычно вылазят на серверах с нестандартной конфигурацией.
Отлаживать такие штуки ой как не просто,так как для правильной отладки нужно как минимум иметь под рукой подобное железо.

[yesday]

Ну, LKM-киты обычно не сильно зависят от именно конфига железа.
Я например VirtualBox юзаю - поднял из темплейта систему, накатил нужное ядро - и играешься до посинения. Ну для этого, как и сказал SynQ, нужно понимание процессов, которые происходят в ядре при работе.

[SynQ]

Сообщение от yesday

Со вторым чуть сложнее, но тоже реализуемо - берём все боль-мень актуальные дистрибутивы (Fedora 13-16, RHEL/CentOS 5,6 , Debian 5,6), смотрим, какие ядра идут с дистрибами. Рожаем гденить у себя виртуалку, и на ней ставим все возможные ядра, под каждое собираем свой модуль.

Все так, особенно для дистрибутивов на stable версии ядра (rhel/centos), но там где надо адаптировать лкм под версии, на которых он не тестировался, может быть очень много проблем, например для сетевой части - структуры могут меняться, где-то можно не знать, что теперь надо ставить мутекс или спинлок, из-за этого у себя в виртуалке может и будет хорошо работать, а на сервере будет необъяснимо падать раз в неделю или при большом траффике. И чем сложнее модуль ядра (для перехвата одного сисколла по-моему нет смысла ставить лкм), тем больше таких мест. Поэтому если нет хорошего понимания внутреннего устройства ядра, лкм по большей части дохлый номер. Это на мой взгляд.

В реальности - всё зависит от целей.

Угу, на мой взгляд, лкм - точечный способ для очень важных целей.

[chupakabra]

Все так, особенно для дистрибутивов на stable версии ядра (rhel/centos), но там где надо адаптировать лкм под версии, на которых он не тестировался, может быть очень много проблем, например для сетевой части - структуры могут меняться, где-то можно не знать, что теперь надо ставить мутекс или спинлок, из-за этого у себя в виртуалке может и будет хорошо работать, а на сервере будет необъяснимо падать раз в неделю или при большом траффике. И чем сложнее модуль ядра (для перехвата одного сисколла по-моему нет смысла ставить лкм), тем больше таких мест. Поэтому если нет хорошего понимания внутреннего устройства ядра, лкм по большей части дохлый номер. Это на мой взгляд.

Согласен полностью, да нужно под каждую версию ядра тестировать и дописывать. Слава богу, Open Source, ничего реверсить не нужно, всё открыто и на блюдечке, просто много кропотливой работы + тестирование. Я сейчас этим занимаюсь в свободное время.