Linux глазами хакера

□ – Е дата — дата окончания действия пароля;

□ – I N — период в днях, после которого неиспользуемая учетная запись блокируется. Рекомендую указать не менее 3 дней и не более 4 дней, чтобы приостановить действие записи на время отпуска или болезни работника;

□ – W N — количество дней до окончания срока действия пароля, когда пользователю будет выводиться предупредительное сообщение. Нежелательно указывать менее 3 дней, чтобы не попасть на выходные;

□ – l пользователь — информация о времени жизни их пароля. С этим параметром команда может вызываться любыми пользователями. Чтобы получить сведения о пароле root, выполните директиву chage -l root.

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

Minimum: -1
Maximum: 99999
Warning: -1
Inactive: -1
Last Change: Feb 04, 2004
Password Expires: Never
Password Inactive: Never
Account Expires: Never

Здесь отображаются следующие значения:

• Minimum — минимальный срок действия пароля;

• Maximum — максимальный период для пользования паролем;

• Warning — количество дней, за которые будет выдаваться предупреждение о завершении срока действия пароля;

• Inactive — максимальное количество дней, в течение которых учетная запись может не активироваться;

• Last Change — последняя дата изменения;

• Password Expires — дата окончания действия пароля;

• Password inactive — дата, когда пароль стал неактивным;

• Account Expires — дата окончания действия учетной записи.

Чтобы задать максимальное количество дней жизни пароля в 60 дней, выполните команду:

chage -М 60 robert

Слишком частая смена паролей приводит к тому, что пользователи просто не успевают запомнить их. Из-за этого сложные комбинации начинают писать на бумаге, чтобы случайно не забыть, или просто меняют пароль на старый. Ваша задача — контролировать замену, и в то же время не стоит заставлять пользователя делать это слишком часто. Период в 2–3 месяца (или 60–90 дней) считается вполне приемлемым.

А какие гарантии, что пароль выбран сложный или пользователь снова не указал старый шифр? В этом нам поможет PAM-модуль pam_cracklib.so, который выполняет основные проверки. Например, нельзя будет установить старый пароль или воспользоваться большей его частью.

Чтобы включить модуль pam_cracklib.so, необходимо добавить в файл /etc/pam.d/passwd следующую строку:

password required pam_cracklib.so retry=5 minlength=8

В этой команде мы заставляем систему использовать библиотеку pam_cracklib.so. Параметр retry задает 5 попыток для ввода нового пароля, а они понадобятся, если пользователь попытается задать слишком простую комбинацию. Параметр minlength задает минимальную длину пароля.

14.1.7. BugTraq

Честно сказать, настоящих хакеров в мире не так уж и много. Большинство взломов совершается подростками, которым нечего делать и хочется где-то применить свои силы. Знаний у них не бог весть сколько, поэтому в основном используются уже готовые решения, найденные настоящими хакерами. Это значит, что вы должны следить за новыми методами взлома и всеми появляющимися уязвимостями. Я для этого использую сайт www.securityfocus.com. Здесь регулярно обновляется информация по этим вопросам и предлагаются способы защиты.

Уже давно ходят споры о том, нужны ли сайты наподобие www.securityfocus.com. С одной стороны, они позволяют администраторам получать сведения об уязвимостях, а с другой — хакеры узнают, как можно взломать систему. Я считаю, что такие сайты должны существовать, проблема тут не в этом. Просто большинство администраторов никогда сюда не заходят, а узнают о наличии "тонких мест" в программном обеспечении только тогда, когда их сеть/сайт/сервер взломаны. Даже если вспомнить какую-либо брешь девяностых годов, можно найти в Интернете компьютер или сервер, который содержит эту уязвимость. Я бы таких администраторов увольнял без разговора.

Если вы думаете, что ежедневные проверки обновлений смогут спасти систему, то сильно ошибаетесь. После того, как найдена уязвимость, и до момента выхода обновления проходит некоторое время, и в этот период опасность проникновения на компьютер максимальная. Любой хакер, узнавший метод взлома, может начать штурм, и обязательно добьется успеха. Вы должны раньше него узнать об уязвимости и принять меры по предотвращению вторжения, пока не появится обновление.

Уязвимыми оказываются как сервисы, так и ядро ОС. Если погрешность найдена в программе, то ее нужно обновить, скачав более новую версию с сайта производителя. С ошибками в ОС дело обстоит сложнее. Тут необходимо обновление ядра, что не так уж и просто, если производить операцию из исходных кодов. Но можно облегчить себе задачу, если использовать RPM-пакет, тогда установка будет не намного сложнее, чем любой другой программы.

14.1.8. Патчинг ядра

Помимо официальных обновлений ядра существует множество заплаток, написанных сторонними разработчиками (SELinux, lcap, LIDS и т.д.). Все они предназначены для защиты системы на уровне ядра ОС. Например, можно запретить выполнение кода из стека, что сделает невозможным многие атаки, использующие его переполнение. Некоторые заплатки запрещают просмотр каталога /proc, следят за процессами в системе, защищают от сканирования портов и многое другое.

Почему я не рассматривал примеры сторонних патчей ядра более подробно раньше? Большинство из них требуют перекомпиляции ядра и работают не со всеми версиями/ядрами ОС Linux, а также требуют немалых усилий при установке. Безопасность повышается, и это факт, но стабильность может пошатнуться, потому что эти заплатки делаются сторонними разработчиками, а Red Hat просто может их не учесть.

Именно поэтому я не включал обзор этой тему в данную книгу. Но вы должны знать о существовании таких патчей, и может быть возможности какой-то заплатки вам покажутся удобными и помогут в обеспечении безопасности системы. Но любая их установка будет происходить на ваш страх и риск. Вы также должны учитывать, что обновление ядра может вызвать проблемы. К тому же, каждое новое устанавливаемое вами ядро тоже нужно будет патчить.

14.1.9. Развитие

Одна из важнейших составляющих эффективного управления — образование. В России проблема повышения квалификации стоит особо остро. Сколько администраторов самоучек? Очень много!!! Да и обучение (особенно в регионах) оставляет желать лучшего.

Многие специалисты в сфере безопасности не имеют специального образования. Я достаточно часто общаюсь с администраторами, и, глядя на компьютер, могу сказать, хороший он или нет. Если на компьютере стоят игры, то на 90% такой администратор свободное время тратит на разборки с монстрами. Если игрушек нет, и софт связан только с профессиональной деятельностью, то такой администратор хороший или может стать таким.