Часто задаваемые вопросы по FreeBSD 4.X, 5.X и 6.X
Пред. |  | След.

# Глава 13. Безопасность

13.1. Что означает термин sandbox (песочница)?
13.2. Что такое уровень защиты (securelevel)?
13.3. BIND (`named`) работает на порту 53 и на одном из портов с большим номером. Что происходит?
13.4. Sendmail ждёт соединений как на стандартном порту 25, так и на порту 587! Что происходит?
13.5. Что это за пользователь `toor` с UID 0? Я подвергся взлому?
13.6. Почему `suidperl` работает неправильно?

13.1. Что означает термин sandbox (песочница)?

''Sandbox'' - это термин, используемый при обеспечении безопасности. Он имеет два значения:

- Процесс, помещённый внутрь некоторых виртуальных стен, которые предназначены для того, чтобы предотвратить взлом всей системы в результате взлома этого конкретного процесса.

  Говорится, что процесс может ''играть'' в границах этих стен. Что бы этот процесс ни делал, он эти стены разрушить не может, поэтому вам не нужен его особый аудит, чтобы с уверенностью сказать, насколько его работа безопасна для системы.

  Стеной может служить, например, идентификатор пользователя. Вот определение, даваемое на страницах справочной системы security(7) и named(8).

  Рассмотрим, например, службу `ntalk` (смотрите `/etc/inetd.conf`). Раньше эта служба запускалась с идентификатором пользователя `root`, а сейчас - `tty`. Пользователь `tty` - это та песочница, которая осложняет взлом системы через `ntalk` посредством использования этого идентификатора пользователя.

- Процесс, помещённый внутрь симулируемой машины. Это даёт больший уровень безопасности. В общем это означает, что некто, взломавший процесс, может думать. что может сломать и систему в целом, однако фактически может сломать только симулятор этой машины и не может модифицировать никаких реальных данных.

  Самым распространённым способом достигнуть такого результата является построение имитирующего окружения в каталоге и затем запуск процессов в этом каталоге через chroot (т.е. задав этот каталог в качестве `/` для этого процесса, а не реальный `/` всей системы).

  Другим часто используемым методом является монтирование низлежащей файловой системы в режиме "только для чтения" и затем создание уровня файловой системы поверх неё, что даёт процессу видимость доступа по записи на ту файловую систему. Процесс будет полагать, что может записывать в те файлы, но это будет единственный процесс, который увидит результат - другие процессы не будут этого делать, ни в коем случае.

  Попытка сделать такой тип песочницы настолько прозрачна, что пользователь (или взломщик) даже не поймёт, что он в ней находится.

В UNIX® реализованы два типа ''песочниц''. Один на уровне процесса, и один на уровне идентификаторов пользователей.

Каждый процесс в UNIX полностью защищён от других процессов. Никакой процесс не может модифицировать адресное пространство другого процесса. Это отличается от Windows®, где процесс может легко записать что-либо в адресное пространство другого процесса, что приводит к аварийным ситуациям.

В UNIX каждым процессом владеет некоторый идентификатор пользователя. Если этот пользователь не `root`, он ограждает процесс от других, владельцами которых являются другие пользователи. Этот идентификатор используется также для защиты данных на диске.

13.2. Что такое уровень защиты (securelevel)?

Уровень защиты является механизмом обеспечения безопасности, реализованным в ядре. В общем, когда уровень защиты больше нуля, ядро ограничивает выполнение некоторых операций; даже администратору (то есть пользователю `root`) запрещается их выполнять. На момент написания этого текста механизм уровня защиты может, кроме всего прочего, ограничивать возможности по

- снятию некоторых флагов с файлов, таких, как `schg` (системный флаг неизменяемости),

- записи в память ядра через устройства `/dev/mem` и `/dev/kmem`,

- загрузке модулей ядра и

- изменению правил сетевого экрана.

Для выяснения состояния уровня защиты в работающей системе просто выполните следующую команду:

    # sysctl kern.securelevel

Результат будет содержать название sysctl(8)-переменной (в нашем случае это `kern.securelevel`) и число. Последнее и является текущим значением уровня защиты. Если оно положительно (то есть больше нуля), то по крайней мере некоторые из защит этого механизма включены.

Вы не можете понизить уровень защиты работающей системы; возможность сделать это противоречит назначению этого механизма. Если вам нужно выполнить работу, которая требует не положительный уровень защиты (к примеру, выполнение `installworld` или смена даты), вам потребуется изменить настройки уровня защиты системы в файле `/etc/rc.conf` (вам нужно обратить внимание на переменные `kern_securelevel` и `kern_securelevel_enable`) и перезагрузить систему.

Более подробная информация об уровнях защиты и о том, какие специфические действия выполняют все уровни, может быть найдена на справочных страницах о init(8).

> Внимание: Уровень защиты не является панацеей; в нём есть много недостатков. Зачастую он даёт обманчивое чувство безопасности.

> Одной из самых больших проблем является то, что для его эффективной работы все файлы, используемые в процессе загрузки, должны быть защищены. Если атакующий сможет заставить систему выполнять свой код до установки уровня защиты (что происходит достаточно поздно во время процесса загрузки, так как некоторые вещи, выполняемые системой в это время, не могут быть сделаны при повышенном уровне защиты), то эта защита может быть отключена. Хотя такая задача по защите всех файлов, используемых в процессе загрузки, технически вполне осуществима, если это будет сделано, то поддержка системы станет кошмаром, так как для изменения конфигурационного файла придётся останавливать систему, переводя её по крайней мере в однопользовательский режим.

> Это обстоятельство, а также ряд других, часто обсуждаются в списках рассылки, в частности, во Список рассылки FreeBSD, посвящённый информационной безопасности. Пожалуйста, поищите в архивах более подробное обсуждение. Некоторые надеются, что механизм уровней защиты вскоре отомрёт, а на его смену придёт более гибкий механизм, но пока всё это туманно.

> Считайте себя предупреждёнными.

13.3. BIND (`named`) работает на порту 53 и на одном из портов с большим номером. Что происходит?

Для исходящих запросов BIND использует случайно выбираемый порт с большим номером. Если для исходящих запросов вы хотите использовать порт с номером 53 для работы за межсетевым экраном либо просто для собственного спокойствия, то можете попробовать настроить файл `/etc/namedb/named.conf` следующим образом:

    options {
            query-source address * port 53;
    };

Можете заменить символ `*` некоторым IP-адресом, если хотите настроить все еще жестче.

Кстати, поздравляем. Прекрасно, что вы читаете вывод команды sockstat(1) и обращаете внимание на аномалии!

13.4. Sendmail ждёт соединений как на стандартном порту 25, так и на порту 587! Что происходит?

Последние версии Sendmail поддерживают механизм посылки почты, который работает по порту 587. Эта возможность пока широко не используется, но ее популярность растет.

13.5. Что это за пользователь `toor` с UID 0? Я подвергся взлому?

Не волнуйтесь, `toor` является ''альтернативным'' административным пользователем (toor - это root, записанный задом наперед). Раньше он создавался при установке командного интерпретатора bash(1), однако теперь он создается по умолчанию. Его предполагается использовать с нестандартным командным интерпретатором, так чтобы вам не нужно было менять используемый по умолчанию командный процессор для пользователя `root`. Это важно, так как оболочки, не являющиеся частью дистрибутива системы (например, командный процессор, устанавливаемый из портов или пакаджей), скорее всего, устанавливаются в каталог `/usr/local/bin`, который по умолчанию располагается в другой файловой системе. Если командный процессор для пользователя `root` располагается в `/usr/local/bin`, и `/usr` (или другая файловая система, содержащая `/usr/local/bin`) по какой-либо причине не смонтирована, то `root` не сможет войти в систему для исправления этой проблемы (хотя если вы перезагрузите систему в однопользовательский режим, вы сможете указать командный процессор).

Некоторые используют `toor` для выполнения повседневных административных работ с нестандартным командным процессором, оставляя `root` со стандартной оболочкой для работы в однопользовательском режиме или выполнения аварийных работ. По умолчанию вы не сможете войти в систему как пользователь `toor`, потому что у него нет пароля, так что, если вы хотите его использовать, зарегистрируйтесь в системе как `root` и задайте пароль для пользователя `toor`.

13.6. Почему `suidperl` работает неправильно?

В целях обеспечения безопасности `suidperl` по умолчанию устанавливается без suid-бита. Системный администратор может включить использование suid-бита следующей командой.

    # chmod u+s /usr/bin/suidperl

Если вы хотите, чтобы suid-бит для `suidperl` было установлен во время обновления из исходных текстов, отредактируйте `/etc/make.conf`, добавив `ENABLE_SUIDPERL=true` перед запуском `make buildworld`.

Пред. | Начало | След.
Работа в сети |  | PPP

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.