Как да се защитим от злоупотреби на шел потребители.

NullByte

Active Member
Тази статия/тема е написана от мен ексклузивно за Предприемач и моя блог, не разрешавам копирането на статията или части от нея без моето разрешение.

Ако имате клиенти, приятели или потребители, които имат шел достъп до вашия сървър, добре е вместо да ги лишавате от него, просто да ги ограничите в действията, които могат да извършват.

В повечето случаи един потребител, който използва акаунта си за хостинг на уебсайт, няма нужда от инструменти като gcc/g++ компилаторите, perl, python и др. подобни интерпретатори. Тогава ще е най-добре те да нямат достъп до тях, за да ги ограничите от използването на зловредни скриптове за атаки, пробиви и тн., всичко незаконно и всичко, което би ви навредило.
Да, вярно е, че и само с шел скрипт и команди може да се навреди, но същото може да се постигне и само с php.

Препоръчвам да се проверяват периодично историите на командите на потребителите, което става лесно с една две команди.
За целта първо трябва да сме сигурни, че по подразибране няма .bash_logout скрипт, който да изтрива историята при излизане. Всеки потребител има право на това и не можете да ги ограничите, но го махнете от подразбиращата се директория (/etc/skel).
След това периодично може да проверявате по ключови думи за зловредни действия, например grep perl /home/*/.bash_history ще ви изведе всички съвпадения за всички потребители, които са използвали команди, в които се съдържа думата perl

Хубаво е да проверявате и какви процеси са пуснати с инструменти като top и htop, или командата ps (ps -u username), както и файлове със съмнителни разширения (например за перл .pl - търсите с команда find -name \.pl)

За да се ограничат определени инструменти или компилатори, може да използвате следната методика, която аз използвам (не претендирам да е добра):
Първо създавате една или повече групи, в зависимост от вашите нужди. Да кажем нужни са ни 2 групи - една потребителска (users), която ще има ограничения и една администраторска (admins) за наши приятели или за системни администратори, която ще може всичко, което потребителите преди въвеждането на ограниченията са можели.
Потребителската - users би трябвало да е създадена предварително, а администраторската admins я създавате вие с командата addgroup (за дебиан и подобни) или groupadd за всички.
След това създаваме потребители, на които основната група да е една от тези, ако имате повече групи може да добавяте на един потребител няколко групи.
За дебиан това става лесно - adduser ivanov --ingroup admins - това ще създаде юзър ivanov с основна група admins. Съответно за ограничен потребител adduser ime --ingroup users.
За модифициране на основната група на вече създаден потребител използваме usermod командата (за всички дистрибуции) - usermod -g grupa user
Пример: usermod -g admins ivanov или usermod -g users ivanov ще направи основната група на потребителя admins или users (ограничената).

След като сме разпределили потребителите е време и да решим как ще ограничим тези в група users.

За целта просто променяме правата на избраните от нас бинарни файлове (програми) на инструментите. Да кажем, че искаме да забраним c,c++ компилатора наречени gcc и g++ и интерпретаторите perl и python, както и допълнително make, с който се build-ват някои програми. За целта пишем следните команди:

Код:
cd /usr/bin
chown root:admins gcc
chmod o-rwx gcc
chown root:admins g++
chmod o-rwx g++
chown root:admins make
chmod o-rwx make
chown root:admins perl
chmod o-rwx perl
chown root:admins python
chmod o-rwx python

Можем да проверим правата с командата ls -l /usr/bin или за определена програма с ls -l /usr/bin | grep perl

-rwxr-x--- 2 root admins 1487332 Apr 12 13:25 perl
-rwxr-x--- 2 root admins 1487332 Apr 12 13:25 perl5.14.2

Виждаме, че само собственика на файловете и групата имат права, а именно root и групата admins.

Така само root и потребители в групата admins ще могат да изпълняват командите.

Вие решавате кои неща да са ограничени, като дори команди като df, who, w, ping, traceroute и тн можете да ограничите по ваше усмотрение.

Ако даден потребител вече си има основна група, например група devels, нищо не пречи да му добавите групата admins, не е нужно тя да е основна.


Друг начин за защита е като ограничите ресурсите за даден потребител, група или за всички. Това става във файла limits.conf, който най-често се намира в /etc/security директорията

Как се борави с този файл може да прочетете с man limits.conf

Ще дам няколко примера:


* hard nofile 65535
* soft nofile 4096
@ivan hard nproc 16384
@ivan soft nproc 2047

където първо се описва потребителя (* означава всички, без root, който трябва отделно да се описва винаги), hard или soft е метода (soft е на ниво shell/bash, а hard е на ниво ядро(kernel))
Ще ограничи броя на отворени файлове за всички потребители на 4096 soft и 65535 hard
Ще ограничи броя на процеси за потребител или група ivan (2047 soft и 16384 hard)

Може да ограничавате много неща, например: процесорно време, максимален размер на файлове, максимален брой едновременни логина в шела, приоритет на процеси и тн.

Ако имате въпроси ще се радвам да отговоря, надявам се да съм бил полезен.
 
Последно редактирано:
От: Как да се защитим от злоупотреби на шел потребители.

В повечето случаи един потребител, който използва акаунта си за хостинг на уебсайт, няма нужда от инструменти като gcc/g++ компилаторите, perl, python и др. подобни интерпретатори.

За това че не им трябва perl или python не съм много съгласен. Има ruby, node.js, erlang и една армада от нови интерпретаторни езици които с успех се използват и във web.

Няма ли да е по-лесно ако просто не се chroot-не самия потребител ИЛИ не се jail-не?

PS: Нека да не прозвучи като заяждане, статията е чудесна, но не описва един фундаментален проблем с unix - липсата на ACL. Какво ще стане ако някой има сайт на ruby и трябва да се подкара - ще трябва да се направи отделна група за него ама с правата на ruby и става една мацаница дето си е еб*л* мамата.

PS2: Горния пример няма да спре "Лошите момчета" (r) (tm) да си компилират статично приложение, да го метнат на хостинга и да го изпълнят със всички последствия... това че на хостинга нямам gcc, не пречи да го имам локално на моята машина нали?

PS3: Пак повтарям - не се заяждам, просто показвам пропуски в модела.
 
От: Как да се защитим от злоупотреби на шел потребители.

В никакъв случаи не приемам мнението като заяждане, даже се учудвам от учтивостта.

Напълно съм съгласен, че не хубаво да се прекалява с ограниченията, защото ще се постигне просто обратния ефект, а е абсолютно вярно, че такива ограничения няма да спрат човек, който си е наумил да злоупотребява, винаги ще намери как, дори за всичко да е помислено. Начини винаги има и са много на брой.

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

Но наистина внимавайте да не си вкарате автогол, има доста уеб приложения на пърл (които използват cgi) и както спомена колегата, node.js и rubi-on-rails набират популярност.
А клиентите не обичат да бъдат ограничавани. Все пак нека послужи за образователна цел този материал, може пък да имате инструмент, който в никакъв случай не желаете да се използва от дадена група потребители, но желаете да бъде достъпен за друга група, която да го ползва и в същото време да няма root достъп.

Всеки сам трябва да прецени какво да ограничи и какво не и дали изобщо да налага ограничения.

Също, вместо ограничаване на правата на дадени инструменти, наблегнете на мониторинг за потенциални хакове и скритпове и тн, тоест да ги грепвате по някакви ключови думи, да гледате ps и тн.
 
Последно редактирано:

Горе