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

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

DMZ

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

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

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

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

Далее...

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

Рубрики: Безопасность | Брандмауэр
Метки: | | | |
Дата: 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-серверов, то прервется работа этих сер­висов. В этом случаем нужно написать более точные правила.

Далее...

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

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

Огненная стенаКак и в сценарии для простой реализации сети с DMZ, первоначально определяются слу­жебные переменные, которые будут использоваться в новом сценарии - firewall.sh. Описание каждой переменной можно найти в этом же разделе. Начало сценария будет таким:

#/bin/sh

IF_LAN="ethl"

IF_DMZ="eth2"

IF_EXT="eth0"

IP_LAN="192.168.1.1"

IP_DMZ="192.168.0.1"

DMZ_HTTP="192.168.0.3"

DMZ_DNS="192.168.О.2"

DMZ_MAIL="192.168.0.4"

## Путь к исполнимому файлу iptables.

## Может отличаться в зависимости

## от дистрибутива Linux

IPT="/usr/sbin/iptables"

Далее...

Брандмауэр для сети с DMZ(простая реализация).

Рубрики: Безопасность | Брандмауэр
Метки: | | | | |
Дата: 29/03/2009 11:36:38
Подписаться на комментарии по RSS

Правила брандмауэра.

     На рисунке показана предложенная топология с IP-адресами интерфейсов. Опишем словесно все пра­вила маршрутизации трафика, а потом реализуем их на IPTables:

  • Пакеты, выходящие за пределы локальной сети (то есть ад­ресованные интернет-узлам), должны проходить через интерфейс eth0. Кроме этого, нужно перезаписать адрес отправителя: поскольку используем внутренние адреса, то нужно заменить внутренний адрес отправителя адресом внешнего интерфейса.
  • Ответы на эти пакеты должны быть переданы на интерфейс eth1 (интерфейс внутренней сети), при этом адрес получателя должен быть корректно перезаписан. Так как ответ, полученный от интернет-узла, будет предназначен внешнему интерфейсу, то нуж­но вернуть ответ внутреннему узлу, указав его внутренний IP-адрес.
  • Пакеты из локальной сети, адресованные компьютерам нейтраль­ной зоны, должны быть переданы на интерфейс eth2. Для этих пакетов NAT не нужен, поскольку DMZ-компьютеры также используют внутренние адреса.
  • Пакеты из нейтральной зоны, адресованные компьютерам локаль­ной сети, должны быть переданы на интерфейс eth1. NAT также не нужен.
  • Пакеты DMZ-компьютеров, адресованные интернет-узлам, должны покинуть пределы сети через интерфейс eth0. В этом случае NAT нужен: нужно перезаписать адрес отправителя ад­ресом внешнего интерфейса.
  • Ответы на эти пакеты должны быть отправлены назад, при этом адрес получателя должен быть корректно перезаписан, так как пакет нужно отправить соответствующей машине нейтральной зоны.
  • Входящие запросы на ТСР-соединения (SYN-пакеты) по портам 80 и 443 должны быть переданы Web-серверу (из нейтральной зоны).
  • Входящие запросы на TCP/UDP-соединения по порту 53 должны быть переданы DNS-серверу (из нейтральной зоны).
  • Входящие запросы на ТСР-соединения по порту 25 должны быть переданы почтовому серверу (из нейтральной зоны).

Далее...

Топология сети с нейтральной зоной(DMZ).

Рубрики: Безопасность | Топология сети
Метки:
Дата: 05/02/2009 12:24:32
Подписаться на комментарии по RSS

В сети любого предприятия наверняка есть обыкновенные рабочие станции (в частности, ком­пьютеры пользователей 1С, пользующихся услугами какого-то внутреннего сервера локальной сети) и узлы, предоставляющие услуги интернет-поль­зователям, к примеру Web-сервер, DNS-сервер.

     Самое разумное решение - разделение этих двух групп компьютеров. Компьютеры, дающие услуги интернет-пользователям, помеща­ются в нейтральную зону (DMZ, Demilitarized Zone). Преимущества нейтральной зоны(DMZ) заключаются в следующем. Если, например, Web-сервер будет взломан, то дальше крекер не сможет «добраться» до других узлов сети. Вот как будет выглядеть данная топология сети.

Далее...

Введение в аудит сети

Рубрики: Аудит сети | Безопасность
Метки: | |
Дата: 02/02/2009 10:39:26
Подписаться на комментарии по RSS

Аудит сети - это не просто какое-то абстрактное понятие. После основных мероприятий по защите вашей сети, нужно обязательно проверить всю сеть на наличие всевозможных уязвимостей, которыми может воспользоваться крекер. Нужно поставить себя на место злоумышленника и попробовать все возможные инструменты по взлому, которыми обычно пользуются крекеры. Провести аудит уязвимостей точно так же, как это делал бы злоумышленник. Самые популярные инструменты крекеров - это сканер портов nmap, программа для поиска уязвимостей Nessus, Nikto - аудитор web-сервера и многие другие. Причем нужно помнить, что мир не стоит на месте, и каждый день находится много новых уязвимостей. Нужно постоянно быть в курсе самых последний изменений в обеспечении безопасности сети.

Далее...