Брандмауэры и специальное программное обеспечение



Pdf просмотр
страница12/42
Дата15.02.2017
Размер6.16 Mb.
Просмотров2892
Скачиваний0
ТипАнализ
1   ...   8   9   10   11   12   13   14   15   ...   42
Листинг 7.1. Файл /etc/inittab с добавленными номерами строк
4 1 #
2 # inittab This file describes how the INIT process should set up
3 # the system in a certain run-level.
4 #
5 # Author: Miquel van Smoorenburg,
6 #
Modified for RHS Linux by Marc Ewing and Donnie Barnes
7 #
Modified for COL by Raymund Will
8 #
9 10 # The runlevels used by COL are:
11 # 0 - halt (Do NOT set initdefault to this)
12 # 1 - Single user mode (including initialisation of network interfaces,
13 # if you do have networking)
14 # 2 - Multiuser, (without NFS-Server und some such)
15 # (basically the same as 3, if you do not have networking)
16 # 3 - Full multiuser mode
17 # 4 - unused
18 # (should be equal to 3, for now)
19 # 5 - X11 20 # 6 - reboot (Do NOT set initdefault to this)
21 22 #
23 # Default runlevel.
24 id:5:initdefault:
25 26 # System initialization.
27 sO::sysinit:/bin/bash -c 'C=/sbin/booterd; [ -x $C ] && $C'
28 si::sysinit:/bin/bash -c 'C=/etc/rc.d/rc.modules: [ -x $C ] && $C default'
29 s2::sysinit:/bin/bash -c 'C=/etc/rc.d/rc.serial; [ -x $C ] && $C'
30 bw::bootwait:/etc/rc.d/rc.boot
31 32 # What to do in single-user mode.
33 1:S:wait:/etc/rc.d/rc 1 34
:S:wait:/sbin/sulogin
35 36 10:0:wait:/etc/rc.d/rc 0 37 11:l:wrtt:/etc/rc.d/rc 1 38 12:2:wait:/etc/rc.d/rc 2 39 13:3:wait:/etc/rc.d/rc 3 40 14:4:wait:/etc/rc.d/rc 4 41 15:5:wait:/etc/rc.d/rc 5 42 16:6:wait:/etc/rc.d/rc 6 43 # Normally not reached, but fallthrough in case of emergency.
44 z6:6:respawn:/sbin/sulogin
45 46 # Trap CTRL-ALT-DELETE
47 ca:12345:Ctrlaltdel:/sbin/shutdown -t3 -r now
48 49 # Action on special keypress (ALT-UpArrow).
50 kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."
51 52 # When our UPS tells us power has failed, assume we have a few minutes
53 # of power left. Schedule a shutdown for 2 minutes from now.
54 # This does, of course, assume you have powerd installed and your
55 # UPS connected and working correctly.
56 pf::powerfail:/sbin/shutdown -h +5 "Power Failure: System Shutting Down"
57 58 # If battery is fading fast -- we hurry...
59 pi::powerfailnow:/sbin/shutdown -c 2> /dev/null
60 p2::powerfailnow:/sbin/shutdown -h now "Battery Low..."
61 62 # If power was restored before the shutdown kicked in, cancel it.
63 po:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
64 65 66 # Run gettys in standard runlevels
67 1:12345:respawn:/sbin/getty ttyl VC linux
68 2:2345:respawn:/sbin/getty tty2 VC linux
69 3:2345:respawn:/sbin/getty tty3 VC linux

4
Комментарии в листинге оставлены без перевода, чтобы не нарушить нумерацию строк. Подробное описание работы сценария см. далее в книге. — Примеч. перев

70 4:2345:respawn:/sbin/getty tty4 VC linux
71 5:2345:respawn:/sbin/getty tty5 VC linux
72 6:2345:respawn:/sbin/getty tty6 VC linux
73 74 # Run kdm in runlevel 5 75 kdm:5:respawn:/opt/kde/bin/kdm -nodaemon > /var/log/kdm 2>&1
Файл /etc/inittab, содержимое которого приведено в листинге 7.1., позаимствован из комплекта
OpenLinux 2.3 компании Caldera. В другом комплекте Linux содержимое этого файла почти наверняка будет иным. Однако если сравнить между собой комплекты Caldera и Red Hat (равно как и SuSE, Mandrake или Debian), то различий наберется куда меньше, чем при сравнении любого из этих комплектов и комплекта Slackware. В каждом из комплектов Linux используется одна и та же программа инициализации init (в любом из них эта программа получается в результате компиляции одного и того же исходного кода), то вся разница в процессах инициализации задается исключительно файлом inittab, подробным рассмотрением которого мы и займемся.
Структура inittab
Строки файла inittab, начинающиеся с символа #, являются комментариями и потому командой init не обрабатываются. Очевидно, они предназначены для пользователей системы и помогают понять логику работы файла. Остальные строки имеют обычную для конфигурационных таблиц структуру в виде набора полей, разделенных двоеточием. Поля эти, если перечислять их слева направо, следующие:
- id (идентификатор). Первое поле содержит уникальный идентификатор строки, состоящий из алфавитно-цифровых символов. Максимально допустимая длина идентификатора равна четырем, но на практике, как правило, используются двухсимвольные идентификаторы. В старых системах длина этого поля не могла превышать двух, и большинство комплектов Linux (все, которые я знаю), еще не отошли от этого ограничения;
- runlevel (уровень выполнения). Во втором поле содержится уровень выполнения, на котором следует выполнять эту строку. Если конкретный уровень не указан, строка выполняется на всех уровнях.
Примером такой строки с пустым полем уровня выполнения является строка 60 в листинге 7.1;
- action (действие). Значением этого поля является одно из предопределенных ключевых слов. Чаще всего это respawn, но также допустимы и boot, bootwait, ctrlaltdel, initdefault, kbrequest, off, once, ondemand, powerfail, powerokwait, powerwait и sysinit;
- process (процесс). Процесс или программа для выполнения.
Каждой строке файла inittab ставится в соответствие уникальный идентификатор. Выбирать его принято так, чтобы он легко ассоциировался с выполняемым действием. Например, для строки, порождающей getty применительно к первому последовательному порту, подойдет идентификатор s1.
По умолчанию уровни выполнения обозначаются цифрами от 0 до 6 и буквами от А до С (или от а до с). Уровни выполнения 0,1 и 6 являются специальными, и без особой надобности их изменять не следует.
Уровень 0 соответствует останову системы, уровень 1 — однопользовательскому режиму, уровень 6 — перезагрузке, поэтому изменение любого из этих уровней может иметь далеко идущие последствия.
Остальные уровни, то есть уровни 2-5, можно настраивать совершенно свободно.
ПРИМЕЧАНИЕ
Традиционно для передачи команд init используется telinit, однако можно вызывать init и напрямую. В OpenLinux
файл telinit является не отдельной программой, а символической ссылкой, указывающей на init. В других комплектах
Linux для этой цели может использоваться жесткая ссылка. Так или иначе, в конечном итоге все равно вызывается
init.
В некоторых комплектах Linux имеется команда runlevel (которая, как правило, устанавливается в каталоге /sbin), отображающая номера предыдущего и текущего уровней выполнения. Если предыдущий уровень выполнения отсутствует, как это бывает после перезагрузки, то вместо него выводится буква N, например N 3. Если затем перевести систему в состояние 2 и снова выполнить команду runlevel, то команда отобразит комбинацию чисел 3 2. Кроме того, текущий уровень выполнения отображается как аргумент команды init в листинге информации о процессах (ps ax).
Уровни выполнения всегда обозначаются числами, но программе init в качестве уровня исполнения можно передавать и символьные аргументы. Аргумент Q обсуждается в следующем абзаце. Символы А, В и С (или а, b, с, что функционально одно и то же) используются только с действием ondemand, которое, в свою очередь, используется только с уровнями выполнения А-С. Данное действие позволяет суперпользователю (только суперпользователь может вызывать inittab) порождать процессы по своему
усмотрению.
Аргумент Q (можно использовать нижний регистр — q, — это одно и то же) предписывает init заново прочесть конфигурационный файл inittab. Менять inittab можно когда угодно и сколько угодно раз, но заново считывается он лишь в следующих случаях:
- завершение процесса, порожденного init (порождать еще один?);
- получение сигнала о сбое питания (от демона или из командной строки);
- переход с одного уровня выполнения на другой;
- обращение к init с аргументом Q или q.

