Заключение

Заключение

Велосипед мы не изобрели, это понятно. Результаты ожидаемы. Использование модуля ядра более опасно, чем обычного data–source ip–traffic, а уже тем более сбора по libpcap или netflow. В случае ошибок или переполнения буферов зависает ядро вместе со всеми процессами, или блокируются все сокеты. Было проведено тестирование на предмет поддержки «нехороших ситуаций» вроде ping–f или nmap–sS–PS 80–iR 100. Однако стабильность работы не гарантируется, тестируйте модуль со всей осторожностью!

Кто–нибудь особенно умный может спросить: «А собственно зачем вы это делали? Фильтровать можно и в ядре, через тот же ipfw deny, pfctl и прочее. Все будет быстро и надежно.»

Возможно. Однако вам придется как–то синхронизировать таблицу юнитов и политик учета с правилами firewall, фактически городить зоопарк скриптов и дублировать одно и то же дважды. Зачем? Использование NeTAMS позволяет хранить всю информацию о правилах в одном месте, без проблем применяя всякие хитрости вроде break flag, prefix table и срабатывание по времени суток. Совершенно прозрачно работают сервисы квот, системные политики, биллинг, и так далее.

Возможные направления улучшения и развития:

• Создать аналогичный продукт для Linux, видимо на базе ULOG

• Сделать поддержку RAW IP пакетов, PPP и так далее

• Проверить работоспособность в случае нескольких модулей ядра, работающих одновременно