WIGF
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
caspara, извиняюсь за запоздалый ответ по поводу твоих правил (я тоже проявлял интерес к ним): очень сложно до конца всё понять, потому что я никогда не пользовался прокси и дома у меня 1 комп. Поэтому и сравнить очень тяжело. Специфические у тебя правила, но они обязательно пригодятся тем, кто в такой конфиграции строит сеть.
В общем, было интересно изучить. Спасибо!
У меня, если не брать стандартные правила, помимо твоих стоят ещё разрешения для DHCP, правила для активного/пассивного ftp-соединения для конкретных серверов и ряд правил снимающих нагрузку на ЦП. В шапке есть ссылка на первоисточник по решению проблемы загрузки ЦП - v2.4 - известные проблемы..., но я всё-таки приведу свои для примера, может кому пригодится (приведу опять же цитатой, как и по VPN, с некоторыми отступлениями и корректировками):
Цитата: Два решения проблемы с сильной загрузкой ЦП:
1. Отключить протоколирование во всех правилах в "Сетевом мониторе" - в результате в журнале будут записываться только срабатывания "Монитора приложений" и всякие атаки и анализаторы.
Но при установке нового приложения очень сложно будет понять то, какие порты для него необходимо открыть и прийдётся опять включать протоколирование (в последнем блокирущем правиле или во всех блокирующих, если их несколько), что не очень то и удобно.
2. Отключение протоколирования во всех разрешающих правилах в "Сетевом мониторе" и создание перехватывающих запрещающих правил без протоколирования.
Т.е. перед последним блокирующим правилом создаём правила блокирующие определённые порты/адреса, но в этом правиле отключаем протоколирование.
В результате получим урезание протоколирования и резкое сокращение нагрузки на ЦП.
Приведу пример своих перехватывающих правил (у меня отключён NetBios, поэтому и правило запрещающее по нему есть):
а) правила по DHCP, NetBios и SSDP (всё собрано в одном правиле):
Код: блокировать UDP В/Из
источник и получатель - любой
порт источника - 67, 68, 137, 138, 1900
порт получателя - 67, 68, 137, 138, 1900 |
б) правила по броадкастам (таких правила у меня 3 штуки):
Код: блокировать UDP В/Из
источник - любой
получатель - броадкаст (255.255.255.255, 10.255.255.255, 10.х.255.255, где х - твоя подсеть
порт источника и получателя - любой |
в) правила по протоколам (таких 2 штуки):
Код: блокировать IP В/Из
источник и получатель - любой
IP-протокол - пользовательский - 139, 241 |
г) правило по 2-м очень популярным для червяков портам:
Код: блокировать TCP/UDP Вх.
источник и получатель - любой
порт источника - любой
порт получателя - 135, 445 |
Правила эти созданы на основе "Журнала". |
Оригинал тут - http://homenet.corbina.net/index.php?s=&showtopic=142254&view=findpost&p=1062948837
Примечание к правилу "2б": внутренние адреса у нас в диапазоне 10.0.0.0/8, подсети по районам 10.x.0.0/16, поэтому и правил по броадкасту несколько.
XenoZ, спасибо. Приятно 
Сам когда-то ставил фаер по этой теме. Очень пригодилось всё, что прочитал тут (ставил где-то в феврале этого года). За это отдельное спасибо!
P.S. XenoZ, добавь ещё в правила по FTP в Сетевом мониторе вот тут - Network Control - ftp-соединение в пассивном режиме.
А то есть общее для обоих типов:
Цитата:| ALLOW TCP OUT FROM IP ZONE:[Internet Zone] TO IP FTP_server WHERE SOURCE PORT IS 1024-4999 AND DESTINATION PORT IS 21 |
Есть для активного режима:
Цитата:| ALLOW TCP IN FROM IP FTP_server TO IP ZONE:[Internet Zone] WHERE SOURCE PORT IS 20 AND DESTINATION PORT IS 1024-4999 |
А для пасcивного нет:
Код:| ALLOW TCP OUT FROM IP ZONE:[Internet Zone] TO IP FTP_server WHERE SOURCE PORT IS 1024-4999 AND DESTINATION PORT IS 1024-65535 |
А то здесь - Настройка персональных файерволов (firewall rules) - есть правила, а в данной теме нет (у меня в настройках в равной степени представлены и те и те правила, поскольку есть и те и те ftp-шники у нас в сетке). |
Всего записей: 1219 | Зарегистр. 19-09-2007 | Отправлено: 10:41 13-11-2007 | Исправлено: WIGF, 17:28 13-11-2007 |
|
). Впрочем, это уже оффтоп... И что такое "стандартные средства"? Имеется в виду дополнительный утиль (вернее, его отсутствие 
)? Тогда при отсутствии следов в журналах придётся ждать повторения ситуации, и понаблюдать за происходящим в мониторе сетевой активности Комода
То, что надо! 
