iptables и voip

iptables и voip

Спасайте! Заблудился в трех соснах.

-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

-A INPUT -s 95.хх.хх.0/24 -p ALL -j ACCEPT # моя сеть
-A INPUT -s 80.хх.хх.2 -p ALL -j ACCEPT # IP-адрес сервера провайдера

-A INPUT -p icmp --icmp-type 8 -m state --state NEW -j ACCEPT

После
iptables -P INPUT DROP

пропадает sip-регистрация. Что я не дописал?

 

Re: iptables и voip

5060 и 5061 UDP/TCP пусти внутрь по умолчанию.

 

Re: iptables и voip

А можно вопрос просто про iptables?

Какого хрена, если в цепочке input запретить icmp, а потом попинговать интерфейс пакетами с TTL=1 с соседней машины:

ping -i 1 <ip>

то ответ от сервера "TTL expired in transit" таки вернется?

P.S. Речь, на самом деле, про Mikrotik, но ноги растут из iptables.
P.P.S. Как такие пакеты ловить, точнее ловить ответ сервера, я знаю, я просто логики не понимаю

 

sepukked

 

Re: iptables и voip

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

Код:

sleep 120
iptables-restore < гарантировано_минимально_работающие_настройки

Ошибся, через две минуты настройки сбросятся. Если все ок, kill скрипту.

 

Re: iptables и voip

Ты проверял, или теоретизируешь? Просто в Mikrotik'е возвращается. В mangle/prerouting пакет еще видно, в input/forward он не появляется, а в конце ответный пакет роутера возникает в output.

На самом деле, я "ловил" и чуть более сложный случай, см. http://forum.ixbt.com/topic.cgi?id=14:51525-134#3545

 

Re: iptables и voip

Не совсем понял... Ты экспайр извне хочешь видеть или изнутри?
В любом случае, если дропаешь, то ничего не вернется. Тут Ваня прав.
В Action попробуй поставить Reject. По логике, может помочь. Там еще есть return, но что это, надо в манах читать. А вообще, на ixbt.com есть тема про Микротик, лучше задать вопрос там.

 

Re: iptables и voip

Я там и задал вопрос с подробностями (см.выше). Меня ткнули носом в картинку с dataflow, где показано, что такие пакеты (TTL-1) умирают в forward (?), не дойдя до правил. А потом related пакет появляется в output. Его можно убить. А входной - нет. Чего я и возмущаюсь.

Вдогонку. на ixbt тоже утверждают, что я неправ. Дома перепроверю.

 

Re: iptables и voip

Эвона как... был невнимателен.

 

sepukked

 

sepukked

 

Re: iptables и voip

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

 

Re: iptables и voip

Ну, вот, результаты проверки (WAN ip = A.B.C.D, netmask=255.255.255.0, default gateway = A.B.C.1, LAN ip = 192.168.1.1, первые правила в input/forward - drop icmp):

Теперь, если с машины из внутренней сети попинговать роутер, то мы видим:

Код:

    C:\>ping -i 1 192.168.1.1
     
    Pinging 192.168.1.1 with 32 bytes of data:
     
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.
     
    Ping statistics for 192.168.1.1:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Счетчик соответствующего правила в input увеличивается на 4. Т.е. роутер ведет себя совершенно логично, а я где-то ошибся. Видать, эксперимент был плохо поставлен.

Но, если пропинговать какой-нибудь хост во внешнем сегменте, default gateway, например, то при этом роутер отвечает!

Код:

    C:\>ping -i 1 A.B.C.1
     
    Pinging A.B.C.1 with 32 bytes of data:
     
    Reply from 192.168.1.1: TTL expired in transit.
    Reply from 192.168.1.1: TTL expired in transit.
    Reply from 192.168.1.1: TTL expired in transit.
    Reply from 192.168.1.1: TTL expired in transit.
     
    Ping statistics for A.B.C.1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms

При этом через output проходят 4 related пакета, а правила ни в input, ни в forward не срабатывают.

В большинстве случаев - да и фиг с ним. Но у меня дома в WAN сегменте "видно" до сотни компьютеров, причем еще и из разных сеток. Т.е. если по соседству со мной найдется пионер, который сделает мой внешний IP своим default gateway'ем, то он может попробовать на зуб мою внутреннюю сеть (в худшем случае перебрав все 256 вариантов), а я этого и не увижу...

P.S. То, что паранойю надо лечить, я знаю

 

Re: iptables и voip

А нат ты включать не планируешь?

 

Re: iptables и voip

я правильно помню что иптаблесы переделали, и всё что идёт мимо роутера попадает только в форвард?

тцпдамп на роутере покажет где что закольцевалось. Проход мимо форварда вроде как потенциально возможет через прероутинг, благо похоже что нат таки есть...

Параноя нужна.

 

Re: iptables и voip

Включен.

 

Re: iptables и voip

Это как?

Меня носом сюда ткнули:

http://wiki.mikrotik.com/wiki/File:IP_final.png

Будто бы из этой картинки (см.внизу, где расшифровывается forward) следует, что транзитные пакеты изымаются из потока в начале этого блока, но до правил.

 

Re: iptables и voip

Пошёл посмотреть что за -i в венде, оказалось ттл... Нет колец, нормальный ответ.

Ну да, ттл-1 до фильтра. Забавно, можно пинговать наглухо зафаерволенные роутеры... Надо будет тоже попробовать, хотя страшным оно не выглядит. С нормальным ттл пакеты проходить не будут.

едит: впрочем, запрет ицмп на аутпут должен убить ответы.

едит2: внутреннюю сеть никто не попробует, пакет с ттл=1 отроучен не будет в любом случае.

едит3: юдп скан это не остановит

 

sepukked

 

Re: iptables и voip

Скорее всего, но знаешь, сколько у меня в WAN идиотов? И тех, у которых MS network наружу, и тех, кто по DHCP адрес себе просит? И тех, у которых запрос DHCP из-за роутера наружу просачивается. Кто какие-то идиотские броадкасты на 255.255.255.255 посылают? И т.д. и т.п. Вот сломают такого... Или сам.

Угу, маркируешь соединение в mangle/prerouting и потом убиваешь related c этой отметкой в output... Но я логику разработчиков хочу понять. Почему на входе не убить? Вот, представь, найдут уязвимость в ядре? Некий "кривой" ICMP пакет посылаем, а он что-нибудь ломает?

Однако ее наличие будет обнаружено. Возможно, еще при этом определяется операционная система на роутере.

Ты хотел сказать, icmp флуд на внутренние адреса c TTL=1?