HOWTO: Iptables для новичков

[AnrDaemon]

Спасибо что откликнулись AnrDaemon
По поводу примеров использования conntrack в голове каша такая же как и с established,related- уже установленные соединения, меня это вводит в ступор, да я вижу как используется там правило но это не помогает его понять.

conntrack используется именно для того, для чего предназначен - для установление факта отношения каждого отдельного пакета к тому или иному открытому соединению. И, конечно, для установления состояния этого соединения. NEW - запрос на соединение, ESTABLISHED - соединение в процессе работы, RELATED - пакет относится к соединению (попытке соединения), но по сути не является его частью (ICMP ответ на попытку установки TCP соединения, подтверждение запроса на подключение, ...), INVALID - комбинация аттрибутов пакета в лучшем случае бессмысленна, DNAT - пакет был подвергнут динамической маршрутизации, ну и т.д.

Определись уже, INPUT или FORWARD. От этого зависит ответ.

Я о том что это единственное разрешающее правило там, помимо открытия одиночного порта для клиента

Такая попытка по меньшей мере странная
Если это открытый шлюз, conntrack использовать для разрешения как-то бессмысленно. Скорее, это должно быть единственное запрещающее правило.
Если это брандмауэр с натом - тогда одним правилом тут не отделаешься.

вот правила,
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT
-A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# - вот у вас так, conntrack насколько я понимаю используются для ограничения количества попыток
# соединений за определенное время? но тут нет параметров. У вас conntrack используется во всех
# правилах, маскардинга у вас нет у меня же адрес динамический.

Для ограничения дятлов используется модуль state в цепочке SSH_CHECK.
В nat/PREROUTING стоит правило conntrack для предотвращения ситуации с переначиванием уже заDNATенных пакетов.

-A PREROUTING -p tcp -m tcp --dport 42167 -j DNAT --to-destination 192.168.1.2:42167

Например, этих пакетов.

-A POSTROUTING -o eth1 -s 192.168.1.0/24 -j MASQUERADE
-A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE

Обратите внимание, у вас ppp0 - исходящий интерфейс. Мы ещё вернёмся к этому отличию чуть позже.
В вашем случае можно убрать указание адреса источника, маскарад сам разберётся, если действительно надо будет натить пакеты. Два раза дурную работу делать не будет

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
:icmp-in

:OUTPUT DROP - это почти всегда ошибка в настройке.

-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i eth1 -p gre -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT

Вот здесь, смотрите, что у вас получается. И что - у меня.
У вас:
ВСЕ пакеты проверяются на вышеотквоченные правила (worst case, так сказать).
У меня:
ВСЕ пакеты проверяются на ОДНО правило:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Пакеты, не признанные предыдущим правилом, проверяются на локальность (-m conntrack здесь не более, чем перестраховка)
-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT
Принимаются все пакеты icmp и gre
-A INPUT -p gre -j ACCEPT
-A INPUT -p icmp -j ACCEPT
Ты ещё тут?? Принимаются пакеты из локальной сети (со всех интерфейсов - eth1 на этой системе реально не существует )
-A INPUT -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
Что, ОПЯТЬ??? Всё, что до сих пор не нашло своего ACCEPT'а, заталкивается в спамоловку
-A INPUT -p tcp -m multiport --dports 9,22,25,110 -m conntrack --ctstate NEW -j SSH_CHECK
Всё, что пережило предыдущее правило, проверяется ещё десятком фильтров, но это - слёзы, по сравнению с трафиком, отсеиваемым самым первым правилом.

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

$ uptime; iptables -vL
 13:13:23 up 4 days, 12:04,  3 users,  load average: 0.06, 0.01, 0.00
Chain INPUT (policy DROP 21616 packets, 3764K bytes)
 pkts bytes target     prot opt in     out     source               destination
4010K(100%) 1152M(100%) ACCEPT     all  --  any    any     anywhere             anywhere            ctstate RELATED,ESTABLISHED
19360(0,47%) 1434K(0,12%) ACCEPT     all  --  lo     any     anywhere             anywhere            ctstate NEW
    0     0 ACCEPT     gre  --  any    any     anywhere             anywhere
  200(0,0049%) 12008(0,0010%) ACCEPT     icmp --  any    any     anywhere             anywhere
