Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

DNS

Разделение функций сервера имен.

Рубрики: Безопасность | Защита сервисов
Метки: | |
Дата: 18/09/2009 09:41:52
Подписаться на комментарии по RSS

Сервер имен выполняет две роли: разрешает запросы клиентов и выступает в роли авторитетного сервера для какой-то зоны. Представим, что у нас есть средняя компания. Имеется домен www.test.net. Целесообразно разделить функции серверов имен.

     Один сервер имен будет находиться во внутренней сети и разрешать запросы клиентов - это будет сервер для внутреннего употребления. Второй сервер будет авторитетным для зоны - он будет отвечать на запросы интернет-пользователей для этой зоны. Месторасположение данного сервера - нейтральная зона (DMZ).

Далее...

DNSSEC: служба безопасности DNS.

Рубрики: Безопасность | Защита сервисов
Метки: | |
Дата: 14/09/2009 10:37:09
Подписаться на комментарии по RSS

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

     DNSSEC (DNS Security Extensions) - набор расширений протокола DNS, использующий РКС и цифровые подписи для осуществления безопасных транзакций между серверами и клиентами (или между серверами и серверами). Подробное описание DNSSEC можно найти в RFC 2535. Рассмотрим, как надо реализовать эту систему в DNS.

     Технология DNSSEC - это не абсолютно новая концепция, ей уже несколько лет, и ее уже успели опробовать.

Далее...

Защита DNS: продолжение.

Рубрики: Безопасность | Защита сервисов
Метки: | |
Дата: 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: общие настройки.

Рубрики: Безопасность | Защита сервисов
Метки: |
Дата: 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.

Рубрики: Безопасность | Управление доступом
Метки: | | |
Дата: 15/07/2009 09:02:50
Подписаться на комментарии по RSS

Рассмотрим пример ACL, который позволяет работать DNS-серверу на машине. ACL будет состоять из двух частей. Первая часть будет содержать общий набор правил, предоставляющих базовый доступ. Эта часть универсальна - она подойдет не только для DNS-сервера, но и для разных остальных приложений, запущенных в Linux-системе.

     Во второй части будут описаны специфические для DNS-сервера правила, ограничивающие доступ к файлам, и определяющие возможности DNS-сервера. Как было написано ранее, набор правил будет представлен в виде shell-сценария, который содержит серию команд lidsconf.

     Сначала надо сделать системные исполнимые файлы и библиотеки доступными только для чтения. Обойти данное ограничение нужно только в LFS-оболочке. Итак, надо защитить каталоги /bin, /sbin, /usr и /opt:

Далее...

Фильтрация локальных пакетов.

Рубрики: Безопасность | Брандмауэр
Метки: | | | |
Дата: 09/04/2009 09:33:05
Подписаться на комментарии по RSS

     До этого IPTables использовался централизованно - только на бранд­мауэре. Но это нельзя рассматривать как полную защиту сети - ведь защищать нужно не только сеть в целом, но и отдельную машину.

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

Далее...

Создание набора правил брандмауэра(Часть 2).

Рубрики: Безопасность | Брандмауэр
Метки: | | | |
Дата: 06/04/2009 09:09:25
Подписаться на комментарии по RSS

     Защита нейтральной зоны (DMZ).

     Правила, заданные в сценарии nat.sh, ограничивали поток трафика в нейтральную зону, но не определяли ограничения на ис­ходящий от DMZ-серверов трафик, который может передаваться или в ло­кальную сеть, или в Интернет. В идеале нужно разрешить только ESTABLISED- и RELATED-трафик, так как DMZ-серверы будут только обрабатывать запросы клиен­тов и не будут устанавливать новых соединений.

     Но есть определенная проблема, которая заключается в том, что сервисы, в частности DNS и SMTP, будут устанавливать новые соединения. Если запретить созда­ние новых соединений для DNS-серверов, то прервется работа этих сер­висов. В этом случаем нужно написать более точные правила.

Далее...