Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[44.195.23.152] |
|
Страницы: (4) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Собственно, один из вариантов обеспечения безопасности -- ограничение доступа со стороны "левого" народа к файловой системе. Есть ещё и второй -- менее надёжный -- взлом пользователей сети Интернет с целью изменения кода ДНК. Мдаааа... Было бы не хило ещё и полное переливание крови произвести с умеренной радиотерапией костного мозга... :DDD
Если разговор идёт об ограничении доступа со стороны "пользователей", то всё нормально решается и через стандартные "права доступа". А, если разговор идёт о серверах, да ещё работающих на порту менее 1024 и, как следствие, требующих запуска от рута? Чего делать? Нет, коллеги, сс@ь в ложку и топиться не стоит... :DDD Не наш путь... :DDD Беда здесь в том, что коз... (упс!) я хотел сказать "недоброжелатель" может в отношении сервера предпринять атаку (удалённую, как правило) типа "переполнение буфера" с выходом на запуск shell'а. В этом случае коз... (упс!) вы поняли... получит доступ к ФС на уровне прав рута. Допустить этого нельзя. Но сервер очень нужен. И по другому его не стартовать. Для этих-то целей и используется механизм change root jail или тюрьма с изменённым корнем. Т.е. демону подсоввывается некая псевдо-ФС, которую он воспринимает как рутовый раздел. Ниже мы будем это более-менее подробненько "разбирайтен". Только, оговорюсь сразу -- я привожу "стандартные" заклинания, которые подойдут к любому серверу, допускающему заключение в chroot. В принципе, большая часть демонов позволяет производить с собой такое "надругательство", однако, есть два НО: 1. В Linux может быть на одном хосте не более 19 таких демонов, во FreeBSD -- 25. по-моему. Цифири точно не помню. Никогда в такое ограничение не упирался, т.к. ... ну представьте себе такой вот хост... :DDD 2. Какие-нибудь древне-убогие серванты, не "понимающие" такого обращения с собой. Редко используемые, полу-сырые... Это может вообще не завестись. Кстати, как примечание -- вот по этой-то причине я и стараюсь быть "в струе". Т.е. пользоваться тем, чем в UNIX пользуется основная часть народа и что кажется мне наиболее осмысленным. Да и проблем меньше... :DDD |
Сообщ.
#2
,
|
|
|
у меня давно зреет идея, сделать какой-нить механизм разрешающий для нерутовых приложений биндинг сокетов с портами меньше 1024. Что-нить в духе
echo "uid=xxx, port=yyy" > /proc/sys/net/ipv4/allow_binding как считаете - потенциальных дыр в безопасности не появится? |
Сообщ.
#3
,
|
|
|
аха
забиндится потом какой-нибудь юзерь на твоём серваке на 80-й (21-й, 53-й, 113-й или ещё какой) порт, а ты сиди и расхлёбывай потом, объясняй, что ты хороший и не вывешивал на заглавную страницу главного сервера компании детское порно.. =) |
Сообщ.
#4
,
|
|
|
1. Пользователь и группа.
Надо создать именно такую группу и такого юзера, от "лица" которого сервант будет крутиться в системе. Банально -- groupadd, useradd, только при создании юзера, вместо shell'а указываем ему /dev/null (-s /dev/null). Домашний каталог -- до балды. Скажем, /home/servant -- ничем не хуже прочих вариантов. Заходим в этот каталог и создаём подкаталоги. Идея в том, чтобы создать структуру каталогов, аналогичную той, что вы видете при cd /. Делаем: # 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..... Учтите это. Всё это произойдёт несмотря на то, что вы копируете командой: # cp /etc/localtime /home/servant/etc/localtime Теперь наш демон имеет "временную поправку", с которой он может работать. Во-вторых. Нам потребуется лог. Настраиваем демона syslog. Это отдельная тема, просто, настраивайте его на использование (в случае локального хранения логов) на /home/servant/где_в_вашей_системе_логи_хранятся. Впоследних. Для работы демона требуется два "девайса" -- /dev/null и /dev/urandom. Делаем их: # 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! |
Сообщ.
#5
,
|
|
|
deil - не какой-нить, а специально созданный для данного демона. шелла у него нет.
в общем-то сейчас любой грамотный демон после accept-а соединения делает seteuid - так что проблема немного надуманная |
Сообщ.
#6
,
|
|
|
CHROOT'нешься тут с вами Столько всего еще надо узнать...
|
Сообщ.
#7
,
|
|
|
Цитата в общем-то сейчас любой грамотный демон после accept-а соединения делает seteuid - так что проблема немного надуманная Аааа... "Бережёного Бог бережёт, а не бережёного -- конвой стережёт". Лучше их "упаковать" поотдельности (демонов). Так что, даже если кто и получит доступ к shell'у, то в районе тюрьмы. Вэлкам, плиз... :DDD Чего возжелали найтить? :DDD Это просто сохранит время при взломе. Т.е. послужит сигналом админу (если заметит) -- типа, "чувак, something is wrong, ты бы глянул, а?"... А там, пока взломщикк ещё эксплоит подберёт, пока то, пока сё, админ может приготовить адекватный ответ... Не более. |
Сообщ.
#8
,
|
|
|
дайте мне рута, и я выйду из chroot
|
Сообщ.
#9
,
|
|
|
Угу... А теперь представь -- чудило ломает хост. Радостный такой... Wu-FTPd дырявый выискал... К примеру. Сломал... И... чего?
Получит ли он рута при таком раскладе? Ни фига. Т.е. ценность такого "получения" равна нулю. Т.к. для этого демона всё, что он видит (как процесс, а shellcode выстреливается из того же процесса и получает всё, что видит целевой демон) -- тюрьма. Ни backdoor ни поставить, ни rootkit не встремить... Ничего, т.к. к "родительской" ФС доступа нет. :DDD А админ увидит, что кто-то его сервант завалил... Shellcode так просто не проходит. :DDD |
Сообщ.
#10
,
|
|
|
ну, способов выхода можно придумать несколько:
создать файлы устройств и замонтировать физические партиции. создать /dev/mem и писать туда. загрузить lkm. замонтировать /proc и там делов наворотить, основательно надругавшись над параметрами системы. то же самое делается через sysctl увидеть процессы и зацепиться к неchroot-нутому путем записи в его память ... так что, для рутовых сервисов chroot не панацея. |
Сообщ.
#11
,
|
|
|
для этого придется закачать кучу прог
|
Сообщ.
#12
,
|
|
|
почему кучу-то? вообще никаких не надо. внедряешь простой код на чистых сисколлах. работает где угодно
|
Сообщ.
#13
,
|
|
|
Цитата так что, для рутовых сервисов chroot не панацея. Вообще-то панацеи нет... Вообще и ни от чего. :DDD Далее. по идеям: Цитата 1. создать файлы устройств и замонтировать физические партиции. 2. создать /dev/mem и писать туда. 3. загрузить lkm. 4. замонтировать /proc и там делов наворотить, основательно надругавшись над параметрами системы. 5. то же самое делается через sysctl 6. увидеть процессы и зацепиться к неchroot-нутому путем записи в его память 1. Нет. Откуда ты знаешь то, какие партиции вообще есть на данном хосте? В том-то и идея -- тюрьма мешает. Если монтировать партиции удалённо, то можно прицепиться. Но, опять-таки, что это даст? 2. Бога ради... И что тебе это даст? Как ты скажешь системе, что ты его создал и она должна его использовать? Такой файлец, как правило, есть... В настоящей корневой ФС. Опять тюрьма мешает. Ладно. Ты умудрился сказать системе, что этот файл она должна использовать ("невозможное возможно, если верить в чудеса ) Дальше-то как? Перезагрузить тачку? При взломе? Ну, тогда уж лучше прийти, похлопать админа по плечику и сказть -- "чувак, ты извини... я тя тут немного по-ломаю... ты не против?" :DDD 3. Не реально. Из chroot'нутого каталоге нет доступа к корневой ФС системы. А lkm надо... прогружать через modules (insmod сотоварищи). Но беда в том, что insmod остались в корневой ФС. В новой ФС их нет. Залить свои? Тогда придётся лить и либы. Компилятора в данной ФС так же не будет. И, если ты влил и либы, то тогда тебе надо опять /sbin/ldconfig делать. А это не всегда возможно... Есть выход -- оборзеть, и собрать insmod в статическом режиме. Но контрмера -- как правило, серьёзные хосты защищены от lkm на уровне статической сборки (без модулей) ядра. Суди сам -- а зачем на веб-сервере модули ядра? Чего там динамически подгружать? Не чего. Железо стоит, собрано. Менять его каждый день не будешь... Так что, если у тебя роутер или сервер, то не бойся -- собирай ядро без поддержки модулей. Так безопаснее. И, кстати, в таких системах нет ни компилятора, ни команды chown. А на серьёзных хостах -- даже перла, т.к. те же CGI'ки пишутся "под заказ" на С. 4. ФС /proc, как правило, ориентирована на чтение. Но /proc уже есть в корневой ФС. В новой -- она на фиг не нужна... Аналогично п. 2. 5. Не-а. И sysctl остаётся за пределами тюрьмы. И sysctl.conf так же. Если мы про man sysctl (2) и каталог /proc/sys так же. Если мы про man sysctl (2), то те же яйца, вид сбоку (на С, имеется ввиду... ) То же ничего не даёт. 6. Очень хлопотно. Т.е. это уже local exploit (и опять-таки через shellcode (либо стек, либо кучу сорвать)). Его надо: - влить собранным (почему -- см. выше). - обеспечить условия запуска. - найти именно дырявый процесс. А от рута мало кто работает (раз) и два -- остальные демоны по тюрьмам сидят -- два. Прорыв из одной камеры в другую? :DDD Нет... Это не панацея. Это усложнение жизни... скриптовым мальчуганам, которые думают что у них есть на всё эксплоит... :DDD Добавлено в : Цитата grustnoe @ 17.07.04, 21:50 почему кучу-то? вообще никаких не надо. внедряешь простой код на чистых сисколлах. работает где угодно Хе-хе. Верно. Почти. Дело в том, системные вызовы ядра использованы могут быть через либы демоном или вызываться в виде хекс-кодов операций напрямую из программы, причём, вызывается не программный код, а непосредственно машинные инструкции, располагающиеся в исполняемом процессе (ядре в данном случае, можно так же забраться и просто в процесс) (спасибо, grustnoe, я чего-то зарапортавался...). Однако. Проравться куда-то надо... А куда? :DDD Турма кругом... :DDD И твой дом турма... :DDD И демона... |
Сообщ.
#14
,
|
|
|
сдается мне, вы не понимаете, как это реализовать.
the_Shadow, вот ты же упоминал про shell-код. Это бинарный код, который через уязвимость встраивается в приложение и получает управление, потом слушает на каком-нить порту и при соединии туда запускает шелл. Но теперь отойдите от стандартного мышления. Мы имеем возможность загрузить любой бинарный код и выполнить. Зачем нам какие-то кучи софта и компилятор на атакуемой системе? зачем груды библиотек, когда можно дергать системные вызовы ядра. Зачем insmod, когда вставляющий модуль код можно загрузить удаленно? ну, тоже по пунктам. 1. а что сложно узнать? создаем и пробуем открыть /dev/hd{abcd}X, /dev/sd{abcd..}X. код ошибки нам всё скажет. можно замонтировать /proc и поглядеть в /proc/mounts ... 2. ничуть не мешает. или ты считаешь что файлы устройств должны лежать в /dev? [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. [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. |
Сообщ.
#15
,
|
|
|
Цитата the_Shadow, вот ты же упоминал про shell-код. Это бинарный код, который через уязвимость встраивается в приложение и получает управление, потом слушает на каком-нить порту и при соединии туда запускает шелл. Какой, в нашем случае? /dev/null? Или из "общесистемных" каталогов? Демону shell не нужен... Можно подгрузить со своей тачки... Можно. См. ниже. Цитата Зачем insmod, когда вставляющий модуль код можно загрузить удаленно? Можно. Если подгружать, скажем, с какого-то контролируемого тобою shell'а. А теперь смотри -- ты работаешь под фряхой, а ломаешь линя... Или наоборот. Или ьы сидишь под солярой, а ломаешь фряху... Это можно, но это -- хлопотно! Т.е. до взлома ты должен быть морально готов к неожиданностям. Твой сплоит должен не столько взломать самого демона, сколько и обеспечить проход в систему ряду утилит. Или реализовать их работу. Эксплоит -- "виртуальная машина"? Да, ещё и в режиме распределения по сети? Не плохо... Цитата 1. а что сложно узнать? создаем и пробуем открыть /dev/hd{abcd}X, /dev/sd{abcd..}X. код ошибки нам всё скажет. можно замонтировать /proc и поглядеть в /proc/mounts Угу. Если только у тебя хватит на это времени и если у тебя есть доступ к /proc... Его быть не должно. Ты можешь создать свой... Но что это даст? Цитата то же самое и в chroot-е прекрасно делается. можете проверить. системе неважно, где находится файл устройства и как он называется. Это просто специальный файл, в котором хранятся major и minor номера устройства. Ядро при попытке open замечает, что открывается специальный файл и по этим номерам отфутболивает запрос соответствующему драйверу. Делается! Но давай теперь подумаем -- а как ядру сказать что ты обращаешься к девайсу? И именно твоему? Для каждого девайса есть модуль, так? Он либо "утоптан" в ядро, либо лежит как модуль. А я уже писал про сборку ядра без поддержки модулей. Т.е. хоть ты чего ему грузи -- он тебя не поймёт. При таком раскладе. Цитата Ну, в общем это лечится флагом монтирования nodev партиции, тогда на ней файлы устройств не работают Сам знаешь... Цитата 3. всё что нужно, мы загрузим вообще, /proc/kmem - память ядра, навороченный современный эксплоит сам куда-нить пропишется напрямую, да еще и спрячется Эхххх... Зря я забыл написать о блокировании поддержки файловой системы /proc при конфигурации ядра... А ведь можно и её в /dev/null отправить... И безболезненно... Кстати, где-то в более ранних топиках писал. А зачем она? На хосте, где всё и так известно? Для контроля? Да ну... на фиг... :DDD Это ввела первая S.U.S.E. -- пресловуьый немецкий дистрибутив, "отличающийся надёжностью". Есть даже стиль администрирования от S.U.S.E. -- когда утиль сам невесть чего в /proc делает. Итак, хост вполне "живёт" и без /proc -- прошу принять дополнение... |