inittab от начала и до конца
В этом разделе мы пройдемся по строкам листинга 7.1. Ранее мы ознакомились с форматом файла inittab, теперь же рассмотрим, как он работает на практике.
Строки 1-24 являются комментариями, поэтому мы их пропустим и начнем сразу со строки 24.
Обычно такая строка выполнялась бы только на уровне выполнения 5. Но в данной записи указано действие initdefault, означающее, что данный уровень выполнения следует сделать уровнем выполнения по умолчанию (этот уровень будет использоваться в случае, если программа init запущена без указания требуемого уровня в командной строке). В OpenLinux (и некоторых других комплектах Linux) уровню 5 ставится в соответствие графический вход в систему, поэтому если вы не желаете, чтобы при загрузке системы подключение к ней осуществлялось в графическом режиме, измените уровень выполнения по умолчанию на 3. Это замечание справедливо также для комплекта Red Hat, однако в Debian уровень выполнения по умолчанию равен 2, а тип входа в систему (графический/обычный) зависит не от уровня выполнения, а от того, запускается или нет сценарий xdm.
ПРИМЕЧАНИЕ
В данном случае рассматривается система Caldera OpenLinux, откуда и взят рассматриваемый здесь файл inittab,
поэтому если вы используете другой комплект Linux или другую версию OpenLinux, то ваш файл inittab, скорее всего,
будет отличаться от рассматриваемого здесь. Однако основные концепции в любом случае будут одинаковы.
После строки установки уровня выполнения по умолчанию следуют строки (27-30), в которых осуществляется запуск сценариев инициализации системы. Как явствует из их названий, эти сценарии загружают модули, инициализируют последовательные порты и выполняют прочие действия, которые необходимо выполнить в процессе загрузки системы. В строке 30 указано действие bootwait, поэтому на ней программа init приостановится и будет ждать, пока не завершится выполнение указанного в ней сценария. Все четыре строки (27-30) будут выполняться одновременно, однако до завершения процесса из строки 30 init не будет запускать никаких других процессов. Это позволяет завершить все подготовительные действия, необходимые для перехода к следующему этапу: запуску демонов и порождению getty.
Строки 33 и 34 вызывают два сценария, выполняющихся при переходе системы в состояние 1, иначе говоря, в однопользовательский режим. Программа sulogin нужна для того, чтобы пользователь, обладающий возможностью физического доступа к системе, не смог получить привилегии суперпользователя без знания соответствующего пароля. В противном случае любой желающий смог бы получить полную власть над системой, просто перезагрузив ее в однопользовательском режиме. Без этой строки система, загрузившись в однопользовательском режиме, не станет запрашивать пароль у пользователя, а сразу же предоставит ему доступ к командной оболочке с привилегиями суперпользователя. Однако при наличии физического доступа к системе защиту с использованием программы sulogin можно обойти, о чем подробней рассказывается в следующей главе.
Строки с 36 по 42 выполняются при смене уровней выполнения. Каждая такая строка представляет собой вызов сценария с именем rс и номером уровня, на который переходит система, в качестве аргумента.
Так, при переходе с уровня 5 на уровень 3 будет выполнена строка 39, которая вызовет rс с аргументом 3.
Строка 44 выводит запрос на ввод пароля суперпользователя. Данная строка является мерой предосторожности на случай, если после перехода на уровень выполнения 6 система не перезагрузится должным образом.
Строка 47 перехватывает комбинацию клавиш Ctrl+Alt+Del, осуществляя по ней перезагрузку системы. При желании вместо перезагрузки можно получить останов системы, для чего в этой строке нужно заменить -r на -h. Или же можно просто убрать -r, и тогда по нажатию этих клавиш система будет переходить в однопользовательский режим, предоставляющий доступ к командной оболочке с правами суперпользователя.

Строка 50 перехватывает комбинацию клавиш Alt+T. На данный момент никаких осмысленных действий по ней не делается, а лишь выводится сообщение о том, что ее нужно настраивать самостоятельно. При установке OpenLinux по умолчанию, то есть с использованием bash, данная последовательность команд игнорируется (это также относится и к большинству других дистрибутивов, в которых bash является оболочкой по умолчанию). Поэтому сначала нужно изменить настройку соответствия клавиш таким образом, чтобы bash передавал эту комбинацию, не интерпретируя ее, после чего можно заменять ту часть строки, где стоит echo, на удобную для вас команду.
Строки 56, 59, 60 и 63 представляют интерес лишь для тех, у кого есть источник бесперебойного питания, совместимый с демоном питания powerd. Демон питания может наблюдать за состоянием последовательно порта и в случае возникновения тех или иных событий, связанных с питанием, этот демон способен выполнять действия, указанные в файле inittab. В комплект поставки OpenLinux демон питания не входит. Проблема в том, что в настоящее время лишь очень немногие источники бесперебойного питания работают с демоном, независимо от того, какой у вас комплект Linux.
Строки с 67 по 72 порождают процессы getty для виртуальных терминалов. Обратите внимание, что в однопользовательском режиме доступен лишь один виртуальный терминал. Если хочется иметь побольше свободной памяти, то можно уменьшить число виртуальных терминалов на уровне выполнения 5.
Например, до одного: в графическом режиме они особенно и не нужны, поэтому одного будет вполне достаточно. Для увеличения числа виртуальных терминалов нужно просто добавить дополнительные строки к уже существующим (с уникальными идентификаторами, разумеется).
В строках 50, 56, 59 и 60 поле уровня выполнения содержит пустую строку. Это означает, что данные строки выполняются на любом уровне.
Наконец, в последней строке с номером 75 на уровне выполнения 5 порождается процесс kdm (KDE
Display Manager). В комплекте Red Hat вместо kdm может использоваться xdm или gdm. В Debian всегда используется уровень выполнения 2, a xdm запускается не через inittab, а точно так же, как и все остальные серверы.

ПРИМЕЧАНИЕ
Если ваша система загрузилась в однопользовательский режим, хотя уровень выполнения по умолчанию у нее
отличен от 1, значит, сценарий reboot обнаружил проблему с жестким диском, требующую ручного запуска fsck.
После исправления проблемы система вновь начнет загружаться в многопользовательском режиме.
Сценарии rс, часть первая
В OpenLinux все сценарии инициализации хранятся в каталоге /etc/rc.d. В нем также имеются подкаталоги rc0.d - rc6.d, где номер соответствует уровню выполнения, а также подкаталог init.d. В каталогах rc#.d (# означает номер уровня исполнения) находятся символические ссылки, указывающие на сценарии из подкаталога /etc/rc.d/init.d (листинг 7.2). Всем сценариям из init.d можно передавать аргументы start и stop, а некоторым — еще два аргумента: reload и restart. Хотя реализация аргументов restart/reload несложна, по крайней мере один демон (dhcp) по сигналу SIGHUP неправильно считывает свой конфигурационный файл. Сигнал SIGHUP (от английского слова hangup — повесить телефонную трубку, дать отбой) означает, что демон должен заново прочитать файл конфигурации и продолжить работу с новой конфигурацией.
СОВЕТ
Сигналы, адресуемые работающим в системе процессам, являются средством передачи команд, предписывающих
выполнение этими процессами определенных действий. Чаще всего они применяются для посылки фоновым
процессам команды завершения работы. Разрешается использовать сигналы, номера которых лежат в диапазоне
от 1 до 31. Команде завершения работы соответствует сигнал SIGTERM (15). Другими часто используемыми
сигналами являются SIGKILL (9) и SIGHUP (1). Полный список сигналов можно получить при помощи команды man 7
signal. Посылкой сигналов процессам занимается команда kill, принимающая в качестве параметров имя или номер
сигнала и идентификатор процесса, например kill -SIGHUP PID или kill -1 PID. При отсутствии параметра-сигнала
посылается сигнал SIGTERM.


Листинг 7.2. Частичный список файлов каталога /etc/rc.d/
drwxr-xr-x
2 root root
1024 Aug 30 07:25 init.d
-rwxr-xr-x 1 root root
5336 Aug 16 22:45 re
-rwxr-xr-x 1 root root
8930 Jul 7 08:55 re.boot
-rwxr-xr-x 1 roo



