LinuxForum.Fans
Тема

Несколько вопросов по iptables

Автор: Liber 27 сообщений 8952 просмотров
#303277

Всем привет! Я начинающий пользователь linux. Так уж сложились обтоятельства, что мне приходится разбираться с наладкой маршрутизатора под управлением Debian 6. Понятное дело, по ходу возникает немало вопросов. Нижеприведенные вопросы я уже размещал на ЛОРе, но с ответами пока как-то негусто. Я подумал: может тут мне смогут помочь?..


Настраиваю роутер с NAT. Вроде даже все завелось. Но в том, что касается настройки iptables поначитался всякого - и манов, и статей, в голове каша. Не уверен, что все верно понимаю.

Есть пара вопросов. Если вдруг кому не жаль времени поглядеть - буду благодарен за ответы.

Схема сети следующая: домашние машины => коммутатор => маршрутизатор под управлением Debian с 2 ethernet интерфейсами => внутренняя сеть прова (с различными сервисами, включая DC, игровые серверы и т.п.) => IPsec VPN для доступа в интернет.

Правила настраиваются скриптом '/etc/network/if-pre-up.d/NAT'. Представляет собой компиляцию материалов из нескольких нагугленных статей, плюс некоторые личные дополнения:

text
#!/bin/bash

# Устанавливаем переменные окружения: LAN="eth1" WAN="eth0" VPN="ppp0" LAN_IP_RANGE="192.168.110.0/24" LAN_IP="192.168.110.1" WAN_IP="172.20.85.281" LIBER_IP="192.168.110.100" SNAKE_IP="192.168.110.101" SSH_PORT="22828"

# Включаем форвардинг пакетов и подгружаем модули: echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp

# Очищаем существующие таблицы правил: iptables --flush iptables --delete-chain iptables --table nat --flush iptables --table nat --delete-chain iptables --table mangle --flush iptables --table mangle --delete-chain

# Устанавливаем политики запрета всего: iptables --policy INPUT DROP iptables --policy OUTPUT DROP iptables --policy FORWARD DROP

# Разрешаем локальный траффик для loopback: iptables --append INPUT --in-interface lo --jump ACCEPT iptables --append OUTPUT --out-interface lo --jump ACCEPT iptables --append INPUT ! --in-interface lo --destination 127.0.0.0/8 --jump REJECT

# Явно разрешаем доступ к SSH из внутренней сети: iptables --append INPUT --protocol tcp --in-interface $LAN --destination-port $SSH_PORT --jump ACCEPT

# Явно разрешаем пинг: iptables --append INPUT --protocol icmp --icmp-type 8 --jump ACCEPT

# Запрещаем все пакеты, которые не могут быть идентифицированы и поэтому не могут иметь определенного статуса: iptables --append INPUT --match state --state INVALID --jump DROP iptables --append FORWARD --match state --state INVALID --jump DROP

# Приводит к связыванию системных ресурсов, так что реальный обмен данными становится невозможным, запрещаем: iptables --append INPUT --protocol tcp ! --syn --match state --state NEW --jump DROP iptables --append OUTPUT --protocol tcp ! --syn --match state --state NEW --jump DROP

# Разрешаем траффик для внутренней сети: iptables --append INPUT --in-interface $LAN --jump ACCEPT iptables --append OUTPUT --out-interface $LAN --jump ACCEPT

# Разрешаем входящие пакеты уже инициированных соединений, а также дочерние от них: iptables --append INPUT --protocol all --match state --state ESTABLISHED,RELATED --jump ACCEPT # Разрешаем исходящие пакеты новых, а так же уже инициированных и их дочерних соединений: iptables --append OUTPUT --protocol all --match state --state NEW,ESTABLISHED,RELATED --jump ACCEPT # Разрешаем форвардинг для новых, а так же уже инициированных и их дочерних соединений: iptables --append FORWARD --protocol all --match state --state NEW,ESTABLISHED,RELATED --jump ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU: iptables --insert FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

# Разрешаем доступ из внутренней сети наружу: iptables --append FORWARD --in-interface $LAN --out-interface $WAN --jump ACCEPT iptables --append FORWARD --in-interface $LAN --out-interface $VPN --jump ACCEPT

