The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Много вопросов по ipfw  и т.п."
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Много вопросов по ipfw  и т.п."
Сообщение от Sergey_A emailИскать по авторуВ закладки(ok) on 29-Мрт-04, 15:50  (MSK)
Господа, есть несколько вопросов по ipfw [FreeBSD 4.9].
Для начала опишу ситуацию. Есть локальная сеть (которую будем защищать), есть сеть заказчика (которая потенциально небезопасна). Между ними стоит роутер с Firewall'ом. Локальная сеть живёт сама по себе и ей от внешнего мира ничего не надо, но в ней есть сервера к которым, по определённым портам, нужен доступ с некоторых машин из сети заказчика.

А теперь вопросы.

1) По какой стратегии строить правила Firewall'a ?

Вариант первый : использование keep-state. Т.е. для того что бы клиенты могли общаться с серверами по портам 135 и 2000, надо написать что-то вроде :

ipfw add 10 check-state
ipfw add 20 allow tcp from 10.10.10.15 to 192.168.1.10 135  keep-state
ipfw add 30 allow udp from 10.10.10.15 to 192.168.1.10 2000 keep-state
ipfw add 40 deny ip from any to any

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

ipfw add 5 check-state
ipfw add 10 allow tcp from 10.10.10.15 to 192.168.1.10 135
ipfw add 20 allow udp from 10.10.10.15 to 192.168.1.10 2000 keep-state
ipfw add 30 allow tcp from 10.10.10.15 to 192.168.1.10 established
ipfw add 40 deny ip from any to any

Но это не будет работать для udp пакетов, так что приходится опять же использовать keep-state. Этот вариант имеет право на жизнь если много tcp портов и мало udp. (Или это кривой вариант и есть что-нибудь проще ???)

Первый вариант лучше в плане безопасности, но в нём есть минус : связь рвётся если сервер и клиент перестают общаться друг с другом на время большее чем время жизни правила (по умолчанию 300 сек).

Что скажете ?

2) Если в сети заказчика используется DHCP, т.е. одной из сетевух роутера ip выдаётся динамически, то надо ли рзрешать udp по 67,68 портам ?
Нужна ли периодическая связь компьютера с сервером DHCP в процессе ? Компьютер, единожды связавшись с сервером и получив от него нужную информацию (ip, netmask и т.п.), забывает про сервер и больше никогда с ним не связывается ? Или он периодически общается с сервером DHCP ?

Дело в том, что сначала у меня было только одно правило (то что на уровне ядра) : deny ip from any to any, и при этом IP компьютер получал - значит инициализация сетевухи (получение информации от DHCP сервера) происходит раньше чем грузится Firewall. Потом, когда я писал правила Firewall'а, я решил добавить на всякий случай правила для DHCP :

ipfw add 10 allow udp from any 67 to me  68
ipfw add 20 allow udp from me  68 to any 67

Но за всё время работы роутера, судя по счётчикам ipfw, не было и одного пакета. Или я не правильно написал правила ?

3) Можно ли в ipfw1 указывать несколько ip и/или портов в одном правиле ? Или это только в ipfw2 сделано ?

4) Читал в форумах, что советуют обьединять несколько ip и/или портов в одно правило если это возможно. С точки зрения ресурсов компьютера есть ли в этом выгода ? У меня есть тайное подозрение, что эти обьединения
всё равно потом транслируются ipfw в ряд индивидуальных правил (напимер один ip и/или один порт).

5) Самое забавное. Сейчас правила Firewall'а построены с использованием keep-state. Так вот, когда я запускаю на удалённом компьютере Putty, делаю там что-нить, а потом она у меня валяется в фоне, то через 5 минут (300 секунд) динамическое правило на ssh удаляется, а Putty при этом ещё некоторое время работает.
У меня рядом машинка с FreeBSD и обычная виндовская машинка. На виндовской запускаю putty и жду 5 минут. После 5-ти минут я с локальной консоли на FreeBSD'ёвой машинке убеждаюсь, что динамическое правило на прохождение обратного пакетика (от freebds к putty) удалилось. После чего в putty набираю, например, "ipfw -s show", и любуюсь на отображение правил, затем putty говорит "Network error: Software caused connection abort" и отваливается. Как же это так происходит ? Ведь у меня правила выглядят так :

ipfw add 10 allow tcp from any to any 22 keep-state
ipfw add 20 deny ip from any to any

Соответственно как только убивается динамическое правило (созданое 10-м правилом), то связь должна однозначно разорваться, а я успеваю ещё что-нить сделать (где-то от 1 до 10 секунд у меня есть, прежде чем отвалится putty). Как же проходят обратные пакеты от роутера к putty ? Ничего не понимаю.

