Ограничение bcast, mcast трафика, iptables. [SOLVED]
Имеется маршрутизатор на базе Gentoo Linux (обычный компьютер с несколькими сетевыми интерфейсами). Данная машина помимо маршрутизации выполняет ряд других функций, в частности на ней запущен torrent клиент Deluge. Выход в интернет осуществляется через VPN соединение. Машина работает круглосуточно. При разрыве VPN соединения (которое бывает не чато, но не вовремя) машина начинает заваливать broadcast и multicast пакетами оборудование провайдера и провайдер (corbina) блокирует мой порт на своем оборудовании. Линка нет, приходится звонить в службу тех поддержки и слушать, что надо проверить компьютер на вирусы и.т.д. В Deluge убрал все галочки с: UPnP, Обмен пирами, NAT-PMP, DHT, LSD, сам в этих настройках особо не разбирался. Думаю решить проблему кардинально - ограничением broadcast и multicast трафика посредством iptables. Такой способ будет эффективен как для исходящего трафика, так и для транзитного (ведь основная функция машины - маршрутизация).
Изучил руководство по iptables, для решения задачи использовал критерий limit. Получилось небольшое количество правил, которые как оказалось не работают - сегодня пока был на работе VPN соединение разорвалось, провайдер заблокировал порт. :(
Итак исходные данные:
1.
~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:da:bb:e5:2b
inet addr:10.200.75.157 Bcast:10.200.79.255 Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6633327 errors:5 dropped:0 overruns:0 frame:5
TX packets:10688298 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:787667633 (751.1 MiB) TX bytes:873097143 (832.6 MiB)
Interrupt:11 Base address:0xd80
eth1 Link encap:Ethernet HWaddr 00:04:76:14:15:f5
inet addr:172.23.8.8 Bcast:172.23.8.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:336 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:72381 (70.6 KiB)
Interrupt:5 Base address:0x4d00
eth0 - смотрин на провайдера
eth1 - смотрит во внутреннюю сеть
2. broadcast адрес очевиден - 10.200.79.255, поискав в интернете выяснил, что диапазон multicast адресов - 224.0.0.0/8.
Теперь непосредственно правила и комментарии к ним, чтобы было удобней разбирать:
$IPTABLES -t mangle -A PREROUTING -d 224.0.0.0/8 -j MARK --set-mark 0x02 ## - помечаем транзитный multicast трафик 0x02
$IPTABLES -t mangle -A PREROUTING -d 10.200.79.255 -j MARK --set-mark 0x03 ## - помечаем транзитный broadcast трафик 0x03
$IPTABLES -t mangle -A OUTPUT -d 224.0.0.0/8 -j MARK --set-mark 0x02 ## - помечаем исходящий multicast трафик 0x02
$IPTABLES -t mangle -A OUTPUT -d 10.200.79.255 -j MARK --set-mark 0x03 ## - помечаем исходящий broadcast трафик 0x03
$IPTABLES -t mangle -A INPUT -m mark --mark 0x02 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01 ## - выполняем отсев транзитного multicast трафика, разрешенные пакеты метим 0x01
$IPTABLES -t mangle -A INPUT -m mark --mark 0x03 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01 ## - выполняем отсев транзитного broadcast трафика, разрешеные пакеты метим 0x01
$IPTABLES -t mangle -A OUTPUT -m mark --mark 0x02 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01 ## - выполняем отсев исходящего multicast трафика, разрешеные пакеты метим 0x01
$IPTABLES -t mangle -A OUTPUT -m mark --mark 0x03 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01 ## - выполняем отсев исходящего broadcast трафика, разрешеные пакеты метим 0x01
$IPTABLES -A FORWARD -m mark --mark 0x02 -j DROP ## - drop'аем все лишние транзитные multicast пакеты
$IPTABLES -A FORWARD -m mark --mark 0x03 -j DROP ## - drop'аем все лишние транзитные broadcast пакеты
$IPTABLES -A OUTPUT -m mark --mark 0x02 -j DROP ## - drop'аем все лишние исходящие multicast пакеты
$IPTABLES -A OUTPUT -m mark --mark 0x03 -j DROP ## - drop'аем все лишние исходящие broadcast пакеты
Вот и все правила. Заранее благодарен за помощь. Куда копать дальше не знаю.
- Для комментирования войдите или зарегистрируйтесь
Как щщитаете,
если заменить строчку
$IPTABLES -t mangle -A INPUT -m mark --mark 0x03 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01на
полегчает?
Не работает
Попробовал так:
$IPTABLES -t mangle -A OUTPUT -m pkttype --pkt-type multicast -j MARK --set-mark 0x02$IPTABLES -t mangle -A OUTPUT -m pkttype --pkt-type broadcast -j MARK --set-mark 0x03
$IPTABLES -A OUTPUT -m mark --mark 0x02 -m recent --update seconds 1 --hitcount 5 --jump DROP
$IPTABLES -A OUTPUT -m mark --mark 0x03 -m recent --update seconds 1 --hitcount 5 --jump DROP
Не работает, ругается на аргумент seconds
Попробовал:
$IPTABLES -t mangle -A OUTPUT -m pkttype --pkt-type multicast -j MARK --set-mark 0x02$IPTABLES -t mangle -A OUTPUT -m pkttype --pkt-type broadcast -j MARK --set-mark 0x03
$IPTABLES -A OUTPUT -m mark --mark 0x02 -m recent --update --seconds 1 --hitcount 5 --jump DROP
$IPTABLES -A OUTPUT -m mark --mark 0x03 -m recent --update --seconds 1 --hitcount 5 --jump DROP
Вроде ошибок нет, должно работать. Решил проверить:
$IPTABLES -t mangle -A OUTPUT -p icmp --icmp-type 8 -j MARK --set-mark 0x04$IPTABLES -A OUTPUT -m mark --mark 0x04 -m recent --update --seconds 1 --hitcount 5 --jump DROP
Не работает. При выполнении
ping localhost -i 0.01все пинги проходят!Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
1. -d 224.0.0.0/8 - таким
1. -d 224.0.0.0/8 - таким образом помечается ВЕСЬ трафик (не только multicast), идущий в обозначенную сеть и только в неё. Соответственно, если вы хотите метить только ВСЕ multicast пакеты, то вам нужно использовать -m pkttype --pkt-type multicast (соответственно такой модуль должен быть собран в ядре) а -d 224.0.0.0/8 вообще указывать не нужно
2. broadcast трафик через маршрутизатор и так не ходит (только, вроде бы, если намеренно отправлять пакеты на broadcast адрес чужой сети), потому блокировать его нет смысла. Смотрите в сторону приложений, которые установлены на самой машине.
3. транзитный трафик никогда не попадает в цепочку INPUT. Чтобы воздействовать на транзитный трафик делайте это в цепочке FORWARD
4. зачем метить пакеты? Бессмысленная процедура. Можно просто указать критерии в самих отсеивающих правилах и сказать, что с этими пакетами делать.
А вообще, на мой взгляд, подход неверный. Нужно смотреть в сторону настройки тех приложений, которые запущены на машине. Если они генерируют столько bcast/mcast трафика, значит они так настроены. А если резать этот трафик файерволом то пакеты естественно будут теряться и корректно работать эти приложения не будут.
_Andrey написал(а): А вообще,
Не совсем согласен. Приложения генерируют bcast/mcast трафик только после разрыва VPN соединения - толку от этого трафика уже никакого, тем более, что провайдер его все равно ограничит, да еще и порт на сутки заблокирует. А при контроле трафика через фаервол отключение порта исключается.
Итак, наколько я понял для ограничения исходящих bcast и mcast пакетов необходимо следующее:
$IPTABLES -t nat -A POSTROUTING -o eth0 -d 10.200.79.255 -m recent --update seconds 60 --hitcount 5 --jump DROP## для bcast пакетов$IPTABLES -t nat -A POSTROUTING -o eth0 -m pkttype --pkt-type multicast -m recent --update seconds 60 --hitcount 5 --jump DROP## для mcast пакетовПравильно ли я все понял?
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
Вижу вы неважно
Вижу вы неважно ориентируетесь в iptables :), попробую пояснить (сори, если где ошибусь)
Таблица nat служит для манипуляций, связанных с преобразованием ip адреса проходящих пакетов (цели SNAT,DNAT,MASQUERADE) - она не предназначена для фильтрации. Т.е. пытаясь дропнуть пакет в этой таблице вы уже заведомо допускаете ошибку. Для фильтрации существует таблица filter.
Транзитный трафик идет через PREROUTING -> FORWARD -> POSTROUTING, входящий трафик идет через PREROUTING -> INPUT, исходящий - через OUTPUT -> POSTROUTING. Причем заметьте: цепочки PRE/POSTROUTING есть только в таблицах nat и mangle. А вообще рекомендую, развёрнуто и понятно :)
Если после разрыва соединения толку от этих пакетов никакого то почему бы совсем не перекрыть им bcast/mcast доступ в локальную сеть?
Если я правильно понял топологию вашей сети то
Конечно это сгодится только в том случае, если у вас на маршрутизаторе не используются приложения, требующие для работы передачу bcast/mcast трафика по локальной сети.
Чтобы воздействовать на транзитный трафик нужно просто заменить в правилах OUTPUT на FORWARD.
А вообще, я не зря обратил внимание на приложения: при нормальной работе они не должны себя так вести. Если они всё равно работают в инете то попробуйте в настройках жёстко привязать их к ppp интерфейсу (ip адресу), тогда при его падении приложение вообще не будет ничего никуда слать. Или как альтернатива: добавьте для всех этих приложений команды запуска/остановки в ip-up/ip-down соответственно - раз без ppp туннеля от них всё равно никакого толку то при его падении они будут останавливаться и снова запускаться при поднятии.
Первый пост в топике.
Сразу видно Вы не внимательно прочитали первый пост в топике. Если внимательно прочитать первый пост то можно заметить, что там имеется ссылка на Руководство по iptables на opennet.ru, которую Вы мне советуете поситить. Если еще более внимательно прочитав первый пост, можно заметить, что я выложил там те правила которые написал изначально для фильтрации bcast, mcast трафика (я специально выделил их тегом code), и в этих правилах фильтрация происходит в таблице FILTER. Я вкурсе того как пакеты проходят таблицы и цепочки. Я вкурсе того для чего служит таблица NAT, первый пост топика начинается со слов - "имеется маршрутизатор", наверняка он осуществляет маршрутизацию, и наверняка делает он это посредством MASQUERADE или SNAT в таблице NAT.
Собственно тема топика - "Ограничение bcast, mcast трафика, iptables.", а не настройка deluge, не блокирование bcast, mcast трафика, а именно ОГРАНИЧЕНИЕ.
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
наверняка он осуществляет
skip
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
jazz_bass написал(а): Сразу
Простите, видимо действительно невнимательно, раз не посмотрел, куда ведёт ссылка под названием "руководство по iptables". Очень рад, что Вам уже известна эта статья.
и сами же отметили, что эти правила не работают должным образом, а я в одном из первых постов объяснил почему
видимо не очень хорошо знаете или невнимательно читали руководство, раз пытаетесь ограничивать транзитный трафик в цепочке INPUT а затем дропать исходящй в таблице NAT
исходя из первого топика взял на себя смелость предположить, что смысл топика - получение помощи в разрешении возникшей у Вас проблемы, потому и предложил вариант её решения, который я считаю наиболее правильным. Применять его или нет - это уже решать Вам - я своё мнение не навязываю.
Я указал Вам на тот момент в Ваших правилах, где Вы допускаете ошибку, причем попытался сделать это развёрнуто (хотя мог бы просто сослаться на man iptables где всё это есть), чтобы было наглядно понятно, в чем заключается ошибка. И я очень сожалею, что Вы не смогли извлечь пользы из озвученной мной информации.
Прошу прощения,
за то, что написал не работающие правила для iptables - честное
пионерское, сделал это намеренно :)
Я лишь дал "удочку" в лице
--match recent, дальше человекусамому решать, что с ней делать, в какой цепочке использовать.
Я так думаю, что человек, работающий в этой области, должен неплохо знать
"предмет" - быть спецом.
Прошу не забрасывать неня сильно межконтинентальными баллистическими тапочками :D
_Andrey написал(а): видимо
Я не считаю себя специалистом в области iptables, да и вообще в администрировании. Я не являюсь "...человеком, работающим в этой области...", как считает willy, все происходит дома, домашний сервер(маршрутизатор), раздающий интернет жене и мне. Несмотря на это имею базовые представления о том как работает iptables. Я знаю, что таблица NAT предназначена для преобразования (подмены) адресов источника/цели, я знаю, что таблица mangle служит для внесения изменений в пакеты (изменение ttl...), я знаю, что таблица filter служит для фильтрации. Мое решение фильтровать в nat связанно с постом willy. Меня это смутило, но мне казалось всегда, что тут в основном сидят люди гораздо более подкованные в вопросах: администрирования и линукса, поэтому его решение я принял на веру.
Я действительно ошибся, когда писал первый пост. Дело в том, что в моем скрипте для iptables гораздо больше правил чем я написал, поэтому когда я писал пост я случайно скопировал две строки из таблицы INPUT, а в комментарии написал отсев транзитного трафика. Это опечатка я извиняюсь за нее, просто в скрипте есть и фильтрация входящего bcast mcast трафика. Напрасно вы считаете, что я не извлек из Вашей информации пользы - я не знал о существовании pkttype, в руководстве по iptables о нем не слова. Поискав в google узнал о многих типах пакетов которые можно ловить данным критерием, помимо multicast можно ловить broadcast и anycast(не совсем понял, что это за пакет, да и iptables у меня на него ругается). По поводу Deluge все говорят, что надо убрать обмен локальными пирами UPnP и DHT - я все это убрал, и все равно не добился желаемого результата.
Большое спасибо за --match recent, я и незнал ничего про него, нашел вот это. Попробую Ваш рецепт. Единственное, что мне непонятно, Почему не работает limit.
Скажите пожалуйста должны ли работать следующие правила:
$IPTABLES -A OUTPUT -m mark --mark 0x02 -j DROP$IPTABLES -A OUTPUT -m mark --mark 0x03 -j DROP
$IPTABLES -t mangle -A OUTPUT -m pkttype --pkt-type multicast -j MARK --set-mark 0x02
$IPTABLES -t mangle -A OUTPUT -m pkttype --pkt-type broadcast -j MARK --set-mark 0x03
$IPTABLES -t mangle -A OUTPUT -m mark --mark 0x02 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01
$IPTABLES -t mangle -A OUTPUT -m mark --mark 0x03 -m limit --limit 5/sec --limit-burst 10 -j MARK --set-mark 0x01
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
Ну, я тоже - домашний пользователь гентоо :D
Как я понимаю - критерий лимит работает в установленных соединениях, ну а
broadcast storm - это большое количество запросов (по сути - попыток соединения)
на единицу времени. Тут может помочь либо
--connlimit ! --connlimit-above, либо--recent.Но что-то мне сдаётся, что мы тут с Вами не здесь причину ищем :)
Может быть стоит начеркать костыль в виде скрипта, проверяющего наличие
соединения с провайдером путём пинга его DNS, например, который будет
запускаться cron'ом каждые N минут. В случае отвала соединения - останов deluge,
и перезапуск его через, скажем, 2 минуты?
Что-то типа:
eval /bin/ping -c 1 "${DNS}" if [ $? -ne 0 ]; then kill `pgrep deluge | head -1` sleep 120 eval /usr/bin/deluge {Ваши опции} wait fiБлин, два компьютера, и завал провайдера бродкастами - тут что-то не то...
Тут, чесслово, нужна помощь боле опытных в компьютерных сетях товарищей, так сказать - помощь зала :)
Не работает --recent Все таки
Не работает --recent
Все таки хотелось бы решить вопрос посредством iptables.
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
[SOLVED]
Был в командировке, не мог ответить.
Подправил правила:
$IPTABLES --table nat --append PREROUTING --in-interface Ваш_локальный_интерфейс --match mark --mark 0x03 --match recent --update --seconds 60 --hitcount 5 --jump DROP$IPTABLES --table nat --append PREROUTING --in-interface Ваш_iface --match recent --set --jump ACCEPT
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!