В качестве сборщика выбран пакет flow-tools, последней на данный момент версии — 0.68, который был установлен из портов: «/usr/ports/net-mgmt/flow-tools».
В качестве хранилища взят MySQL версии 5.1.34.

Установка указанных пакетов не вызвала никаких проблем и описывать её я не буду )

На первом этапе надо наладить сбор данных и их экспорт в таблицу MySQL.

Мои знания о netflow вообще и о flow-tools в частности весьма поверхностны, так что просьба не пинать за не самые лучшие решения, а помочь советом в случае чего )

Запуск сборщика данных

Запускаем коллектор, который будет получать данные от циски и сохранять их в файлах:

/usr/local/bin/flow-capture
 -n48
 -N0
 -w /data/flow
 -E1G
 0/10.0.1.13/2055

Опишу использованные мной параметры:

• -n48 — количество ротаций файлов за сутки, 48 раз — это каждые полчаса;
• -N0 — формат имён файлов со статистикой, 0 — просто файл в указанной папке;
• -w /data/flow — папка для хранения файлов;
• -E1G — размер файла, по достижении которого, файл со статистикой ротейтится — 1ГБ, если размер файла не достигает указанного, то файл ротейтится согласно параметра -n48;
• 10.0.1.5/10.0.1.13/2055 — принимать данные, отправленные на адрес 10.0.1.5/принимать данные только от экпортёра 10.0.1.13/порт для ожидания данных;

Сборщик будет висеть на указанных айпишнике и порту, принимать данные от указанного адреса и складывать их во временный файл в папке /data/flow, например с таким именем:

tmp-v05.2009-05-11.183644+0600

Через промежуток времени, согласно параметра -n48, а в нашем случае это полчаса, временный файл будет переименован в окончательный, например вот такой:

ft-v05.2009-05-11.183644+0600

И затем будет создан новый временный файл:

tmp-v05.2009-05-11.190609+0600

Пишем скриптик для запуска коллектора и помещаем его в «/usr/local/etc/rc.d», в простом случае он может быть вот такой:

#!/bin/sh

CMD="/usr/local/bin/flow-capture
 -n48
 -N0
 -w /data/flow
 -E5G
 10.0.1.5/10.0.1.13/2055"

PID="/var/run/flow-capture.pid.2055"

case "$1" in
 start)
  echo "Start flow-capture"
  $CMD
 ;;
 stop)
  echo "Stop flow-capture"
  kill -TERM `cat $PID`
 ;;
 *)
  echo " Usage: `basename $0` { start | stop }"
  exit 1
 ;;
esac

exit 0

Ну и конечно надо разрешить в нашем файрволе входящие пакеты с адреса экспортёра на адрес коллектора по протоколу udp и на порт 2055.

Настройка экспорта данных с циски

Настраиваем циску для экспорта данных с нужного нам интерфейса:

cs#conf t
cs(config)#ip flow-export version 5
cs(config)#ip flow-export destination 10.0.1.5 2055
cs(config)#int bvi1
cs(config-if)#ip flow egress
cs(config-if)#ip flow ingress
cs(config-if)#^Z

Посмотреть что получилось на циске можно вот так:

cs#show ip flow interface
BVI1
  ip flow ingress
  ip flow egress
cs#show ip flow export
Flow export v5 is enabled for main cache
  Export source and destination details :
  VRF ID : Default
    Destination(1)  10.0.1.5 (2055)
  Version 5 flow records
  4084394 flows exported in 150001 udp datagrams
  0 flows failed due to lack of export packet
  0 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures

Экспорт данных из файла в текстовый вид

Для проверки наличия нужных нам данных в файлах, которые нам создал коллектор, можно экпортировать их в текстовый формат:

flow-export -f2 -mDPKTS,DOCTETS,SRCADDR,DSTADDR < raw_file

Ключ -f2 задаёт формат вывода - ASCII с полями, разделёнными запятой. Поля, которые вы хотите увидеть задаются параметром -m, список всех полей есть в мане к flow-export. При указании полей, насколько я понял, нужно перечислять их в порядке следования в списке в мане, например, указать поле DPKTS после поля DSTADD нельзя - это приведёт к ошибке:

# flow-export -f2 -mDOCTETS,SRCADDR,DSTADDR,DPKTS < raw_file
flow-export: Out of order field: DPKTS
flow-export: ftxfield_parse(): failed

Список полей для экспорта можно задать и при помощи масок, что будет короче в написании, но сложнее в восприятии )

Подготовка MySQL для сохранения данных

Понятно, что прежде чем записывать данные в MySQL, нужно создать пользователя, базу данных и таблицу с нужными нам полями.
Описывать создание пользователя и базы я не буду в виду тривиальности задачи )
Остановлюсь на создании таблицы, в моём случае это было примерно так:

