iptables. теория. (Смотрю в книгу - вижу фигу.)

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

Модераторы: SLEDopit, Модераторы разделов

Abigor
Сообщения: 100

iptables. теория.

Сообщение Abigor »

В описании таблицы nat, сказано, что
Через эту таблицу проходит только первый пакет из потока. Преобразования адресов автоматически применяется ко всем последующим пакетам.

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

Из табличек ниже, узнаем более детальную информацию, что входящий пакет сначала попадает на цепочку PREROUTING таблицы mangle, затем в цепочку PREROUTING таблицы nat. Идем в википедию, внимательно разглядываем эту картинку. И там тоже видно, что пакет в любом случае попадает в таблицу nat.

Видимо я что-то не так понял, но что именно?
Спасибо сказали:
Аватара пользователя
sash-kan
Администратор
Сообщения: 13939
Статус: oel ngati kameie
ОС: GNU

Re: iptables. теория.

Сообщение sash-kan »

подразумевается, видимо, то, что nat тесно взаимодействует и вообще основан на технике connection tracking (отслеживание соединений).
насколько я понимаю, при поступлении пакета, если он совпадает с какой-то из строчек в каком-либо из списков conntrack (вообще, не список, а таблица, но лучше так, чтобы не смешивать с таблицами netfilter-а типа той же nat), то к нему сразу же применяется сохранённое там же преобразование адреса.
так что фигурально можно сказать, что последующие пакеты «минуют» nat.
если же совпадения не произошло, но пакет (по своим характеристикам) должен отслеживаться conntrack-ом, то создаётся запись в соответствующем списке conntrack-а, пакет «обрабатывается» правилами из таблицы nat (проходя через разные nat-овые цепочки), а затем вычисленное преобразование адреса добавляется к той самой вновь созданной conntrack-овой строчке.

надеюсь, я верно изложил взаимодействие между списками conntrack-а и правилами, прописанными в цепочках nat, не сильно погрешив против истины.
Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог
Спасибо сказали:
Abigor
Сообщения: 100

Re: iptables. теория.

Сообщение Abigor »

Еще вот это не совсем ясно. Состояния в пространстве пользователя
Признак NEW сообщает о том, что пакет является первым для данного соединения. Это означает, что это первый пакет в данном соединении, который увидел модуль трассировщика. Например если получен SYN пакет являющийся первым пакетом для данного соединения, то он получит статус NEW. Однако, пакет может и не быть SYN пакетом и тем не менее получить статус NEW. Это может породить определенные проблемы в отдельных случаях, но может оказаться и весьма полезным, например когда желательно "подхватить" соединения, "потерянные" другими брандмауэрами или в случаях, когда таймаут соединения уже истек, но само соединение не было закрыто.

Вот когда пришедший пакет является SYN и открывает соединение, тут понятно, что оно (соединение же?) получает статус NEW. А вот когда пакет не являясь SYN получает статус NEW не совсем понятно, а вернее совсем не понятно. Может пример какой есть, чтобы визуально в голове представилась картинка? А то не укладывается :)

...и в догонку, пока перечитывал мануал, совсем запутался
Когда локальный процесс на брандмауэре отправляет первый пакет из потока, то в цепочке OUTPUT ему присваивается состояние NEW, а когда возвращается пакет ответа, то состояние соединения в цепочке PREROUTING изменяется на ESTABLISHED, и так далее. Если же соединение устанавливается извне, то состояние NEW присваивается первому пакету из потока в цепочке PREROUTING. Таким образом, определение состояния пакетов производится в пределах цепочек PREROUTING и OUTPUT таблицы nat.

так чему же присваивается состояние: пакету или потоку/соединению, которому этот пакет принадлежит?

ппц. я тупой)
Спасибо сказали:
Аватара пользователя
sash-kan
Администратор
Сообщения: 13939
Статус: oel ngati kameie
ОС: GNU

Re: iptables. теория.

Сообщение sash-kan »

Abigor писал(а):
25.05.2011 15:24
А вот когда пакет не являясь SYN получает статус NEW не совсем понятно, а вернее совсем не понятно. Может пример какой есть, чтобы визуально в голове представилась картинка?
чтоб далеко не ходить — возьмите любой (не tcp) протокол транспортного уровня.
это ведь только в заголовках tcp-пакетов есть бит syn (если я правильно ошибаюсь).
конкретно — udp. весьма распространённый протокол. бита syn в заголовке не предусмотрено.
ну и вообще conntrack всякой всячиной научили заниматься, далеко не только tcp:

Код: Выделить всё

$ /sbin/modprobe -l | grep conntrack
kernel/net/netfilter/nf_conntrack.ko
kernel/net/netfilter/nf_conntrack_proto_dccp.ko
kernel/net/netfilter/nf_conntrack_proto_gre.ko
kernel/net/netfilter/nf_conntrack_proto_sctp.ko
kernel/net/netfilter/nf_conntrack_proto_udplite.ko
kernel/net/netfilter/nf_conntrack_netlink.ko
kernel/net/netfilter/nf_conntrack_amanda.ko
kernel/net/netfilter/nf_conntrack_ftp.ko
kernel/net/netfilter/nf_conntrack_h323.ko
kernel/net/netfilter/nf_conntrack_irc.ko
kernel/net/netfilter/nf_conntrack_netbios_ns.ko
kernel/net/netfilter/nf_conntrack_pptp.ko
kernel/net/netfilter/nf_conntrack_sane.ko
kernel/net/netfilter/nf_conntrack_sip.ko
kernel/net/netfilter/nf_conntrack_tftp.ko
kernel/net/netfilter/xt_conntrack.ko
kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko
kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko


Abigor писал(а):
25.05.2011 15:24
так чему же присваивается состояние: пакету или потоку/соединению, которому этот пакет принадлежит?
для таблиц netfilter-а существуют только пакеты. поэтому с точки зрения правил netfilter-а «состояние» есть именно у пакета.
а вот надстройка conntrack манипулирует соединениями. она-то и видит состояние соединения и, исходя из него, присваивает пакету (в прилагающихся к пакету внутренних netfilter-овских структурах данных) тот или иной (внутренний) признак.
так что верны оба утверждения: «пакет имеет такой-то признак» и «соединение имеет такой-то признак». ведь пакет, попав в лапы conntrack-а, мгновенно становится частью соединения (существующей или свежесозданной строчки в списках conntrack-а).

p.s. добавлю ещё немного головной боли. вообще все эти conntrack-овские соединения и состояния — это всего лишь внутренний netfilter/conntrack-овский суржик. мимо них пробегают какие-то там пакеты, вот они об этих пакетах и судачат.
к реальным протоколам (tcp, udp и т.д. и т.п.) это имеет мало отношения. ими занимаются сокеты.
Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог
Спасибо сказали:
Abigor
Сообщения: 100

Re: iptables. теория.

Сообщение Abigor »

теория оно конечно хорошо, но уж больно не терпелось перейти к практической реализации полученных знаний. ну и нифига не получается \=

Код: Выделить всё

#!/bin/sh
### BEGIN INIT INFO
# Provides:          iptables
# Required-Start:    $syslog $network $time
# Required-Stop:     $syslog $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 6
# Short-Description: Start firewall at boot time
# Description:       Enable service provided by iptables.
### END INIT INFO

#IPTables Configuration.
ipfw='/sbin/iptables'

#Local Area Network configuration
#lan0_ip='192.168.1.24'
#lan0_ip_range='192.168.1.0/24'
lan_broadcast='192.168.1.255'
#if0='eth0'
lan1_ip='192.168.1.25'
lan1_ip_range='192.168.1.0/24'
if1='eth1'

#Localhost Configuration
lo='lo'
lo_ip='127.0.0.1'

start_fw()
{
        $ipfw -F
        $ipfw -X

###########################################################################
#
# 4. rules set up.
#

######
# 4.1 Filter table
#

#
# 4.1.1 Set policies
#

        $ipfw -P INPUT DROP
        $ipfw -P OUTPUT DROP
        $ipfw -P FORWARD DROP

#
# 4.1.2 Create userspecified chains
#

#
# Create chain for bad tcp packets
#
        $ipfw -N bad_tcp_packets

#
# Create separate chains for ICMP, TCP and UDP to traverse
#
        $ipfw -N allowed
        $ipfw -N tcp_packets
        $ipfw -N udp_packets
        $ipfw -N icmp_packets

#
# 4.1.3 Create content in userspecified chains
#

#
# bad_tcp_packets chain
#
        $ipfw -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
        $ipfw -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
        $ipfw -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

#
# allowed chain
#
        $ipfw -A allowed -p TCP --syn -j ACCEPT
        $ipfw -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
        $ipfw -A allowed -p TCP -j DROP

#
# TCP rules
#
        $ipfw -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed

#
# UDP ports
#
        $ipfw -A udp_packets -p UDP -s 0/0 --dport 53 -j ACCEPT
        $ipfw -A udp_packets -p UDP -s 0/0 --dport 123 -j ACCEPT
        #$ipfw -A udp_packets -p UDP -i $if1 --dport 67:68 -j ACCEPT

#
# ICMP rules
#
        $ipfw -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
        $ipfw -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 4.1.4 INPUT chain
#

#
# Bad TCP packets we don't want.
#

        $ipfw -A INPUT -p tcp -j bad_tcp_packets

#
# Rules for networks
#
        $ipfw -A INPUT -p ALL -i $if1 -s $lan1_ip_range -j ACCEPT
        $ipfw -A INPUT -p ALL -i $lo -s $lo_ip -j ACCEPT
        $ipfw -A INPUT -p ALL -i $lo -s $lan1_ip -j ACCEPT

#
# Rules for incoming packets from the lan.
#
        $ipfw -A INPUT -p ALL -d $lan1_ip -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
        $ipfw -A INPUT -p TCP -i $if1 -j tcp_packets
        $ipfw -A INPUT -p UDP -i $if1 -j udp_packets
        $ipfw -A INPUT -p ICMP -i $if1 -j icmp_packets


# 4.1.6 OUTPUT chain

       $ipfw -A OUTPUT -p tcp -j bad_tcp_packets

        $ipfw -A OUTPUT -p ALL -i $lo -j ACCEPT
        $ipfw -A OUTPUT -p ALL -i $if1 -j ACCEPT

}

case "$1" in
start)  echo -n "Starting firewall: iptables"
        start_fw
        echo "."
        ;;
stop)   echo -n "Stopping firewall: iptables"
        $ipfw -F
        $ipfw -X
        $ipfw -P INPUT ACCEPT
        $ipfw -P OUTPUT ACCEPT
        $ipfw -P FORWARD ACCEPT
        echo "."
        ;;
save)   echo -n "Saving firewall: iptables"
        iptables-save > /etc/rules-save
        echo "."
        ;;
restart) echo -n "Restarting firewall: iptables"
        $ipfw -F
        $ipfw -X
        cat /etc/rules-save | iptables-restore
        echo "."
        ;;
reload|force-reload) echo -n "Reloading configuration files for firewall: iptables"
        echo "."
        ;;
*)      echo "Usage: /etc/init.d/rc.firewall start|stop|restart|reload|force-reload"
        exit 1
        ;;
esac
exit 0

после запуска достучаться на 22 порт машины не представляется возможным. пинг ни на машину, ни с самой машины не ходят. В принципе нового я ничего не придумал, как я понимаю работу этого фаервола: пакет из сети 192.168.1.0/24 пришел на порт 22 сервера sshd (который на машине с фаерволом). Он попадает в цепочку INPUT в которой мы первым правилом отправляем его в цепочку bad_tcp_packets. Бит SYN у нас установлен, состояние NEW присутствует, но нет бита ACK, поэтому в цепочке bad_tcp_packets ни под одно правило наш пакет не попадает и возвращается в цепочку INPUT на следующее правило. А там у нас $ipfw -A INPUT -p ALL -i $if1 -s $lan1_ip_range -j ACCEPT. Проктокол подходит, интерфейс подходит, источник подходит. т.е. все критерии совпали. Пакет принят. ДАлее он попал к сервису sshd, та произошла черная магия и сервер sshd отправляет ответный пакет с битами SYN/ACK. Попадаем в цепочку OUTPUT. Там переадресуется на цепочку bad_tcp_packets, где не попав ни под один критерий, т.к. состояние уже меняется на ESTABLISHED, через правило $ipfw -A OUTPUT -p ALL -i $if1 -j ACCEPT улетает к "клиенту". Однако не работает!

