Михаил Фленов СанктПетербург бхвпетербург 2010 удк 681 06 ббк 32. 973. 26018. 2 Ф69
 Скачать 3.69 Mb.
|
|
4.3.6. Взлом паролей Я еще раз хочу напомнить о недопустимости использования простых паролей не только администратором, но и всеми пользователями системы. Если про- следить за уязвимостями, которые находят в Linux-системах, то очень часто можно увидеть эксплоиты, которые позволяют повысить права хакера от простого пользователя до root. Если взломщик не сможет получить доступ даже в качестве простого пользователя, то и воспользоваться эксплоитом бу- дет невозможно. Сложные пароли должны быть абсолютно у всех пользователей. Если хакер получит доступ к файлу /etc/shadow с 1000 записями, то подбор паролей упрощается . Вспомните, как хранятся пароли. Они зашифрованы необратимым Глава 4 126 образом . Это значит, что при простом переборе каждый возможный вариант тоже шифруется, а потом сравнивается с результатом из файла /etc/shadow. За счет того, что кодирование отнимает достаточно много процессорного времени , перебор становится слишком продолжительным. Подбирать сложно, если вы сравниваете полученный результат только с од- ной записью. А если в системе 1000 пользователей, то достаточно один раз зашифровать возможный вариант пароля и потом соотнести его с 1000 запи- сями в файле паролей. Вероятность попадания увеличивается в 1000 раз, и подбор упрощается. Когда хакеры получают файл /etc/shadow, то первым делом запускается про- верка всех записей, в которых имя пользователя и пароль одинаковы. Вы не поверите , но такое встречается очень часто, и если файл паролей большой, то с некоторой вероятностью можно сказать, что хакер найдет такую запись. Если это не помогло, то в ход идет перебор всех часто используемых слов. Вот тут уже вероятность попадания близка к 100%, потому что из десяти пользователей один обязательно будет новичком и установит простой па- роль . Вы должны проводить обучение каждого нового пользователя (в част- ности , по вопросу выбора пароля) и самостоятельно запускать программу сопоставления паролей с часто используемыми словами. Если вам удалось подобрать , то хакер тем более сделает это. 4.4. Типичные ошибки распределения прав Строгое распределение прав может значительно обезопасить систему. При правильной регламентации доступа большинство взломов могут оказаться неэффективными . Например, однажды в Интернете появилось сообщение, что один из сервисов ОС Linux содержит ошибку. Благодаря хорошему рас- пределению прав мой сервер оказался защищенным от проникновения через эту дыру. Злоумышленник мог пробраться на сервер, но ничего изменить или удалить было нельзя, потому что внешним пользователям этого сервиса все файлы были открыты только для чтения. Итак , если у вас хорошо настроены права доступа, то это может оказаться непреодолимой преградой для злоумышленника, даже в случае наличия уяз- вимости . Но нужно также иметь в виду, что не от всех уязвимостей можно защититься правами доступа, поэтому не забывайте следить за новостями и вовремя латать систему. Мой начальник в банальном файле Excel вел на сервере план работ, в кото- ром указывалось, что, кто и когда должен сделать. Этот файл был доступен для чтения всем, но его нельзя было изменять. Права на изменения есть только Управление доступом 127 на директорию, но не на нужный файл. Как изменить информацию в файле? Остановитесь и подумайте. Буквально через абзац я расскажу, как решить эту проблему Давайте рассмотрим классический пример с файлами и каталогами. До- пустим , что у вас на каталог поставлены максимальные права drwxrwxrwx (или 777), а на все файлы в нем — -rw------- . По идее, только владелец файла может его модифицировать, но это не совсем так. Да, злоумышленник не сможет изменить сам файл, но список файлов в директории ему доступен (разрешены чтение и корректировка). Благодаря этому взломщик просто удалит нужный файл и создаст другой с новыми правами без каких-либо преград Теперь ясно, как можно изменить файл, недоступный для записи? Можно прочитать файл и сохранить его содержимое в другом файле, например, вы- полнить команду cat имязапрещенногофайла >> имянашегофайла Эта команда скопирует содержимое файла в новый. Если файл не существо- вал , то он будет создан из-под вашей учетной записи. Значит, вы будете его владельцем и сможете делать все, что угодно. Теперь можно удалить файл, созданный начальником, и заменить его своей копией. Так как вы — владе- лец , вы можете изменить этот файл, подправив нужную информацию, а по- том просто изменить владельца и дату изменения, чтобы никто ничего не за- подозрил Хитро ? Ничего хитрого, но почему-то мало кто обращает на такую мелочь внимание , хотя это не мелочь, а дыра в безопасности. Бессмысленно запре- щать изменение файла, если у меня полные права на директорию. Попробуй- те выполнить следующие команды: su root ls -al >> /home/flenov/1.txt ls -al /home/flenov/1.txt su flenov rm /home/flenov/1.txt В первой строке переключаемся под пользователя root, чтобы от его имени выполнять команды. Вторая команда отображает файлы из текущей директо- рии , а результат сохраняет в файл /home/flenov/1.txt. Директория выбрана не случайно , это домашний каталог пользователя flenov, в котором он может делать все, что угодно. Следующая строка выполняет команду ls -al к только что созданному фай- лу , чтобы просмотреть подробную информацию о нем. Убедитесь, что вла- делец root и права доступа равны -rwxr--r-- . Если это не так, то запретите Глава 4 128 изменения файла для группы и для всех. В принципе, достаточно запретить изменение для всех, потому что flenov в группу root не входит, а значит, не сможет изменять файл. Теперь переключаемся на пользователя flenov и удаляем файл. Прикол в том, что файл удалится. Единственное, что вы увидите — предупреждение, что удаляется файл, защищенный от изменений. Чтобы этого не произошло, вы должны ограничивать доступ не только к файлам, но и каталогам. Бывают случаи, когда директория должна иметь все права. Это открытые папки , через которые пользователи могут обмениваться файлами. Но при этом нужно защититься таким образом, чтобы только администратор или владелец файла могли его удалять. Все остальные пользователи не должны иметь прав на уничтожение уже существующих чужих файлов. Как же ре- шить эту проблему, когда директорию необходимо сделать доступной всем, а ее содержимым должны управлять только хозяева? Допустим , что у вас есть каталог shared. Для того чтобы в нем могли удалять файлы только владельцы, нужно установить для него sticky-бит. Это делается командой chmod с параметром +t : chmod +t shared Попробуйте выполнить команду ls -al и посмотреть права доступа к ката- логу . Вы должны увидеть drwxrwxrwt . Обратите внимание, что на месте сим- вола x для всех пользователей стоит t . Это и указывает на установленный sticky-бит. Теперь попробуйте удалить из этой директории файл, принадле- жащий другому пользователю. Вы увидите сообщение "rm: cannot unlink ‘имя файла ’: Operation not permitted". Используйте этот бит на всех открытых папках. Некоторые хакеры, получив доступ к открытому диску и не обретя доступа к закрытой информации, на- чинают уничтожать все, что видят. С помощью sticky-бита взломщик сможет удалить только то, что создал сам, и ничего лишнего. В Linux есть каталог /tmp, для которого как раз установлены права drwxrwxrwx , и в нем сохраняются временные данные всех пользователей. В современных дистрибутивах на этот каталог уже выставлен sticky-бит. Проверьте, если в вашей системе это не так, то установите его самостоятельно, чтобы никто не смог удалить чужие временные файлы. 4.5. Привилегированные программы В главе 3 я уже намекал о существовании еще двух битов доступа — SUID и SGID, и теперь пора с ними познакомиться поближе. Допустим, что пользо- вателя необходимо ограничить в правах, чтобы он не натворил бед, но при Управление доступом 129 этом дать возможность запускать программу, к которой требуется специальный доступ . В этом случае можно установить SUID-бит, тогда и программа сможет работать (от имени владельца), и у пользователя не будет лишних привилегий. Бит SUID можно установить командой chmod с параметром u+s : chmod u+s progname Если теперь просмотреть права доступа к файлу progname, то они окажутся равными -rwsr-xr-x . Как видите, появилась буква s на том месте, где долж- но быть разрешение на запуск (символ x ) для владельца файла. Бит SGID похож на SUID, но он позволяет запускать программу с правами группы владельца файла. Этот бит устанавливается подобным образом командой chmod с параметром g+s : chmod g+s progname В этом случае права доступа к файлу будут -rwxr-sr-x . Во второй группе вместо символа x (право на запуск для группы владельца файла) появилась буква s Привилегии SUID и GUID достаточно удобны и полезны, но, с другой сторо- ны , они таят в себе очень много проблем. Например, гость, обладающий ми- нимальными правами, запускает программу с установленным битом SUID, владельцем которой является пользователь root. Это значит, что программа будет работать с правами root, а не гостевыми параметрами пользователя. Если в ней окажется ошибка, через которую можно выполнять команды на сервере , то эти директивы будут реализовываться от имени владельца про- граммы , то есть root. Таким образом, даже если взломщик сам не имеет воз- можности претворять в жизнь команды, то через привилегированную про- грамму сможет получить доступ к запрещенной области. Биты SUID и GUID нужно использовать аккуратно, и в любом случае владельцем программ не должен быть root или другой привилегированный пользователь. Луч- ше , если это будет специально заведенная для этой программы учетная запись, ко- торая обладает только теми правами, которые необходимы пользователю. Рассмотрим еще один пример. Допустим, гость не должен иметь прямого доступа к каталогу /home/someone, а для работы программы он необходим. Чтобы не открывать ему лишних возможностей, нужно завести отдельного пользователя с правами доступа на каталог /home/someone, сделать его вла- дельцем программы и установить бит SUID. Если в программе будет найдена ошибка , то взломщик получит доступ к /home/someone, но все остальные раз- делы диска останутся недоступными. Такая политика соответствует нашему основному правилу "Что не разреше- но , то запрещено" и обеспечит максимальную безопасность сервера. Глава 4 130 4.6. Дополнительные возможности защиты Помимо прав доступа у любого файла есть еще и атрибуты, которые позволяют построить дополнительную стену безопасности на пути взломщика. Единст- венное условие — атрибуты могут использоваться только на файловых систе- мах Ext2 и Ext3. Но ограничением это можно назвать с большой натяжкой, по- тому что Ext3 уже давно становится стандартом для всех дистрибутивов. Просмотреть текущие атрибуты можно с помощью команды lsattr : lsattr filename.txt -------------- filename.txt Первая строка демонстрирует использование команды, а во второй — ото- бражается результат ее работы. Как видите, мы получили набор символов тире вместо атрибутов, а значит, ни один из них не определен. Для установки атрибута применяется команда chattr : chattr атрибуты файл Если требуется рекурсивное изменение доступа к каталогу и всем содержа- щимся в нем файлам и подкаталогам, можно использовать ключ -R . В этом случае вместо имени файла укажите директорию. Вот перечень основных атрибутов, применяемых в команде chattr : A — не создавать метку atime записи времени последнего обращения к файлу. С точки зрения безопасности этот атрибут несет отрицательный эффект , потому что по дате обращения можно контролировать, когда файл был модифицирован. Поэтому не рекомендую устанавливать этот флаг. Но если у вас под ОС Linux работает личный компьютер, и нет необходи- мости отслеживать историю изменений, то можно установить этот атрибут и тем самым уменьшить количество обращений к диску (отменить лиш- нюю операцию записи при сохранении файла); a — позволяет открывать файл только в режиме добавления. Это значит, что уже существующие данные изменить или удалить нельзя; d — заставляет игнорировать файл при копировании. Этот флаг позволяет уменьшить размер резервной копии, но устанавливать его нужно только на файлы, не имеющие ценности и важности, например, временные; i — запрещает выполнение с файлом каких-либо действий по корректи- ровке (изменение, удаление, переименование, создание ссылок); s — делает невозможным восстановление файла после удаления. При уда- лении все пространство на диске, где был файл, будет заполнено нулями; S — во время изменения файла все действия будут фиксироваться на же- стком диске. Управление доступом 131 Для установки атрибута перед ним нужно поставить знак плюс, для снятия — знак минус. Рассмотрим несколько примеров: chattr +i test chattr +s test lsattr test s--i---------- test В первой строке мы добавляем атрибут i , а значит, запрещаем какие-либо изменения файла. Во второй строке устанавливаем флаг s , и теперь при уда- лении файла можно быть уверенным, что он уничтожен полностью. Команда в третьей строке запрашивает текущие атрибуты, и в последней строке вы можете увидеть, что в перечне атрибутов первый символ равен s , а четвер- тый — i Итак , у нашего файла два взаимоисключающих атрибута. Один запрещает изменения , другой требует полного стирания с диска. Что произойдет, если мы попытаемся удалить файл. Посмотрим? rm test rm: remove write-protected file “test”? В первой строке мы выполняем команду удаления файла. На это ОС просит подтвердить операцию над защищенным от записи файлом (сообщение пока- зано во второй строке). Как видите, ОС определила наш атрибут i . Попро- буйте ввести букву Y, чтобы подтвердить действие. Вы увидите сообщение об ошибке, и файл останется на месте. Давайте снимем атрибут i : chattr -i test lsattr test s------------- test После отмены атрибута я выполнил команду lsattr , чтобы убедиться в правильности выполнения команды. Вот теперь файл легко удалить с по- мощью команды rm 4.7. Защита служб В этой книге будет рассматриваться множество серверных служб. Безопас- ность их работы для системы в целом зависит не только от правильной на- стройки самой службы, но и от прав, которые вы ей дадите. Хакеры очень часто атакуют определенные сервисы и ищут в них изъяны, через которые можно было бы проникнуть в систему, а, как мы знаем, ошибки есть всегда и везде. Глава 4 132 Во время написания первого издания этой книги на мой сайт было произве- дено несколько удачных атак, потому что из-за занятости я просто не обнов- лял свой сайт, который располагался на сервере известной хостинговой ком- пании . За два дня на сайте дважды меняли главную страницу, а потом злоумышленники захватили форум. Мне пришлось его убирать в недоступ- ное место, чтобы восстановить свои права администратора, напрямую редак- тируя базу данных MySQL. Как произошел взлом? На сайте стоял форум phpBB. Это один из популяр- ных движков, который абсолютно бесплатен, поэтому его выбирают многие владельцы сайтов. Многие хакеры стремятся найти ошибки в наиболее из- вестных разработках, и иногда им это удается. Только своевременное обнов- ление форума (в данном случае) позволяет защититься от нападения. После атаки я обновил форум, но это не помогло. Разработчики не устранили в последней версии одну критическую ошибку, а лишь дали инструкции по исправлению на форуме своего сайта. Конечно же, я не увидел этих предпи- саний и в итоге мог потерять всю базу данных, если бы один из посетителей сайта не дал мне ссылку на описание ошибки и способов ее устранения. Давайте на примере абстрактного сайта www.sitename.com посмотрим, как происходило вторжение. На форуме можно войти в просмотр какой-нибудь темы , и в строке адреса появится ссылка http://www.sitename.com/forum/viewtopic.php?p=5583 Если к этой ссылке добавить в конец следующий текст &highlight=%2527.$poster=%60команда Linux%60.%2527 то указанная команда Linux выполнится на сервере. Вот так, например, можно было просмотреть файлы каталога /etc на сервере: &highlight=%2527.$poster=%60ls%09/etc%09-la%60.%2527 А вот эта команда могла удалить главную страницу сайта: &highlight=%2527.$poster=%60rm%09index.php%60.%2527 Как видите, благодаря ошибке в одной строке скрипта форума под угрозой оказалось существование всего сервера. А ведь опасность можно уменьшить, ограничив права WEB-сервера в ОС. Для этого администраторы должны создать виртуальную среду для выполне- ния WEB-сервиса, сделав при этом все остальные разделы сервера недоступ- ными для злоумышленника. В этом случае и каталог /etc окажется недося- гаемым , и максимальный вред, который сможет нанести злоумышленник, — уничтожить сайт и нарушить работу WEB-сервиса, но все остальные будут трудиться в штатном режиме. Восстановить один сервис проще, чем налажи- вать абсолютно все. Управление доступом 133 После этого случая я целый день бродил по Интернету в поисках уязвимых форумов , и таких оказалось много, потому что администраторы сайтов явно не следят за обновлениями. Я думаю, что в скором времени эти администра- торы прошли через все круги ада. Рано или поздно взломщик найдет их фо- румы , и в этом случае нужно молиться, чтобы он не уничтожил всю базу, а только пошалил. Хочется еще раз напомнить о необходимости обновления всех программ, сервисов и самой ОС. Если вы сможете исправить ошибку раньше , чем хакер ее найдет, то обезопасите свою жизнь. Во время поисков уязвимых форумов я просматривал возможность получе- ния доступа к каталогу /etc, чтобы увидеть не только количество неопытных владельцев сайтов, но и некомпетентных администраторов. Вы не поверите, но доступ открыт, наверное, на 90% серверов. Это безграмотность админист- раторов или их лень? Не знаю, так что точно сказать не могу. Только круп- ные серверы были защищены, а мелкие хостинговые компании явно эконо- мят на заработной плате, не нанимая хороших администраторов. |