На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила трёх "С"
Пожалуйста,
1. Соблюдайте правила Форума.
2. Слушайте советы Модераторов.
(например, http://forum.sources.ru/index.php?act=ST&f=7&t=80382 )
3. Сверяйтесь с учебником по Великому и Могучему
Страницы: (4) [1] 2 3 ... Последняя » все  ( Перейти к последнему сообщению )  
> CHROOT'нутые. , Имеются ввиду сервера.
    Собственно, один из вариантов обеспечения безопасности -- ограничение доступа со стороны "левого" народа к файловой системе. Есть ещё и второй -- менее надёжный -- взлом пользователей сети Интернет с целью изменения кода ДНК. Мдаааа... Было бы не хило ещё и полное переливание крови произвести с умеренной радиотерапией костного мозга... :DDD

    Если разговор идёт об ограничении доступа со стороны "пользователей", то всё нормально решается и через стандартные "права доступа".

    А, если разговор идёт о серверах, да ещё работающих на порту менее 1024 и, как следствие, требующих запуска от рута? Чего делать? Нет, коллеги, сс@ь в ложку и топиться не стоит... :DDD Не наш путь... :DDD

    Беда здесь в том, что коз... (упс!) я хотел сказать "недоброжелатель" может в отношении сервера предпринять атаку (удалённую, как правило) типа "переполнение буфера" с выходом на запуск shell'а. В этом случае коз... (упс!) вы поняли... :D получит доступ к ФС на уровне прав рута. Допустить этого нельзя. Но сервер очень нужен. И по другому его не стартовать.

    Для этих-то целей и используется механизм change root jail или тюрьма с изменённым корнем. Т.е. демону подсоввывается некая псевдо-ФС, которую он воспринимает как рутовый раздел. Ниже мы будем это более-менее подробненько "разбирайтен".

    Только, оговорюсь сразу -- я привожу "стандартные" заклинания, которые подойдут к любому серверу, допускающему заключение в chroot. В принципе, большая часть демонов позволяет производить с собой такое "надругательство", однако, есть два НО:

    1. В Linux может быть на одном хосте не более 19 таких демонов, во FreeBSD -- 25. по-моему. Цифири точно не помню. Никогда в такое ограничение не упирался, т.к. ... ну представьте себе такой вот хост... :DDD

    2. Какие-нибудь древне-убогие серванты, не "понимающие" такого обращения с собой. Редко используемые, полу-сырые... Это может вообще не завестись. Кстати, как примечание -- вот по этой-то причине я и стараюсь быть "в струе". Т.е. пользоваться тем, чем в UNIX пользуется основная часть народа и что кажется мне наиболее осмысленным. Да и проблем меньше... :DDD
      у меня давно зреет идея, сделать какой-нить механизм разрешающий для нерутовых приложений биндинг сокетов с портами меньше 1024. Что-нить в духе

      echo "uid=xxx, port=yyy" > /proc/sys/net/ipv4/allow_binding

      как считаете - потенциальных дыр в безопасности не появится?
      Сообщение отредактировано: grustnoe -
        аха
        забиндится потом какой-нибудь юзерь на твоём серваке на 80-й (21-й, 53-й, 113-й или ещё какой) порт, а ты сиди и расхлёбывай потом, объясняй, что ты хороший и не вывешивал на заглавную страницу главного сервера компании детское порно.. =)
          1. Пользователь и группа.
          Надо создать именно такую группу и такого юзера, от "лица" которого сервант будет крутиться в системе.

          Банально -- groupadd, useradd, только при создании юзера, вместо shell'а указываем ему /dev/null (-s /dev/null).

          Домашний каталог -- до балды. Скажем, /home/servant -- ничем не хуже прочих вариантов.

          Заходим в этот каталог и создаём подкаталоги. Идея в том, чтобы создать структуру каталогов, аналогичную той, что вы видете при cd /.
          Делаем:
          ExpandedWrap disabled
             
            # mkdir dev;mkdir etc;mkdir usr;mkdir usr/sbin;mkdir var;mkdir var/run;mkdir lib;.....

          Здесь, ясен пень, не все. Только как пример. Чего надо добавить -- те каталоги, которые ваш сервант будет использовать для конфигов и подтесать вышеприведённый список под свою систему.

          Как опеределить чего надобно. Выберите все каталоги, которые не chroot'нутый демон использует (в /etc, /var, /tmp, /opt, ...). Короче, задачка на внимательность.

          Далее по списку все эти каталоги создём в /home/servant, считая этот каталог корневым.

          IMHO, ясно...

          Теперь либы. Вот здесь -- внимательнее. Дело в том, что теперь надо скурпулёзно разобраться с либам. Берём бинарник нашего демона и применяем к нему несложное заклинание ldd. Будут выведены все либы, которыми сей бинарник пользуется. Эти либы далее (по списиску, опять-таки), копируем в полученную иерархию каталогов. Копируем физически! А вот здесь -- внимание! В зависимости от демона, вам придётся или не придётся делать в новом /etc новый ld.so.conf и, как следствие, обрабатывать его новым /sbin/ldconfig... Дело в том, что на выходе ldconfig получается кэш ld.so.cache, содержащий имена из библиотек. ELF-бинарник получает имена из кэша и знает чего ему вызывать (упрощённая схема). Описывать надо подробную иерархию. Дело в том, что для ldconfig есть trusted каталоги (см. man). Если Вы не укажете свой каталог в trusted, то ldconfig на него не обратит никакого внимания. Учтите... :DDD

          Более лучший вариант.
          Кстати, можно создать такой кэш и использовав ldconfig с опцией -C имя_кэша, правда, надо ещё и -r имя_root_каталога указать. В этом случае нет необходимости
          переписывать бинарник ldconfig -- это "раз". А вот и "два" -- shared libs -- хорошее место для сокрытия backdoors. Т.е., учитывая открытость кода, довольно просто поправить такую либу, подсунуть её на место старой и произвести заклинание ldconfig. Далее. Пишем вполне безобидный (или модифицираем старый), выкладываем его в каталог (даже общедоступный -- админ редкко знает чего там и зачем). Ясное дело -- работаем от root'а. По завершении -- от любого пользователя, кому есть право исполнить этот файлец с нашей "закладкой".

          Ну, а дальше -- всё просто до безобразия. Как работает -- объяснять не надо? :DDD
          По этой причине не стоит безоглядно копировать файло...
          /****
          * Кстати, выше -- простой руткит. Очень простой. Но эффективный... Как автомат
          * Калашникова... :DDD
          * Именно rootkit, используемый как неактивный троян, используется для "болевого
          * удержания" системы под контролем. И выловить его крайне сложно, т.к. как
          * правило, проще переинсталлировать всё. Уничтожив следы взлома, как правило.
          * Реинсталл производиться должен только после того, как вы поняли как вас поимели!!!
          * Иначе -- просто не парьтесь. Не забивайте себе голову. Всё повторится.
          ****/

          Теперь разбираемся с conf-файлом (файлами) нашего демона. Столь же скурпулёзно, т.к. мало кто из авторов демонов думает что мы от chrootим их творение.

          Далее. Обеспечиваем демона инфой для работы.

          Во-первых, для того, чтобы логи писались с корректным временем, берём файл вашего часового пояса и копируем в свою иерархию каталогов. Т.е. в моём случае это будет /etc/localtime. В моём случае (да и в большинстве случаев) этот файлец -- ссылка на /usr/share/zoneinfo/Etc/ваша_зона. Так что, при копировании этого файла в /home/servant/etc, будет копироваться файл из /usr..... Учтите это.
          Всё это произойдёт несмотря на то, что вы копируете командой:
          ExpandedWrap disabled
             
            # cp /etc/localtime /home/servant/etc/localtime


          Теперь наш демон имеет "временную поправку", с которой он может работать.

          Во-вторых. Нам потребуется лог. Настраиваем демона syslog. Это отдельная тема, просто, настраивайте его на использование (в случае локального хранения логов) на /home/servant/где_в_вашей_системе_логи_хранятся.

          Впоследних. Для работы демона требуется два "девайса" -- /dev/null и /dev/urandom. Делаем их:
          ExpandedWrap disabled
             
            # cd /home/servant/dev
            # mknod -m 0666 null c 1 3
            # mknod -m 0664 urandom c 1 9

          Читать man mknod для системы. Старший и младщий номера девайса могут отличаться. Посмотрите на свои в "базовой" файловой системе.


          2. Запуск демона.
          Теперь демона надо стартовать.

          2.1 Надо в системных путях прописать что-то типа PATH = /home/servant/usr/sbin или где он там у вас. Причём, правим общесистемный профайл.
          2.2 Теперь правим скрипты, которые присутствуют в /etc/rc.d/*. Корректируем их на запуск демона из тюрьмы.

          В принципе, всё.

          3. Потенциальные грабли.
          Если демон вообще оборзел и не хочет стартовать, то, возможно, он не находит либы или какие-то конфиги ему не по вкусу. Ничего страшного. Наилучший выход здесь -- заклинание strace в отношении мерзавца. Т.е. strace (вполне возможно) покажет на чём приткнулось копыто демона или за что там хвост зацепился... :DDD Задача несколько не тривиальная.

          Далее. Либы. Как правило, некорректная работа с ними -- основная причина отказов демонов.

          Ещё одни грабли -- отсутствие старта syslog. Плохо это, но не смертельно. Надо:
          1. Попытаться рестартовать ещё раз syslog. Порой, этот демон погано себя ведёт и плохо читает свои конфиги. Если не стартует и Вы уверены, что всё правильно прописали, то рестарт хоста. Полный.

          2. Если не помогло и syslog так же не обрабатывает вашего демона, то Вы ошиблись -- переход на п.1.

          Enjoy! :D
            deil - не какой-нить, а специально созданный для данного демона. шелла у него нет.

            в общем-то сейчас любой грамотный демон после accept-а соединения делает seteuid - так что проблема немного надуманная :)
              CHROOT'нешься тут с вами :wacko: Столько всего еще надо узнать...
                Цитата

                в общем-то сейчас любой грамотный демон после accept-а соединения делает seteuid - так что проблема немного надуманная :)


                Аааа... "Бережёного Бог бережёт, а не бережёного -- конвой стережёт". Лучше их "упаковать" поотдельности (демонов). Так что, даже если кто и получит доступ к shell'у, то в районе тюрьмы. Вэлкам, плиз... :DDD Чего возжелали найтить? :DDD

                Это просто сохранит время при взломе. Т.е. послужит сигналом админу (если заметит) -- типа, "чувак, something is wrong, ты бы глянул, а?"... А там, пока взломщикк ещё эксплоит подберёт, пока то, пока сё, админ может приготовить адекватный ответ... Не более.
                  дайте мне рута, и я выйду из chroot :)
                    Угу... А теперь представь -- чудило ломает хост. Радостный такой... Wu-FTPd дырявый выискал... К примеру. Сломал... И... чего? :D

                    Получит ли он рута при таком раскладе? Ни фига. Т.е. ценность такого "получения" равна нулю. Т.к. для этого демона всё, что он видит (как процесс, а shellcode выстреливается из того же процесса и получает всё, что видит целевой демон) -- тюрьма. Ни backdoor ни поставить, ни rootkit не встремить... Ничего, т.к. к "родительской" ФС доступа нет. :DDD

                    А админ увидит, что кто-то его сервант завалил... Shellcode так просто не проходит. :DDD
                      ну, способов выхода можно придумать несколько:

                      создать файлы устройств и замонтировать физические партиции.

                      создать /dev/mem и писать туда.

                      загрузить lkm.

                      замонтировать /proc и там делов наворотить, основательно надругавшись над параметрами системы.

                      то же самое делается через sysctl

                      увидеть процессы и зацепиться к неchroot-нутому путем записи в его память

                      ...


                      так что, для рутовых сервисов chroot не панацея.
                      Сообщение отредактировано: grustnoe -
                        для этого придется закачать кучу прог
                          почему кучу-то? вообще никаких не надо. внедряешь простой код на чистых сисколлах. работает где угодно :)
                          Сообщение отредактировано: grustnoe -
                            Цитата

                            так что, для рутовых сервисов chroot не панацея.

                            Вообще-то панацеи нет... Вообще и ни от чего. :DDD

                            Далее. по идеям:
                            Цитата

                            1. создать файлы устройств и замонтировать физические партиции.
                            2. создать /dev/mem и писать туда.
                            3. загрузить lkm.
                            4. замонтировать /proc и там делов наворотить, основательно надругавшись над параметрами системы.
                            5. то же самое делается через sysctl
                            6. увидеть процессы и зацепиться к неchroot-нутому путем записи в его память


                            1. Нет. Откуда ты знаешь то, какие партиции вообще есть на данном хосте? :D В том-то и идея -- тюрьма мешает. :) Если монтировать партиции удалённо, то можно прицепиться. Но, опять-таки, что это даст? :)

                            2. Бога ради... И что тебе это даст? Как ты скажешь системе, что ты его создал и она должна его использовать? Такой файлец, как правило, есть... В настоящей корневой ФС. Опять тюрьма мешает.

                            Ладно. Ты умудрился сказать системе, что этот файл она должна использовать ("невозможное возможно, если верить в чудеса :D) Дальше-то как? Перезагрузить тачку? При взломе? Ну, тогда уж лучше прийти, похлопать админа по плечику и сказть -- "чувак, ты извини... я тя тут немного по-ломаю... ты не против?" :DDD

                            3. Не реально. Из chroot'нутого каталоге нет доступа к корневой ФС системы. А lkm надо... прогружать через modules (insmod сотоварищи). Но беда в том, что insmod остались в корневой ФС. В новой ФС их нет. Залить свои? Тогда придётся лить и либы. Компилятора в данной ФС так же не будет. :D И, если ты влил и либы, то тогда тебе надо опять /sbin/ldconfig делать. А это не всегда возможно... :)

                            Есть выход -- оборзеть, и собрать insmod в статическом режиме. Но контрмера -- как правило, серьёзные хосты защищены от lkm на уровне статической сборки (без модулей) ядра. Суди сам -- а зачем на веб-сервере модули ядра? Чего там динамически подгружать? Не чего. Железо стоит, собрано. Менять его каждый день не будешь... :D Так что, если у тебя роутер или сервер, то не бойся -- собирай ядро без поддержки модулей. Так безопаснее. :D

                            И, кстати, в таких системах нет ни компилятора, ни команды chown. А на серьёзных хостах -- даже перла, т.к. те же CGI'ки пишутся "под заказ" на С.

                            4. ФС /proc, как правило, ориентирована на чтение. Но /proc уже есть в корневой ФС. В новой -- она на фиг не нужна... :D Аналогично п. 2. :D

                            5. Не-а. И sysctl остаётся за пределами тюрьмы. :D И sysctl.conf так же.
                            Если мы про man sysctl (2) и каталог /proc/sys так же. Если мы про man sysctl (2), то те же яйца, вид сбоку (на С, имеется ввиду... :D) То же ничего не даёт. :D

                            6. Очень хлопотно. Т.е. это уже local exploit (и опять-таки через shellcode (либо стек, либо кучу сорвать)). Его надо:
                            - влить собранным (почему -- см. выше).
                            - обеспечить условия запуска.
                            - найти именно дырявый процесс. А от рута мало кто работает (раз) и два -- остальные демоны по тюрьмам сидят -- два. Прорыв из одной камеры в другую? :DDD

                            Нет... Это не панацея. Это усложнение жизни... скриптовым мальчуганам, которые думают что у них есть на всё эксплоит... :DDD

                            Добавлено в :
                            Цитата grustnoe @ 17.07.04, 21:50
                            почему кучу-то? вообще никаких не надо. внедряешь простой код на чистых сисколлах. работает где угодно :)

                            Хе-хе. Верно. Почти.
                            Дело в том, системные вызовы ядра использованы могут быть через либы демоном или вызываться в виде хекс-кодов операций напрямую из программы, причём, вызывается не программный код, а непосредственно машинные инструкции, располагающиеся в исполняемом процессе (ядре в данном случае, можно так же забраться и просто в процесс) (спасибо, grustnoe, я чего-то зарапортавался...). Однако. Проравться куда-то надо... А куда? :DDD Турма кругом... :DDD И твой дом турма... :DDD И демона... :D
                              сдается мне, вы не понимаете, как это реализовать. :)

                              the_Shadow, вот ты же упоминал про shell-код. Это бинарный код, который через уязвимость встраивается в приложение и получает управление, потом слушает на каком-нить порту и при соединии туда запускает шелл.

                              Но теперь отойдите от стандартного мышления. Мы имеем возможность загрузить любой бинарный код и выполнить. Зачем нам какие-то кучи софта и компилятор на атакуемой системе? зачем груды библиотек, когда можно дергать системные вызовы ядра. Зачем insmod, когда вставляющий модуль код можно загрузить удаленно?

                              ну, тоже по пунктам.

                              1. а что сложно узнать? создаем и пробуем открыть /dev/hd{abcd}X, /dev/sd{abcd..}X. код ошибки нам всё скажет.
                              можно замонтировать /proc и поглядеть в /proc/mounts
                              ...

                              2. ничуть не мешает. или ты считаешь что файлы устройств должны лежать в /dev? :)
                              ExpandedWrap disabled
                                 
                                [root@aero /] ls -l /dev/hda
                                brw-rw----    1 root     disk       3,   0 2004-05-12 11:57 /dev/hda
                                [root@aero /] mknod xxx b 3 0
                                [root@aero /] fdisk -l ./xxx
                                 
                                Disk ./xxx: 10.2 GB, 10248118272 bytes
                                16 heads, 63 sectors/track, 19857 cylinders
                                Units = cylinders of 1008 * 512 = 516096 bytes
                                 
                                Device Boot      Start         End      Blocks   Id  System
                                ./xxx1               1         653      329080+  82  Linux swap
                                ./xxx3             654        2979     1172304   83  Linux
                                ./xxx4            2980       19857     8506512   83  Linux

                              то же самое и в chroot-е прекрасно делается. можете проверить.
                              системе неважно, где находится файл устройства и как он называется. Это просто специальный файл, в котором хранятся major и minor номера устройства. Ядро при попытке open замечает, что открывается специальный файл и по этим номерам отфутболивает запрос соответствующему драйверу.

                              Ну, в общем это лечится флагом монтирования nodev партиции, тогда на ней файлы устройств не работают

                              3. всё что нужно, мы загрузим :)
                              вообще, /proc/kmem - память ядра, навороченный современный эксплоит сам куда-нить пропишется напрямую, да еще и спрячется

                              4.
                              ExpandedWrap disabled
                                 
                                [aero /] ls /proc
                                1      15773  521  590  611  635   bus          ide         meminfo     stat
                                14174  2      525  593  612  639   cmdline      interrupts  misc        swaps
                                14179  25688  527  594  613  641   cpuinfo      iomem       modules     sys
                                15102  25692  530  595  614  667   crypto       ioports     mounts      sysvipc
                                15205  3      535  6    615  668   devices      irq         mtrr        tty
                                15207  30123  537  606  616  669   dma          kcore       net         uptime
                                15208  4      539  607  617  670   driver       kmsg        partitions  version
                                15214  5      546  608  618  671   execdomains  ksyms       pci
                                15601  516    548  609  619  9     filesystems  loadavg     self
                                15771  519    551  610  620  acpi  fs           locks       slabinfo
                                [root@aero /] mkdir proc2
                                [root@aero /] mount proc /proc2 -t proc
                                [root@aero /] ls /proc2
                                1      15779  519  551  610  620  acpi         fs          locks       slabinfo
                                14174  15782  521  590  611  635  bus          ide         meminfo     stat
                                14179  2      525  593  612  639  cmdline      interrupts  misc        swaps
                                15102  25688  527  594  613  641  cpuinfo      iomem       modules     sys
                                15205  25692  530  595  614  667  crypto       ioports     mounts      sysvipc
                                15207  3      535  6    615  668  devices      irq         mtrr        tty
                                15208  30123  537  606  616  669  dma          kcore       net         uptime
                                15214  4      539  607  617  670  driver       kmsg        partitions  version
                                15601  5      546  608  618  671  execdomains  ksyms       pci
                                15771  516    548  609  619  9    filesystems  loadavg     self


                              у меня в chroot жил slack-3.5. и /proc из под chroot прекрасно монтировался

                              не знаю, ориентирована ли она на чтение, но /proc/sys ориентирована на настройку системы.
                              а /proc/$pid/mem - вообще доступ к памяти процесса $pid

                              цитата из man 5 proc:
                              fd This is a subdirectory containing one entry for each
                              file which the process has open, named by its file
                              descriptor, and which is a symbolic link to the actual
                              file (as the exe entry does). Thus, 0 is standard
                              input, 1 standard output, 2 standard error, etc.

                              mem Via the mem file one can access the pages of a pro╜
                              cess's memory through open(2), read(2), and fseek(3).

                              sys This directory (present since 1.3.57) contains a number of
                              files and subdirectories corresponding to kernel variables.
                              These variables can be read and sometimes modified using the
                              proc file system, and the sysctl(2) system call. Presently,
                              there are subdirectories abi, debug, dev, fs, kernel, net,
                              proc, rxrpc, sunrpc and vm that each contain more files and
                              subdirectories.
                                Цитата

                                the_Shadow, вот ты же упоминал про shell-код. Это бинарный код, который через уязвимость встраивается в приложение и получает управление, потом слушает на каком-нить порту и при соединии туда запускает шелл.

                                Какой, в нашем случае? /dev/null? Или из "общесистемных" каталогов? Демону shell не нужен... :) Можно подгрузить со своей тачки... Можно. См. ниже. :D

                                Цитата

                                Зачем insmod, когда вставляющий модуль код можно загрузить удаленно?

                                Можно. Если подгружать, скажем, с какого-то контролируемого тобою shell'а. А теперь смотри -- ты работаешь под фряхой, а ломаешь линя... :D Или наоборот. Или ьы сидишь под солярой, а ломаешь фряху... :D Это можно, но это -- хлопотно! Т.е. до взлома ты должен быть морально готов к неожиданностям.

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

                                Или реализовать их работу. Эксплоит -- "виртуальная машина"? Да, ещё и в режиме распределения по сети? Не плохо... :D

                                Цитата

                                1. а что сложно узнать? создаем и пробуем открыть /dev/hd{abcd}X, /dev/sd{abcd..}X. код ошибки нам всё скажет.
                                можно замонтировать /proc и поглядеть в /proc/mounts

                                Угу. Если только у тебя хватит на это времени и если у тебя есть доступ к /proc... :D Его быть не должно. Ты можешь создать свой... Но что это даст?

                                Цитата

                                то же самое и в chroot-е прекрасно делается. можете проверить.
                                системе неважно, где находится файл устройства и как он называется. Это просто специальный файл, в котором хранятся major и minor номера устройства. Ядро при попытке open замечает, что открывается специальный файл и по этим номерам отфутболивает запрос соответствующему драйверу.


                                Делается! Но давай теперь подумаем -- а как ядру сказать что ты обращаешься к девайсу?
                                И именно твоему? Для каждого девайса есть модуль, так? Он либо "утоптан" в ядро, либо лежит как модуль. А я уже писал про сборку ядра без поддержки модулей. Т.е. хоть ты чего ему грузи -- он тебя не поймёт. При таком раскладе.

                                Цитата

                                Ну, в общем это лечится флагом монтирования nodev партиции, тогда на ней файлы устройств не работают

                                :D Сам знаешь... :D

                                Цитата

                                3. всё что нужно, мы загрузим :)
                                вообще, /proc/kmem - память ядра, навороченный современный эксплоит сам куда-нить пропишется напрямую, да еще и спрячется

                                Эхххх... Зря я забыл написать о блокировании поддержки файловой системы /proc при конфигурации ядра... А ведь можно и её в /dev/null отправить... :D И безболезненно... Кстати, где-то в более ранних топиках писал.

                                А зачем она? На хосте, где всё и так известно? Для контроля? Да ну... на фиг... :DDD
                                Это ввела первая S.U.S.E. -- пресловуьый немецкий дистрибутив, "отличающийся надёжностью". Есть даже стиль администрирования от S.U.S.E. -- когда утиль сам невесть чего в /proc делает. Итак, хост вполне "живёт" и без /proc -- прошу принять дополнение... :D
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0462 ]   [ 15 queries used ]   [ Generated: 29.03.24, 15:41 GMT ]