t root 478 Aug 27 08:48 re.local
-rwxr-xr-x 1 root root
2809 Jul 14 16:45 re.modules
-rwxr-xr-x 1 root root
5586 Aug 16 22:45 rc.orig
-rwxr-xr-x 1 root root
10903 Mar 12 1999 re.serial
. drwxr-xr-x
2 root root
1024 Aug 11 23:04 rcO.d drwxr-xr-x
2 root root
1024 Aug 11 23:04 rcl.d drwxr-xr-x
2 root root
1024 Aug 11 23:04 rc2.d drwxr-xr-x
2 root root
1024 Aug 11 23:04 rcS.d drwxr-xr-x
2 root root
1024 Aug 11 23:04 rc4.d drwxr-xr-x
2 root root
1024 Aug 30 07:25 rcS.d drwxr-xr-x
2 root root
1024 Aug 30 07:25 rc6.d
-rwxr-xr-x 1 root



root 846 Jun 29 11:02 unconfigured.sh init.d/
-rwxr-xr-x 1 root root
2144 Jul 14 16:56 bigfs
-rwxr-xr-x 1 rootroot 864 Jan 28 1999 cron
-rwxr-xr-x
1 root root 1364 Apr 13 13:38 dhcpd
-rwxr-xr-x
1 root root 6920 Jul 14 16:55 functions
-rwxr-xr-x
1 root root 833 Jul 14 22:46 gpm
-rwxr-xr-x
1 root root 1296 Aug 16 22:45 halt
-rwxr-xr-x
1 root root 983 May 11 11:24 httpd
-rwxr-xr-x
1 root root 1243 Jul 14 15:52 inet
-rwxr-xr-x
1 root root 978 Jul 7 05:30 keytable lrwxrwxrwx
1 root root 11 Aug 5 12:35 local -> ../re.local
-rwxr-xr-x
1 root root 804 Jul 14 23:09 logoutd
-rwxr-xr-x
1 root root 931 Nov 4 1998 Ipd
-rwxr-xr-x
1 root root 1720 Jul 14 22:04 mta
-rwxr-xr-x
1 root root 1294 Jul 27 23:16 named
-rwxr-xr-x
1 root root 2260 Jul 14 16:05 netmount
-rwxr-xr-x
1 root root 2072 Jul 14 16:23 network
-rw-r-xr-x
1 root root 791 Jul 27 23:22 news
-r-xr-xr-x
1 root root 1863 Jun 22 07:57 nfs
-rwxr-xr-x
1 root root 1232 Jan 7 1998 nis-client
-rwxr-xr-x
1 root root 831 Jan 8 1998 nis-server
-rwxr-xr-x
1 root root 1489 Apr 3 00:26 ntp
-r-xr-xr-x
1 root root 3157 Aug 27 10:55 pcmcia
-rwxr-xr-x
1 root root 649 May 26 1998 ppp lrwxrwxrwx
1 root root 4 Aug 5 12:35 reboot -> halt
-rwxr-xr-x
1 root root 238 Oct 2 1997 rmnologin
-rwxr-xr-x
1 root root 780 Oct 2 1997 rstatd
-rwxr-xr-x
1 root root 1130 Jul 14 22:06 rusersd
-rwxr-xr-x
1 root root 1130 Jul 14 22:05 rwalld
-rwxr-xr-x
1 root root 1130 Jul 14 22:06 rwhod
-rwxr-xr-x
1 root root 1211 Jul 15 03:10 samba
-rwxr-xr-x
1 root root 969 Nov 25 1997 single
-rwxr-xr-x
1 root root 1159 Apr 9 1998 skeleton
-rwxr-xr-x
1 root root 607 Apr 29 04:15 skipped
-rwxr-xr-x
1 root root 1714 Jul 14 20:08 squid
-rwxr-xr-x
1 root root 1147 Mar 25 06:28 syslog
-rwxr-xr-x
1 root root 1060 Mar 16 1999 urandom
-r-xr-xr-x
1 root root 6949 Aug 30 07:25 vmware
-rwxr-xr-x
1 root root 259 Jul 21 09:27 webmin
-rwxr-xr-x
1 root root 990 Aug 10 17:48 xdm
-rwxr-xr-x
1 root root 948 Mar 25 07:53 zap rc2.d: lrwxrwxrwx
1 root root
14 Aug 5 12:35 KO5news -> ../init.d/news lrwxrwxrwx
1 root root
15 Aug 5 12:35 K09samba -> ../init.d/samba lrwxrwxrwx
1 root root
15 Aug 5 23:51 K12squid -> ../init.d/squid lrwxrwxrwx
1 root root
13 Aug 5 12:35 K25gpm -> ../init.d/gpm lrwxrwxrwx
1 root root
15 Aug 5 09:01 K25httpd -> . ./init.d/httpd lrwxrwxrwx
1 root root
17 Aug 5 12:35 K3Ologoutd -> ../init.d/logoutd lrwxrwxrwx
1 root root
16 Aug 5 12:35 K39rwalld -> .,/init.d/rwalld lrwxrwxrwx
1 root root
16 Aug 5 12:35 K40rstatd -> ../init.d/rstatd lrwxrwxrwx
1 root root
15 Aug 5 12:35 K44dhcpd -> ../init.d/dhcpd
lrwxrwxrwx
1 root root
17 Aug 5 12:35 K47rusersd -> ../init.d/rusersd lrwxrwxrwx
1 root root
15 Aug 5 12:35 K48rwhod -> ../init.d/rwhod lrwxrwxrwx
1 root root
13 Aug 5 12:35 K5Omta -> ../init.d/mta lrwxrwxrwx
1 root root
13 Aug 5 12:35 K60nfs -> ../init.d/nfs lrwxrwxrwx 1 root root
13
Aug
5 12:35 K70ntp -> ../init.d/ntp lrwxrwxrwx
1 root root
17 Aug 5 12:35 K73ipxripd -> ../init.d/ipxripd lrwxrwxrwx
1 root root
20 Aug 5 12:35 K79nis-client -> . ./init.d/nis-client lrwxrwxrwx
1 root root
20 Aug 5 12:35 K80nis-server -> . ./i nit. d/nis-server lrwxrwxrwx
1 root root
14 Aug 5 12:35 K85inet -> ../init.d/inet lrwxrwxrwx
I root root
15 Aug 5 21:25 K90named -> . ./init.d/named lrwxrwxrwx
1 root root
17 Aug 5 12:35 S0lnetwork -> ../Init.d/network lrwxrwxrwx
1 root root
16 Aug 5 12:35 S0lpcmcia -> . ./imt.d/pcracia lrwxrwxrwx
1 root root
16 Aug 5 12:35 S05syslog -> ../init.d/syslog lrwxrwxrwx
1 root root
17 Aug 5 12:35 S05urandom -> ../init.d/urandom lrwxrwxrwx
1 root root
18 Aug 5 12:35 S20netmount -> ../init.d/netmount lrwxrwxrwx
1 root root
13 Aug 5 09:02 S26ipx -> ../init.d/ipx lrwxrwxrwx
1 root root
13 Aug 5 12:35 S351pd -> ../init.d/lpd lrwxrwxrwx
1 root root
14 Aug 5 12:35 S40cron -> .,/init.d/cron lrwxrwxrwx
1 root root
13 Aug 5 12:35 S41atd -> ../init.d/atd lrwxrwxrwx
1 root root
18 Aug 5 12:35 S75keytable •> ../init.d/keytable lrwxrwxrwx
1 root root
15 Aug 5 12:35 S981ocal -> . ./irrit.d/local lrwxrwxrwx 1 root root
15
Aug
5 12:35 S99bigfs -> ../init.d/bigfs lrwxrwxrwx
1 root root
19 Aug 5 12:35 S99rmno1ogin -> ../init.d/rmnologin lrwxrwxrwx
1 root root
17 Aug 5 12:35 S99skipped -> ../init.d/skipped lrwxrwxrwx
1 root root
13 Aug 5 12:35 S99zap -> ../init.d/zap
Имена всех файлов из каталогов /etc/re.d/rc#.d начинаются либо с буквы S (от английского слова start
запуск), либо с буквы К (от английского слова kill — уничтожение). Соответственно, сценарии первой категории занимаются запуском демонов, а второй категории — их остановом. Вслед за первым символом идет число, определяющее относительный порядок выполнения сценариев, за которым следует собственно информационная часть имени, которая, как правило, совпадает с именем соответствующего сценария из init.d, на который указывает данная ссылка. Рассмотрим, например, файл S35lpd. Это символическая ссылка, указывающая на файл ../init.d/lpd, используемая сценарием rс для вызова сценария lpd из init.d с аргументом start, в результате чего начинает работу демон печати. Запустить этот сценарий можно из командной строки:
/etc/rc.d/init.d/lpd start
Именно в этом и состоит преимущество инициализации в стиле System V: пользователь root получает возможность запускать, останавливать и, в некоторых случаях, перезапускать и перезагружать произвольные демоны простым вызовом сценария из init.d с соответствующим аргументом. Выполнять это действие может только суперпользователь. Инициализация в стиле BSD не поддерживает подобного единого подхода к управлению различными демонами. Если в вашей системе используется стиль инициализации BSD, чтобы запустить или остановить тот или иной демон, вы должны знать, как именно этот демон управляется из командной строки, а это далеко не всегда ограничивается простым запуском исполняемого файла демона.
Если сценарий /etc/re.d/rc запускается без аргумента, он при помощи команды run level узнает текущий и предыдущий уровни выполнения и на основании этой информации определяет, какие сценарии и как ему следует запустить. Для этого он сравнивает содержимое каталогов, соответствующих предыдущему и текущему уровням выполнения, и, основываясь на различиях между ними, останавливает одни демоны и запускает другие. Говоря более подробно, сценарий rс сначала останавливает все те демоны, которые выполняются на момент его вызова и подлежат останову при переходе с предыдущего уровня выполнения на текущий, после чего стартует все те демоны, которые должны выполняться на текущем уровне, но сейчас не выполняются. Таким образом, сначала выполняются сценарии с префиксом
К в порядке от младших номеров к старшим, а затем сценарии с префиксом S тоже от младших номеров к старшим. Благодаря этому запуск и остановка демонов осуществляются в нужном порядке. Например, прежде чем запускать sendmail (mta) или web-сервер Apache (httpd), следует запустить сетевую подсистему.
И наоборот, прежде чем останавливать сетевую подсистему, сначала нужно остановить все зависящие от нее службы.
Такое поведение является отличительной чертой комплекта OpenLinux компании Caldera. В комплекте Red Hat и в других комплектах каталоги не сравниваются, вместо этого просто выполняются сценарии останова и запуска из каталога, соответствующего новому уровню выполнения.
Сценарии rс, часть вторая
Теперь, когда вы получили общее представление об инициализации системы, от ядра и до программы init, я расскажу вам о некоторых деталях этого процесса подробнее. В данном разделе главы я более
подробно расскажу о механизме запуска-останова демонов при смене уровней выполнения. Поскольку программа init запускается ядром, она обладает привилегиями суперпользователя. Таким образом, всякий процесс, запущенный из строк 36-42 листинга 7.1, будет запущен на уровне привилегий суперпользователя, если, конечно, он явно не был запущен от имени другого (непривилегированного) пользователя. Если злоумышленнику удастся вставить туда команду запуска программы, сохраняющей коды клавиш, нажимаемых в ответ на приглашение входа в систему, и время от времени отсылающей этот файл по электронной почте на указанный им адрес, то вскоре в распоряжении злоумышленника окажутся имена и пароли всех активных пользователей системы. Если пользователь сможет в одном из каталогов
/etc/rc.d/rc[l-5].d/ создать ссылку на какой-нибудь посторонний файл, то во время инициализации системы этот файл может быть запущен на выполнение от имени суперпользователя.
ВНИМАНИЕ
Все файлы, расположенные в каталоге /etc/red/ и его подкаталогах и запускаемые в процессе инициализации
системы, выполняются от имени суперпользователя (в дистрибутиве Debian это замечание относится к
подкаталогам rc.boot/, rc[0-6].d/ и init.d/, расположенным непосредственно в каталоге /etc). Если это ссылка, то
независимо от того, ведет ли она за пределы /etc/rc.d/ или нет, файл, на который она указывает, все равно
выполняется от имени суперпользователя. Любые изменения в существующих сценариях или добавления новых могут
вступить в силу при следующей перезагрузке или смене уровня выполнения. Вывод очевиден: правом на запись в файлы
и каталоги, используемые при инициализации системы, должен обладать только суперпользователь и никто другой.
Далее идет очень короткий обзор некоторых ключевых сценариев, включая один сценарий запуска- останова демона. Обучение чтению сценариев не входит в задачи данного текста, поэтому при возникновении трудностей следует обратиться к книге, посвященной разработке сценариев командной оболочки. Первым будет рассмотрен сценарий /etc/rc.d/rc (см. листинг 7.3 5
). Номера строк в самом сценарии отсутствуют, они добавлены мною для удобства дальнейшего изложения.

