FreeBSD

Опубликовано: | Автор:

NFS-соединение работает по клиент-серверной схеме. Один компьютер является сервером и предоставляет свои файловые системы другим машинам. Это называется “NFS-экспортирование”, а предоставляемые файловые системы называют “экспортами”. Клиенты могут монтировать экспорты сервера почти точно так же как и локальные файловые системы.

Одним из интересных свойств NFS является отсутствие привязки клиента к текущему состоянию сервера (stateless). Вы можете перезагрузить сервер, при этом клиенты не “отвалятся”. Разумеется они не смогут получить доступ к экспортам сервера когда он отключен, однако как только сервер вернется в строй, вы сможете просто продолжить работу с места вашей остановки.

Ядро должно быть собрано с опцией

options NFSSERVER

Создаем файл экспорта /etc/exports, в котором описываются локальные точки системы, доступные для монтирования клиентами.
Мой файл выглядит так

/var/datas -maproot=root -alldirs 10.15.0.9
/var/data -maproot=root -alldirs 10.15.0.9

в моем файле две точки монтирования(/var/datas и /var/data). В одной строке максимум можно прописать три точки. Если их больше, то описываем их в следующей строке, но не более чем три точки на одну строку в файле.

Права доступа на точки экспорта в нашем случае описаны следующим образом:
— maproot=user
Права данного пользователя используются для удаленного подключения как root. Права включают все группы в которые входит пользователь на локальной машине. Может быть представлен по имени или uid (как в нашем примере).

10.15.0.9 – хост которому разрешено монтирование.

Далее делаем запись в /etc/rc.conf и перегружаем машину

rpcbind_enable=«YES»
nfs_server_enable=«YES»
nfs_server_flags=«-t -n 5 -h 10.15.0.2»
mountd_flags=«-r»
mountd_enable=«yes»

Описание параметров
rpcbind
— l – Turn on libwrap connection logging
— h – биндинг адреса для UDP requests (если не указать – будет слушать на всех доступных)
mountd
— r – Allow mount RPCs requests for regular files to be served
nfsd
— h – биндинг адреса
— t – параметр, указывающий обслуживать только TCP-клиентов (если требуется работать по протоколу UDP, следует указать параметр -u)
— n – количество создаваемых серверов

Опубликовано: | Автор:

Ядро должно быть собрано с опцией

options NFSCLIENT

В /etc/rc.conf добавляем

nfs_client_enable=«YES»

Ну и собственно команды для монтирования

/sbin/mount_nfs -T 10.15.0.2:/var/data /var/data/ftp/pub/video1
/sbin/mount_nfs -T 10.15.0.2:/var/datas /var/data/ftp/pub/video2

Опубликовано: | Автор:
Начиная с FreeBSD 10, в базовый состав операционной системы не входит DNS-сервер и его нужно устанавливать из портов отдельно. Этим мы и займемся.
Настройка будет серверная, а потому наш named, как и положено на защищенном сервере, будет резвиться в песочнице и отдавать только свои зоны.

 

Опубликовано: | Автор:

Кратко, rootkit — это набор программ призванный спрятать некую негативную деятельность или присутствие взломщика в системе.

Таким образом, в случае, если на сервере происходит некая посторонняя деятельность (рассылка спама, на сайтах появляются файлы, которые вы не создавали, повышенная нагрузка, которую не понятно что создает), особенно после того, как сервер взламывали тем или иным способом, то стоит попробовать поискать код. Это можно сделать с помощью антивируса или специального ПО для обнаружения руткитов. Наверное, самой известной программой для поиска руткитов является rkhunter.

Установка rkhunter

Будем устанавливать rkhunter 1.4.0 под Debian 7.

В общем-то, установка не должна составить трудностей, так как оказалось, что rkhunter версии 1.4.0-1 есть в официальных репозиториях Debain 7. Устанавливаем:

# apt-get install rkhunter

Либо можно установить вручную скачав архив с официального сайта:

cd ~ wget http://sourceforge.net/projects/rkhunter/files/rkhunter/1.4.0/rkhunter-1.4.0.tar.gz tar xfz rkhunter-1.4.0.tar.gz cd rkhunter-1.4.0 sh installer.sh --layout default --install

Вывод последней команды:

Checking system for:
Rootkit Hunter installer files: found
A web file download command: wget found
Starting installation:
Checking installation directory «/usr/local»: it exists and is writable.
Checking installation directories:
Directory /usr/local/share/doc/rkhunter-1.4.0: creating: OK
Directory /usr/local/share/man/man8: creating: OK
Directory /etc: exists and is writable.
Directory /usr/local/bin: exists and is writable.
Directory /usr/local/lib: exists and is writable.
Directory /var/lib: exists and is writable.
Directory /usr/local/lib/rkhunter/scripts: creating: OK
Directory /var/lib/rkhunter/db: creating: OK
Directory /var/lib/rkhunter/tmp: creating: OK
Directory /var/lib/rkhunter/db/i18n: creating: OK
Installing check_modules.pl: OK
Installing filehashsha.pl: OK
Installing stat.pl: OK
Installing readlink.sh: OK
Installing backdoorports.dat: OK
Installing mirrors.dat: OK
Installing programs_bad.dat: OK
Installing suspscan.dat: OK
Installing rkhunter.8: OK
Installing ACKNOWLEDGMENTS: OK
Installing CHANGELOG: OK
Installing FAQ: OK
Installing LICENSE: OK
Installing README: OK
Installing language support files: OK
Installing rkhunter: OK
Installing rkhunter.conf: OK
Installation complete

Прочие параметры инсталлятора rkhunter вы можете узнать воспользовавшись командой:

sh installer.sh --help

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

Также стоит установить программу unhide, которая позволяет искать скрытые процессы и порты:

apt-get install unhide

Настройка rkhunter

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

Конфигурационные файлы:

/etc/default/rkhunter — можно настроить периодические задачи (обновление, проверка, отчеты),
/etc/rkhunter.conf — основной конфигурационный файл

Справочная информация может быть найдена в директории /usr/share/doc/rkhunter и с помощью команды man rkhunter. Кое-какие скрипты есть в директории /usr/share/rkhunter.

Параметры, которые можно задать в /etc/default/rkhunter (параметры могут принимать значения true или false):

CRON_DAILY_RUN="« — по умолчанию значение true. Позволяет ежесуточно запускать проверку.
CRON_DB_UPDATE=»" — по умолчанию значение true. Позволяет включить еженедельные обновления баз.
DB_UPDATE_EMAIL="false" — отправлять ли отчеты об еженедельном обновлении баз. По умолчанию — false.
REPORT_EMAIL="root" — адрес электронной почты, куда отправлять отчеты. По умолчанию — root.
APT_AUTOGEN="false« — позволяет включить автоматическое обновление баз.
NICE=»0" — позволяет управлять приоритетом процесса.
RUN_CHECK_ON_BATTERY="false" — следует ли проводить автоматические проверки в случае работы компьютера от батареи.

В /etc/rkhunter.conf можно поправить следующие настройки:

PKGMGR=DPKG — судя по документации, в Debian данный параметр особого эффекта не дает, так что можно оставить по умолчанию.
DISABLE_TESTS="apps" — отключает проверку актуальности версий софта, с этим прекрасно справляются разработчики Debian.
SUSPSCAN_DIRS="/tmp /var/tmp" — указываем в какой директории искать подозрительные файлы.
OS_VERSION_FILE="/etc/debian_version" — где искать файл с версией ОС.
USE_LOCKING=1 — позволяет спользовать блокировку для защиты от ошибок в случае если запущено несколько процессов rkhunter в Debian. Может пригодиться, если вы запускаете rkhunter автоматически с помощью cron.
DISABLE_UNHIDE=2 — отключает использование утилиты unhide.rb написанной на ruby.

