Рассел Сейдж. Приемы профессиональной работы в unix перевод "Tricks of the unix masters" by Russel G
| Вид материала | Документы |
- Лекция 10. Файловые системы Unix, 116.79kb.
- Unix-подобные операционные системы, характеристики, особенности, разновидности, 40.63kb.
- Методические материалы, 3002.45kb.
- Курс для опытных администраторов unix, 67.69kb.
- Министерство Образования Российской Федерации. Юургу курсовая, 383.18kb.
- Программа курса «unix», 18.71kb.
- Лабораторная работа №1. Командный интерпретатор, 418.36kb.
- The design of the unix operating system by Maurice, 9215.6kb.
- Разработка автоматизированной системы мониторинга аппаратного и программного обеспечения, 20.06kb.
- Лекція 6 "Інформатика та комп'ютерна техніка" Тема Сервісні та прикладні програми Види, 55.04kb.
файлы.
Еще одна вещь, за которой должен следить администратор, это
"скрытые файлы". Скрытые файлы являются частью системы и имеют опре-
деленный смысл: они предназначены для того, чтобы не загромождать
распечатки каталогов. Для того чтобы скрыть файл, нужно сделать пер-
вым символом имени файла точку (.). При использовании команды ls вы
должны указать опцию -a, если вы хотите увидеть файлы, начинающиеся с
точки. Обнаружение запрещенных файлов может быть затруднено, если
файл зарыт на три-четыре уровня каталога вниз и назван незаметным
именем. Решение заключается в том, чтобы всегда применять опцию -a
команды ls, если вы сталкиваетесь с проблемами. Некоторые команды по
умолчанию печатают файлы, начинающиеся с точки. Ncheck(1M) печатает
все файлы, имеющие взведенный бит разрешения установки пользователь-
ского идентификатора. Если файл назван странным образом, его сразу же
видно. Одним из моих любимых является файл "...". Он выглядит нес-
колько странно, но это правильное имя файла. Вы даже можете завести
имя файла, образованное 14 точками - такова максимальная длина имени
файла.
КОМАНДЫ su
Последний вопрос, за которым нужно следить,- запрещенные команды
su. Su - это такое средство, которое позволяет вам ПОДСТАВИТЬ другой
пользовательский идентификатор вместо вашего собственного. Если
кто-то знает корневой пароль, он может войти в систему с любого тер-
минала и применить команду su с корневым паролем. Однако, это, веро-
ятно, тот случай, когда нарушители потратят больше всего времени, пы-
таясь чего-либо добиться. Дело в том, что все транзакции su
записываются в протокольный файл под названием sulog. Правда, к сожа-
лению, если уж нарушитель стал суперпользователем, то ему ничто не
мешает модифицировать протокольный файл с целью удаления компромети-
рующих записей. К тому же если редактор vi вызван без имени файла, то
никто не может увидеть, какой файл редактируется в то время, когда в
системе происходит вредительство.
Но бдительный системный администратор может бороться с этим при
помощи команды ps. Она печатает строку о команде su точно так же, как
она делает это для всех остальных процессов, поэтому можно сразу же
заметить, что кто-то превратился в суперпользователя командой su. На-
рушителя выдает то, что родительский процесс имеет регистрационное
имя, а владельцем su является суперпользователь. Наконец, все равно
же нужен корневой пароль. А если кто-то уже знает корневой пароль, то
зачем ему связываться с командой su? Применять su было бы резонно
только в том случае, если бы залатать команду su так, чтобы она не
записывала транзакцию в протокол и изменяла строку, которую печатает
ps. Мы еще не знаем, чтобы кто-нибудь добился такого эффекта.
СОХРАНЕНИЕ КОНФИДЕНЦИАЛЬНОСТИ ДАННЫХ
Даже если допустить, что секретность обеспечена, бывают случаи,
когда администратору нужно защитить важные файлы от любопытных глаз.
В системе UNIX это можно сделать с помощью специальных атрибутов за-
щиты файла, специальных групповых прав доступа, шифровки или даже
размещения этих данных на диске, который монтируется только в случае
необходимости. Однако, такие данные не должны оставаться физически
присутствующими в системе, если они не монтированы, потому что нару-
шитель может их смонтировать и получить к ним доступ. Командный файл
mntlook, рассмотренный ранее, умеет просматривать все устройства и
находить такие доступные, но немонтированные файловые системы.
Необходимо соблюдать такое правило: "Если вы не хотите, чтобы
кто-нибудь видел этот файл, не держите его на виду". И не думайте,
что вы так хорошо его спрятали, что никто не сможет его найти. Если
люди имеют суперпользовательский доступ в вашу систему, они могут за
считанные минуты получить распечатку каждого файла этой системы. За-
тем, когда вы не видите, они могут при помощи uucp передать интерес-
ный файл в другую систему для последующего изучения, скопировать его
на гибкий диск или даже отпечатать. Помните, что если в вашу систему
проник несанкционированный пользователь, НИКАКОЙ БЕЗОПАСНОСТИ БОЛЬШЕ
НЕТ!
КОНТРОЛЬ ЗА ИСПОЛЬЗОВАНИЕМ МОДЕМА
Модемы являются одной из крупных пробоин в защите системы. Если
только у вас нет специальной аппаратуры для предварительной фильтра-
ции обращений в систему UNIX, то она всегда уязвима посредством мо-
демных портов.
Большие вычислительные системы могут иметь произвольное число
модемов, как принимающих, так и передающих. Вам может показаться, что
поскольку команда login имеет дополнительный пароль для линий с набо-
ром номера, то все секретно, но это не так. Имеются программы, кото-
рые могут пробовать много комбинаций вероятных регистрационных имен и
паролей, и в случае подходящей комбинации команда login может впус-
тить нарушителя в систему!
Обращение вовне, в другие системы через модемы - отдельная исто-
рия. Обычно тот, кто правильно зарегистрировался в системе, хочет
обращаться к другим системам. Но что, если на вашей стороне имеются
улавливающие регистрационные имена типа class, education, test и
т.д.? Кто-то может войти в систему под видом одного из таких пользо-
вателей и использовать модем безо всякого риска быть схваченным за
руку. Единственный способ поймать таких нарушителей - по номеру тер-
минальной линии, если у вас имеются специально выделенные линии.
Что произошло бы, если бы тот, кто вошел в вашу систему через
модем при помощи одного из перечисленных регистрационных имен, обра-
тился бы потом вовне, к какой-нибудь "дальней земле"? Тогда не было
бы никакой возможности уследить за обратным вызовом определенного
пользователя.
ПРЕДОТВРАЩЕНИЕ ЗАПРЕЩЕННЫХ ПЕРЕСЫЛОК ФАЙЛОВ
Запрещенные пересылки файлов имеют отношение почти исключительно
к средствам uucp. В системе Berkeley (BSD 4.1 и старше) сетевые ко-
манды также имеют аналогичные проблемы. Вот пример: если кто-то за-
пускает в системе Berkeley командный файл для "взлома двери", то ко-
манда удаленной регистрации в системе (rlogin) регистрирует
нарушителя на другой машине в качестве суперпользователя и никогда не
спрашивает корневой пароль. Разве это не очевидная пробоина в систе-
ме? Несанкционированный пользователь может также применить удаленное
копирование (rcp), чтобы скопировать программу "взлома двери" во все
системы.
Самое главное следить за протокольными файлами. Но опять же, что
если нарушитель удаляет из протокольных файлов все записи, связанные
с заданием вопросов? У вас нет способа узнать о том, что это произош-
ло. Еще нужно следить за таким поведением нарушителей, когда они де-
лают вызов и выдают себя за корректную удаленную систему. Они могут
добиться этого, изменив узловое имя своей системы таким образом, что-
бы оно соответствовало одному их ваших разрешенных "корреспондентов".
Изощренного нарушителя очень трудно поймать, но мы предлагаем некото-
рые идеи, которые должны вам в этом помочь.
СВЕДЕНИЕ К МИНИМУМУ ВОЗМОЖНОСТЕЙ ВЗЛОМА
Это то, чем администраторы часто пренебрегают. Совет номер один
- НИКОГДА не оставлять без присмотра терминал, зарегистрированный как
суперпользовательский. Бросить без присмотра терминал с корневым дос-
тупом - все равно, что оставить тысячу ключей от сейфа компании на
вашем столе. Все несанкционированные пользователи могут воспользо-
ваться этим, подготовив командный файл "взлома двери", ожидающий та-
кого момента. Как только они получают в свои руки ваш терминал, всего
лишь одна команда предоставляет им безграничные суперпользовательские
возможности. С этого момента система перестает быть защищенной.
Системные администраторы должны проверять свои системы и смот-
реть на них с точки зрения нарушителя. Есть ли хоть когда-нибудь мо-
мент, в который система уязвима? Что может произойти среди ночи, ког-
да работают программы резервного копирования? Может ли кто-нибудь
завладеть консольным терминалом? Не сможет ли навредить тот, кто при-
ходит к вам помогать? Если вы на секундочку вышли, не сможет ли
кто-то применить команду chmod, а потом заполнить экран чем-нибудь
другим, чтобы вы не узнали, что это было сделано? Вот те опасности, о
которых вам нужно помнить.
ТИПИЧНЫЕ ПРОБЛЕМЫ БЕЗОПАСНОСТИ
Рассмотрев в общих чертах обязанности системных администраторов
и, в частности, основные вопросы системной безопасности, мы готовы
теперь к более детальному изучению того, как могут произойти наруше-
ния защиты. Каждый метод вмешательства в систему имеет свои преиму-
щества и недостатки с точки зрения нарушителя и оставляет возможность
борьбы с ним. Будучи осведомленным об этих характеристиках, админист-
ратор получает хороший шанс обнаружить пробои в защите и выявить по-
тенциальных нарушителей.
ПОТАЙНЫЕ ДВЕРИ
Мы уже отмечали, что люди, которые могут получить суперпользова-
тельский доступ в систему хотя бы на короткое время, могут написать
программы, предоставляющие им постоянный суперпользовательский дос-
туп. Напомним, что тот, кто хочет прорвать защиту системы UNIX, пер-
вым делом пытается найти способ стать суперпользователем. Как мы уже
обсуждали, нарушение физической защиты или плохо оберегаемый корневой
пароль могут дать нарушителю возможность запустить процесс как супер-
пользовательский, что предоставляет доступ к файлам (например, стан-
дартным исполняемым модулям системы UNIX), которые не может изменить
обычный пользователь. В результате нарушитель получает для себя "по-
тайную дверь".
Ключевым вопросом является способ хранения в системе UNIX указа-
ний о владельце и привилегиях, связанных с файлом. Помимо хорошо из-
вестных прав доступа для владельца, группы и прочих пользователей
(эти права устанавливаются командой chmod), имеется два более старших
бита, называемых setuid (установка пользовательского идентификатора)
и setgid (установка группового идентификатора).
Как правило, процесс, запущенный данным пользователем, имеет
только те привилегии на доступ, которые принадлежат этому пользовате-
лю. Однако, многие системные команды должны иметь доступ к таким фай-
лам, к которым мы бы не хотели разрешать доступ пользователя, за иск-
лючением очень ограниченного набора ситуаций. Ярким примером является
команда passwd, позволяющая пользователю сменить свой пароль. Очевид-
но, что этой команде необходим доступ на запись в файл /etc/passwd, а
такой доступ имеет обычно только суперпользователь.
Проблему решает исполняемый файл команды passwd, в котором бит
setuid установлен на владельца файла, а владельцем файлов, соответс-
твующих обычным системным командам, является суперпользователь (поль-
зовательский идентификатор 0). Это означает, что ВО ВРЕМЯ РАБОТЫ ПРО-
ЦЕССА, соответствующего данной команде, пользователь имеет корневые
привилегии! Когда команда завершается, прекращается и корневой доступ
... если только в данную команду не было какого-то вмешательства или
если нарушитель не установил особую программу setuid. В этих случаях
остается только войти в потайную дверь.
Потайная дверь - это чаще всего файл, владельцем которого явля-
ется суперпользователь, но который подвергнут вмешательству несанкци-
онированного пользователя, завладевшего каким-то образом правом дос-
тупа на запись в этот файл, обычно путем временного
суперпользовательского доступа. Важно понимать, что потайная дверь -
это просто еще один процесс, порожденный из обычного пользовательско-
го интерпретатора shell, но с одной существенной особенностью: у него
другой номер пользовательского идентификатора - как правило, 0, т.е.
идентификатор суперпользователя. Поскольку пользовательский идентифи-
катор хранится в самом процессе, он может быть подвергнут вмешатель-
ству.
Фактическое проникновение в систему с обретением возможностей
суперпользователя происходит тогда, когда работает "дверная" програм-
ма. Здесь используется волшебство бита setuid. Когда этот бит взве-
ден, программа устанавливает (или изменяет) пользовательский иденти-
фикатор процесса на пользовательский идентификатор владельца данного
файла (который оказывается суперпользовательским). Пока этот пользо-
вательский идентификатор временно является суперпользовательским,
программа превращается в shell-интерпретатор (обычно путем выполнения
системного вызова exec). Такой shell находится по другую сторону две-
ри, в царстве суперпользователя, со всеми принадлежащими ему привиле-
гиями.
Как мы уже отмечали, обсуждая команды su, более изощренные нару-
шители могут различными способами маскировать свое прониконвение в
систему. Один из способ маскировки - иметь "дверную" программу, кото-
рая ничего не делает, если только она не вызвана с какой-нибудь неза-
метной опцией, например -z. Скорее всего, программа потайной двери не
выдает сколько-нибудь полезного синтаксического сообщения, если ее
вызвать без правильной опции.
Еще одна хитрость заключается в том, что программа потайной две-
ри может изменить свою командную строку (которую можно отобразить при
помощи команды "ps -ef", выдающей полное состояние процесса) на какую
-нибудь безобидную, запускаемую обычно суперпользователем (например,
getty).
Опытный нарушитель вряд ли оставит исходный текст программы по-
тайной двери в системе, поэтому администратор вынужден разглядывать
только исполняемый модуль. Для реассемблирования объектного кода мож-
но применить отладчик (adb), но если только вы не имеете безумно
близкого знакомства с внутренностями системы UNIX, вам будет весьма
трудно представить себе, что происходит. Изощренные программы потай-
ной двери избегают также присутствия легко узнаваемых строк в испол-
няемых модулях. Вы можете, однако, применить команду strings (если
она есть в вашей системе) для поиска символьных строк, которые там
могли бы быть.
ПРОТОКОЛЬНЫЕ ФАЙЛЫ
Одна из простейших ловушек для того, кто пытается добыть права
суперпользователя - создавать запись, помещаемую в протокольный файл.
При этом администраторам нужно следить за протокольными файлами, не
появляются ли там записи, которые могут быть признаком злодейства.
Ниже мы покажем вам инструментальное средство, которое автоматически
следит за одним из таких протокольных файлов - файлом sulog, содержа-
щим транзакции "замененного пользователя". Другой протокольный файл,
часто нуждающийся в проверке, это протокол программы uucp, потому что
эта программа может быть использована для несанкционированных пересы-
лок файлов. Многие нарушители пытаются проверить протокольные файлы и
удалить компрометирующие записи, сгенерированные при их вмешательст-
ве. В арсенале администратора есть средства борьбы с этим. Они не на
100 процентов эффективны, но отлавливают некоторых нарушителей и, ус-
ложняя им жизнь, могут отбить охоту вторгаться в систему.
В дополнение к обычным протокольным файлам, поддерживаемым сис-
темой UNIX, некоторые администраторы заводят свои собственные прото-
кольные файлы, а затем подправляют ключевые команды так, чтобы они
помещали данные в эти новые регистрационные файлы в процессе своей
работы. Это может помочь обезвредить неосторожных лазутчиков. Один
знакомый администратор сделал протокольный файл для команды cu и наз-
вал его /tmp/.../.culog. Довольно умный тайный фокус, но в
/usr/lib/crontab у него была запись для периодической печати этого
файла. Это его выдавало: нужно было маскироваться получше. Заметим
также, что ваши "скрытые" имена протокольных файлов могут быть извле-
чены путем просмотра исполняемого образа команды с помощью утилиты
strings.
Если у вас есть пользователь, от которого вы ожидаете чего-ни-
будь запрещенного, вы должны уметь установить специальную систему ре-
гистрации, которая запускала бы более совершенный механизм, когда та-
кой пользователь работает в системе. Программу watch из главы 6 можно
модифицировать так, чтобы она вызывала специальную протоколирующую
программу, когда в систему входит пользователь из известного списка.
Протоколирующая программа могла бы повторять команды ps (process
status, состояние процесса) и/или делать "моментальные снимки" обыч-
ных регистрационных файлов (особенно учетных файлов) и направлять ре-
зультаты в припрятанный протокольный файл. Идея состоит в том, что
опасные процессы можно было бы обнаружить до того, как нарушитель по-
лучает возможность войти в протокольные файлы и изменить их. (Видимо,
вам нужно избегать применения команды at в такой программе, а перио-
дически пользоваться вместо нее командой sleep. В противном случае,
нарушитель может распознать ваши мероприятия по записи файла
crontab.) Как только вы имеете результат о сеансе работы опасного
пользователя, вы можете запустить grep для поиска интересующих вас
имен или написать инструментальное средство, которое выполняет для
вас такой поиск.
УЧЕТНЫЕ ФАЙЛЫ
Вероятно, наиболее важным среди протокольных файлов является
учетный файл. В учетном файле имеется запись о каждом и всяком про-
цессе, запускаемом в системе. Точную структуру можно посмотреть в
файле /usr/include/sys/acct.h. В одном из полей этой структуры запи-
саны процессы, имеющие суперпользовательские возможности.
Когда кто-либо входит в систему через корневую дверь, для shell-
интерпретатора, который он запускает, и для всех процессов, которые
он порождает, владельцем является корень (суперпользователь). В учет-
ном файле отражен номер терминала, с которого запущен процесс, поэто-
му вы можете увидеть корневые процессы, запущенные с таких термина-
лов, на которых пользователям не разрешен суперпользовательский
доступ.
Если у вас имеются обычные линии с набором номера, то все такие
записи могут представлять не одного и того же пользователя. Другие
входы в систему могут иметь одинаковый номер терминала, но разные
пользовательские идентификаторы. Однако, вы можете знать, кто обычно
имеет доступ к некоторым выделенным линиям.
Учетные файлы могут хорошо разоблачить процессы, имеющие не та-
кой пользовательский идентификатор, как у лица, запустившего эти про-
цессы. Поищите процессы, владельцем которых был известный пользова-
тель, но которые имеют суперпользовательские возможности. Среди них
могут быть корректные записи, например lpr, так как отображаются все
системные программы, запущенные со взведенным битом setuid. Записи,
которые мы ищем, относятся к shell-интерпретаторам с установленным
учетным флагом суперпользователя. Это выдает тот факт, что была вы-
полнена программа потайной двери. Изучите подключаемый файл acct.h,
чтобы увидеть все определения. Используя бит ASU для проверки поля,
мы можем изолировать флаговую область, отражающую привилегию супер-
пользователя. Самый лучший способ рассмотреть эту структуру - напи-
сать программу на языке Си, печатающую все элементы структуры. В сле-
дующей распечатке показаны некоторые важные учетные поля:
------------------------------------------------------------------------
|
| cmd f uid tty btime
|
| more 0 russ 0 Sat Jul 5 01:25:59 1986
| ls 0 russ 0 Sat Jul 5 01:31:12 1986
| ps 0 russ 0 Sat Jul 5 01:31:59 1986
| id 0 russ 0 Sat Jul 5 01:34:00 1986
| pwd 0 russ 0 Sat Jul 5 01:34:12 1986
| sh 1% russ 0 Sat Jul 5 01:33:51 1986
| \__ корневой shell с эффективным пользовательским идентификатором