create table export (
 unix_secs int(11) unsigned null,
 exaddr varchar(16) null,
 dpkts int(10) unsigned null,
 doctets int(10) unsigned null,
 first int(11) unsigned null,
 last int(11) unsigned null,
 srcaddr varchar(16) null,
 dstaddr varchar(16) null,
 srcport smallint(5) unsigned null,
 dstport smallint(5) unsigned null,
 prot tinyint(3) unsigned null,
 key (srcaddr)
);

Возможно, из-за отсутствия опыта работы с netflow, я мог собрать ненужные мне поля, а какие-то интересные, наоборот, пропустить. Это можно легко поправить в рабочем порядке )

Экспорт данных из файла в MySQL

Теперь, когда СУБД готова к приёму наших данных, можно их экспортировать:

/usr/local/bin/flow-export -f3
 -mUNIX_SECS,EXADDR,DPKTS,DOCTETS,FIRST,
 LAST,SRCADDR,DSTADDR,SRCPORT,DSTPORT,PROT
 -u "flow:DBPassword:localhost:/tmp/mysql.sock:flow:export" < raw_file

Параметр -f3 задаёт формат экспорта - MySQL, параметр -u задаёт данные для доступа к базе данных - "пользователь:пароль:хост:порт:база:таблица".

Так же не забываем о необходимости соблюдения соответствия очерёдности полей, экпортируемых из файлов, с очерёдности полей, созданных в таблице.

Периодичность запуска этой процедуры определите сами с учётом своих нужд. В моём случае довольно и одного раза в час.

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

Я решил, что мне удобнее хранить данные посуточно в отдельных таблицах с названиями типа "export_0512". Для это я написал небольшой скрипт на perl, который проверяет наличие таблицы для данного дня, при необходимости создаёт её и экспортирует в неё данные указанной выше командой, а также удаляет таблицу за этот день, но прошлого месяца.

Выборки из MySQL

Как извлекать нужные данные из БД учить не буду, т.к. и сам не очень хорошо в этом разбираюсь. Приведу лишь несколько запросов, которые я использую.

Найти десятку самых активных хостов из сети "10.255.0" по количеству исходящих байт:

select srcaddr,sum(doctets) as traf_out from export_0511
 WHERE srcaddr like '10.255.0.%' group by srcaddr order by traf_out desc limit 10;

Найти десятку портов получателей с самым большим исходящим трафиком для указанного айпишника:

select srcaddr,sum(doctets) as traf_int,dstport,prot from export_0512
 WHERE srcaddr like '10.255.0.3' group by dstport  order by traf_int desc limit 10;

Найти десятку удалённых хостов, на которые был наибольший исходящий трафик с указанного айпишника:

select srcaddr,dstaddr,sum(doctets) as traf_int from export_0511
 WHERE srcaddr like '10.255.0.3' group by dstaddr  order by traf_int desc limit 10;

Заключение

Данный пример позволяет только лишь быстро запустить сбор данных и сделать какие-либо запросы из базы данных. Различные проверки ошибок, удобства и т.п. каждый реализует сам в меру своих требований и фантазии )
Кому-то, наверняка, потребуется и веб-интерфейс для запросов в базу, но лично для меня и данного случая такой необходимости пока нет.

Буду благодарен за конструктивную критику и советы )

Как оказалось проблема была из-за какой-то ошибки файловой системы, fsck помог:
fsck /dev/sda4

За столько лет работы под ФриБСД ни разу с такой хренью не сталкивался )

Грустно…

Краткие сведения о Cisco PIX Firewall 520

520-я серия файрволов компании Cisco устарела довольно давно — производитель более не поставляет их с июля 2001, не выпускает обновлений программного обеспечения с июня 2004, а поддержка аппаратной части закончится в июне 2006 года. Но несмотря на это файрвол всё ещё остаётся достаточно интересным устройством особенно с учётом нынешней его стоимости.

С виду данный файрвол представляет собой несколько модернизированный ПК — корпус, материнская плата, блок питания, 3.5″ привод для гибких дисков с виду такие же как у обычного ПК. Жёсткого диска у этого устройства, к счастью, нет, а в качестве долговременной памяти используется флеш-память, которая размещена на отдельной PCI-плате расширения вместе с другими схемами, реализующими специфичные функции, такие как консольный порт и интерфейс перекрытия сбоев (Failover), который позволяет дублировать основной файрвол резервным в случае выхода его из строя.

Для интереса приведу основные технические характеристики устройства, используемого в описанном случае — 768 MB RAM, CPU Pentium III 848 MHz, Flash 16MB, 4 сетевых адаптера 10/100.

Операционная система, по словам Cisco, специально разработана для данных задач, что позволяет устройству обрабатывать намного больший поток данных нежели обычные операционные системы для ПК.

Интерфейс командной строки весьма схож с интерфейсом маршрутизаторов Cisco, но имеет некоторые недостатки, впрочем не настолько существенные чтобы их отдельно описывать.

Версия операционной системы в конкретном случае — 6.3(4).

Схема сети

Простая типовая схема, которая довольно часто используется в небольших сетях.

Файрвол одним интерфейсом подключен к Интернет провайдеру.
Ко второму интерфейсу подключен сервер, за которым находится локальная сеть.
На третий интерфейc отдельно вынесен веб-сервер. Это сделано из соображений безопасности, т.к. веб-сервер потенциально более уязвим нежели другие наши службы и поэтому должен быть отделён от остальной сети, чтобы в случае его взлома уменьшить опасность для других компьютеров нашей сети. Кроме взлома сервера нарушить работу сети может и большое количество запросов к нему, в этом плане отделение веб-сервера позволит локализовать подобную проблему.
Зачастую для обозначения отдельного сегмента сети, предназначенного для размещения общедоступных сервисов, применяется термин DMZ (ДМЗ – демилитаризованная зона). Это название используется и в документации к файрволу. В нашем же случае использовано название «www», которое является более простым и наглядным для описываемой схемы.

На внешнем интерфейсе (outside) файрвола имеется один реальный IP-адрес, например 1.2.3.246:255.255.255.252, полученный от провайдера. Адрес со стороны провайдера на нашем соединении — 1.2.3.245, для нас он будет маршрутом по-умолчанию.

На внутреннем интерфейсе (inside) с адресом из приватной подсети 192.168.255.1:255.255.255.252. К нему подключен сервер с адресом 192.168.255.2:255.255.255.252. На второй интерфейс сервера подключена локальная сеть с адресами из сети 10.0.1.0:255.255.255.0.
Доменное имя, используемое в нашей сети, определим как «my.domain.tld».

На третий интерфейс (www) с адресом 192.168.255.5:255.255.255.252, подключен веб-сервер, имеющий адрес 192.168.255.6:255.255.255.252.

Настройка файрвола

После того как схема сети рассмотрена можно перейти непосредственно к настройке файрвола. Подробно будут описаны только моменты, непосредственно касающиеся нашей схемы.

Общие настройки

Первоначальная настройка должна производиться через консольный порт. Затем можно будет управлять файрволом удалённо по протоколу ssh.

Полагаю, что нет необходимости подробно объяснять использование базовых команд, таких как переход в привилегированный режим (enable), просмотр конфигурации (show run), переход в режим конфигурирования (configure terminal), смена имени хоста (hostname) и домена (domain name), установка паролей (passwd и enable password) и т.п. Приведу лишь простой пример:

pix>
pix> enable
Password: *******
pix# configure terminal
pix(config)# hostname pix-gtw
pix-gtw(config)# domain-name my.domain.tld
pix-gtw(config)# clock timezone KGT +6
pix-gtw(config)# clock set 11:59:00 09 dec 2005
pix-gtw(config)# [Ctrl - Z]
pix-gtw# write mem
pix-gtw# quit

При смене имени или домена, например командой «domain-name my.domain.tld», появится следующее предупреждение:

"%Key pair with hostname my.domain.tld will be invalid".

Дело в том, что имя и домен используется при генерировании RSA-ключей, которые необходимы для цифровых сертификатов и подписей, в том числе для подключение по ssh. В этом случае следует перегенерировать и сохранить новые ключи, возможно потребуется сначала удалить старые ключи:

pix-gtw(config)# ca zeroize rsa
pix-gtw(config)# ca generate rsa key 512
pix-gtw(config)# ca save all

Если этого не сделать, то вы не сможете в следующий раз подключиться удалённо, только через консольный порт.

Ключи хранятся в специальной области флеш-памяти, посмотреть их можно командой «show ca mypubkey rsa».

Сохранить текущую конфигурацию в долговременную память можно командой «write mem».
Записать конфигурацию на сервере по tftp-протоколу можно командой:

write net 192.168.255.2:pix-gtw

где 192.168.255.2 — адрес tftp-сервера, а pix-gtw – имя файла.

Сетевые интерфейсы

Интерфейсы имеют аппаратные идентификаторы (hardware_id), например ethernet0. Для каждого интерфейса задаётся его скорость и административное состояние:

interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto shutdown

В данном случае все интерфейсы в режиме автоопределения скорости, при этом последний отключен за ненадобностью.

Кроме аппаратного идентификатора интерфейсы имеют и имя, которое мы вольны задать сами. Вот пример задания имён интерфейсов:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 www security20
nameif ethernet3 not_used security25

Последний параметр — уровень безопасности (security level) нуждается в пояснении. Число от 0 до 100 задаёт уровень безопасности данного интерфейса относительно других интерфейсов — чем выше число, тем безопаснее считается сеть. Это число абстрактно, т.е. само по себе не является показателем безопасности сети. Этот параметр используется системой для определения возможности и способа обмена данными между интерфейсами — для доступа из более безопасной сети в менее безопасную должны использоваться команды nat и global, а для доступа из менее безопасной сети в более безопасную — static и access-list.
Интерфейсы же с одинаковыми уровнями безопасности вообще не могут работать друг с другом.

Указываем IP-адреса на интерфейсах:

ip address outside 1.2.3.246 255.255.255.252
ip address inside 192.168.255.1 255.255.255.252
ip address www 192.168.255.5 255.255.255.252

К сожалению на один интерфейс можно назначить только один адрес.

К интерфейсу можно привязать списки доступа (access-list) для входящего и исходящего направлений, например список доступа 101 для входящего потока на интерфейсе outside:

access-group 101 in interface outside

Сам список создаётся примерно как и на маршрутизаторах Cisco, например:

access-list 101 permit tcp host 4.5.6.100 any eq 22
access-list 101 deny tcp any any eq 22
access-list 101 permit ip any any

Данный пример намеренно упрощён для того, чтобы подчеркнуть его неполноту.

Следует помнить о том, что в списках доступа подразумевается ещё и последнее, неявное правило, которое запрещает весь остальной трафик, для которого не описано подходящего правила.

Статическая маршрутизация

Командой route можно добавить статический маршрут. Формат команды прост:

route имя_интерфейса сеть маска шлюз [метрика]

Нам нужно добавить по-меньшей мере маршрут по-умолчанию, в нашем случае указывающий на адрес 1.2.3.245, и доступный через интерфейс outside:

route outside 0.0.0.0 0.0.0.0 1.2.3.245

Протокол ICMP

Протокол ICMP необходим для нормальной работы сети на базе стека протоколов TCP/IP, но некоторые типы сообщений данного протокола могут быть использованы злоумышленниками для сбора сведений о сети или для нарушения её нормальной работы. Поэтому для внешнего интерфейса файрвола следует разрешить только самые необходимые типы сообщений ICMP, в данном случае, это сообщения о недоступности хоста или сети (unreachable) и сообщения об окончании времени жизни пакета (time-exceeded).
В следующем примере разрешаем весь ICMP на интерфейсе outside для одной сети и одного хоста, затем два типа сообщений на внешнем интерфейсе и весь ICMP на интерфейсах inside и www:

icmp permit 3.4.5.0 255.255.255.0 outside
icmp permit host 4.5.6.100 outside
icmp permit any unreachable outside
icmp permit any time-exceeded outside
icmp permit any inside
icmp permit any www

Доступ к файрволу по ssh

Если файрвол уже соответствующим образом настроен, то к нему можно подключиться по ssh с именем пользователя pix, например:

ssh pix@192.168.255.1

Доступ к файрволу нужно ограничить минимально необходимым количеством хостов. Сделать это можно командой ssh:

ssh 4.5.6.100 255.255.255.255 outside
ssh 192.168.255.2 255.255.255.255 inside

Маска и интерфейс являются необязательными параметрами.

Кроме этого доступ к ssh-порту должен быть открыт и в соответствующих списках доступа.

Сохранение логов на сервере

Для удобства использования и хранения системных сообщений файрвола лучше передать их на syslog-сервер. К примеру передаём логи на хост 192.168.255.2 с идентификатором LOCAL7 (по нумерации файрвола — 23), с уровнем warnings и выше (critical, alerts, emergencies), а также с идентификатором устройства «pix-gtw»:

logging on
logging trap warnings
logging facility 23
logging device-id string pix-gtw
logging host inside 192.168.255.2

На указанном хосте должен быть доступен по сети syslog-демон, а в конфигурации демона должна быть запись для логов с нашим идентификатором, указывающая на существующий файл:

local7.*	/var/log/pix.log

Эти логи будут очень полезны при настройке и отладке конфигурации файрвола.
Не забудьте настроить архивацию этих логов, чтобы они не занимали слишком много места.

NAT и PAT

Трансляции предназначены для того, что дать возможность локальным хостам обращаться к хостами во внешнем мире. Кроме этого трансляции скрывают адреса локальных хостов, что положительно сказывается на безопасности.

В Cisco PIX используются два вида трансляций Network Address Translation (NAT) и Port Address Translation (PAT), которые, в свою очередь, могут быть статическими или динамическими.

NAT позволяет транслировать каждый локальный адрес в соответствующий ему глобальный один к одному. При статическом NAT-е это соответствие задаётся жёстко. При динамическом NAT-е используются свободные адреса из заданного диапазона глобальных адресов (пула). Количество локальных адресов, которые должны транслироваться, должно равняться количеству глобальных адресов.
Данные о соответствии локальных и глобальных адресов хранятся в таблице трансляций. Идентификация трафика производится по соответствию локального и глобального адресов.

PAT позволяет транслировать локальные адреса в один глобальный, случайным образом назначая для каждого соединения новый порт на глобальном интерфейсе. Идентификация трафика производится по соответствию адресов и портов. Статический PAT позволяет задать постоянное соответствие локальных и глобальных адресов и портов.

Механизм работы трансляций достаточно прост – в пакете, полученном от локального хоста, адрес отправителя меняется на глобальный, а в случае использования динамического PAT, также меняется (на случайный) номер порта отправителя. В таком виде пакет и отправляется получателю во внешней сети, который отсылает ответный пакет на указанные адрес и номер порта отправителя. Получив пакет из внешней сети файрвол ищет в таблице трансляций соответствующую запись и, если таковая имеется, модифицирует полученный пакет заменяя глобальный адрес получателя локальным и, в случае динамического PAT, также и номер порта получателя, после этого пакет отсылается локальному хосту.

Практически все прикладные программы могут работать через NAT без каких-либо затруднений, т.к. производится только замена локального адреса, в случае же применения PAT не будут работать некоторые приложения, которые например используют разные порты для входящего и исходящего трафика.

Один из особых вариантов NAT — исключение из NAT (NAT Exemption). Исключение из NAT настраивается командой «nat 0 access-list» и отключает трансляцию для адресов, указанных в списке доступа, т.е. обмен идёт без какой-либо трансляции вообще.

Зависимость трансляций от уровней безопасности интерфейсов

Как уже говорилось выше, способ настройки трансляции зависит от уровня безопасности интерфейсов — для настройки доступа из более безопасной сети в менее безопасную нужно использовать команду nat, а для доступа из менее безопасной сети в более безопасную — static.

Для просмотра уровней безопасности можно воспользоваться командой «show nameif», которая также покажет и имена интерфейсов:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 www security20
nameif ethernet3 not_used security25

Применительно к нашей конфигурации сети можно составить простую табличку:

Таблица трансляций (xlate)

Для трансляции соединений файрвол создаёт таблицу соответствий, которая в терминологии Cisco PIX 520 называется xlate или translation slots. Мы можем посмотреть уже существующие записи в таблице командой «show xlate», а очистить всю таблицу — командой «clear xlate». Кстати, последнюю операцию рекомендуется делать после изменений правил трансляции, но учтите, что это приведёт к разрыву уже установленных соединений если они созданы с использованием какой-либо трансляции.
Для удаления только определённых записей можно указать глобальный или локальный адрес и, если это PAT, то и соответствующий порт:

clear xlate global 1.2.3.246
clear xlate local 192.168.255.6 lport 80

При отсутствии обмена записи в таблице трансляций удаляются по истечении таймаута, который задаётся командой «timeout xlate» и по-умолчанию равен трём часам. Записи для протокола UDP удаляются через 30 секунд после закрытия соединения, независимо от заданного значения таймаута.

Обращения с сервера во внешний мир

Для настройки обращений сервера во внешний мир используются команды global и nat.

Команда global создаёт пул глобальных адресов, т.е. реальных адресов на внешнем интерфейсе, которые использоваться определённой трансляцией. В нашем случае пул состоит только лишь из одного адреса, который непосредственно указан на внешнем интерфейсе файрвола, поэтому мы можем использовать ключевое слово interface вместо собственно IP-адреса.
Следующей командой мы создаём глобальный пул с номером 1 на внешнем интерфейсе, использующий адрес этого интерфейса, т.е. все обращения из этого пула будут уходить во внешний мир с нашего глобального адреса 1.2.3.246:

global (outside) 1 interface

Команда nat позволяет нам указать локальные адреса, которые должны транслироваться, и задаёт соответствие с пулом глобальных адресов, описанным командой global. Следующей командой мы задаём, что обращения с хоста 192.168.255.2, подключенного на интерфейсе inside, будут транслироваться через глобальный пул номер 1:

nat (inside) 1 192.168.255.2 255.255.255.255

Соответствие глобальных и локальных пулов определяется по номеру (NAT ID), который указывается в этих командах.

Всё, можно проверять доступность внешнего мира с сервера.
При изменение правил трансляции не забывайте выполнять команду «clear xlate».

Обращения из внешнего мира к серверу

На нашем сервере есть несколько служб, которые должны быть доступны из-вне, в нашем случае это DNS, SSH, SMTP, FTP.

Для настройки трансляции с интерфейса outside на интерфейс inside используется команда static.
Команда static позволяет задать статическую трансляцию, указав точное соответствие локального адреса и глобального адреса и порта. В качестве порта можно указать его номер или имя. Соответствие номеров и имён портов описано в документации. В конфигурации файрвола все номера портов заменяются их именами, если таковые известны.
Кроме самой команды static необходимые разрешительные правила должны быть указаны в соответствующих списках доступа (access-list).

Синтаксис команды static, используемый в данном случае, достаточно прост:

static (локальный_интерфейс, глобальный_интерфейс) протокол глобальный_адрес локальный_адрес

Так же как в описанном ранее случае использования команды global мы можем в качестве глобального адреса указать ключевое слово interface.

Следующей командой мы задаём статическую трансляцию с глобального интерфейса outside на локальный интерфейс inside для протокола tcp с 25-го порта глобального интерфейса на 25-й порт хоста 192.168.255.2:

static (inside,outside) tcp interface 25 192.168.255.2 25

Применительно к SMTP протоколу нужно упомянуть, что файрвол, из соображений безопасности, изменяет строку приветствия нашего SMTP-сервера, заменяя почти всё звёздочками. Например
из строки:

220 mail.domain.tld ESMTP Sendmail 8.13.0/8.13.0; Mon, 5 Dec 2005 18:01:32 +0600 (KGT)

получается что-то вроде этого:

220 ********************************0******0********** ***200**** *0***0 *0*00 *****

По аналогии с предыдущей командой выполняем следующие:

static (inside,outside) tcp interface 20 192.168.255.2 20
static (inside,outside) tcp interface 21 192.168.255.2 21
static (inside,outside) udp interface 53 192.168.255.2 53

Для настройки подключения к серверу по протоколу ssh придётся использовать отличный от стандартного порт, т.к. 22-й занят самим файрволом. Следующей командой мы задаём соответствие свободного порта на внешнем интерфейсе файрвола (например 222) и стандартного ssh-порта сервера:

static (inside,outside) tcp interface 222 192.168.255.2 22

Теперь при подключении к серверу из-вне нужно будет указать номер порта. Например для клиента из пакета openssh команда будет выглядеть вот так:

ssh -p 222 malik@1.2.3.246

В то время как подключение к самому файрволу будет производиться как обычно:

ssh pix@1.2.3.246

Ну и конечно в списке доступа на внешнем интерфейсе, должны быть соответствующие разрешительные правила для обращений на порты, для которых мы настроили статическую трансляцию:

access-list 101 permit tcp any host 1.2.3.246 eq 20
access-list 101 permit tcp any host 1.2.3.246 eq 21
access-list 101 permit tcp any host 1.2.3.246 eq 25
access-list 101 permit udp any host 1.2.3.246 eq 53
access-list 101 permit tcp host 4.5.6.100 host 1.2.3.246 eq 222

Доступ к веб-сайту из внешнего мира

Вот этой командой мы задаём статическую трансляцию с интерфейса outside на интерфейс www для протокола tcp с 80-го порта внешнего интерфейса на 80-й порт хоста 192.168.255.6:

static (www,outside) tcp interface 80 192.168.255.6 80

В список доступа на внешнем интерфейсе добавляем разрешительное правило для 80-го порта:

access-list 101 permit tcp any host 1.2.3.246 eq 80

Инициировать исходящие соединения с веб-сервера мы не позволяем в целях повышения безопасности веб-сервера. Поэтому более никаких трансляций на внешнем интерфейсе для
этого сервера мы не задаём.

Доступ из локальной сети к веб-серверу

Если из локальной сети доступ к веб-сайту будет осуществляться также как и из внешнего мира, т.е. только по протоколу http и на тот же глобальный адрес (1.2.3.246), то и достаточно будет статической транляции http-порта, но теперь нам нужно будет указать не ключевое слово interface, а именно IP-адрес, под котором мы бы хотели видеть веб-сервер:

static (www,inside) tcp 1.2.3.246 80 192.168.255.6 80

Если же мы хотим чтобы веб-сервер был напрямую доступен с хостов локальной сети и от нашего сервера и обращения к нему вообще не транслировались, то надо использовать конструкцию «nat 0 access-list» и соответствующий список доступа:

nat (inside) 0 access-list 110
access-list 110 permit ip 10.0.1.0 255.255.255.0 host 192.168.255.6
access-list 110 permit ip host 192.168.255.2 host 192.168.255.6

Конечно же файрвол должен иметь маршрут для адресов локальной сети:

route inside 10.0.1.0 255.255.255.0 192.168.255.2

Этот маршрут на файрволе необходим и для взаимодействия веб-сервера с локальной сетью, т.к. файрвол является для веб-сервера маршрутизатором по-умолчанию.

Дополнительные примеры трансляций

Возможно кого-то заинтересуют несколько примеров трансляций, не имеющих прямого отношения к нашей схеме. Соответственно и адреса в примерах не имеют отношения к описанной схеме.

Первый пример

У нас есть несколько глобальных адресов и мы хотим чтобы обращения из внешнего мира на какой-либо их порт транслировались на определённые локальные адреса:

static (inside,outside) tcp 1.2.4.1 80 192.168.0.1 80
static (inside,outside) tcp 1.2.4.2 80 192.168.0.2 80

Второй пример

У нас есть несколько глобальных адресов и мы хотим чтобы все обращения от некоторых локальных хостов уходили во внешний мир со строго определённых глобальных адресов – настраиваем два разных глобальных пула и соответствующие им NAT-ы:

global (outside) 1 1.2.4.1
global (outside) 2 1.2.4.2
nat (inside) 1 192.168.0.1 255.255.255.255
nat (inside) 2 192.168.0.2 255.255.255.255

Т.е. обращения с хоста 192.168.0.1 уйдут во внешний мир с адреса 1.2.4.1, а обращения с хоста 192.168.0.2 уйдут с адреса 1.2.4.2.

А если при этом мы хотим, чтобы ещё и обращения из-вне на определённые глобальные адреса транслировались на соответствующие локальные, то нам надо сделать и обратную трансляцию:

static (inside,outside) 1.2.4.1 192.168.0.1
static (inside,outside) 1.2.4.2 192.168.0.2

В итоге у нас получается двунаправленная трансляция с соответствием глобальных и локальных адресов.

Документация

Вся документация, использованная для настройки файрвола и написания данной статьи, была взята с сайта компании Cisco (http://www.cisco.com/):
1. «Cisco PIX Firewall and VPN Configuration Guide»;
2. «Cisco PIX Firewall Command Reference»;
3. «Using NAT and PAT Statements on the Cisco Secure PIX Firewall».

В качестве прокси использован Squid в режиме http-акселератора. Настройки Squid-а позволяют указать время кеширования, в течение которого запросы не будут передаваться на сервер приложений, а результаты работы скриптов будут отдаваться из кеша так же как и статичные страницы и картинки.

Проблема оказалась в том, что ASP-скрипты не желали кешироваться, и, несмотря ни на какие настройки Squid-а удалялись из кеша сразу после поступления. Таким образом задача по снижению нагрузки на серверы приложений и БД не выполнялась.

Дело было в директиве CacheControl со значением Private, которое выдаётся по-умолчанию, и мне не удалось повлиять на него настройками Squid-а. Изменить значение этой директивы удалось только при помощи дополнительной строчки в ASP-скриптах:

<% Response.CacheControl="Public" %>

По-умолчанию форвардинг выключен, чтобы исправить это положение нужно изменить значение одного ключика в реестре. Вот документ с сайта компании Microsoft, он написан про Windows 2000, но подходит и для XP:

How to Enable TCP/IP Forwarding in Windows 2000 (Q230082)

--------------------------------------------------------------------------------
The information in this article applies to:

Microsoft Windows 2000 , Advanced Server
Microsoft Windows 2000 , Server
Microsoft Windows 2000 , Professional
Microsoft Windows 2000 , Datacenter Server  

--------------------------------------------------------------------------------
IMPORTANT : This article contains information about editing the registry.
Before you edit the registry, make sure you understand how to restore it if a
problem occurs. For information about how to do this, view the "Restoring the
Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help
topic in Regedt32.exe.  

SUMMARY
Transmission Control Protocol/Internet Protocol (TCP/IP) forwarding is disabled
by default in Windows 2000. This article describes how to enable TCP/IP
forwarding on a Windows 2000-based computer.  

MORE INFORMATION
WARNING : Using Registry Editor incorrectly can cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee
that problems resulting from the incorrect use of Registry Editor can be
solved. Use Registry Editor at your own risk.  

For information about how to edit the registry, view the "Changing Keys and
Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete
Information in the Registry" and "Edit Registry Data" Help topics in
Regedt32.exe. Note that you should back up the registry before you edit it. If
you are running Windows NT or Windows 2000, you should also update your
Emergency Repair Disk (ERD).  

To enable TCP/IP forwarding:  

Use Registry Editor (Regedt32.exe) to view the following registry key:  

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Set the following registry value:  

Value Name: IPEnableRouter
Value type: REG_DWORD
Value Data: 1  

NOTE : A value of 1 enables TCP/IP forwarding for all network connections
installed and used by this computer.
For additional information about TCP/IP forwarding, click the article numbers
below to view the articles in the Microsoft Knowledge Base:
Q140859 TCP/IP Routing Basics for Windows NT
Q169415 Routing and Remote Access Release Notes Readme.doc File
Q169548 Using Proxy Server with Routing and Remote Access
--------------------------------------------------------------------------------

Вот собственно и всё.

Малик /20040101/

• циска 2610 c IOS версии 12.2(8)T:

  IOS (tm) C2600 Software (C2600-IS-M), Version 12.2(8)T,  RELEASE SOFTWARE
  (fc2)
  System image file is "flash:c2600-is-mz.122-8.T.bin"

• ADSL-модем Corecess Romance в режиме бриджа;
• свитч 3com;
• ну и компьютер конечно.

PPPoE сервер также был на циске, но думаю это значения иметь не должно.

Для подключение по PPPoE мы должны иметь имя и пароль, выданные нашим провайдером, например имя — oe1919, пароль — Pa$$worD99.

К сожалению указанная модель циски имеет только один Ethernet-интерфейс, поэтому пришлось вешать на нём и PPPoE-клиента, и NAT. Думаю что в случае с циской с двумя Ethernet-интерфейсами настройка сложнее не будет.

Схема подключения

Схема сети проста — циска, компьютер и модем включены в один свитч. Модем, настроен в режим бриджа, т.е. тупо отправляет пакетики с одного интерфейса на другой и наоборот.

Конечно было бы правильнее включить модем в отдельный интерфейс циски, а всю локальную сеть на другой, но второго Ethernet-интерфейса у нас нет.

[-- добавлено 20040613 >>>

А вот если свитч поддерживает ВЛАНы, то можно попробовать отделить ethernet интерфейсы циски и модема в один ВЛАН, а остальную сеть во вторую, при этом циска должна обязательно входить в оба ВЛАНа. У меня не было под рукой умного свитча так что эту схему я не проверял, но думаю всё должно получиться.

<<&lt добавлено 20040613 --]

Настройка циски

Ниже приводится конфиг циски в части, касающейся PPPoE:

!
vpdn enable
!
vpdn-group 1
 request-dialin
  protocol pppoe
!
!
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
 no ip mroute-cache
 no keepalive
 pppoe enable
! использовать интерфейс dialer1 в качестве шаблона:
 pppoe-client dial-pool-number 1
 no cdp enable
!
interface Dialer1
 ip address negotiated
 ip mtu 1492
 ip nat outside
 encapsulation ppp
 no ip mroute-cache
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication pap callin
 ppp pap sent-username oe1919 password Pa$$worD99
!
ip nat inside source list 10 interface Dialer1 overload
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
access-list 10 permit 10.0.0.0 0.0.0.255
!
dialer-list 1 protocol ip permit
!
!

Думаю комментарии здесь не нужны.

На сайте циски можно посмотреть пример для циски с двумя интерфейсами:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080126dc0.shtml

Есть один момент, на сайте циски в конфиге интерфейса Dialer1 указана вот такая строка «ppp authentication pap».

У меня же заработало только с вот такой строкой — «ppp authentication pap callin».

Параметр callin означает «Authenticate remote on incoming call only», т.е. что-то вроде «запрашивать аутентификацию удалённо только на входящие вызовы», если я правильно перевёл указанную фразу.

Если есть необходимость и желание, то можно поиграть параметрами dialer в интерфейсе Dialer1, например «dialer idle-timeout» позволяет указать время простоя перед отключением от PPPoE сервера, думаю что для этого на обеих сторонах соединения не должен быть включен keepalive, либо параметр «dialer persistent» — соединяться даже если нет необходимости, т.е. постоянно быть на связи.

Проверка состояния, сброс сессии

Посмотреть состояние соединения можно командой «show vpdn»:

test_cs#sh vpdn

PPPoE Tunnel and Session Information Total tunnels 1 sessions 1

PPPoE Tunnel Information

VPDN group: 1
Session count: 1

PPPoE Session Information
SID       RemMAC          LocMAC       Intf     VASt  OIntf         VLAN/
                                                                    VP/VC
53306  0001.4232.eed3  0005.5e82.0880  Vi1      UP    Et0/0

Смотрим какие подключения у нас есть:

test_cs#who
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00

  Interface      User        Mode                     Idle     Peer Address
  Vi1                     Virtual PPP (PPPoE ) 00:00:00

А командой «sh int d1″ можно посмотреть адрес выданный нам сервером.

Сбросить сессию можно командой «clear vpdn tunnel pppoe».

Конечно это не все команды, которые могут пригодиться при работе с PPPoE.

Компьютер

На интерфейс компьютера назначаем адрес из сегмента 10.0.0.0/24, и указываем в качестве шлюза по-умолчанию адрес циски на Ethernet-е (10.0.0.1). Проверяем — всё работает — даже «пинги пингуются и тресроуты трейсятся»

Простое подключение циски с одним Ethernet-ом, без NAT-а

Если нам не нужен NAT, а мы хотим просто подключить по PPPoE только саму циску, то конфиг немного упрощается:

!
vpdn enable
!
vpdn-group 1
 request-dialin
  protocol pppoe
!
!
interface Ethernet0/0
 no ip address
 no ip mroute-cache
 no keepalive
 half-duplex
 pppoe enable
 pppoe-client dial-pool-number 1
 no cdp enable
!
interface Dialer1
 ip address negotiated
 ip mtu 1492
 encapsulation ppp
 no ip mroute-cache
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication pap callin
 ppp pap sent-username oe1919 password Pa$$worD99
!
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
dialer-list 1 protocol ip permit
!

Малик.
20031011.

Дополнение от 20060713.

При настройке циски с двумя ethernet-интерфейсами столкнулся с проблемой — у клиентов из ЛАН открывались только некоторые сайты, а в случае с ФТП — только список файлов. Например при подключении telnet-ом на 80-й порт сайта mail.ru с компьютера из локальной сети страничка не отдавалась (таймаут), то же самое с самой циски работало нормально. Подозрение на непроходимость больших пакетов не подтвердилось — пинги с размером пакетов в 1400 байт проходили нормально.

На сайте компании Циско было найдено описание проблемы:
Troubleshooting MTU Size in PPPoE Dialin Connectivity.

Вкратце проблема из-за несоответствия MTU на компьютерах клиентов и серверов (1500) и на PPPoE-соединении роутера (1492), это приводит к тому, что пакеты от сервера размером больше 1492 байт дропаются, а при отфильтровывании ICMP-сообщений сервер не узнает об убиении его пакетов.

Проблема решилась добавлением одной строки в конфигурацию внутреннего интерфейса нашей циски:

!
interface FastEthernet0/0
 description LAN
 ip nat inside
 ip tcp adjust-mss 1452
! именно 1452, а не 1492
!