А не пропушить ли нам вендоров standalone NAT/PAT на поддержку PBA?

[Stak]

Коллеги, кто использует standalone NAT/PAT устройства (Cisco ASA, Juniper SRX, Huawei Eudemon, etc..) и планирует (или уже совершил) переход на РАТ, большая просьба к вам - запросите у вышеозначенных вендоров поддержку РВА (port block allocation).

Эта фича сводит объём логов РАТ к объему, аналогичному NАТ.

Но на стандалон-NATах её пока никто не поддерживает, только на сервисных картах, интегрируемых в роутеры (такие есть для A9K, MX, и СХ600).

 

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

[rus-p]

Знаете ли вы хоть один согласованный проект по этой схеме с контролирующими органами ?

[Stak]

Знаю. У нас сейчас и НАТ , и РАТ используется, примерно 300К абонентов.

[ingress]

Почему то все считают что port allocation logging недостаточно, в вашей схеме передаётся destination IP address или только internal/external allocated?

[Stak]

для НАТ - передаётся пара internal/external ip, для РАТ - internal/external ip + destination ip для каждой сессии.

 

В случае использования port block allocation - каждому внутреннему ip будет соответствовать внешний ip + блок портов, т.е. одна запись в логе на все трансляции одного абонента.

[ingress]

В случае использования port block allocation - каждому внутреннему ip будет соответствовать внешний ip + блок портов, т.е. одна запись в логе на все трансляции одного абонента.

 

вот в этом и есть вопрос - у вас это согласовано?

[Stak]

Хороший вопрос. Проясню, о результатах отпишусь.

 

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

[dazgluk]

В случае использования port block allocation - каждому внутреннему ip будет соответствовать внешний ip + блок портов, т.е. одна запись в логе на все трансляции одного абонента.

 

вот в этом и есть вопрос - у вас это согласовано?

Коллеги, впишусь в тему.

Так же рассматриваем вариант перевода NAT на PBA, планируем собирать логи + netflow v5 с приватной стороны.

Решение не очень нравится, но альтернатива только IPFIX, а найти адекватный IPFIX коллектор пока не удалось, кто как решает данную проблему?

 

P.S. Рассматриваем NAT=Jun MX480 Flow=nfdump либо flow-tools

Edited September 17, 2012 by dazgluk

[rus-p]

Кроме организационного вопроса с PBA был еще один технический вопрос с обычным, не PBA режимом, по крайней мере для сервисных карт:

 

для РАТ - internal/external ip + destination ip для каждой сессии.

 

Если не ошибаюсь, на сервисных картах для ASR9k и подобных, Full-Cone NAT не посылает в нетфлове dst IP, наследуя свойство независимости маппинга для своего типа, и циска только обещает некий функционал DBL, решающий эту проблему.

Dst IP наверно можно забрать снимая нетфлов с внутреннего интерфейса и проводя корреляцию с базой трансляций, но это ведь гиморрой.

А как у вас ?

[Stak]

У нас РАТ на cisco ASA или АСЕ , там есть dst адрес в логе.

[Tima]

Решение не очень нравится, но альтернатива только IPFIX, а найти адекватный IPFIX коллектор пока не удалось, кто как решает данную проблему?

 

 

Я слышал, nprobe работает

[dazgluk]

Решение не очень нравится, но альтернатива только IPFIX, а найти адекватный IPFIX коллектор пока не удалось, кто как решает данную проблему?

 

 

Я слышал, nprobe работает

И поля 225 (PostNAT source IP) и 227 (PostNAT source port) логгирует? Интересно, надо попробовать демку

[dazgluk]

Если верить внутреннему help nprobe, указанные поля он к сожалению не собирает :-(

[Stak]

Реализация Deterministic NAT (РАТ) была бы также интересной.

http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-04

[Stak]

Уточнил у безопасников:

Печалька. ФСБ нам это дело зарубило - формально ссылаются на 538 приказ (необходимо логгировать СОЕДИНЕНИЯ), Кстати, использование NAT (без логгирования по сессиям) этому приказу так же противоречит.

Т.е. в текущих российских реалиях - внедрять Port Block Allocation или Deterministic NAT (РАТ) - нельзя. Точнее, можно, но логи по сессиям (с конкретным dst адресом) всё равно собирать надо.

[rus-p]

Уточнил у безопасников:

Печалька. ФСБ нам это дело зарубило - формально ссылаются на 538 приказ (необходимо логгировать СОЕДИНЕНИЯ)

Вот тут кто-то может прокомментировать, что имелось в виду под соединениями ?

 

В 538 приказе формулировка проста "сведения баз данных о расчетах за оказанные услуги связи, в том числе о соединениях, трафике и платежах абонентов".

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

Почему все кинулись искать скрытый смысл и под соединениями для схемы с NAT понимают соединения с IP на IP, а для схемы без NAT органам достаточно дхцп лиз ?

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