» Deerfield VisNetic Firewall 2.0

bredonosec

Цитата:

Это критично?

Не знаю , но раз есть более новая версия, почему-бы ей не воспльзоваться?
Мне лично больше нравится 8sign - там цвет меняется+на старенького каспа значок похож.

Цитата:

Мне лично больше нравится 8sign

их разве уже научились ломать?

bredonosec
А ты поинтерусйся в соответсвующей теме и тебе все откроется.

Странная фигня какаято.
StrongDC и другие клиенты снова глючат. не качают контент ни туда ни сюда.

Но. все бы ничегою логи визнетика пусты, в этом плане. чисто.

Если визнетик открыть полностью, то все отлично. все работает в dc++

КАк упралять логами так, что бы поймать этот супор?

dariusii
Поставить галку во всех Rules"ах галку напротив "Лог конекшин" или "лог пакет", а то нет галки, нет записи в логах

Minoz

все протоколы, что в "advanced", просматриваются. Лог ведется. Кроме GRE. Он разрешен и лог этого протокола я выключил.
Правил, поставленных в ручную, что либо запрещающих, у меня нет.
Какой смысл вести лог того, что разрешено?

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

dariusii
Ну не знаю... У меня в ТСР в конце стоит "контрольное" правило

Цитата:

my address [all]<->All addres[all] - block

Так что у меня все в лог попадает по любомо. А если нет правила по другому протоколу, то все равно попадает в лог с пометкой (no matching rule). Так что это твой какой то локальный глюк.

Minoz


Цитата:

my address [all]<->All addres[all] - block

Все заблокировано наглухо. Даже, если создать другие правила разрешений.


Цитата:

Так что это твой какой то локальный глюк.

читай внимательнее >>


Цитата:

.. Если визнетик открыть полностью, то все отлично. все работает в dc++ ..

Проблема встретилась не только у меня одного. Все, кто сидит в нашей сетке на этом файрволле, наблюдают эту же картину. доступ по dc++ блокируется, но причина неизвестна. Логов никаких. Можно заблокировать весть трафик и поставить такому правилу низший приоритет с ведением логов (странно. я думал, что визнетик и так это делает. Получается, была огромная дыра, если верить Minoz).
Логов по этому поводу никаких. полная тишина. логи видны совсем по другим вещам. блоки внешних ип, как и раньше, типа "2006/08/27, 00:25:54.671, GMT +0400, 2010, Device 1, Blocked incoming UDP packet (no matching rule), src=24.232.176.197, dst=213.85.177.222, sport=22032, dport=49152".

Кто-нибудь может что-то сказать по этому поводу?

Сия "локальная вещь" замечена еще у 3х знакомых. Вернее, у всех, кого я знаю, кто использует данный файрволл в нашей сетке.

dariusii

Цитата:

Какой смысл вести лог того, что разрешено?

- Чтоб знать, где проблема: в том, что стена не пускает, или что прога не отправляет. И если стена, то почему - адрес забанен, порт под правило не попал, проч.
Просто полезно весь траф отслеживать, содержимое пакетов необязательно в лог пихзать
Minoz

Цитата:

У меня в ТСР в конце стоит "контрольное" правило

Цитата:my address [all]<->All addres[all] - block

- Смысл?
И так у виснетика есть фича Configuration - advanced - other protocols - block (by default) - блокирование всего не упомянутого в правилах. Можно, конечно, открыть, но будет именно та огромная дыра, о которой упомянул дарюс.
Нахига дублировать?

Цитата:

Blocked incoming UDP packet (no matching rule), src=24.232.176.197, dst=213.85.177.222, sport=22032, dport=49152".

- Это точно не относится к дс++?
//повторюсь, с прогой никогда не работал, но привык, что ежели виснетик чего-то не пропускает и регулярно появляются неопознанные пакеты в момент этих непропусканий, то вероятно, они связаны

bredonosec

наша сетка
10.60.0.0/16
до
10.63.0.0/16

лог показывает именно то, что действительно не разрешено.
dc++ можно вообще не подымать в этот момент.
===

аудит разрешенных правил по dc++ делал, тоже. - пусто. В логах вообще пусто.

Повторюсь. При отключенном визнетике - все ок.
И еще. Данная хрень не только у меня. У всех, у кого стоит визнетик в нашей сетке, творится та же самая хрень.

Проблем с какими-либо другими приложениями (не dc++ клиентами) не наблюдается.

Пробовал везде отрубать "block incoming fragments" - не то.

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

dariusii
Более или менее подробное описанно, что надо открыть для ДС тут. Из этого можно сделать вывод, что по по ТСР нужно открыть фсе и для фсех... Получится очень спецефическая настройка фаера...

