Enforcer
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В этой ветке andrex задавал вопрос, почему при попытке захода Тотал Коммандером на фтп-сервер зависает окно TC, в котором надпись LIST, а если вырубить Аутпост, то все ок... ему кто-то посоветовал включить в аутпосте Allow Inbound Identification - это неправильный совет, потому что тогда разрешается входящий доступ на 113 порт локального компа, а этот порт к активному режиму фтп отношения не имеет... совершенно правильно Ilich Ramires ответил, что такая трабла с Аутпостом и Тотал Коммандером - это из-за активного режима работы фтп... Поэтому и можно выставить в FTPшных настройках Тотал Коммандера флаг Use passive mode by default, и тогда Тотал Коммандер заработает, но доступ к фтп будет в пассивном режиме... а вот если хочется, чтобы доступ был в актив моде, то надо в правилах Аутпоста для Тотал Коммандера прописать два правила: в первом надо разрешить исходящие TCP-соединения на 21-й порт фтп, а во втором разрешить входящие TCP-соединения с 20-го (удаленного) порта фтп на любой порт локального компа в диапазоне 1024-5000... ну примерно в таком диапазоне. Если второе правило не прописать, то как раз и будет Тотал Коммандер зависать на окне LIST при попытке коннекта с фтп в активном режиме.
Меня весьма заинтересовала также ситуация, когда при загрузке iexplore.exe под другим админовским аккаунтом на самом деле IE не грузится, а вместо этого увеличивается в три раза размер памяти WE... Могу предположить, что каким то образом при попытке загрузки IE в уже запущенный процесс WE загружаются ВСЕ DLL, НЕОБХОДИМЫЕ ДЛЯ РАБОТЫ IE, и с их помощью WE выходит в инет... поэтому соответственно, и увеличивается размер памяти WE... но даже если так, все равно не могу понять, почему не запускается файл iexplore.exe, а вместо этого explorer.exe загружает в свой процесс dll-ки Internet Explorer'а. Действительно, нештатная ситуация.
По поводу лупбэка, что при наличии локальной прокси (АдМюнчер или Проксомитрон) его на форуме усиленно советуют отключать, сняв галку Allow loopback в системных настройках Аутпоста... А по моему так просто лишние заморочки получаются... Приходится прописывать в Аутпосте ДЛЯ КАЖДОГО приложения (для которого в АдМюнчере в Options -> Filter Targets стоит +Opera или допустим +FlashGet) сначала правило, разрешающее исходящие TCP-соединения на удаленный 127.0.0.1 а потом еще одно правило для АдМюнчера, разрешающее доступ на те порты и протоколы, которые нужны этому конкретному приложению... собственно, вся соль в том, чтобы не давать АдМюнчеру доступ куда угодно (в противном случае лупбэк обязательно надо запретить в Аутпосте!), а вместо этого создать в ОП для коровы набор правил, разрешающих всем приложениям, ходящим в инет через корову, доступ на только необходимые порты/протоколы/направления... и тогда можно смело включать лупбэк в ОП, и ОП не будет каждый раз доставать предупреждениями, что такая то прога коннектится с 0.0.0.0 на 127.0.0.1, и не придется создавать лишние правила для каждого приложения с доступом на удаленный 127.0.0.1. В общем я так и сделал, галка Allow loopback в ОП у меня включена, но АдМюнчер имеет доступ строго на те порты и протоколы, которые - в сумме - нужны всем приложениям, трафик которых корова фильтрует (для каждого из этих приложений стоит плюс в Options -> Filter Targets).
Однако, тут есть нюанс. Разрешая для коровы сразу доступ на все порты, которые нужны - в сумме - всем приложениям, ходящим через корову, и не создавая отдельного правила для каждого приложения (с разрешенным лупбэком) получается что если каждое из приложений имеет доступ не только на свои порты, но и на порты других приложений... ведь все эти порты скопом прописаны в правилах для коровы. Поэтому безопаснее всего, все таки запретить лупбэк, создать для каждого приложения свой набор правил с локальным 0.0.0.0 и удаленным 127.0.0.1, но и АдМюнчеру тоже не разрешать доступ куда угодно (не помещать в Доверенные приложения), а для большей безопасности прописать все эти необходимые приложениям порты, и только их.
P.S как бы развить тему про контроль компонентов в Аутпост Про... уж очень мало информации, как фаер это делает... у меня создалось впечатление, что не всегда верно он это делает. а особо не нравится подлянка, когда диалог ОП меня вынуждает либо разрешить доступ неизвестному КОМПОНЕНТУ (а я вот не знаю, что это за компонент другой программы просится в сеть через Оперу или IE! Не хочу давать доступ!), либо запретить доступ ПРИЛОЖЕНИЮ, через которое в сеть просится компонент  Вот ведь гадство, и выбора хорошего у меня нету, только плохой и еще хуже... давать доступ компоненту (или вообще отключить контроль компонентов) - значит рисковать. Нафиг тогда вообще нужен контроль компонентов! А иначе я вынужден запретить доступ всему приложению (Опере или Флешгету) из-за этого неизвестного компонента - тогда риска пустить в инет троянскую DLL нету, но броузер или даунлоадер перестанут работать вообще! За такое разработчикам надо надавать по рукам. Ну неужели так трудно было сделать, чтобы можно было в этом диалоге запретить доступ именно компоненту, а приложение, через которое компонент просится в сеть, чтобы продолжало нормально работать... А еще было бы замечательно, если б открывая Приложения -> Компоненты, можно было бы прямо там разрешать/запрещать доступ в сеть каждому компоненту... а то там ничего сделать нельзя! только удалить компонент из списка, или посмотреть папку, в которой он лежит. |