Подготовка rkhunter к первому поиску руткитов

Перед выполнением проверки нужно выполнить два действия.

Прежде всего, необходимо создать базу знаний о текущих файлах, чтобы потом было с чем сравнивать. То есть необходимо быть уверенным, что система чистая. Лучшим вариантом будет выполнить это действие сразу после настройки системы. База создается командой:

rkhunter --propupd

Базу можно будет найти по следующему пути: /var/lib/rkhunter/db/rkhunter.dat

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

rkhunter --update

Первый запуск

rkhunter -c -sk

Результат:

System checks summary
=====================

File properties checks...
Files checked: 135
Suspect files: 0

Rootkit checks...
Rootkits checked : 309
Possible rootkits: 0

Applications checks...
All checks skipped

The system checks took: 6 minutes and 21 seconds

All results have been written to the log file (/var/log/rkhunter.log)

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

На самом деле вывод более подробный, представлена только финальная часть. Как видно, лог можно найти по пути /var/log/rkhunter.log

Возможные ключи

Команды

-c, --check — выполнить поиск руткитов, результат будет выведен на стандартный вывод, а также в лог-файл.
--unlock — эта комманда просто удаляет lock-файл.
--update — будет произведена проверка на наличие обновления базы знаний. Для работы данной команды требуется, чтобы в системе был установлен один из браузеров командной строки, к примеру, wget или lynx. Желательно выполнять данную команду с некой периодичностью. При использовании в cron стоит использовать также опцию --nocolors.
--propupd [{filename | directory | package name},...] — команда позволяющая добавить в базу данных о файлах системы информацию о файле, всех файлах в директории или пакете. Это необходимо для работы одного из тестов, который сравнивает файл в текущем состоянии с тем, которое было при создании базы. Помните, добавляемый в базу файл должен быть заведомо не зараженным.
--versioncheck — эта команда заставляет rkhunter проверить наличие новой версии программы для поиска руткитов. Браузер командной строки должен присутствовать в системе. Если используется в cron желательно использовать опцию --nocolors.
--list [tests | {lang | languages} | rootkits | perl | propfiles] — эта команда выводит некоторые поддерживаемые возможности программы. Tests — выведет названия доступных тестов, languages — покажет поддерживаемые языки, rootkits — отобразит списки руткитов из базы rkhunter. Perl — выведет список модулей perl которые могут понадобиться в работе rkhunter, список этот не обязательный, но желательный. Установить модули perl можно с помощью команды cpan или утилиты dh-make-perl, которую нужно устанавливать отдельно. propfiles — отобразит список имен файлов, которые использовались для генерации базы файлов. Если никаких опций не задано, то будут показаны все списки кроме propfiles.
-C, --config-check — будет проведена проверка конфигурационных файлов. Проверяются только включенные опции (enabled). Чтобы проверить все опции можно указать --enable all --disable none в командной строке.
-V, --version — будет выведена версия rkhunter.
-h, --help — эта команда отобразить экран с краткой справкой.

Параметры

Различных параметров достаточно много, поэтому мы посмотрим только часть из них. Те, которые показались автору статьи наиболее полезными.

