Stak Опубликовано 16 сентября, 2012 · Жалоба Коллеги, кто использует standalone NAT/PAT устройства (Cisco ASA, Juniper SRX, Huawei Eudemon, etc..) и планирует (или уже совершил) переход на РАТ, большая просьба к вам - запросите у вышеозначенных вендоров поддержку РВА (port block allocation). Эта фича сводит объём логов РАТ к объему, аналогичному NАТ. Но на стандалон-NATах её пока никто не поддерживает, только на сервисных картах, интегрируемых в роутеры (такие есть для A9K, MX, и СХ600). Полагаю, если таких запросов будет приличное количество от разных операторов - то шансы, что вендоры реализуют этот функционал на standalone платформах, сильно повысятся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 17 сентября, 2012 · Жалоба Знаете ли вы хоть один согласованный проект по этой схеме с контролирующими органами ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 17 сентября, 2012 · Жалоба Знаю. У нас сейчас и НАТ , и РАТ используется, примерно 300К абонентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 17 сентября, 2012 · Жалоба Почему то все считают что port allocation logging недостаточно, в вашей схеме передаётся destination IP address или только internal/external allocated? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 17 сентября, 2012 · Жалоба для НАТ - передаётся пара internal/external ip, для РАТ - internal/external ip + destination ip для каждой сессии. В случае использования port block allocation - каждому внутреннему ip будет соответствовать внешний ip + блок портов, т.е. одна запись в логе на все трансляции одного абонента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 17 сентября, 2012 · Жалоба В случае использования port block allocation - каждому внутреннему ip будет соответствовать внешний ip + блок портов, т.е. одна запись в логе на все трансляции одного абонента. вот в этом и есть вопрос - у вас это согласовано? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 17 сентября, 2012 · Жалоба Хороший вопрос. Проясню, о результатах отпишусь. upd: Озадачил наших безопасников, проконсультируются с органами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 17 сентября, 2012 (изменено) · Жалоба В случае использования port block allocation - каждому внутреннему ip будет соответствовать внешний ip + блок портов, т.е. одна запись в логе на все трансляции одного абонента. вот в этом и есть вопрос - у вас это согласовано? Коллеги, впишусь в тему. Так же рассматриваем вариант перевода NAT на PBA, планируем собирать логи + netflow v5 с приватной стороны. Решение не очень нравится, но альтернатива только IPFIX, а найти адекватный IPFIX коллектор пока не удалось, кто как решает данную проблему? P.S. Рассматриваем NAT=Jun MX480 Flow=nfdump либо flow-tools Изменено 17 сентября, 2012 пользователем dazgluk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 17 сентября, 2012 · Жалоба Кроме организационного вопроса с PBA был еще один технический вопрос с обычным, не PBA режимом, по крайней мере для сервисных карт: для РАТ - internal/external ip + destination ip для каждой сессии. Если не ошибаюсь, на сервисных картах для ASR9k и подобных, Full-Cone NAT не посылает в нетфлове dst IP, наследуя свойство независимости маппинга для своего типа, и циска только обещает некий функционал DBL, решающий эту проблему. Dst IP наверно можно забрать снимая нетфлов с внутреннего интерфейса и проводя корреляцию с базой трансляций, но это ведь гиморрой. А как у вас ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 17 сентября, 2012 · Жалоба У нас РАТ на cisco ASA или АСЕ , там есть dst адрес в логе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tima Опубликовано 17 сентября, 2012 · Жалоба Решение не очень нравится, но альтернатива только IPFIX, а найти адекватный IPFIX коллектор пока не удалось, кто как решает данную проблему? Я слышал, nprobe работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 18 сентября, 2012 · Жалоба Решение не очень нравится, но альтернатива только IPFIX, а найти адекватный IPFIX коллектор пока не удалось, кто как решает данную проблему? Я слышал, nprobe работает И поля 225 (PostNAT source IP) и 227 (PostNAT source port) логгирует? Интересно, надо попробовать демку Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 19 сентября, 2012 · Жалоба Если верить внутреннему help nprobe, указанные поля он к сожалению не собирает :-( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 21 сентября, 2012 · Жалоба Реализация Deterministic NAT (РАТ) была бы также интересной. http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-04 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 25 сентября, 2012 · Жалоба Уточнил у безопасников: Печалька. ФСБ нам это дело зарубило - формально ссылаются на 538 приказ (необходимо логгировать СОЕДИНЕНИЯ), Кстати, использование NAT (без логгирования по сессиям) этому приказу так же противоречит. Т.е. в текущих российских реалиях - внедрять Port Block Allocation или Deterministic NAT (РАТ) - нельзя. Точнее, можно, но логи по сессиям (с конкретным dst адресом) всё равно собирать надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 сентября, 2012 · Жалоба Уточнил у безопасников: Печалька. ФСБ нам это дело зарубило - формально ссылаются на 538 приказ (необходимо логгировать СОЕДИНЕНИЯ) Вот тут кто-то может прокомментировать, что имелось в виду под соединениями ? В 538 приказе формулировка проста "сведения баз данных о расчетах за оказанные услуги связи, в том числе о соединениях, трафике и платежах абонентов". Это очень похоже на туннельную статистику, которую провайдер выдает своему клиенту, начало сессии, конец, трафик. Почему все кинулись искать скрытый смысл и под соединениями для схемы с NAT понимают соединения с IP на IP, а для схемы без NAT органам достаточно дхцп лиз ? Речь идет конечно об установлении лиц причастных к прошедшим событиям. Для реального времени весь трафик отливается на пробник. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...