IPB

Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  < 1 2  
Ответить в эту темуОткрыть новую тему
> Настройка iptables
keyboarder
сообщение 26.12.2005, 16:22
Сообщение #26





Гости





Цитата(Gall @ 26.12.2005, 00:15)
А если сначала рассортировать по нескольким цепям, а потом в каждой цепи сделать свои правила?
*



так ничего не поменяется. траффик ведь только по портам различается. а если мы не знаем, на какой порт происходит подключение, то ничего поделать не можем. надо вот ещё попробовать CONNMARK --restore-mark на исходящих пакетах, для соединения, для которого выполнялось CONNMARK --save-mark на входящем RELATED подключении.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
Mayor
сообщение 27.12.2005, 00:52
Сообщение #27





Группа: Пользователи
Регистрация: 7.12.2004
Из: Бурик-II
Пользователь №: 3 331



а через limit можно скорость соединения ограничить? но только не за счет возрастания трафика ?

Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
keyboarder
сообщение 27.12.2005, 19:14
Сообщение #28





Гости





Цитата(Mayor @ 27.12.2005, 00:52)
а через limit можно скорость соединения ограничить? но только не за счет возрастания трафика ?
*



limit - это ограничения на количество выбираемых пакетов за секунду. хм. наверное, можно, но кажется, что это не лучший способ.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
keyboarder
сообщение 2.1.2006, 18:10
Сообщение #29





Гости





а состояние у conntrack'ера меняется до того, как пакет попал на обработку в iptables или после? пакет, который является ответом на устанавливаемое соединение - это уже ESTABLISHED или ещё нет?
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
ssh
сообщение 2.1.2006, 18:18
Сообщение #30





Группа: Модераторы
Регистрация: 22.6.2004
Пользователь №: 2 239



Цитата(keyboarder @ 2.1.2006, 18:10)
а состояние у conntrack'ера меняется до того, как пакет попал на обработку в iptables или после? пакет, который является ответом на устанавливаемое соединение - это уже ESTABLISHED или ещё нет?
*


1) iptables видит пакет как related, следовательно - до

2) да, уже established
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
keyboarder
сообщение 8.1.2006, 15:46
Сообщение #31





Гости





вот. сварганил небольшbt скриптики по настройке iptables и tc. тестировал неделю, всё работает. может быть, окажется кому полезным. постараюсь ещё и объяснить, что тут к чему.

цель у всего такая: выделить траффик, который относиться к обмену файлами через ftp и overnet. разрешить его только внутри сегмента и получить возможность ограничивать скорость скачивания файлов с хоста.

в скрипте используются переменные

ftppassive - диапазон портов (или один порт) для пассивных data соединений ftp.
overnet - tcp порт overnet клиента.
overnetudp - udp порт.
nets - это сети, которым хочется открыть доступ.

чистим таблицы filter и mangle. где будет происходить вся работа.

Исходный код
ipt="iptables"
iptm="iptables -t mangle"

$ipt    -F
$iptm   -F


цепочки, в которые будут попадать отклассифицированные пакеты. в этих очередях будет происходить проверка на то, что пакеты и соединения относятся к допустимым ip, и расстановка меток на соединения и udp пакеты.

Исходный код
$iptm -N IFTP
$iptm -N OFTP
$iptm -N IOVERNET
$iptm -N OOVERNET
$iptm -N IOVERNETUDP
$iptm -N OOVERNETUDP


классификация входящих соединений: это ftpcontrol (21), ftpdata для пассивных соединений (ftppassive) и overnet. и отлов overnet'овского udp пакета. нужно обратить внимание на --state NEW. НЕ ВСЕ пакеты перелопачиваются для tcp соединений, а только лишь NEW.

Исходный код
$iptm -A INPUT -p tcp --dport 21 -m state --state NEW -j IFTP
$iptm -A INPUT -p tcp --dport $ftppassive -m state --state NEW -j IFTP
$iptm -A INPUT -p tcp --dport $overnet -m state --state NEW -j IOVERNET
$iptm -A INPUT -p udp --dport $overnetudp -j IOVERNETUDP


классификация исходящего траффика. это активное ftpdata (20). и overnet'овские порты. опять же --state NEW, чтобы не все подряд пакеты перелапачивать, а только нужные.

Исходный код
$iptm -A OUTPUT -p tcp --sport 20 -m state --state NEW -j OFTP
$iptm -A OUTPUT -p tcp --sport $overnet -m state --state NEW -j OOVERNET
$iptm -A OUTPUT -p udp --sport $overnetudp -j OOVERNETUDP


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

можно сказать, что все правила ортогональны (не пересекаются по условиям), но из-за глупости реализации netfilter, правила -j ACCEPT действительно обрывают цепочки и немного ускоряют обработку траффика

Исходный код
for i in $nets; do
       $iptm -A IFTP -s $i -j CONNMARK --set-mark 1
       $iptm -A IFTP -s $i -j ACCEPT
       $iptm -A OFTP -d $i -j CONNMARK --set-mark 1
       $iptm -A OFTP -d $i -j ACCEPT
       
       $iptm -A IOVERNET -s $i -j CONNMARK --set-mark 1
       $iptm -A IOVERNET -s $i -j ACCEPT
       $iptm -A OOVERNET -d $i -j CONNMARK --set-mark 1
       $iptm -A OOVERNET -d $i -j ACCEPT

       $iptm -A IOVERNETUDP -s $i -j MARK --set-mark 1
       $iptm -A IOVERNETUDP -s $i -j ACCEPT
       $iptm -A OOVERNETUDP -d $i -j MARK --set-mark 1
       $iptm -A OOVERNETUDP -d $i -j ACCEPT
done


теперь. в filter.INPUT и в filter.OUTPUT все соединения и udp пакеты к overnet и ftp из правильных сетей будут помечены единичкой. этим и пользуемся при написании следующего блока правил. это уже для таблици filter. здесь, кстати, ещё важно то, что НЕ отбрасываются ВСЕ входящие соединения и пакеты, а пропускаются лишь те, что идут к ftp и overnet. производиться анализ только траффика к ftp и overnet. другие каналы никак не задеваются. что позволяет, например, спокойно гонять файлы через direct client conntect irc или icq.

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

Исходный код
$ipt -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT


анализируем по типам траффика. всё просто. если tcp соединение - НЕ ESTABLISHED (NEW, или ещё какое другое) соединение, и не отмаркированное 1 (а маркируется только правильное соединение), то они отбрасываются. для проверки меток tcp используется connmark. с udp та же самая идея. но метку, естественно, проверяем при помощи mark.

внимание можно обратить на первое правило в блоке. в filter.INPUT не бывает не ESTABLISHED соединений с 20 активного ftpdata порта. надо это зарезать на всякий случай.

Исходный код
$ipt -A INPUT -p tcp --dport 20 -j DROP
$ipt -A INPUT -p tcp --dport 21 -m connmark ! --mark 1 -j DROP
$ipt -A INPUT -p tcp --dport $ftppassive -m connmark ! --mark 1 -j DROP
$ipt -A INPUT -p tcp --dport $overnet -m connmark ! --mark 1 -j DROP
$ipt -A INPUT -p udp --dport $overnetudp -m mark ! --mark 1 -j DROP


с filter.OUTPUT та же самая история. установленные tcp соединения не трогаем. раз они установились, то всё хорошо. неустановленный соединений с ftpcontrol и ftpdata не бывает в OUTPUT. они подозрительный и их надо зарезать. остальное проверяется по присутствию метки.

Исходный код
$ipt -A OUTPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

$ipt -A OUTPUT -p tcp --sport 21 -j DROP
$ipt -A OUTPUT -p tcp --sport $ftppassive -j DROP
$ipt -A OUTPUT -p tcp --sport 20 -m connmark ! --mark 1 -j DROP
$ipt -A OUTPUT -p tcp --sport $overnet -m connmark ! --mark 1 -j DROP
$ipt -A OUTPUT -p udp --sport $overnetudp -m mark ! --mark 1 -j DROP


маршрутизации у меня на машине нет, поэтому

Исходный код
$ipt -A FORWARD -j DROP


а это разметка пакетов для traffic control. который будет поднят в следующем скрипте.

Исходный код
$iptm -A POSTROUTING -p tcp -m connmark --mark 1 -j CLASSIFY --set-class 1:20
$iptm -A POSTROUTING -p udp -m mark --mark 1 -j CLASSIFY --set-class 1:20



Добавлено в [mergetime]1136717079[/mergetime]:
следующий скрипт.

создаём htb (это один из методов контроля траффика, которые позволяет его делить по скоростям) дисциплину планирования на eth0 ставим её в корень дерева. обзываем 1: (основной номер в названии узла дерева (до, до, детко, куча абстрактных названий) и говорим, что пакеты, для которых не проставлен класс автоматически классфицируются как 10 - дополнительный номер.

добавляем класс 1:1 - это будет корень для маленького поддеревца, в котором будет происходить расщепление канала на несколько. говорим, что он работает на полной теленетовской скорости в 100 мегабит.

ну и всё. теперь для класса 1:10 - это неразмеченные пакеты, указывается, что их следует пропускать на той же скорости в 100 мегабит.

а для размеченных и имеющих имя 1:20 (основное:дополнительное), которое они получили в iptables ограничиваем скорость до 1 мегабайта в секунду.

Исходный код
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1mbps


Добавлено в [mergetime]1136717122[/mergetime]:
если я где-то наглючил или что-то не понятно, спрашивайте. написал это в основном, чтобы самому получше разобраться с этим всем.

Добавлено в [mergetime]1136717210[/mergetime]:
ах да. два скриптика для сброса настроек этих всех.

Исходный код
tc qdisc del dev eth0 root


Исходный код
ipt="iptables"
iptm="iptables -t mangle"

$ipt    -F
$iptm   -F

$iptm -X IFTP
$iptm -X OFTP
$iptm -X IOVERNET
$iptm -X OOVERNET
$iptm -X IOVERNETUDP
$iptm -X OOVERNETUDP
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
wintermute
сообщение 24.7.2006, 12:44
Сообщение #32





Группа: Пользователи
Регистрация: 4.3.2006
Пользователь №: 9 799



хм. ничего не понимаю. почему-то перестала работать комманда

Исходный код
       iptables -t mangle -A ISSH -s $i -m mark --mark 1 -j CONNMARK --save-mark


после обновления iptables. ошибку выдаёт такую:

iptables: Unknown error 4294967295

в чём проблема ermm.gif

Добавлено в [mergetime]1153726749[/mergetime]:
а ну да. в $i - просто некий ip'шник.

Добавлено в [mergetime]1153727085[/mergetime]:
при этом, похоже, ругается он на -j CONNMARK --save-mark. вот. больше ничего сказать не могу.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
wintermute
сообщение 24.7.2006, 13:03
Сообщение #33





Группа: Пользователи
Регистрация: 4.3.2006
Пользователь №: 9 799



бррРРр. iptables оказался глючным. но gentoo его уже починили.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
slc
сообщение 24.7.2006, 13:06
Сообщение #34





Группа: Пользователи
Регистрация: 21.4.2005
Пользователь №: 4 141



Цитата(wintermute @ 24.7.2006, 14:03)
бррРРр. iptables оказался глючным. но gentoo его уже починили.
*


гы , жесть ..
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
Plazmid
сообщение 30.7.2006, 09:20
Сообщение #35





Группа: Пользователи
Регистрация: 2.1.2004
Из: Уралмаш
Пользователь №: 1 413



Цитата(keyboarder @ 8.1.2006, 15:46)
создаём htb (это один из методов контроля траффика, которые позволяет его делить по скоростям)

ммм, как работает? с iptables ясно, а это что за фича такая? в ядре встроена и отрабатывает после правил iptables или что?

p.s. скорость прокачки у меня контроллируется ftp-сервером.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
eiix
сообщение 30.7.2006, 15:14
Сообщение #36





Группа: Пользователи
Регистрация: 16.7.2006
Пользователь №: 13 565



Цитата(Plazmid @ 30.7.2006, 10:20)
ммм, как работает? с iptables ясно, а это что за фича такая? в ядре встроена и отрабатывает после правил iptables или что?

p.s. скорость прокачки у меня контроллируется ftp-сервером.
*



в ip route 2 есть такая штука - tc. работает очень просто - вешается на интерфейс и в соответствии с настройками управляет передачей пакетов. в принципе, может работать без iptables. работает именно с очередями приёма и передачи сетевого интерфейса. то есть, до (приём) или после (отправление) iptables.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
Plazmid
сообщение 31.7.2006, 09:25
Сообщение #37





Группа: Пользователи
Регистрация: 2.1.2004
Из: Уралмаш
Пользователь №: 1 413



надо бы сесть, почитать за iproute2, не думал, что она может ограничивать скорость потока.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
USSRchisUSSR
сообщение 8.11.2009, 09:48
Сообщение #38





Группа: Пользователи
Регистрация: 12.11.2004
Из: от туда
Пользователь №: 3 127



patch-o-matic кто-нить ставил? страдаю уже неделю.

скачиваю последнюю версию ядра, iptables, патча, он говорится что патчит, но при установке всего счастья на место нет того чего мне надо.

затеял это из-за nth

в новой версии не оказалось nth, пришлось брать старую, старая становится только на 1.4.0 iptables и не фтыкается на родное ядро
попробовал на старое 2.4.18, патч установился, но не собирается ядро smile.gif

это пипец какой-то....

доканал я его всёже.

Сообщение отредактировал USSRchisUSSR - 11.11.2009, 15:44
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
coolman
сообщение 30.7.2010, 15:34
Сообщение #39





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



:crying:123

Сообщение отредактировал coolman - 31.7.2010, 12:02
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
coolman
сообщение 6.11.2010, 17:57
Сообщение #40





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



давайте обсудим проблему ддоса, почему нету правил не для новичков? ACCEPT DROP и все дальше ну ни как, а как же hashlimit recent и так далее?
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения

2 страниц V  < 1 2
Ответить в эту темуОткрыть новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



- Текстовая версия Сейчас: 21.7.2018, 22:44
Блог КАБiNET