--appendlog — в случае использования данного параметра лог /var/log/rkhunter.log будет дополнен, а не перезаписан. По умолчанию, после того, как rkhunter отработает, основной лог перезаписывается, а предыдущее его содержимое сохраняется в файле rkhunter.log.log, при чем, хранится только один.
--cs2 — основная цветовая схема рассчитана на черный фон. Если же результат будет выведен на экран с белым фоном, то можно использовать альтернативную цветовую схему.
--cronjob — при указании данного параметра будут использованы следующие опции: --check, --nocolors и --skip-keypress, а также не будет вывода в стандартный выход. Поэтому в сочетание с данным параметром можно использовать --report-warnings-only.
--display-logfile — после того, как rkhunter закончит свою работу вывести содержимое лога. Вообще говоря, лог содержит более подробную информацию о найденных проблемах.
--lang — можно указать на каком языке выводить информацию в процессе проверки. Список доступных языков можно получить командой rkhunter --list lang. По умолчанию используется английский.
--logfile [file] — позволяет переопределить файл в который будет писаться лог. При необходимости ничего не писать в лог, можно задать в качестве пути /dev/null.
--nocolors — этот параметр позволяет включить черно-белый режим вывода результатов работы.
--nolog — подавляет запись чего-либо в лог.
--quiet — подавляет любой вывод. Может быть полезно при проверке только кода выхода. То есть если rkhunter используется из скрипта, к примеру.
--report-warnings-only — при этом выводятся только предупреждения. Может быть полезно при запуске через cron. Таким образом, предупреждения будут видны при подключении к серверу с помощью KVM, к примеру.
--sk, --skip-keypress — по умолчанию rkhunter после некоторых наборов тестов просит нажать клавишу “Ввод”. Чтобы таких запросов не поступало можно использовать эту опцию.
--syslog [facility.priority] — по умолчанию в syslog ничего не пишется. Если требуется отмечать время начала и окончания тестирования, можно использовать данный параметр.
--verbose-logging — этот параметр может использоваться, чтобы некоторые тесты писали в лог более подробную информацию. Это может пригодиться для повторного прогона, когда не понятно из-за чего возникло предупреждение. Требует дополнительного времени.

Автоматический поиск руткитов

Чтобы rkhunter начал автоматически проверять систему ежесуточно (у меня проверка начинается в 6:25) достаточно в файле /etc/default/rkhunter установить значение параметраCRON_DAILY_RUN равным true. В данном случае будет использоваться следующая команда:

/usr/bin/rkhunter --cronjob --report-warnings-only --appendlog

Как мы помним, --cronjob подразумевает под собой параметры --check, --nocolors и --skip-keypress. То есть в данном случае rkhunter запускается для проверки системы в черно-белом режиме отображения, не запрашивает каких-либо нажатий клавиш, при этом в консоль выводятся только предупреждения и лог будет дописываться, а не перезаписываться. Так как со временем файл лога будет увеличиваться  в размере, то не забудьте настроить его ротацию.

Если же вы хотите проводить поиск руткитов по другому расписанию и с другими параметрами, то команду запуска можно добавить в cron вручную.

Опубликовано: | Автор:

I. Списки

      Списки позволяют определять множества, имеющие общие признаки в пределах правила — такие как IP адреса, номера портов и т.д. При загрузке наборов правило для списка «раскладывается» на отдельные правила для каждого элемента.

Синтаксис: {элементы_списка}

Замечание: запятая при перечислении элементов необязательна, достаточно пробела.

II. Макросы

Макросы — определяемые пользователем переменные, которые могут представлять собой IP адреса, номера портов, имена интерфейсов, и т.д.

      Имена макросов должны начаться с символа и могут содержать символы,цифры, и символы подчеркивания. Названия макросов не могут носить имена зарезервированных слов, типа pass, out, или queue.

Синтаксис:  <имя_макроса>="<значение>" # определение макроса
            $<имя_макроса>             # вызов макроса

Замечание:

           <значением> могут быть также списки и другие макросы, возможна рекурсия:
           <имя_макроса_списка>="{" <имя_макроса1><имя_макроса2> "}"

 

III. Таблицы

      Таблицы используются для хранения группы адресов IPv6 и/или IPv4.

Синтаксис:  table <имя_таблицы> { список_адресов }
            table <имя_таблицы> file <имя_файла>

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

При определении таблиц могут использоваться следующие атрибуты:

const — содержание таблицы не может быть изменено после ее создания. Без этого атрибута pfctl ( 8 ) может использоваться для добавления или удаления элементов таблицы в любое время, при выполнении с securelevel (7), равным двум и выше.

persist — заставляет ядро сохранять таблицу в памяти, даже когда никакие правила к ней не обращаются. Без этого атрибута, ядро автоматически удалит таблицу, когда последнее правило, ссылающееся на нее будет отработано.