# Разрешаем доступ снаружи во внутреннюю сеть: iptables --append FORWARD --in-interface $WAN --out-interface $LAN --jump ACCEPT iptables --append FORWARD --in-interface $VPN --out-interface $LAN --jump ACCEPT

# NAT-маскарадинг: iptables --table nat --append POSTROUTING --out-interface $WAN --source $LAN_IP_RANGE --jump MASQUERADE iptables --table nat --append POSTROUTING --out-interface $VPN --source $LAN_IP_RANGE --jump MASQUERADE

################ # # Проброс портов # # Правила для каждого проброса: # 1 - Проброс внешнего порта на адрес в LAN # 2 - Перенаправление пакетов через NAT при обращении LAN-клиента к LAN-службе по ее WAN адресу # 3 - На случай, если клиент - сам маршрутизатор # 4 - Разрешающее правило для форвардинга из WAN в LAN

# Greylink DC++ iptables --table nat --append PREROUTING \ --protocol tcp --destination $WAN_IP --dport 22612 --jump DNAT --to-destination $LIBER_IP

iptables --table nat ---append POSTROUTING \ --protocol tcp --destination $LAN_IP --dport 22612 --jump SNAT --to-source $LIBER_IP

iptables --table nat --append OUTPUT \ --protocol tcp --destination $WAN_IP --dport 22612 --jump DNAT --to-destination $LIBER_IP

iptables --insert FORWARD 1 \ --protocol tcp --match tcp --in-interface $WAN --out-interface $LAN \ --destination $LIBER_IP --dport 22612 --jump ACCEPT

iptables --table nat --append PREROUTING \ --protocol tcp --destination $WAN_IP --dport 22682 --jump DNAT --to-destination $LIBER_IP

iptables --table nat ---append POSTROUTING \ --protocol tcp --destination $LAN_IP --dport 22682 --jump SNAT --to-source $LIBER_IP

iptables --table nat --append OUTPUT \ --protocol tcp --destination $WAN_IP --dport 22682 --jump DNAT --to-destination $LIBER_IP

iptables --insert FORWARD 1 \ --protocol tcp --match tcp --in-interface $WAN --out-interface $LAN \ --destination $LIBER_IP --dport 22682 --jump ACCEPT

Собственно вопросы:

1) Если все будет работать и так, то подгрузку модулей (modprobe ...) из скрипта лучше убрать?

2) Правильно ли я понимаю, что политики (iptables --policy) представляют собой нечто вроде глобальных правил по умолчанию? Т.е. если не найдено правило, условия которого соответствуют параметрам IP пакета, то выполняются действия, заданные политиками. Так?

3) Правило: iptables --append INPUT ! --in-interface lo --destination 127.0.0.0/8 --jump REJECT наверное, лучше заменить на DROP? Т.е. не будет ли лучшим ответом на такой пакет покерфейс и ледяное молчание?

4) Что касается раздела «Разрешаем доступ снаружи во внутреннюю сеть». При текущих правилах получается такая картина:

Если каким-то чудом на WAN интерфейс попадет пакет с IP назначения из диапазона LAN сети, то он будет пропущен. Но учитывая таблицы маршрутизации на роутерах прова, попасть на него он никак не должен.

С другой стороны, это потенциальная уязвимость, и разрешающие правила на форвардинг лучше давать на каждый конкретный порт при пробросе. Я прав? Как тут лучше поступить? Убрать эти правила и оставить блокировку таких пакетов на откуп политикам?

5) Прошу поглядеть, правильно ли сделан проброс портов. Нет ли ошибок? Попросить посканировать снаружи сейчас некого, а изнутри внешние порты просканировать не получается (пишет, что закрыто, хотя грей включен, а файер на десктопе отрублен). Хотя, по идее, должен сканить, благодаря второму правилу для проброса:

text
iptables --table nat ---append POSTROUTING \
        --protocol tcp --destination $LAN_IP --dport 22612 --jump SNAT --to-source $LIBER_IP

6) Еще по пробросу... Сейчас выглядит довольно неуклюже из-за обилия правил (по правилу для каждого порта). Я в курсе о расширении multiport, но сам его применять не стал, опасаясь напортачить в синтаксисе. Может быть, кто-нибудь сможет привести пример, как добавить порты?

7) И снова о пробросе: допустимо ли применение списка протоколов? Т.е. можно ли указать опцию --protocol tcp,udp и завязать оба протокола на один порт (для того же DC)?