Листинг 7.3. Сценарий re (номера строк добавлены искусственно) 1 #\/bin/bash 2#
3 # гс This file is responsible for starting/stopping
4 # services when the run!eve! changes.
5#
6 # Temporary feature:
7

# If the action for a particular feature in the new run-level
8 # is the same as the action in the previous run-level, this
9 # script will neither start nor start that feature, since that
10 # would have no effect except to thrash the system for no reason.
11 # Once all scripts are converted to use start-stop-daemon
12 # to _start_ their daemons (most of them only use it to kill
13 # them), this feature can be removed.
14 #
15 # $Id: rc.v 1.7 1999/07/14 21:36:04 ray Exp $
161 17 # Author: Miquel van Smoorenburg,
18 # Hacked to bits by Bruce Perens
19 # Modified for COL by Raymund Will
20 #
21 22 export RC_DEBUG=false
23 export RC_VERBOSE=true
24 LOG=/dev/tty12 25 26 true() { return 0; }
27 false() { return 1; }
28 Echo() {
29 local a=$l; shift
30 local o=$l; shift
31 local i
32 33 echo -n "$a" >> $LOG
34 for i in "$@"; do
35 echo -n " '$i'" >> $LOG
36 done
37 echo "$o" >> $LOG
38 }
39 40 # check for new-style boot-logger

5
Комментарии в листинге оставлены без перевода, чтобы не нарушить нумерацию строк. Описание работы сценария см. далее в книге. — Примеч. перев.