Управление таблицами также может осуществляться на лету, используя pfctl ( 8 ).


Синтаксис:
   pfctl -t <имя_таблицы> -T add    # добавить в таблицу
   pfctl -t <имя_таблицы> -T delete # удалить
   pfctl -t <имя_таблицы> -T show   # вывести на экран ip адреса из таблицы Это
                                    # также откроет таблицу, если она не существует.

IV. Правила фильтрации

Синтаксис: {pass,block}{in,out}[log][quick]on interface[proto{tcp,udp,...}]from SRC_IP[port SRC_PORT] to DST_IP[port DST_PORT][tcp_flags][state]

pass — разрешить
block — запретить
in/out — направление
log — указатель необходимости регистрации пакета через pflog ( 8 ) (регистрируется лишь первый пакет соединения, в противном случае log all)
quick — указатель на то, что список правил далее не должен просматривается и к пакету применяется данное правило
interface — интерфейс
proto — протокол
SRC_IP — источник
SRC_PORT — порт источника
DST_IP — адресат
DST_PORT — порт адресата
tcp_flags — Определяет флаги, которые должны быть установлены в заголовке TCP при использовании proto tcp. Флаги определяются как flags check/mask.
state — Определяет, сохраняется ли информация о состоянии на пакетах, соответствующих этому правилу.

варианты:
keep state — работает с TCP, UDP, и ICMP
modulate state — работы только с TCP. PF генерирует Initial Sequence Numbers (ISNs) для пакетов, соответствующих этому правилу.
synproxy state — проксирует входящие TCP соединения. Эта опция включает функциональные возможности keep state и modulate state.

V. Инициализация управления очередями ALTQ

      Поддержка ALTQ может быть включена только путем компилирования ядра FreeBSD с соответствующими параметрами.

Замечание: ALTQ поддерживается не всеми существующими драйверами сетевых карт. Для просмотра списка поддерживаемых устройств в вашем релизе FreeBSD обратитесь к стравеб сайта PF для FreeBSDнице справочника altq (4).

Следующие параметры включат ALTQ и добавят дополнительную функциональность:

options         ALTQ
options         ALTQ_CBQ        # Class Bases Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build

options ALTQ — включает подсистему ALTQ
options ALTQ_CBQ — включает Class Based Queuing (CBQ). CBQ позволяет распределять пропускную способность соединений по классам или очередям для выставления приоритетов трафика на основе правил фильтрации.
options ALTQ_RED — включает Random Early Detection ( RED ). RED используется для предотвращения перегрузки сети. RED вычисляет длину очереди и сравнивает ее с минимальной и максимальной границей очереди. Если очередь превышает максимум, все новые пакеты отбрасываются. В соответствии со своим названием, RED отбрасывает пакеты из различные соединений в произвольном порядке.
options ALTQ_RIO — включает Random Early Detection In and Out.
options ALTQ_HFSC — включает Hierarchical Fair Service Curve Packet Scheduler. (Дополнительная информация http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html)
options ALTQ_PRIQ — включает Priority Queuing ( PRIQ ). PRIQ всегда пропускает трафик из более высокой очереди первым.
options ALTQ_NOPCC — включает поддержку SMP для ALTQ . Эта опция необходима для SMP систем.

VI. Правила ALTQ

      Правила для очередей также задаются в конфигурационном файле (/etc/pf.conf)

Синтаксис: altq on interface scheduler bandwidth bw qlimit qlim tbrsize size queue {queue_list}

interface — сетевой интерфейс, на котором активируется очередь.
scheduler — какой планировщик будет использован. Доступные значения cbq и priq. На интерфейсе в один момент времени можно установить только один планировщик.
bw — общая пропускная способность, доступная планировщику. Может содержать аббревиатуры b, Kb, Mb, Gb для обозначения bits, kilobits, megabits, и gigabits в секунду, конкретное значение или процент от общей пропускной способности.
qlim — максимальное число пакетов в очереди. Необязательный параметр. По умолчанию — 50
size — размер token bucket regulator в байтах. Если не определен, то устанавливается на основе ширины полосы пропускания.
queue_list — список дочерних очередей, открываемых из родительской очереди.

Очередь определяется следующим образом

Синтаксис: queue name [on interface] bandwidth bw [priority pri][qlimit qlim] scheduler (sched_options) {queue_list}

name — имя очереди. Эта запись должна быть идентична определенной в директиве altq опцией queue_list. Для cbq это также может быть запись имени очереди в предыдущей директиве queue параметре queue_list. Имя не должно быть длиннее 15 символов.
interface — сетевой интерфейс, на котором запущена очередь. Это значение опциональное и если не определено, то очередь будет работать применительно ко всем интерфейсам. bw — общая пропускная способность, доступная планировщику. Может содержать аббревиатуры b, Kb, Mb, Gb для обозначения bits, kilobits, megabits, и gigabits в секунду, конкретное значение или процент от общей пропускной способности. Указывается только при использовании планировщика cbq.
pri — приоритет очереди. Для cbq приоритет изменяется от 0 до 7, для priq диапазон от 0 до 15. Приоритет 0 считается самым низким. Если этот параметр не определен, ему назначается 1. qlim — максимальное число пакетов в очереди. Необязательный параметр. По умолчанию — 50 scheduler — используемый планировщик — cbq или priq. Должен быть таким же, как и родительская очередь.
sched_options — дополнительные опции для управления планировщиком:
default — определить очередью по умолчанию, куда будут включаться все пакеты не подходящие под остальные очереди. Может быть только одна.
red — включить Random Early Detection (RED) для этой очереди.
rio — включить RED с IN/OUT. В этом режиме RED поддерживает очереди различной длины и различные пороговые значения, по одному на каждый уровень IP Quality of Service.
ecn — включить Explicit Congestion Notification (ECN) для этой очереди. Ecn работает совместно с red.
borrow — эта очередь может заимствовать пропускную способность у других очередей. Может быть определено только при использовании cbq.

pfctl -d выключить пакет-фильтр

pfctl -e включить пакет-фильтр
pfctl -f /etc/pf.conf загрузить конфиг из /etc/pf.conf

pfctl -nf /etc/pf.conf проверить на ошибки /etc/pf.conf, но не загружать его
pfctl -R -f /etc/pf.conf загрузить только правила фитрации
pfctl -N -f /etc/pf.conf загрузить только правила NAT
pfctl -O -f /etc/pf.conf load загрузить только опции

pfctl -F all сбросить все
pfctl -F rules сбросить только правила фильтрации
pfctl -F queue сбросить только очереди
pfctl -F nat сбросить правила NAT
pfctl -F info сбросить всю статистику
pfctl -z clear очистить все счетчики

pfctl -s rules показать текущие правила фильтрации
pfctl -v -s rules show показать информацию по каждому правилу фильтрации
pfctl -vvsr показать текущие правила фильтрации с добавлением номера правила
pfctl -v -s nat показать текущие правила NAT отдельно по каждому правилу
pfctl -s nat -i xl1 показать правила NAT для интерфейса xl1
pfctl -s queue показать очереди
pfctl -s state показать текущее состояние таблиц
pfctl -s info показать статистику правил и состояние счетчиков
pfctl -s all показать все что можно

pfctl -t testtable -T show просмотр содержимого таблицы
pfctl -t testtable -T show -v более подробной статистики по каждому адресу
pfctl -t testtable -T add 192.168.1.1 добавление адресов в таблицу
pfctl -t testtable -T delete 192.168.1.1 удаление адресов из таблицы

Опубликовано: | Автор:

Недавно столкнулся с проблемой, настройка двух каналов в интернет на ОС FreeBSD
Ничего абсолютно сложного не предполагалось, но все же пришлось не много почитать документацию.

Собственно задача:

1. создать шлюз с двумя выходами в интернет, один основной, другой резервный.
2. минимизировать участие человека в смене на бек канал.

Инструменты:

ОС FreeBSD 6.x, PF, perl


Решение:

FreeBSD был поставлен с минимальной установкой, единственное изменение, которое нужно сделать
это добавить в ядро модуль PF. Делается это все не сложно.

cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/PF
ee /usr/src/sys/i386/conf/PF

добавляем строчки:
# PF

device pf
device pflog
device pfsync

# ALTQ

options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_PRIQ
options ALTQ_NOPCC

Далее нужно сохранить и пересобрать ядро:

cd /usr/src
make buildkernel KERNCONF=PF
make installkernel KERNKONF=PF
reboot

После загрузки системы нужно подправить /etc/rc.conf
Добавить следующее:

gateway_enable=«YES»
pf_enable=«YES» # Включить PF (загрузить модуль если необходимо)
pf_rules="/etc/pf.conf" # определение правил для pf
pf_flags="« # дополнительные флаги для запуска pfctl
pflog_enable=«YES» # запустить pflogd (8)
pflog_logfile=»/var/log/pflog" # где pflogd должен сохранять протокол
pflog_flags="" # дополнительные флаги для запуска pflogd

сохраняем.

далее нужно прописать правила для PF:

ee /etc/pf.conf

# Main Setting

ext_if_1=«rl0» # IPS_1 — интерфейс первого канала
ext_if_2=«rl1» # IPS_2 — интерфейс второго канал
int_if=«ae0» # lan — интерфейс внутренний сети
lo=«lo0» # loopback

int_net=«172.21.0.0/16» # LAN NETWORK
ext_addr_1=«222.0.0.2» # IPS_1 wan
ext_addr_2=«223.0.0.2» # IPS_2 wan
int_addr=«172.21.0.1» # LAN IP

gw_1=«222.0.0.1» # IPS_1 gw
gw_2=«223.0.0.1» # IPS_2 gw

# services

tcp_svc=«ssh» — разрешенные порты на внешних интерфейсах.

#log — логирование пакетов

set loginterface ae0
set loginterface rl0
set loginterface rl1

# skip iface — не фильтровать loopback,
# многие сервисы используют данный интерфейс под системные вещи.

set skip on lo0

# scrub
scrub in all

# NAT
# Натируем внешние интерфейсы

nat on $ext_if_1 inet from !(self) -> ($ext_if_1:0) # IPS_1 nat
nat on $ext_if_2 inet from !(self) -> ($ext_if_2:0) # IPS_2 nat

# BLOCK ALL
# первоночально необходимо заблокировать весь входящий трафик

block in

# antispoof
antispoof quick for $int_if

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

# IPS_1
pass in on $ext_if_1 reply-to ($ext_if_1 $gw_1) inet proto icmp to ($ext_if_1) tag EXT_IF_A icmp-type echoreq code 0
pass in on $ext_if_1 inet proto icmp from ($ext_if_1:network) to ($ext_if_1) icmp-type echoreq code 0

# IPS_2
pass in on $ext_if_2 reply-to ($ext_if_2 $gw_2) inet proto icmp to ($ext_if_2) tag EXT_IF_B icmp-type echoreq code 0
pass in on $ext_if_2 inet proto icmp from ($ext_if_2:network) to ($ext_if_2) icmp-type echoreq code 0

# allow tcp ports
# разрешаем на внешних интерфейсах сервисы и маршрутизирем их, выше у нас разрешен только ssh
# для udp аналогичная запись за изменением только proto tcp на proto udp

# IPS_1
pass in on $ext_if_1 reply-to ($ext_if_1 $gw_1) inet proto tcp to ($ext_if_1) port { $tcp_svc }
pass in on $ext_if_1 inet proto tcp from ($ext_if_1:network) to ($ext_if_1) port { $tcp_svc }

# IPS_2
pass in on $ext_if_2 reply-to ($ext_if_2 $gw_2) inet proto tcp to ($ext_if_2) port { $tcp_svc }
pass in on $ext_if_2 inet proto tcp from ($ext_if_2:network) to ($ext_if_2) port { $tcp_svc }

# INCOMING ROUTE
# маршрутизирем весь входящий трафик, под условием, если пришел на тот то интерфейс,
# то отправить необходимо ответ с того-то шлюза
# плюс проставляем теги. Теги помогут нам корректно пробрасывать порты,
# допустим у нас есть терминал сервер, пробросить можно следующим образом
# rdr on $ext_if_2 proto tcp from any to $ext_addr_2 port 3389 tag EXT_IF_B -> 172.21.0.1 port 3389
# rdr on $ext_if_1 proto tcp from any to $ext_addr_1 port 3389 tag EXT_IF_A -> 172.21.0.1 port 3389

# IPS_1
pass in quick from ($ext_if_1:network) tagged EXT_IF_A keep state
pass in quick reply-to ($ext_if_1 $gw_1) tagged EXT_IF_A keep state

# IPS_2
pass in quick from ($ext_if_2:network) tagged EXT_IF_B keep state
pass in quick reply-to ($ext_if_2 $gw_2) tagged EXT_IF_B keep state

# FIREWALL
# разрешаем все во внутреннем пространстве шлюза
pass out inet from (self:network)
pass in inet proto icmp to (self:network)

# LOCAL NETWORK
# Разрешаем весь трафик на выход из локальной сети
pass quick on $int_if

# OUTGOING ROUTE
# Маршрутизирем исходящий трафик

pass out route-to ($ext_if_1 $gw_1) inet from ($ext_if_1) keep state
pass out route-to ($ext_if_2 $gw_2) inet from ($ext_if_2) keep state

pass out inet from { $ext_if_1 $ext_if_2 } to (self:network)

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

Далее, необходимо в rc.conf добавить основной шлюз:

ee /etc/rc.conf

defaultrouter=«222.0.0.1»

сохраняем.

Далее нужно поставить пакетик для перла NET_PING:

cd /usr/ports/net/p5-Net-Ping
make install

Далле пишем сам скрипт для переключения каналов в случае падение основного, и обратно в случае поднятия.

Сохраняем скрипт, делаем его исполняемым, и закидываем в крон на исполнение раз в минуту.

Все. Перезагружаемся и у Вас все должно работать.

#!/usr/bin/perl -w

use strict;
use warnings;
use Net::Ping;

# 1 - автоматический режим переключение канала
# 2 - принудительное переключение на второй канал.

my $action = 1;
my $p = Net::Ping->new("icmp");
my $host_gw = "222.0.0.1"; # default gw
my $gw = "223.0.0.1";
my $now = localtime time;

if($action == 1){
my $command = `netstat -rn | grep default`;
my @b = split('s+',$command,3);
if ($p->ping($host_gw,0.05)){
print "host $host_gw is okn";
if($b[1] ne $host_gw){
if($b[1] eq ""){
`route add default 222.0.0.1`;
}else{
`route change default 222.0.0.1`;
open(LOG,">>/change_route.log");
print LOG "[!] $now Route change to 222.0.0.1n";
close(LOG);
}
}
}else{
print "host $host_gw is bad.n";
if($b[1] ne $gw){
`route change default 223.0.0.1`;
open(LOG,">>/change_route.log");
print LOG "[!] $now Route change to 223.0.0.1n";
close(LOG);
}
}
$p->close();
}

if($action == 2){
my $command = `netstat -rn | grep default`;
my @b = split('s+',$command,3);
if($b[1] ne $gw){
if($b[1] eq ""){
`route add default 223.0.0.1`;
}else{
`route change default 223.0.0.1`;
open(LOG,">>/change_route.log");
print LOG "[!] $now Route change to 223.0.0.1n";
close(LOG);
}
}
}

 

 

http://habrahabr.ru/post/66851/