В начало → Настольная книга по безопасности Gentoo → A. Безопасность системы |
Сколько преград не установи, злоумышленник, имея физический доступ к компьютеру, сможет легко их обойти. Несмотря на это, кое-какие меры для относительной защиты от злоумышленника с физическим доступом к вашей машине принять можно. Поместив оборудование в кладовку под замок, вы помешаете злоумышленнику попросту отключить его и унести с собой. Стоит запереть корпус компьютера на замок, чтобы не дать злоумышленнику просто вынуть из него жесткий диск. Чтобы предотвратить загрузку с альтернативного диска, благодаря чему можно просто обойти порядок входа в систему и права доступа, попробуйте установить в BIOS жесткий диск в качестве первого загрузочного устройства и запаролить BIOS. Также важно установить пароль для загрузчика LILO или GRUB, чтобы не дать недобросовестному пользователю загрузить систему в однопользовательском режиме, получив к ней полный доступ. Это подробно описано в третьей главе, в разделах защита GRUB паролем и защита LILO паролем.
Для начала выпишите службы, которые должны работать на машине. Это поможет вам выбрать наилучшую схему разбивки разделов в системе и позволит лучше спланировать меры безопасности. Конечно же, в этом нет необходимости, если ваш компьютер служит для одной определенной задачи, например в качестве рабочей станции или выделенного межсетевого экрана. В таких случаях не должны запускаться никакие службы, за исключением, возможно, sshd.
Составленный список также может пригодиться для администрирования системы. Вы увидите, что, поддерживая перечень текущих версий, значительно легче удерживать все в актуальном состоянии, когда в каких-либо из ваших демонов обнаруживаются уязвимости к удаленному доступу.
Правила разбиения разделов:
любое дерево каталогов, в которое пользователь должен иметь возможность записи (например, /home, /tmp), должно размещаться в отдельном разделе с использованием дисковых квот. Это снижает риск переполнения всей файловой системы каким-либо пользователем. Portage использует /var/tmp для компиляции, поэтому этот раздел должен быть большим
любое дерево каталогов, в которое вы планируете устанавливать программное обеспечение не средствами управления пакетами дистрибутива, следует размещать в отдельном разделе. Согласно стандарту иерархии файлов (англ.), это /opt или /usr/local. Являясь отдельными разделами, они не удаляются при переустановке системы
для лишней защиты можно поместить статические данные в отдельный раздел, монтируемый только для чтения. Если вы настоящий параноик, можете пользоваться неперезаписываемым носителем, например, компакт-диском
Администратор системы (пользователь root) является наиболее важным пользователем, и его права не следует использовать без крайней необходимости. Если злоумышленник получит доступ с правами администратора, единственным способом восстановить доверие к системе будет переустановить ее.
Золотые правила для root
всегда создавайте пользователя для каждодневных работ, а если этому пользователю понадобятся права администратора, добавьте его в группу «wheel». Это дает возможность обычным пользователям выполнять команды с правами администратора с помощью su
никогда не запускайте X или другое пользовательское приложение под root. Права администратора следует использовать только при крайней необходимости: если уязвимость есть в приложении, запущенном от имени пользователя, злоумышленник может получить права этого пользователя. А если приложение запущено с правами администратора, то злоумышленник получит их.
войдя под учетной записью администратора, всегда указывайте абсолютные пути (или всегда используйте команду su -, которая заменяет переменные среды пользователя на администраторские, обеспечивая наличие в PATH администратора только защищенных каталогов, например /bin и /sbin). Иначе можно обмануть администратора и заставить его выполнить совершенно другое приложение. Если PATH администратора защищен или он использует только абсолютные пути, то можно быть уверенным, что это не произойдет
если пользователю нужно выполнять лишь несколько команд с правами администратора, то вместо использования учетной записи root, рекомендуется использовать команду sudo. Просто также задумывайтесь, кому вы даете доступ к этой команде!
никогда не оставляйте без присмотра терминал, в котором вы зарегистрированы в качестве root
В Gentoo по умолчанию есть некоторая защита от обычных пользователей, пытающихся с помощью su получить права администратора. По умолчанию настройки PAM требуют, чтобы пользователь был членом группы «wheel» для того, чтобы запускать команду su.
Есть ряд причин набросать правила безопасности для своей системы или сети.
хорошие правила безопасности позволяют вам наметить подход к безопасности системно, а не сваливать в кучу разрозненные меры. Например, без правил администратор может решить отключить telnet, так как в нем пароли передаются не зашифрованными, оставив доступ по FTP, обладающему таким же недостатком. Хорошие правила безопасности позволяют выявить, какие меры безопасности имеют смысл, а какие — нет
чтобы выявлять проблемы, проводить аудит или выслеживать злоумышленников, может потребоваться перехват данных, передаваемых по сети, проверка истории входа пользователей и выполнявшихся ими команд, а также просмотр их домашних каталогов. Без указания об этом в документации и явного предупреждения пользователей такие действия могут оказаться незаконными и привести к привлечению вас к ответственности по закону
похищенные учетные записи пользователей являются одной из самых распространенных угроз безопасности системы. Не объясняя пользователям, почему безопасность важна, и как ее поддерживать (например, не записывать пароли на клочках бумаги на рабочем месте), можно и не надеяться на защищенность пользовательских данных
хорошо задокументированная схема сети и системы поможет как вам, так и, при необходимости, суду и следствию, отслеживать проникновение злоумышленника и выявлять слабые места по факту взлома. Уведомление правил безопасности о том, что ваша система является частной сетью и несанкционированный доступ запрещен, также способствует надлежащему преследованию нарушителя по закону после его поимки
Надеемся, что теперь необходимость в хороших правилах безопасности более чем ясна.
Сами по себе правила — это документ или набор документов, раскрывающих функции сети или системы (например, какие именно услуги предоставляются), допустимые и запрещенные действия, применение «передового опыта» обеспечения безопасности, и т. д. Все пользователи должны быть знакомы как с правилами безопасности, так и с изменениями, которые вы вносите для поддержания их актуальности. Важно уделять время, чтобы добиваться понимания правил пользователями, объяснять, зачем знакомится под роспись, и что будет, если пользователь явно нарушит их требования (в правилах безопасности об этом должно быть ясно указано). Необходимо повторять ознакомление по крайней мере раз в год, так как правила подвержены изменениям (а также для напоминания пользователям).
Примечание: Создавайте правила, понятные для чтения и не допускающие разночтений в любой ситуации. |
Правила безопасности должны охватывать по крайней мере следующие темы:
допустимые действия
обращение с ценными сведениями (в любом письменном виде, на электронном или бумажном носителе)
обращение с компьютерным оборудованием в поездках
Для разных пользователей могут требоваться разные типы или уровни доступа, и содержание ваших правил может отличаться, чтобы охватить их все.
В распухших правилах безопасности легко упустить важные моменты. В правилах для ИТ-персонала могут содержаться сведения, закрытые для обычных пользователей. Поэтому есть смысл разделить их на несколько небольших разделов, например, «допустимые действия», «использование паролей», «правила использования электронной почты», «правила удаленного доступа».
Примеры правил безопасности приведены на сайте проекта правил безопасности SANS (англ.). Если у вас небольшая сеть, и вы считаете, что эти примеры слишком велики, можете обратиться к руководству по объектовой безопасности (Site Security Handbook) (англ.).
В Gentoo Linux файл make.conf содержит USE-флаги, определенные пользователем, а /etc/make.profile/make.defaults — USE-флаги по умолчанию. Для данного руководства важны флаги pam (Pluggable Authentication Modules — подключаемые модули опознания), tcpd (Упаковщики TCP) и ssl (Secure Socket Layer). Все они включены в USE-флаги по умолчанию.
В GRUB можно защитить загрузчик паролем двумя различными способами. В первом используется открытый пароль, а во втором — шифрование с использованием md5+salt.
Листинг 1: /boot/grub/grub.conf |
timeout 5 password changeme |
Благодаря этим строкам был добавлен пароль changeme. Если во время загрузки не ввести пароль, то GRUB просто загружает вариант по умолчанию.
При добавлении пароля MD5 вы должны преобразовать открытый пароль в зашифрованный в том же формате, что и в файле /etc/shadow. За дополнительными сведениями обращайтесь к man crypt. Зашифрованный пароль, например changeme, может выглядеть вот так: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
Зашифровать пароль можно прямо в оболочке GRUB:
Листинг 2: md5crypt в оболочке grub |
#/sbin/grub GRUB version 0.92 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> md5crypt Password: ******** (было набрано слово changeme) Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs. grub> quit |
Затем скопируйте полученный пароль в /boot/grub/grub.conf.
Листинг 3: /boot/grub/grub.conf |
timeout 5 password --md5 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs. |
Задержка в 5 секунд пригодится в случае, когда система физически недоступна, и нужна возможность перезагрузки без использования клавиатуры. Более подробно о паролях в GRUB вы можете узнать, набрав info grub.
В LILO также поддерживается два способа защиты с помощью пароля: общий и для отдельного образа, в обоих случаях пароль хранится в открытом виде.
Общий пароль устанавливается в начале файла конфигурации и относится к каждому загрузочному образу:
Листинг 4: /etc/lilo.conf |
password=changeme restricted delay=3 |
Пароль для отдельного образа устанавливается следующим образом:
Листинг 5: /etc/lilo.conf |
image=/boot/bzImage read-only password=changeme restricted |
Если параметр restricted не введен, то пароль будет запрашиваться при каждой загрузке.
Чтобы сохранить новые сведения в файле lilo.conf, нужно запустить /sbin/lilo.
С помощью файла /etc/securetty можно указать, с каких терминальных устройств (tty) можно входить в систему администратору.
Рекомендуется закомментировать все строки, кроме vc/1 (если у вас devfs), или кроме tty1 (если у вас udev). Благодаря этому суперпользователь сможет входить в систему одновременно только один раз и только с одного терминала.
Примечание: Пользователи, входящие в группу «wheel» по-прежнему смогут воспользоваться su -, чтобы стать администратором, работая с других терминалов. |
Листинг 6: /etc/securetty |
(для devfs) vc/1 (для udev) tty1 |
Для перехвата предупреждений и ошибок, которые могут свидетельствовать о происходящей атаке или успешном взломе, следует подключать дополнительное журналирование. Часто злоумышленники сканируют систему и «проверяют ее на зуб» перед атакой.
Также немаловажно, чтобы файлы журналов были легко читаемыми и обозримыми. В Gentoo Linux при установке на выбор предлагается 3 разных средства журналирования.
Syslogd является самым распространенным средством журналирования для Linux и Unix. Он способен делать ротацию журналов, однако использование /usr/sbin/logrotate с вызовом по расписанию (logrotate настраивается с помощью файла /etc/logrotate.conf) может оказаться полезней, так как у logrotate есть много дополнительных возможностей. Частота ротации подбирается в зависимости от загрузки системы.
Ниже приведен стандартный файл syslog.conf с некоторыми добавлениями. Мы раскомментировали строки cron и tty, и добавили удаленный сервер журналирования. Для дальнейшего усиления журналирования можно настроить ведение журнала в двух местах.
Листинг 1: /etc/syslog.conf |
# /etc/syslog.conf Файл настройки syslogd. # # За дополнительной информацией обращайтесь к # странице справки syslog.conf(5). # Взято из Debian, пока пользуемся им # Daniel Robbins, 5/15/99 # # Сначала стандартные файлы журналов. Журналирование по подсистемам. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* /var/log/mail.log user.* -/var/log/user.log uucp.* -/var/log/uucp.log local6.debug /var/log/imapd.log # # Журналирование почтовой системы. Разбито на части, чтобы # легко писать сценарии для разбора этих файлов. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # Журналирование новостной системы INN # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice # # Журналы, куда может попадать "все подряд". # *.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages # # Предупреждения и чрезвычайные сообщения, посылаемые всем вошедшим. # *.emerg * *.=alert * # # Мне нравится вывод сообщений на консоль, но только на ту виртуальную # консоль, что я обычно оставляю простаивать. # daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8 # Настройка сервера удаленного журналирования *.* @logserver # Именованный канал /dev/xconsole - для утилиты `xconsole'. Чтобы использовать, # следует запускать `xconsole' с параметром `-file': # # $ xconsole -file /dev/xconsole [...] # # ПРИМЕЧАНИЕ: измените список, данный ниже, или вы с ума сойдете, если # у вас осносительно загруженная площадка.. # #daemon.*,mail.*;\ # news.crit;news.err;news.notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn |/dev/xconsole local2.* --/var/log/ppp.log |
Злоумышленники, скорее всего, будут стараться уничтожать следы своего пребывания, исправляя или удаляя файлы журналов. Можно затруднить им работу, ведя журналирование на одном или нескольких удаленных серверах журнала, расположенных на других компьютерах. Узнать больше о syslogd можно, запустив man syslog.
Metalog, написанный Frank Dennis, не может отправлять журнал на удаленный сервер, но дает преимущество, когда речь о скорости и гибкости журналирования. Он может вести журналы по названию программы, срочности, подсистеме (как и syslogd), и комплектуется разборщиком регулярных выражений, с помощью которых можно запускать внешние сценарии при обнаружении заданных шаблонов. При необходимости это может оказаться очень полезным.
Стандартной настройки обычно достаточно. Если необходимо, чтобы вам отправлялось письмо при любом неверно введенном пароле, используйте один из следующих сценариев.
Для postfix:
Листинг 2: /usr/local/sbin/mail_pwd_failures.sh для postfix |
#! /bin/sh echo "$3" | mail -s "Warning (program : $2)" root |
Для netqmail:
Листинг 3: /usr/local/sbin/mail_pwd_failures.sh for netqmail |
#!/bin/sh echo "To: root Subject:Failure (Warning: $2) $3 " | /var/qmail/bin/qmail-inject -f root |
Не забудьте сделать сценарий исполняемым командой /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh.
Затем в файле /etc/metalog/metalog.conf раскомментируйте строку под «Password failures»:
Листинг 4: /etc/metalog/metalog.conf |
command = "/usr/local/sbin/mail_pwd_failures.sh" |
Syslog-ng, за некоторыми отличиями, обладает теми же возможностями, что и syslog и metalog. Он может фильтровать сообщения по уровню и содержимому (как metalog), вести удаленное журналирование, как syslog, обрабатывать журналы, получаемые от syslogd (даже потоки от Solaris), записывать в TTY, запускать программы, и служить сервером журналирования. То есть, он сочетает лучшие черты обоих средств журналирования с возможностью расширенной настройки.
Ниже приведен слегка подправленный классический конфигурационный файл.
Листинг 5: /etc/syslog-ng/syslog-ng.conf |
options { chain_hostnames(off); sync(0); }; #источник, откуда читать журнал source src { unix-stream("/dev/log"); internal(); }; source kernsrc { file("/proc/kmsg"); }; #получатели destination authlog { file("/var/log/auth.log"); }; destination syslog { file("/var/log/syslog"); }; destination cron { file("/var/log/cron.log"); }; destination daemon { file("/var/log/daemon.log"); }; destination kern { file("/var/log/kern.log"); }; destination lpr { file("/var/log/lpr.log"); }; destination user { file("/var/log/user.log"); }; destination mail { file("/var/log/mail.log"); }; destination mailinfo { file("/var/log/mail.info"); }; destination mailwarn { file("/var/log/mail.warn"); }; destination mailerr { file("/var/log/mail.err"); }; destination newscrit { file("/var/log/news/news.crit"); }; destination newserr { file("/var/log/news/news.err"); }; destination newsnotice { file("/var/log/news/news.notice"); }; destination debug { file("/var/log/debug"); }; destination messages { file("/var/log/messages"); }; destination console { usertty("root"); }; destination console_all { file("/dev/tty12"); }; destination xconsole { pipe("/dev/xconsole"); }; #создание фильтров filter f_authpriv { facility(auth, authpriv); }; filter f_syslog { not facility(authpriv, mail); }; filter f_cron { facility(cron); }; filter f_daemon { facility(daemon); }; filter f_kern { facility(kern); }; filter f_lpr { facility(lpr); }; filter f_mail { facility(mail); }; filter f_user { facility(user); }; filter f_debug { not facility(auth, authpriv, news, mail); }; filter f_messages { level(info..warn) and not facility(auth, authpriv, mail, news); }; filter f_emergency { level(emerg); }; filter f_info { level(info); }; filter f_notice { level(notice); }; filter f_warn { level(warn); }; filter f_crit { level(crit); }; filter f_err { level(err); }; filter f_failed { match("failed"); }; filter f_denied { match("denied"); }; #связывание фильтров с получателями log { source(src); filter(f_authpriv); destination(authlog); }; log { source(src); filter(f_syslog); destination(syslog); }; log { source(src); filter(f_cron); destination(cron); }; log { source(src); filter(f_daemon); destination(daemon); }; log { source(kernsrc); filter(f_kern); destination(kern); }; log { source(src); filter(f_lpr); destination(lpr); }; log { source(src); filter(f_mail); destination(mail); }; log { source(src); filter(f_user); destination(user); }; log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); }; log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); }; log { source(src); filter(f_mail); filter(f_err); destination(mailerr); }; log { source(src); filter(f_debug); destination(debug); }; log { source(src); filter(f_messages); destination(messages); }; log { source(src); filter(f_emergency); destination(console); }; #журнал по умолчанию log { source(src); destination(console_all); }; |
Syslog-ng очень легко настраивается, но с той же легкостью можно что-либо упустить в файле настройки, так как он очень велик. Автор также обещает дополнительные возможности, например, шифрование, опознание, сжатие и обязательную проверку прав доступа (MAC — mandatory access control). С такими возможностями программа станет незаменимой для журналирования в сети, так как злоумышленник не сможет перехватывать журнал.
К тому же у syslog-ng есть еще одно достоинство: он не требует прав администратора для запуска!
Конечно же, ведение журналов — это только полдела. Приложение наподобие Logcheck может значительно облегчить регулярный анализ журналов. Logcheck — это сценарий, который вместе с двоичным файлом logtail, запускается службой cron и сверяет журналы с заданными правилами на предмет подозрительной деятельности. При совпадении он отправляет электронное письмо с соответствующими записями на почтовый ящик администратора.
Logcheck и logtail входят в состав пакета app-admin/logsentry.
Logcheck использует четыре файла для выделения важных событий из обычных сообщений. Этими файлами являются logcheck.hacking, содержащий известные сообщения, встречающиеся при взломе, logcheck.violations, содержащий шаблоны, сигнализирующие о нарушениях безопасности, logcheck.violations.ignore, содержащий ключевые слова, совпадающие с шаблонами в файле нарушений, но которые можно игнорировать, и logcheck.ignore, содержащий записи, которые можно игнорировать.
Предупреждение: Не оставляйте logcheck.violations.ignore пустым. Для обработки журналов Logcheck использует grep, некоторые версии которого считают пустой файл знаком подстановки (wildcard). В таком случае все нарушения будут игнорироваться. |
При монтировании разделов с файловой системой ext2, ext3 или reiserfs можно указать различные параметры в файле /etc/fstab. Среди них:
nosuid — игнорировать установленный для файла бит SUID, уподобляя его обычному файлу
noexec — предотвращать запуск файлов с данного раздела
nodev — игнорировать файлы устройств
К сожалению, эти настройки можно легко обойти, задействовав косвенные пути. Тем не менее, установкой noexec для /tmp можно воспрепятствовать использованию большинства вредоносных программ, разработанных для запуска напрямую из каталога /tmp.
Листинг 1: /etc/fstab |
/dev/sda1 /boot ext2 noauto,noatime 1 1 /dev/sda2 none swap sw 0 0 /dev/sda3 / reiserfs notail,noatime 0 0 /dev/sda4 /tmp reiserfs notail,noatime,nodev,nosuid,noexec 0 0 /dev/sda5 /var reiserfs notail,noatime,nodev 0 0 /dev/sda6 /home reiserfs notail,noatime,nodev,nosuid 0 0 /dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 proc /proc proc defaults 0 0 |
Предупреждение: Установка /tmp в режим noexec может помешать нормальной работе различных сценариев. |
Примечание: За сведениями о дисковых квотах обращайтесь к разделу квоты. |
Примечание: Я не устанавливаю для /var параметры noexec или nosuid, даже если обычно файлы никогда не запускаются из этого каталога, так как netqmail устанавливается в /var/qmail и требует разрешения на исполнение и доступ к одному файлу с SUID. Я устанавливаю /usr в режим только для чтения, так как я никогда ничего не записываю туда, кроме случая обновления Gentoo. Тогда я перемонтирую файловую систему в режиме чтения-записи, обновляю систему и перемонтирую обратно в режиме только для чтения. |
Примечание: Даже если вы не используете netqmail, Gentoo все же нужен установленный бит исполнения для /var/tmp, так поскольку сборка ebuild выполняется именно здесь. Но если у вас есть насущная необходимость монтировать каталог /var с параметром noexec, можно указать для этого альтернативный путь. |
Контроль использования ресурсов может быть очень эффективным при попытке предотвращения локальной атаки на отказ от обслуживания или ограничения максимального количества входов в систему для группы или пользователя. Однако излишне строгие настройки будут затормаживать работу вашей системы и станут причиной сбоев программ, поэтому проверьте каждый из параметров.
Листинг 1: /etc/security/limits.conf |
* soft core 0 * hard core 0 * hard nproc 15 * hard rss 10000 * - maxlogins 2 @dev hard core 100000 @dev soft nproc 20 @dev hard nproc 35 @dev - maxlogins 10 |
Если вы пытаетесь установить nproc или maxlogins в 0, то подумайте, может, лучше вместо этого удалить пользователя. В примере выше установлены настройки группы dev для процессов, основных файлов и maxlogins. Все остальное установлено в значения по умолчанию.
Примечание: /etc/security/limits.conf является частью пакета PAM и применима только для пакетов, использующих PAM. |
/etc/limits очень схож с файлом ограничений /etc/security/limits.conf. Единственное отличие — формат, который применим лишь для пользователей или заполнителей (но не для групп). Вот пример конфигурации:
Листинг 2: /etc/limits |
* L2 C0 U15 R10000 kn L10 C100000 U35 |
Здесь устанавливаются настройки по умолчанию и специфичные настройки для пользователя kn. limits являются частью пакета sys-apps/shadow. Если вы включили pam в make.conf, то нет необходимости устанавливать какие-либо ограничения в этом файле.
Предупреждение: Проверьте, что рабочая файловая система поддерживает квоты. Чтобы задействовать квоты для ReiserFS, необходимо наложить заплатку на ядро,которая доступна на сайте Namesys. Пользовательские утилиты можно загрузить с сайта проекта Linux DiskQuota project. При совместной работе квот с ReiserFS вы можете встретить проблемы. Мы вас предупредили! |
Установка квот на файловые разделы ограничивает использование дискового пространства для каждого пользователя или каждой группы. Квоты должны быть включены в ядре и добавлены к точке монтирования в /etc/fstab. Параметр ядра включается в конфигурации ядра в разделе File systems->Quota support. Установите следующие настройки, пересоберите ядро и перезагрузитесь в систему с новым ядром.
Начните с установки квот, запустив emerge quota. Затем измените /etc/fstab и добавьте usrquota и grpquota к разделам, использование которых вы хотите ограничить, так, как показано в примере ниже.
Листинг 3: /etc/fstab |
/dev/sda1 /boot ext2 noauto,noatime 1 1 /dev/sda2 none swap sw 0 0 /dev/sda3 / reiserfs notail,noatime 0 0 /dev/sda4 /tmp ext3 noatime,nodev,nosuid,noexec,usrquota,grpquota 0 0 /dev/sda5 /var ext3 noatime,nodev,usrquota,grpquota 0 0 /dev/sda6 /home ext3 noatime,nodev,nosuid,usrquota,grpquota 0 0 /dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 proc /proc proc defaults 0 0 |
Создайте для каждого раздела, для которого включены квоты, файлы квот (aquota.user и aquota.group) и поместите их в корень каждого из разделов.
Листинг 4: Создание файлов квот |
# touch /tmp/aquota.user # touch /tmp/aquota.group # chmod 600 /tmp/aquota.user # chmod 600 /tmp/aquota.group |
Это шаг выполняется для любого раздела, для которого включены квоты. После добавления и настройки файлов квот вам понадобится добавить сценарий запуска quota в загрузочный уровень запуска.
Важно: XFS проверяет все квоты самостоятельно, поэтому для нее не требуется добавления сценария quota в начальный уровень загрузки. Есть ряд файловых систем, не указанных в этом документе, которые функционируют также, поэтому обратитесь к странице руководства вашей файловой системы, для того, чтобы узнать, как она обрабатывает проверки квот. |
Листинг 5: Добавление квот в загрузочный уровень исполнения |
# rc-update add quota boot |
Теперь настроим систему для проверки квот раз в неделю, добавив следующую строку в /etc/crontab:
Листинг 6: Добавление проверки квот в crontab |
0 3 * * 0 /usr/sbin/quotacheck -avug. |
Перезагрузив компьютер, время установить квоты для пользователей и групп. С помощью команды edquota -u kn запустится редактор, определенный переменной $EDITOR (по умолчанию nano) для правки квот для пользователя kn. edquota -g сделает то же самое для групп.
Листинг 7: Установка квот для пользователя kn |
Quotas for user kn: /dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500) inodes in use: 356, limits (soft = 1000, hard = 1500) |
Для большей информации обратитесь к man edquota или Quota miniHOWTO.
Если правилами определено, что пользователи должны менять свои пароли каждые две недели, измените значения переменной PASS_MAX_DAYS на 14 и PASS_WARN_AGE на 7. Это рекомендуется для того, чтобы предотвратить старение пароля, так как полный перебор всех значений может взломать любой пароль, если есть достаточно времени. Также рекомендуется установить LOG_OK_LOGINS в значение yes.
Файл login.access также является частью пакета sys-apps/shadow, который управляет процессом входа в систему. Он определяет на основании имени пользователя, группы или узла, кто сможет войти в систему, а кто не сможет. Так как по умолчанию этот файл содержит лишь примеры и комментарии, то все пользователи системы могут войти в систему. В зависимости от того, что вы защищаете — сервер или рабочую станцию, рекомендуется настроить этот файл так, чтобы никто, кроме вас (как администратора), не мог получить доступ к консоли.
Примечание: Эти настройки не влияют на суперпользователя. |
Листинг 8: /etc/login.access |
-:ALL EXCEPT wheel sync:console -:wheel:ALL EXCEPT LOCAL .gentoo.org |
Важно: Настраивая эти параметры, будьте осторожны, так как любая ошибка может привести к тому, что вы не сможете войти в собственную систему, не воспользовавшись правами суперпользователя. |
Примечание: Эти настройки не применимы для SSH, так как по умолчанию для SSH не запускается /bin/login. Это может быть включено с помощью параметра UseLogin yes в файле /etc/ssh/sshd_config. |
Это устанавливает доступ на вход в систему так, что только члены группы wheel могут входить в систему локально или из домена gentoo.org. Возможно, попахивает паранойей, но лучше быть в безопасности, чем сожалеть о потерянном.
Обычные пользователи не должны иметь доступ к конфигурационным файлам или паролям. Атакующий может украсть пароли к базе данных или веб-сайту и использовать их для дефейса или даже хуже — для удаления файлов. Вот почему важно правильно установить разрешения на файлы. Если вы уверены, что определенный файл может использоваться только суперпользователем, установите для него права 0600 и назначьте ему правильного владельца с помощью chown.
Листинг 1: Поиск файлов, доступных по записи всем |
# find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \; 2>/dev/null >writable.txt # find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \; 2>/dev/null >>writable.txt |
Эти команды создадут огромный файл, содержащий имена файлов, которые имеют права на запись для группы и всех остальных. Проверьте их и устраните ненужные права, запустив для файлов команду /bin/chmod o-w.
Файлы с битами SUID или SGID будут запущены с привелегиями владельца или группы владельца, а не с привелегиями запустившего их пользователя. Обычно это используется для файлов, которые должны запускаться с правами суперпользователя для выполнения необходимых задач. Эти файлы, если содержат уязвимости, могут стать источником повышения привелегий локальным пользователем. Это может быть опасным, поэтому с подобных файлов необходимо любой ценой удалить установленный бит SUID или SGID. Если вы не используете эти файлы, запустите для них команду chmod 0 или удалите пакет, установивший этот файл (проверить, какому пакету принадлежит определенный файл, можно с помощью команды equery; если у вас ее еще нет, то, чтобы установить ее, просто наберите emerge gentoolkit). Иначе просто удалите бит SUID с помощью chmod -s.
Листинг 2: Поиск файлов с setuid |
# find / -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \; 2>/dev/null >suidfiles.txt |
Эта команда создаст файл, содержащий список всех SUID/SGID-файлов.
Листинг 3: Список файлов с setuid |
/bin/su /bin/ping /bin/mount /bin/umount /var/qmail/bin/qmail-queue /usr/bin/chfn /usr/bin/chsh /usr/bin/crontab /usr/bin/chage /usr/bin/expiry /usr/bin/sperl5.6.1 /usr/bin/newgrp /usr/bin/passwd /usr/bin/gpasswd /usr/bin/procmail /usr/bin/suidperl /usr/lib/misc/pt_chown /usr/sbin/unix_chkpwd /usr/sbin/traceroute /usr/sbin/pwdb_chkpwd |
По умолчанию в Gentoo Linux не так много файлов с битом SUID (хотя это зависит от типа вашей установки), но у вас может получиться список, представленный выше. Большинство команд используется только суперпользователем. Удалите SUID-бит с ping, mount, umount, chfn, chsh, newgrp, suidperl, pt_chown и traceroute, запустив для каждого из них chmod -s. Не удаляйте бит с su, qmail-queue или unix_chkpwd. Удалив setuid с этих файлов, вы не сможете стать суперпользователем и получать почту. Удаляя бит (там, где это безопасно), вы исключаете возможность обычного пользователя (или злоумышленника) получить права суперпользователя с помощью этих файлов.
В моей системе есть только несколько SUID-файлов: su, passwd, gpasswd, qmail-queue, unix_chkpwd и pwdb_chkpwd. Но если у вас запущен X-сервер, то в вашей системе их будет больше, так как X нужны повышенные привелегии, которые могут быть предоставлены посредством SUID.
Файл может считаться удаленным лишь в том случае, когда нет больше ссылок, указывающих на него. Это может звучать странно, но просто следует понять, что файл (например, /usr/bin/perl) на самом деле является ссылкой на inode, в котором сохранены данные. На файл может указывать любое число ссылок, и пока каждая их них не будет удалена, файл будет существовать.
Если у ваших пользователей есть доступ к разделам, которые не смонтированы с параметрами nosuid или noexec (например, если /tmp, /home, /var/tmp не являются отдельными разделами), вы должны удостовериться, что они не смогут создать жесткие ссылки на файлы с SUID- или SGID-битами, благодаря чему они могут иметь доступ к устаревшим версиям файлов.
Предупреждение: Если вы получаете предупреждения об оставшихся жестких ссылках, а ваши пользователи имеют доступ по записи к разделам, позволяющим запускать файлы с SUID/SGID-битами, вы должны прочитать этот раздел очень внимательно. Любой из ваших пользователей может разрушить ваши обновления, сохранив устаревшую версию программы. Если ваши пользователи не могут создавать собственные файлы с битом SUID или могут только запускать программы с помощью динамического загрузчика (разделы, смонтированные с параметром noexec), то вам не о чем беспокоиться. |
Примечание: Пользователям не нужен доступ по чтению для файла, чтобы создать на него ссылку, им нужен всего лишь доступ по чтению к каталогу, содержащему этот файл. |
Чтобы проверить, сколько ссылок имеет файл, вы можете использовать команду stat.
Листинг 4: Команда stat |
$ stat /bin/su File: `/bin/su' Size: 29350 Blocks: 64 IO Block: 131072 regular file Device: 900h/2304d Inode: 2057419 Links: 1 Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-02-07 01:59:35.000000000 +0000 Modify: 2004-11-04 01:46:17.000000000 +0000 Change: 2004-11-04 01:46:17.000000000 +0000 |
Чтобы найти файлы с SUID и SGID со множеством ссылок, вы можете задействовать команду find.
Листинг 5: Поиск suid/sgid-файлов с несколькими ссылками |
$ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls |
PAM — это набор библиотек, предоставляющих альтернативный способ аутентификации пользователя в программах. USE-флаг pam уже включен по умолчанию. Хотя настройки PAM в Gentoo Linux довольно разумны, всегда есть возможность что-нибудь улучшить. Для начала установите cracklib.
Листинг 1: Установка cracklib |
# emerge cracklib |
Листинг 2: /etc/pam.d/passwd |
auth required pam_unix.so shadow nullok account required pam_unix.so password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=2 ocredit=2 password required pam_unix.so md5 use_authtok session required pam_unix.so |
После этого с помощью cracklib будет проверяться пароль пользователя, имеет ли он длину по крайней мере 8 символов, содержит ли он по крайней мере 2 цифры, 2 других символа и не менее 3 символов, отличающихся от символов прошлого пароля. Благодаря этому пользователь будет выбирать стойкие пароли. Проверьте документацию PAM для других параметров.
Листинг 3: /etc/pam.d/sshd |
auth required pam_unix.so nullok auth required pam_shells.so auth required pam_nologin.so auth required pam_env.so account required pam_unix.so password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=2 ocredit=2 use_authtok password required pam_unix.so shadow md5 session required pam_unix.so session required pam_limits.so |
Любая служба, не описанная в одном из файлов PAM из каталога /etc/pam.d, будет использовать правила, взятые из /etc/pam.d/other. По умолчанию установлена политика deny, как и должно быть. Но нам нужна регистрация, поэтому добавим pam_warn.so. Последняя конфигурация — это pam_limits, которая управляется с помощью /etc/security/limits.conf. См. раздел /etc/security/limits.conf для подробного описания этих настроек.
Листинг 4: /etc/pam.d/other |
auth required pam_deny.so auth required pam_warn.so account required pam_deny.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.so |
Обычно для контроля доступом к службам используется inetd (которого в Gentoo нет), но так же можно воспользоваться xinetd или другими сервисами.
Примечание: Служба должна быть запущена с помощью tcpd в качестве аргумента сервера (для случая xinetd). См. раздел о xinetd для большей информации. |
Листинг 1: /etc/hosts.deny |
ALL:PARANOID |
Листинг 2: /etc/hosts.allow |
ALL: LOCAL @wheel time: LOCAL, .gentoo.org |
Как вы видите, формат записи очень похож на содержимое файла /etc/login.access. Tcpd поддерживает отдельная служба; она никак не связана с /etc/login.access. Эти настройки применимы только для служб, использующих упаковщики TCP.
Также возможно запускать команды при разрешенной службе (это может быть полезным для создания трансляций для коммутируемых пользователей), но это не рекомендуется, так как обычно, решая одну проблему, люди создают еще больше. Допустим, что вы настроили сценарий, отправляющий электронное письмо в том случае, когда кто-то подпал под запрещающее правило, но тогда злоумышленник может запустить DoS-атаку, попадающую под правило запрещения. Из-за этого создастся много ввода-вывода и ненужно электронной почты, поэтому не делайте так! Прочтите man 5 hosts_access для дальнейшей информации.
Основное правило при конфигурации ядра — удалять все ненужное. Это не только создаст маленькое ядро, но и также исключит вероятные уязвимости, которые могут присутствовать в драйверах и других возможностях.
Также рекомендуется отключить поддержку загружаемых модулей. Хотя возможность внедрения руткитов сохраняется, это делает систему более неприступной для обычного злоумышленника, пытающегося установить руткит в виде модуля ядра.
Множество параметров ядра может быть изменено с помощью файловой системы /proc или sysctl.
Чтобы иметь возможность на лету изменять параметры и переменные ядра, вам понадобится определить в ядре CONFIG_SYSCTL. Она включена по умолчанию в ядрах серии 2.4.
Листинг 1: Отключения IP-форвардинга |
# /bin/echo "0" > /proc/sys/net/ipv4/ip_forward |
Проверьте, что проброс IP-пакетов отключен. Эта возможность необходима лишь для узла, имеющего доступ к нескольким сетям. Рекомендуется устанавливать и отключать этот флаг до включения или отключения других флагов.
Листинг 2: Отбрасывание пакетов ping |
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all |
Это просто заставит ядро игнорировать все сообщения ping (ICMP-пакеты типа 0). IP-пакет, несущий ICMP-сообщение, может содержать также в нагрузку и другую информацию, о которой вы можете не подозревать, поэтому следует отключить прием. Администраторы используют ping как утилиту диагностики и часто выражают недовольство, если она отключена, но нет причины позволять чужакам пинговать узел. Тем не менее, если необходимо разрешить внутренним пользователям использовать ping, то можно отключить сообщения ICMP типа 0 в межсетевом экране (тем самым позволив локальным администраторам использовать эту утилиту).
Листинг 3: Игнорирование широковещательных запросов ping |
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts |
Это отключает ответ на широковещательные ICMP-запросы, предотвращая реализацию Smurf-атаки. Smurf-атака основана на отправке ICMP-пакета типа 0 (ping) по широковещательному адресу сети. Обычно для этого злоумышленник использует поддельный адрес. Все компьютеры сети ответят на сообщение ping, что может вызвать наводнение трафика на узел, адрес которого был подделан.
Листинг 4: Отключение исходящих маршрутизированных пакетов. |
# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route |
Не принимать исходящие маршрутизированные пакеты. Злоумышленники могут использовать исходящую маршрутизацию для генерации трафика, имеющего адрес внутренней сети, но на самом деле возвращаемого назад злоумышленнику, что позволит ему компрометировать сеть. Исходящая маршрутизация очень редко используется по назначению, так что безопаснее ее отключить.
Листинг 5: Отключение приема перенаправлений |
# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects # /bin/echo "0" > /proc/sys/net/ipv4/conf/all/secure_redirects |
Не принимать ICMP-пакеты перенаправления. ICMP-перенаправления могут быть использованы злоумышленником для изменения таблиц маршрутизации.
Листинг 6: Защита против неправильных сообщений об ошибках |
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses |
Включить защиту против приходящих неправильных сообщений об ошибках.
Листинг 7: Включение фильтрации обратного пути |
# for i in /proc/sys/net/ipv4/conf/*; do /bin/echo "1" > $i/rp_filter done |
Включает фильтрацию обратного пути. Это поможет быть уверенным, что в пакетах используются правомерные адреса, при этом входящие пакеты будут автоматически отброшены, если запись в таблице маршрутизации об адресе этих пакетов не соответствуют сетевому интерфейсу, с которого они пришли. Это позволит предотвратить подделку IP-адресов. Необходимо включить эту возможность для каждого net/ipv4/conf/*, иначе проверка исходящих пакетов не будет полностью функционировать.
Предупреждение: Тем не менее включение фильтрации обратного пути может стать проблемой при использовании асимметричной маршрутизации (исходящие пакеты идут отличным от входящих пакетов путем) или при использовании немаршрутизируемом узле с несколькими IP-адресами на различных интерфейсах. |
Листинг 8: Регистрация всех поддельных, исходящих маршрутизированных и перенаправленных пакетов |
# /bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians |
Регистрировать поддельные пакеты, пакеты с исходящей маршрутизацией и пакеты перенаправлений.
Все настройки будут сброшены после перезагрузки компьютера. Рекомендуется добавлять их в /etc/sysctl.conf, который будет автоматически загружен сценарием инициализации /etc/init.d/bootmisc.
Синтаксис /etc/sysctl.conf достаточно понятный. Удалите из указанных путей /proc/sys/ и замените / на .:
Листинг 9: Переход к файлу sysctl.conf |
(Вручную с помощью команды echo:) /bin/echo "0" > /proc/sys/net/ipv4/ip_forward (Автоматически в файле sysctl.conf:) net.ipv4.ip_forward = 0 |
Заплатка от Grsecurity входит в sys-kernel/hardened-sources, но по умолчанию отключена. Сначала сконфигурируйте ядро, а затем настройте параметры Grsecurity. Подробное описание доступных параметров Grsecurity можно найти на странице проекта укрепленного Gentoo.
Последние версии hardened-sources содержат Grsecurity версии 2.*. Для дополнительной информации о наборе патчей Grsecurity обратитесь к документации, доступной на домашнем сайте Grsecurity.
Kerneli — это заплатка, которая добавляет функции шифрования к существующему ядру. Наложив эту заплатку на ядро, вы получите такие новые параметры, как алгоритмы шифрования, дайджеста и фильтры к зашифрованным образам.
Предупреждение: В настоящий момент заплатка kerneli для последнего ядра нестабильна, поэтому будьте осторожны при ее использовании. |
И множество других.
Apache поставляется с достаточно полным конфигурационным файлом по умолчанию, но опять же необходимо улучшить некоторые аспекты, например, использовать для Apache только один адрес. Ниже приведены параметры, которые вы должны внести в конфигурационный файл.
Если вы не отключали поддержку ssl в /etc/make.conf перед установкой Apache, то теперь вы должны иметь доступ к серверу с включенным SSL. Чтобы включить ее, просто добавьте следующую строку.
Листинг 1: /etc/conf.d/apache |
HTTPD_OPTS="-D SSL" |
Листинг 2: /etc/apache/conf/apache.conf |
#Добавьте свой IP для прослушивания Listen 127.0.0.1 BindAddress 127.0.0.1 #Не следует использовать nobody или nogroup для каждого сервиса, запущенного #без административных привелегий #(просто добавляем пользователя apache с группой apache) User apache Group apache #Не сообщать информацию о версии сервера ServerSignature Off ServerTokens Prod |
Apache собран с параметрами --enable-shared=max и --enable-module=all. По умолчанию это включает все модули, поэтому вы должны закомментировать все неиспользуемые модули в разделе LoadModule (LoadModule и AddModule). Затем перезапустите сервис, выполнив /etc/init.d/apache restart.
Документация доступна по адресу http://www.apache.org.
Документацию можно найти на сайте Internet Software Consortium. Руководство администратора BIND 9 также доступно каталоге doc/arm.
Новые сборочные файлы BIND поддерживают изменение корневого каталога из коробки. После установки bind следуйте этим простым инструкциям:
Листинг 3: Изолирование среды BIND |
# emerge --config bind (Перед запуском следующей команды вам может потребоваться изменить каталог chroot в файле /etc/conf.d/named. Иначе будет использован /chroot/dns.) |
Djbdns — это реализация DNS, за обнаружение уязвимостей в которой автор готов выплачивать деньги. Принцип работы сильно отличается от Bind 9, однако он работает. Дополнительная информация может быть получена на сайте http://www.djbdns.org.
В общем случае использование FTP (File Transfer Protocol, протокол передачи файлов) является плохой идеей. Этот протокол отправляет данные незашифрованными (в том числе и пароли), прослушивает 2 порта (обычно это порты 20 и 21), и часто злоумышленники ищут анонимный доступ для обмена варезом. Так как протокол содержит ряд проблем безопасности, то следует использовать sftp или HTTP. Если это невозможно, то максимально обезопасьте свои сервисы и будьте готовы.
Если вам необходимо предоставить доступ к базе данных mysql локальным приложениям, раскомментируйте следующую строку в /etc/mysql/my.cnf.
Листинг 4: Отключение доступа к сети |
skip-networking |
Затем мы отключаем использование команды LOAD DATA LOCAL INFILE. Это предотвратит несанкционированное чтение локальных файлов. Это также подходит против SQL-инъекций в PHP-сценариях.
Листинг 5: Отключение LOAD DATA LOCAL INFILE в разделе [mysqld] |
set-variable=local-infile=0 |
Затем необходимо удалить тестовую базу данных (test) и все учетные записи за исключением root.
Листинг 6: Удаление тестовой базы данных и всех ненужных пользователей |
mysql> drop database test; mysql> use mysql; mysql> delete from db; mysql> delete from user where not (host="localhost" and user="root"); mysql> flush privileges; |
Предупреждение: Если вас уже есть настроенные учетные записи, то будьте осторожны с этими командами. |
Примечание: Если вы изменяли пароли в командной строке MySQL, то всегда очищайте ~/.mysql_history и /var/log/mysql/mysql.log, так как они сохраняют список выполненных SQL-команд с открытыми паролями. |
У proftpd было несколько проблем с безопасностью, но большинство из них было исправлено. Тем не менее, неплохо внести некоторые улучшения:
Листинг 7: /etc/proftpd/proftpd.conf |
ServerName "My ftp daemon" # Не показывать ident сервера ServerIdent on "Go away" # Упрощаем создание виртуальных пользователей RequireValidShell off # Использовать альтернативные файлы паролей и групп (в формате passwd) AuthUserFile "/etc/proftpd/passwd" AuthGroupFile "/etc/proftpd/group" # Разрешения Umask 077 # Таймауты и ограничения MaxInstances 30 MaxClients 10 "Only 10 connections allowed" MaxClientsPerHost 1 "You have already logged on once" MaxClientsPerUser 1 "You have already logged on once" TimeoutStalled 10 TimeoutNoTransfer 20 TimeoutLogin 20 # Все входят в изолированную оболочку DefaultRoot ~ # Не запускать с правами администратора User nobody Group nogroup # Регистрировать любые передачи TransferLog /var/log/transferlog # Проблемы с универсализацией имен файлов DenyFilter \*.*/ |
Дополнительная информация может быть найдена на http://www.proftpd.org.
Pure-ftpd является ответвлением оригинального trollftpd с модификациями Фрэнка Денниса по части безопасности и функциональности.
Используйте виртуальных пользователей (и никогда не применяйте системные учетные записи), включив параметр AUTH. Установите его для -lpuredb:/etc/pureftpd.pdb и создайте пользователей при помощи команды /usr/bin/pure-pw.
Листинг 8: /etc/conf.d/pure-ftpd |
AUTH="-lpuredb:/etc/pureftpd.pdb" ## Misc. Others ## MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15" |
Добавьте к переменной MISC_OTHER параметры запрета на подключение анонимных пользователей (-E), изменения корневого каталога для всех (-A), запрета записи и чтения файлов, начинающихся с точки (-X), максимального периода бездействия (-I), ограничения рекурсии (-L) и подходящего umask.
Предупреждение: Не используйте параметры -w или -W! Если же вы хотите, чтобы у вас был сайт с варезом, то перестаньте читать это руководство! |
Дополнительная информация может быть найдена на http://www.pureftpd.org.
Vsftpd (сокращение от very secure ftp) — это небольшой FTP-демон, который может запускаться с настройками по умолчанию. Он прост и не имеет множества возможностей, присущих pureftp и proftp.
Листинг 9: /etc/vsftpd |
anonymous_enable=NO local_enable=YES #read only write_enable=NO #enable logging of transfers xferlog_std_format=YES idle_session_timeout=20 data_connection_timeout=20 nopriv_user=nobody chroot_list_enable=YES chroot_list_file=/etc/vsftpd/chrootlist ls_recurse_enable=NO |
Как вы можете видеть, нет возможности установить для данного сервиса индивидуальные разрешения, но если используется настройки для анонимного доступа, то это он не так уж плох. Иногда неплохо иметь анонимный FTP-сервер (для доступа к открытому ПО), и vsftpd неплохо подходит для этой работы.
Netqmail часто признается наиболее безопасным почтовым сервером. Он написан с прицелом на безопасность (и паранойю). По умолчанию он не разрешает релей и, начиная с 1996 года, не имеет никаких уязвимостей безопасности. Просто наберите emerge netqmail и настройте его!
Samba — это протокол, предоставляющий файлы в сетях Microsoft/Novell, и он не должен использоваться в интернете. Его необходимо обезопасить.
Листинг 10: /etc/samba/smb.conf |
[global] #Прослушивать определенный интерфейс interfaces = eth0 10.0.0.1/32 #Использовать зашифрованные пароли encrypt passwords = yes directory security mask = 0700 #Разрешить трафик из подсети 10.0.0.* hosts allow = 10.0.0. #Включить аутентификацию #(не используйте режим share) security = user #Запретить привелигерованные учетные записи invalid users = root @wheel #Максимальный отображаемый размер ресурса (не является ограничителем) max disk size = 102400 #Ужесточить политики паролей min password length = 8 null passwords = no #Использовать PAM (если была добавлена поддержка) obey pam restrictions = yes pam password change = yes |
Проверьте, что для каждого ресурса выставлены правильные разрешения и не забудьте прочитать документацию.
Теперь перезапустите сервер и добавьте пользователей, которым необходим доступ к этому сервису. Это можно сделать с помощью команды /usr/bin/smbpasswd с параметром -a.
Для OpenSSH необходимо лишь одно улучшение — использование более надежного механизма аутентификации, основанного на шифровании с использованием открытого ключа. Очень много сайтов (например, http://www.sourceforge.net, http://www.php.net и http://www.apache.org) было подвержено несанкционированному доступу из-за пустых или слабых паролей.
Листинг 11: /etc/ssh/sshd_config |
#Включаем только версию 2 Protocol 2 #Отключаем вход администратора. Пользователи могут использовать su для входа PermitRootLogin no #Включаем аутентификацию по открытому ключу PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys #Отключаем .rhost и обычную аутентификацию по паролю HostbasedAuthentication no PasswordAuthentication no PermitEmptyPasswords no #Разрешаем подключаться только пользователям из групп wheel или admin AllowGroups wheel admin #Из этих групп разрешаем подключаться только следующим пользователям #@<domainname> не обязательна, но заменяет старую директиву #AllowHosts AllowUsers kn@gentoo.org bs@gentoo.org #Вход в систему SyslogFacility AUTH LogLevel INFO (Измените адрес на свой) ListenAddress 127.0.0.1 |
Также проверьте, что в конфигурационном файле нет параметра UsePAM yes, который перекрывает механизм аутентификации с помощью открытого ключа.
Теперь создайте для каждого пользователя ключ (на компьютере, с которого они будут регистрироваться) с помощью следующей команды:
Листинг 12: Создание пар ключей DSA |
# /usr/bin/ssh-keygen -t dsa |
И введите пароль.
Листинг 13: Вывод ssh-keygen |
Generating public/private dsa key pair. Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Press enter] Created directory '/home/kn/.ssh'. Enter passphrase (empty for no passphrase): [Enter passphrase] Enter same passphrase again: [Enter passphrase again] Your identification has been saved in /home/kn/.ssh/id_dsa. Your public key has been saved in /home/kn/.ssh/id_dsa.pub. The key fingerprint is: 07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen |
После этого в каталоге ~/.ssh/ появятся два файла с названием id_dsa и id_dsa.pub. Файл id_dsa является секретным ключом и должен оберегаться от других. Другой файл, id_dsa.pub, должен быть размещен на каждом сервере, к которому необходим доступ. Добавьте этот ключ в каталог ~/.ssh/authorized_keys в домашнем каталоге пользователя. Теперь пользователь должен иметь доступ к подключению:
Листинг 14: Adding the id_dsa.pub file to the authorized_keys file |
$ scp id_dsa.pub other-host:/var/tmp/currenthostname.pub $ ssh other-host password: $ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys |
Теперь ваши пользователи должны тщательно оберегать свои секретные ключи. Поместите их на сменный носитель, который они будут всегда носить с собой, или спрячьте их на рабочих станциях пользователей (поместите их под правила паролей).
Для дальнейшей информации посетите веб-сайт OpenSSH.
xinetd является заменой inetd (которого в Gentoo нет), демона сетевых сервисов. Он поддерживает контроль доступа, основанный на адресе удаленного узла и времени доступа. Он также предоставляет расширенные возможности регистрации событий, включая время запуска сервера, адрес удаленного узла, имя удаленного пользователя, время работы сервера и выполненные запросы.
Как в случае с другими сервисами, важно создать хорошую конфигурацию по умолчанию. Но так как xinetd запускается с правами администратора и поддерживает протоколы, о работе которых вы можете не знать, рекомендуется не использовать его. Но если вы все равно хотите использовать его, то вы можете укрепить его безопасность:
Листинг 15: Установка xinetd |
# emerge xinetd tcp-wrappers |
И отредактируйте конфигурационный файл:
Листинг 16: /etc/xinetd.conf |
defaults { only_from = localhost instances = 10 log_type = SYSLOG authpriv info log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } # Это установит работу pserver (cvs) через xinetd со следующими: # настройками: # максимум 10 обработчиков (10 подключений одновременно) # использовать только TCP # использовать пользователя cvs для запуска сервиса # использовать только 1 IP # разрешать доступ с 10.0.0.* # разработчики могут пользоваться cvs только с 8 до 17 часов # использовать упаковщики tpcd (контроль доступа через # /etc/hosts.allow и /etc/hosts.deny) # max_load для компьютера 1.0 # Отключающий флаг для настроек по умолчанию, я предпочитаю, # чтобы он был отключен service cvspserver { socket_type = stream protocol = tcp instances = 10 protocol = tcp wait = no user = cvs bind = 10.0.0.2 only_from = 10.0.0.0 access_times = 8:00-17:00 server = /usr/sbin/tcpd server_args = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver max_load = 1.0 log_on_failure += RECORD disable = no } |
Для большей информации см. man 5 xinetd.conf.
По умолчанию Xorg настроен функционировать в качестве Xserver. Это может быть опасным, так как X использует не зашифрованные TCP-соединения и прослушивает подключения xclient.
Важно: Если вам не нужен этот сервис, отключите его! |
Но если вам требуется использовать рабочую станцию в качестве X-сервера, используйте команду /usr/X11R6/bin/xhost с большой осторожностью. Эта команда позволит клиентам других узлов подключаться к вашему экрану. Это может быть полезно при необходимости запуска приложения X с другого компьютера, и это возможно лишь через сеть, но это может быть использовано и злоумышленником. Синтаксис этой команды — /usr/X11R6/bin/xhost +hostname.
Предупреждение: Не используйте возможность xhost +! Эта возможность позволит любому клиенту подключиться к X-серверу и взять контроль над ним. Если злоумышленник может получить доступ к X, то сможет регистрировать нажатия на клавиши, что позволит ему взять контроль над вашим компьютером. Если вы все же используете ее, то всегда указывайте узел. |
Более безопасным решением является полное отключение этой возможности при старте X-сервера с помощью startx -- -nolisten tcp или отключение ее навсегда в файлах конфигурации.
Листинг 17: /usr/X11R6/bin/startx |
defaultserverargs="-nolisten tcp" |
Вы должны защитить startx, чтобы не допустить его перезаписи при установке новой версии Xorg. Добавьте следующую строку в /etc/make.conf:
Листинг 18: /etc/make.conf |
CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx" |
Если вы используете графический диспетчер входа в систему, вам понадобится другой подход.
Для gdm (Gnome Display Manager)
Листинг 19: /etc/X11/gdm/gdm.conf |
[server-Standard] command=/usr/X11R6/bin/X -nolisten tcp |
Для xdm (X Display Manager) и kdm (Kde Display Manager)
Листинг 20: /etc/X11/xdm/Xservers |
:0 local /usr/bin/X11/X -nolisten tcp |
Изменение корневого каталога для службы является способом ограничения среды службы (или пользователя), в которой она имеет доступ лишь к необходимым ресурсам. Запущенная служба под пользователем, отличном от суперпользователя (nobody, apache, named) может предоставить злоумышленнику доступ лишь к тем файлам, к которым имеет доступ пользователь, от имени которого запущена служба. Это означает, что злоумышленник не сможет получить права root, даже если служба подвержена различным уязвимостям.
Некоторые службы, например pure-ftpd и bind, могут быть заключены в chroot. Если служба поддерживает эту возможность, используйте ее, иначе вы можете можете создать среду собственноручно. Давайте рассмотрим пример создания chroot. Чтобы изучить работу механизма chroot, мы будем экспериментировать с bash (простейший для изучения случай).
Создайте каталог /chroot, выполнив команду mkdir /chroot. Затем определите, какие динамические библиотеки необходимы для работы bash (если он собран с параметром -static, этот шаг можно пропустить):
Следующая команда создаст список библиотек, необходимых для bash.
Листинг 1: Получение списка используемых библиотек |
# ldd /bin/bash libncurses.so.5 => /lib/libncurses.so.5 (0x4001b000) libdl.so.2 => /lib/libdl.so.2 (0x40060000) libc.so.6 => /lib/libc.so.6 (0x40063000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) |
Теперь создадим изолированную среду для bash.
Листинг 2: Создание изолированной среды для bash |
# mkdir /chroot/bash # mkdir /chroot/bash/bin # mkdir /chroot/bash/lib |
Затем скопируем файлы, используемые bash (/lib) в изолированный lib и скопируем файл bash в изолированный каталог bin. Этим мы создадим ту же самую среду, но с ограниченными возможностями. После этого попробуйте выполнить команду chroot /chroot/bash /bin/bash. Если вы получите строку приглашения, гласящую /, то у вас все получилось! Иначе вам сообщат, какого файла не хватает. Некоторые разделяемые библиотеки могут использовать другие файлы.
Как вы можете заметить, внутри изолированной среды ничего, кроме echo, не работает. Это потому что в внутри среды chroot кроме bash нет никаких других команд, а echo является встроенной командой.
Подобным образом вы можете создать службу в изолированной среде. Единственное различие в том, что служба может время от времени обращаться к устройствам и файлам настроек в /etc. Просто скопируйте их (файлы устройств можно скопировать с помощью команды cp -a) в изолированную среду, отредактируйте сценарий инициализации перед тем, как заключить службу в среду. Может быть сложным определить, какие устройства и файлы конфигурации могут понадобиться. Здесь может пригодиться команда strace. Запустите службу вместе с /usr/bin/strace и отследите все вызовы open, read, stat и, возможно, connect. Это подскажет вам, что нужно копировать. Но в большинстве случаев вам понадобится скопировать файл passwd (отредактируйте копию, удалив из него всех пользователей, не нужных для запуска службы), /dev/zero, /dev/log и /dev/random.
Другим способом создания безопасной среды является запуск виртуальной машины. Виртуальная машина — это процесс, выглядящий как отдельная ОС и работающий в реальной операционной системе, которая предоставляет ему необходимые системные ресурсы. Безопасность достигается в том, что если сервер, запущенный внутри виртуальной машины, будет взломан, то будет затронут только виртуальный сервер, а не родительская установка.
Для дальнейшей информации по установке пользовательского режима Linux, обратитесь к руководству по пользовательскому режиму Linux.
Люди часто думают, что межсетевой экран окончательно защитит их систему, но они ошибаются. В большинстве случаев плохо настроенный межсетевой экран предоставляет еще меньше безопасен, чем его отсутствие. Он тоже является программой, и с ним нужно обращаться так же, как и с остальными программами, так как он может содержать уязвимости.
А теперь подумайте перед реализацией межсетевого экрана! Так ли он вам нужен? Если да, то вам нужно написать правила, определяющие его работу, тип межсетевого экрана и кто должен им управлять. Но сначала прочитайте это руководство.
Межсетевые экраны используются для двух целей:
Для защиты извне (черви/злоумышленники)
Для защиты изнутри (сотрудники/дети)
В основном есть три типа межсетевых экранов:
Фильтрование пакетов
Прокси
Программный шлюз
Межсетевой экран должен работать на выделенном компьютере без лишних запущенных сервисов (или же только с sshd) и обезопасен такими способами, которые описаны в этом руководстве.
Весь сетевой трафик передается в виде пакетов. Непрерывный поток разделяется на маленькие, легко управляемые пакеты, которые собираются в точке назначения. В заголовке каждого пакета содержится информация о способе и месте его назначения. Также эта информация используется работы межсетевого экрана. Фильтрация основана на:
разрешении или запрещении пакетов на основании IP-адреса отправителя/получателя
разрешении или запрещении пакетов на основании порта отправителя/получателя
разрешении или запрещении пакетов на основании протокола
разрешении или запрещении пакетов на основании параметров, специфичных для каждого из протоколов
Другими словами, фильтрация основана на содержимом заголовка пакета, а не самого пакета.
Недостатки:
адрес в пакете может быть ненастоящим адресом IP (или подделанным отправителем)
данные или запросы в пропущенном пакете могут содержать непредвиденные данные, которые злоумышленник может использовать для эксплуатации известных уязвимостей в сервисах, расположенным на межсетевом экране или позади него
критично к сбоям
Преимущества:
простая реализация
возможность отправки предупреждений о возможных атаках до того, как они произойдут (то есть регистрация сканирования портов)
хорош против предотвращения SYN-атак
Вот примеры свободных фильтров пакетов для Linux:
Примечание: Рекомендуется использовать iptables. ipchains устарел. |
Шлюз сеансового уровня является межсетевым экраном, проверяющим соединения перед разрешением обмена данных. Это значит, что он не только разрешает или запрещает пересылку пакетов на основании их заголовка, но и определяет перед открытием сессии на основании настраиваемых правил, что оба адресата реально существуют. Фильтрация основывается на:
IP-адресе отправителя/получателя
порте отправителя/получателя
времени
протоколе
пользователе
пароле
Весь трафик прослушивается и проверяется, и непрошенный трафик может быть отброшен.
Недостатки:
Взаимодействует на транспортном уровне и может потребовать изменения программ, предоставляющих транспортные функции.
Шлюзы уровня приложений являются прокси-серверами для приложений, обменивающимися вместо клиентов данными с удаленными системами. Это позволяет находиться вне доступа извне за ДМЗ (демилитаризованной зоной, частью частной сети, видимой сквозь межсетевой экран) или разрешать межсетевому экрану предотвращать соединения извне. Фильтрация основывается на:
разрешении или запрещении на основании IP-адреса источника/назначения
на содержимом пакетов
ограничения доступа к файлу на основе типа файла и расширения
Преимущества:
Может кэшировать файлы, увеличивая производительность сети
Детализированная регистрация всех подключений
Хорошая расширяемость (некотрые прокси могут распределять кэшированные данные между собой)
Нет прямого доступа извне
Может изменять содержимое пакета на лету
Недостатки:
Конфигурация является комплексной
Программные шлюзы принято считать наиболее безопасным решением, так как они не запускаются с правами администратора, и все узлы за ними будут недоступными из интернета.
Пример свободного шлюза:
Для нормального функционирования iptables должен быть включен в ядро. Я включил поддержку iptables модулей (команда iptables загрузит их по мере необходимости) и пересобрал ядро (но вы можете включить их в само ядро, если намереваетесь отказаться от загружаемых модулей ядра, как сказано выше). Для более детальной информации по настройке iptables в ядре обратитесь к странице Iptables Tutorial Chapter 5: Preparations. После пересборки нового ядра (или во время компиляции) вы должны добавить команду iptables. Для этого просто наберите emerge iptables.
Теперь проверим свою работу, запустив iptables -L. Если команда завершилась ошибкой, значит, что-то не так, поэтому проверьте еще раз настройки.
iptables — новый и весьма улучшенный межсетевой экран в ядрах Linux 2.4.x. Он является наследником ipchains для ядер Linux 2.2.x. Одним из значительных нововведений является то, что iptables способен совершать полноценную фильтрацию пакетов. С ее помощью стало возможным следить за каждым установленным TCP-соединением.
TCP-соединение содержит в себе серию пакетов, содержащих информацию IP-адресе и порте отправителя и получателя, а также последовательное число, поэтому пакеты могут быть воссозданы без потери данных. TCP является протоколом, ориентированном на подключение, в отличии от UDP, который не гарантирует доставку.
Изучая заголовок TCP-пакета, межсетевой экран может может определить, является ли полученный пакет частью уже установленного соединения или нет, и принять решение, принять или отбросить этот пакет.
При использовании межсетевого экрана, не отслеживающего соединения, возможно провести его и заставить с помощью манипулирования заголовками TCP-пакета принимать пакеты, которые необходимо отбросить. Это может быть сделано с помощью установки SYN или других флагов заголовка TCP и создания поддельного пакета, который будет считаться частью уже установленного соединения (ведь межсетевой экран не будет отслеживать состояние соединения). При использовании фильтрации пакетов, отслеживающих соединения, можно отбрасывать подобные пакеты, если они не являются частью уже установленного соединения. Это также предотвратит «stealth-сканирование», разновидности сканирования, с помощью которого сканер отправляет пакеты с такой комбинацией флагов, при которых они не будут зарегистрированы межсетевым экраном, полагающим, что это — обычные SYN-пакеты.
В iptables также есть различные возможности, как например NAT (Network Address Translation, сетевая трансляция адресов) и ограничения по частоте. Ограничение по частоте весьма полезна для предотвращения DoS-атак (Denial of Service, отказ от обслуживания), например SYN-наводнений.
TCP-соединения устанавливаются после так называемого троекратного рукопожатия. При установлении TCP-соединения клиент отправляет серверу пакет с установленным флагом SYN. При получении сервер возвращает клиенту пакет с установленными SYN+ACK. При его получении клиент отвечает третьим пакетом с ACK для подтверждения соединения.
SYN-наводнения основаны на отправке SYN-пакетов с одновременным запретом отправки пакетов SYN+ACK. Клиент может создать пакет с поддельным IP-адресом отправителя, так как ему не нужно на что-либо отвечать. Сервер заполнит очередь подключений полуоткрытыми соединениями, ожидающими окончательного пакета с ACK, до того, как удалит их из очереди. Очередь ограничена определенным числом, и когда она заполнится, то станет невозможным принимать новые подключения. Если пакет с ACK не будет получен по истечении определенного временного интервала, то он будет автоматически удален из очереди. Настройки таймаута могут быть различными, но обычно они находятся в пределах 30—60 секунд или даже больше. Клиент инициирует атаку, создавая множество SYN-пакетов с различных IP-адресов и отправляя их на адрес цели как можно чаще, заполняя тем самым очередь полуоткрытыми соединениями и не позволяя другим клиентам устанавливать легитимные подключения к серверу.
В данном случае может быть полезным ограничение отправки. Можно ограничить частоту отправки принятых SYN-пакетов с помощью -m limit --limit 1/s, тем самым ограничив число SYN-пакетов до одного в секунду и оградив свои ресурсы от SYN-наводнений.
Примечание: Другим решением, предотвращающим SYN-наводнения является использование SYN cookies, которые позволят вашему компьютеру отвечать на SYN-пакеты без заполнения очереди подключений. SYN cookies могут быть включены при конфигурировании ядра Linux, однако на данный момент эта поддержка считается экспериментальной. |
А теперь немного практических занятий!
Будучи загруженным в ядро, iptables предоставляет 5 ловушек, в которые вы можете поместить свои правила. Они называются INPUT, OUTPUT, FORWARD, PREROUTING и POSTROUTING. Каждая из них называется цепочкой и содержит список правил. Каждое правило описывает, что если заголовок пакета выглядит как образец, то делать с этим пакетом нужно то-то и то-то. Если правило не подходит под пакет, то пакет переходит к следующему правилу в цепочке.
Вы можете поместить правила в 5 цепочках напрямую или создать новые цепочки и добавлять в них правила таким же способом, как и в обычную цепочку. Iptables поддерживает следующие параметры.
Параметр: |
Описание: |
-A |
Добавление |
-D |
Удаление |
-I |
Вставка |
-R |
Замена |
-L |
Просмотр |
-F |
Удалить все правила в цепочке или все цепочки |
-Z |
Обнулить счетчики во всех цепочках |
-C |
Проверить этот пакет в цепочке |
-N |
Создать новую пользовательскую цепочку |
-X |
Удалить пользовательскую цепочку |
-P |
Изменить политику цепочки для цели |
-E |
Изменить имя цепочки |
-p |
протоколе |
-s |
Адрес/маска источника |
-d |
Адрес/маска назначения |
-i |
Входящее имя (имя ethernet) |
-o |
Исходящее имя (имя ethernet) |
-j |
Перейти (цель для правила) |
-m |
Расширенные сравнения (могут использовать внешние расширения) |
-n |
Числовой вывод адресов и портов |
-t |
Таблица для обработки |
-v |
Расширенный режим |
-x |
Расширить числа (вывести все значения) |
-f |
Проверять только второй и последующие фрагменты |
-V |
Версия пакета |
--line-numbers |
Указывать номера строк при выводе |
Сначала попробуем заблокировать все ICMP-пакеты, идущие на наш компьютер, просто для того, чтобы познакомиться с iptables поближе.
Листинг 1: Блокировка всех пакетов ICMP |
# iptables -A INPUT -p icmp -j DROP |
Сначала мы указываем цепочку, в которую хотим поместить правило, затем протокол проверяемого пакета и в конце цель. Цель может быть именем пользовательской цепочки или одной из специальных целей — ACCEPT, DROP, REJECT, LOG, QUEUE или MASQUERADE. В случае, если мы укажем DROP, то пакет будет отброшен без уведомления клиента.
Примечание: LOG является «необрывающей» целью. Если пакет подпадает под правило с целью LOG, то он будет передан следующему правилу в цепочке, а не обработан только этим правилом. Это позволяет регистрировать пакеты и при этом их обрабатывать. |
Теперь попробуйте выполнить ping localhost. Вы не должны получить ответа, так как iptables будет отбрасывать все входящие ICMP-сообщения. Вы также не сможете проверить и другие компьютеры, так как ответные ICMP-пакеты тоже будут отбрасываться. А теперь, чтобы вновь получать ICMP, очистим цепочку.
Листинг 2: Сбросить все правила |
# iptables -F |
Теперь взглянем на полноценную фильтрацию пакетов с помощью iptables. Если нужно полноценное исследование входящих пакетов на интерфейсе eth0, то выполним следующую команду:
Листинг 3: Принимать пакеты от уже установленных соединений |
# iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT |
Это разрешит принимать любой пакет из уже установленного соединения или связанного в цепочке INPUT. Вы можете отбросить любой пакет, не соответствующий состоянию таблицы, выполнив команду iptables -A INPUT -i eth0 -m state --state INVALID -j DROP сразу же после предыдущей. Эта команда включит фильтрацию пакетов на основании состояния, подключив внешнее расширение «state». Если вам необходимо разрешить подключаться клиентам к компьютеру, то вы можете использовать флаг --state NEW. Iptables содержит несколько модулей различного назначения. Вот некоторые из них:
Модуль/сравнение |
Описание |
Расширенные параметры |
mac |
Расширение для проверки MAC-адресов входящих пакетов. |
--mac-source |
state |
Включение проверки состояния соединения |
--state (состоянием может быть ESTABLISHED,RELATED, INVALID, NEW) |
limit |
Частотное ограничение |
--limit, --limit-burst |
owner |
Попытка проверить различные характеристики создателя пакета |
--uid-owner userid --gid-owner groupid --pid-owner processid --sid-owner sessionid |
unclean |
Различные случайны проверки пакетов на правильность |
Теперь попробуем создать пользовательскую цепочку и применить ее для одного из существующих:
Листинг 4: Создание пользовательской цепочки |
(Создаем новую цепочку с одним правилом) # iptables -X mychain # iptables -N mychain # iptables -A mychain -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT (Разрешающая политика по умолчанию для всего исходящего трафика. Входящий будет отброшен.) # iptables -P OUTPUT ACCEPT # iptables -P INPUT DROP (И добавление ее в цепочку INPUT) # iptables -A INPUT -j mychain |
Применив правило к входящей цепочке, мы получим следующую политику: все исходящие пакеты будут пропущены, а все входящие — отброшены.
Документация может быть найдена по адресу Netfilter/iptables documentation.
Теперь взглянем на полный пример. Мои правила для межсетевого экрана/шлюза будут следующими:
Подключения к межсетевому экрану разрешены только через SSH (порт 22)
Локальная сеть должна иметь доступ к HTTP, HTTPS и SSH (также должен быть разрешен DNS)
ICMP может содержать постороннюю информацию и не должен быть разрешен. Конечно же, мы разрешаем некоторые ICMP-сообщения.
Сканирование портов должно быть определено и зарегистрировано
SYN-атаки должны быть пресечены
Весь остальной трафик должен быть отброшен и запротоколирован
Листинг 5: /etc/init.d/firewall |
#!/sbin/runscript IPTABLES=/sbin/iptables IPTABLESSAVE=/sbin/iptables-save IPTABLESRESTORE=/sbin/iptables-restore FIREWALL=/etc/firewall.rules DNS1=212.242.40.3 DNS2=212.242.40.51 #inside IIP=10.0.0.2 IINTERFACE=eth0 LOCAL_NETWORK=10.0.0.0/24 #outside OIP=217.157.156.144 OINTERFACE=eth1 opts="${opts} showstatus panic save restore showoptions rules" depend() { need net } rules() { stop ebegin "Setting internal rules" einfo "Setting default rule to drop" $IPTABLES -P FORWARD DROP $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP #default rule einfo "Creating states chain" $IPTABLES -N allowed-connection $IPTABLES -F allowed-connection $IPTABLES -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A allowed-connection -i $IINTERFACE -m limit -j LOG --log-prefix \ "Bad packet from ${IINTERFACE}:" $IPTABLES -A allowed-connection -j DROP #ICMP traffic einfo "Creating icmp chain" $IPTABLES -N icmp_allowed $IPTABLES -F icmp_allowed $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ time-exceeded -j ACCEPT $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ destination-unreachable -j ACCEPT $IPTABLES -A icmp_allowed -p icmp -j LOG --log-prefix "Bad ICMP traffic:" $IPTABLES -A icmp_allowed -p icmp -j DROP #Incoming traffic einfo "Creating incoming ssh traffic chain" $IPTABLES -N allow-ssh-traffic-in $IPTABLES -F allow-ssh-traffic-in #Flood protection $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL RST --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL FIN --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ ALL SYN --dport ssh -j ACCEPT $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT #outgoing traffic einfo "Creating outgoing ssh traffic chain" $IPTABLES -N allow-ssh-traffic-out $IPTABLES -F allow-ssh-traffic-out $IPTABLES -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT einfo "Creating outgoing dns traffic chain" $IPTABLES -N allow-dns-traffic-out $IPTABLES -F allow-dns-traffic-out $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \ -j ACCEPT $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \ -j ACCEPT einfo "Creating outgoing http/https traffic chain" $IPTABLES -N allow-www-traffic-out $IPTABLES -F allow-www-traffic-out $IPTABLES -A allow-www-traffic-out -p tcp --dport www -j ACCEPT $IPTABLES -A allow-www-traffic-out -p tcp --dport https -j ACCEPT #Catch portscanners einfo "Creating portscan detection chain" $IPTABLES -N check-flags $IPTABLES -F check-flags $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \ --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:" $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit \ 5/minute -j LOG --log-level 1 --log-prefix "XMAS:" $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -j DROP $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \ -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:" $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -m limit \ --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:" $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -j DROP $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit \ --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:" $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \ --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:" $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP # Apply and add invalid states to the chains einfo "Applying chains to INPUT" $IPTABLES -A INPUT -m state --state INVALID -j DROP $IPTABLES -A INPUT -p icmp -j icmp_allowed $IPTABLES -A INPUT -j check-flags $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A INPUT -j allow-ssh-traffic-in $IPTABLES -A INPUT -j allowed-connection einfo "Applying chains to FORWARD" $IPTABLES -A FORWARD -m state --state INVALID -j DROP $IPTABLES -A FORWARD -p icmp -j icmp_allowed $IPTABLES -A FORWARD -j check-flags $IPTABLES -A FORWARD -o lo -j ACCEPT $IPTABLES -A FORWARD -j allow-ssh-traffic-in $IPTABLES -A FORWARD -j allow-www-traffic-out $IPTABLES -A FORWARD -j allowed-connection einfo "Applying chains to OUTPUT" $IPTABLES -A OUTPUT -m state --state INVALID -j DROP $IPTABLES -A OUTPUT -p icmp -j icmp_allowed $IPTABLES -A OUTPUT -j check-flags $IPTABLES -A OUTPUT -o lo -j ACCEPT $IPTABLES -A OUTPUT -j allow-ssh-traffic-out $IPTABLES -A OUTPUT -j allow-dns-traffic-out $IPTABLES -A OUTPUT -j allow-www-traffic-out $IPTABLES -A OUTPUT -j allowed-connection #Allow client to route through via NAT (Network Address Translation) $IPTABLES -t nat -A POSTROUTING -o $OINTERFACE -j MASQUERADE eend $? } start() { ebegin "Starting firewall" if [ -e "${FIREWALL}" ]; then restore else einfo "${FIREWALL} does not exists. Using default rules." rules fi eend $? } stop() { ebegin "Stopping firewall" $IPTABLES -F $IPTABLES -t nat -F $IPTABLES -X $IPTABLES -P FORWARD ACCEPT $IPTABLES -P INPUT ACCEPT $IPTABLES -P OUTPUT ACCEPT eend $? } showstatus() { ebegin "Status" $IPTABLES -L -n -v --line-numbers einfo "NAT status" $IPTABLES -L -n -v --line-numbers -t nat eend $? } panic() { ebegin "Setting panic rules" $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -P FORWARD DROP $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT eend $? } save() { ebegin "Saving Firewall rules" $IPTABLESSAVE > $FIREWALL eend $? } restore() { ebegin "Restoring Firewall rules" $IPTABLESRESTORE < $FIREWALL eend $? } restart() { svc_stop; svc_start } showoptions() { echo "Usage: $0 {start|save|restore|panic|stop|restart|showstatus}" echo "start) will restore setting if exists else force rules" echo "stop) delete all rules and set all to accept" echo "rules) force settings of new rules" echo "save) will store settings in ${FIREWALL}" echo "restore) will restore settings from ${FIREWALL}" echo "showstatus) Shows the status" } |
Вот несколько советов при создании правил для межсетевого экрана:
Создайте политику межсетевого экрана до того, как ее реализуете
Сделайте ее простой
Знайте принцип работы каждого протокола (прочитайте подходящий RFC)
Всегда помните, что межсетевой экран — это просто программа, запускаемая с правами администратора.
Проверьте свой межсетевой экран
Если вам кажется, что iptables труден для понимания или нужно слишком много времени для настройки межсетевого экрана, то вы можете попробовать Shorewall. Для генерации правил межсетевого экрана он использует iptables, но акцентируется на правилах и не указывает протокол.
Squid является очень хорошим прокси-сервером. Он может фильтровать трафик на основании времени, регулярных выражений в пути/URI, IP-адреса получателя и отправителя, домена, браузера, имени зарегистрированного пользователя, типа MIME и номера порта (протокола). Некоторые возможности не указаны, но трудно перечислить их всех.
В следующем примере я добавил фильтр баннеров вместо фильтра, основанного на фильтрации порносайтов. По этой причине gentoo.org не должен быть перечислен в списке порносайтов. И я не собираюсь тратить свое время на поиски хороших сайтов для вас.
В данном случае, вот мои правила:
Веб-серфинг (HTTP/HTTPS) разрешен только в рабочее время (с понедельника по пятницу с 8 до 17 часов и в субботу с 8 до 13 часов), но если служащие остаются, то они должны работать, а не сидеть в интернете.
Скачивание файлов не разрешено (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg и так далее)
Нам не нужны баннеры, поэтому они будут отфильтрованы и заменены на прозрачный GIF (здесь пригодится ваша креативность!).
Все остальные подключения в/из Интернета запрещены.
Все это реализуется в 4 простых шага.
Листинг 6: /etc/squid/squid.conf |
# Указываем IP и порт http_port 10.0.2.1:3128 # Стандартная конфигурация hierarchy_stoplist cgi-bin ? acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY # Добавляем основные списки контроля доступа acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 # Добавляем тех, кто может пользоваться прокси acl localnet src 10.0.0.0/255.255.0.0 # Добавляем порты acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl purge method PURGE # Добавляем список контроля доступа, основанного на регулярных # выражениях, встречаемых в URL acl archives urlpath_regex "/etc/squid/files.acl" acl url_ads url_regex "/etc/squid/banner-ads.acl" # Добавляем список контроля доступа, основанного на времени и дате acl restricted_weekdays time MTWHF 8:00-17:00 acl restricted_weekends time A 8:00-13:00 acl CONNECT method CONNECT # Разрешаем менеджеру подключаться с localhost http_access allow manager localhost http_access deny manager # Разрешать очищать запросы только с localhost http_access allow purge localhost http_access deny purge # Запрещать запросы на неизвестные порты http_access deny !Safe_ports # Запрещать подключение к портам, не относящимся к SSL http_access deny CONNECT !SSL_ports # Мои собственные правила # Добавляем страницу, отображаемую на месте # удаленного баннера deny_info NOTE_ADS_FILTERED url_ads # Запрещаем баннеры http_access deny url_ads # Запрещаем любые архивы http_access deny archives # Ограничиваем доступ в рабочим временем http_access allow localnet restricted_weekdays http_access allow localnet restricted_weekends # Запрещаем все остальное http_access deny all |
Далее перечислим типы запрещенных к скачиванию файлов. Я добавил zip, viv, exe, mp3, rar, ace, avi, mov, mpg, mpeg, au, ra, arj, tar, gz и z файлы.
Листинг 7: /etc/squid/files.acl |
\.[Zz][Ii][pP]$ \.[Vv][Ii][Vv].* \.[Ee][Xx][Ee]$ \.[Mm][Pp]3$ \.[Rr][Aa][Rr]$ \.[Aa][Cc][Ee]$ \.[Aa][Ss][Ff]$ \.[Aa][Vv][Ii]$ \.[Mm][Oo][Vv]$ \.[Mm][Pp][Gg]$ \.[Mm][Pp][Ee][Gg]$ \.[Aa][Uu]$ \.[Rr][Aa]$ \.[Aa][Rr][Jj]$ \.[Tt][Aa][Rr]$ \.[Gg][Zz]$ \.[Zz]$ |
Примечание: Обратите внимание на [] с заглавными и строчными буквами. Это сделано для того, чтобы никто не смог обмануть наш фильтр, пытаясь скачать файл с расширением AvI вместо avi. |
Далее добавим регулярные выражения для определения баннеров. Вы, возможно, будете более изобретательнее меня:
Листинг 8: /etc/squid/banner-ads.acl |
/adv/.*\.gif$ /[Aa]ds/.*\.gif$ /[Aa]d[Pp]ix/ /[Aa]d[Ss]erver /[Aa][Dd]/.*\.[GgJj][IiPp][FfGg]$ /[Bb]annerads/ /adbanner.*\.[GgJj][IiPp][FfGg]$ /images/ad/ /reklame/ /RealMedia/ads/.* ^http://www\.submit-it.* ^http://www\.eads.* ^http://ads\. ^http://ad\. ^http://ads02\. ^http://adaver.*\. ^http://adforce\. adbot\.com /ads/.*\.gif.* _ad\..*cgi /Banners/ /SmartBanner/ /Ads/Media/Images/ ^http://static\.wired\.com/advertising/ ^http://*\.dejanews\.com/ads/ ^http://adfu\.blockstackers\.com/ ^http://ads2\.zdnet\.com/adverts ^http://www2\.burstnet\.com/gifs/ ^http://www.\.valueclick\.com/cgi-bin/cycle ^http://www\.altavista\.com/av/gifs/ie_horiz\.gif |
И в заключении мы хотим, чтобы отображался следующий файл вместо удаленного баннера. Он основан половине HTML-файла с прозрачным GIF-изображением размером 4х4.
Листинг 9: /etc/squid/errors/NOTE_ADS_FILTERED |
<HTML> <HEAD> <META HTTP-EQUIV="REFRESH" CONTENT="0; URL=http://localhost/images/4x4.gif"> <TITLE>ERROR: The requested URL could not be retrieved</TITLE> </HEAD> <BODY> <H1>Add filtered!</H1> |
Примечание: Не закрывайте теги <HTML> и <BODY>. Squid сделает это самостоятельно. |
Как вы видите, у Squid есть множество возможностей для очень эффективной фильтрации и кэширования. Можно даже использовать альтернативные прокси-сервера Squid для сегментирования очень больших сетей. Приведенная конфигурация подходит для небольшой сети с 1—20 пользователями.
Однако комбинация межсетевого экрана (iptables) и программного шлюза (Squid), возможно, является наилучшей, особенно если Squid находится где-нибудь в безопасном месте, где никто не может иметь к нему доступ извне. Нам все же стоит позаботиться об атаках изнутри.
Теперь вам необходимо настроить клиентские браузеры для использования прокси-сервера. Шлюз предотвратит попытки пользователей общаться с внешним миром без использования прокси.
Примечание: В Mozilla это может быть сделано через Edit->Preferences->Advanced->Proxies. |
Также можно настроить прозрачное использование прокси, указав iptables перенаправлять весь исходящий трафик на вход Squid. Это можно сделать, добавив следующее правило на шлюзе:
Листинг 10: Разрешить проброс портов для нашего прокси-сервера |
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to proxyhost:3128 # iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128 |
Примечание: Если прокси-сервер работает на том же узле, что и межсетевой экран (хотя это не рекомендуется, но может понадобится из-за отсутствия свободных компьютеров), то используйте цель REDIRECT вместо DNAT (REDIRECT направит пакеты на localhost). |
Мы узнали:
Межсетевой экран является опасным сам по себе. Плохо настроенный межсетевой экран хуже, чем его отсутствие.
Как установить простой шлюз и прозрачный прокси-сервер.
Залогом хорошей работы межсетевого экрана заключается в знании протоколов, которые вы собираетесь разрешить.
IP-трафик не всегда содержит законные данные, например пакеты ICMP, которые могут содержать вредоносное содержимое.
Как предотвратить SYN-атаку.
Фильтрация HTTP-трафика предотвратит загрузку нежелательных изображений и вирусов.
Сочетание пакетных фильтров и программных шлюзов дает лучший контроль.
Теперь, если вам действительно это нужно, идите и создайте правила межсетевого экрана, отвечающего вашим требованиям.
AIDE — это система обнаружения атак, основанная на узле (Host-Based Intrusion Detection System, HIDS), свободная альтернатива Tripwire (если вы уже работали с Tripwire, то не должны испытывать сложности с конфигурационным файлом AIDE). HIDS используется для обнаружения изменений в важных системных файлах настроек и двоичных файлах с помощью сверки уникальных криптографических контрольных сумм, созданных каждого из файлов и сохраненных в надежном месте. Принцип действия таков: заранее сохраненный и достоверный хеш сравнивается с сгенерированным с текущей копии каждого файла, чтобы определить какой из файлов был изменен. HIDS является великолепным решением для регистрации подозрительных изменений в системе, однако для того, чтобы она заработала, нужно приложить небольшие усилия.
Конфигурационный файл основан на применении регулярных выражений, макросов и правил для файлов и каталогов. Есть следующие макросы:
Макрос |
Описание |
Синтаксис |
ifdef |
если определен |
@@ifdef "name" |
ifndef |
если не определен |
@@ifndef "name" |
define |
определить переменную |
@@define "name" "value" |
undef |
удалить переменную |
@@undef "name" |
ifhost |
если "hostname" |
@@ifhost "hostname" |
ifnhost |
если не "hostname" |
@@ifnhost "hostname" |
endif |
endif должен использоваться каждый раз, когда используется любой из вышеприведенных макросов, за исключением define и undef |
@@endif |
Если у вас есть много компьютеров с Gentoo и вы хотите использовать на них AIDE, то макросы будут весьма полезными. Но не на всех компьютерах запускаются одни и те же сервисы или есть одни и те же пользователи.
Теперь необходимо установить флаги проверок для файлов и каталогов. Возможны сочетания прав доступа, свойств файлов и криптографических хешей (контрольных сумм).
Флаг |
Описание |
p |
права доступа |
i |
inode |
n |
количество ссылок |
u |
пользователь |
g |
группа |
s |
размер |
b |
число блоков |
m |
время последней модификации |
a |
время последнего доступа |
c |
время изменения |
S |
проверка растущего размера |
md5 |
контрольная сумма MD5 |
sha1 |
контрольная сумма SHA1 |
rmd160 |
контрольная сумма RMD160 |
tiger |
контрольная сумма Tiger |
R |
p+i+n+u+g+s+m+c+md5 |
L |
p+i+n+u+g |
E |
Пустая группа |
> |
растущий лог-файл p+u+g+i+n+S |
А если AIDE собран с поддержкой mhash, то доступны следующие возможности:
Флаг |
Описание |
haval |
контрольная сумма HAVAL |
gost |
контрольная сумма ГОСТ |
crc32 |
контрольная сумма CRC32 |
Теперь вы можете создать собственные правила, основанные на сочетании вышеперечисленных флагов, например:
Листинг 1: Создание набора правил для AIDE |
All=R+a+sha1+rmd160 Norm=s+n+b+md5+sha1+rmd160 |
И последнее, что нам понадобится для создания собственного конфигурационного файла, — это умение добавлять правило для файла или каталога. Чтобы ввести правило, скомбинируйте файл или каталог с правилом. AIDE добавляет все файлы рекурсивно, если вы не указали обратное в другом правиле.
Флаг |
Описание |
! |
Не добавлять этот файл или каталог. |
= |
Добавлять этот каталог, но не рекурсивно. |
А теперь взглянем на полный пример:
Листинг 2: /etc/aide/aide.conf |
@@ifndef TOPDIR @@define TOPDIR / @@endif @@ifndef AIDEDIR @@define AIDEDIR /etc/aide @@endif @@ifhost smbserv @@define smbactive @@endif # Расположение базы данных для чтения. database=file:@@{AIDEDIR}/aide.db # Расположение базы данных для записи. database_out=file:aide.db.new verbose=20 report_url=stdout # Определение правил All=R+a+sha1+rmd160 Norm=s+n+b+md5+sha1+rmd160 @@{TOPDIR} Norm !@@{TOPDIR}etc/aide !@@{TOPDIR}dev !@@{TOPDIR}media !@@{TOPDIR}mnt !@@{TOPDIR}proc !@@{TOPDIR}root !@@{TOPDIR}sys !@@{TOPDIR}tmp !@@{TOPDIR}var/log !@@{TOPDIR}var/run !@@{TOPDIR}usr/portage @@ifdef smbactive !@@{TOPDIR}etc/smb/private/secrets.tdb @@endif =@@{TOPDIR}home Norm |
В приведенном примере мы указали некоторые макросы, корневой каталог, с которого будет начинать свою работу AIDE, и каталог, в котором находится AIDE. AIDE сверяется с /etc/aide/aide.db при проверке на целостность. Но при обновлении или создании нового файла она сохраняет информацию в /etc/aide/aide.db.new. Это делается для того, чтобы не переписать старую базу данных. Параметр report_URL пока не реализован, но, согласно автору, он должен отправлять электронную почту или даже запуск сценариев.
Теперь по умолчанию пакет AIDE поставляется вместе с рабочим конфигурационным файлом, сценарием-помощником и сценарием планировщика заданий crontab. Сценарий-помощник содержит множество задач для вас и предоставляет более дружественный интерфейс. Чтобы просмотреть все доступные параметры, попробуйте aide --help. Все что вам нужно, чтобы начать, — запустить aide -i, и теперь сценарий crontab должен найти базу данных и ежедневно отправлять отчеты по электронной почте. Рекомендуется все же пересмотреть файл /etc/aide/aide.conf и удостовериться, что конфигурация подходит для данного компьютера.
Примечание: В зависимости от процессора, скорости чтения диска и установленных для файлов флагов, это может занять много времени. |
Примечание: Не забудьте установить алиасы, чтобы получать почту, адресуемую суперпользователю. Иначе вы никогда не узнаете, что пишет для вас в отчетах AIDE. |
Все же есть небольшой риск, заключающийся в том, что злоумышленник может (если узнает об установленном AIDE) изменить локальную базу данных файлов, обновить ее или изменить /usr/bin/aide. Поэтому вы должны создать компакт-диск или иной носитель и сохранить на нем копию файла .db и двоичных файлов AIDE.
Дополнительную информацию вы можете найти на сайте проекта AIDE
Snort является сетевой системой обнаружения вторжения (Network Intrusion Detection System, NIDS). Чтобы установить и настроить его, воспользуйтесь следующими примерами.
Листинг 3: /etc/conf.d/snort |
PIDFILE=/var/run/snort_eth0.pid MODE="full" NETWORK="10.0.0.0/24" LOGDIR="/var/log/snort" CONF=/etc/snort/snort.conf SNORT_OPTS="-D -s -u snort -dev -l $LOGDIR -h $NETWORK -c $CONF" |
Листинг 4: /etc/snort/snort.conf |
(Шаг 1) var HOME_NET 10.0.0.0/24 var EXTERNAL_NET any var SMTP $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var DNS_SERVERS [10.0.0.2/32,212.242.40.51/32] var RULE_PATH ./ (Шаг 2) preprocessor frag2 preprocessor stream4: detect_scans detect_state_problems detect_scans disable_evasion_alerts preprocessor stream4_reassemble: ports all preprocessor http_decode:80 8080 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace preprocessor rpc_decode: 111 32771 preprocessor bo: -nobrute preprocessor telnet_decode (Шаг 3) include classification.config (Шаг 4) include $RULE_PATH/bad-traffic.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/telnet.rules include $RULE_PATH/smtp.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/tftp.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-attacks.rules include $RULE_PATH/sql.rules include $RULE_PATH/x11.rules include $RULE_PATH/icmp.rules include $RULE_PATH/netbios.rules include $RULE_PATH/misc.rules include $RULE_PATH/attack-responses.rules include $RULE_PATH/backdoor.rules include $RULE_PATH/shellcode.rules include $RULE_PATH/policy.rules include $RULE_PATH/porn.rules include $RULE_PATH/info.rules include $RULE_PATH/icmp-info.rules include $RULE_PATH/virus.rules # include $RULE_PATH/experimental.rules include $RULE_PATH/local.rules |
Листинг 5: /etc/snort/classification.config |
config classification: not-suspicious,Not Suspicious Traffic,3 config classification: unknown,Unknown Traffic,3 config classification: bad-unknown,Potentially Bad Traffic, 2 config classification: attempted-recon,Attempted Information Leak,2 config classification: successful-recon-limited,Information Leak,2 config classification: successful-recon-largescale,Large Scale Information Leak,2 config classification: attempted-dos,Attempted Denial of Service,2 config classification: successful-dos,Denial of Service,2 config classification: attempted-user,Attempted User Privilege Gain,1 config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1 config classification: successful-user,Successful User Privilege Gain,1 config classification: attempted-admin,Attempted Administrator Privilege Gain,1 config classification: successful-admin,Successful Administrator Privilege Gain,1 # NEW CLASSIFICATIONS config classification: rpc-portmap-decode,Decode of an RPC Query,2 config classification: shellcode-detect,Executable code was detected,1 config classification: string-detect,A suspicious string was detected,3 config classification: suspicious-filename-detect,A suspicious filename was detected,2 config classification: suspicious-login,An attempted login using a suspicious username was detected,2 config classification: system-call-detect,A system call was detected,2 config classification: tcp-connection,A TCP connection was detected,4 config classification: trojan-activity,A Network Trojan was detected, 1 config classification: unusual-client-port-connection,A client was using an unusual port,2 config classification: network-scan,Detection of a Network Scan,3 config classification: denial-of-service,Detection of a Denial of Service Attack,2 config classification: non-standard-protocol,Detection of a non-standard protocol or event,2 config classification: protocol-command-decode,Generic Protocol Command Decode,3 config classification: web-application-activity,access to a potentially vulnerable web application,2 config classification: web-application-attack,Web Application Attack,1 config classification: misc-activity,Misc activity,3 config classification: misc-attack,Misc Attack,2 config classification: icmp-event,Generic ICMP event,3 config classification: kickass-porn,SCORE! Get the lotion!,1 |
Дополнительной информация может быть найдена на сайте Snort.
Система HIDS, как AIDE, является лучшим средством для обнаружения изменений в вашей системе, но хуже не будет, если будет установлен еще один рубеж обороны. chkrootkit — это утилита, которая сканирует системные файлы на наличие руткитов — программ, разработанных для сокрытия присутствия взломщика и сохранения доступа к системе, а также на наличие следов кейлоггеров и прочих вредоносных программ. Хотя chkrootkit (и прочие аналоги, например rkhunter) являются полезными утилитами, как контроля за системой, так и для обнаружения следов вторжения, но они не могут гарантировать, что ваша система в безопасности.
Наилучший способ использовать chkrootkit для обнаружения внедрения — запускать его с помощью cron. Сначала установите app-admin/chkrootkit. chkrootkit может запускаться из командной строки или же с помощью записи в cron следующего вида:
Листинг 6: Назначение задания chrootkit в crontab |
0 3 * * * /usr/sbin/chkrootkit |
После успешной установки и настройки ее безопасности систему, тем не менее, нельзя называть завершенной. Процесс обеспечения безопасности является постоянным по времени, ведь большинство известных взломов является результатом использования известных уязвимостей в устаревших системах. Постоянное обновление системы — наиболее значимый шаг, который вы можете совершить для обеспечения наилучшей безопасности.
Если у вас установлена последняя версия portage, то, предварительно обновив дерево с помощью команды emerge --sync, вы можете запустить команду glsa-check --list, которая проверит вашу систему на наличие известных уязвимостей. glsa-check является частью пакета app-portage/gentoolkit.
Листинг 1: Пример вывода glsa-check -l |
# glsa-check -l WARNING: This tool is completely new and not very tested, so it should not be used on production systems. It's mainly a test tool for the new GLSA release and distribution system, it's functionality will later be merged into emerge and equery. Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml before using this tool AND before reporting a bug. [A] means this GLSA was already applied, [U] means the system is not affected and [N] indicates that the system might be affected. 200406-03 [N] sitecopy: Multiple vulnerabilities in included libneon ( net-misc/sitecopy ) 200406-04 [U] Mailman: Member password disclosure vulnerability ( net-mail/mailman ) ....... |
Предупреждение: Утилита glsa-check все еще является экспериментальной, поэтому, если вы действительно ставите безопасность превыше всего, то лучше также свериться с другими источниками. |
Все строки, содержащие [A] и [U], могут быть игнорированы, так как они неприменимы для данной системы.
Важно: Не забывайте, что использование emerge -vpuD world не устанавливает все необходимые обновления пакетов. Используйте glsa-check, если хотите быть уверенным, что все GLSA исправлены в вашей системе. |
Листинг 2: Проверка всех GLSA |
(Подвержена ли ваша система GLSA?) # glsa-check -t all WARNING: This tool is completely new and not very tested, so it should not be used on production systems. It's mainly a test tool for the new GLSA release and distribution system, it's functionality will later be merged into emerge and equery. Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml before using this tool AND before reporting a bug. This system is affected by the following GLSA: 200504-06 200510-08 200506-14 200501-35 200508-12 200507-16 (Просмотр всех пакетов, подверженных переустановке) # glsa-check -p $(glsa-check -t all) (частичный вывод) Checking GLSA 200504-06 The following updates will be performed for this GLSA: app-arch/sharutils-4.2.1-r11 (4.2.1-r10) ********************************************************************** Checking GLSA 200510-08 The following updates will be performed for this GLSA: media-libs/xine-lib-1.1.0-r5 (1.1.0-r4) (применение необходимых исправлений) # glsa-check -f $(glsa-check -t all) |
Если вы обновили запущенный сервис, не забудьте перезапустить его.
Также рекомендуется регулярно обновлять ядро.
Вы можете также подписаться на список рассылки gentoo-announce, чтобы получать уведомления GLSA по электронной почте. Инструкции по подписке могут быть найдены на странице Введение в почтовые рассылки Gentoo Linux.
Другим хорошим источником информации по безопасности является список рассылки Bugtraq.
В начало → Настольная книга по безопасности Gentoo → A. Безопасность системы |