6) При запуске ettercap (в режиме прослушивания, т.е. тогда когда идёт отображение на экран соединений) загрузка процессора на все 100% (см.ниже). Ведь это всё-таки не хорошо, как я понимаю. Почему так ? Может-быть из-за сетевухи (сетевуха 3com, хотя я считаю что 3com не плохие сетевухи делает) ?

last pid:  3824;  load averages:  0.58,  0.17,  0.06                                                  up 2+21:51:37  14:53:15
30 processes:  2 running, 28 sleeping
CPU states: 99.6% user,  0.0% nice,  0.0% system,  0.4% interrupt,  0.0% idle
Mem: 11M Active, 5604K Inact, 11M Wired, 4K Cache, 8176K Buf, 156M Free
Swap:

  PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
3821 root      55   0  5112K  3816K RUN      0:46 89.85% 87.01% ettercap
3688 sergey     2   0  5292K  2216K select   0:02  0.00%  0.00% sshd


7) Что скажите по поводу праивл firewall'а ? Сейчас, т.к. машинка не бовая, а тестируется, стоят правила без указания конкретных IP. Потом буду указывать.


ipfw='/sbin/ipfw -q'
ournet='192.168.10.0/24'
ifout='xl1'
ifuser='xl0'

${ipfw} flush
${ipfw} add 100 deny icmp from any to any in icmptype 5,9,13,14,15,16,17
${ipfw} add 200 deny ip from ${ournet} to any in via ${ifout}
${ipfw} add 300 allow all from any to any via lo0
${ipfw} add 400 deny all from any to 127.0.0.0/8
${ipfw} add 500 deny ip from 127.0.0.0/8 to any
${ipfw} add 600 allow icmp from any to any

${ipfw} add 900 allow tcp from any to me 21 keep-state
${ipfw} add 950 allow tcp from me 20 to any keep-state
${ipfw} add 1000 allow tcp from any to any 22  keep-state
${ipfw} add 1050 allow udp from me to any 53   keep-state
${ipfw} add 1100 allow tcp from any to any 135 keep-state
${ipfw} add 1180 allow tcp from any to any 1028 keep-state
${ipfw} add 1200 allow tcp from any to any 1234 keep-state
${ipfw} add 1500 allow tcp from any to any 2000 keep-state
${ipfw} add 5000 allow udp from any 67 to me  68
${ipfw} add 5010 allow udp from me  68 to any 67

${ipfw} add 64000 deny all from any to any

  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "Много вопросов по ipfw  и т.п."
Сообщение от vitaliy Искать по авторуВ закладки(ok) on 29-Мрт-04, 16:33  (MSK)
А есть необходимость использования динамических правил?
Самый простой вариант(примерно ессно):
ipfw add 10 allow tcp from any to me 25, 53, 80
ipfw add 20 allow tcp from any to any established
ipfw add 65000 deny ip from any to any
  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Много вопросов по ipfw  и т.п."
Сообщение от Sergey_A emailИскать по авторуВ закладки(ok) on 29-Мрт-04, 18:09  (MSK)
>А есть необходимость использования динамических правил?
>Самый простой вариант(примерно ессно):
>ipfw add 10 allow tcp from any to me 25, 53, 80
>
>ipfw add 20 allow tcp from any to any established
>ipfw add 65000 deny ip from any to any

Ты читал что я написал ? Я же расписал оба варианта.
Как быть с udp ? Оно тоже нужно.
В ipfw1 нельзя (вроди как. у меня не получилось) указывать через запятую адреса\порты.

Чем ещё плох "established" - блягодаря этому правилу можно будет спокойно "заваливать" любую машинку в локальной сети (ту что уже за роутером) и роутер будет пропускать эти пакеты. Это не есть хорошо. Я не знаю что будет твориться с виндовой машинкой если её закидывать такими пакетами, но что-то мне подсказывает, что ничего хорошего. Я не знаю, можно ли будет взломать таким образом виндовскую машинку, но DoS атаку думаю можно будет реализовывать на ура. Причём ДОСить, в таком случае, можно будет с любой машинки из сети заказчика (я же написал, что она потенциально не безопасна, ибо сама подключена к инету).

Ситуация такова, что локальная сеть должна работать, пусть сама по себе, без связи с внешним миром, но дожна. Если же реализовать правила с использованием "keep-state", то проломиться в локальную сеть можно будет не только с определённых адресов, но и на определённые порты.
На роутере можно сделать ограничения на количество соединений и тем самым оградить локальную сеть от DoS атаки. Пусть ДОСят, всё будет осаждаться на роутере.

2 ALL: Народ, я конечно понимаю, что написал много, но писал я по делу, особо воды не разливал. Сами часто говорите, что нехватает информации что бы ответить на вопрос, а вот как написал подробнее, так никто и не читает. =((

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру