куча входящих запросов, и опять же p2p.
-
Доброго всем времени суток. Прошу сильно не критиковать если где банальные ошибки допускаю, я только учусь.
Есть сеть, юзеров 50, один сервак на WIN2008, с ДХЦП, ДНС, маршрутизацией.. соотвественно он и был маршрутизатором.
Появилось желание поставить pf между серваком и провом, установил на отдельный комп. Обычно все настраиваю по минимуму, не заморачиваясь с настроиками, как есть по дефолту, так и работает. так и тут, настроил ДХЦП на pf.
На WIn2008 отключил ДХЦП и маршрутизацию.
Локалка 192.168.0.ХХХ\24, инет проводной, 176.197.ХХХ.ХХХ\30
Вот такие настройки.
Собственно теперь что не нравится мне.
В логах такая херня творится.
И продолжается это с момента запуска pf. Кстати до этого на 53 порт ломились, думал что что то с ДНС,
Подскажите куда копать?? Хостов которые шлют на меня запросы порядка 20.
И еще одно..
Пробросил я пару портов для p2p клиента местной сети (О-ГО клиент) использует он TCP 10853 и UDP 6308, порт TCP при запуске программы открывается, и она на этом виснет, UDP остается закрытым, через Flylink я к хабу прова подключился, там один порт открыл и все пошло, и поиск и скачивание, а вот местный клиент не в какую не хочет, почему порт UDP не открывается??
netatst выдает следующее по этому процессу
Имя Локальный адрес Внешний адрес Состояние PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 8388
TCP 0.0.0.0:10853 0.0.0.0:0 LISTENING 8388
TCP 127.0.0.1:56776 127.0.0.1:1110 CLOSE_WAIT 8388
TCP 127.0.0.1:56778 127.0.0.1:1110 CLOSE_WAIT 8388
TCP 192.168.0.11:56785 212.75.210.102:80 CLOSE_WAIT 8388
TCP 192.168.0.11:56786 212.75.210.101:80 CLOSE_WAIT 8388
UDP 0.0.0.0:6308 : 8388
UDP 127.0.0.1:65111 : 8388Открывал абсалютно все порты, эксперементировал, не хочет подключатся..
Понимаю что тем по поводу пробросса портов куча, и т.д. но я уже кучу их прочитал, и решения так и не нашел.
заранее спасибо, (если с картинками какая фигня то извените). -
1. На скрине fw на LAN правило №4 снизу - лишнее и тольку от него - нуль, т.к. адрес 192.168.0.1 находится в Вашей же сети (и это не адрес pfsense даже)
2. По поводу логов fw. Как вариант (с вероятностью 99%) - у кого-то в вашей локалке работает софт (п2п-клиенты etc), к-ый коннектится к адресам , к-ые вы видите в логах, а т.к. проброса портов для локальных адресов коннектящихся клиентов нет, то и получается та ситуация, к-ую вы наблюдаете.
Для того, чтобы такого не было - отключайте последнее правило.Это плохой тон, как по мне, разрешать пользователям выход в инет по всем портам (не забываем про вирусы). Обойдите всех пользователей , узнайте кому какие сервисы нужны (и нужны ли вообще ?), разрешите только эти сервисы в правилах fw. Ваша политкика - запрещено всё , что не разрешено. Будут возмущаться недоступностью игрушек, п2п и т.д. - пускай пишут объяснительную начальству. Поверьте, весь пыл сразу сходит на нет ;D
3. Насчет Flylink . Хаб провайдера случаем не "серый" адрес имеет ? Если так - отключите в fw на WAN самое первое правило.
Как вариант - смените программу-клиента.P.s. И отберите у пользователей права локального администратора, если у кого они есть\остались.
-
Спасибо за ответ и за советы.
По поводу правил fw на Lan это после эксперемента остались, кто то посоветовал, что надо открыть диапозон портов для п2п в момент его работы, а потом якобы закрывать. А так вроде пользователи у меня работают по портам каторые в алисе разрешенны..
По поводу правила с портом 9780 спасибо)) Носом ткнули и сообразил что оно не нужно)) В пропали запросы по диапозону портов (и еще раз большое спасибо) .Только вернулась проблема с ДНС Вот такая картина в логах… Адресса источники меняются время отвремени.. пробовал создавать блок-правила что бы в логи не попадала эта инфа, но адресса тут же меняются, и как бы понятно что так проблему не решить, закрыв на нее глаза..
Act Time If Source Destination Proto
block Sep 12 15:26:06 WAN 183.60.108.152:33252 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:17688 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:49889 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:17688 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 LAN 192.168.0.1:50422 192.58.128.30:53 UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:49889 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:49889 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:07 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDP
block Sep 12 15:26:08 WAN 183.60.108.152:1051 176.197.ххх.ххх:53UDPПо поводу отключения правила доступа приватных сетей - отключал все, доступ ко всему давал. дабы разобраться а потом методом тыка отсекать ненужное, но результата не было.. Да и бог с ним..
Ну и с пользователями и правда надо разбираться, сеть просто в наследство досталась..
P.S.: Добавил запрещающее все провило в низ списка на лан интерфейс, в логах вообще тишина организовалась (про ВАН я не говорю), это нормально или лучше убрать правило, что бы хоть не много контролировать что происходит в сети??
И в этота запись в логе интрересная,
block Sep 12 16:12:57 WAN 95.181.54.250:137 95.181.54.251:137 UDP
Причем тут я то вообще??? не знакомые мне вообще адресса, оба два)) P
P.S. ан нет, это IP моего проваидера, только чего им надо.. Они через меня обмениваются пакетами?? -
1. Последнее правило - лишнее. У пф политика - запрещено всё, что не разрешено.
2. Это наши китайские товарищи "балуются" :
2.1. Идем в Firewall: Aliases
В URL вписываем строку : http://www.ipdeny.com/ipblocks/data/countries/cn.zone и сохраняем этот алиас.
2.2. Идем в Firewall: Rules:WAN, создаем блокирующее правило и ставим его самым первым :
-
werter, полезная инфа..
А то в логах просто нереальный шум был.. да и вообще если честно тревожно как то было))
А про правило запрещающее все в ЛАН - я его создал что бы опять же в логах не было шума лишнего как пользователи бьются об fw, но тут вопрос, следом, стоит ли это делать??
Или лучше смотреть кто куда вообще просится и не отключать логирование локалки??
Ну и про этот запрос
block Sep 12 16:12:57 WAN 95.181.54.250:137 95.181.54.251:137 UDP
Может не обращать внимание, проваидера сеть, все равно уже вроде не так страшно.. ?? -
Записи вида
block Sep 12 16:12:57 WAN 95.181.54.250:137 95.181.54.251:137 UDP
Будут постоянно. Это Netbios в сеть ломиться, если не отключать галочку Клиент для сетей микрософт.
Провайдеров наверно уже достало.
У коммутаторов dlink dgs-3120 уже на аппаратном уровне появилось NetBIOS Filtering (Filter NetBIOS over TCP/IP) -
Мне просто интересно, кто ломится?? Провайдер ко мне, или я к нему??
Источник, 95.181.54.250:137, не мой IP и назначение 95.181.54.251:137 тоже не мой..
Я бы понял если бы запись такого вида была
block Sep 12 16:12:57 WAN 176.197.ххх.ххх:137 95.181.54.251:137 UDP
Тогда понятно, мой клиент ломится, а так чет не догоняю.. -
Для сети 95.181.54.248/30 адрес 95.181.54.251 будет широковещательным
и если у вас адрес 95.181.54.249/30 то адаптер будет принимать пакеты
