Linux Security FAQ

Материал из MediaWiki
Перейти к навигации Перейти к поиску

Является отдельным документом и поддерживается Владимиром Ивановым AKA ivlad, с разрешения которого перенесен сюда.

Общие рекомендации по защите

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

Учтите, что данный FAQ предполагает наличие у читающего некоторого объема знаний о администрировании UNIX.

Что посоветуете для общего обеспечения безопасности?

Прочитать данный FAQ и применить его к себе, а так же:

  • Обеспечить физическую безопасность системы. Никакие брэндмауэры, антивирусы, настройка прав на файловой системе не помогут, если взломщик может вынуть жесткий диск из сервера и унести домой. Даже если вы будете шифровать данные на жестком диске, зачем облегчать ему задачу? А если он просто развинтит винчестер? Держите ваши серверы под замком!
  • Поставить все обновления безопасности от вендоров вашего дистрибутива.
  • Отключить все ненужные сервисы. Проверьте как сервисы, запускаемые из (x)inetd так и standalone, запускаемые из стартовых скриптов. man inetd.conf, man xinetd
  • Настроить syslogd для копирования важных сообщений на другую машину. Прочитайте man syslog.conf на предмет опции @hostname. Хранение копии файлов журналов на отдельной системе (доступ к которой, конечно, должен быть максимально ограничен) позволит иметь журнал, который не был изменен вломщиком, заметавшим следы, если взлом все-таки произошел. С другой стороны, syslogd обычно использует UDP для доставки сообщений, что не позволяет гарантировать, полноту журнала на протоколирующей системе. Кроме того, это открывает широкие возможности для спуфинга сообщений и DoS с целью переполнения файловой системы, где хранятся файлы журналов. Таким образом, может оказаться необходимым рассмотреть модифицированные версии syslogd (например, syslog-ng), позволяющие использовать протокол tcp для доставки сообщений и позволяющие выполнять их электронную подпись. Это особенно важно, если сообщения доставляются через глобальные сети.
  • Отказаться от использования протоколов с слабой авторизацией. В первую очередь это относится к так называемым r-командам: rlogin, rsh, rcp - соответствующие сервисы следует отключить или заменить на аналоги с более стойкой аутентификацией (Kerberized или ssh). Если r-команды вам таки необходимы (например, для работы с cisco, которая ssh не понимает), используйте TCP Wrappers (man tcpd). Кроме того, не стоит применять без необходимости telnet, POP3, отключите так же plain-text аутентификацию в IMAP, либо туннелируйте эти протоколы в SSL.
  • Производить проверку изменений файлов. Для дистрибутивов, основанных на RPM, частично помогает rpm -Va, однако лучше использовать специализированные программные пакеты, такие как Tripwire или Aide. Применение такого ПО позволит своевременно обнаружить изменения в конфигурационных файлах или установку "троянских коней".
  • Произвести тотальный chroot для всех возможных сервисов. В первую очередь, это касается Apache (описание тут) и BIND (описание тут), если вы пользуетесь ими. Однако, я рекомендую вам помещать в chroot все ваши сервисы предоставляемые пользователям через Internet.
  • Приложить OpenWall patch. Документация и патчи под стандартное ядро ищите на [1], обратите внимание, что производитель вашего дистрибутива, возможно, уже включил этот патч в свое ядро. Так же очень интересными возможностями обладает GrSecurity (см. так же ответ на вопрос 2.5).

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

Какой/какая дистрибутив/OS лучше в плане защищенности?

Обязательно ли ставить Slackware на сервер? Правда ли, что RedHat Linux такой «дырявый?»

Дистрибутив обязан быть поддерживаемым: его обновления безопасности должны выходить быстро и оперативно, а так же не изменять функции пакетов. Желательна поддержка дистрибутива в течении длительного времени. Примерами таких дистрибутивов являются RHEL (он же CentOS), Suse Linux Enterprise Server (не openSUSE), Debian Stable, Ubuntu LTS.

Разница между особенностями дистрибутивов, относящимися к безопасности, обычно сильно перевешивается (не)знанием администратора. Таким образом, знающий системный администратор способен на основе дистрибутива общего назначения (каковыми являются и Slackware и Fedora и Debian и многие другие) построить систему, имеющую приемлемый уровень безопасности для Internet-хоста. Однако, особо надо отметить «специализированные» дистрибутивы. Они часто собраны на основе «нестандартного» ядра и реализуют какую-либо формальную модель безопасности. Примером такого дистрибутива может служить Adamantix, собранный на основе проектов Linux RSBAC и PaX. Такой дистрибутив может служить фундаментом для построения высоко защищенной системы, однако требует некоторого дополнительного времени для настройки. Отметим так же существование ОС МСВС, основанной на дистрибутиве Mandrake Linux и включающей в себя RSBAC.

Ряд дистрибутивов, точнее, аппаратно-программных комплексов, включающих в себя Linux был сертифицирован по Common Criteria (ISO15408). Сюда, в частности, относятся некоторые системы IBM и HP под управлением дистрибутивов RedHat и SUSE.

/* FIXME: TODO - SELinux,Trustix, LIDS, Openwall GNU/*/Linux */

Взломали! Что делать?

Во-первых, Don't panic! :) Не вы первый, не вы последний. Во-вторых, постарайтесь определить для себя, какие действия вы должны предпринять. В-третьих, записывайте все, что вы сделали - это поможет на досуге сесть, разобраться и сделать выводы. Теперь подробней.

Идентифицируйте проблему:

  • Насколько опасен взлом? Критична ли информация, которая могла подвернуться утечке? Сколько систем взломано? Может ли быть так, что о некоторых взломах вы не подозреваете? Стоит ли немедленно выдернуть кабель из сетевого интерфейса или можно позволить себе понаблюдать за действиями взломщика? Кого нужно оповестить о взломе? Стоит ли привлекать правоохранительные органы?
  • Традиционно, для сохранения контроля над взломанной системой, взломщики устанавливают т.н. rootkit - набор программ (и иногда - модулей ядра), которые скрывают факт взлома от системного администратора, обеспечивают доступ к системе, или позволяют расширить привилегии атакующего. Если у вас возникло подозрение, что в системе установлен rootkit, попробуйте проверить ОС с помощью chkrootkit или rkhunter. Так же проверьте целостность файлов с помощью Tripwire/Aide (см. так же п. 1.1).

Приступайте к решению проблемы:

  • Не забудьте записывать все происходящее. Если вы решили понаблюдать за взломщиком, отдавайте себе отчет, что он может это обнаружить и постараться уничтожить все следы. Убедитесь, что он не использует ваши сервера как трамплин для новых атак. Будет очень неприятно оказаться вовлечённым в DDoS или обнаружить у себя склад эксплоитов или вареза (хотя, кому как, конечно :) ). Повторю прописную истину, что если вы следите за взломщиком командой, не надо пользоваться скомпрометированными ящиками электронной почты для координации своих действий.
  • Команда CERT Coordination Center выпустила документ Steps for Recovering from a UNIX or NT System Compromise, описывающий основные шаги по восстановлению системы.
  • Если у вас нет желания и сил проводить расследование, переустановите OS с дистрибутива, восстановите данные из резервных копий (у вас ведь есть резервные копии? :) ) и перечитайте данный FAQ для повышения ее защищенности.

Сделайте выводы:

  • После того как работоспособность восстановлена, займитесь «разбором полетов». Как этот взломщик пролез? Как сделать так, что бы подобного больше не случалось? Попытки взломов могут повториться, к этому нужно быть готовым. Тут вам понадобятся сделанные ранее записи.

Дополнительная информация:

Сборка из исходных текстов

Много раз в форуме читал что все серверные приложения обязательно компилируют из исходников.Объясните новичку почему и какие изменения вносите при компиляции?

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

Чем опасна работа под root?

В первую очередь - собственными ошибками. Во-вторых, намного возрастает опасность всевозможных «троянских коней» и т.п. Случайно запустив троянскую программу без привилегий root, вы в худшем случае потеряете свои файлы. Запуск из-под root может обернуться настоящей катастрофой.

Более подробно можно почитать в LOR FAQ

Незнакомые сервисы.

Много раз читал про такой подход к администрированию безопасности - «если не знаешь, что это - отключи», но так же читал про «если не знаешь, что это - не трогай». Какой подход правильнее и надежнее?

Оба подхода фундаментально неверны. Наш подход - «если не знаешь, что это - узнай, потом реши». ;)

Какой алгоритм шифрования лучше всего?

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

Вообще говоря, криптография — отдельная, большая и сложная тема, выходящая за рамки этого FAQ, поэтому здесь мы дадим только практические рекомендации. За дополнительной информацией обратитесь к литературе, упомянутой в разделе «Что читать».

Для прикладного применения в настоящее и ближайшее время подходит алгоритм симметричного шифрования AES с длиной ключа не менее 256 бит, алгоритм хеширования SHA256 и алгоритмы ассиметричного шифрования RSA или El-Gamal с длиной ключа не менее 1024 бит.

Локальная безопасность

Не могу удалить файл от root!

Например, /bin/login, /etc/passwd и др. Скопировать получается, удалить скопированный файл получается. Удалить исходный - нет.

Проблема обычно состоит в том, что на файл установлен бит immutable. Файловая система ext2 поддерживает дополнительные биты, управляющие некоторыми атрибутами файлов. В частности, бит immutable не позволяет изменить, переименовать или удалить файл. Руководствами по безопасности рекомендуется устанавливать такой бит на файлы типа /bin/login и /bin/passwd. Атрибут append-only позволяет открывать файл на запись только для дополнения. Такой бит может быть установлен на файлы системных журналов. (ВНИМАНИЕ! При этом может нарушиться нормальная работа logrotate). Подробнее - man chattr.

Попробовал снять immutable bit с помощью chattr - не получилось. В чем может быть дело?

Linux (хотя в принципе это закреплено и в Posix) поддерживает так называемые kernel capabilities - флаги ядра, ограничивающие возможности системы в целом. К ним, например, относятся CAP_CHOWN (возможность пользователям применять chown) или CAP_KILL (возможность посылать сигналы процессам, владельцем которых является другой пользователь).

Среди них есть CAP_LINUX_IMMUTABLE - этот флаг ядра (специфичный для Linux) управляет возможностью снятия аттрибутов immutable и append-only с файлов. В принципе для управления capabilities можно использовать команду echo и интерфейс /proc/sys/kernel/cap-bound, однако, проще установить утилиту lcap, там же есть ссылки на дополнительную информацию).

Подробнее - /usr/src/linux/include/linux/capability.h и домашняя страница lcap, Linux Capabilities FAQ.

Как ограничить ресурсы пользователю? Диск, память, процессорное время?

Собственно ограничение дискового пространства пользователя выполняется посредством механизма квот. Подробнее - Quota mini-HOWTO. Память, процессорное время и многое другое управляется посредством Pluggable Authentification Modules - PAM. В данном случае - pam_limits. Конфигурационный файл (/etc/[pam|security]/limits.conf) в принципе самодостаточен, так же рекомендуем ознакомиться с документацией к PAM.

ВНИМАНИЕ! pam_limits - это PAM модуль, что означает, что он обычно имеет эффект только при регистрации пользователя одним из способов, позволяющим применить PAM, например через ssh или при вызове /bin/login. Таким образом, это не имеет эффекта на Apache, запускающийся с параметром «User» в httpd.conf или MySQL.

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

Как дать пользователю права root, но только частично?

Например, как разрешить любой mount, а не только те, что в fstab?

Наша рекомендация - пользуйтесь sudo! Помимо раздачи прав пользователям ведет учет применения этих самых прав, обладает гибкой системой конфигурирования в том числе и в масштабе локальной сети (впрочем, механизм этот далек от идеала IMHO - LDAP был бы куда как лучше; для этого есть патчи, искать в списках рассылки sudo - прим. ivlad).

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

Наконец, вы можете применить RSBAC (см. выше), но это требует куда больших затрат на администрирование.

На крайний случай (на самый крайний!) - воспользуйтесь механизмом SUID на конкретных программах.

Подробнее - [4], man chmod.

Как не дать пользователю запускать свои программы?

У меня пользователь собрал/скачал эксплоит/игру/еще-какую-гадость. Теперь запустил и ломает/играет/еще-какой-гадостью-занимается. Как победить ситуацию в принципе?

Традиционно, в Unix существует ровно два места, куда пользователь может записать свои файлы - домашний каталог пользователя и /tmp. Что бы пользователь не смог запустить в системе лишние программы, собрав их самостоятельно из исходников, следует поступить так:

  • от каталога /tmp можно избавиться - создайте у каждого пользователя в домашнем каталоге собственный TMP и пропишите на $HOME/tmp соответствующие переменные окружения (обычно это $TMPDIR). После этого права 1777 с /tmp можно снять. Поставьте, скажем, 0755, 0711 или что-то подобное в соответствии с ситуацией.
  • смонтируйте файловую систему с домашними каталогами пользователей с параметром noexec, после чего они не смогут создать исполняемые файлы в домашних каталогах. /tmp можно так же смонтировать с noexec - если вам это нужно.
  • Рекомендуем сделать тоже самое для сменных носителей - floppy, CDROM, zip...

Подробнее - man mount.

Примечание от Piter Kravtchenko (lbast@mail.ru): такой фокус не проходит, если вы устанавливаете софт, работающий с flexlm, поскольку он плюет на $TMPDIR, и желает писать именно в /tmp.

Примечание от Sergey (srg@csu.ac.ru): Насчет монтирования $HOME с noexec, ничто на мешает юзеру сделать скопировать в систему что-нить и сделать /lib/ld-2.3.1.so ./nmap hostname. Лекарство - патч к ядру с [5], на уровне ядра .. если файл лежит в каталоге, не принадлежащем руту выполнение запрещено.

А как сгенерировать стойкий пароль подручными средствами?

cat /dev/[u]random | uuencode -m - | head -n 2 | tail - -c длина пароля

Как прозрачно шифровать данные на диске? Есть ли аналоги BestCrypt под Linux?

Ядро Linux имеет встроенную возможность работы с зашифрованными устройствами хранения данных. Ядро 2.6.4 и старше позволяет организовать прозрачное шифрование данных на диске двумя способами: с помощью Cryptoloop или dm-crypt, остальные ядра - только Cryptoloop. Для начала подробнее о каждом.

Cryptoloop - это механизм, суть работы которого заключается в создании файловой системы внутри защищённого файла на диске, доступ к которой осуществляется посредством петлевого блочного устройства, или loopback-устройства (/dev/loop*, не путать с петлевым интерфейсом lo). Такое устройство монтируется как обычное блочное устройство, после чего шифрование и дешифрование осуществляется "на лету". Существует две реализации Cryptoloop - для ядер 2.4 и 2.6, причём эти реализации несовместимы друг с другом. Способ имеет следующие недостатки:

  • требует наложения патчей на пакет util-linux, а в случае с ядром 2.4 - ещё и на само ядро;
  • нельзя работать с носителем напрямую, только через петлевое устройство;
  • небезопасно использовать с журналируемыми ФС;
  • активная разработка Cryptoloop приостановлена в пользу dm-crypt.

С появлением в 2.6-х ядрах низкоуровневого драйвера логических томов - Device mapper - стала возможной работа не только с петлевыми устройствами, но и непосредственно с дисковыми разделами. Более того, благодаря модульной структуре Device mapper, ничто не мешает, комбинируя различные цели, организовать шифрование данных на RAID-массиве или создать зашифрованный своп. Цель для Device mapper, отвечающая за шифрование данных, называется dm-crypt. От всех недостатков предыдущего способа dm-crypt избавлен, но доступен он только для ядер старше 2.6.4 (если не заморачиваться с патчами).

И Cryptoloop, и dm-crypt для собственно шифрования используют шифры, являющиеся частью так называемого Cryptographic API (aka CryptoAPI), интегрированного в ядро. CryptoAPI применяется не только для шифрования данных на диске, но и, например, для организации защищённого туннеля по протоколу IPsec.

Здесь будет описано создание и использование зашифрованной файловой системы с помощью dm-crypt. Потребуются следующие программные пакеты:

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

	Device Drivers --->
		Multi-device support (RAID and LVM) --->
			 Device mapper support
			 Crypt target support
		Block devices --->
			 Loopback device support
	Cryptographic options --->
		 SHA384 and SHA512 digest algorithms
		 AES cipher algorithms (i586)

Алгоритмы хэширования и шифрования выбирайте по вкусу, однако стоит принять во внимание недавние сообщения об уязвимостях в MD5 и SHA1. Собираем ядро.

Установка необходимого ПО. Здесь тоже всё как обычно: 

root@linux# ./configure && make && make install

И так для каждого пакета. Можно воспользоваться пакетами из своего дистрибутива, если они в нём есть.

Загружаем необходимые модули:

  1. modprobe dm_mod
  2. modprobe dm_crypt
  3. modprobe aes_i586
  4. modprobe sha512

Теперь необходимо определиться, что использовать в качестве защищённого хранилища для файловой системы: раздел на диске или loop-файл. Принципиальной разницы нет, только в последнем случае придётся вводить на несколько команд больше. Для удобства рассмотрим эти случаи отдельно.

1) Использование раздела на диске. Предполагается, что у вас уже есть свободный раздел, который вы собираетесь зашифровать. Если нет, то самое время его подготовить с помощью стандартных средств. Файловую систему создавать не нужно, это будет сделано позже. Когда раздел готов, даём такую команду: 

root@linux# cryptsetup -c aes -h sha512 -s 256 -y create sec /dev/hdXY

где:

  • -с aes - алгоритм шифрования;
  • -h sha512 - алгоритм хэширования;
  • -s 256 - длина ключа;
  • -y - запрашивать подтверждение ключевой фразы;
  • sec - имя устройства Device mapper'а;
  • /dev/hdXY - зашифрованный раздел или устройство.

Должно появиться приглашение `Enter passphrase:'. Рекомендуется, чтобы это была именно фраза, символов так на 20. Опцию -y имеет смысл использовать только при первом доступе к носителю. Все остальные опции придётся вводить каждый раз в неизменном виде, поэтому стоит обернуть команду в скрипт.

После выполнения команды должен появиться файл /dev/mapper/sec, такой же, как и любой другой файл блочного устройства. На нём необходимо создать файловую систему и смонтировать её как обычно: 

root@linux# mke2fs /dev/mapper/sec
root@linux# mount /dev/mapper/sec /mnt/sec

Всё, можно работать с /mnt/sec как с обычной файловой системой, при этом шифрование будет производиться "на лету". По завершении работы НЕОБХОДИМО уничтожить устройство /dev/mapper/sec, иначе его можно будет смонтировать без ввода пароля. 

root@linux# umount /mnt/sec
root@linux# cryptsetup remove sec

2) Использование loop-файла. Всё то же самое, с той лишь разницей, что сначала придётся этот loop-файл создать и подключить его к петлевому устройству: 

root@linux# modprobe loop
root@linux# dd if=/dev/urandom of=~/container bs=1M count=100
root@linux# losetup /dev/loop/0 ~/container
root@linux# cryptsetup -c aes -h sha512 -s 256 -y create sec /dev/loop/0
root@linux# mke2fs /dev/mapper/sec
root@linux# mount /dev/mapper/sec /mnt/sec

Не забываем корректно завершить работу: 

root@linux# umount /mnt/sec
root@linux# cryptsetup remove sec
root@linux# losetup -d /dev/loop/0

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

Более подробную информацию о dm-crypt можно получить по адресу [6]. Ещё немного информации о dm-crypt по-русски здесь. Если по каким-то причинам требуется использовать Cryptoloop, то на этот случай есть Cryptoloop-HOWTO.

Также следует отметить, что существует Linux-порт программы BestCrypt.

by Eugeny Ostapenko (thesoulru@gmail.com)

Посмотрите так же на pam_mount.

Как изменить размер зашифрованного раздела на диске?

Внимание! Перед началом операции необходимо забекапить все данные с раздела.

Пусть раздел /dev/sda3 зашифрован при помощи dm_crypt без LUKS и LVM (первый метод из предыдущего раздела), и справа от него имеется свободное место. Раздел отображается на /dev/mapper/home, а примонтирован в /home. Требуется расширить /dev/sda3 на все свободное пространство или на его часть.

Переходим в однопользовательский режим и отмонтируем раздел: 

root@linux# init 1
root@linux# umount /home
root@linux# cryptdisks_stop home

Получаем информацию о первом цилиндре раздела: 

root@linux# fdisk /dev/sda
    
    Command (m for help): p
    /dev/sda3            2189       14593    89643162+  83  Linux

Запоминаем число 2189. Теперь нужно удалить существующий раздел /dev/sda3 (d) и создать на его месте новый (n) с таким же типом, номером (sda3) и первым цилиндром (2189). На сколько увеличится размер нового раздела зависит от введённой величины последнего цилиндра. Действуем: 

    Command (m for help): d
    Partition number (1-4): 3
    Command (m for help): n
    Command action
       e   extended
       p   primary partition (1-4)
    p   (или e)
    Partition number (1-4): 3
    First cylinder (2189-14593, default 2189):
    Using default value 2189
    Last cylinder or +size or +sizeM or +sizeK (2189-14593, default 14593): 
    Using default value 14593
    Command (m for help): w

Перезагружаемся. После перезагрузки /home должен монтироваться по-старому и иметь прежний размер. Далее следующее: 

root@linux# init 1
root@linux# umount /home
root@linux# cryptsetup resize home
root@linux# e2fsck -f /dev/mapper/home  (или какая у вас ФС)
root@linux# resize2fs /dev/mapper/home

Размер раздела увеличился пропорционально сдвигу последнего цилиндра.

Также смотрите:

Как безопасно удалять файлы?

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

Чтобы удалить информацию, необходимо:

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

Для решения этой задачи, например, можно использовать утилиту (и модуль ядра) THC-Securedelete. В архиве есть файл usenix6-gutmann.doc, который подробно описывает принципы удаления информации с диска с учетом кодирования данных в контроллере. К сожалению, это довольно туманная тема, поскольку многое зависит от конфигурации дисков, использования RAID и т.п. Другая утилита, решающая эту задачу — wipe.

Дополнительная информация:

«Secure Deletion of Data from Magnetic and Solid-State Memory» Питера Гутмана

Сетевая безопасность.

Посоветуйте нормальный файрвол под Linux! Типа AtGuard!

AtGuard - страшный уродец по сравнению с теми возможностями, которые предоставляют ipchains (2.2 ядра) и iptables aka netfilter (2.4 и новее). Рекомендуем читать документацию. Кроме того, под Linux существуют Checkpoint Firewall-1, Raptor, но это уже за деньги. Наконец, на [7] желающие могут попробовать T.REX. Это уже довольно сложные комплексы, предназначенные скорее для защиты корпоративных сетей, чем одиночных рабочих станций.

Подробнее - IPChains-HOWTO, IPTables-HOWTO, на русском.

Как мне узнать, что творится у меня в сети? Какие средства обнаружения вторжений существуют под Linux?

Самый популярный сниффер - TCPDump; домашняя страница проекта - [8]. Самое популярное свободное средство обнаружения вторжений (Intrusion Detection System, IDS) - Snort; домашняя страница - [9]. Довольно удобным для тех, кто предпочитает графические интерфейсы может оказаться пакет Wireshark ([10]), который к тому же имеет приятную возможность «вырезания» потока информации из лога tcpdump.

А вот как бы не дать пользователям заниматься тем же?

В противодействии взломщикам, пытающимся «прослушать сеть» надо сочетать три метода:

  • Построение не-sniffer-friendly сетевой топологии. Проще говоря - full-switched сети. Поскольку находятся любители переполнить таблицу соответствия MAC-адресов портам на коммутаторах (switches), активное оборудование тоже нужно правильно настраивать. Впрочем, это тема отдельного разговора.
  • Мониторинг сети - пользовательских систем и активного оборудования. Отметим, что сниффер - это пассивная программа. При правильной реализации сниффер не оказывает никакого влияния на сеть и не может быть обнаружен программными методами. Существующие методики обнаружения снифферов основываются на ошибках в реализации. Примером такого способа является следующий: проверяющий создает ethernet фрейм содержащий к качестве MAC адреса получателья адрес, неравный адресу подозреваемой машины. В качестве IP адреса получателья используется тем не менее IP подозреваемой машины. Пакет высылается в сеть. Идея состоит в том, что если сетевой интерфейс находится в promisc режиме то пакет с MAC не соответствующий MAC адресу карточки все равно пройдет через нее и достигнет уровня OS. Остается в качестве IP payload положить например ICMP echo-request или TCP SYN для некоторого well-known открытого порта. Если вы получили ответ, значит карточка находится в смешаном режиме. Если нет - то возможно что автор сниффера умнее вас. Второй способ проверки основан на том, что теоретически OS машины сетевой интерфейс которой находится в смешаном режиме, должна обрабатывать бОльшее число пакетов чем та, которая слушает только пакеты для себя. Проверка производится так - в сегменте сети создается большое количество траффика, не имеющего в качестве адреса получателя подозреваемую машину. После этого сравнивается время отклика (например, на ping) для подозреваемой машины и гарантированно «чистой.» Если подозреваемая машина сниффит сеть то на нее должна возрасти нагрузка по сравнению с «чистой» машиной. Способ не работает, если вы не способны создать загрузку в сети достаточно серьезную для «прогрузки» сниферящей машины. Т.е. прогрузить E15K на 10Mb ethernet вряд ли возможно. Примером ПО, позволяющего обнаружить sniffer в сети является Sentinel ([11]). Эта утилита реализует указанные две проверки плюс еще одну, основанную на том, что если сниффер увидит в сети незнакомый ip он сделает reverse DNS look-up, который можно увидеть. собственно, опять же «правильный» сниффер ничего такого делать не будет. Существует еще несколько методик поиска, могущих применяться с переменным успехом, однако вцелом идеальным решением остается применение коммутаторов.
  • Административные меры. Как ни странно, увольнение одного нарушителя может надолго отбить охоту у других повторять его эксперименты. Безусловно, это относится не только к снифферам.

Дополнительная информация:

А чем бы мне проверить, какие порты у меня открыты? А как просканировать себя на «дырки?»

Надо поискать в своем дистрибутиве nmap. Если его там нет, ругнуть составителя дистрибутива и пойти на [12], скачать, собрать, применить. В качестве «просто» сканнера безопасности взять Nessus (homepage - [13]), заслуживший «рекомендации лучших собаководов» в лице Jet Infosystems и ФАПСИ.

Как безопасно соединить два (три, десять) офиса через Internet?

Технология, которая вам нужна называется VPN (Virtual Private Network). Самым развитым на текущий момент средством для создания VPN является набор протоколов IPSec. В Linux существует несколько реализаций IPsec. Для ядер ветки 2.4 и более ранних поддержка реализована в рамках проекта Openswan; для ядер ветки 2.6 рекомендуется пользоваться встроенным стеком IPSec.

Среди других способов для создания VPN можно отметить pptp (и L2TP, [14]), STunnel ([15]), VTun и OpenVPN

Мы не рекомендуем вам пользоваться pptp без крайней необходимости. Протокол pptp в реализации от Microsoft подвержен многочисленным уязвимостям, описание которых можно взять, например, здесь: [16] (спасибо за ссылку Денису Матыцыну).

Ни при каких обстоятельствах мы не рекомендуем вам пользоваться протоколом FWZ (разработка компании Checkpoint, применяющаяся в линейке продуктов Firewall-1/VPN-1). Протокол FWZ подвержен уязвимости, позволяющей туннелировать любой UDP траффик внутрь защищенного периметра. Подробнее об уязвимости можно прочитать здесь: [17].

Известен некоторый MAC-адрес. Как можно определить по нему IP адрес?

[18]. Предупреждаю - штука капризная, работает не всегда и не у всех. Связано это с широковещательной природой arp, скоростями работы сети и фазой луны. Но попробовать не мешает.

Как копировать всю электронную почту компании, проходящую через сервер?

Вообще-то, это неэтично. Кроме того, электронная почта может попадать под действие закона о конфиденциальности почтовой переписки, так что такое копирование (даже если «директор фирмы велел») может быть наказуемо. Мы настоятельно рекомендуем проконсультироваться в юридическом отделе вашей компании, прежде чем начинать «играть в Большого Брата».

Для sendmail

Копирование почты средствами sendmail описано в Sendmail FAQ, вопрос 4.20. Копия статьи в новостную группу доступна тут, так же доступна копия logall.c.

Для Postfix

Прочтите man-страницу cleanup(8), обратите внимание на опцию always_bcc.

Для Exim

По этому поводу есть FAQ по адресу [19]. Единственное, там описывается процесс копирования только исходящей почты. Если же надо копировать всю почту, то вот миниFAQ не претендующий на единственно верное решение:

  • Определить system-filter
      system_filter = /usr/local/system_filter.exim
      system_filter_directory_transport = local_copy_outgoing

      /usr/local/system_filter.exim:

      if $sender_address_domain is domain.ru
      then
      unseen save /var/mail/backup/${lc:$sender_address}/outgoing/
      endif
  • Определить transport`s
     local_copy_incoming:

      driver = appendfile
      directory = /var/mail/backup/$local_part@$domain/incoming
      delivery_date_add
      envelope_to_add
      return_path_add
      group = mail
      user = mail
      mode = 0660
      maildir_format = true
      create_directory = true

      local_copy_outgoing:

      driver = appendfile
      delivery_date_add
      envelope_to_add
      return_path_add
      group = mail
      user = mail
      mode = 0660
      maildir_format = true
      create_directory = true
  • И последнее, задать в траспорте для доставки локальным пользователям shadow_transport
      local_delivery:

      shadow_transport = local_copy_incoming

Спасибо Алексею Синицыну за информацию о exim.

А что такое IDENT и зачем он нужен?

Сервис IDENT предназначен для определения имени пользователя на удаленной клиентской системе, который подключился к вашему серверу. Сервер ident ожидает соединения на порту 113/tcp (обычно запускается через inetd). Протокол ident описан в RFC 1413.

С работой сервиса IDENT связаны три особенности:

  • сервис сообщает удаленной стороне имена локальных пользователей, что может использоваться при атаке
  • сервер ident "знает" только о локальных пользователях, что может привести к проблемам в случае NAT
  • если производится фильтрация порта 113/tcp без уведомления другой стороны о фильтрации пакета (действие DROP в iptables), это может привести к задержке при соединениях с серверами, которые проверяют ident

Для решения первой и второй проблемы разработаны несколько ident серверов, которые не сообщают имени пользователя, а так же поддерживают NAT. Для решения третьей проблемы, фильтруя порт ident, используйте REJECT, а не DROP.

Обычно сервер ident можно безболезненно отключить. Практически единственным сервисом, для работы которого часто требуется ident, является irc.

Дополнительная информация:

Как шифровать почту?

Наш системный администратор прочитал совет 3.7 и архивирует всю почту. Чем можно защитить свою переписку?

Право на частную жизнь, безусловно, является основополагающим в свободном обществе.

Понимая это, Филипп Циммерманн создал программу, которую назвал «PGP - Pretty Good Privacy». Среди функциональных возможностей программы есть возможность посылки зашифрованных сообщений по электронной почте. Существует так же свободная реализация, совместимая с PGP - GNU Privacy Guard.

За более подробной информацией обратитесь к GnuPG Handbook, стандарту OpenPGP, описанному в RFC2440 и HOWTO о проведении встреч для обмена ключами GnuPG (оригинальная версия и перевод на русский язык).

Дополнительная информация:

Как обнаружить присутствие NAT? Как избежать обнаружения?

Поиск устройств, скрытых за трансляцией адресов и противодействие ему — это борьба брони и снаряда. Как и в ситуации с прослушиванием сетевого трафика, до победы еще далеко, и кому она достанется — пока не ясно.

Механизмы обнаружения NAT основаны на том, что сетевой трафик, порождаемый различными хостами, имеет отличающиеся характеристики. Например, начальное значение TTL (в Windows - 128, а в Linux - 64) отличается в различных операционных системах и, как правило, известно и статично. Наблюдая в сети пакеты с различным значением TTL, приходящим с одного и того же сетевого устройства, можно предположить, что это устройство осуществляет трансляцию адресов. Так же, наблюдение TTL, на единицу меньше ожидаемого значения, может говорить о наличии NAT (в этом случае предполагается, что NAT-устройство уменьшит TTL при маршрутизации пакета). Кроме того, для обнаружения NAT могут использоваться аномалии в IP ID, TCP Timestamp и трассировка открытого соединения.

Как правило, все эти меры можно успешно нейтрализовать за счет качественной нормализации трафика, выполняемой на устройстве с NAT. Использование NAT в режиме сетевого моста (без уменьшения значения TTL) позволит избежать обнаружения за счет TTL и трассировкой соединения.

Дополнительная информация:

Кто-то пытается подобрать пароль по SSH. Как с этим бороться?

Можно использовать pam_abl, позволяющий автоматически помещать в черный список на заданное время системы, с которых производятся попытки подбора пароля. Этот модуль PAM может работать не только с sshd, но и с другими демонами, поддерживающими аутентификацию через PAM.

Другое решение состоит в использовании Swatch для анализа /var/log/messages и поиска сообщений об ошибочной аутентификации в sshd.

Вот пример: 

watchfor /Illegal/
exec "/sbin/ipfw add 1 deny ip from $10 to any in via rl0 && echo /sbin/ipfw delete 1 | at now +30minutes"
mail addresses=admin\@domain.ru,subject="SSH:\ Illegal\ User\ IPFW \ Rule\ Added"

Дополнительная информация:

Дополнительные сведения.

Что еще почитать по безопасности?

Вот список рекомендуемых материалов:

Maximum Security: A Hacker's Guide to Protecting Your Internet Site and Network, [20] Материалы проекта HoneyNet, [21]

Атака на Internet. Медведовский И.Д., Семьянов П.В., Леонов Д.Г., ДМК, 1999 г.

Компьютерная безопасность: криптографические методы защиты. Петров А.А. ДМК, Москва 2000, ISBN 5-89818-064-8

Designing Network Security. Merike Kaeo. Cisco Press, 1999. ISBN 1-57870-043-4

Домашние страницы проектов OpenSwan и StrongSwan

"Securing and Optimizing Linux", сайт книги тут

[22]

[23]

[24]

[25]

Обнаружение вторжения средствами Debian GNU/Linux, статья на Linuxfocus, [26]

Распечатать и повесить на стену Шпаргалку о TCP/IP и tcpdump SANS Institute, краткое руководство о безопасности Linux с сайта Linuxsecurity.com

Про SSH читать буклет о основных командах, и, конечно, FAQ на сайте OpenSSH

Rainbow library, набор стандартов и документов о компьютерной безопасности, включая «Оранжевую» и «Красную» книги

Программное обеспечение

Список ПО, полезного для специалистов по информационной безопасности, составил Fyodor. Список называется Top 75 Security Tools.

Так же полезно посмотреть на ipt_p2p, a P2P match module for iptables

Забыл пароль root! Что делать?

Загрузиться с компакт-диска с linux, подмонтировать корневой раздел, отредактировать /etc/shadow или, если вы пользуетесь TCB, /etc/tcb/root/swadow.

Файл shadow состоит из строк, каждая из которых имеет 9 полей разделенных двоеточиями. В первом поле хранится имя пользователя, во втором - хеш пароля. Удалите содержимое второго поля, сохраните файл, отмонтируйте файловую систему, перезагрузитесь с жесткого диска, входите в систему как root, без пароля.Не забудьте установить новый пароль!

О этом FAQ.

В этом FAQ мало вопросов/плохие ответы/я могу лучше...

Отлично! Шлите ваши рекомендации. Я ищу единомышленников, готовых уделять время на поддержку этого FAQ в актуальном состоянии.

А почему ответы такие короткие, нельзя ли примеры конфигов привести, etc?

Как было замечено, кажется, в FAQ фидошной конференции RU.LINUX, «это FAQ, а не сказки братьев Гримм». Для большинства вопросов приведены ссылки, где можно найти более подробную информацию по соответствующей теме. Мне жаль, но у меня не так много времени. См. пункт 5.1.

Можно ли этот FAQ распечатать/повестить на стенку/подарить другу/etc?

Можно! Но! Мы уважаем время и труд людей, сделавших для вас этот FAQ «бездвоздмездно, то есть даром.» Поэтому, распространяя FAQ тем или иным образом, указывайте его происхождение. Кроме прочего, это позволит людям получить новые версии FAQ. На таких условиях вы можете распространять FAQ любым образом.

Источник — http://lorwiki.zhbert.ru/index.php?title=Linux_Security_FAQ&oldid=131