45928(1,12%) 5505K(0,47%) ACCEPT     all  --  !eth1  any     192.168.35.0/24      anywhere            ctstate NEW
 4017(0,10%)  193K(0,02%) SSH_CHECK  tcp  --  any    any     anywhere             anywhere            multiport dports discard,ssh,smtp,pop3 ctstate NEWСравните со своим...

-A INPUT -i eth0 -p tcp -m tcp --dport 137:139 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 137:139 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 445 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 445 -j ACCEPT

Не проще локалку разрешить и не мучаться?

-A INPUT -i eth0 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 21 -j ACCEPT

А...
-A INPUT -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
...не?

-A INPUT -i ppp0 -s 192.168.1.1 -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i eth1 -s 192.168.1.1 -p udp -m udp --dport 1194 -j ACCEPT

Немного не понял структуры ваших сетей.

-A INPUT -i ppp0 -s 192.168.1.2 -p tcp -m tcp --dport 42167 -j ACCEPT
-A INPUT -i eth1 -s 192.168.1.2 -p tcp -m tcp --dport 42167 -j ACCEPT

Вы этот порт заDNATили, что он делает в INPUT?

-A INPUT -p icmp -m icmp --icmp-type 8 -j DROP

Смысл? Смотрите выше, icmp трафик - это слёзы. Проще его пропускать весь, чем городить огород с правильной фильтрацией. (А это правил десять минимум!)

# жуткая портянка дропов

Все инвалидные флаги и правила, не попавшие в ACCEPT, ловятся conntrack'ом... нет смысла заморачиваться дополнительно при -P INPUT DROP

# dhcp local

Замените state на conntrack... и откройте OUTPUT. Всё заработает.

multiport --dports 9,22,25,110

т.е так 137:445 диапазон, а через , единичные порты, не знал, отдельное спасибо

man iptables ?
Диапазон можно и через тире. (вроде)

Так же хотелось бы спросить, почему вы закрыли порт 110 pop3 именно так, а не тихим дроп?

Чтобы клиент не гадал, что случилось с пакетом.

-A INPUT -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT

Вот этот "!" он же в разных случаях по разному действует?

Этот ! действет всегда одинаково. Отрицает правило. "Пришло не с eth1".

-A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1357:1500 -j TCPMSS --set-mss 1356

У меня есть правило которое исправляет mtu, но оно подгружается после поднятия ppp+
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1500 -j TCPMSS --clamp-mss-to-pmtu -o ppp0
без него страницы не открываются

Вот мы и добрались до разницы. У меня ppp соединения - входящие
В моём случае --clamp-mss-to-pmtu не работает, MSS сервера на исходящих ограничен сверху только одним натом (1460 байт).
На входящих ppp соединениях же MTU 1396, чтобы работал интернет за натом, надо сказать клиентам, чтобы понизили MSS ЕЩЁ на 40 байт. 1356 (см. правило выше).

[connectof]

Сложно конечно, я себе всю эту структуру представлял более топорно, по поводу статуса соединения, кое что нашел.

(Нажмите, чтобы показать/скрыть)

TCP соединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи SYN пакета, в ответ на который передается SYN/ACK пакет и подтверждает установление соединения пакет ACK. После этого соединение считается установленным и готовым к передаче данных.

но, насколько я понимаю соединение не может быть установлено если есть общее запрещающее правило или правило указывающие конкретно что именно запрещено, из моих правил выходит что -m state --state NEW,ESTABLISHED -j ACCEPT, дыры, т.е оно пропускает все
AnrDaemon

Такая попытка по меньшей мере странная Smiley
Если это открытый шлюз, conntrack использовать для разрешения как-то бессмысленно. Скорее, это должно быть единственное запрещающее правило.
Если это брандмауэр с натом - тогда одним правилом тут не отделаешься.

Попытка сделать брандмауэр с натом конечно же, что вы посоветуете?

Немного не понял структуры ваших сетей.

eth1 локальная сеть от провайдера, довольно таки загаженная, сыплется неимоверное количество попыток соединений в секунду по разным портам.
ppp0  поднят openl2tpd, интернет.
eth0 локальная сеть

Для ограничения дятлов используется модуль state в цепочке SSH_CHECK.

Мда conntrack, connlimit, путал их, так не приходилось использовать. conntrack оказывается более продвинутый вариант -m state. Сложно понять нечто большее не имея соотв. образования. Можно сесть и нарисовать себе схему, но не думаю что это существенно изменить что то...
О state и conntrack, lor

(Нажмите, чтобы показать/скрыть)

О state и conntrack

Что лучше использовать второй понятно было и так, с ваших слов
conntrack управляет состоянием соединений, правила типа icmp type 11 и 3 мне не нужны?

предотвращения ситуации с переначиванием уже заDNATенных пакетов.

пакетов которые перенаправлены на конкретную машину внутри сети? что значит "переначиванием"? что с ними происходит? я понял лишь то что conntrack помогает определить статус nat пакетов, и что то предпринимает. Но на практике это ничего не дает

Ты ещё тут?

хотел тоже самое спросить, спасибо что так развернуто ответили, не поленились

OUTPUT DROP - это почти всегда ошибка в настройке.

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

ВСЕ пакеты проверяются на вышеотквоченные правила (worst case, так сказать).

замедляет работу? А icmp я боюсь уже разрешать, почитал что люди пишут, последил в своё время за коробочкой-роутером и его логами там после сканирования портов шли атаки разного рода, когда он не отвечал на запросы пинга и была включена защита от сканирования портов, их поубавилось

Вы этот порт заDNATили, что он делает в INPUT?

а без этого не работало
filter же действует для внутренней сети которая за натом?

Этот ! действет всегда одинаково. Отрицает правило. "Пришло не с eth1".

все кроме eth1?
-A INPUT -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
вот эти правила разрешающие, мне бы как то попроще, закрыться от внешки и разрешить только то что нужно.

[bubuntu-ru]

eth1 локальная сеть от провайдера, довольно таки загаженная, сыплется неимоверное количество попыток соединений в секунду по разным портам.

виндовые машины в сети есть, хоть они и всегда чистые и под контролем, лучше перестраховаться думал я
А icmp я боюсь уже разрешать, почитал что люди пишут, последил в своё время за коробочкой-роутером и его логами там после сканирования портов шли атаки разного рода, когда он не отвечал на запросы пинга и была включена защита от сканирования портов, их поубавилось

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

Если соединения идут по разным портам с разных хостов, обычная проба. Если типа так, 192.168.1.100 и с 0 до 65535  портов, тогда скан.
Если отдача в дропе по дефолту,  ошибок не будет.
3 пинга уж можно включить, а как же пинг с хостов в локалке и трассер как минимум.
Если и есть защита от пинга, даже nmap многое узнает -PN (хотя если айпитаблес  нормально настроить, nmap, он нагнет )
Если попроще, то пластиковый роутер нормальный вариант будет.

[AnrDaemon]

Forewarning: Мая есть пить, за ашипки не ругать.

Сложно конечно, я себе всю эту структуру представлял более топорно, по поводу статуса соединения, кое что нашел.

(Нажмите, чтобы показать/скрыть)

TCP соединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи SYN пакета, в ответ на который передается SYN/ACK пакет и подтверждает установление соединения пакет ACK. После этого соединение считается установленным и готовым к передаче данных.

Представлял топорно, или структуру топорно?
По поводу спойлера - conntrack как раз следит за этим, и ещё за кое-чем. Я сам до конца не разбирался, но по диагонали документацию пробежал.

но, насколько я понимаю соединение не может быть установлено если есть общее запрещающее правило или правило указывающие конкретно что именно запрещено,

Вообще - да. В частности - надо смотреть конкретные наборы правил.

из моих правил выходит что -m state --state NEW,ESTABLISHED -j ACCEPT, дыры, т.е оно пропускает все

Скажем так, большую часть. В отсутствие RELATED не проходят сервисные пакеты, это может вводить в ступор некоторые приложения.
И, как я уже сказал, мешать NEW с ESTABLISHED - создавать слабо управляемую (если вообще) кашу.

AnrDaemon

Такая попытка по меньшей мере странная Smiley
Если это открытый шлюз, conntrack использовать для разрешения как-то бессмысленно. Скорее, это должно быть единственное запрещающее правило.
Если это брандмауэр с натом - тогда одним правилом тут не отделаешься.

Попытка сделать брандмауэр с натом конечно же, что вы посоветуете?

Нарисовать схему маршрутизации в сети на большом листе. А3 или больше.
Ваши сомнения в целесообразности беспочвенны, это поможет
Просто распечатайте на второй лист вот эту табличку, поставьте палец на свою схему маршрутизации и воообразите себя пакетом. Проведите пальцем по всей карте, выписывая названия таблиц и цепочек, через которые проходит пакет. Дополните их правилами... Потом внесите всё в компьютер.

Немного не понял структуры ваших сетей.

eth1 локальная сеть от провайдера, довольно таки загаженная, сыплется неимоверное количество попыток соединений в секунду по разным портам.

Фигня всё это... Я вот на следующей неделе ещё одну хаутушку опубликую, думаю, вам будет небезынтересно.

ppp0  поднят openl2tpd, интернет.
eth0 локальная сеть

Ясно.

Для ограничения дятлов используется модуль state в цепочке SSH_CHECK.

Мда conntrack, connlimit, путал их, так не приходилось использовать. conntrack оказывается более продвинутый вариант -m state.

Скорее, более адекватный и современный.

Сложно понять нечто большее не имея соотв. образования.

Вы всё правильно поняли
Для _настройки_ большего знать в общем-то необязательно. Хотя, не скрою, желательно.

О state и conntrack, lor

По-моему, обычный звездёж Что в общем-то обычно для лора. (Это не значит, что они не правы, просто не понравился заданный участниками тон разговора)

conntrack управляет состоянием соединений, правила типа icmp type 11 и 3 мне не нужны?

Нет. Правило -m conntrack --ctstate ESTABLISHED,RELATED, записанное в начало цепочки, вообще покрывает, как вы видели, более 90% всех проходящих пакетов. Ибо раз мы разрешили установку этого соединения, глупо перепроверять на валидность каждый отдельный входящий в него пакет.

предотвращения ситуации с переначиванием уже заDNATенных пакетов.

пакетов которые перенаправлены на конкретную машину внутри сети? что значит "переначиванием"? что с ними происходит? я понял лишь то что conntrack помогает определить статус nat пакетов, и что то предпринимает. Но на практике это ничего не дает

Мая есть пьян и ленив. Так что копаться в поиске не беду, просто скажу, что возможна ситуация, в которой уже перенаправленное установленное соединние оказывается ещё раз перенаправлено, уже по другому адресу либо с другими параметрами, что напрочь убивает возможность его использования.
При этом внешне правила кажутся рабочими.

Ты ещё тут?

хотел тоже самое спросить, спасибо что так развернуто ответили, не поленились

Ну, "ты ещё тут" относилось к пакету... надеюсь, это было понятно

OUTPUT DROP - это почти всегда ошибка в настройке.

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

DROP в цепочке OUTPUT никак не поможет, а вот вредит изрядно, заставляя писать куча странных, плохо читаемых правил, которые потом ещё приходится комментировать (чтобы не забыть) и поддерживать в актуальном виде.
(Кивая в сторону вышеупомянутой таблички) цепочка OUTPUT вообще относится полностью к самому серверу.

ВСЕ пакеты проверяются на вышеотквоченные правила (worst case, так сказать).

замедляет работу?

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

(Нажмите, чтобы показать/скрыть)

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i eth1 -p gre -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -j ACCEPT

А icmp я боюсь уже разрешать, почитал что люди пишут, последил в своё время за коробочкой-роутером и его логами там после сканирования портов шли атаки разного рода, когда он не отвечал на запросы пинга и была включена защита от сканирования портов, их поубавилось

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

Вы этот порт заDNATили, что он делает в INPUT?

а без этого не работало

Значит, где-то ошиблись с настройкой.

filter же действует для внутренней сети которая за натом?

Таблица filter действует... выше ссылка.

Этот ! действет всегда одинаково. Отрицает правило. "Пришло не с eth1".

все кроме eth1?

Я как бы именно это и сказал. Ибо интерфейсов реально много

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 6c:f0:49:d1:de:75
          inet addr:192.168.35.1  Bcast:192.168.35.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10847125 errors:0 dropped:3407177662 overruns:0 frame:0
          TX packets:13994881 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1232041823 (1.1 GB)  TX bytes:1553517964 (1.4 GB)
          Interrupt:220 Base address:0xa000

eth0:1    Link encap:Ethernet  HWaddr 6c:f0:49:d1:de:75
          inet addr:192.168.10.2  Bcast:192.168.10.15  Mask:255.255.255.240
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:220 Base address:0xa000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:532643 errors:0 dropped:0 overruns:0 frame:0
          TX packets:532643 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:113989838 (108.7 MB)  TX bytes:113989838 (108.7 MB)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.35.1  P-t-P:192.168.35.200  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:189 errors:0 dropped:0 overruns:0 frame:0
          TX packets:211 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:22772 (22.2 KB)  TX bytes:21498 (20.9 KB)

ppp1      Link encap:Point-to-Point Protocol
          inet addr:192.168.35.1  P-t-P:192.168.35.200  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:162 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:14065 (13.7 KB)  TX bytes:102 (102.0 B)

-A INPUT -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
вот эти правила разрешающие, мне бы как то попроще, закрыться от внешки и разрешить только то что нужно.

Так у нас запрещено всё, что не разрешено Потому и правила все разрешающие... кроме специально оговорённых запрещающих.
Внимательно ещё раз перечитайте man iptables, часть TARGETS.
P.S.
Приведённый мной в предыдущем сообщении конфиг может служить таким себе примером минималистического подхода к настройке маршрутизатора. Там есть немного мусора и отсутствует одно правило, но в остальном - только необходимое.

[connectof]

bubuntu-ru

Если попроще, то пластиковый роутер нормальный вариант будет.

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

3 пинга уж можно включить, а как же пинг с хостов в локалке и трассер как минимум.

Да конечно. за traceroute отвечает тот же пинг вроде бы, нет? поправьте меня тогда
AnrDaemon
это все хорошо, судя по таблице выходит что пакеты идущие через форвард фильтрацию не проходят, но если судить иначе, пакеты приходят на внешние адреса и только потом передаются внутренней подсети о.0
 Сегодня еще русскую вики полистал (на удивление, там очень хорошо некоторые вещи разобраны )
Изменил правила, стал использовать -m conntrack --ctstate, вроде бы все гладко.

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

-A INPUT -i lo -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT


тут идет куча различных дропов всякого рода гадости ну и разрешение нужных соединений

без этих адских разрешающих правил так ничего и не завелось

Код: [Выделить]

-A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
я сделал так в конце всех input правил

Код: [Выделить]

-A INPUT -i eth0 -m conntrack --ctstate NEW -p tcp --sport 0:1023 -j DROP
-A INPUT -i eth1 -p udp -m udp --dport 0:65535 -j DROP
-A INPUT -i eth1 -p tcp -m tcp --dport 0:65535 -j DROP
-A INPUT -i ppp0 -p udp -m udp --dport 0:65535 -j DROP
-A INPUT -i ppp0 -p tcp -m tcp --dport 0:65535 -j DROP


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

-A FORWARD ! -s 192.168.1.0/24 -m conntrack --ctstate NEW -p tcp --sport  0:65535 -j DROP

И так, - если источник ПРИХОДЯЩЕГО транзитного трафика не подсеть 192. посылаем нафиг, т.е должно блокировать все из вне, оно?

[AnrDaemon]

Ещё раз, медленно.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT !!!!!!!!!!!!!!!!!!!!!!!!!!!!
Дальше разрешаем только то, что должно быть разрешено.
Никаких дополнительных дропов городить не надо.

P.S.
Маршрутизированные пакеты проходят фильтр - в своей собственной цепочке. Ссылку на карту я давал.

[Lion-Simba]

Не совсем понимаю принцип действия
-m state --state NEW,ESTABLISHED -j ACCEPT

-m conntrack
state не работает с UDP.

Пруф?

[AnrDaemon]

Лень.
Даже если я был не прав, смысл ломать копья об архаичные модули? Использовать его ты всё равно не будешь.

[Lion-Simba]

Лень.

А вводить людей в заблуждение вам не лень.

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

Я его использую. Успешно. Вместе с UDP.

Как правильно было подмечено здесь:

Не надо путать систему conntrack и критерий conntrack. state предоставляет такой же интерфейс к той же самой системе conntrack, только куцый и урезанный до невозможности.

Это же подтверждается исходниками. Если мне из всего conntrack нужны только состояния NEW, ESTABLISHED и RELATED, зачем мне весь остальной интерфейс conntrack?

В связи с этим мне не понятно ваше повсеместное желание отучить всех пользоваться -m state.

[AnrDaemon]

Так такой же, или куцый и урезанный? Определитесь уже, а то дискуссим не получается - я от смеха из-под стола вылезти не могу.

[Lion-Simba]

Так такой же, или куцый и урезанный? Определитесь уже, а то дискуссим не получается - я от смеха из-под стола вылезти не могу.

Интерфейс - урезанный, но к той же самой реализации. Это не два разных модуля, это два разных интерфейса к одному и тому же модулю. Если мне не нужны все возможности модуля, то мне хватит и урезанного интерфейса.

Модуль всего один - conntrack. Это подсистема ядра.
А интерфейсов к нему два - state и conntrack (да, он называется так же, как и сама подсистема).
Интерфейс state явялется подмножеством интерфейса conntrack.

[Pro_ceed]

Да, есть... Извиняюсь. А интернет ползёт через tun? Может правило "-A FORWARD -o tun+ -j ACCEPT" дырочку для таких действий оставило?
Если покажешь результирующую таблицу правил - будет наглядней

Код: [Выделить]

sudo iptables-save

Извиняюсь что не написал раньше были маленькие технические неувязки.
Параметры сети:

PPP0 (eth1)-------squid3------- eth2 (локальная сеть)

Вот вывод на команду sudo iptables-save:

(Нажмите, чтобы показать/скрыть)

# Generated by iptables-save v1.4.4 on Wed Dec  8 16:08:56 2010
*mangle
:PREROUTING ACCEPT [3898569:2484430904]
:INPUT ACCEPT [1637903:978050980]
:FORWARD ACCEPT [2242667:1504920986]
:OUTPUT ACCEPT [1682174:1050232087]
:POSTROUTING ACCEPT [3924799:2555151316]
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Wed Dec  8 16:08:56 2010
# Generated by iptables-save v1.4.4 on Wed Dec  8 16:08:56 2010
*nat
:PREROUTING ACCEPT [145354:11684914]
:POSTROUTING ACCEPT [518:31835]
:OUTPUT ACCEPT [42364:2587653]
-A PREROUTING -d 192.168.254.1/32 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.101.101:3389
-A PREROUTING -s 192.168.101.0/24 -d 192.168.101.100/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A PREROUTING -s 192.168.101.0/24 -d 192.168.101.100/32 -p tcp -m tcp --dport 8080 -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 3128
-A POSTROUTING -d 192.168.101.101/32 -p tcp -m tcp --dport 3389 -j SNAT --to-source 192.168.101.100
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
# Completed on Wed Dec  8 16:08:56 2010
# Generated by iptables-save v1.4.4 on Wed Dec  8 16:08:56 2010
*filter
:INPUT DROP [0:0]
:FORWARD DROP [2:80]
:OUTPUT ACCEPT [14818:7552407]
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
-A INPUT -i ppp+ -m state --state INVALID,NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT ! -i ppp+ -m state --state NEW -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3333 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 26 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -s 192.168.101.0/24 ! -d 192.168.101.100/32 -p tcp -m tcp --dport 3128 -j DROP
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -o tun+ -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth2 -p tcp -m conntrack --ctstate NEW -m multiport --dports 20,21,26,465,25,110,3128
-A FORWARD -i eth2 -p udp -m conntrack --ctstate NEW -m udp --dport 53 -j ACCEPT
-A FORWARD -i eth2 -o ppp0 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.101.0/24 ! -d 192.168.101.100/32 -p tcp -m tcp --dport 3128 -j DROP
COMMIT
# Completed on Wed Dec  8 16:08:56 2010

[merfo]

Что то буксую... Подскажите пожалуйста.
Задача простейшая, в принципе.
Нужно исходящий запрос на определённый IP направить на 127.0.0.1
Как будет правило выглядеть?

[fisher74]

По идее

Код: [Выделить]

-t nat -A OUTPUT -d xx.xx.xx.xx -j DNAT --to-destination 127.0.0.1Только вот как это дальше цепочки OUTPUT пойдёт и пойдёт ли - чёт я затрудняюсь...

[AnrDaemon]

Что то буксую... Подскажите пожалуйста.
Задача простейшая, в принципе.
Нужно исходящий запрос на определённый IP направить на 127.0.0.1
Как будет правило выглядеть?

Задача поставлена некорректно.  (Или если точнее, условие задачи сильно смахивает на создание дыры в безопасности шлюза)
Какая реальная цель такого перенаправления? От этого будет зависить правильный ответ на вопрос.