13.1. | Что означает термин sandbox (песочница)? |
| <<Sandbox>> - это термин, используемый при
обеспечении безопасности. Он имеет два значения: Процесс, помещённый внутрь некоторых виртуальных
стен, которые предназначены для предотвращения взлома
всей системы в результате взлома этого конкретного
процесса. Процесс может работать в границах этих стен.
Поскольку, что бы этот процесс ни делал, он эти стены
разрушить не может, особый аудит его кода не нужен для
того, чтобы с уверенностью сказать, насколько его
работа безопасна для системы. Стеной может служить, например, идентификатор
пользователя. Вот определение, даваемое на страницах
Справочника security(7) и named(8). Рассмотрим, например, службу ntalk
(смотрите inetd(8)). Раньше эта
служба запускалась с идентификатором пользователя
root, а сейчас - tty.
Пользователь tty - это та песочница,
которая осложняет взлом системы через ntalk
посредством использования этого идентификатора
пользователя. Процесс, помещённый внутрь симулируемой машины. Это
даёт больший уровень безопасности. Это означает, что
некто, взломавший процесс, может думать, что может сломать и
систему в целом, однако фактически может сломать только
симулятор этой машины и не может модифицировать никаких
реальных данных. Самым распространённым способом достигнуть такого
результата является построение имитирующего окружения в
каталоге и затем запуск процессов в этом каталоге через
chroot (т.е. задав этот каталог в качестве
/ для этого процесса,
а не реальный / всей
системы). Другим часто используемым методом является монтирование
низлежащей файловой системы в режиме "только для чтения" и
затем создание уровня файловой системы поверх неё, что даёт
процессу видимость доступа по записи на ту файловую систему.
Процесс будет полагать, что может записывать в те файлы, но
это будет единственный процесс, который увидит результат
- другие процессы не будут этого делать ни в коем
случае. Попытка сделать такой тип песочницы настолько прозрачна, что
пользователь (или взломщик) даже не поймёт, что он в ней
находится.
В UNIX(R) реализованы два типа <<песочниц>>. Один на
уровне процесса, и один на уровне идентификаторов
пользователей. Каждый процесс в UNIX(R) полностью защищён от других процессов.
Никакой процесс не может модифицировать адресное пространство
другого процесса. В UNIX(R) каждым процессом владеет некоторый идентификатор
пользователя. Если этот пользователь не
root, он ограждает процесс от других,
владельцами которых являются другие пользователи. Этот
идентификатор используется также для защиты данных на диске. |
13.2. | Что такое уровень защиты (securelevel)? |
| securelevel является механизмом
обеспечения безопасности, который реализован в ядре. Когда
уровень защиты больше нуля,
ядро ограничивает выполнение некоторых операций; даже
суперпользователю root
запрещается их выполнять. Механизм уровня защиты ограничивает
возможности по:
снятию некоторых флагов с файлов, таких, как
schg (системный флаг неизменяемости), записи в память ядра через устройства
/dev/mem и
/dev/kmem, загрузке модулей ядра и изменению правил сетевого экрана.
Для выяснения состояния уровня защиты в работающей
системе: # sysctl -n kern.securelevel
Результат содержит текущее значение уровня защиты.
Если оно больше нуля, то по крайней мере некоторые
из защит этого механизма включены. Уровень защиты работающей системы не может быть понижен,
поскольку это противоречит назначению этого механизма.
Если для задачи требуется неположительный
уровень защиты, измените значения переменных
kern_securelevel и
kern_securelevel_enable в файле
/etc/rc.conf и перезагрузите
систему. Более подробная информация об уровнях защиты и о том, какие
специфические действия выполняют все уровни, может быть найдена на
справочных страницах о init(8). Предупреждение: Уровень защиты не является панацеей; в нём есть много
недостатков. Зачастую он даёт обманчивое чувство
безопасности. Одной из самых больших проблем является то, что для его
эффективной работы все файлы, используемые в процессе загрузки,
должны быть защищены. Если атакующий сможет заставить систему
выполнять свой код до установки уровня защиты (что происходит
достаточно поздно во время процесса загрузки, так как некоторые
вещи, выполняемые системой в это время, не могут быть сделаны при
повышенном уровне защиты), то эта защита может быть отключена.
Хотя такая задача по защите всех файлов, используемых в процессе
загрузки, технически вполне осуществима, если это будет сделано,
то поддержка системы станет кошмаром, так как для изменения
конфигурационного файла придётся останавливать систему,
переводя её по крайней мере в однопользовательский режим. Это обстоятельство, а также ряд других, часто обсуждаются в
списках рассылки, в частности, во Список рассылки FreeBSD, посвящённый информационной безопасности.
Поищите в
архивах более подробное обсуждение. Предпочтителен
более гибкий механизм. |
13.3. | BIND (named) работает на
одном из портов с большим номером. Что происходит? |
| Для исходящих запросов BIND использует случайно
выбираемый порт с большим номером. В последних версиях
при каждом запросе выбирается новый случайный порт UDP.
Это может вызвать проблемы в некоторых сетевых конфигурациях,
особенно если фаервол блокирует входящие UDP пакеты на
определенных портах. Чтобы обеспечить прохождение
пакетов через фаервол, попробуйте параметры
avoid-v4-udp-ports и
avoid-v6-udp-ports, чтобы предотвратить
случайный выбор номеров портов, пересекающихся с блокируемым
диапазоном. Предупреждение: Если в /etc/namedb/named.conf
указан номер порта (такой как 53) в параметре
query-source или
query-source-v6, то случайный
выбор порта использоваться не будет. Настоятельно
рекомендуется, чтобы эти параметры не использовались для
указания фиксированных номеров порта. Кстати, поздравляем. Прекрасно, что вы читаете вывод
команды sockstat(1) и обращаете внимание на
аномалии! |
13.4. | Даемон Sendmail ждёт
соединений как на стандартном порту 25, так и на
порту 587! Что происходит? |
| Последние версии Sendmail
поддерживают механизм посылки почты, который работает по
порту 587. Эта возможность пока широко не используется,
но её популярность растёт. |
13.5. | Что это за пользователь toor с UID 0? Я
подвергся взлому? |
| Не волнуйтесь, toor является
<<альтернативной>> учётной записью
суперпользователя (toor - это root, записанный задом
наперёд). Его предлагается использовать с нестандартным
командным интерпретатором, так чтобы не нужно было менять
используемый по умолчанию командный процессор для
root. Это
важно, так как оболочки, не являющиеся частью дистрибутива
системы, устанавливаются в каталог
/usr/local/bin, который по
умолчанию располагается в другой файловой системе. Если
командный процессор для пользователя root располагается в
/usr/local/bin и файловая система,
содержащая /usr/local/bin, не
смонтирована, то root не сможет войти в
систему для исправления проблемы и понадобится
перезагрузиться в однопользовательском режиме, чтобы
указать командный процессор. Некоторые используют toor для выполнения
повседневных административных работ с нестандартным
командным процессором, оставляя root со стандартной
оболочкой для работы в однопользовательском режиме или
выполнения аварийных работ. По умолчанию пользователь не
сможет войти в систему как toor, потому что для него
не указан пароль, поэтому войдите из-под root и установите пароль
для toor до того
как использовать его для входа в систему. |