Можно и линукс настроить так, что кто-то подключится к нему удаленно и просто введет от рута одну команду, которая будет страшнее всех вирусов под виндоус вместе взятых: rm -rf и снесёт все к чертовой матери за считанные секунды\минуты.
Его ещё, попытавшись вломиться, этого рута нужно получить. :)
Для этого есть понятие распределения прав доступа.
Если набросать на коленках, то одно из правил, в простейшем варианте, может выглядеть так (Только добавленные в /etc/sudoers строки, лишнее не относящееся напрямую к сказанному, но дефолтно существующее, убрано для читаемости и восприятия. Модифицировать это можно по своему вкусу для своих задач используя как образец, параллельно поглядывая в 'man sudoers'.):
# User alias specification
User_Alias APT_GET_USERS = user1, user2
# Cmnd alias specification
Cmnd_Alias APT_CMD = /usr/bin/apt-get
# Runas alias specification
Runas_Alias APT_RUN_AS = %wheel
# Defaults specification
Defaults:APT_GET_USERS !lecture
# If env_reset is disabled, sudo will NOT reset the environment
# to only contain the fixed list of variables.
# See sudoers(5) for details.
#Defaults:WHEEL_USERS !env_reset
# Preserve DISPLAY and XAUTHORITY environment variables
# for "xgrp" group members.
# User privilege specification
APT_GET_USERS ALL=(APT_RUN_AS) APT_CMD
Это правило звучит так:
Любые пользователи только входящие в список APT_GET_USERS, имеют право на любых машинах, как пользователи группы wheel (APT_RUN_AS), запускать любые команды списка APT_CMD.
При этом, даже если пользователь занесён в группу wheel, но его нет в списке APT_GET_USERS, исполнять команды из списка APT_CMD не имеет права.
Предположим, что право на монтирование/размонтирование каких-то файловых систем с особо ценной информацией вы решили дать какой-то группе пользователей. Настройки sudoers можно выполнить по аналогии. Но тогда встаёт вопрос, как распределить права между группами пользователей в sudoers, если право выполнять apt-get является наиболее критичным, поскольку вносит изменения в систему и является более ответственным, чем права пользователей списка mount.
Для этого можно воспользоваться флагом rootpw . И содержимое sudoers может выглядеть так:
# User alias specification
User_Alias APT_GET_USERS = user1
User_Alias MOUNT_USERS = user1, user2
# Cmnd alias specification
Cmnd_Alias APT_CMD = /usr/bin/apt-get
Cmnd_Alias MOUNT_CMD = /bin/mount, /bin/umount
# Runas alias specification
Runas_Alias APT_RUN_AS = %wheel
Runas_Alias MOUNT_RUN_AS = %wheel
# Defaults specification
Defaults:APT_GET_USERS rootpw
# If env_reset is disabled, sudo will NOT reset the environment
# to only contain the fixed list of variables.
# See sudoers(5) for details.
#Defaults:WHEEL_USERS !env_reset
# Preserve DISPLAY and XAUTHORITY environment variables
# for "xgrp" group members.
# User privilege specification
APT_GET_USERS ALL=(APT_RUN_AS) APT_CMD
MOUNT_USERS ALL=(MOUNT_RUN_AS) MOUNT_CMD
В данной конфигурации выполнять apt-get через sudo имеет право только пользователь user1, а mount и umount пользователи user1 и user2. Более того, для выполнения mount/umount через sudo у пользователей списка MOUNT_USERS будет запрашиваться их личный пользовательский пароль, а для выполнения apt-get через sudo, на которое имеет право только пользователь user1, у него будет запрашиваться пароль root, которого требует флаг rootpw.
Всё это с учётом того, что если suid-бит с su снят, пользователи группы wheel не могут воспользоваться лазейкой через команду 'su -' и будут наделены только правами предоставленными им в sudoers.
Ну в общем правил безопасности много и на sudoers они не заканчиваются.
Можно снять с su suid-бит запретив пользователям группы wheel получать права root через su минуя sudoers.
# ls -l /bin/su
-rws--x--- 1 root wheel 22244 Июл 2 2010 /bin/su
# chmod u-s /bin/su
# ls -l /bin/su
-rwx--x--- 1 root wheel 22244 Июл 2 2010 /bin/su
$ su -
su: Authentication failure
И любители вламываться к пользователям группы wheel пойдут лесом.
Вернуть suid-бит назад:
# chmod u+s /bin/suПоследний экстрим: запретить root'у логиниться в системе:
# find /etc/ -name securettyНу много чего ещё.
Можно Бруй и Карлов "Linux-сервер: пошаговые инструкции инсталляции и настройки" почитать о настройке сервера и использовать для настройки домашней железяки. С поправкой на конфиги. О sudoers там очень на редкость доступно рассказывают авторы.
Ну и разные хакерские оригинальные фишки и трюки по защите и информингу поискать.
Кстати некоторые инструменты в Windows портированы именно из *nix'ов.
rm -rf и снесёт все к чертовой матери за считанные секунды\минуты.
Агащас, если:
файловые дефолтом в noauto
нельзя получить суперюзера
нельзя логиниться root'у
монтировать только через sudoers по списку (с соответствующим в fstab)
:)
Я говорю в данный момент о грамотной, профессиональной защите. Которая даже при попадании вирусов в систему не даст им шанса что-либо нарушить.
Для начала в Windows и *nix разные принципы к подходу базового уровня настройки безопасности.
В *nix запрещено всё, что не разрешено. Венчает эту вершину FHS стандарт.
В Windows безопасность базового начального уровня. Если её настроить как положено дефолтом, пользователи завопят, что ничего не работает.
А то интересно получается- в виндоус, особенно в хр, кто сейчас сидит на линуксе, а тогда сидел на винде они лазили в интернет под админом и кричали какое говно система. В линуксе сидят с ограниченными правами и конечно все хорошо. Что тоже самое мешало настроить в Виндоусе?
Объём возни. В Windows безопасность нужно наслаивать ничего не упустив. Если вы настроите Windows на профессиональном уровне (не прыщавого!) хакера, можете смело идти работать в АНБ в отдел по кибербезопасности. Можете быть уверены, лохи там не сидят.
Если хочется побаловаться с защитой, наверное не лишним будет почитать что-нибудь о шелл-кодинге про искусство взлома и защиты систем. Такие кодеры самые опасные и вирусы там всякие, для *nix'ов, это просто детский сад на выезде.
Можно и на пользовательском уровне приводить всё в порядок, но уверяю, пережевать придётся гигатонны информации не пользовательского уровня, что для основной массы народа абсолютно недоступно и нереально ни в каком виде. Много надо перелопатить книг профессиональных хакеров и возможно посетить не один десяток хакерских ресурсов, где не трепятся, а работают. А дело это хлопотное и геморное. Особенно при очередном сломе архитектуры ОСи.
Плюс в Windows есть неудобоваримые табуретки. Например, сама по себе идея централизованной базы неплоха, и для разработки, и для отладки, но при эксплуатации это одновременно трудноуправляемый хороший мусоросборник.
А вот в *nix'овые конфиги, которые сами по себе простые ascii-файлы и поддаются контролю без семи пядей во лбу, которые не являются исполняемыми, подсадить что-то затруднительно. Ну разве что на дцать десятков байт управляющих кодов натолкать, и сделать файл нечитаемым. Но в *nix чтобы допустить такое, ну совсем уж надо разгильдяем быть.
Если же вас так волнуют вирусы в Windows
Да дело тут даже не в вирусах, а в принципиальной разнице, пока ещё (тонкий намёк), архитектуры ОСей.
И потом, неужели вы думаете, что высококвалифицированные программисты работающие в корпорации майкрософт хуже разбираются в программировании,
Они не хуже. Они под заказ делают:
кто платит, тот и танцует.
Техзадание же...
