Зачем мне твой баш, если я могу заливать файлы и выполнять php-код?
повысить привилегии, получить рут-доступ
Диск можно просто примонтировать и отмонтировать, получишь сброс рута.
так мой способ на корню отрубает рутование
к тому же взломщик после первого рутования может всю систему засрать хз чем
И зачем мне для этого баш, если я могу залить скомпилированный эксплоит, а потом запустить его из php через exec/proc_open/passthru (или что там не требует баша)? У тебя какое-то странное представление о php — я понимаю, это вообще-то не язык, но с его помощью тоже можно управлять системой, как и любым другим ЯП.
Давай эксперимент проведём: ты настроишь такой сервер, закинешь ему в index.php бекдор на php, а потом скинешь сюда.
Чувак, для этого обычно ставят левым юзерам в /etc/passwd шелл
/bin/false, /bin/nologin или /bin/date
тот же самый эффект, только можно настроить отдельно на каждого юзера и не менять права системных файлов.
ваш кеп
Ты таки неправ. По факту так: залил себе WSO-шел, и через веб получил возможность выполнять команды. Пхп позволяет запускать команды через баш, хотя юзер www-data имеет шелл /bin/false. Мой же способ решает проблему на корню.
>запустить его из php через exec/proc_open/passthru (или что там не требует баша)?
Как раз это и требует баш. Так что нет, скомпилированный эксплоит ты не запустишь.
https://www.amazon.com/How-Linux-Works-Superuser-Should/dp/1593275676/ref=pd_sim_14_6?_encoding=UTF8&psc=1&refRID=J63ACH4R8HPDMQRT776D
Почитайте уже хотя бы любую инструкцию к инструменту которым собрались пользоваться.
Предложенное решение может сломать систему. Менять режим доступа системных дирей - это дичь.
Пока ничего не сломалось, все норм работает, база и сервер пашут без проблем.
Это не дичь, а а стандартное средство обеспечение безопасности: максимальное ограничение прав пользователей. Простым юзерам доступ к /bin, /sbin и /etc не нужен.
Это не дичь, а обеспечение безопасности сервера через DAC.
>Пока ничего не сломалось
>Пока
ну и я так понимаю у тебя там кокойто LAMP и ничо особо сложного, такшо не кажи гоп поки не перестрибнеш, может какой-то сервайс и споткнется об это однажды
>Простым юзерам доступ к /bin, /sbin и /etc не нужен.
это нужно делать путем грамотной настройки групп, какими-то AppArmor, SeLinux и прочей заточенной на это хуйней, а не блять меняя режим доступа системных файлов
Ну так и не для сложных систем эта схема, понятное дело.
В свежеустановленном дебиан-сервере только от рута процессы и работают, так что запрет на директории простым юзерам устойчивости сервера не грозит.
И да, против мандатного конроля доступа ничего не имею.
Хочу обратить внимание на тот факт, что разобраться с профилями аппармор можно за несколько часов, освоить селинукс можно за несколько дней, а сменить права ни три директории - несколько секунд. Почувствуй разницу. Это простое и сердитое решение для маленьких веб-серверов.
>Ну так и не для сложных систем эта схема, понятное дело.
>В свежеустановленном дебиан-сервере только от рута процессы и работают, так что запрет на директории простым юзерам устойчивости сервера не грозит.
Блять, это многопользовательская система и не твоя персональная, понимаешь? Через пол года ты можешь убежать на новое место, придет другой админ, поставит пару пакетов, охуеет с их неочевидного поведения и поверь мне, в тот момент, когда он докопается до истины, он проклянет тебя так, что мало не покажется.
Мимо исправлявший наследие предшественников
>Как раз это и требует баш
Действительно, причём все из них. Я думал, что кто-то не требует, и есть аналог exec-функций из C.
>В свежеустановленном дебиан-сервере только от рута процессы и работают
Апач от www-data работает. Кстати, у тебя не возник вопрос, как он получает доступ к своим конфигам, если они в /etc?
>Апач от www-data работает
В свежеустановленном сервере нет апача, если это действительно минимальная установка по сети без отметки ламп-сервера.
>Кстати, у тебя не возник вопрос, как он получает доступ к своим конфигам, если они в /etc?
Возникал конечно. И действительно, lighttpd как раз поэтому не запустается в такой конфигурации. В отличие от nginx и apache.
Вероятно, конфиги на старте считывает рут, а уж потом права падают до www-data.
>Блять, это многопользовательская система и не твоя персональная, понимаешь?
Пользователи веб-сервера должны делать только то, что им действительно необходимо. Веб сервер выполняет узкую задачу - раздает сайты, и права на /etc и /bin им ни в коей мере не нужны. Как раз таки свободный доступ к этим директориям и является дырой безопасности.
>Давай эксперимент проведём: ты настроишь такой сервер, закинешь ему в index.php бекдор на php, а потом скинешь сюда.
Ок.
http://5mo3467jwq4kcuz5.onion/f/ - форум в торе. Шеллы в его кэше:
http://5mo3467jwq4kcuz5.onion/f/cache/WSO.php
root
http://5mo3467jwq4kcuz5.onion/f/cache/wso.php
admin
В идеале вы должны определить айпи сервера и получить рут. Твори, анон! Сервер крутится у меня на виртуалочке.
>нет апача
У тебя-то есть.
Просто помни, что это костыль и не жалуйся, когда апачу зачем-то понадобится доступ в те директории, в которые он должен его иметь. И не удивляйся, если тебя вдруг поимеют через какой-нибудь финт вроде подгрузки расширения и выполнения кода через чей-нибудь конфиг. Хотя на скриптах за пять минут такое не запилишь, конечно.
> апачу зачем-то понадобится доступ в те директории, в которые он должен его иметь
В текущем виде директроий ему хватает, а что сверх этого - излишество и дыра.
>поимеют через какой-нибудь финт вроде подгрузки расширения и выполнения кода через чей-нибудь конфиг
Щито? Подгрузки расширения чего?
>хватает
Сейчас хватает, а если придётся запускать что-то сложнее форумчика? Уверен, что он не захочет прочитать что-то в /etc, будучи уже под юзером www-data?
>Подгрузки расширения чего?
Расширения php, очевидно же. https://forum.antichat.ru/threads/70763/
К счастью, на настройках по умолчанию такой фокус не провернёшь.
Взял и запретил www-data использовать сеть, да? А я думал так быстренько взять узнать твой IP.
Хз что ты имеешь в виду под запретом сети, но через iptables настроена прозрачная маршрутизация через тор. Так что чтоб узнайть мой айпи получи сначала рут и поправь правила iptables.
Это и имел в виду.
ну чё там, баш взлетел? бинарь запустился ли?
Зачем тебе это? Отруби просто все исходящие конекты, если тебя взломают не супер юсера смогут выходить в нет. Посмотри так же в сторону SELinux, с этой штукой даже под рутом запариться можно.
>Зачем тебе это? Отруби просто все исходящие конекты, если тебя взломают, получат аккаунт не супер юсера, не смогут выходить в нет. Посмотри так же в сторону SELinux, с этой штукой даже под рутом запариться можно.
Выше писал же: селинукс изучается дни, а три команды выполняются за секунды. Так-то я еще в аппармор могу. Но запрет директорий безопасности не повредит.
>настроена прозрачная маршрутизация через тор
Погоди-ка, ты спиздел. Если бы у тебя была прозрачная маршрутизация, пикрелейтед выдал бы IP выходной ноды.
Хуйня. Все бинарники можно залить отдельно.
Тред не читай @ Хуйню отвечай.
>а три команды выполняются за секунды.
а можно ваще rm -rf и точно ни одного вируса
Ебать вы мудреные ребята, мне бы таким быть.
Хз о чем ты, все по инструкции делал.
https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
В предлагаемом мной способе сохраняется нормальная работоспособность сервера и бызы, в отличие от твоего.
>LAMP и ничо особо сложного, такшо не кажи гоп поки не перестрибнеш, может какой-то сервайс и споткнется об это однажды
Так и об селинукс споткнуться может. Проблемы нужно решать по мере поступления.
Блять, это многопользовательская система и не твоя персональная, понимаешь?
Никто ж не запрещает использовать более тонкую настройку, например:
groupadd -r shells
usermod -a -G shells user3
chown root:shells /bin/bash
chown root:shells /bin/dash
chmod 0750 /bin/bash
chmod 0750 /bin/dash
- www-data и mysql также теряют доступ к оболочке, но у простых юзеров он сохраняется.
Можно и так:
groupadd -r exe
usermod -a -G exe user3
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
- пользователи кроме root и user3 теряют доступ к оболочкам, конфигам и исполняемым файлам.
groupadd -r exe
usermod -a -G exe user3
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
- пользователи кроме root и user3 теряют доступ к оболочкам, конфигам и исполняемым файлам.
А почему тогда запросы от имени твоего веб-сервера фейлятся? getaddrinfo failed — стало быть, даже DNS не разрешаются.
>стало быть, даже DNS не разрешаются
Так доступа к /etc нет же у www-data, /etc/resolv.conf недоступен
вроде ж у меня только .pth debian-tor имеет доступ к внешней сети
Видимо, да. А зачем тебе тогда там проксирование, лол? Для скрытого сервиса достаточно просто запустить тор (ну и дропать всё, кроме debian-tor).
>Какие подводные камни?
/lib/ld-linux-x86-64.so.2 /whatever/you/want
свой айпи не палить же
Вот только ни apache+php, ни mysql не дают запускать произвольные бинарники напрямую.
Спасибо, именно это я и хотел услышать.
Ну и очевидный вопрос: можно ли на пыхе писать эксплоиты, которые обычно пишутся на сях для повышения привилегий? Или пыха тут практически бессильна?
>практически бессильна?
This. Но расчитывать на это тоже не стоит, не все эксплоенты требуют бинарной ёбли прямо на атакуемом устройстве.
Вон, взять, например, уязвимости в imagemagick (у которого есть модуль для php), которые только вчера закрыли: http://www.debian.org/security/2017/dsa-3799
Спасибо, добра тебе.
>уязвимости в imagemagick (у которого есть модуль для php),
Там же выполнение произвольного кода вроде, а не повышение привилегий.
>выполнение произвольного кода
Ну так это и нужно для начала. Обычный кулхацкер с оповским способом сможет только php-скрипты выполнять да sql-команды, а произвольный бинарный код (для начала с правами веб-сервер) — нет.
Какой смысл запускать апач от пользователя www-data, если апач один хрен имеет доступ к башу?
Это, какжется, многих только вводит в заблуждение, как, например,
Это, какжется, многих только вводит в заблуждение, как, например,
А откуда этот произвольный код будет выполняться, если /tmp, /var и /dev/shm примонтированы с noexec?
Из оперативной памяти. Добро пожаловать в реальный мир, у нас тут существует https://en.wikipedia.org/wiki/Arbitrary_code_execution
Инновационный способ защиты веб-сервера Аноним (Google Android: Mobile Safari) 02/03/17 Чтв 21:59:37 #56 №1978535
Удаляем нахуй пыхапе и всё связанное с ним говно, берём вместо него джяву. Забываем слово "шелл" навсегда.
Неправ ли я в чем? Какие подводные камни?
Есть готовый phpbb на джава?
Напиши
только юзер3 и рут будут иметь достук к бинарям и оболочке Аноним (Linux: Firefox based) 02/03/17 Чтв 23:38:54 #59 №1978594
#!/bin/bash
groupadd -r exe
usermod -a -G exe user3
chown root:exe -v /home
chown root:exe -v /media
chown root:exe -v /opt
chown root:exe -v /boot
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chown root:exe -v /usr/sbin/nologin
chown root:exe -v /usr/bin/sudo
chown root:exe -v /usr/bin/ssh
chown root:exe -v /usr/bin/perl
chmod 0750 -v /boot
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
chmod 0750 -v /usr/sbin/nologin
chmod 0750 -v /usr/bin/sudo
chmod 0750 -v /usr/bin/ssh
chmod 0750 -v /usr/bin/perl
chmod 0750 -v /home
chmod 0750 -v /media
chmod 0750 -v /opt
groupadd -r exe
usermod -a -G exe user3
chown root:exe -v /home
chown root:exe -v /media
chown root:exe -v /opt
chown root:exe -v /boot
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chown root:exe -v /usr/sbin/nologin
chown root:exe -v /usr/bin/sudo
chown root:exe -v /usr/bin/ssh
chown root:exe -v /usr/bin/perl
chmod 0750 -v /boot
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
chmod 0750 -v /usr/sbin/nologin
chmod 0750 -v /usr/bin/sudo
chmod 0750 -v /usr/bin/ssh
chmod 0750 -v /usr/bin/perl
chmod 0750 -v /home
chmod 0750 -v /media
chmod 0750 -v /opt
Имеет ли смысл монтировать корень и всё остальное с nosuid, если www-data и mysql и так не имеют доступа к шеллу и бинарям?
еще daemon и messagebus желательно в группу добавить
Что помешает поднять себе права, в дырявом ядре и не такое делается. Если бы линукс был бы не пробиваемой стеной, его давно уже бы выпилили, за ненадобностью тот же АНБ
>Что помешает поднять себе права
Для поднятия прав нужно изначально обладать некоторыми правами. Так вот, эти права можно ограничивать грамотным разграничением прав с DAC, MAC и контейнеров.
>Если бы линукс был бы не пробиваемой стеной
Так никто и не спорит, что непробиваемой не является. Однако грамотная защита способна свести вероятность злома к минимуму.
>Для поднятия прав нужно изначально обладать некоторыми правами
Лол, ты даун корзиночка?
Ну что ж ты ругаешься.
Как ты запустишь эксплоит, если еще не закинул его на сервер?
Как ты запустишь эксплоит, если у тебя нет права на его запуск?
Как ты надеешься получить результат, если этот эксплоит унаследует только разрешающие правила родительского процесса, который, в свою очередь, ограничен правилами SELinux или AppArmor?
Да, я таки корзиночка, но не даун.
Заебал буггуртить уже, как эксплоиты устанавливаются!? Браузер сам их скачивает лалка, прав не нужно, експлоит ждет нужного времени, когда заходит рут пользователь, на шindows все в разы проще
Речь-то о сервере и способе усиления его защиты.
Браузер скачивает, но права нужны. Эти права могут быть таки дополнительно ограничены: /home может монтироваться с noexec и браузер может быть защищен профилем AppArmor. И соснет твой эксплоит.
Браузер также может быть запущен от пользователя nobody, например.
>Что помешает поднять себе права
Ты бы хоть тред прочитал. Просто так ты бинарник никакой не запустишь, нужна уязвимость с RCE, чтобы запустить код из процесса уязвимого веб-сервера/БД. Всё ещё возможно, но уже намного сложнее, чем просто вхуячить веб-шелл и залить exploit.c.
И ты хуйню пишешь — мы же договорились, что возможность исполнения php-кода есть, стало быть, права веб-сервера у тебя уже в наличии.
Зойчем кормишь?
возможность исполнения php-кода != возможностьисполнения любого php-кода
- права сервера правам сервера рознь
прост)
>возможность исполнения php-кода != возможностьисполнения любого php-кода
Чё несёт?
Исполнять-то можно любой, вот только результат может быть разным: в одном случае ты бы запускал бинарники и сдеанонил мой сервер, в другом ты не имеешь доступа к бинарям и не можешь выйти за пределы директории сервера и ограничен доступ к POSIX CAPABILITIES. Чувствуешь разницу?
кстати, твой скрипт
http://5mo3467jwq4kcuz5.onion/f/cache/test.php
теперь корректро работает и выдает айпи выходной ноды, несмотря на полный запрет доступа к /etc/resolv.conf
(включилл аппармор, выключил защиту из оп-шапки)
(запрет доступа для апача и его потомков)
>Пока ничего не сломалось, все норм работает, база и сервер пашут без проблем.
я так понял ОП сделал эту команду, но ничего еще не перезагружал?
Ну-ну.
я так понял ОП сделал эту команду, но ничего еще не перезагружал?
Ну-ну.
>linux
>перезагружал
Спермач, съеби-ка ты отсюда.
Ну он то не знает, что скрипты инициализации mysql, например, слегка затейливы.
не пизди мне тут, нормально база пашет и после перезагрузок
а в debian? там же скрепты на perl.
а, так это гейний /usr/bin не отрубал!
То есть /usr/bin/perl, /usr/bin/tclsh И тд - не шеллы в классическом понимании?
еще какие шеллы.
То есть /usr/bin/perl, /usr/bin/tclsh И тд - не шеллы в классическом понимании?
еще какие шеллы.
что сказать-то хотел? в минимальном дебиане перл вообще не стоит. И нахрена перл апачу и базе данных?
и перл отрубил. Всё пашет норм.
#!/bin/bash
groupadd -r exe
usermod -a -G exe user3
chown root:exe -v /home
chown root:exe -v /media
chown root:exe -v /opt
chown root:exe -v /boot
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chown root:exe -v /usr/sbin/nologin
chown root:exe -v /usr/bin/sudo
chown root:exe -v /usr/bin/ssh
chown root:exe -v /usr/bin/perl
chmod 0750 -v /boot
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
chmod 0750 -v /usr/sbin/nologin
chmod 0750 -v /usr/bin/sudo
chmod 0750 -v /usr/bin/ssh
chmod 0750 -v /usr/bin/perl
chmod 0750 -v /home
chmod 0750 -v /media
chmod 0750 -v /opt
>/usr/bin/tclsh
Спасибо за подсказку, какие еще опасные файлы посоветуешь закрыть?
>так это гейний /usr/bin не отрубал
А как сервер запустит перл, если нет доступа к башу? Произвольный файл не запустишь же без /bin/dash.
При попытки запуска произвольного файла апач в качестве шелла использует именно /bin/dash. Как ты заставишь апач использовать именно перл для запуска файлов?
Более того, если на чистый сервер ставить нгинкс и мыху, то там ни перла, ни tclsh даже не будет установлено.
tclsh на моем сервере нет.
(на самом деле нет, перл все-таки с зависимостями прилетит, что не отменяет факта того, что пользователям www-data и mysql перл не нужен)
>в одном случае ты бы запускал бинарники и сдеанонил мой сервер, в другом ты не имеешь доступа к бинарям
Пиздос, а я тебе о чём? Ты будешь посты когда-нибудь до конца и внимательно читать? Я говорил исключительно о возможности выполнения php-кода, о произвольном и речи не было. А ты мне начал втирать дичь про то, что «возможность исполнения php-кода != возможность исполнения любого php-кода».
А почему раньше не работал, разобрался?
>/bin/dash
/bin/sh в общем случае.
>/bin/sh в общем случае
Ну да, в дебине он является ссылкой на /bin/dash
>почему раньше не работал, разобрался?
Вообще-то нет. Точно из-за какого файла не знаю.
Факт в том, что resolv.conf тут ни при чем, все и без него работает при ограничении сервера аппармором.
НЕВОЗМОЖНО ИЗБАВИТЬСЯ ОТ PERL.
В freebsd пытались и теперь она проклята.
ты ебанашка!
Я посоветую не заниматься хуетой.
в стандартном хостинге в php должны использовать open_basedir (дважды рожденный, которую никак не удалят), полностью отключенный CGI и какую-нибудь из работающих вариаций переключения apache в пользователя типа mod_itk
сие есть философский вопрос.
пакет mysql-server зависит от perl, что бы ты тут не говорил.
ну вроде exec глубоко пох на наличие шелла
это системный вызов.
http://www.php.net/function.exec
ИЛИ НЕТ?
Не. Открой исходники и увидишь, что этот php-шный exec всегда транслируется на прыщах в exec с запуском баша.
ну значит pcntl_exec()
Ну значит, открой исходники, блядь, я твои фантазии заебался опровергать.
>mysql-server зависит от perl
Так я и не удаляю перл из системы, я лишь закрываю его от пользователей mysql и www-data.
>в стандартном хостинге в php должны использовать open_basedir
А у нас випиэска, можем себе позволить большее.
Ну спасибо ёпта опу за троллинг, похуярило все директории, слетели все доступы.
Врёти. Неси пруфы. У меня всё работает.
>написали какую-то хуйню в треде
>скопировал в консоль от рута
>все слетело к хуям
Типичный линуксоид из /s/
Что значит похуярило? Можно ж обратно права вернуть. Да и можно более дифференцированный подход применять, и менять права постеренно, а не все сразу.
Да ну вас нахуй, я думал вы реально годноту принесли, обождал чуток потом еще чуток чтоб отсеять вброс какера. Сук у меня портал крутился и сетка сайтов строительной тематики в кол-ве 47 шт.
А бэкап харда сервера я делал 3 месяца назад, после этого костыли на кмс накатывал и сетку сайтов дополнял статьями. Ебись оно всё конём, сижу и руки опустили. Даже прикасаться к серверу желания нет. Щас нахуярюсь. ОП чтоб твою комп с люниксом сгорел!
В голосину. Ну ОП так-то не наебал, теперь твой сервак хуй кто станет взламывать, там и так уже все само наебнулось. Годно же.
ну я и открыл, блядь.
pcntl_exec запускает напрямую!
Школьник, прекращай врать.
Ты можешь внятно объяснить что случилось? Каким образом доступ к серверу получал? Отвалился ли ssh или просто легли серверы? В чем именно проблема-то? Какие симптомы? Почему считаешь состояние необратимым? Какие именно команды запускал?
В шапке ж написано:
"Однакож самому теперь придется работать под рутом, ибо простой юзер залогиниться теперь не сможет."
Именно этио и произошло или чтото другое? Ты просто потерял доступ к консольке от юзера или нечто большее?
И, строго говоря, ты сам виноват. В продакшн прежде чем выкатывать мог бы и на виртуалке потестить.
Я и не говорил, что решение универсально. Я лишь утверждаю, что на виртуалочке с дебианом и единственным форумом решение работает без проблем.
Ну вот, ты послужил тестировщиком инновационного способа защиты сервера (способ на самом деле самый классический - разделение прав доступа), за это тебе спасибо.
БЭКАПЫ НЕ ДЕЛАЮ
@
БЕЗДУМНО КОПИРУЮ КОМАНДЫ ИЗ ИНТЕРНЕТА
@
ОП чтоб твою комп с люниксом сгорел!
Тавлсто
да ты заебал. реально нет в этой функции работы с шеллом.
Нахуя она бы там нужна, если pcntl_* подразумевает прямые низкоуровневые вызовы posix?
Классика же. Пингвиноиды не меняются.
У меня всё работает.
- пиздобол
pic related
- пиздобол
pic related
Проиграл с пикчи.
Всё равно
>Process Control support in PHP is not enabled by default. You have to compile the CGI or CLI version of PHP with --enable-pcntl configuration option when compiling PHP to enable Process Control support.
не беспокойся, в дебиане собрали - значит везде собрали.
>pcntl_exec
Ну давай, запусти что-нибудь напрямую! Вот тебе шелл без баша
http://5mo3467jwq4kcuz5.onion/f/cache/WSO.php
pass: root
В том-то и дело, что нет.
Вот еще пруфец: красным отмечены недоступные для чтения директории. Скрипт в действии, форум http://5mo3467jwq4kcuz5.onion/f/ работает.
отклеился, от поста выше
чет впадлу.
ну какой в этом толк?
Я последний раз встречался со взломом до root на хостинге 17 лет назад. Через ssh
Сам форум все равно похакают, есть там возможность что-то запускать или нет.
ну какой в этом толк?
Я последний раз встречался со взломом до root на хостинге 17 лет назад. Через ssh
Сам форум все равно похакают, есть там возможность что-то запускать или нет.
слив засчитан
ты ебанутый? ты что там делаешь?
> форум все равно похакают, есть там возможность что-то запускать или нет
И не претендую на универсальную защиту, просто показал простой способ сильно затруднить рутование.
Более того,
/usr/bin
/usr/sbin
/usr/lib
тоже можно закрыть от юзеров!
(без ущерба для нормальной работы сервера)
/usr/bin
/usr/sbin
/usr/lib
тоже можно закрыть от юзеров!
(без ущерба для нормальной работы сервера)
Чувак, хватит дрочить на свои «инновации» — ясно же, что они не всем подходят.
Всем вообще ничто не подходит.
--
Выяснили же, что это толстяк.
Итоговая версия инновационного защитного скрипта Аноним (Linux: Firefox based) 09/03/17 Чтв 14:10:30 #137 №1984631
#!/bin/bash
# Создаем группу и добавляем юзеров, которых нежелательно ограничивать, в группу, которая будет владеть закрываемыми от посторонних директориями
groupadd -r exe
usermod -a -G exe alice
usermod -a -G exe bob
usermod -a -G exe daemon
usermod -a -G exe messagebus
usermod -a -G exe lightdm
# Меняем группу владельца с рут на новую группу
chown root:exe -v /home
chown root:exe -v /media
chown root:exe -v /opt
chown root:exe -v /boot
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chown root:exe -v /mnt
chown root:exe -v /srv
chown root:exe -v /usr/bin
chown root:exe -v /usr/sbin
chown root:exe -v /usr/lib
chown root:exe -v /usr/local
chown root:exe -v /usr/include
chown root:exe -v /usr/games
chown root:exe -v /usr/src
# Даем возможность членам группы заходить в ограничиваемые ддя доступа посторонних директории
chmod 0750 -v /home
chmod 0750 -v /media
chmod 0750 -v /opt
chmod 0750 -v /boot
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
chmod 0750 -v /mnt
chmod 0750 -v /srv
chmod 0750 -v /usr/bin
chmod 0750 -v /usr/sbin
chmod 0750 -v /usr/lib
chmod 2750 -v /usr/local
chmod 0750 -v /usr/include
chmod 0750 -v /usr/games
chmod 0750 -v /usr/src
# Поротестировано на дебиан 8 с апач, мыхой и пхп5, форумом phpbbex. - Их работу скрипт не нарушает.
# Создаем группу и добавляем юзеров, которых нежелательно ограничивать, в группу, которая будет владеть закрываемыми от посторонних директориями
groupadd -r exe
usermod -a -G exe alice
usermod -a -G exe bob
usermod -a -G exe daemon
usermod -a -G exe messagebus
usermod -a -G exe lightdm
# Меняем группу владельца с рут на новую группу
chown root:exe -v /home
chown root:exe -v /media
chown root:exe -v /opt
chown root:exe -v /boot
chown root:exe -v /bin
chown root:exe -v /sbin
chown root:exe -v /lib
chown root:exe -v /etc
chown root:exe -v /mnt
chown root:exe -v /srv
chown root:exe -v /usr/bin
chown root:exe -v /usr/sbin
chown root:exe -v /usr/lib
chown root:exe -v /usr/local
chown root:exe -v /usr/include
chown root:exe -v /usr/games
chown root:exe -v /usr/src
# Даем возможность членам группы заходить в ограничиваемые ддя доступа посторонних директории
chmod 0750 -v /home
chmod 0750 -v /media
chmod 0750 -v /opt
chmod 0750 -v /boot
chmod 0750 -v /bin
chmod 0750 -v /sbin
chmod 0750 -v /lib
chmod 0750 -v /etc
chmod 0750 -v /mnt
chmod 0750 -v /srv
chmod 0750 -v /usr/bin
chmod 0750 -v /usr/sbin
chmod 0750 -v /usr/lib
chmod 2750 -v /usr/local
chmod 0750 -v /usr/include
chmod 0750 -v /usr/games
chmod 0750 -v /usr/src
# Поротестировано на дебиан 8 с апач, мыхой и пхп5, форумом phpbbex. - Их работу скрипт не нарушает.
#!/bin/sh
chown root:root -v /home
chown root:root -v /media
chown root:root -v /opt
chown root:root -v /boot
chown root:root -v /bin
chown root:root -v /sbin
chown root:root -v /lib
chown root:root -v /etc
chown root:root -v /mnt
chown root:root -v /srv
chown root:root -v /usr/bin
chown root:root -v /usr/sbin
chown root:root -v /usr/lib
chown root:staff -v /usr/local
chown root:root -v /usr/include
chown root:root -v /usr/games
chown root:root -v /usr/src
chmod 0755 -v /home
chmod 0755 -v /media
chmod 0755 -v /opt
chmod 0755 -v /boot
chmod 0755 -v /bin
chmod 0755 -v /sbin
chmod 0755 -v /lib
chmod 0755 -v /etc
chmod 0755 -v /mnt
chmod 0755 -v /srv
chmod 0755 -v /usr/bin
chmod 0755 -v /usr/sbin
chmod 0755 -v /usr/lib
chmod 2755 -v /usr/local
chmod 0755 -v /usr/include
chmod 0755 -v /usr/games
chmod 0755 -v /usr/src
# - все пользователи снова получат доступ к закрытым ранее директориям
chown root:root -v /home
chown root:root -v /media
chown root:root -v /opt
chown root:root -v /boot
chown root:root -v /bin
chown root:root -v /sbin
chown root:root -v /lib
chown root:root -v /etc
chown root:root -v /mnt
chown root:root -v /srv
chown root:root -v /usr/bin
chown root:root -v /usr/sbin
chown root:root -v /usr/lib
chown root:staff -v /usr/local
chown root:root -v /usr/include
chown root:root -v /usr/games
chown root:root -v /usr/src
chmod 0755 -v /home
chmod 0755 -v /media
chmod 0755 -v /opt
chmod 0755 -v /boot
chmod 0755 -v /bin
chmod 0755 -v /sbin
chmod 0755 -v /lib
chmod 0755 -v /etc
chmod 0755 -v /mnt
chmod 0755 -v /srv
chmod 0755 -v /usr/bin
chmod 0755 -v /usr/sbin
chmod 0755 -v /usr/lib
chmod 2755 -v /usr/local
chmod 0755 -v /usr/include
chmod 0755 -v /usr/games
chmod 0755 -v /usr/src
# - все пользователи снова получат доступ к закрытым ранее директориям
если есть доступ и функции выполнения внешних команд доступны, то что помешает злодею загрузить необходимые бинарнички и выполнить их?
если функции выполнения внешних команд недоступны, то зачем это пионерия?
если функции выполнения внешних команд недоступны, то зачем это пионерия?
>если есть доступ и функции выполнения внешних команд доступны, то что помешает злодею загрузить необходимые бинарнички и выполнить их?
На уровне пхп функции если доступны, то как раз описанный скпипт закрывает доступ к системным исполняемым файлам.
Доступ же к исполнению в /var/www можно прикрыть монтированием с noexec.
>если функции выполнения внешних команд недоступны, то зачем это пионерия?
Если доступ к выполнению закрыт на уровне disable_functions в php.ini, то описанный выше скрипт дает дополнитьельный уровень защиты, хуже не делает.
Его и не только в LAMP-серверах применять можно, может и другие сферы применения возможны.
если мы говорим про хостинг - никто там ничего тебе монтировать не станет
если про впс - там как правило один единственный раздел под рут и все.
итого остается лишь самопал / вдс
Вы таки не поверите, но на /proc можно выставить права 0550.
Это позволяет скрыть uname и прочую инфу.
Веб-сервер от этого не ломается.
Это позволяет скрыть uname и прочую инфу.
Веб-сервер от этого не ломается.
Ну вот, на самопале всё это прекрасно работает.
Насчет впс - на хабре описан способ горячей переустановки ленукса. Хз, может это позволит переразбить диск.
На /sys выставляем права 0550
На /dev выставляем права 0750
www-data и mysql в итоге имеют доступ только к /run, /tmp, /var. К остальным директориям, лежащим в корне, доступ от них можно закрыть.
На /dev выставляем права 0750
www-data и mysql в итоге имеют доступ только к /run, /tmp, /var. К остальным директориям, лежащим в корне, доступ от них можно закрыть.
>/run
о г-ди, в линупсе все настолько печально?
они бы еще весь /var в корень расквартировали.
бтв немного улыбнуло отсутвия такой утилиты как mtree, которая позволяет откатить все права на дефолтные во всех системных директориях. Ну или сохранить/восстановить юзерские...
Брюзжишь бессмысленно, из мухи слона раздуваешь. Только раном фряха и отличается, варран на ран симлинкнут кстати, а права ручками можно наскриптить.
>Только раном фряха и отличается
Ха, если бы. Линукс именно и отличается от фри помойным отношением к hier. Привычка все пихать в одну директорию и бинарники и логи и конфиги и данные растут именно отсюда.
Ты не понял разницы. Во фре mtree c незапамятных времен есть и не надо ничего предолить. Там помимо прав можно и даты с чексумами проверять и/или восстанавливать если надо. Т.е. контроль изменений. И можно было исправить проблемы с левыми правами (например ошибся с chown/chmode и похерил весь корень) как тут у мамкиного владельца строительных сайтов.
А напердолить можно все что угодно, не спорю.
>Привычка все пихать в одну директорию и бинарники и логи и конфиги и данные
Что за дичь ты несешь, примеры хоть приведи. Бинари в бин, логи в вар, конфиги в етс. Ты какой-то поехавший.
>с чексумами проверять
debsums есть
>Т.е. контроль изменений.
auditd, aide, tripwire
>улыбнуло отсутвия такой утилиты как mtree
https://github.com/archiecobbs/mtree-port
This project is a port of the very useful mtree utility, originally only available in BSD distributions, to Linux and other operating systems.
моло.дцы, ч.о. Только в BSD оно в баз.овой системе и все изм.енения в структуре и пра.вах пе.рдо.лят разра.ботчики. Ты лишь используешь.
В линупсе такого не будет.
>Что за дичь ты несешь, примеры хоть приведи.
любая про.приетар.ь под линупс, аля оракел.
кон.фиги муск.ула в /var.
меш.ан.ина из сист.емных фа.йлов и юзе.рленда, вме.сто прав.ослав.ного /usr/local.
это так, схо.ду.
по остальным с.м ответ выше. Все де.фо.лты пил.ятся ра.зр.абочик.ами, тебе лишь ост.ается на.катить/пр.овер.ить в случ.ае fака.па.
ЗЫ что за ебанутый спам фильтр
>кон.фиги муск.ула в /var.
Сдается мне, что ты пиздишь, pics related.
Собственно базы в вар, конфиг в етс.
>меш.ан.ина из сист.емных фа.йлов и юзе.рленда, вме.сто прав.ослав.ного /usr/local.
А в GNU нет принципиальных отличий между системными и юзерлендом.
В /usr/local обычно кладут то, что ставится мимо пакетного менеджера.
>Во фре mtree
годно. Может еще подскажешь тулзы для разруливания дохлых зависимостей и портов? лет 10 назад пробовал BSD и чет подахуел с того как быстро засирается система
pkg help set
вообще я с трудом вспоминаю какие-либо пробюлемы с этим. Обычно такое возникает когда мешают в одну кучу порты и пакеты (установку из репозитория).
С введением pkgng все еще стало проще. Вся база со связями теперь предсавлена в sqlite. Там вообще можно все SQL запросами разрулить.
Но повторюсь, мне пока ни разу не понадобилось.
Есть один действенный хинт - после обновления дерева портов всегда читать /usr/ports/UPDATING, там, как правило, если есть необходимость, то приводятся команды для portupgrade/portmaster/pkg что конкретно нужно сделать чтобы обновиться. Т.е. убунту стайл - скопировал в консолечку команды не задумываясь и все заебок.
Пример из недавнего:
20170220:
AFFECTS: devel/libevent2
AUTHOR: [email protected]
libevent2 has been renamed back to libevent as the default version.
If you manage out of tree ports make sure to run the following:
# pkg set -n libevent2:libevent
# pkg set -o devel/libevent2:devel/libevent
cat
im a kitty cat
AND I DANCE DANCE DANCE DANCE DANCE
ба
bump
Бамп
Так и какой способ более правильный?
Один как я понимаю ушатывает права на директории до полыхания анусов и отваливания сайтов на нём. А другой?
Какой ИСТИННЫЙ ПУТЬ?
Так и какой способ более правильный?
Один как я понимаю ушатывает права на директории до полыхания анусов и отваливания сайтов на нём. А другой?
Какой ИСТИННЫЙ ПУТЬ?
>ушатывает права на директории до полыхания анусов и отваливания сайтов на нём
Ничего не ушатывает, не слушай того толстяка.
Вот тебе рекомендаций чуток:
Защита сервера с использованием принципа наименьших привилегий.
- регулярные обновления серверного софта
- минимизация количества установленного софта и запущенных сервисов
- безопасность ФС с применением umask, chmod, chown, mount, правка fstab, грамотная разбивка на разделы
- Запуск процесса веб-сервера, процесса БД и пользователей БД от отдельных пользователей с минимальными правами
- Минимизация прав доступа веб-сервера к файлам с помощью DAC (выставление минимальных прав доступа к файлам) и MAC (Apparmor, SELinux, TOMOYO)
- защита сети: открывать только используемые порты, применение iptables, snort, fail2ban.
- Применение IDS - snort etc
- использование сильных уникальных паролей везде
- контейнеразация приложений: chroot, LXC, Docker
- контроль целостности и аудит: auditd, tripwire, aide, netstat, rkhunter, ps, last, w, who, id, iftop, jnettop, htop, lsof, inotify, слежение за логами.
- проверка системы на наличие вредоносных файлов: rkhunter, chkrootkit, clamav.
- тюнинг ядра: правки в /etc/sysctl.conf
- Использование PAM
- применение Grsecurity
- шифрование каналов: примнение SSH, SSL.
- тюнинг безопасности самого веб-приложения: использование нестандартных путей и прочее
- настройка безопасности конкретных приложений: ssh (авторизация по ключам), apache, nginx, mysql, php (настройка php.ini).
- различные правки в etc: sudoers, securetty, timezone etc
- регулярное резервное копирование
Каждый из перечисленных пунктов можно было б расписать весьма подробно.
>- различные правки в etc: sudoers, securetty, timezone etc
Вот про это распиши подробнее.
в судоерс не разбираюсь
securetty позволяет контролировать логининг рута через консольку: если очистить файл, рут не сможет залогиниться (при этом созраняется возможность работы через sudo у юзеров)
dpkg-reconfigure tzdata - команда выбора часового пояса. Можно выбрать UTC для затруднения деанона.
Еще хз какте файлы поправить
/etc/hosts.deny перечисляет хосты, с конорых нельзя не сервер заходить, например
/etc/sysctl.conf - настройки ядерной безопасности, дальше сам гугли
бамп
завтра принесу еще один илитный скрипт
завтра принесу еще один илитный скрипт
Какой протокол шифрования используется в ssh по умолчанию?
Бит (bit) неизменяемости (immutable) файла (ака "immutable bit") может быть назначен файлу, который размещён в расширенной файловой системе (Ext3, Ext4, Extended File System), для его защиты от изменений. "immutable bit" может быть добавлен к атрибутам файла с помощью программы chattr и только супер-пользователем. После того, как файлу будет назначен атрибут immutable, над этим файлом будет запрещено: Модификация; Переименование; Удаление; Невозможность создавать жесткие (hard) ссылки.
http://www.remoteshaman.com/unix/common/immutable-bit
Итак, создадим два скрипта.
Первый - /+i.sh, содержащий следующее:
#!/bin/dash
chattr +i -R -V /boot
chattr +i -R -V /etc
chattr +i -R -V /lib
chattr +i -R -V /bin
chattr +i -R -V /sbin
chattr +i -R -V /opt
chattr +i -R -V /media
chattr +i -R -V /mnt
chattr +i -R -V /srv
chattr +i -R -V /usr/bin
chattr +i -R -V /usr/games
chattr +i -R -V /usr/include
chattr +i -R -V /usr/lib
chattr +i -R -V /usr/local
chattr +i -R -V /usr/sbin
chattr +i -R -V /usr/src
chattr +i -V /usr
chattr +i -V /var/lib
chattr +i -V /var/cache
chattr +i -V /var/www
chattr +i -V /var/local
chattr +i -V /var/opt
chattr +i -V /var/spool
chattr +i -V /var
chattr +i -V /home
chattr +i -V /
- это приводит к невозможности модификации перечисленных в скрипте директорий и файлов.
Это защитит от некоторых атак, а также от некоторых ошибок админа.
Вернуть все взад. Создаем скрипт /-i.sh и снимаем иммунный бит в обратном порядке:
#!/bin/dash
chattr -i -V /
chattr -i -V /var
chattr -i -V /var/lib
chattr -i -V /var/cache
chattr -i -V /var/www
chattr -i -V /var/local
chattr -i -V /var/opt
chattr -i -V /var/spool
chattr -i -V /home
chattr -i -V /usr
chattr -i -R -V /usr/bin
chattr -i -R -V /usr/games
chattr -i -R -V /usr/include
chattr -i -R -V /usr/lib
chattr -i -R -V /usr/local
chattr -i -R -V /usr/sbin
chattr -i -R -V /usr/src
chattr -i -R -V /boot
chattr -i -R -V /etc
chattr -i -R -V /lib
chattr -i -R -V /bin
chattr -i -R -V /sbin
chattr -i -R -V /opt
chattr -i -R -V /media
chattr -i -R -V /mnt
chattr -i -R -V /srv
Можно автоматизировать процесс снятия и восстановления бита на время установки, удаления и обновления программ созданием конфига
/etc/apt/apt.conf
содержащего строки
DPkg::Pre-Invoke{"/-i.sh";};
DPkg::Post-Invoke{"/+i.sh";};
- заблокированные файлы вне времени обновлений не сможет изменить даже рут.
Можно править скрипты по вкусу, например, блокируя не весь /etc, а только /etc/nginx и /etc/mysql.
http://www.remoteshaman.com/unix/common/immutable-bit
Итак, создадим два скрипта.
Первый - /+i.sh, содержащий следующее:
#!/bin/dash
chattr +i -R -V /boot
chattr +i -R -V /etc
chattr +i -R -V /lib
chattr +i -R -V /bin
chattr +i -R -V /sbin
chattr +i -R -V /opt
chattr +i -R -V /media
chattr +i -R -V /mnt
chattr +i -R -V /srv
chattr +i -R -V /usr/bin
chattr +i -R -V /usr/games
chattr +i -R -V /usr/include
chattr +i -R -V /usr/lib
chattr +i -R -V /usr/local
chattr +i -R -V /usr/sbin
chattr +i -R -V /usr/src
chattr +i -V /usr
chattr +i -V /var/lib
chattr +i -V /var/cache
chattr +i -V /var/www
chattr +i -V /var/local
chattr +i -V /var/opt
chattr +i -V /var/spool
chattr +i -V /var
chattr +i -V /home
chattr +i -V /
- это приводит к невозможности модификации перечисленных в скрипте директорий и файлов.
Это защитит от некоторых атак, а также от некоторых ошибок админа.
Вернуть все взад. Создаем скрипт /-i.sh и снимаем иммунный бит в обратном порядке:
#!/bin/dash
chattr -i -V /
chattr -i -V /var
chattr -i -V /var/lib
chattr -i -V /var/cache
chattr -i -V /var/www
chattr -i -V /var/local
chattr -i -V /var/opt
chattr -i -V /var/spool
chattr -i -V /home
chattr -i -V /usr
chattr -i -R -V /usr/bin
chattr -i -R -V /usr/games
chattr -i -R -V /usr/include
chattr -i -R -V /usr/lib
chattr -i -R -V /usr/local
chattr -i -R -V /usr/sbin
chattr -i -R -V /usr/src
chattr -i -R -V /boot
chattr -i -R -V /etc
chattr -i -R -V /lib
chattr -i -R -V /bin
chattr -i -R -V /sbin
chattr -i -R -V /opt
chattr -i -R -V /media
chattr -i -R -V /mnt
chattr -i -R -V /srv
Можно автоматизировать процесс снятия и восстановления бита на время установки, удаления и обновления программ созданием конфига
/etc/apt/apt.conf
содержащего строки
DPkg::Pre-Invoke{"/-i.sh";};
DPkg::Post-Invoke{"/+i.sh";};
- заблокированные файлы вне времени обновлений не сможет изменить даже рут.
Можно править скрипты по вкусу, например, блокируя не весь /etc, а только /etc/nginx и /etc/mysql.
bumping
>chattr +i -V /var/www
Интересно
bump
а можно было просто все смонтировать в RO и не париться. Ерохин вон зделол и с Дианочкой мутит, а Сычев все какие-то скрипты пердолит. Даже строку в цикле не способен подставить а тупо копирует свои chattr.
Обычным языком расшифруй.
мимо Ерохин
>все смонтировать в RO и не париться.
Иммунный бит дает не только запрет на обычное изменение, но и на изменение даты модификациии и дает запрет на создание жестких ссылок (создание которых якобы может подорвать защиту с помощью AppArmor), а также требует дополнительный POSIX capability (впрочем, монтирование также требует разрешения, так что можно применить и то и другое) для установки и снятия этого бита.
>расшифруй
что именно?
>смонтировать в RO
chattr можно применять более избирательно к дир и файлам, в олличие от грубого RO, требующего заранее разбитых разделов.
> что именно?
> а можно было просто все смонтировать в RO и не париться.
в /etc/fstab можну указать монтирование разделов только для чтения.
Например,
/dev/sda3 /srv ext4 ro 0 0
- добавляем строку в таблицу разделов, и после перемонтирования раздела /dev/sda3 директория /srv станет доступна только для чтения.
Да мне интересно просто, он один раз сайт задеплоил и забил на него хуй, что он тот раздел не редактируемым делает?
именно нередактируемым даже для рута, если не перемонтировать с rw
и в чем разница? что на readonly разделах внезапно стало можно изменять дату или создавать жесткие ссылки? этот ваш аттрибут совсем не для этого. как и во фре schg.
Я вообще-то тип юморнул, анон там указал, что в пердолескрипте и директория с содержимым сайта, что как бы намекает что юзер хрен что изменит потом.
poweroff
тхреад закончилсо
>в пердолескрипте и директория с содержимым сайта, что как бы намекает что юзер хрен что изменит потом.
ну вот, я ж говорю, чаттр позволяет водходить тольше, блокируя лишь избранные файлы, а не весь докрут сервера, и это, вероятно, единственное преимущество чаттр в сравненоо с ридонли
интересныйтредик,пожалуй подпишусь
bump
бамп
Троллейбус-из-буханки.жпг
Если есть возможность залить произвольный похопэ-кот, то принципиально нет никаких проблем залить статически слинкованный busybox в /tmp.
Нахуя это делать, правда, не очень понятно (если ты мамкин хакир и конпелируешь зиродей сплоет то нахуй тебе /bin/bash вообще сдался без рута - лей сплоет сразу как ELF или a.out епта, а как заберешь uid 0 то execve уже будет иметь права к небу и аллаху), но шелл получить можно, если вот прямо зачем-то тебе понадобилось.
По факту же, толку от запрета доступа к /{s,}bin практически никакого. Если, конечно, у тебя не прадедушкина шлака вместо ОС, с /sbin полным suidных бинарей. Тогда да, дело другое.
Тред не читай @ Хуйню отвечай
Ну хуйню-то ты ответил, конечно, но а что сказать-то хотел?
>Если есть возможность залить произвольный похопэ-кот, то принципиально нет никаких проблем залить статически слинкованный busybox в /tmp
Дальше что? Пыха без баша не даст выполнить бизибокс. /tmp смонтирован с noecec, и ни баш, ни бизибокс в темпе не запустишь.
Хотел сказать, что тебе стоило прочитать тред, а не обсираться, как несколько человек до тебя.
> Пыха без баша не даст выполнить бизибокс
Даст, если есть pcntl_exec, dl или любое место где можно сунуть примерно 30-35 байт шеллкодезов (CVE со stack overflow и прочим double free vulnerability не один десяток каждый год).
(Кстати, без доступа к /etc после fork+setuid похопэ нормально работает? Что-то смотно помню что там что-то было с его конфигами, что оно желало постоянного доступа. Хотя, возможно, путаю с чем-то.)
> /tmp смонтирован с noecec
Не по умолчанию в большинстве дистров (обычно это вообще не отдельная точка монтирования, а если отдельная - только `nodev,nosuid`, как это с /dev/shm обычно). Но тут важно что в исходную постановку не входило, это уже маневрирование началось. Так выяснится что у тебя и веб-сервер в отдельном неймспейсе крутится (докер-хуёкер какой-нибудь), а то и AppArmor включится внезапно, не?
Опять же, если шеллкодезов можно просунуть примерно на сотню с небольшим байт (оценка на глаз, конечно - тратить несколько часов на написание, поиск CVE и прочий бисер - нет никакого желания, не веришь - не моя печаль), и на хосте не предприняты никакие меры (SELinux/AppArmor/черт в ступе), то mmap с PROT_EXEC делают noexec бесполезным.
>pcntl_exec
Ещё один.
Неправильный пост ткнул, вот правильные .
> это уже маневрирование
Напоминаю.
Вообще, закрывать /bin/sh чтобы не допустить "повысить привелегии, получить рут-доступ", это примерно так же логично, как отломать дверную ручку чтобы дверь не открыли.
При том, что еще деды на первослаке пихали процессы в chroot и это намного проще и лучше работало. Эффект как раз ровно тот же самый (нет никакого /bin вообще - нахуй он в чруте-то сдался? и без uid=0 из чрута не выпрыгнешь, т.е. все та же история), но при этом нет дикой ебанистики, вскрытой еще в первом же посте "все теперь работает только от рута".
Ну а если все упирается в "exec/system/бэктики/... не работают, а pcntl_* нет" то почему бы их просто в похапэ-то не отключить? Там настройка есть для этого. Не поможет, конечно, но, опять же, эффект будет тот же самый.
> без uid=0 из чрута не выпрыгнешь
Поправка: это если не созданы тепличные условия, которые позволяют, конечно. (А они бывают в наличии.)
>"все теперь работает только от рута".
ниже описано простое устранение проблемы: создание отдельной группы для шелл-пользователей
>пихали процессы в chroot и это намного проще и лучше работало. Эффект как раз ровно тот же самый (нет никакого /bin вообще - нахуй он в чруте-то сдался?
Нет, ОП-способ проще чрута и менее пердольный
Ты ебанутый? Ты что тут делаешь?
Одну директиву в конфиг тебе засунуть более пердольно, чем хуячить перимшшены и потом пердолиться "простым устранением проблем"?
bum
ЖАMQ!
Ко всему прочему:
ставим права 0600 на /bin/su
и пользуемся только sudo
- тогда даже знание рутового пароля не поможет левому юзеру залогиниться, если он не состоит в группе sudo
(хотя какой смысл, если без sudo итак su не запустишь, если sudo установлена)
и очищаем /etc/securetty - руту незачем напрямую логиниться
ставим права 0600 на /bin/su
и пользуемся только sudo
- тогда даже знание рутового пароля не поможет левому юзеру залогиниться, если он не состоит в группе sudo
(хотя какой смысл, если без sudo итак su не запустишь, если sudo установлена)
и очищаем /etc/securetty - руту незачем напрямую логиниться
chmod 000 `which chmod`
между прочим, задача на соображалку - как потом запилить права обратно?
с livecd
yaourt -Sy coreutils
/usr/lib/ld-linux.so /bin/chmod 755 /bin/chmod
А теперь запусти эту поеботу на 64-битной системе, с мультилибом или без, и охуей.
bump
Этот ебанутый тред еще не утонул?
no
тред живи
долгожданный бамп
chmod 0750 -v /etc
chmod 0750 -v /bin
chmod 0750 -v /sbin
После этого нерутовые пользователи (в том числе mysql и www-data) теряют доступ к оболочкам (/bin/sh, /bin/bash) и теряют возможность выполняния команд.
Залитые веб-шеллы становятся практически бесполезны (возможность заливать файлы и выполнять php-код сохраняется, но теряется доступ к конфигам /etc/password и прочим), невозможным становиться доступ к перлу, питону и запуску произвольных файлов помимо php-скриптов.
Работа базы данных и самого сайта при этом не нарушается.
Однакож самому теперь придется работать под рутом, ибо простой юзер залогиниться теперь не сможет.
Неправ ли я в чем? Какие подводные камни?