DNS
Разделение функций сервера имен.
Метки: ACL | DMZ | DNS
Дата: 18/09/2009 09:41:52
Подписаться на комментарии по RSS
Сервер имен выполняет две роли: разрешает запросы клиентов и выступает в роли авторитетного сервера для какой-то зоны. Представим, что у нас есть средняя компания. Имеется домен www.test.net. Целесообразно разделить функции серверов имен.
Один сервер имен будет находиться во внутренней сети и разрешать запросы клиентов - это будет сервер для внутреннего употребления. Второй сервер будет авторитетным для зоны - он будет отвечать на запросы интернет-пользователей для этой зоны. Месторасположение данного сервера - нейтральная зона (DMZ).
DNSSEC: служба безопасности DNS.
Метки: DNS | DNSSEC | PKC
Дата: 14/09/2009 10:37:09
Подписаться на комментарии по RSS
Так как TSIG-ключи можно добавить в конфигурационный файл каждой машины, их употребление не очень практично. Во-первых, когда имеется много серверов имен, то при изменении ключей придется проделать много действий. А во-вторых, если крекер получит доступ к серверу имен, он получит и TSIG-ключи, что позволит ему отправлять подделанные сообщения другим серверам от имени этого сервера.
DNSSEC (DNS Security Extensions) - набор расширений протокола DNS, использующий РКС и цифровые подписи для осуществления безопасных транзакций между серверами и клиентами (или между серверами и серверами). Подробное описание DNSSEC можно найти в RFC 2535. Рассмотрим, как надо реализовать эту систему в DNS.
Технология DNSSEC - это не абсолютно новая концепция, ей уже несколько лет, и ее уже успели опробовать.
Защита DNS: продолжение.
Метки: chroot | DNS | TSIG
Дата: 09/09/2009 08:57:41
Подписаться на комментарии по RSS
Запуск BIND от имени непривилегированного пользователя.
Обычно BIND всегда запускался от имени root, но, учитывая все его уязвимости, это делать нежелательно, так как позволяет легко скомпрометировать систему.
Начиная с версии 8.1.2, появилась возможность запуска BIND от имени простого пользователя. Прежде BIND стартует от имени root - для того, чтобы сесть на 53 порт, а затем сбрасывает полномочия root и принимает полномочия указанного с помощью опции -n пользователя:
# named -n namedДля запуска named нужно создать новую учетную запись, а не запускать от имени nobody, от имени которого и так запущено много процессов.
Защита DNS: общие настройки.
Метки: DNS | UDP
Дата: 25/08/2009 13:56:38
Подписаться на комментарии по RSS
Сервер имен BIND стал стандартом де-факто на DNS-серверы, иногда слово BIND применяется как синоним DNS. BIND применяется повсюду: и в маленькой сети с выходом в Интернет, и в немалой корпоративной закрытой сети, и в сети интернет-провайдера...
Также BIND прославился в плане уязвимостей. Подробное описание всех исправленных багов во всех версиях BIND доступно по адресу:
http://www.isc.org/sw/bind/bind-security.php
Пример ACL для DNS-cepвepa.
Метки: ACL | DNS | LFS | LIDS
Дата: 15/07/2009 09:02:50
Подписаться на комментарии по RSS
Рассмотрим пример ACL, который позволяет работать DNS-серверу на машине. ACL будет состоять из двух частей. Первая часть будет содержать общий набор правил, предоставляющих базовый доступ. Эта часть универсальна - она подойдет не только для DNS-сервера, но и для разных остальных приложений, запущенных в Linux-системе.
Во второй части будут описаны специфические для DNS-сервера правила, ограничивающие доступ к файлам, и определяющие возможности DNS-сервера. Как было написано ранее, набор правил будет представлен в виде shell-сценария, который содержит серию команд lidsconf.
Сначала надо сделать системные исполнимые файлы и библиотеки доступными только для чтения. Обойти данное ограничение нужно только в LFS-оболочке. Итак, надо защитить каталоги /bin, /sbin, /usr и /opt:
Фильтрация локальных пакетов.
Метки: DMZ | DNS | IPTables | SMTP | SSH
Дата: 09/04/2009 09:33:05
Подписаться на комментарии по RSS
До этого IPTables использовался централизованно - только на брандмауэре. Но это нельзя рассматривать как полную защиту сети - ведь защищать нужно не только сеть в целом, но и отдельную машину.
Возьмем, к примеру, ситуацию, в отдельных случаях крекеру удается каким-то образом проникнуть в нейтральную зону - он получил доступ к серверу из нейтральной зоны. В настоящее время он пытается расширить свои «права», то есть получить доступ к другим машинам, в том числе и брандмауэру. Следовательно, брандмауэр IPTables нужно запускать и на других машинах сети - чтобы защитить эти машины.
Создание набора правил брандмауэра(Часть 2).
Метки: DMZ | DNS | ICMP | IPTables | SMTP
Дата: 06/04/2009 09:09:25
Подписаться на комментарии по RSS
Защита нейтральной зоны (DMZ).
Правила, заданные в сценарии nat.sh, ограничивали поток трафика в нейтральную зону, но не определяли ограничения на исходящий от DMZ-серверов трафик, который может передаваться или в локальную сеть, или в Интернет. В идеале нужно разрешить только ESTABLISED- и RELATED-трафик, так как DMZ-серверы будут только обрабатывать запросы клиентов и не будут устанавливать новых соединений.
Но есть определенная проблема, которая заключается в том, что сервисы, в частности DNS и SMTP, будут устанавливать новые соединения. Если запретить создание новых соединений для DNS-серверов, то прервется работа этих сервисов. В этом случаем нужно написать более точные правила.