Фаервол канального уровня. Но во взаимодействии со сторонними приложениями может и больше, но это уже извращение.

Прикрути к нему IPSec или OpenVPN. через -j LOG включи логирование. Включи полное логирование с OpenVPN/IPSec.

http://www.fstec.ru/_docs/doc_3_3_006.htm

Администрирование: простота использования

Вот это, правда не знаю, как решить :) Разве что какое-нибудь Zeroconf юзать.

Но ты уверен, что это всё можно использовать без соответствующей лицензии сертифированной ФАПСИ компанией? Насколько я знаю, без бумажки, ты - какашка :)

Приведу технические требования до 2го класса:

>> Управление доступом (фильтрация данных и трансляция адресов)

5 4 3 2 1
+ + + + =

5 класс
МЭ должен обеспечивать:
 - фильтрацию на сетевом уровне.

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

4 класс
МЭ должен обеспечивать:
- фильтрацию пакетов служебных протоколов, служащих для диагностики и
  управления работой сетевых устройств;
- фильтрацию с учетом входного и выходного сетевого интерфейса как
  средство проверки подлинности сетевых адресов;
- фильтрацию с учетом любых значимых полей сетевых пакетов.

3 класс
МЭ должен обеспечивать:
- фильтрацию на транспортном уровне запросов на установление
  виртуальных соединений. При этом, по крайней мере, учитываются
  транспортные адреса отправителя и получателя;
- фильтрацию на прикладном уровне запросов к прикладным сервисам. При
  этом, по крайней мере, учитываются прикладные адреса отправителя и
  получателя;
- фильтрацию с учетом даты/времени.

2 класс
МЭ должен обеспечивать:
- возможность сокрытия субъектов (объектов) и/или прикладных функций
  защищаемой сети;
- возможность трансляции сетевых адресов.

>> Идентификация и аутентификация

5 4 3 2 1
- - + = +

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

>> Регистрация

5 4 3 2 1
- + + + =

4 класс
МЭ должен обеспечивать:
- возможность регистрации и учета фильтруемых пакетов.

В параметры регистрации включаются адрес, время и результат фильтрации.

3 класс
МЭ должен обеспечивать:
- регистрацию и учет запросов на установление виртуальных соединений;
- локальную сигнализацию попыток нарушения правил фильтрации.

2 класс
МЭ должен обеспечивать:
- дистанционную сигнализацию попыток нарушения правил фильтрации;
- регистрацию и учет запрашиваемых сервисов прикладного уровня;
- программируемую реакцию на события в МЭ.

Другие требования непосредственно к iptables не относятся. Похоже, что голый iptables тянет только на 4 класс. С бубном - 3й. Мне интересно, что нужно для второго? :)

По поводу лицензии. Именно лицензия и будет сертифицирующим результатом изысканий. Без сертификата оно просто никому ненужно.

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

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

По поводу лицензии. Именно лицензия и будет сертифицирующим результатом изысканий. Без сертификата оно просто никому ненужно.

Думаю, что Вам нужно связаться с FSF (если там есть русские) или пойти на форумы ИБ.

- фильтрацию с учетом любых значимых полей сетевых пакетов.

Вот это я хз. Это тут какое-то околокомпьютерное описание. Если l7-filter возможностей будет достаточно, то да.

фильтрацию на транспортном уровне запросов на установление

виртуальных соединений. При этом, по крайней мере, учитываются
транспортные адреса отправителя и получателя;
Это вообще не совсем понятно. У транспортного уровня (TCP/UDP) используются адреса сетевого уровня (IP). Ну ещё порт, но это без проблем.

- фильтрацию с учетом даты/времени.

?? Изменять правила через cron?

фильтрацию на прикладном уровне запросов к прикладным сервисам. При

этом, по крайней мере, учитываются прикладные адреса отправителя и
получателя;
Это как так? Что такое адреса прикладного уровня? Названия/pid процессов? Если да, то, насколько мне известно, нету ни одной реализации (в смысле, вообще, даже проприетарной), которая может прозрачно узнать, что за процесс на другом конце. Зажимать инетик (или тонко рулить возможностями доступа у удалённым хостам) приложениям можно через linux network namespaces или через прикручивание контекста приложения SELinux к iptables (делается одной коммандой). Но, следует понимать, что оба метода подразумевают наличие на всех компах в сети подобных настроек для контроля доступа конечных приложений. И как Вы этим будете рулить ещё и через маршрутизатор, я хз.

- возможность сокрытия субъектов (объектов) и/или прикладных функций

защищаемой сети;

- возможность аутентификации входящих и исходящих запросов методами,

устойчивыми к пассивному и/или активному прослушиванию сети.
IPSec всей сети. Больше тут никаких простых решений не вижу.

- возможность регистрации и учета фильтруемых пакетов.

В параметры регистрации включаются адрес, время и результат фильтрации.
-j LOG / Snort

- регистрацию и учет запросов на установление виртуальных соединений;

-j LOG + анализатор лога / Snort

- локальную сигнализацию попыток нарушения правил фильтрации.

Видимо, какой-то анализатор лога. Думаю, такие есть. / Snort

- дистанционную сигнализацию попыток нарушения правил фильтрации;

-j LOG + syslog-ng + анализатор лога. / Snort

- регистрацию и учет запрашиваемых сервисов прикладного уровня;

Тут я вообще не понял. Это, скажем, «Вася Пупкин установил соединение к FTP серверу в 12:00» или «Вася Пупки скачивает файл mokrie_pisechki.avi в 13:00»?

- программируемую реакцию на события в МЭ.

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

Возможно, нужно для части функций использовать wireshark совместно со snort.

Что касается IPSec. Насколько я знаю, перехватить тем же снортом пакеты в открытом (незашифрованном) виде нельзя. Поэтому (для огранизации на каждом компе, на шлюзе выход и так будет прозрачным) Вам нужно будет направлять в виртуальный интерфейс пакеты, где их можно перехватить для анализа, а уже потом отправлять в криптотуннель. Возможно, для этого больше подойдёт openvpn с stateless-соединениями.

Опять же, это локальный фаер или на шлюзе? Если на шлюзе, то это через VLAN-изоляцию делается. Если локальный, то можно тупо запретить в iptables всё, что явно не разрешено (обычное дело на нормальных серверах). Или прикрыть какой-то порт. Или разрешить только определенной подсети подключаться. Или использовать knock.


И, если не сложно, можете объяснить что и для чего Вы делаете? Если это продукт, который будет продаваться, то такие вопросы от Вас весьма странны. Если это для внутреннего пользования, то, насколько я знаю, Вам нужно будет ещё заплатить более 100к за экспертизу ФАПСИ (что кто там это будет делать?), чтобы они лицензировали это для внутреннего пользования.



В любом случае отпишитесь. О любом результате тоже отпишитесь.

Ещё можно что-то типа этого ( http://www.cyberciti.biz/faq/linux-detect-port-scan-attacks/ ) использовать.

И вот ещё:
fail2ban

http://hackertarget.com/kippo-honeypot-on-ubuntu-10-04/
http://www.cipherdyne.org/psad/

что нужно для второго? :)

iptables + bash.

iptables + bash

не всё так просто

Думаю, что Вам нужно связаться с FSF (если там есть русские) или пойти на форумы ИБ.

Не-не, FSF тут не при чём. Речь о сертификации решения во ФСТЭК.

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

Я сам хз, как это. Что-то типа прокси наверное должно быть? Т.е. это уже не пакетный фильтр ниразу.

Изменять правила через cron?

Нет, всё проще - фильтровать с учётом времени действия правила. Ну т.е. это можно в ядре сделать, был где-то даже модуль, но в дефолтном iptables этого вроде нет.

Без сертификата iptables/netfilter никакой защищенности по требованиям ФСТЭК не предоставляет.

Я в том плане, что официально о таковой защищенности и использовать для защиты соответствующих данных iptables использовать нельзя.

Ну это очевидно.

Вопрос на самом деле был в том, чтобы понять, что нужно добавить к iptables, чтобы получить удовлетворяющий по классу 2 продукт. Далее - сертификация, далее - продажи и внедрение. Ну сами понимаете ;)

Ну требования достаточно просты :)

- дистанционную сигнализацию попыток нарушения правил фильтрации;

Решаем через syslog на другой сервер.

- регистрацию и учет запрашиваемых сервисов прикладного уровня;

Протоколирование портов там есть :) Если мало, то плагин layer7 для iptables в зубы.

- программируемую реакцию на события в МЭ.

Даже не знаю, но проблем тоже не вижу, какие-нибудь скрипты прикрутить.

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

Вот это поясните, как можно реализовать?

Я не эксперт в этих вопросах, но думаю, что прикладные сервисы - порты UDP и TCP (возможно стоит отнести типы ICMP). Прикладные адреса отправителя и получателя - номера портов источника и назначения.

То, о чём вы говорите имеет отношение к требованию:

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

Да, для сертификации можно использовать ТУ. Поэтому, если что то не фильтруется так как надо, например, какой-нибудь экзотический протокол внутри IP (ESP, AH) на прикладном уровне, то сертификация может не прокатить, т.к. не выполняется фильтрация на прикладном уровне требуемая для данного класса.

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

Насколько я помню у TCP/IP уровни OSI с 4 по 7 находятся в одном объединенном блоке. Поэтому прикладной и транспортный можно отнести на уровень UDP+TCP+ICMP. Думаю подтверждение этому можно найти в каких-нибудь ГОСТах или внутренних документах ФСТЭК/ГТК.

Вот кстати: http://ru.wikipedia.org/wiki/TCP/IP

Правда SSL всегда железно на 6-ом :( то есть не на прикладном.

OK, спасибо за комментарии, я буду разбираться.

Как успехи Ваши?

Пока затихла тема, но из того что успел осознать: 3 класс - сделать довольно просто, во втором вся сложность с «фильтрацией на транспортном уровне». Всем спасибо, возможно ещё вернёмся.

Есть ли какие-нибудь подвижки?

см. выше :) iptables - показатель защищённости по ФСТЭК (комментарий)

поясните

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

Вот это не могу понять что такое. На МЭ должна быть возможность проверки подлинности входящих/исходящих запросов и при этом, данные методы должны быть устойчивы к прослушиванию?

Kerberos, racoon2, ipsec + iptables — это именно то, о чём речь?

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

Вот это требование, похоже, можно выполнить используя NFQUEUE — возможность netfilter, при которой пакет передаётся в usermode для обработки и принятия решения о фильтрации.

В этом случае, достаточно прикрутить соответствующие regex-фильтры (HTTP, FTP, ...).

Ну как? Есть какие-нибудь подвижки?

Подвижки есть.

Касательно требований:

- идентификация и аутентификация — это решается, например, через Kerberos, racoon2, ipsec;

- фильтрация по содержимому — это решается с использованием netfilter + NFQUEUE + l7filter;

- журналирование — это решается с использованием ULOGD из того же netfilter;

- фильтрация с учётом даты/времени — здесь нужен kernel-модуль, его в стандартном iptables нет.