так очень трудно сделать, нужно читать доки с обьяснениями какие команды за что отвечают.
В первую очередь нужно искать документацию по своему дистрибутиву, восновном она лежит на
gentoo.org/doc/
gentoo-wiki.com
ru.gentoo-wiki.com
то что тебе нужно лежит тут, так-же есть русская версия - но она немного устарела и лучше смотреть на английскую и что непонятно подсматривать на русской.
использование такого метода - дыра в маршрутизаторе, все равно считаю лучше ставить еденицу только тогд акогда она там действительно нужна. в процедуре останова фаера я указываю 0 >> , ибо на практике знаю что правила сбрасываются, а пересылка пакетов остается, и считаю это излишнем в плане безопасности, во как завернул :-)
а что это за "процедура останова фаера"?
/etc/init.d/iptables stop кто-то уже отменил?
а если ты воспользуешся этой командой - то правил разрешающих пересылку небудет, как и самой пересылки.
да и зачем его отключать?
Тогда логируйте DROPED/REJECTED пакеты, запускайте DC++ на поиск, и смотрите, что там куда не пускает
У меня политика DROP, а правила только разрешающие, т.е. поиск dc++ попадает под политику. Пробую логировать все пакеты (они есть, список внушительный), но в логах не пишется какое действие было предпринято по отношению к данному пакету.
Как логировать пакеты, которые дропаются политикой, а не правилами?
Добавлено:
В конец всех правил добавить?
iptables -A INPUT -j LOG --log-ip-options --log-tcp-options --log-prefix "INPUT DROP policy packets "
iptables -A OUTPUT -j LOG --log-ip-options --log-tcp-options --log-prefix "OUTPUT DROP policy packets "
Нет. В начало. Цепочки просматриваются по порядку и сравнение останавливается при первом совпадении, если там управляющее правило (accept,drop,forward etc)! Это очень важный нюанс. Внимательно читайте документацию.
Я делал так (в самом начале):
$IPT -N DROPl
$IPT -A DROPl -j LOG --log-prefix 'firewall drop: '
$IPT -A DROPl -j DROP
$IPT -P INPUT DROPl
Или можно после всех правил:
$IPT -A INPUT -j DROPl
$IPT -A OUTPUT -j DROPl
$IPT -A FORWARD -j DROPl
Да, да я это понимаю.
Я думал так, правила у меня пропускающие, следовательно то, что дропается проходит через них (не соответствует ни одно му из них) и встречает правило LOG (далее сбрасывается - применяется политика).
Пробую твой пример ($IPT заменено iptables):
$IPT -N DROPl
$IPT -A DROPl -j LOG --log-prefix 'firewall drop: '
$IPT -A DROPl -j DROP
$IPT -P INPUT DROPl
пишет
iptables: Bad policy name
А вот втрой пример сработал.
$IPT -A INPUT -j DROPl
$IPT -A OUTPUT -j DROPl
$IPT -A FORWARD -j DROPl
Если что, есть команда такая - sysctl. Используй в скрипте в любом месте. Синтаксис - как в файле /etc/sysctl.conf.
_______________________
From Siberia with Love!
Конфиг еще очень сырой, но сейчас нет времени дописывать (((
Вопрос собственно в следующем:
Считается ли ответный ACK пакет при установке TCP соединения, как ESTABLISHED, или нет?
судя по картинке
(взято с opennet.ru) ответный ACK должен рассматриваться как ESTABLISHED, но перед картинкой написано:
Цитата:
TCP соединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи SYN пакета, в ответ на который передается SYN/ACK пакет и подтверждает установление соединения пакет ACK. После этого соединение считается установленным и готовым к передаче данных.
TCP/IP является протоколом, в котором соединение устанавливается в 3 фазы. Если компьютер А пытается установить соединение с компьютером Б они обмениваются специальными TCP пакетами.
A: SYN пакет (првыед Б!)
Б: ACK пакет, SYN пакет (Ога!, как оно?)
A: ACK пакет (дык, ничего)
После чего соединение считается установленным (ESTABLISHED).
Проблема в том, что в лог падают входящие соединения к mldonkey
Много букв конечно, но: $FILTER_INPUT_TCP_NEW -m multiport --destination-port $FILTER_INPUT_TCP_DPORTS --tcp-flags ALL SYN -j RETURN, т.е. пакеты только с единственным SYN пропускаются. Второй шаг и пакет с ACK отбрасывается. Почему не каждое соединение затрудняюсь сказать, непонятно даже про какой протокол речь идет - осел? Мало ли, может оно частично по UDP работает ;P
Хотя нет. Сейчас проверил ACK пакеты на стадии согласования уже в состоянии ESTABLISHED. Да и как написано в описании iptables в состоянии NEW находятся пакеты, которые не связанны с соединенем в обе стороны. Как я понимаю при входящем TCP ответный SYN ACK пакет от тоже уже будет в состоянии ESTABLISHED, т.к. часто в примерах скриптов встречается такая конструкция для защиты от SYN флуда: $IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
Хотя нет. Сейчас проверил ACK пакеты на стадии согласования уже в состоянии ESTABLISHED. Да и как написано в описании iptables в состоянии NEW находятся пакеты, которые не связанны с соединенем в обе стороны. Как я понимаю при входящем TCP ответный SYN ACK пакет от тоже уже будет в состоянии ESTABLISHED, т.к. часто в примерах скриптов встречается такая конструкция для защиты от SYN флуда: $IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
Да вот в том и проблема, что исходящие (ответные) SYN/ACK файрвол нормально пропускает, в логах я их не вижу.
А вот попадающие под правило -m state --state=NEW пакеты с установленным ACK (единственным) правилом - для меня загадка.
И если посмотреть на правило защиты от SYN флуда, которое ты привел, опять таки подтверждается мысль, что iptables этот входящий (ответный) ACK считает как NEW, ведь это правлило отбрасывает те пакеты, в которых установлены оба флага и SYN и ACK, помеченные как NEW
Т.е. получается, что это нормально (то, что ответный ACK - это NEW) и мне стоит точно так же отбрасывать пакеты с SYN и ACK и не заморачиваться???? Ну не зря же для проверки NEW очень часто стоит процитированное правило!
p.s.
Протокол TCP
Да, на самом деле в mldonkey часть соединений идет через UDP, но для iptables это же совершенно разные соединения )))
А зачем эта заморочка на домашнем компе - проще комп за роутером поставить
Наоборот, ни каких заморочек настроил и оно рабоатет. А роутер мало того что скорость урезает, да и ещё для другого дела предназначен и для одной машины он совершенно ни к чему. Если действительно нужен роутер то тогда лучше взять какой нибудь старый залежалый компьютер, и зделать его роутером. И мы ведь не ищем лёгких путей.
#!/bin/bash
а зачем?
а зачем?
Просто
Просто я хотел посмотреть у кого какие рабочие скрипты под iptables. Может себе взял за основу. А то у меня с нуля не получается настроить.
так очень
так очень трудно сделать, нужно читать доки с обьяснениями какие команды за что отвечают.
В первую очередь нужно искать документацию по своему дистрибутиву, восновном она лежит на
gentoo.org/doc/
gentoo-wiki.com
ru.gentoo-wiki.com
то что тебе нужно лежит тут, так-же есть русская версия - но она немного устарела и лучше смотреть на английскую и что непонятно подсматривать на русской.
Мой конфиг,
Мой конфиг, создан на основе статей в вики:
/ Enchant /
"Никакую проблему нельзя решить на том же уровне, на котором она возникла"
а вот вместо echo
а вот вместо echo 1 >> нужно использовать /etc/sysctl.conf
имхо
использование такого метода - дыра в маршрутизаторе, все равно считаю лучше ставить еденицу только тогд акогда она там действительно нужна. в процедуре останова фаера я указываю 0 >> , ибо на практике знаю что правила сбрасываются, а пересылка пакетов остается, и считаю это излишнем в плане безопасности, во как завернул :-)
there is only war...
а что это за
а что это за "процедура останова фаера"?
/etc/init.d/iptables stop кто-то уже отменил?
а если ты воспользуешся этой командой - то правил разрешающих пересылку небудет, как и самой пересылки.
да и зачем его отключать?
процедурка
дык так и делаю инит-скрипте есть такая, у меня так выглядит
stop() {
ebegin "Stopping firewall"
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F
$IPTABLES -X
$IPTABLES -P INPUT $POLICY
$IPTABLES -P FORWARD $POLICY
$IPTABLES -P OUTPUT $POLICY
echo "0" > /proc/sys/net/ipv4/ip_forward
eend $?
}
вобще я параноик...
there is only war...
А как прописать
А как прописать правила iptables для dc++?
Прописал
Соединяется нормально и даже скачивает. НО не работает поиск файлов :(
Как он осуществляется? что надо прописать?
Надо
Надо ESTABLISHED,RELATED пакеты разрешить
.
не понял
они разрешены
(раньше стоят правила)
Тогда
Тогда логируйте DROPED/REJECTED пакеты, запускайте DC++ на поиск, и смотрите, что там куда не пускает
.
У меня политика DROP, а правила только разрешающие, т.е. поиск dc++ попадает под политику. Пробую логировать все пакеты (они есть, список внушительный), но в логах не пишется какое действие было предпринято по отношению к данному пакету.
Как логировать пакеты, которые дропаются политикой, а не правилами?
Добавлено:
В конец всех правил добавить?
тока что-то оно
тока что-то оно не логирует ничего, а поиск продолжает не работать
Нет. В начало.
Нет. В начало. Цепочки просматриваются по порядку и сравнение останавливается при первом совпадении, если там управляющее правило (accept,drop,forward etc)! Это очень важный нюанс. Внимательно читайте документацию.
Я делал так (в самом начале):
Или можно после всех правил:
Да, да я это
Да, да я это понимаю.
Я думал так, правила у меня пропускающие, следовательно то, что дропается проходит через них (не соответствует ни одно му из них) и встречает правило LOG (далее сбрасывается - применяется политика).
Пробую твой пример ($IPT заменено iptables):
пишет
А вот втрой пример сработал.
Спасибо.
Вот у меня
Вот у меня с такими правилами всё работает как надо.
/sbin/iptables -A OUTPUT -p tcp --dport :411 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport :9176 -j ACCEPT /sbin/iptables -A INPUT -p udp --dport :9176 -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --sport :9176 -j ACCEPT /sbin/iptables -A OUTPUT -p udp --sport :9176 -j ACCEPT /sbin/iptables -A INPUT -p tcp --sport :19176 -j ACCEPTА вот таких правил нет.
Если что, есть
Если что, есть команда такая - sysctl. Используй в скрипте в любом месте. Синтаксис - как в файле /etc/sysctl.conf.
_______________________
From Siberia with Love!
Не грусти, товарищ! Всё хорошо, beautiful good!
Не совсем:
Не совсем: пробелы нельзя :)
Понимаю, что вопрос может быть не в той ветке, но все же....
Понимаю, что вопрос может быть не в той ветке, но все же....
Вот мой конфиг iptables
Конфиг еще очень сырой, но сейчас нет времени дописывать (((
Вопрос собственно в следующем:
Считается ли ответный ACK пакет при установке TCP соединения, как ESTABLISHED, или нет?
судя по картинке
(взято с opennet.ru) ответный ACK должен рассматриваться как ESTABLISHED, но перед картинкой написано:
Т.е. ответный ACK - это еще NEW
То же самое нашел тут :
Проблема в том, что в лог падают входящие соединения к mldonkey
Например:
Явно видно, что отклоняется в правиле FILTER_INPUT_TCP_NEW (FITN) из-за ACK
Вот такая вот непонятка выходит (((
Либо это действительно удаленный сервер пытается подключиться без начального SYN
Никто не сталкивался?
P.S.
Только что просмотрел логи и нашел запись:
Т.е. с моего компьютер точно так же идут ACK пакеты как NEW. и таких записей не одна/две, но добавляются явно не при каждом новом соединении (((
Много букв конечно, но
Много букв конечно, но:
$FILTER_INPUT_TCP_NEW -m multiport --destination-port $FILTER_INPUT_TCP_DPORTS --tcp-flags ALL SYN -j RETURN, т.е. пакеты только с единственным SYN пропускаются. Второй шаг и пакет с ACK отбрасывается. Почему не каждое соединение затрудняюсь сказать, непонятно даже про какой протокол речь идет - осел? Мало ли, может оно частично по UDP работает ;PХотя нет. Сейчас проверил ACK
Хотя нет. Сейчас проверил ACK пакеты на стадии согласования уже в состоянии ESTABLISHED. Да и как написано в описании iptables в состоянии NEW находятся пакеты, которые не связанны с соединенем в обе стороны. Как я понимаю при входящем TCP ответный SYN ACK пакет от тоже уже будет в состоянии ESTABLISHED, т.к. часто в примерах скриптов встречается такая конструкция для защиты от SYN флуда:
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-resetДа вот в том и проблема....
Да вот в том и проблема, что исходящие (ответные) SYN/ACK файрвол нормально пропускает, в логах я их не вижу.
А вот попадающие под правило -m state --state=NEW пакеты с установленным ACK (единственным) правилом - для меня загадка.
И если посмотреть на правило защиты от SYN флуда, которое ты привел, опять таки подтверждается мысль, что iptables этот входящий (ответный) ACK считает как NEW, ведь это правлило отбрасывает те пакеты, в которых установлены оба флага и SYN и ACK, помеченные как NEW
Т.е. получается, что это нормально (то, что ответный ACK - это NEW) и мне стоит точно так же отбрасывать пакеты с SYN и ACK и не заморачиваться???? Ну не зря же для проверки NEW очень часто стоит процитированное правило!
p.s.
Протокол TCP
Да, на самом деле в mldonkey часть соединений идет через UDP, но для iptables это же совершенно разные соединения )))
А зачем эта заморочка на
А зачем эта заморочка на домашнем компе - проще комп за роутером поставить
Наоборот..
Наоборот, ни каких заморочек настроил и оно рабоатет. А роутер мало того что скорость урезает, да и ещё для другого дела предназначен и для одной машины он совершенно ни к чему. Если действительно нужен роутер то тогда лучше взять какой нибудь старый залежалый компьютер, и зделать его роутером. И мы ведь не ищем лёгких путей.
Ты в терминах хотя бы
Ты в терминах хотя бы разберись для начала, прежде чем такие советы давать.