Михаил Флёнов - Linux глазами хакера

• Название: Linux глазами хакера
• Автор: Михаил Флёнов
• Жанр: Программное обеспечение
• Год: 2005
• ISBN: 5-94157-635-8

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

Для пользователей, администраторов и специалистов по безопасности

---

man имя

Имя — это название команды или программы, a man выводит на экран информацию об объекте. Например, чтобы увидеть описание команды shutdown, выполните man shutdown.

Для выхода из программы помощи нужно набрать на клавиатуре <-е>. В ответ на это перед вами появится сообщение "Quit at end-of-file (press RETURN)". Нажмите клавишу <Enter>, затем перейдите в конец просматриваемого файла помощи, и программа man завершит работу.

Более простой способ завершения программы man — нажать клавишу <q>. В этом случае выход произойдет мгновенно.

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

2.10. Основы конфигурирования

Прежде чем переходить к более глубокому рассмотрению вопросов, связанных с конфигурированием ОС Linux, мы должны определиться с правилами, которые действуют вне зависимости от ОС и сервиса. Если вы будете их придерживаться, то сможете построить действительно защищенную систему (сервер или даже сеть из компьютеров и серверов).

2.10.1. Запрещено то, что не разрешено

Когда вы настраиваете параметры доступа, то необходимо придерживаться принципа минимализма, который заключается в следующем:

1. Необходимо запускать минимум возможного. Это касается не только сервисов в целом, но и их составляющих. Например, вам нужен Web-сервер и для этого чаще всего устанавливается Apache. Эта программа включает в себя очень много возможностей, среди которых поддержка интерпретируемых языков PHP и Perl, но, как правило, программисты сайтов используют только один из этих языков, поэтому нет смысла разрешать оба. Если сайт проектируется с помощью PHP, то следует удалить Perl, и наоборот. Ну а если ваш сайт использует сразу два языка сценариев, увольте своих программистов, потому что в разнородных системах намного сложнее построить безопасность.

2. Следует разрешать минимум необходимого. Большинство администраторов не любят заниматься какими-либо настройками, поэтому открывают полный доступ на все, что только может пригодиться. Но слово "может" не совместимо с безопасностью. Возможность, которую вы откроете пользователю, на самом деле может ему не понадобиться, а вот злоумышленник благодаря лишней лазейке может натворить много бед. Например, на клиентских компьютерах может быть открыта какая-то папка для всеобщего доступа. Это мотивируется тем, что пользователям может потребоваться обмен данными. А если нет?

При рассмотрении конфигурирования ОС и ее сервисов я буду часто напоминать об этом правиле, и при разборе примеров будем отталкиваться именно от полного запрета.

2.10.2. Настройки по умолчанию

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

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

Когда пишете имя параметра или путь в файловой системе, будьте внимательны не только к словам, но и к их написанию. ОС Linux чувствительна к регистру имен файлов и директорий. Эта особенность имеет значение и для некоторых конфигурационных файлов.

2.10.3. Пароли по умолчанию

Многие сервисы во время установки прописывают пароли по умолчанию. В ОС Linux эта проблема стоит особо остро, потому что программы инсталляции используют RPM-пакеты и чаще всего даже не предлагают их сменить. Я бы на месте разработчиков вообще запретил запуск сервисов с пустым или неизмененным паролем.

Например, база данных MySQL после установки использует для администратора учетную запись без пароля и с именем root, которое может ввести в заблуждение, но вы должны знать, что этот логин никакого отношения к системной записи не имеет. Это внутренняя учетная запись базы данных, и пароли могут и должны быть разными. Сразу после установки MySQL необходимо сменить код доступа.

Прежде чем сдавать систему в эксплуатацию, убедитесь, что изменены все пароли. Снова пример с MySQL. Администраторы редко используют его, а только устанавливают. Конфигурированием обычно занимаются программисты, которые настраивают базы под себя и почему-то любят использовать пароли по умолчанию. Я сам программист и при разработке баз данных тоже так делаю в надежде, что за паролями проследит администратор, а тот надеется на меня, и получается, что мы оба забываем.

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

Пароли по умолчанию используются не только в программах и ОС, но и в сетевых устройствах, таких как маршрутизаторы и управляемые коммутаторы. В эти устройства встроена система защиты и авторизации. Производители, не долго думая, чаще всего устанавливают имя Admin, а пароль оставляют пустым. Это большое упущение. Я бы на их месте для пароля по умолчанию использовал серийный номер устройства. В этом случае хакер не сможет его подобрать. Хотя и серийный номер не является абсолютной защитой, потому что если хакер увидит устройство своими глазами, то он легко сможет вычислить и пароль.

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

2.10.4. Универсальные пароли

Производители BIOS раньше устанавливали в свои чипы универсальные коды доступа, которые позволяли войти в систему, не зная основной пароль, который установил администратор. Например, в одной из версий BIOS компании AWARD использовался универсальный шифр AWARD_SW. Начиная с версии 4.51, такая "услуга" отсутствует.

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

2.10.5. Безопасность против производительности

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

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

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

Глава 3 Добро пожаловать в Linux

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