orvman
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Spectr
Ай, молодца, даже ссылочку кинул. Если там поискать, то можно найти много чего интересного и любопытного. Всем настоятельно рекомендую.
arta999
Цитата:| SP 1 ставила с сайта майкрософт примерно месяц назад. Версия Оутпост 2.1.303.4009 (314) - работает. Так же работала 2.5 и 2.7 |
Да все правильно, сейчас работает. Я в этом случае имел ввиду лишь первые кандидаты первого пака для сервера. Сейчас официальный SP1 работает вполне нормально.
Цитата: Цитата:В Agnitum Outpost Firewall нет некоторых особенностей, необходимых для сетевого брандмауэра.
каких? к сожалению не сказано... |
Дело в самом ядре брандмауэра и принципе работы. Достаточно вспомнить, что ОР стал пропускать транзиты локали только с версии 2.1. - где опять же нужно сначала было ручками прописывать разрешение. А если взять как реализуется сам NAT и копнуть глубже, то можно найти не только недочеты, но и отсутствие многих фичей и возможностей, характерных для именно серверных брандмауэров. Например, мап портов, запрет скачки типов файлов и т.д. - ОР в данном случае просто в статистике так и будет писать - "Разрешить пакеты NAT" и все тут. То есть либо NAT есть, либо его вообще нет, третьего пока не дано. И на шлюзе методом ОР нельзя привязать клиента локали к конкретным правилам ОР, например, заходить на только определенный сайты и т.д. - все это делается только путем инсталла самого ОР на машине-клиенте в локали и прописывание нужных правил ОР там. Также можно взять во внимание саму реализацию политики ОР. Например, возьмем политику обучения (я уже не говорю о политике блокировки). Во многих случаях - ОР будет тупо блокировать и отбрасывать некоторые потоки протоколов по дефолту, где в статистике будет опять же тупо прописана причина "Режим обучения" и все. Можно приводить еще кучу примеров, если копнуть еще глубже. Это лишь именно поверхностное объяснение. Также, можно вспомнить людей, которые сталкивались с большими проблемами, например, при подключении через VPN (вариантов море). Дело в том, что на сервере часто нужно иметь возможность разрешения по некоторым малоизвестным протоколам на основе IP, глянуть их можно вот так: Параметры - системные - общие правила - параметры - добавить (правило):
Где протокол IP и IP-протокол Не определено - и щелкнуть мышкой. Теперь возьмем во внимание, что большинство потоков для стандартной работы персонального фаера юзает именно протоколы UDP и TCP - в данном случае в ОР имеется свой набор известных ему протоколов - и все неизвестные ему протоколы будут просто баниться. Много еще можно говорить на эту тему. Если взять во внимание, что я не являюсь разработчиком ОР, то, возможно, во многих местах этого объяснения я и ошибся, мне неизвестны многие тонкости работы ОР, тем более, что ОР постоянно видоизменяет свою работу и неизвестно, что ОР ждет в будующем. Здесь я только пояснил все поверхностно.
Цитата: Цитата:на сервере не могут работать некоторые подключаемые модули
интересно какие? у меня все запустились |
См. выше. Могут возникнуть проблемы в плане несовместимости плагинов ОР и самой операционки. Если еще взять во внимание, что плагины ОР имеют самый больший приоритет, перехватывая все потоки данных.
А вот теперь что же касается сервера. Сначала нужно понять, что именно подразумевается под словом "сервер". Именно головная машина локали, где запущена куча внутренних сетевых служб, где крутятся серверные базы данных, есть несколько подсетей + Active Directory + разруливающий NAT и т.д. или просто сама ось Windows 2003 Server с большинством выключенных сетевых служб. Вот поэтому-то и говорилось, что ОР именно на сервере противопоказан, он не нужен там, для этих целей используется другое программное обеспечение, серверное. Конечно, можно поставить и ОР, например, в случае, если стоит локаль с десятком машин, но опять же сначала нужно определиться, что требуется от ОР. Просто работа его в качестве шлюза? У меня на шлюзе стоит именно XPSP2+ОР, ось 2003 в данном случае вообще мне не нужна. Зачем? Лишние проблемы? Проще проставить сервер где-нибудь в локали и все, а клиентам проставить ОР в фоновом режиме и прописать их на машинах как юзеры, а не админы, чтоб особо умные не делали типа "net stop" и т.д. Можно еще в сетке по желанию поставить прокси. В общем, короче говоря, ставить ОР или не ставить это дело твое, я тебя не отговариваю, это дело твое. Я высказал лишь свое мнение.
Цитата: Цитата:Не будут два разных брандмауэра работать вместе и все тут.
Каких конктертно? По поводу встроенного брандмауэра в Traffic Inspector 1.1.3.160rc могу сказать что никаких проблем не наблюдается. C версиями OP 2.1, 2.5, 2.7.
Простенький фаер Atguard стоявший до этого удалила, так как при установке ОП написал, что возможны конфликты. |
Еще раз повторяю не будут. Вот смотри. ОР отслеживает трафик в реальном режиме времени, делает анализ на разрешение/запрет по сетевым интерфейсам машины и т.д., все это видно по журналу ОР. Теперь возьмем во внимание, ну, например, сам Детектор атак. Как он работает. А работает он так. Он просто тупо перехватывает все сетевые пакеты и затем уже делает свой анализ. А для этой реализации сам ОР, естественно, просто обязан прописать в реестре машины свои настройки для истинного перехвата траффика. А теперь представь, что стоит еще один фаер и требует тоже монопольного доступа ко всему трафику машины. Что имеем? А в большинстве случаев имеем несовместимость и т.д., а затем сразу же в 90% BSOD машины, правда есть еще варианты. Да, действительно, не исключено, что многие gate-подобный софт будет работать стабильно вместе с ОР (это доказанные факты), но... Но, тогда, касаемо именно последних версий этого софта+OP в большинстве случаев из-за своих наворотов в принципах защиты работать такие связки не будут вместе. Но, все-таки не исключен факт работы Traffic Inspector и ОР. Тут дело именно в другом варианте реализации принципа работы этой связки. Например, сначала пропускает потоки через себя ОР, делает анализ, если он удовлетворяет правилам и настройкам ОР, то траффик передается уже к Traffic Inspector, где защита машины именно от сетевых атак от него уже не зависит, это иллюзия защиты, в данном случае Traffic Inspector будет лишь также собирать логи, статистику и т.д. А если ОР + такой вот софт встал криво и не в той последовательности самого инсталла и т.д.? Что тогда? А тогда неправильная работа ОР и второго фаера гарантирована, со всеми вытекающими отсюда последствиями. Да и смысл ставить одновременно два фаера на машину? Вот представь себе. Стоит тот же Касперский антивирусный монитор, ну и скажем нортоновский монитор. Что имеем? Два титана, кромсающих друг друга и сообщающих о неизвестном вирусе в оперативочке и т.д., это в лучшем случае, последствия могут быть и другие, все зависит от настроек и версий самих этих мониторов и т.д. А вот теперь вернемся обратно к антивирусу Касперского. Возьмем ту замечательную связку, которые все уже знают и сталкивались с этой неработоспособностью. Если ты не знаешь, что поясню, что в последних версиях этого антивирусника есть такая фича - защита от сетевых атак. Так вот, юзер ни о чем не подозревая, ставит себе ОР+KAV. Что он имеет после инсталла? А имеет то, что в лучшем и в большинстве случаев сетка работает только до первого подключения/отключения, а затем восстановление нормальной работы по сетевым интерфейсам решается перезагрузкой ОР или всей машины (тут нюансы). А как это решается? А решается отключением в KAV этой защиты от сетевых атак. Именно только так и никак больше. Это доказанный факт и куча народа этого форума подтвердит это при необходимости.
А ты сможешь опровергнуть это? Вот поэтому-то я и объясняю, что в большинстве случаев ОР в связке с другими навороченными фаерами работать не будет, либо будет работать неправильно, создавая иллюзию защиты, отсюда и падения системы и т.д.
А теперь вернемся к гейт-подобному софту. Дело в том, что да, действительно, многие админы, например, на шлюзе ставят себе, например, тот же ОР+WinGate, но предварительно отключая в нем многие дополнительные фичи и навороты, оставляя один прокси и уже на шлюзе разруливают NAT и т.д. Для этого достаточно проставить гейт-подобные в Доверенные приложения самого ОР. То есть появляется такая схема. ОР продолжает защищать систему, а весь NAT и т.д. разруливается уже через этот софт.
В общем, исходя из принципов работы всех (!) брандмауэров, два фаера на машине-бред, это совершенно не нужно.
Цитата:| DNS (сразу при установке проги нужно разрешить ДНС для клиентов) |
В смысле кеш-DNS? Если он, то опять же, исходя из принципа работы ОР (он персональный, а не серверный) - кеш распространяется только на машину, где стоит сам ОР, но никак не на сетку.
А если ты имеешь ввиду саму службу DNS для клиентов, то да, это прописные истины, без этого у клиента кина не будет.
Цитата:| Простенький фаер Atguard стоявший до этого удалила, так как при установке ОП написал, что возможны конфликты. |
В принципе установить-то можно все и обходными путями, если тебе нужно или может пригодится, то есть такой в файле outpost.ini в разделе [Interface] ключик DisableFwCheck=no (опять же - за последствия я не ручаюсь)
Цитата: Конкретная ситуация защитить комп от соседей по локалке разрешив им (и себе) доступ к расшаренным ресурсам.
Если проблема не решаема, значит придется продолжать поиски фаера. |
arta999 В смысле? Я не понял суть вопроса.
У меня все работает. Для сетки в ОР галка NetBios стоит. Но фильтрация на вход на шары идет через логин и пароль и именно на то, что я действительно разрешил, а не на все и не всем подряд в локали.
Проверена машина другим сканером XSpider (предварительно в детекторе отключив "блокировать на...", иначе ОР его просто забанит). Открыт только 53 порт для локали и известен mac-адрес (что вполне логично), ничего другого определить не удалось.
А настройки NetBios делаются на уровне операционной системы через учетные записи пользователей для шар машины, а ОР здесь не при чем, оффтоп уже. |