Код: Выделить всё

#iptables -L -Z -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   144 bad_tcp_packets  tcp  --  any    any     anywhere             anywhere
    6  1194 ACCEPT     all  --  eth1   any     localnet/24          anywhere
    0     0 ACCEPT     all  --  lo     any     localhost            anywhere
    0     0 ACCEPT     all  --  lo     any     debian.vlgsi         anywhere
    0     0 ACCEPT     all  --  any    any     anywhere             debian.vlgsi        state NEW,RELATED,ESTABLISHED
    0     0 tcp_packets  tcp  --  eth1   any     anywhere             anywhere
    0     0 udp_packets  udp  --  eth1   any     anywhere             anywhere
    0     0 icmp_packets  icmp --  eth1   any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 16 packets, 6372 bytes)
 pkts bytes target     prot opt in     out     source               destination
   16  6372 bad_tcp_packets  tcp  --  any    any     anywhere             anywhere

Chain allowed (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
    0     0 DROP       tcp  --  any    any     anywhere             anywhere

Chain bad_tcp_packets (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  any    any     anywhere             anywhere            tcp flags:SYN,ACK/SYN,ACK state NEW reject-with tcp-reset
    0     0 LOG        tcp  --  any    any     anywhere             anywhere            tcp flags:!FIN,SYN,RST,ACK/SYN state NEW LOG level warning prefix `New not syn:'
    0     0 DROP       tcp  --  any    any     anywhere             anywhere            tcp flags:!FIN,SYN,RST,ACK/SYN state NEW

Chain icmp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp echo-request
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp time-exceeded

Chain tcp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 allowed    tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh

Chain udp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:domain
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:ntp
Zeroing chain `INPUT'
Zeroing chain `FORWARD'
Zeroing chain `OUTPUT'
Zeroing chain `allowed'
Zeroing chain `bad_tcp_packets'
Zeroing chain `icmp_packets'
Zeroing chain `tcp_packets'
Zeroing chain `udp_packets'


что не так? :unsure:
Спасибо сказали:
Аватара пользователя
sash-kan
Администратор
Сообщения: 13939
Статус: oel ngati kameie
ОС: GNU

Re: iptables. теория.

Сообщение sash-kan »

неверные правила:
Abigor писал(а):
26.05.2011 11:57
$ipfw -A OUTPUT -p ALL -i $lo -j ACCEPT
$ipfw -A OUTPUT -p ALL -i $if1 -j ACCEPT
цитата из man iptables:
QUOTE писал(а):[!] -i, --in-interface name
Name of an interface via which a packet was received (only for packets entering the INPUT, FORWARD and PREROUTING chains).


соответственно, эти правила отсутствуют:

Код: Выделить всё

Chain OUTPUT (policy DROP 16 packets, 6372 bytes)
pkts bytes target     prot opt in     out     source               destination
   16  6372 bad_tcp_packets  tcp  --  any    any     anywhere             anywhere
а так как политика — drop, то пакеты «становятся героями посмертно».
Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог
Спасибо сказали:
Abigor
Сообщения: 100

Re: iptables. теория.

Сообщение Abigor »

Дайте кто-нибудь заданий, чтобы потренироваться в написании правил. Ибо для домашнего десктопа особо не разгуляешься, а какой-то интересной ситуации, наиболее приближенной к реальности, придумать сам не могу. ):
Спасибо сказали:
Аватара пользователя
Skyb
Сообщения: 967
ОС: RFremix 18

Re: iptables. теория.

Сообщение Skyb »

Abigor писал(а):
30.05.2011 12:40
Дайте кто-нибудь заданий, чтобы потренироваться в написании правил. Ибо для домашнего десктопа особо не разгуляешься, а какой-то интересной ситуации, наиболее приближенной к реальности, придумать сам не могу. ):

У меня на домашнем есть локальная сеть + wifi + несколько виртуальных сетей (это я к тому что можно сделать на домашнем) и ими развести весь интеренет и настроить шейпер. Вот задачка ;) можете себе такую же сделать.
C:\windows> ifconfig
"ifconfig" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Спасибо сказали: