Ключевые слова:faq, security, linux, limit, (найти похожие документы)
From: Владимир Иванов <ivlad@unixgods.net.>, Анатолий Пугачев <mator@mail.ru.>
Newsgroups:
Date: Mon, 15 Aug 2004 18:21:07 +0000 (UTC)
Subject: LOR/Security FAQ
Оригинал: http://ivlad.unixgods.net/lor-faq/lor-faq.html
LOR/Security FAQ.
Владимир Иванов <ivlad@unixgods.net.>, Анатолий Пугачев <mator@mail.ru.> и др.
v2.4.10, 15 августа 2004
Этот документ представляет собой список вопросов, наиболее часто
задаваемых новыми посетителями форума Security на сервере
http://linux.org.ru (иначе LOR/Security). На данный момент он весьма
неполон поэтому дополнения принимаются!
Копия этого FAQ доступна по адресу: http://ivlad.unixgods.net/lor-faq1. Общие рекомендации по защите.
Во-первых, следует понимать, что абсолютной защиты не существует.
Задача человека, занимающегося обеспечением безопасности системы -
сделать так, что бы затраты на ее взлом превосходили ценность взлома.
Во-вторых, с ростом защищенности системы падает удобство работы с ней.
В-третьих, само обеспечение безопасности требует ресурсов -
человеческих, денежных и вычислительных.
Учтите, что данный FAQ предполагает наличие у читающего некоторого
объема знаний о администрировании UNIX.
> 1.1. Что посоветуете для общего обеспечения безопасности?
Прочитать данный FAQ и применить его к себе; а так же:
обеспечить физическую безопасность системы
никакие брэндмауэры, антивирусы, настройка прав на файловой
системе не помогут, если взломщик может вынуть жесткий диск из
сервера и унести домой. Даже если вы будете шифровать данные на
жестком диске, зачем облегчать ему задачу? А если он просто
развинтит винчестер? Держите ваши серверы под замком!
поставить все security fixes от вендоров вашего дистрибутива:
+ для RedHat ищите на ftp://updates.redhat.com/ или
воспользуйтесь RedHat Network up2date;
+ для Debian - поместите строчку
deb http://security.debian.org stable/updates main contrib non-free
в /etc/apt/sources.list, выполните apt-get update и apt-get
upgrade;
отключить все ненужные сервисы
проверьте как сервисы, запускаемые из (x)inetd так и
standalone, запускаемые из стартовых скриптов. man inetd.conf,
man xinetd
настроить syslogd для копирования важных сообщений на другую машину
man syslog.conf на предмет опции @hostname. Хранение копии
файлов журналов на отдельной системе (доступ к которой,
конечно, должен быть максимально ограничен) позволит иметь
журнал, который не был изменен вломщиком, заметавшим следы,
если взлом все-таки произошел. С другой стороны, syslogd обычно
использует UDP для доставки сообщений, что не позволяет
гарантировать, полноту журнала на протоколирующей системе.
Кроме того, это открывает широкие фозможности для спуфинга
сообщений и DoS с целью переполнения файловой системы, где
хранятся файлы журналов.
Таким образом, может оказаться необходимым рассмотреть
модифицированные версии syslogd (например, [6]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 (http://www.tripwire.org/) или
или Aide (http://www.cs.tut.fi/~rammer/aide.html).
Применение такого ПО позволит своевременно обнаружить изменения
в конфигурационных файлах или установку "троянских коней".
произвести тотальный chroot для всех возможных сервисов;
в первую очередь, это касается Apache (описание тут
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap29sec254.html)
и BIND (описание тут
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap21sec167.html),
если вы пользуетесь ими. Однако, я рекомендую вам помещать
в chroot все ваши сервисы предоставляемые пользователям через Internet.
приложить OpenWall patch
документация и патчи под стандартное ядро ищите на
http://www.openwall.com/linux/, обратите внимание, что
производитель вашего дистрибутива, возможно, уже включил этот
патч в свое ядро. Так же очень интересными возможностями
обладает GrSecurity (http://www.grsecurity.net/) (см. так же ответ
на вопрос 2.5).
Из перечисленных шагов каждый следующий требует несколько больше
усилий чем предыдущий, поэтому начинайте с начала, но доходить до
конца необязательно - рассчитывайте ваши силы и соблюдайте балланс
между ресурсами, потраченными на защиту информации и ценностью этой
информации.
> 1.2. Какой/какая дистрибутив/OS лучше в плане защищенности?
> Обязательно ли ставить Slackware на сервер? Правда ли, что RedHat
> Linux такой <<дырявый?>>
Разница между особенностями дистрибутивов, относящимися к
безопасности, обычно сильно перевешивается (не)знанием администратора.
Таким образом, знающий системный администратор способен на основе
дистрибутива общего назначения (каковыми являются и Slackware, и
RedHat, и Debian, и многие другие) построить систему, имеющую
приемлемый уровень безопасности для Internet-хоста. Однако, особо надо
отметить <<специализированные>> дистрибутивы. Они часто собраны на
основе <<нестандартного>> ядра и реализуют какую-либо формальную
модель безопасности.
Примером такого дистрибутива может служить AltLinux Castle, собранный
на основе проекта Linux RSBAC ( http://www.rbac.org/, документация
по-русски: http://linux.ru.net/~inger/RSBAC-DOC-ru.html). Такой
дистрибутив может служить фундаментом для построения высоко защищенной
системы, однако требует некоторого дополнительного времени для
настройки. Отметим так же существование ОС МСВС, основанной на
дистрибутиве Mandrake Linux и включающей в себя RSBAC.
TODO: SELinux,Trustix, LIDS, Openwall GNU/*/Linux
> 1.3. Взломали! Что делать?
Во-первых, Don't panic! :) Не вы первый, не вы последний. Во-вторых,
постарайтесь определить для себя, какие действия вы должны
предпринять. В-третьих, записывайте все, что вы сделали - это поможет
на досуге сесть, разобраться и сделать выводы.
Теперь подробней.
Идентифицируйте проблему.
Насколько опасен взлом? Критична ли информация, которая могла
подверчься утечке? Сколько систем взломано? Может ли быть так,
что о некоторых взломах вы не подозреваете? Стоит ли немедленно
выдернуть кабель из сетевого интерфейса или можно позволить
себе понаблюдать за действиями взломщика? Кого нужно оповестить
о взломе? Стоит ли привлекать правоохранительные органы?
Традиционно, для сохранения контроля над взломанной системой,
взломщики устанавливают т.н. rootkit - набор программ (и иногда
- модулей ядра), которые скрывают факт взлома от системного
администратора, обеспечивают доступ к системе, или позволяют
расширить привелегии атакующего. Если у вас возникло
подозрение, что в системе установлен rootkit, попробуйте
проверить ОС с помощью chkrootkit (http://www.chkrootkit.org/).
Так же проверьте целостность файлов с помощью Tripwire/Aide
(см. так же п. 1.1)
Приступайте к решению проблемы.
Не забудьте записывать все происходящее. Если вы решили
понаблюдать за взломщиком, отдавайте себе отчет, что он может
это обнаружить и постараться уничтожить все следы. Убедитесь,
что он не использует ваши сервера как трамплин для новых атак.
Будет очень неприятно оказаться вовлеченным в DDoS или
обнаружить у себя склад эксплоитов или вареза (хотя, кому как,
конечно :) ). Повторю прописную истину, что если вы следите за
взломщиком командой, не надо пользоваться e-mail для
координации своих действий.
Если у вас нет желания и сил проводить расследование,
переустановите OS с дистрибутива, восстановите данные из
резервных копий (у вас ведь есть резервные копии? :) ) и
перечитайте данный FAQ для повышения ее защищенности.
Сделайте выводы.
После того как работоспособность восстановлена, займитесь
<<разбором полетов.>> Как этот взломщик пролез? Как сделать
так, что бы подобного больше не случалось? Если попытки взломов
будут повторяться, к чему надо быть готовый. Тут вам
понадобятся сделанные ранее записи.
За дополнительной информацией обратитесь к руководству CERT:
http://www.cert.org/tech_tips/win-UNIX-system_compromise.html
> 1.4. Сборка из исходных текстов.
> Много раз в форуме читал что все сервернные приложения обязательно
> компилируют из исходников.Объясните новичку почему и какие изменения
> вносите при компиляции?
Это не так. Собирать из исходников надо, если знаешь, зачем. Если не
знаешь, возьми то, что есть в дистрибутиве. Самостоятельная сборка ПО
может понадобиться для внесения в работу программы изменений, которые
доступны только путем перекомпиляции из исходников. Вторым важным
случаем, когда имеет смысл пересобрать ПО самостоятельно, является
срочная необходимость исправления ошибки. После того, как вендор
вашего дистрибутива выпустил исправленную версию, установите ее вместо
вашей <<срочной>> сборки.
> 1.5. Чем опасна работа под root?
В первую очередь - собственными ошибками. Во-вторых, намного
возрастает опасность всевозможных <<троянских коней>> и т.п. Случайно
запустив троянскую программу с без привелегий root вы в худшем случае
потеряете свои файлы. Запуск из-под root может обернуться настоящей
катастрофой.
> 1.6. Незнакомые сервисы.
Много раз читал про такой подход к администрированиб безопасности -
<<если не знаешь, что это - отключи>>, но так же читал про <<если не
знаешь, что это - не трогай>>. Какой подход правильнее и надежнее?
Оба подхода фундаментально неверны. Наш подход - <<если не знаешь, что
это - узнай, потом реши>>. ;)
2. Локальная безопасность.
> 2.1. Не могу удалить файл от root!
> Например, /bin/login, /etc/passwd и др. Скопировать получается,
> удалить скопированный файл получается. Удалить исходный - нет.
Проблема обычно состоит в том, что на файл установлен бит immutable.
Файловая система ext2 поддерживает дополнительные биты, управляющие
некоторыми атрибутами файлов. В частности, бит immutable не позволяет
изменить, переименовать или удалить файл. Руководствами по
безопасности рекомендуется устанавливать такой бит на файлы типа
/bin/login и /bin/passwd. Атрибут append-only позволяет открывать файл
на запись только для дополнения. Такой бит может быть установлен на
файлы системных журналов.(ВНИМАНИЕ! При этом может нарушиться
нормальная работа logrotate). Подробнее - man chattr.
> 2.2. Попробовал снять 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 (homepage:
http://pw1.netcom.com/~spoon/lcap/ , там же есть ссылки на
дополнительную информацию).
Подробнее - /usr/src/linux/include/linux/capability.h и домашняя
страница lcap, Linux Capabilities FAQ
(http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt).
> 2.3. Как ограничить ресурсы пользователю? Диск, память, процессорное время?
Собственно ограничение дискового пространства пользователя выполняется
посредством механизма квот. Подробнее - 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.
> 2.4. Как дать пользователю права root, но только частично?
Например, как разрешить любой mount, а не только те, что в fstab?
Наша рекомендация - пользуйтесь sudo! Помимо раздачи прав
пользователям ведет учет применения этих самых прав, обладает гибкой
системой конфигурирования в том числе и в масштабе локальной сети
(впрочем, механизм этот далек от идеала IMHO - LDAP был бы куда как
лучше; для этого есть патчи, искать в списках рассылки sudo - прим.
Vladimir Ivanov).
Вторым вариантом может стать priv (
ftp://ftp.ucdavis.edu/pub/unix/priv.tar.gz). Идеи, заложенные в
эту программу в чем-то лучше, например, информацию о привелегиях можно
хранить в NIS, а формат конфигурационного файла напоминает termcap,
поэтому конфигурационные файлы легче создавать и модифицировать с
помощью скриптов, что полезно при больших инсталляциях. К сожалению,
по всей видимости, развитие priv остановлено.
Наконец, вы можете применить RSBAC (см. выше), но это требует куда
больших затрат на администрирование.
На крайний случай (на самый крайний!) - воспользуйтесь механизмом SUID
на конкретных программах.
Подробнее - http://www.courtesan.com/sudo/, man chmod.
> 2.5. Как не дать пользователю запускать свои программы?
У меня пользователь собрал/скачал эксплоит/игру/еще-какую-гадость.
Теперь запустил и ломает/играет/еще-какой-гадостью-занимается. Как
победить ситуацию в принципе?
Традиционно, в Unix существует ровно два места, куда пользователь
может записать свои файлы - домашний каталог пользователя и /tmp. Что
бы пользователь не смог запустить в системе лишние программы, собрав
их самостоятельно из исходников, следует поступить так:
* от каталога /tmp можно избавиться - создайте у каждого
пользователя в домашнем каталоге собственный TMP и пропишите на
$HOME/tmp соответствующие переменные окружения (обычно это
$TMPDIR). После этого права 1777 с /tmp можно снять. Поставьте,
скажем, 0755, 0711 или что-то подобное в соответствии с ситуацией.
* смонтируйте файловую систему с домашними каталогами пользователей
с параметром noexec, после чего они не смогут создать исполняемые
файлы в домашних каталогах. /tmp можно так же смонтировать с
noexec - если вам это нужно.
* Рекомендуем сделать тоже самое для сменных носителей - floppy,
CDROM, zip...
Подробнее - man mount.
Примечание от Piter Kravtchenko ([email protected]): такой фокус не
проходит, если вы устанавливаете софт, работающий с flexlm, поскольку
он плюет на $TMPDIR, и желает писать именно в /tmp.
Примечание от Sergey ([email protected]): Насчет монтирования хома с
noexec, ничто на мешает юзеру сделать скопировать в систему что-нить и
сделать:
/lib/ld-2.3.1.so ./nmap hosnname
Лекарство - патч к ядру с http://www.grsecurity.net/, на уровне
ядра .. если файл лежит в каталоге, не принадлежащем руту выполнение
запрещено.
> 2.6. А как сгенерировать стойкий пароль подручными средствами?
cat /dev/[u]random | uuencode -m - | head -n 2 | tail -c длина пароля
> 2.7. А как бы шифровать домашний каталог пользователя?
Начните с http://www.kerneli.org/, посмотрите так же на
pam_mount (http://www.flyn.org/projects/pam_mount/).
3. Сетевая безопасность.
> 3.1. Посоветуйте нормальный файрвол под Linux! Типа AtGuard!
AtGuard - страшный уродец по сравнению с теми возможностями, которые
предоставляют ipchains (2.2 ядра) и iptables aka netfilter (2.4 ядра).
Рекомендуем читать документацию. Кроме того, под Linux существуют
Checkpoint Firewall-1, Raptor, но это уже за деньги. Наконец, на
http://www.opensourcefirewall.com/ желающие могут попробовать
T.REX. Это уже довольно сложные комплексы, предназначенные скорее для
защиты корпоративных сетей, чем одиночных рабочих станций.
Подробнее - IPChains-HOWTO,IPTables-HOWTO.
> 3.2. Как мне узнать, что творится у меня в сети? Какие средства обнаружения
> вторжений существуют под Linux?
Самый популярный сниффер - TCPDump; домашняя страница проекта -
http://www.tcpdump.org/. Самое популярное свободное средство
обнаружения вторжений (Intrusion Detection System, IDS) - Snort;
домашняя страница - http://www.snort.org/. Довольно удобным для
тех, кто предпочитает графические интерфейсы может оказаться пакет
Ethereal (http://www.ethereal.com/), который к тому же имеет
приятную возможность <<вырезания>> потока информации из лога tcpdump.
> 3.3. А вот как бы не дать пользователям заниматься тем же?
В противодействии взломщикам, пытающимся <<прослушать сеть>> надо
сочетать три метода:
построение не-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 (http://www.packetfactory.net/projects/sentinel/).
Эта утилита реализует указанные две проверки плюс еще одну, основанную на
том, что если сниффер увидит в сети незнакомый ip он сделает
reverse DNS look-up, который можно увидеть. собственно, опять
же <<правильный>> сниффер ничего такого делать не будет.
Существует еще несколько методик поиска, могущих применяться с
переменным успехом, однако вцелом идеальным решением остается
применение коммутаторов.
административные меры
Как ни странно, увольнение одного нарушителя может надолго
отбить охоту у других повторять его эксперименты. Безусловно,
это относится не только к снифферам.
> 3.4. А чем бы мне проверить, какие порты у меня открыты? А как просканировать
> себя на <<дырки?>>
Надо поискать в своем дистрибутиве nmap. Если его там нет, ругнуть
составителя дистрибутива и пойти на http://www.insecure.org/nmap ,
скачать, собрать, применить. В качестве <<просто>> сканнера
безопасности взять Nessus (homepage - http://www.nessus.org/),
заслуживший <<рекомендации лучших собаководов>> в лице Jet Infosystems
и ФАПСИ.
> 3.5 Как безопасно соединить два (три, десять) офиса через Internet?
Технология, которая вам нужна называется VPN (Virtual Private
Network). Самым развитым на текущий момент средством для создания VPN
является набор протоколов IPSec. Реализация IPSec в linux называется
FreeSwan (домашняя страница проекта http://www.freeswan.org/).
Среди других способов для создания VPN можно отметить pptp (и L2TP,
http://www.l2tpd.org/), STunnel ( http://www.stunnel.org/),
VTun ( http://vtun.sourceforge.net/).
Мы не рекомендуем вам пользоваться pptp без крайней необходимости.
Протокол pptp в реализации от Microsoft подвержен многочисленным
уязвимостям, описание которых можно взять, например, здесь:
http://www.ssl.stu.neva.ru/psw/crypto/pptp.html (спасибо за ссылку
Денису Матыцыну).
Ни при каких обстоятельствах мы не рекомендуем вам пользоваться
протоколом FWZ (разработка компании Checkpoint, применяющаяся в
линейке продуктов Firewall-1/VPN-1). Протокол FWZ подвержен
уязвимости, позволяющей туннелировать любой UDP траффик внутрь
защищенного периметра. Подробнее об уязвимости можно прочитать здесь:
http://www.cert.org/advisories/CA-2001-17.html.
> 3.6. Известен некоторый MAC-адрес. Как можно определить по нему IP адрес?
http://www.habets.pp.se/synscan/programs.php?prog=arping
Предупреждаю - штука капризная, работает не всегда и не у всех.
Связано это с широковещательной природой arp, скоростями работы сети и
фазой луны. Но попробовать не мешает.
> 3.7. Как копировать всю электронную почту компании, проходящую через сервер?
Вообще-то, это неэтично. Кроме того, электронная почта может попадать
под действие закона о конфиденциальности почтовой переписки, так что
такое копирование (даже если <<директор фирмы велел>>) может быть
наказуемо. Мы настоятельно рекомендуем проконсультироваться в
юридическом отделе вашей компании, прежде чем начинать <<играть в
Большого Брата>>.
Для sendmail
Копирование почты средствами sendmail описано в Sendmail FAQ, вопрос
4.20.
Для Postfix
Прочтите man-страницу cleanup(8), обратите внимание на опцию
always_bcc.
Для Exim
По этому поводу есть FAQ по адресу
http://www.exim.org/exim-html-4.30/doc/html/FAQ_19.html#TOC348
Единственное, там описывается процесс копирования только исходящей
почты. Если же надо копировать всю почту, то вот миниFAQ не
претендующий на единственно верное решение:
1. Определить system-filter
system_filter = /usr/local/system_filter.exim
system_filter_directory_transport = local_copy_outgoing
/usr/local/system_filter.exim:
[...skip...]
if $sender_address_domain is domain.ru
then
unseen save /var/mail/backup/${lc:$sender_address}/outgoing/
endif
2. Определить 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
3. И последнее, задать в траспорте для доставки локальным
пользователям shadow_transport
local_delivery:
[...skip...]
shadow_transport = local_copy_incoming
Спасибо Алексею Синицыну за информацию о exim.
> 3.8. А что такое IDENT и зачем он нужен?
Сервис IDENT предназначен для определения имени пользователя на
удаленной клиентской системе, который подключился к вашему серверу.
Сервер ident ожидает соединения на порту 113/tcp (обычно запускается
через inetd). Протокол ident описан в RFC 1413.
С работой сервиса IDENT связаны три особенности:
1. сервис сообщает удаленной стороне имена локальных пользователей,
что может использоваться при атаке
2. сервер ident "знает" только о локальных пользователях, что может
привести к проблемам в случае NAT
3. если производится фильтрация порта 113/tcp без уведомления другой
стороны о фильтрации пакета (действие DROP в iptables), это может
привести к задержке при соединениях с серверами, которые проверяют
ident
Для решения первой и второй проблемы разработаны несколько ident
серверов, которые не сообщают имени пользователя а так же поддерживают
NAT. Для решения третьей проблемы, фильтруя порт ident, используйте
REJECT а не DROP.
Обычно сервер ident можно безболезненно отключить. Практически
единственным сервисом, для работы которого часто требуется ident,
является irc.
> 3.9. Как избавить пользователей от просмотра баннеров, не дать скачивать mp3
> и т.д.?
Можно отфильтровывать это на прокси-сервере. Для этого существует ряд
программ-редиректоров, например, "Режик" (http://www.rejik.ru/).
> 3.10. Как шифровать почту?
Наш системный администратор прочитал совет 3.7 и архивирует всю почту.
Чем можно защитить свою переписку?
Право на частную жизнь, безусловно, является основополагающим в
свободном обществе.
Понимая это, Филипп Циммерманн создал программу, которую назвал <<PGP
- Pretty Good Privacy>>. Среди функциональных возможностей программы
есть возможность посылки зашифрованных сообщений по электронной почте.
Существует так же свободная реализация, совместимая с PGP - GNU
Privacy Guard (http://www.gnupg.org/).
За более подробной информацией обратитесь к GnuPG Handbook (http://www.gnupg.org/gph/),
стандарту OpenPGP, описанному в RFC2440 (http://www.gnupg.org/rfc2440.html)
и HOWTO о проведении встреч для обмена ключами GnuPG
( оригинальная версия http://www.cryptnet.net/fdp/crypto/gpg-party.html
и перевод на русский язык http://ivlad.unixgods.net/gpg-party/gpg-party-howto.html).
4. Дополнительные сведения.
> 4.1. Что еще почитать по безопасности?
Вот список рекомендуемых материалов:
* Maximum Security: A Hacker's Guide to Protecting Your Internet
Site and Network, http://security.tsu.ru/info/misc/maxsec/
* Материалы проекта HoneyNet, http://project.honeynet.org/
* Атака на Internet. Медведовский И.Д., Семьянов П.В., Леонов Д.Г.,
ДМК, 1999 г.
* Компьютерная безопасность: криптографические методы защиты. Петров
А.А. ДМК, Москва 2000, ISBN 5-89818-064-8
* Designing Network Security. Merike Kaeo. Cisco Press, 1999. ISBN
1-57870-043-4
* Домашняя страница проекта FreeS/WAN (IPSec),
http://www.freeswan.org/
* "Securing and Optimizing Linux", сайт книги тут -
http://www.openna.com/products/books/sol/solus.php
* http://www.securityfocus.com/
* http://www.securityportal.com/
* http://www.insecure.org/
* http://www.linuxsecurity.com/
* Обнаружение вторжения средствами Debian GNU/Linux, статья на
Linuxfocus, http://www.linuxfocus.org/Russian/January2003/article274.shtml
* распечатать и повесить на стену
http://gsib.sl.ru/~mator/pdfs/tcpip.pdf,
http://gsib.sl.ru/~mator/pdfs/QuickRefCard.pdf
* про SSH читать
http://gsib.sl.ru/~mator/pdfs/Advanced_OpenSSH.pdf
* RFC 1413 - Identification Protocol
* ipt_p2p (http://mega.ist.utl.pt/~filipe/ipt_p2p/) is a P2P match module for iptables
* Rainbow library (http://www.radium.ncsc.mil/tpep/library/rainbow/),
набор стандартов и документов о компьютерной
безопасности, включая <<Оранжевую>> и <<Красную>> книги
> 4.2. Забыл пароль root! Что делать?
Загрузиться с компакт-диска с linux, подмонтировать корневой раздел,
отредактировать /etc/shadow.
Файл shadow состоит из строк, каждая из которых имеет 9 полей
разделенных двоеточиями. В первом поле хранится имя пользователя, во
втором - хеш пароля. Удалите содержимое второго поля, сохраните файл,
отмонтируйте файловую систему, перезагрузитесь с жесткого диска,
входите в систему как root, без пароля.Не забудьте установить новый
пароль!
5. О этом FAQ.
5.1. В этом FAQ мало вопросов/плохие ответы/я могу лучше...
Отлично! Шлите ваши рекомендации. Я ищу единомышленников, готовых
уделять время на поддержку этого FAQ в актуальном состоянии.
> 5.2. А почему ответы такие короткие, нельзя ли примеры конфигов привести, etc?
Как было замечено, кажется, в FAQ фидошной конференции RU.LINUX, <<это
FAQ а не сказки братьев Гримм>>. Для большинства вопросов приведены
ссылки, где можно найти более подробную информацию по соответствующей
теме. Мне жаль, но у меня не так много времени. См. пункт 5.1.
> 5.3. Можно ли этот FAQ распечатать/повестить на стенку/подарить другу/etc?
Можно! Но! Мы уважаем время и труд людей, сделавших для вас этот FAQ
<<бездвоздмездно, то есть даром.>> Поэтому, распространяя FAQ тем или
иным образом, указывайте его происхождение. Кроме прочего, это
позволит людям получить новые версии FAQ. На таких условиях вы можете
распространять FAQ любым образом.