8) Как я понимаю, проброс портов на VPN интерфейсе нужно делать отдельно (для торрент-клиента, например или того же DC++ при подключении к интернет-хабам). У меня сейчас динамический IP, можно ли указать в правиле --in-interface вместо --destination (т.е. название интерфейса вместо его IP)?

P.S. Ну и в целом буду благодарен за общие поправки по перечисленным правилам и указания на корявости и упущения, которые, уверен, я тут наляпал.

Большое спасибо!

#303303

Что, неужели не к чему придраться? Ни за что не поверю... :(

#303305
Liber написал:
Что, неужели не к чему придраться? Ни за что не поверю... :(

Вам что тут техподдержка платного продукта? Придут ребята глянут что и как.

#303308

Раз делаете

text
# Разрешаем доступ из внутренней сети наружу:
iptables --append FORWARD --in-interface $LAN --out-interface $WAN --jump ACCEPT
iptables --append FORWARD --in-interface $LAN --out-interface $VPN --jump ACCEPT

# Разрешаем доступ снаружи во внутреннюю сеть: iptables --append FORWARD --in-interface $WAN --out-interface $LAN --jump ACCEPT iptables --append FORWARD --in-interface $VPN --out-interface $LAN --jump ACCEPT

Тогда уш проще

text
iptables -P FORWARD ACCEPT

При выше изложенных правилах зачем это

text
iptables --insert FORWARD 1 \
        --protocol tcp --match tcp --in-interface $WAN --out-interface $LAN \
        --destination $LIBER_IP --dport 22682 --jump ACCEPT
#303309

Проброс делается в PREROUTING и не как в POSTROUTING
То что взяли за основу чужие конфиги это хорошо для понимания.
Но ещё лучше тогда почитать man.

#303389
"Kettler" написал:
Вам что тут техподдержка платного продукта? Придут ребята глянут что и как.
Да нет конечно. Не терпится просто уже маленько. Просмотров много, а ответов нет. На ЛОРе вон вообще никто ничего отвечать не стал (
Спасибо, что уделили время!

"Kettler" написал:
Тогда уш проще

iptables -P FORWARD ACCEPT

Вот у меня по этому поводу сомнения (п.4 первого поста). Наверное, все-таки лучше для каждого проброшенного порта разрешающие правила добавлять, а не так глобально?

"Kettler" написал:
При выше изложенных правилах зачем это

Нууу... это ведь еще не "железное" правило, а так, шаблон скорее. Про вышеизложенные правила я как раз вот и думаю сейчас, оставлять их или нет. Поэтому к каждому пробрасываемому порту добавил разрешающее правило на форвардинг. Чтоб он не умер внезапно, если чего изменю.

"Kettler" написал:
Проброс делается в PREROUTING и не как в POSTROUTING
Если честно, не очень я этот момент понимаю... То есть, неправильно в статейке было написано, и проброс сейчас не работает? Похоже, тут мне еще основательно повникать придется...

Еще раз спасибо!
#303390

Еще, если не осложнит... можно живой пример синтаксиса расширения multiport?

#303394
"Liber" написал:
1) Если все будет работать и так, то подгрузку модулей (modprobe ...) из скрипта лучше убрать?

Особой разницы нет, только если срипт при загрузе не стартует, а используется iptables-save/restore.

"Liber" написал:
3) Правило: iptables --append INPUT ! --in-interface lo --destination 127.0.0.0/8 --jump REJECT наверное, лучше заменить на DROP? Т.е. не будет ли лучшим ответом на такой пакет покерфейс и ледяное молчание?

Если и так политики в DROP смысла нет в этом правиле.

"Liber" написал:
Сейчас выглядит довольно неуклюже из-за обилия правил (по правилу для каждого порта).

Нормально всё выглядит.

#303397

"zenon" написал:
Особой разницы нет, только если срипт при загрузе не стартует, а используется iptables-save/restore.
Ясно.

"zenon" написал:
Если и так политики в DROP смысла нет в этом правиле.
Понятно. Я просто собирал наиболее интересные правила из разных источников. В том числе, чтобы:
а) не забыть
б) на случай дальнейшего изменения политик/других правил

Хотя это, конечно, лишнее правило, с которым нужно сверяться... Лучше пока его закомментировать, да?

Спасибо!
#303398

"zenon" написал:
Нормально всё выглядит.
То есть можно не заморачиваться? Если сделать список портов через запятую, разве не красивше вид будет?

Кстати, а перечислять протоколы: --p tcp,udp можно или недопустимо? (Конечно, если в опциях ничего конфликтного нет: например, опций, неприменимых к udp-датаграмам?)
#303402

Мне понравилась вот такая реализация - это если красиво.

#303403

Большое спасибо за материалы! Поштудирую.

#306144
"zenon" написал:
Почитай гентушные доки
...
Логика_и_правила_iptables

Немного не пойму вот этого участка из приведенного источника:

text
# 2. Входящий SSH трафик
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N ssh-in
  $IPTABLES -F ssh-in
  $IPTABLES -A ssh-in -p tcp --dport 22 -j ACCEPT
# Защита о флуда по SSH
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

Сперва правилом $IPTABLES -A ssh-in -p tcp --dport 22 -j ACCEPT безусловно разрешаются входящие TCP соединения на 22й порт. А потом добавляется ворох правил с ограничением по времени в качестве защиты от флуда. Какой в этом смысл? Ведь до них просто не будет до ходить дело: будет постоянно отрабатывать первое разрешающее правило. И если его поставить после правил с limit, это тоже играть роли не будет.

В чем я не прав?

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

Спасибо!

#306145

P.S. тогда уж сделать правило таким:

text
$IPTABLES -A ssh-in -m limit ! --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j DROP

(если я верно понял описание этого модуля из доков)

#306147

Пытаюсь сам вниктуть в ssh-in цепочку, созданную там, вроде идея при политиках DROP завернуть 22 порт в ssh-in и пропустить только то что можно... как-то не стыкуется немного. _:(

#306155

Мне кажется, там все-таки ошибка... *SCRATCH*
Вот как предложено в другом источнике из списка:

text
  #Incoming traffic
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  #Flood protection
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

Тут, по крайней мере, все понятно и логично...

Правда, я не совсем понимаю сути этой защиты... Если какой-то усердный товарищ будет долбить 22й порт такими пакетами, то ведь и "честный" пользователь будет испытывать проблемы при подключении? Тут уж кому повезет - чей пакет первым проскочит в очередную секунду, разве нет?

#306158

На счет "долбить" - смотря что подразумевать, если брут, то ничего страшного, подолбится и перестанет, там же не масштабов ddos коннекты.
...
Ну вот из "классики":

text

1 iptables -N ssh_brute_check 
2 iptables -A ssh_brute_check -m conntrack --ctstate NEW -m recent --update --seconds 600 --hitcount 3 -j DROP
3 iptables -A ssh_brute_check -m recent --set -j ACCEPT
4 iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_brute_check

1 Создаем цепочку для проверки попыток соединений на защищаемый порт
2 Если за последние 10 минут (600 секунд) с одного адреса было 3 или более новых соединений — блокируем этот адрес
3 В противном случае — разрешаем
4 Все попытки открыть новое соединение по SSH направляем на проверку
...
Есди правило такое:

text
iptables -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT

Трактовка примерно такая - будут приняты не более одного tcp пакета в секунду с флагами ALL RST
Всё остальное на усмотрение установленной политики (DROP в нормальном варианте).

#306173

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

> Трактовка примерно такая - будут приняты не более одного tcp пакета в секунду с флагами ALL RST
Это я понял... Я не понял смысла такой меры. Исключительно защита буфера от зафлуживания?

Например, при усердном флуде SSH порта SYN пакетами с подменой IP отправителя (даже с одной машины можно генерировать кучу пакетов в секунду) переполнения буфера полуоткрытых соединений не произойдет, но "законопослушному" пользователю будет подключиться не реально. Т.к. вероятность того, что именно на его пакете правило сработает на разрешение обратно пропорциональна количеству флуд-пакетов. Или я не прав?

#306175
Liber написал:
но "законопослушному" пользователю будет подключиться не реально. Т.к. вероятность того, что именно на его пакете правило сработает на разрешение обратно пропорциональна количеству флуд-пакетов. Или я не прав?

Законопослушный пользователь с ip адресом отправителя флуда?

Войдите или зарегистрируйтесь, чтобы ответить.