41 export SVIBooter=/sbin/booter
42 [ -x $SVIBooter ] | SVIBooter=false
43 44 if $SVIBooter test; then
45 export SVIuseBooter=true
46
CMDS="add start"
47 48
# redirect STDOUT and STDERR
49 exec - >> $LOG 2>&1 50 51
#DEBUGGING
52
Booter() {
53 local c=$l; shift
54 local s
55 local i
56 57 case "$c" in
58 add)
59 s="$l"; shift
60 eval "$s" $c
61 ;;
62 start)
63 s="$l": shift
64 eval "$s" $c "$@"
65 case $? in
66 0) $SVIBooter ok;;
67 1) $SVIBooter fail;;
68 2) $SVIBooter skip;;
69 *) $SVIBooter "N/A" ;;
70 esac
71 ;;
72 stop)
73 s="$l"; shift
74 Echo "# Booter " "." "$s" $c "$@"
75 eval "$s" $c "$@"
76 ;;
77 *)
78
$SVIBooter $c "$@"
79 ;;
80 esac
81
}
82
[ -z "$PREVLEVEL" ] && {PREVLEVEL=N
83 else
84
SVIuseBooter=false
85
CMDS="start"
86 87
# Set onlcr to avoid staircase effect.
88 stty onlcr 0>&1 89 90 Booter() {
91 local c="$1"; shift
92
[ "$c" != "start" -a "$c" != "stop" ] && return 0 93 local s="$l"; shift
94
Echo "# eval " "." "$s" $c "$@"
95 eval "$s" $c "$@"
96 }
97 fi
98 99 # Now find out what the current and what the previous run!eve! are.
100 101 runlevel=$RUNLEVEL
102 # Get first argument. Set new run!eve! to this argument.
103 [ -n "$1" ] && runlevel=$l
104 105 previous=$PREVLEVEL 106 107 Echo "runlevel=$runlevel previous=$previous" "."
108 export runlevel previous
109 110 RCD=/etc/rc.d
111 # Is there an re directory for this new runlevel?
112 if [ -d "$RCD/rc$runlevel.d" ]; then
113 avoid="" # A list of start scripts I don't have to run.
114

115
# First, run the KILL scripts.
116 if [ "$previous" != N ]; then
117 for i in $RCD/rc$rumevel.d/K[0-9][0-9]*; do
118
# Check if the script is there.
119
[ -f "$i" ] || continue
120 121 suffix=${i#$RCD/rc$runlevel
.d/K[0-9][0-9]}
122 123
# Generate the name of the start script corresponding
124
# to this stop script, the start script in the previous
125
# level, and the stop script in the previous level.
126
# Check these files, and see if the previous level's
127
# files are links to the ones for this level.
128
# If they are, this level treats this feature the same
129
# as the previous level, and I don't have to run these
130
# files.
131 stopIt=true
132 start=$RCD/rc$runlevel.d/S[0-9][0-9]$suffix
133 previous_start=$RCD/rc$previous.d/S[0-9][0-9]$suffix
134 previous_stop=$RCD/rc$previous.d/K[0-9][0-9]$suffix
135 136 if [ -f $previous_stop ] && [ $i -ef $previous_stop ]; then
137 stopIt=false
138 if [ -f $start ] || [ -f $previous_start ]: then
139 if [ -f $start ] &&
140
[ -f $previous_start ] &&
141
[ $start -ef $previous_start ]; then
142 stopIt=true
143 else
144 avoid=$avoid"
"$start
145 fi
146 fi
147 fi
148 149
# Kill it.
150
$stopIt && Booter stop $i
151 done
152 fi
153 154 Booter list "RUNLEVEL Run-level change..."
155 Booter add_menu "BLANK4"
156 Booter add_menu "T4 Entering run-level $runlevel:"
157 for cmd in $CMDS; do
158 159
# Now run the START scripts for this runlevel.
160 for i in $RCD/rc$runlevel.d/S*; do
161
# Check if the script is there.
162
[ -f "$i" ] || continue
163 164 startIt=true
165 case " $avoid " in
166 *\ $i\ *) startIt=false;:
167 esac
168 if $startIt; then
169 suffix=${i#$RCD/rc$runlevel.d/S[0-9][0-9]}
170 previous_start=$RCD/rc$previous.d/S[0-9][0-9]$suffix
171 stop=$RCD/rc$runlevel .d/K[0-9][0-9]$suffix
172 if [ -f $previous_start ] &&
173
[ $i -ef $previous_start ] &&
174
[ ! -f $stop ]; then
175 startlt-false
176 fi
177 fi
178 179 $startlt && Booter $cmd $i
180 done
181 182 if [ "$cmd" != "add" ]; then
183 Booter complete RUNLEVEL
184 else
185
Booter end
186
Booter activate RUNLEVEL
187 fi
188 done

189 fi
190 191 [ $SVIuseBooter = false ] && exit 0 192 193 194 if [ $runlevel != 5 ]: then
195 sleep 1 196 /usr/bin/chvt 1 197 else
198 /sbin/booter list "FINAL"
199 /sbin/booter add_menu "BLANK5"
200 /sbin/booter add "KDE Starting KDE"
201 /sbin/booter end
202 /sbin/booter activate "FINAL"
203 /sbin/booter item "KDE"
204 sleep 1 205 ( trap "" SIGHUP
206 sleep 10 207 echo -e "\n\nPlease switch to a different virtual console for login!\n\n"
208 ) > /dev/tty7 &
209 fi
210 211Booter quit
212
# eof /etc/rc.d/rc
Строки, начинающиеся с символа #, считаются комментариями (за исключением самой первой строки, в которой указывается программа, используемая для выполнения команд сценария) и при выполнении сценария игнорируются. В строках 2-117 происходит инициализация переменных, определяются текущий и предыдущий уровни выполнения, а также сравниваются сценарии запуска- останова из соответствующих этим уровням подкаталогов каталога /etc/rc.d.
В строках начиная с 119 и до конца файла сначала выполняются сценарии останова демонов, ненужных на новом уровне выполнения. После этого осуществляется выполнение сценариев запуска демонов, которые должны выполняться на новом уровне, но сейчас не выполняются.
Следующим сценарием, который мы рассмотрим, будет типичный сценарий запуска-останова демона. Множество подобных сценариев расположено в каталоге /etc/re.d/init.d. Большинство таких сценариев очень похожи на сценарий из листинга 7.4 6

Листинг 7.4. Сценарий старта-останова демона named
1 #!/bin/sh
2 #
3 # named This shell script takes care of starting and stopping
4 # named (BIND DNS server).
5#
6 7 NAHE=named
8 DAEMON=/usr/sbin/$NAME
9 10 # Source function library.
11 . /etc/rc.d/init.d/functions
12 13 # Source networking configuration.
14 . /etc/sysconfig/network
15 16 # Check that networking is up.
17 [ ${NETWORKING} = "no" ] && exit 0 18 19 [ -r
/etc/sysconfig/daemons/$SUBSYS ] || ONBOOT=Yes
20 [
! -r /etc/sysconfig/daemons/$SUBSYS ] || . /etc/sysconfig/daemons/$SUBSYS
21 [
"$ONBOOT" = "no" -a "$PROBABLY" = "booting" ] && exit 0 22 23 [ -x $DAEMON ] || exit 0 24 25 26 # See how we were called.
27 case "$1" in
28 start)
29 [ -e /var/lock/subsys/$SUBSYS ] && exit 1 30

6
Комментарии в листинге оставлены без перевода, чтобы не нарушить нумерацию строк. Подробное описание работы сценария см. далее в книге. — Примеч. перев.

31 [ -f /etc/named.conf ] |] exit 0 32 33 # Start daemons.
34 echo -n "Starting BIND DNS server: "
35 start-stop-daemon -S -n $NAME -x $DAEMON -- $OPTIONS
36 echo "."
37 touch /var/lock/subsys/$SUBSYS
38 ;;
39 40 stop)
41 [ -e /var/lock/subsys/$SUBSYS ] || exit 0 42 43 # Stop daemons.
44 echo -n "Stopping BIND DNS server: "
45 start-stop-daemon -K -p /var/run/$NAME.pid -n $NAME
46 echo "."
47 rm -f /var/lock/subsys/$SUBSYS
48 ;;
49 50 restart)
51 [ -e /var/lock/subsys/$SUBSYS ] || exit 0 52 53 echo -n "Re-starting BIND DNS server: "
54 start-stop-daemon -K -s 1 -p /var/run/$NAME.pid -n $NAHE
55 echo "."
56 ;;
57 58 *)
59 echo "Usage: named {start|stop|restart}"
60 exit 1 61 esac
62 63 exit 0
Как и ранее, строки, начинающиеся с символа #, адресуются читающему сценарий пользователю и при выполнении игнорируются.
В строках 7 и 8 инициализируются некоторые переменные, а строки 11 и 14 включают в исходный текст сценария некоторые глобальные переменные из конфигурационного каталога системы (такой каталог присутствует далеко не во всех комплектах Linux). Строка 17 проверяет, запущена ли сетевая подсистема, и если нет и в случае, если сеть не работает, прекращает выполнение сценария (бессмысленно запускать
DNS-сервер в отсутствие сети). Строка 23 позволяет убедиться в том, что файл демона существует и является исполняемым.
После этого выполняется обработка аргумента, переданного в сценарий. Если использован аргумент start, выполняются строки 29-38. Если использован аргумент stop и демон запущен (это проверяется в строке 41), то выполняются строки 44-48. Если аргументом является restart и демон запущен (это проверяется в строке 51), то выполняются строки 53-56, посылающие ему сигнал SIGHUP (1). Этот сигнал предписывает демону заново прочесть свой конфигурационный файл и продолжить работу.
Наконец, если аргумент не был распознан или попросту отсутствует, выдается подсказка по использованию сценария.
Примерно так же работают и все остальные сценарии старта-останова в стиле System V. Детали зависят от дистрибутива, но общий подход везде один и тот же. Инициализация в стиле BSD происходит несколько по-другому: вместо многих небольших сценариев в этой системе используется несколько больших и отсутствует механизм start/stop/restart.

Заключение
В этой главе была рассмотрена инициализация в стиле System V. И хотя изложение было ориентировано на систему Caldera Open Linux 2.3, представленный в ней материал применим и ко многим другим комплектам Linux, использующим инициализацию в стиле System V. Также был затронут круг вопросов, связанных с начальной загрузкой системы. Были рассмотрены уровни выполнения, которые являются средством организации демонов в группы. Вы также узнали об использовании сценариев инициализации для запуска/останова демонов при переходе с одного уровня выполнения на другой.
Кроме того, из этой главы явствует, что если злоумышленнику удастся подменить сценарий инициализации или изменить уже существующий, благодаря этому во время инициализации ОС он сможет
запустить любую программу с привилегиями суперпользователя.


Физическая безопасность и
консольные атаки
8
В данной главе рассматриваются следующие вопросы:
- уязвимые места системы, которыми можно воспользоваться до загрузки ядра;
- загрузчик LILO;
- параметры загрузки на непредвиденный случай;
- восстановление позабытого пароля учетной записи root;
- резервное копирование системы;
- защита вашей сети.
Прочитав предыдущую главу, вы, должно быть, уже получили представление о том, какими элементами системы может воспользоваться злоумышленник, желающий взломать систему и обладающий физическим доступом к взламываемому компьютеру. В данной главе будет продемонстрировано, как именно реализуется подобный взлом (если вы не закрыли пару-другую пробелов в вашей системе безопасности). Узнав о том, с какой простотой этого можно добиться, вы поймете, почему можно считать, что каждый, обладающий физическим доступом к компьютеру, фактически «владеет» им.
До загрузки ядра
Система беззащитна перед консольными атаками в любое время, даже до того, как произойдет ее начальная загрузка. Все что нужно для организации подобной атаки — это перезагрузить систему.
Перезапуск можно выполнить либо при помощи обычной команды shutdown, либо щелкнув BRS (BRS —
Big Red Switch — большой красный переключатель, то есть переключатель подачи электропитания). Если вы просто выдернете шнур электропитания из розетки, вы получите тот же самый результат. Таким образом, выполнить принудительную остановку работающей системы совсем несложно. Как только система прекратила свою работу, вы можете загрузиться либо с гибкого диска, либо с компакт-диска CD-
ROM.
Да, да, конечно, вы можете войти в BIOS и настроить компьютер так, чтобы единственным допустимым загрузочным диском был диск С: (/dev/hdc), то есть для загрузки будет использоваться только главная загрузочная запись MBR. После этого, чтобы предотвратить изменение этого параметра, вы можете защитить BIOS при помощи пароля. Теперь для того, чтобы войти в систему, злоумышленник должен обладать паролем BIOS, так как иначе он не сможет войти в BIOS и, стало быть, не сможет загрузить систему так, как ему это нужно.
ПРИМЕЧАНИЕ
Настройка пароля для BIOS — это не то же самое, что настройка пароля для суперпользователя. Возможно, для
вас будет удобным сделать пароль BIOS таким же, как и пароль пользователя root (суперпользователя), так как
пароль BIOS используется чрезвычайно редко, поэтому его очень легко позабыть. Однако если вы решили
использовать подобную политику, никогда не забывайте менять пароль BIOS синхронно со сменой пароля root, иначе
вы легко можете запутаться в паролях.
Если спустя несколько месяцев (или лет) вы обнаруживаете, что забыли пароль для входа в BIOS, не волнуйтесь. Вы можете обратиться к документации (если она у вас, конечно, есть) установленной в вашем компьютере материнской платы для того, чтобы узнать, как можно сбросить содержимое CMOS (то есть энергонезависимой памяти, в которой хранятся значения параметров BIOS). Как правило, для этого требуется замкнуть специальный установленный на материнской плате переключатель. В результате содержимое CMOS устанавливается равным значениям по умолчанию, при этом материнская плата забывает о существовании пароля BIOS и вы сможете беспрепятственно проникнуть в BIOS, чтобы заново настроить CMOS. Эта возможность поддерживается большинством современных материнских плат.
Однако некоторые достаточно старые модели такой возможности не поддерживают. В этом случае вам придется отключить систему от питания, отключить от материнской платы специальную батарейку CMOS
и подождать около 20 минут (30 минут, чтобы уж точно не ошибиться). При этом значения параметров
CMOS (где, собственно, и хранится пароль) станут равными значениям по умолчанию. Это означает, что все остальные значения аппаратной конфигурации, в соответствии с которыми система была настроена ранее, будут утеряны. Вам придется заново настраивать BIOS. Однако здесь важно обратить внимание на то, что если вы можете проделать такую процедуру с содержимым CMOS, значит, это может сделать и любой другой, кто обладает физическим доступом к компьютеру. Иными словами, пароль BIOS не является достаточно надежной защитой вашей системы.
СОВЕТ
На случай потери содержимого CMOS я рекомендую вам сохранить значения параметров BIOS в надежном месте.
Вы можете переписать их на бумагу или сохранить где-либо в электронном виде, например, в виде снимков
различных экранов BIOS. Имейте в виду, что содержимое CMOS может быть утеряно не только в результате
необходимости сбросить пароль BIOS. Причиной утери содержимого CMOS может стать севшая батарейка, это
может произойти в случае, если вы отключите систему от электропитания на достаточно длительное время.

LILO
После того как компьютер завершает процедуру начального тестирования POST, он приступает к поиску операционной системы, которую следует загрузить. Если вы настроили BIOS таким образом, чтобы компьютер мог загрузиться только с диска С:, происходит обращение к главной загрузочной записи MBR этого диска. Из MBR в оперативную память компьютера загружается исполняемый код начального загрузчика. В данной книге я предполагаю, что Linux является единственной операционной системой, установленной на компьютере, а в качестве загрузчика используется LILO, являющийся стандартным загрузчиком в среде Linux. Начальные загрузчики большинства современных операционных систем работают аналогичным образом и используют сходный набор параметров. В частности, если вы имеете дело с системой, оснащенной несколькими ОС (например, Linux и Windows, Solaris, BeOS, OS/2 и т. п.), как правило, у вас есть возможность выбрать одну из установленных систем для того, чтобы загрузить ее в память компьютера. Выбор осуществляется с использованием LILO или другого аналогичного менеджера начальной загрузки. Более подробно об этом вы можете узнать из инструкций, прилагаемых к используемому вами менеджеру загрузки. Подробнее о LILO можно узнать в любом хорошем руководстве по администрированию системы Linux.
По умолчанию, если в MBR содержится LILO, значит, в глобальном разделе файла /etc/lilo.conf содержится пара стандартных строчек:
prompt timeout= 50
Эти параметры предназначены для осуществления двух функций: первая из них обеспечивает вам возможность выбора между несколькими образами загрузки (ядрами
ОС), вторая обеспечивает временную задержку для осуществления выбора. Первый параметр lilo.conf (параметр prompt) указывает на то, что в процессе начальной загрузки менеджер загрузки LILO должен отобразить на экране компьютера приглашение LILO:.
Если параметр prompt не указывается в файле lilo.conf,
значит, никакого приглашения на экран не выводится. Второй параметр сообщает LILO о том, какое количество времени (в десятых долях секунды) следует подождать, прежде чем приступить к загрузке ядра
ОС по умолчанию. Благодаря этому осуществляется поддержка автоматической загрузки ОС на вашем компьютере. Иными словами, чтобы загрузить ОС по умолчанию, вы можете включить компьютер и больше не предпринимать никаких действий — LILO предложит вам выбрать одну из ОС; если вы не воспользуетесь этой возможностью и никак не прореагируете на предложение, LILO подождет в течение указанного времени (значение параметра timeout в рассмотренном ранее примере соответствует пяти секундам), а затем приступит к загрузке ядра ОС по умолчанию.
ВНИМАНИЕ
Если в файле /etc/lilo.conf вы используете параметр prompt и при этом забыли добавить (или удалить) параметр
timeout=, ваша система не будет обладать возможностью загрузки без участия пользователя.
Если вы удалите из файла lilo.conf обе строки, система всегда будет напрямую загружать ядро ОС по умолчанию. Вы не сможете выбирать, какую из ОС вам хотелось бы загрузить, кроме того, вы не сможете
передавать ядру ОС какие-либо параметры загрузки. В этом случае все необходимые параметры загрузки должны располагаться в разделе image файла lilo.conf.
ВНИМАНИЕ
Если загрузчик LILO настроен на прямую загрузку ядра ОС по умолчанию и если вы меняете ядро, вы должны либо
перенастроить LJLO, либо создать загрузочный диск со старым ядром, готовым к загрузке. Этот диск следует
держать наготове до тех пор, пока вы не убедитесь в том, что новое ядро загружается без каких-либо проблем и
сбоев.
Если удаление обеих этих строк невозможно (как правило, из-за того, что на вашем компьютере установлена еще одна операционная система, будь то Linux или любая другая ОС), вы можете защитить паролем загрузку любого из образов ОС. Настройка пароля выполняется для каждого из ядер по отдельности.
ПРИМЕЧАНИЕ-
По умолчанию файл /etc/lilo.conf может прочитать кто угодно, поэтому если вы намерены защитить паролями
загрузку каких-либо ядер ОС, скорее всего, будет разумным выполнить в отношении этого файла команду chmod 600.
Существует еще один вариант: после запуска LILO вы можете переместить файл /etc/lilo.conf на гибкий диск, так
как он не требуется для того, чтобы продолжить загрузку системы. Помните, что если ядро ОС по умолчанию
(которое указывается в lilo.conf в самой первой позиции) защищено паролем, система не сможет выполнить
автоматическую загрузку без участия пользователя, в связи с этим, возможно, будет удобнее защитить паролем
только те ядра, которые не являются ядрами ОС по умолчанию.
Параметры загрузки для непредвиденных ситуаций
Иногда в результате даже самой аккуратной переделки ядра или тщательно проверенного редактирования инициализационных файлов нечто препятствует корректному завершению процедуры инициализации. Конечно же, если вы редактируете файл inittab или любой из сценариев rс, вы делаете это с большой осторожностью. Вы тщательно продумываете каждое вносимое вами изменение, а также выполняете тестирование. Однако даже самые лучшие тесты не могут полноценно имитировать реальную загрузку системы, и сценарий, который выглядит вполне корректным и работоспособным, в процессе реального запуска системы может не выполниться или, того хуже, привести к зависанию системы.
Причинами могут быть самые разные факторы, однако чаще всего неприятности возникают из-за того, что определенные действия выполняются в неправильной последовательности.
Для примера рассмотрим сценарий, который используется для запуска процесса kerneld на начальных стадиях загрузки системы, которая использует ядро версии 1.2.13 с модулями. После обновления ядра системы до версии 2.0.25 я решил использовать тот же самый сценарий. К сожалению, в результате выполнения этого сценария в момент загрузки нового модуля kerneld, который работает совместно с новой версией ядра, система зависает. После непродолжительных исследований я обнаружил, что новая версия процесса kerneld должна знать имя узла (hostname) системы, однако на момент загрузки kerneld имя узла системе еще не известно. Чтобы решить проблему, необходимо просто запустить процесс определения имени узла раньше, чем загружается kerneld (то есть в файле /etc/rc.d/rc.boot). Описанная история произошла лично со мной, однако она могла произойти с кем угодно. Подчас достаточно позабыть добавить нужный ключ или упустить полный путь к исполняемому файлу, и отредактированный вами сценарий перестает корректно работать.
СОВЕТ
Если вам кажется, что система зависла, это вовсе не значит, что она действительно зависла. Прежде чем
паниковать, жать на или кнопку отключения электропитания, как минимум, следует подождать, пока
истечет IP-тайм-аут. Как правило, длительность этого тайм-аута составляет 2 минуты, но он может длиться и
несколько дольше. Если вы удалите строку vga=274, вы сможете увидеть имя каждого из сценариев rс по мере того,
как они будут выполняться. Обратите внимание на то, какой из них был запущен последним. Возможно, именно он
является причиной проблемы. В дальнейшем для отладки вы должны в первую очередь обратиться именно к этому
сценарию.
К счастью, если в файле lilo.conf вы используете строки prompt и timeout, вы сможете передавать программе init параметры. Когда система загружается и вы видите на экране приглашение LILO:, вы можете нажать клавишу , а затем клавишу <ТаЬ> для того, чтобы увидеть набор меток ядра, доступных для загрузки. После этого вы можете набрать на клавиатуре одну из меток, а за ней указать любой набор параметров, который вы желаете использовать для загрузки системы. Любые используемые
ядром параметры извлекаются из введенной вами строки, оставшиеся в строке параметры передаются далее по цепочке программе init. Например, если ваш компьютер оснащен оперативной памятью объемом
128 Мбайт и при этом вы желаете, чтобы из этой памяти использовались только первые 96 Мбайт, вы можете указать параметр запуска в виде: mem=96MB (или любой другой объем RAM). Этот параметр будет воспринят и обработан ядром. Однако если вы укажете параметр -Ь, ядро не будет его обрабатывать и передаст этот параметр программе init. Это относится к любому однозначному числу или буквам s или q либо в верхнем, либо в нижнем регистре.
СОВЕТ
Параметр - Ь используется для запуска системы в режиме обслуживания, то есть без выполнения каких-либо
сценариев rс. Это очень удобно в случае, если вы подозреваете, что выполнение одного из этих сценариев нарушает
корректную работу системы.
Передав любой из допустимых номеров или букв, обозначающих один из уровней запуска, вы отменяете действие значений по умолчанию, определенных в файле inittab. Большая часть этих букв или цифр делают то, что полагается, если они передаются из командной строки работающей системы. Однако аргумент -b выполняет особую функцию. Этот параметр является специальным параметром на случай сбоев. Если вы передаете программе init параметр -b, эта программа выполняет чтение файла inittab, однако при этом ни один из сценариев rс не выполняется. Этот параметр также заставляет систему перейти на уровень запуска 1 (режим обслуживания). Таким образом, сценарии rс не запускаются. В результате вы получаете возможность монтировать систему для чтения/записи и исправить ее. Однако даже при использовании ключа -b некоторые строки файла inittab все же обрабатываются. Такими строками являются строки с идентификаторами (id), начинающимися с символа
, например или
1. Если вы намерены добавить в initttab команду запуска некоторого сценария и присвоить соответствующей строке идентификатор, начинающийся с символа
, будет лучше проверить этот сценарий с каким-либо другим id, и лишь убедившись в его работоспособности, назначить ему id, начинающийся с
. В страницах электронной документации man вы не найдете описания этой возможности, так как она не является документированной.
Взгляните на листинг 7.1 в главе 7. В этом листинге присутствуют следующие строки:
1:S:wait:/etc/rc.d/rc 1
:S:wait:/sbin/sulogin
Вне зависимости от того, используете ли вы ключ -b или нет, эти две строки файла inittab будут исполнены. Вторая строка заставляет систему отобразить приглашение на ввод пароля учетной записи root.
И все же это не обеспечивает полной безопасности.
ВНИМАНИЕ
В следующем абзаце рассказывается о возможности загрузки непосредственно в командную оболочку. При
выполнении этой процедуры могут возникнуть необратимые повреждения файловой системы, поэтому данную
возможность следует использовать только в самом крайнем случае!
Если же несмотря на все ваши усилия вы обнаруживаете, что даже при передаче загрузчику LILO ключа -b система подвисает в процессе загрузки или вы просто забыли пароль учетной записи root, не отчаивайтесь. В подобной ситуации после появления на экране приглашения LILO: вы можете передать загрузчику параметр init=/bin/sh. Этот аргумент используется ядром. Если вы помните, прежде чем приступить к работе в фоновом режиме, ядро запускает одну и только одну программу: init. Если же вы передадите ядру указанный ранее аргумент, вместо init ядро запустит исполняемый файл командной оболочки. Эта процедура чрезвычайно опасна, однако благодаря этому вы сможете смонтировать корень файловой системы в режиме для чтения и записи (mount -n -о remountrw /), отредактировать /etc/inittab или
/etc/shadow, после этого выполнить синхронизацию при помощи sync и перезагрузить систему. В данном случае, прежде чем выполнять перезагрузку, я рекомендую запустить sync дважды. При обращении к sync
«грязные» буферы будут сброшены на диск, благодаря чему вы можете быть уверены в том, что любые внесенные вами изменения действительно сохранены на диске. Данный метод исправления важных инициализационных файлов должен использоваться только в самом крайнем случае, когда у вас не остается больше никакой другой альтернативы, кроме переустановки системы. Дело в том, что в ходе выполнения этой процедуры вы можете нарушить целостность вашей файловой системы и таким образом сделать переустановку ОС неизбежной.


Восстановление пароля root
Прежде чем вы попытаетесь сделать то, о чем только что говорилось, вы должны попытаться воспользоваться загрузочным гибким диском Caldera OpenLinux (или загрузочным диском, входящим в ваш комплект поставки Linux) или установочным компакт-диском (большинство таких дисков являются загрузочными) и попытаться загрузить систему. Как только перед вами появится экран, на котором вам предлагается выбрать диск, на который вы хотите установить Linux, остановитесь. Если вы продолжите, будет запущена программа fdisk, а это не то, что вам нужно. Как правило, при помощи загрузочного диска вы можете выполнить загрузку ОС, а затем, не продолжая установку, перейти в режим командной строки. В разных вариантах поставок Linux для этой цели требуется выполнить разные действия, однако, как правило, все они похожи. Вы должны свериться с руководством, которое входит в используемый вами комплект поставки.
В частности, если вы используете Caldera OpenLinux, на экране, предлагающем вам выбрать диск для установки, вы должны нажать комбинацию клавиш ++, после чего следует подключиться к системе с использованием учетной записи root (при этом вам не потребуется вводить пароль). Как и другие разновидности поставки, Caldera OpenLinux использует виртуальный диск в оперативной памяти (ramdisk), который представляет собой полную корневую файловую систему, в которую входит подкаталог с именем target. Вы можете смонтировать вашу старую корневую файловую систему в каталоге target, перейти в подкаталог target/etc (cd target/etc) и затем отредактировать теневой файл паролей. Если вы забыли пароль, вы должны просто удалить хэшированный пароль из файла (вы не должны оставить между двумя двоеточиями ни одного символа, даже пробела). После этого перейдите обратно в корневой каталог (cd /), размонтируйте файловую систему, которую вы смонтировали в каталоге target (это очень важно), а затем перезагрузите систему как обычно, то есть с использованием вашей старой файловой системы. В результате вы сможете в систему с использованием учетной записи root, не сообщая при этом пароля.
ВНИМАНИЕ
Без пароля учетной записи root ваша система является совершенно беззащитной. Выполняя описанную процедуру, вы
должны отключиться от сети (просто выдерните кабель Ethernet из разъема сетевой карты), а войдя в систему, в
самую первую очередь немедленно восстановите пароль учетной записи root.
Не забывайте о том, что любой человек, обладающий физическим доступом к вашему компьютеру, может проделать все, о чем здесь рассказывалось.
Резервное копирование
Наверное, наиболее недооцененной областью системной безопасности является резервное копирование данных. Просматривая любые инструкции и руководства, связанные с Linux, вы очень часто будете сталкиваться с фразой: «Наверняка у вас уже есть свежая резервная копия данных, не так ли?».
Резервное копирование рекомендуется делать всем, даже домашним пользователям. Однако далеко не у всех есть устройство записи информации на магнитную ленту (стриммер). Хороший стриммер до сих пор является, наверное, самой дорогостоящей частью системы. Зачастую такие устройства используются только на коммерческих предприятиях.
У многих из вас может возникнуть желание использовать для резервного копирования диски Zip, сменные жесткие диски или даже записываемые компакт-диски. Все эти варианты вполне могут применяться для хранения архивов, однако вы должны знать о некоторых весьма серьезных недостатках всех этих носителей по сравнению с магнитной лентой. В частности, диски Zip на самом деле недостаточно хорошо защищены от ошибок. Они не обладают столь же надежными механизмами обнаружения и коррекции ошибок, которые используются в жестких дисках. Если вы намерены использовать для резервного копирования Zip-диск, будьте готовы к потерям данных. Использование сменных жестких дисков может показаться весьма приемлемым вариантом, однако вы должны учитывать, что сменные жесткие диски столь же беззащитны перед скачками напряжения, как и обычные жесткие диски. Таким образом, при неудачном стечении обстоятельств вы можете потерять данные как на своем основном жестком диске, так и на сменном жестком диске, на котором хранилась резервная копия. Наконец, записываемые компакт-диски обладают невысокой скоростью записи, кроме того, их емкость не может быть более 660 Мбайт.
Существуют самые разнообразные рекомендации относительно того, как следует выполнять резервное копирование. Вы можете каждый вечер создавать полную резервную копию всей системы, вы можете делать это один раз в неделю и при этом ежедневно или три раза в неделю выполнять добавочное
(incremental) резервное копирование. Многие компании организуют хранение еженедельных или
ежемесячных резервных копий на стороне, то есть вне здания фирмы, в которой функционирует система.
Таким образом, ленты, на которых хранятся резервные копии, размещаются как в здании фирмы, так и в другом здании, благодаря чему надежность хранения данных возрастает. Для этой цели вы должны выбрать компанию с хорошей репутацией и хранить свои резервные копии так, чтобы никто кроме вас не обладал бы физическим доступом к вашим лентам резервного копирования.
К сожалению, во многих местах, где мне приходилось бывать, ленты резервного копирования зачастую забываются вставленными в стримеры или хранятся так, что любой может получить к ним доступ. На самом деле физическим доступом к лентам резервного копирования должны обладать только те люди, которые по долгу службы должны знать пароль учетной записи root. На деле ленты резервного копирования должны защищаться от постороннего доступа даже лучше, чем сами системы.
Ленты резервного копирования, в особенности те из них, которые хранят на себе полную резервную копию всей системы, содержат полный образ системы. Их можно использовать для того, чтобы в точности воссоздать систему. Фактически хорошая резервная копия системы — это даже лучше, чем возможность физического доступа к системе. Дело в том, что содержимое ленты можно загрузить на любой другой системе. Для этого достаточно знать название утилиты, при помощи которой была создана данная резервная копия (на самом деле многие графические коммерческие утилиты резервного копирования просто-напросто выполняют функции интерфейса для упрощения работы с традиционными утилитами резервного копирования Linux, такими как tar, cpio или dump).
Если злоумышленник получает возможность загрузить на какую-либо другую систему всего один файл /etc/shadow, значит, он получает доступ не только к тем сведениям, которые хранятся в системе в данный момент (все эти сведения и так записаны на ленту с резервной копией), но и к тем данным, которые появятся в системе в будущем. В этом случае все пароли, включая пароль root, следует считать раскрытыми. Загрузив файл теневых паролей на свой компьютер, злоумышленник может не спеша использовать в отношении этого файла любые программы автоматического взлома. В скором времени ему станет известно большинство паролей. Однако наиболее важным будет пароль root.
СОВЕТ
Если вы подозреваете, что содержимое резервной копии стало доступным для неавторизированного лица либо в
результате кражи, либо в результате несанкционированного копирования, вы должны сменить все пароли на данной
системе, кроме того, все системы, которые доверяют данной системе, должны рассматриваться как уязвимые.
Охрана сети Linux
Исходя из всего вышесказанного становится очевидно, что разные системы должны защищаться по- разному. О защите сетей и уязвимых местах сетевой архитектуры Linux будет рассказано в следующей части книги, здесь же мы остановимся на физическом доступе к клиентским системам.
Если вы имеете дело с сетью любых размеров, скорее всего, у вас в сети существует несколько различных категорий систем. В частности, у вас наверняка есть клиентские системы, с которыми работает большая часть пользователей. В сети существует также сервер (или два), который хранит на себе пользовательские файлы и обеспечивает доступ к сетевым службам печати (как правило, домашние каталоги всех пользователей при помощи NFS монтируются в рамках клиентских файловых систем, то же самое происходит с электронной почтой и другими данными). Если сеть обладает подключением к
Интернету, скорее всего, в ней установлена система, выполняющая функции брандмауэра, а также, возможно, функции маскировки внутренних IP-адресов (IP-masquerading).
Давайте рассмотрим некоторые уязвимые места, присущие клиентам Linux, работающим в вашей сети, и их влияние на защиту серверов.
В зависимости от используемой сетевой модели на клиентах Linux могут существовать учетные записи различных видов. Как правило, на клиентских машинах размещается существенно сокращенный файл /etc/password. Однако вне зависимости от того, используете ли вы NIS, клиенты с полными запаролеными учетными записями или xdm, благодаря чему клиенты подключаются напрямую к серверу, файл /etc/shadow, размещенный на клиентских машинах, следует считать уязвимым местом. Это означает, что вы обязаны включить в него учетную запись root в самой первой позиции, однако пароль этой учетной записи на клиентских машинах должен отличаться от пароля учетной записи root на сервере, который в свою очередь должен отличаться от пароля учетной записи root на системе, выполняющей функции брандмауэра, который опять же должен отличаться от пароля учетной записи root на любой из машин, напрямую подключенных к Интернету.
При этом вы также должны убедиться в том, что клиенты доверяют серверам, но при этом серверы не доверяют клиентам. Не существует никаких причин, по которым сервер должен доверять клиентам.
Необходимо также всегда рассматривать клиентские системы как наиболее уязвимые элементы сети.

Заключение
Данная глава завершает собой дискуссию о загрузке операционной системы, которая была начата в предыдущей главе. Ознакомившись с этим материалом, вы, должно быть, поняли, насколько уязвимой является система в процессе начальной загрузки. Вы узнали о том, что любой знающий человек может использовать перезагрузку системы для того, чтобы получить доступ ко всем элементам системы, даже тем, которые доступны только для учетной записи root, в том числе и самой учетной записи root.
Данная глава затрагивает вопросы, связанные с безопасностью не только самой системы, но и безопасностью резервных копий. Как вы узнаете позднее, чем больший объем информации вы предоставляете кому-либо о системе, тем проще для этого человека получить полный доступ к этой системе.








Поделитесь с Вашими друзьями:
1   ...   8   9   10   11   12   13   14   15   ...   42


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал