Ru-Board.club
← Вернуться в раздел «Программы»

» Настройка персональных файерволов (firewall rules)

Автор: Karlsberg
Дата сообщения: 13.04.2004 17:40
eika
Мы конфигурируем правила исходя не из того, кто куда просится, а из того, каким программам мы хотим разрешить работать с инетом.

Цитата:
Атака на DNS

В rfc и еще нескольких источниках указан именно этот диапазон.

Цитата:
что-то отвалится, если заблкировать порт 1025 вообще?

С помощью утилитки TCPView (см. пару постов назад от AntiBIOtic) можно посмотреть кто находится в состонии Listen на этом порту. Если кто-то ненужный - блокируем, иначе оставляем.
Автор: eika
Дата сообщения: 13.04.2004 22:12
miasnikov andrew

Цитата:
Никто, т.к. оба номера в IANA помечены как reserved, т.е. никто не заявлял, что они однозначно используются кем-то.

Да дело не только в теории. Применяет же его MS. Раз применяет, значит масштаб серьезный. Поэтому нужно считаться.

Цитата:
Не было уточнено, открыт порт или нет

Открыт как и в любой другой ОС Windows (по крайней мере в 2K/XP -- точно). Но за ним присматривает фаер и "стучит" мне...

Цитата:
каким образом ты определил, что к тебе кто-то ломится.

А какое это имеет значение?

Цитата:
а лучше задавать конструктивные вопросы.

Как раз я был конструктивен, а вы пятались мне помочь не абстрагировавшись от классической схемы -- раз порт открыт, значит того, кто его открыл можно поймать netstat'ом.

Цитата:
Если понятно, то уже не огульно. Т.к. сетевой экран подразумевает отсев ненужных коннектов. И чем строже политика - тем надежнее защита.

Да мне это все ясно и далеко не ново. Но вопрос то более тонкий, затрагивающий RPC, и, возможно, работу других приложений, которые используют его обычным способом, т.е. через "прослойку" по имени Generic Host Process.

Karlsberg

Цитата:
Мы конфигурируем правила исходя не из того, кто куда просится, а из того, каким программам мы хотим разрешить работать с инетом.

Я не уверен, что из нужного мне софта использует RPC по сети. Узнать это не представляется возможным, используя утилиты мониторинга портов. Причина проста и я ее уже приводил:

Цитата:
Важно то, что порт 1025 используется не приложением напрямую, Generic Host Process'ом (aka svchost.exe). Так что имя приложения тут вам ничего не дает

Надеялся услышать здесь тех, кто пробовал блокировать RPC-порты, например, на серверах. Видимо, придется применять метод научного тыка.

Цитата:
В rfc и еще нескольких источниках указан именно этот диапазон.

Этот, это какой? А можно номер RFC?

Цитата:
С помощью утилитки TCPView (см. пару постов назад от AntiBIOtic) можно посмотреть кто находится в состонии Listen на этом порту. Если кто-то ненужный - блокируем, иначе оставляем.

Читайте выше, задобался повторять.
Автор: bredonosec
Дата сообщения: 13.04.2004 22:33

Цитата:
каким образом ты определил, что к тебе кто-то ломится.
А какое это имеет значение?
- Скажем так, интересно.


Цитата:
Как раз я был конструктивен, а вы пятались мне помочь не абстрагировавшись от классической схемы -- раз порт открыт, значит того, кто его открыл можно поймать netstat'ом.
- Насколько понимаю, порт открыт только тогда, когда на нем висит какой-нить сервис. Или его использует какая-то прога.
Сколько ни сканил свой, никаких портов, окромя используемых (ТСР/УДП, и если какой-нить сервис включен - то и его) видно не было. Тестил на чистой машине - без стенки.

Далее. К вопросу об свхост. Ты навесил весьма длинный список процессов, которые его используют. Хочешь сказать, что все его используют одновременно? Наверно, следующий совет уже понятен: когда вот так ломятся, посмотри, какие процессы работают. Не встроенным, а сторонней утилитой. И пробуй по одному их отрубать. Или блокировать. Метод научного тыка? Возможно. Но их всего штук 10-30. И часть их никаким боком с сетью не связана, другая часть - висит на других портах, так что круг сужается. Если найдешь более быстрый способ - напиши, будем благодарны.
Автор: Karlsberg
Дата сообщения: 13.04.2004 22:56
eika
Если это просьба помочь, то давай немного успокоимся и сбавим пыл. Здесь никто никому ничего не обещал а только по-возможности пытается помочь.

Цитата:
не уверен, что из нужного мне софта использует RPC по сети. Узнать это не представляется возможным, используя утилиты мониторинга портов. Причина проста и я ее уже приводил:
Цитата:
Важно то, что порт 1025 используется не приложением напрямую, Generic Host Process'ом (aka svchost.exe). Так что имя приложения тут вам ничего не дает

Насколько я понимаю, tcp view показывает что svchost.exe слушает на 1025-ом порту. В таком случае в services методом научного тыка можно определить, какой сервис за это отвечает. Или по-другому, с помощью проги process explorer с известного сайта sysinternals.com посмотреть с какими аргументами запущен процесс (id процесса берется из tcp view). Аргумент обычно указывает на функцию, которую сервис выполняет и нафига он, собственно, нужен.

Цитата:
Цитата:
В rfc и еще нескольких источниках указан именно этот диапазон.
Этот, это какой? А можно номер RFC?

В шапочке в сноске как раз говорится об верхнем пределе. Про RFC - неверно в общем, верно для Windows платформ. Вот несколько линков на "забор":
_http://www.zeiss.net.ru/docs/technol/tcpip/tcp01.htm
_http://members.rogers.com/zyklon/tpfold.html
А вот этот уже от мелкомягких, просто вернее не бывает
_www.microsoft.com/siteserver/ssrk/docs/rk_fltrset.doc


Добавлено
bredonosec
Ты ответил пока я тут сочинял
Автор: eika
Дата сообщения: 13.04.2004 23:07
bredonosec

Цитата:
Скажем так, интересно.

Топик то про фаеры. Логично предположить что как раз им им.

Цитата:
Сколько ни сканил свой, никаких портов, окромя используемых (ТСР/УДП, и если какой-нить сервис включен - то и его) видно не было. Тестил на чистой машине - без стенки.

А вы попробуйте на XP Pro запустить TCPView и увидите как минимум несколько вещичек, очевидность предназначениея которых совсем не очевидна

Цитата:
Ты навесил весьма длинный список процессов, которые его используют.

Кого svchost?

Цитата:
Хочешь сказать, что все его используют одновременно?

Если ДА, то думаю, ДА. Потому как ну очень уж много резидентно работающих служб его используют -- даже на рабочей станции минимум 30% из приведеного списка. А максимум на серверах может и до 60..70% подпрыгивать. А может и больше.

Цитата:
Не встроенным, а сторонней утилитой. И пробуй по одному их отрубать. Или блокировать.

А я не уверен, что его открывает к.л. приложение. Этот порт могла открыть и служба RPC, остановка которой невозможна по причинам невозможности продолжения функционирования ОС в нормальном режиме.

Цитата:
Но их всего штук 10-30.

Побольше, но часть из них чиста оффлайновые или проверенные временем.

Цитата:
другая часть - висит на других портах, так что круг сужается

Одно приложение может открывать несколько портов. Тот же RemotelyAnywhere (remotelyanywhere.exe) -- 4 порта.

Цитата:
Если найдешь более быстрый способ - напиши, будем благодарны.

Буду пробовать другой метод научного тыка -- закрою порт и буду искать глюки. Не будет их -- оставлю. Будут -- буду пытаться помнить, про то, что я заткнул RPC-порт и неплохо бы попробовать не из-за него ли

Добавлено
Karlsberg

Цитата:
Если это просьба помочь, то давай немного успокоимся и сбавим пыл. Здесь никто никому ничего не обещал а только по-возможности пытается помочь.

Да не парься ты, все нормально.

Цитата:
Насколько я понимаю, tcp view показывает что svchost.exe слушает на 1025-ом порту. В таком случае в services методом научного тыка можно определить, какой сервис за это отвечает. Или по-другому, с помощью проги process explorer с известного сайта sysinternals.com посмотреть с какими аргументами запущен процесс (id процесса берется из tcp view). Аргумент обычно указывает на функцию, которую сервис выполняет и нафига он, собственно, нужен.

Да я пока другой способ планирую попробовать. Отписал выше.

Цитата:
В шапочке в сноске как раз говорится об верхнем пределе.

Не, в шапке описаны оба предела: 1024-5000.

Цитата:
www.microsoft.com/siteserver/ssrk/docs/rk_fltrset.doc

Вот тут однозначно. Спасибо. Но все же неплохо бы найти в RFC описания алгоритма смены портов серверами DNS.
Автор: Karlsberg
Дата сообщения: 13.04.2004 23:52
eika

Цитата:
Не, в шапке описаны оба предела: 1024-5000.

Я имел в виду сноску под таблицей:

Цитата:
*относительно диапазона локальных TCP портов (1024-5000)- 5000 значение по умолчанию, на NT based может быть изменено
ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters |-> MaxUserPort | тип DWORD | valid значения 5000-65534



Цитата:
неплохо бы найти в RFC описания алгоритма смены портов серверами DNS

Я почти уверен что DNS серверу неважно с какого порта пришел запрос, потому что в первом линке есть инфа об одном варианте юникса, который использует порты начиная с 32000 с кусочком. Он просто шлет ответ на тот порт с которого пришел запрос.
Автор: Spectr
Дата сообщения: 14.04.2004 00:27
eika

Цитата:
А вопросы в связи с этим такие:

1. Нафига все эти клиенты ломятся ко мне на этот порт? Чего им там надо? Вирей, использующих RPC DCOM, чтоли понахватали?

2. Как думаете, что-то отвалится, если заблкировать порт 1025 вообще? Просто у меня не совсем рабочая станция -- на ней стоят еще RemotelyAnywhere и FTP-сервер с возможностью удаленного админимтрирования через клиента.


А можно вернуться к истокам обсуждения после всех этих эмоциональных всплесков.

ЗАЧЕМ тебе RPC вообще??? Для FTP server это не нужно!!!
Для RemotelyAnywhere подозреваю тоже.
У меня RPC (UDP and TCP) запрещены как в системных правилах так и в apllication rules для svchost (outpost firewall)
При этом у меня по-видимому та же конфигурация WinXPPro+ Serv-U with remote administartion (активно администирурю из дома)
Последние 2 месяца активно пользуюсь Remote Administrator и игрался с MS RemoteDesktop (интересно было сравнить)
remotelyAnywhere самую последнюю версию сгрузил в эти выходные и буду в ближайшие дни тестировать, но при беглом чтении документации я не увидел необходимости открывать RPC.

Можно поинтересоваться зачем тебе нужен RPC??? У меня тоже стучаться в него чуть ли не каждую минуту, так как идиотов хватающих вирусы каждый день в сетке нашей организации выше крыши.
Совет - запрети в явном виде все для svchost кроме тех служб что нужны и открывай по мере необходимости.
Так как использую VPN ( virtual private network) то мне пришлось например открыть явно ESP, AH, GRE PPTP protocols, а до этого у меня все они были заблокированы по дефолту.
Автор: bredonosec
Дата сообщения: 14.04.2004 03:02

Цитата:
А вы попробуйте на XP Pro запустить TCPView и увидите как минимум несколько вещичек, очевидность предназначениея которых совсем не очевидна


Цитата:
Если ДА, то думаю, ДА. Потому как ну очень уж много резидентно работающих служб его используют -- даже на рабочей станции минимум 30% из приведеного списка. А максимум на серверах может и до 60..70% подпрыгивать. А может и больше.
- Насчет ХР - повторить не могу, у меня машина не поднимет эту ось. А на моей 98 - открываю процесс вьюером - 15 процессов. Из них - стенка, ИЕ, тотал, монитор антивиря, сам вьюер, блокиратор доступа - штуки сторонние, остается всего 9, из них - експлорер, интернат, ядро(кернел), систрей, таскмонитор, по назначению любому понятны, остается 4 - среди которых и можно плясать, если что. (как пример, действия показываю)
На ХР, насколько с нею игрался (ставя знакомым), сервисов поболее, но в нормальном состоянии (не тогда, когда запущена куча прог/служб/проч), показывало не более 30 процессов. Сервер не ставил, не интересовался, про него говорить не могу. (Вы собираетесь этот сервер использовать, или просто как пример помянули? Если второе - лучше говорите о себе, а не в принципе - легче будет разобрать )

Цитата:
ЗАЧЕМ тебе RPC вообще??? Для FTP server это не нужно!!!
Для RemotelyAnywhere подозреваю тоже.
У меня RPC (UDP and TCP) запрещены как в системных правилах так и в apllication rules для svchost (outpost firewall)
При этом у меня по-видимому та же конфигурация WinXPPro+ Serv-U with remote administartion (активно администирурю из дома)
- Не уверен за точность, но по-моему, читал подобное же предложение у мелких - насчет закрыть РПЦ целиком. (хотя ручаться не могу.. не помню) (((
Автор: miasnikov andrew
Дата сообщения: 14.04.2004 08:43
Spectr
Цитата:
ЗАЧЕМ тебе RPC вообще??? Для FTP server это не нужно!!!
Для RemotelyAnywhere подозреваю тоже.

Ты поосторожней с такими заявлениями - тут щас крику не оберешься со стороны eika

Для нервных надо объяснять, что не все службы связанные с RPC обязательно должны ходить в сеть. А, следовательно, если закрыть им (читай svсhost'у) доступ в интернет, то ничего фактически не произойдет.
И уж ни в коем случае не надо пытаться останавливать RPC как сервис - мало ли чего произойдет на машине (а потом нам всем тут счет выставят и следом касса приедет )

К тому же в этом топике не надо рассуждать про серверные задачи. По данному вопросу - милости просим в Помощь Сисадмину. Персональные фаерволы imho, cтавятся обычно на рабочие станции, а не на Win2k AD
Давайте оставаться в приемлимых рамках обсуждения, pls!
Автор: Spectr
Дата сообщения: 14.04.2004 12:04
miasnikov andrew

Цитата:
не все службы связанные с RPC обязательно должны ходить в сеть. А, следовательно, если закрыть им (читай svсhost'у) доступ в интернет, то ничего фактически не произойдет.
И уж ни в коем случае не надо пытаться останавливать RPC как сервис - мало ли чего произойдет на машине


Обеими руками присоединяюсь: НЕ НАДО ОСТАНАВЛИВАТЬ НИКАКИЕ СЕРВИСЫ, нужно только блокировать их на уровне файервола.
Сам дважды наступал на эти грабли еще на win2k, начитавшись всяких FAQ по оптимизации виндов и остановки ненужных сервисов. А потом через несколько месяцев приходится долго прослеживатьвсе зависимости сервисов или включать все сервисы подряд чтобы заработала свежеустановленная программа.
Автор: ladutsko
Дата сообщения: 14.04.2004 13:56
Доброе время суток!

Разрешите поделиться своими мыслями (предложениями) относительно таблицы в шапке, так сказать вслух:
1. browser - remote out any т.к. может использовать прокси с нестандартным портом. Да и варезные сайты живут, как правило, на нестандартных портах
2. FTP-clients - remote out any по причинам п.1
3. ICQ - remote out any т.к. может использовать прокси, а также сам сайт login.icq.com имеет много больше портов для конекта ...
4. E-mail - забыли про IMAP (tcp 143)
5. MSN Messenger - tcp remote out 1863 Можно указать сайт messenger.hotmail.com
6. IRC - tcp remote out any Но в комплекте с irc идет identd сервер, что требует tcp local in 113
7. SOCKS proxy - tcp remote out 1080

уф-ф-ф-ф-ф ...
пока все
Автор: bredonosec
Дата сообщения: 14.04.2004 14:26
ladutsko

Цитата:
Разрешите поделиться своими мыслями (предложениями) относительно таблицы в шапке, так сказать вслух:
1. browser - remote out any т.к. может использовать прокси с нестандартным портом. Да и варезные сайты живут, как правило, на нестандартных портах
- Если беру что-нить с варезного сайта с нестандартными портами, делаю правило специально под него, и называю наподобие "letout2monster" Когда заканчиваю работу с ним - отключаю (если намерен в ближайшем будущем туда вернуться), или вытираю.
То есть, упор не на максимальное удобство, за счет открытости всего, что может понадобится, а максимальная безопасность, за счет некоторых неудобств при работе с нестандартными. (2-3 - то же)
Для примера могу привести скайп - для устойчивой работы требует разрешения на коннект удаленных портов: на вход - 33033, на выход - 1001-64000, причем для огромной кучи сервов в пределах 24,0,0,0 - 240,0,0,0 (фактически - на любой серв) с локальных из диапазона 1024-5000. (данные точные, проверены опытным путем) Получается, надо все это открыть? Не думаю. И соответственно, ему назначаю отдельное правило, которое отключено, пока не пользую прогу.

с пунктами 4-7 - раз так, то можно и добавить.
Автор: miasnikov andrew
Дата сообщения: 14.04.2004 15:08

Цитата:
6. IRC - tcp remote out any

Не согласен. Уж где-где, а в IRC ты сам прописываешь данные сервера, к которому коннектишься (IP и порт). Так что any - это слишком много для IRC.

Тут полностью согласен с .bredonosec:
если лень для прог узнавать диапазоны IP/портов/протоколов, а разрешать "any" - защита хорошей не будет.
Автор: ladutsko
Дата сообщения: 14.04.2004 15:23
bredonosec
для броузера можно смело добавлять tcp 3128 out


Цитата:
Так что any - это слишком много для IRC

Обычно IRC сервера сидят на tcp 6660-6669,7000
При этом есть еще DCC!
Работает оно подобно ftp в пассивном режиме ...

bredonosec
Кстати, DCC сервер слушает tcp 59
Добавь, плз.
Автор: bredonosec
Дата сообщения: 14.04.2004 19:17
ladutsko

Цитата:
Кстати, DCC сервер слушает tcp 59
- сорьки.. может невыспался, но что-то не доезжаю к какой строке (службе/проге) это относится?
.... ....
Что это за служба? На персоналках идет? //пойду ка я байки.. не соображаю уже..
Автор: eika
Дата сообщения: 14.04.2004 22:31
Karlsberg

Цитата:
Я имел в виду сноску под таблицей:

Это конкретная реализация, причем реализация от MS. Полагать на них в таких вопросах не хочется. Хочется увидеть к.л. документ (например, RFC) где прописан верхний предел.

Цитата:
Я почти уверен что DNS серверу неважно с какого порта пришел запрос, потому что в первом линке есть инфа об одном варианте юникса, который использует порты начиная с 32000 с кусочком. Он просто шлет ответ на тот порт с которого пришел запрос.

Подождите. Причем тут порт (порт клиента), от которого пришел запрос? Речь о локальных портах, на которые приходит ответ (от сервера).

Spectr

Цитата:
ЗАЧЕМ тебе RPC вообще??? Для FTP server это не нужно!!!

Если вы прочтете внимательно мои сообщения, то поймете, что я как раз не уверен, в чем абсолютно прямо и признался.

Цитата:
Для RemotelyAnywhere подозреваю тоже.
У меня RPC (UDP and TCP) запрещены как в системных правилах так и в apllication rules для svchost (outpost firewall)
При этом у меня по-видимому та же конфигурация WinXPPro+ Serv-U with remote administartion (активно администирурю из дома)
Последние 2 месяца активно пользуюсь Remote Administrator и игрался с MS RemoteDesktop (интересно было сравнить)

Первый сдвиг по моему вопросу :)

Цитата:
remotelyAnywhere самую последнюю версию сгрузил в эти выходные и буду в ближайшие дни тестировать, но при беглом чтении документации я не увидел необходимости открывать RPC.

Документация, к сожалению, достаточно поверхностная и не дает ответов на многие вопросы. Планирую поговорить об этом в программах в ближ. время -- присоединяйтесь, я как раз недавно создал тему по RemotelyAnywhere.

Цитата:
Можно поинтересоваться зачем тебе нужен RPC??? У меня тоже стучаться в него чуть ли не каждую минуту, так как идиотов хватающих вирусы каждый день в сетке нашей организации выше крыши.

Вот лично мне он не нужен, поэтому я и спрашивал, что в моем случае может отвалиться и есть ли у кого-то соотв. опыт. Пока высказывались только теоретики. Вы, видимо, первый практик в теме. За что вам спасибо.

Кстати, вы тоже думаете, что тучи клиентов в больших локалах, ломящихся по TCP:1025 -- это зараженные вирями?

Цитата:
А на моей 98

Зачем же сравнивать ОС, построенные на разных ядрах? XP Pro заметно понасыщенне в плане процессов будет, особенно если на нее поставить софтинок так 50, что у меня выполняется в первые несколько дней жизни ОС.

Цитата:
Вы собираетесь этот сервер использовать, или просто как пример помянули?

Я говорил об использовании XP как сервера (моя домашняя машинка и раб. станция и сервер одновременно, хотя последнее эпизодически -- для моих же персональных нужд). Дело в том, что это влечет за собой необходимость поднятия многих служб, которые вообще не нужны на раб. станции (тем более оффлайновой).

miasnikov andrew
Андрей, читайте сообщения внимательнее, ей богу надоедает повторять одно и тоже!

Цитата:
что не все службы связанные с RPC обязательно должны ходить в сеть

Я писал о службах, использующих RPC, но нуждающихся в сети.

Цитата:
(читай svсhost'у) доступ в интернет

А вы пробовали закрыть svсhost'у доступ в интернет? Попробуйте, что ли на досуге...

Цитата:
уж ни в коем случае не надо пытаться останавливать RPC как сервис

А я для чего выше писал, что это невозможно сделать? Или вы хотите поговорить о том, что Windows могла бы быть устроена по-другому и допускала остановку RPC?

Цитата:
К тому же в этом топике не надо рассуждать про серверные задачи. По данному вопросу - милости просим в Помощь Сисадмину.

А давайте говорить о том, что моя машина как раз персональная, но я на ней гоняю сервер, который эпизодически решает определенные задачи. И использую я кстати, персональный Firewall (Outpost), который в данном случае очень хорошо подходит для решения таких задач, т.е. через мою машину не ходят транзитные пакеты, а ориентация программы на фильтрацию пакетов для конкретных приложений тут наоборот очень полезна и позволяет создавать очень эффективные правила (в отличие от классических пакетных фильтров, обычно используемых на серверах). Так что вопрос как раз по теме.
Автор: Karlsberg
Дата сообщения: 14.04.2004 23:00
eika

Цитата:
Хочется увидеть к.л. документ (например, RFC) где прописан верхний предел

В природе не существует. Зависит от реализации.

Цитата:
Подождите. Причем тут порт (порт клиента), от которого пришел запрос? Речь о локальных портах, на которые приходит ответ (от сервера).

Сервак шлет ответ на порт клиента с которого был послан запрос.
Автор: eika
Дата сообщения: 14.04.2004 23:36
Karlsberg

Цитата:
Сервак шлет ответ на порт клиента с которого был послан запрос.

Вы правы. Это я недопонял одну статью... Сейчас все встало на свои места, т.к. если номер удаленного порта задается клиентом, а сервер использует тот же номер порта, то тогда сервер ступудово будет отвечать в диапазоне клиента (1024..5000 при использовании ОС Windows).

Зная это, я бы не задал вопрос

Цитата:
о все же неплохо бы найти в RFC описания алгоритма смены портов серверами DNS.

Спасибо!


Добавлено
Karlsberg

Цитата:
Сервак шлет ответ на порт клиента с которого был послан запрос.

Все же в реальности все не так как на самом деле

Я провел эксперимент под WinXP.

Не секрет, что если ОС перегрузить, то счетчих DNS-запросов сбрасывается. Так вот перегрузил я систему и сделал ручками первый (по показаням фаера) запрос к DNS-серверу из текущего сеанса.

Какие получились противоречия:

1. Локальный порт первого исходящего запроса к DNS-серверу имеет номер 1030, а не 1024.
2. Ответ на этот запрос (см. п. 1) от DNS-сервера приходит не на локальный порт 1030, а на порт 1029. Т.е. работает правило -1. Причем работает совершенно четко -- я пробовал наблюдать за запросами вполть до номеров портов в районе 18xx.

По противоречию #1 есть догадка, что 6 запросов "израсходывались", например, на lookup'ы по loopback (их фаер не сечет).

А из второго противоречия я делаю вывод, то нижнюю границу нужно все же фиксировать номером порта 1023, а не 1024. А верхнюю 4999, а не 5000. Итого 1023...4999.

Что скажете?
Автор: Spectr
Дата сообщения: 15.04.2004 02:17
eika

Цитата:
Кстати, вы тоже думаете, что тучи клиентов в больших локалах, ломящихся по TCP:1025 -- это зараженные вирями?


Категорически нет. Все намного хуже.
Вcе те кто стучался ко мне по 1025 одновременно стучались на SSDP Discovery (5000), Radmin (4899) и еще на 2 или 3 порта из (3127, 2745, 6129).
И выглядит все это очень некрасиво. 4899 это как раз то через что можно получить полное управление моим компьютером. И когда человек стучится ко мне все по 3-5 портам и три из них могут дать remote access (1025,4899,5000) я одназначно воспринимаю как недружелюбный акт.

А вот какие трояны могут использовать 1025, 5000
http://www.pcflank.com/ports_services.htm

Port/Protocol:
1025/TCP
Service:
blackjack
Description:
Network game Blackjack
Trojans using this port:
NetSpy (SysProtect98), Prosiak

--------
Port/Protocol:
5000/TCP
Service:
ssdppsrv
Description:
This component provides the Simple Service Discovery Protocol sevice used for for Universal Plug and Play. It also provides General Event Notification Architecture (GENA) service.
Trojans using this port:
BioNet Lite, Sockets De Troje

-----------------
Автор: TILK
Дата сообщения: 15.04.2004 08:57
bredonosec

Цитата:
Если беру что-нить с варезного сайта с нестандартными портами, делаю правило специально под него, и называю наподобие "letout2monster" Когда заканчиваю работу с ним - отключаю...
То есть, упор не на максимальное удобство, за счет открытости всего, что может понадобится, а максимальная безопасность, за счет некоторых неудобств при работе с нестандартными.

Что-то не пойму твоей логики : ты закрываешь "исходящие" порты для того, чтобы было "безопаснее", хотя они (я имею ввиду нестандартные) открываются только на момент связи. Т.е. ты выполняешь бесполезную работу. Кроме того, в большинстве файрволов имеется привязка портов к приложениям (в отличии от пакетных фильтров). Ты же не пакетным фильтром пользуешься? Если FTP-клиент открыл соединение, скажем, по 12345-му порту, то злоумышленник уж никак не свалит DCOM через 12345-й порт, потому что это события никак не связанные между собой, а на FTP-клиенты, на сколько я знаю, опсных уязвимостей нет.
Автор: ladutsko
Дата сообщения: 15.04.2004 09:24
bredonosec

Цитата:
Что это за служба? На персоналках идет?

DCC сервер идет в составе IRC
Автор: miasnikov andrew
Дата сообщения: 15.04.2004 11:13
eika
Цитата:
Андрей, читайте сообщения внимательнее, ей богу надоедает повторять одно и тоже!
приехали...
Тогда давай(те) по порядку (хотя мы тут все на ты...)
какие серверы подняты? список в студию.
F то мы до бесконечности будем обсуждать, использует ли какой-то гипотетический процесс RPC и как быстро он загнется, если svchost прикрыть файерволом.


Цитата:
А вы пробовали закрыть svсhost'у доступ в интернет? Попробуйте, что ли на досуге...
Специально из духа экспериментаторства закрыл файром на уровне глобальных правил и поставил запись фильтруемых пакетов (Sygate Pers.Pro 5.5 build 2525).
Перезагрузился. Подключился к SMB-серверу в локалке, прочитал e-mailы и сейчас пишу сюда.
Фантастика? или файервол не работает?

TILK

Цитата:
Что-то не пойму твоей логики : ты закрываешь "исходящие" порты для того, чтобы было "безопаснее", хотя они (я имею ввиду нестандартные) открываются только на момент связи ...
Если FTP-клиент открыл соединение, скажем, по 12345-му порту, то злоумышленник уж никак не свалит DCOM через 12345-й порт, потому что это события никак не связанные между собой, а на FTP-клиенты, на сколько я знаю, опсных уязвимостей нет.

По-моему, имеется в виду, что надо ограничивать порты, на которые ходят приложения. Т.е. браузеру при прочих равных условиях совсем не нужно подключаться на удаленный порт 4899 (обычно это radmin server слушает), верно?
А если порт web-сервера не 80 или 443, а 4899. Что делать?
Соответственно, такие послабления надо вводить как временную меру.
Автор: bredonosec
Дата сообщения: 15.04.2004 12:22
TILK

Цитата:
Что-то не пойму твоей логики : ты закрываешь "исходящие" порты для того, чтобы было "безопаснее",
- Именно. Вы не поняли. У меня в настройках стены порты не делятся на входящие и исходящие. Правило может запретить соединение на тот или иной локальный порт, или с тем или иным удаленным портом любого адреса ,или конкретного их диапазона. То есть, если тот или иной порт открыт, то он открыт и на вход и на выход. И пользоваться им может не только прога, для которой правило сделано, но и любое другое. (оговорюсь, контроль приложений (ЗА)в данный момент не пользую). Теперь смысл ясен?
Разумеется, есть в стенке страховка - stateful inspection, - проверка, был ли мой запрос, по которому должно отвечать с этого адреса по этому порту/диапазону, но предпочитаю явно указывать запрещенные и разрешенные диапазоны.
Автор: Spectr
Дата сообщения: 15.04.2004 18:24
Есть ли у кого какие соображения по-поводу в каких случаях стоит включать Statefull Inspection? (Я полагаю это есть во всех фаерах не тольеко в аутпосте)
По умолчанию это включено только для FTP clients and Download Manager (FTP section).

Есть ли еще случаи когда это стоит делать?
Раз уж мы ужесточили правила для всего остального (svchost,DNS, eMule)по сравнению с дефолтными, может и здесь есть резервы.

Автор: Karlsberg
Дата сообщения: 15.04.2004 22:02
А кто-нибудь знает, что точно делает Statefull Inspection? Был бы очень благодарен за обьяснения нормальным русским языком.
Автор: eika
Дата сообщения: 15.04.2004 22:44
Spectr

Цитата:
Категорически нет. Все намного хуже.
Вcе те кто стучался ко мне по 1025 одновременно стучались на SSDP Discovery (5000), Radmin (4899) и еще на 2 или 3 порта из (3127, 2745, 6129).
И выглядит все это очень некрасиво. 4899 это как раз то через что можно получить полное управление моим компьютером. И когда человек стучится ко мне все по 3-5 портам и три из них могут дать remote access (1025,4899,5000) я одназначно воспринимаю как недружелюбный акт.

С этим вопросом все понятно. Будем наблюдать за этими

Спасибо за инфу.

Добавлено
miasnikov andrew

Цитата:
F то мы до бесконечности будем обсуждать, использует ли какой-то гипотетический процесс RPC и как быстро он загнется, если svchost прикрыть файерволом.

Я говорил, что для начала пойду другим путем. Что собсно и сделал -- закрыл 1025 порт, пока полет нормальный.

Цитата:
Специально из духа экспериментаторства закрыл файром на уровне глобальных правил и поставил запись фильтруемых пакетов (Sygate Pers.Pro 5.5 build 2525).
Перезагрузился. Подключился к SMB-серверу в локалке, прочитал e-mailы и сейчас пишу сюда.
Фантастика? или файервол не работает?

Все фаеры работают по разному. Не знаю как Seagate, но Outpost руководствуется правилом для приложения, даже если иное оговорено в глобальных правилах.

Без svchost.exe не будет работать, например, DNS-резолвинг для IE. Т.е. если вы правильно запретили сетевую деятельность для svchost.exe, то хосты будут недоступны при обращении к ним по DNS-именам (ессно, что предшествующие обращения к этим же DNS-именами не должны быть закэшированы к.л. способом).

Для проверки предлагается такая последовательность действий:

Запретить сетевую деятельность для svchost.exe, перегрузить ОС, открыть браузер и обратиться по HTTP к к.л. хосту по DNS-имени, например, http://www.whitehouse.gov Если сайт откроется, то вы неверно настроили фаер и наоборот.

Ессно, что потом не помешает проверить лог фаера, чтобы не допустить никаких ошибок.
Автор: Spectr
Дата сообщения: 15.04.2004 23:41
Karlsberg

Цитата:
А кто-нибудь знает, что точно делает Statefull Inspection? Был бы очень благодарен за обьяснения нормальным русским языком.


Нашел но только на английском. Sorry!

http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=7443
Автор: Karlsberg
Дата сообщения: 16.04.2004 00:09
Spectr
Ничего, это мы могем Спасибо!

Прикольно, что Statefull Inspection, оказывается, запатентована чекпоинтом, значит другие файеры делают или что-то похожее, или что-то другое.

Цитата:

Applications where SPI could be used
Any file transfer protocol (FTP) application;
Internet telephony and teleconferencing;
Internet Relay Chat (for distributed client connections - DCC);

Я так понимаю, что во всех других случаях Statefull Inspection бесполезен.
Автор: miasnikov andrew
Дата сообщения: 16.04.2004 09:00
eika
вообще-то у меня (судя по логам Sygate) svchost ходит (пытается ) на time.windows.com:123, на сервак на 1900 порт, и (что очень странно!) по локалке на 80е порты...
вот последнее - фигня какая-то. Может, кто знает, зачем ему веб-сервера?

a DNS сверяется (резолвится) сетевым драйвером ndisuio.sys
возможно поэтому все не обломалось при отключении svchost.exe от сети.
Автор: spike
Дата сообщения: 16.04.2004 09:54
по поводу RPC

видел в инете прогу (вроде есть у меня) от мелкософта, она делает так, чтобы работать RPC мог только с localhost


по воводу DHSP и DNS
у знакомой остановил службы эти и нормально она работает в инете на динамическом ip

Страницы: 12345678910111213141516171819202122232425262728293031323334353637

Предыдущая тема: Не устанавливается


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.