bredonosec

Цитата:

- Смысл?

А просто... Зато теперь у меня фсе "левые пакеты" блокируются одним последним правилом, и как то на "душе" сразу легче

Minoz


Правила, что в конце поста, прекрасно работали.

А просто... Зато теперь у меня фсе "левые пакеты" блокируются одним последним правилом, и как то на "душе" сразу легче

Когда на душе спокойно, это хорошо ))

Minoz

Цитата:

просто... Зато теперь у меня фсе "левые пакеты" блокируются одним последним правилом,

Ну ежели от замены строчки типа
Цитата:

2006/08/27, 22:49:30.890, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105

на строчку с указанием номера правила становится легче на душе - пользуйте так
dariusii

Цитата:

Накидал аудит на все, что только мог.

- а в конфигурации вот енто самое правило для "не подпадающих под правила" лог отчеркнул? Просто траффик, не подпадающий под всевозможные правила, мягко говоря, [more=несколько больший]

Код: 2006/08/27, 22:55:48.730, GMT +0200, 2111, Device 1, Rule 77, Blocked incoming MAC packet, src=00-40-F4-11-BC-E4, dst=FF-FF-FF-FF-FF-FF
2006/08/27, 22:55:48.730, GMT +0200, 2111, Device 1, Rule 77, Blocked incoming MAC packet, src=00-40-F4-11-BC-E4, dst=FF-FF-FF-FF-FF-FF
2006/08/27, 22:55:52.570, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:55:54.440, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:55:54.440, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:55:55.760, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:55:57.900, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:55:59.820, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:55:59.820, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:06.250, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.11, dst=192.168.1.1
2006/08/27, 22:56:22.780, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:26.740, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:26.740, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:29.590, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:29.590, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:30.580, GMT +0200, 2128, Device 1, Blocked UDP packet from banned IP, src=192.168.1.33, dst=192.168.1.255, sport=138, dport=138
2006/08/27, 22:56:30.640, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:30.640, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:31.680, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:54.090, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:55.190, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:55.190, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:55.850, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:57.330, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:56:57.880, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:20.730, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:20.730, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:22.380, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:22.380, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:23.750, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:25.450, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:26.270, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:26.270, GMT +0200, 2018, Device 1, Blocked incoming ARP packet (no matching rule), src=192.168.1.1, dst=192.168.1.105
2006/08/27, 22:57:27.370, GMT +0200, 2128, Device 1, Blocked UDP packet from banned IP, src=192.168.1.15, dst=192.168.1.255, sport=137, dport=137

dariusii
Попробуй в файрволе отключить Use Stateful Inspection. При включенной функции у меня NAT вобще не работает, т. е. пакеты до машины проходят, а дальше в логах визнетика пусто, и ответа на запрос нету. При этом с машины где стоит файрвол все работает идеально, и Stateful Inspection работает как ей и положено.

bredonosec
Да. Аудита соединений достаточно

У меня в свое время DC++ был настроен так:

TCP
DCPP_IN - MyAddress(11025)<-AllAddresses(1024-11025)
DCPP_OUT - MyAddress(1024-11025)->AllAddresses(11025)
DCPP_P2P - MyAddress(1024-5000)<->DCServer(411)

UDP
DCPP_IN - MyAddress(11025)<-AllAddresses(1024-11025)
DCPP_OUT - MyAddress(1024-11025)->AllAddresses(11025)
DCPP_P2P - MyAddress(1024-5000)<->DCServer(411)

Т.е. DC++ работает через сервер с 411 портом, в самих DC++ настроено также использование 11025 порта вместо диапазона портов. Stateful Inspection в файрволле выключено. Сервер юзали YoshiHub (с динозавриком), вроде поприличнее штатного..

Сейчас в локалке уже не юзаем (их разряда эксперимента не вышло), глючноватая все же система DC++... так что подробности сообщить не могу

Iliasla

Чуть, скромнее

dariusii,
Вы привели правила


Цитата:

##########################################
DC= адреса или диапазон адресов, куда смотрит клиент dc++
MY= мой ip адрес
HUB= ip адрес хаба
* = настраиваем данное правило в dc++ клиенте !также
F = Block uncoming fragments


TCP. 1024-5000 $MY > 411 $HUB ($F)
TCP. 1024-5000 $MY > 1024-65535 $DC ($F)
TCP. 1412 $MY < 1024-65535 $DC ($*,$F)
UDP. 2896 $MY < 1024-65535 $DC ($*,$F)
##########################################

Почему исчезло правило UDP 1024-5000 > 1024-65535?

SVicUL
Оно у меня и не исчезало
Я его, просто, не применял.
Все работает в обе стороны.
Правила были содраны со стандартных правил iptables из SuSE (добавление оттуда двух правил исходящих соединений). Одно udp и одно tcp.
Там нужно было, лишь, добавить два входящих соединения (SuSE Linux)
Под визнетиком было добавлено еще два правила исходящих. все.

dariusii,

как понял из выше написанного, полное правило для DC++ будет таким:
TCP, 1024-5000 > 411 HUB
TCP, 1024-5000 > 1024-65535
TCP, порт, указанный в настройках < 1024-65535
UDP, порт, указанный в настройках < 1024-65535
UDP, 1024-5000 > 1024-65535
?

dariusii

Цитата:

Iliasla
Чуть, скромнее

Не понял?
С такими правилами работало. По поводу глючности: на компе без Визнетика, но с файрволлом BlackIce вообще практически не работало, хотя порты были прописаны. Выключаешь BlackIce - работает.


Цитата:

TCP, 1024-5000 > 1024-65535
UDP, 1024-5000 > 1024-65535

Смысл городить файрволл с такими дырами?

Iliasla,
по наблюдения DC++ использует "TCP, 1024-5000 > 1024-65535", а без "UDP, 1024-5000 > 1024-65535" у меня не смогут ничего скачать. Притом я использут Sygate, а в нем имеется фильтр приложений.
Я не знаю протокола используемого DC++, поэтому и спрашивают как будет правильнее записать правила для этого клиента.

SVicUL
Sygate использует контроль приложений, Visnetic - нет. Поэтому в Sygate такие настройки можно делать (привязав их к программе DC++ ), другую программу он не пустит, а у Visnetic получится дыра и полезут все, кто захочет.

Iliasla

##########################################
DC= адреса или диапазон адресов, куда смотрит клиент dc++
MY= мой ip адрес
HUB= ip адрес хаба
* = настраиваем данное правило в dc++ клиенте !также
F = Block uncoming fragments

Rules for local area connection
1.TCP. 1412 $MY < 1024-65535 $DC ($*,$F)
any.TCP. 1024-5000 $MY > 411 $HUB ($F)
2.TCP. 1024-5000 $MY > 1024-65535 $DC ($F)
UDP. 2896 $MY < 1024-65535 $DC ($*,$F)
##########################################

Порядок дописал. Так будет точнее.

Осталось разобраться с еще одной гетерогенкой > bittorent протоколом.

Пока что правила таковы для bittorent у меня:

################################################################
MY= мой ip адрес
ALL = All adresses
F = Block uncoming fragments

internet connetction (not ethernet)

BitTorrent IN: TCP, $MY 6881-6999 < 1025-65535 $ALL ($F)
BitTorrent OUT: TCP, $MY 1024-5000 > HTTP and 6881-6999 $ALL ($F)

http адреса можно и определить, но смысла мало. http можно даже убрать. это 80'ка все равно.
Клиента, соответственно, настраиваем, если это нужно.
################################################################

Добавлено:
дело в том, что правила перекрывают друг друга. block incoming/outgoung connections же

Или я чтот не догоняю....

Iliasla
Для сравнения фаеров есть другой топик.
Если потрудится и полистать нескольео страниц назад, то можно увидеть,
что dariusii постоянно пользуется DC++.


dariusii
Нет, это не совсем одно и то-же.
А у тебя с чего вдруг проблема, ничего из Win не обновлял?

KUSA
Нет, это не совсем одно и то-же.
Тогда, как получается, что когда я поменял приоритет входящих соединений по tcp под dc++, у меня все заработало.

нет. у меня проблемы, как таковой нет, если честно. У знакомого. с теми же правилами.
Даже, приоритет правил тот же.
Как получается у него - то есть связь с другими машинами через dc++, то нет связи.
Та же ерунда и с битторрентом. стоит у него азуреус. у меня биткомет. надо было мне его ему поставить и сравнить их. хотя, сам клиент по портам настроен на разрешения визнетика. входящие порты. часть машин с визнетик идет лесом, которые не по правилам сидят (используют свои исходящие порты ниже планки безопасных), а часть работает нормально.
то бишь, не:
################################################################
MY= мой ip адрес
ALL = All adresses
F = Block uncoming fragments

internet connetction (not ethernet)

BitTorrent IN: TCP, $MY 6881-6999 < 1025-65535 $ALL ($F)
BitTorrent OUT: TCP, $MY 1024-5000 > HTTP and 6881-6999 $ALL ($F)

http адреса можно и определить, но смысла мало. http можно даже убрать. это 80'ка все равно.
Клиента, соответственно, настраиваем, если это нужно.
################################################################
надо делать, получается, а :
################################################################
MY= мой ip адрес
ALL = All adresses
F = Block uncoming fragments
ALLPORTS = all ports (0 - 65535)

internet connetction (not ethernet)

BitTorrent IN: TCP, $MY 6881-6999 < $ALLPORTS $ALL ($F)
BitTorrent OUT: TCP, $MY 1024-5000 > $ALLPORTS $ALL ($F)

################################################################

Ну какие, там, у людей файрволлы, сам понимаешь. У основной массы дефолтный winfirewall. Разрешил клиента через такой файрволл, а тот делай, что хошь (про поведение людей на удаленных машинах - основная масса, имхо)

Я же внимания не обращаю.
винда - так.. фильм после юга на ней помонтировал и все.
все мои правила просты, как и раньше писал

iptables -F;
iptables -t nat -F;
iptables -P INPUT ACCEPT;
iptables -P OUTPUT ACCEPT;
iptables -P FORWARD DROP;
export LAN=eth0;
iptables -I INPUT 1 -i ${LAN} -j ACCEPT;
iptables -I INPUT 1 -i lo -j ACCEPT;
iptables -A INPUT -p UDP --dport bootps -i ! ${LAN} -j REJECT;
iptables -A INPUT -p UDP --dport domain -i ! ${LAN} -j REJECT;
iptables -A INPUT -p TCP -i ! ${LAN} -d 0/0 --dport 0:1023 -j DROP;
iptables -A INPUT -p UDP -i ! ${LAN} -d 0/0 --dport 0:1023 -j DROP;
iptables -A INPUT -p TCP -i ! ${LAN} -d 0/0 --dport 3128 -j DROP;
iptables -A INPUT -p UDP -i ! ${LAN} -d 0/0 --dport 3128 -j DROP;
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner squid -j ACCEPT;
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3128;
iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-ports 3128;
iptables -t nat -A OUTPUT -p tcp --dport 8081 -j REDIRECT --to-ports 3128;
iptables -A INPUT -p tcp --syn --dport 22 -m recent --name radiator --set;

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

Хотя, я не очень силен в разнице между этими осями, в плане, "что же лучше еще запереть в win". Как говорят, так и делаю. Как и где работают трояны, итц в вин, мне не особо ведомо. Для лин такое не особо грозит. Поентому просто блокируются важные порты на вход и все.

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

Добавлено:
С другой стороны, как тут кто-то говорил - "создать опр. правило только для одной проги, а дальше нее, типа, эти правила не вылезут" - как я понял, - полное фуфло.
Либо есть нормальные правила для всего, либо от лукавого, имхо. Ибо дыр с такой сложной системой, как правила под опр. прогу, может быть очень много, а учитывая Closed Source (Outpost Firewall etc..) - еще больше.

По факту, получается, что с p2p клиентами под win проблемы решены не полностью. Во! как
Они меня особо не волнуют. win - н и в африке win.
Sorry перед ее поклонниками (или сторонниками, как хотите..)

Цитата:

когда я поменял приоритет входящих соединений по tcp под dc++, у меня все заработало.

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

Цитата:

все мои правила просты, как и раньше писал

- это для виснетика правила в таком виде, или для чего другого? вид какой-то необычный..

bredonosec

Нет. Я про другое. Пример:
Я разрешаю входящие на свой 1412й порт со! всего диавазона 1024-65535 по tcp.
При этом я ставлю галочку "block outgoing connections".
Меня больше всего интересует, что делает "block outgoing connections".
Раньше я считал, что эта опция "работает только в данном правиле".
То есть, если это правило будет стоять выше всех, а "ниже" я поставлю правило, где будет разрешено ходить на! диапазон 1024-65535, то верхнее его не перекроет, только потому что там стояла опция "block outgoing connections". Если же это не так, то получается, что будет очень сложно совместить все правила.
Ну, к примеру, поставлю я его ниже второго, что здесь привел. Смотрите, тогда, что получится с ним. Та же картина конфликта, только, наоборот.
Говорю. Это в случае, если правило "block outgoing connections" или "block incoming connections" перекрывает собою нижележащие правила. А смена приоритета оных это, почему-то, подтверждает

это для виснетика правила в таком виде, или для чего другого? вид какой-то необычный..
Нет. Я про простоту файрволла в Linux.
Кстати, для них все расписано и даже на русском:
http://www.opennet.ru/docs/RUS/iptables/
Просто, я показал, что там минимум правил по данной теме. Об исходящих соединениях вообще особо заботиться не нужно.

Цитата:

правило "block outgoing connections" или "block incoming connections" перекрывает собою нижележащие правила. А смена приоритета оных это, почему-то, подтверждает

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

Цитата:

я показал, что там минимум правил по данной теме.

агитатор