SSH туннель подправить iptables

1 0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Попадает ли под это правило UDP трафик? Видимо зависит от загруженных модулей conntrack*.

1 0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Попадает ли под это правило UDP трафик? Видимо зависит от загруженных модулей conntrack*.

Как мне кажется UDP под all должен попадать но как проверить я не в курсе. Подгружается ли conntrack модуль или нет я точно сказать не могу но похоже нет.

Когда модуль “conntracks” отключен, таблица NAT отсутствует в iptables:
 
# cat /proc/net/ip_tables_names
mangle
filter

Добавление в /etc/sysconfig/iptables-config строки

IPTABLES_MODULES="ip_conntrack"

# echo "modprobe ip_conntrack" >> /etc/sysconfig/modules/iptables.modules
# chmod +x /etc/sysconfig/modules/iptables.modules

Это первая линукс машина с которой я имею дело, не пинайте больно.

Добавлю что это OpenVZ VPS CentOS 6.5

UDP под all должен попадать

Под all попадет конечно, но попадает ли под RELATED,ESTABLISHED — вот вопрос, udp stateless протокол.

Если загружены conntrack модули (см. /sbin/lsmod), то может и отслеживается udp тоже.

Если загружены conntrack модули (см. /sbin/lsmod)

lsmod возвращает ничего

# lsmod
Module                  Size  Used by

lsmod возвращает ничего

В русском языке двое отрицание можно/нужно использовать.
Такого не может (не должно) быть на стандартном CentOS'овском ядре.

ls /lib/modules/`uname -r`/kernel/net/netfilter/*conntrack*

ls /lib/modules/`uname -r`/kernel/net/netfilter/*conntrack*

# ls /lib/modules/`uname -r`# ls /lib/modules/`uname -r`/kernel/net/netfilter/*conntrack*
ls: cannot access /lib/modules/2.6.32-042stab085.20/kernel/net/netfilter/*conntrack*: No such file or directory

Я не вижу папки /kernel в /lib/modules/2.6.32-042stab085.20

Насчет стандартности ядра я не могу ничего сказать, это VPS который я рентую.

это VPS

Кастомное ядро, VPS — oбратись в тех.поддержку.

# ls /proc/sys/net/netfilter/*conntrack*
/proc/sys/net/netfilter/nf_conntrack_acct                  /proc/sys/net/netfilter/nf_conntrack_icmpv6_timeout           /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_fin_wait
/proc/sys/net/netfilter/nf_conntrack_buckets               /proc/sys/net/netfilter/nf_conntrack_log_invalid              /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_last_ack
/proc/sys/net/netfilter/nf_conntrack_checksum              /proc/sys/net/netfilter/nf_conntrack_max                      /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_max_retrans
/proc/sys/net/netfilter/nf_conntrack_count                 /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal           /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_recv
/proc/sys/net/netfilter/nf_conntrack_events                /proc/sys/net/netfilter/nf_conntrack_tcp_loose                /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_sent
/proc/sys/net/netfilter/nf_conntrack_events_retry_timeout  /proc/sys/net/netfilter/nf_conntrack_tcp_max_retrans          /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
/proc/sys/net/netfilter/nf_conntrack_expect_max            /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close        /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_unacknowledged
/proc/sys/net/netfilter/nf_conntrack_generic_timeout       /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait   /proc/sys/net/netfilter/nf_conntrack_udp_timeout
/proc/sys/net/netfilter/nf_conntrack_icmp_timeout          /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established  /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream

Может это оно?

Кастомное ядро, VPS — oбратись в тех.поддержку.

Боюсь с iptables тех.поддержка от хостера мне не светит... Проще хостера сменить. Спасибо большое за помощь.

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

Не закрывай udp для начала, иначе резолвинг (dns) не будет работать, затем смотри как закрывать остальное (просто по портам или при помощи RELATED,ESTABLISHED)

Проблемы с DNS резолвинг это первое что мне казалось может быть причиной но открыть сайт по IP также не получается.

conntrack не подгружается но я так понимаю для его использования надо было добавлять строку так:

# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

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

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

Если уж ты разрешил icmp, и там нет слушающих во внешку сервисов, то зачем же все закрывать? Если там есть такие сервисы, то предпочтительно их правильно настроить, чем использовать для закрытия фаерволл.

Если уж ты разрешил icmp, и там нет слушающих во внешку сервисов, то зачем же все закрывать?

icmp был открыт временно.

Можно и сервисы настроить и фаерволом все закрыть. Чем плох такой подход?

VPS хостера я сменил и все функционирует как надо. В кастомизации кернела похоже загвоздка была.

Можно и сервисы настроить и фаерволом все закрыть. Чем плох такой подход?

А зачем тогда закрывать? Уязвимы приложения, а не сетевая подсистема ядра.

А зачем тогда закрывать? Уязвимы приложения, а не сетевая подсистема ядра.

Вы вопрос задаете для того чтобы почерпнуть что-то полезное из моих ответов или намекнуть на то что мой подход кривой? Если первое то это мой первый опыт в этом деле и он никакой а если второе то напишите конкретно чем подход «закрыть все и открывать нужное» не хорош.

Вы вопрос задаете для того чтобы почерпнуть что-то полезное из моих ответов или намекнуть на то что мой подход кривой?

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

чем подход «закрыть все и открывать нужное» не хорош

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

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

Фаервол стоит так как противостоять бруту открытого порта без него неудобно. Все и началось с того что хостер VPS мой положил из-за брута.

[qoute]Фаервол стоит так как противостоять бруту открытого порта без него неудобно. Да, тогда средствами приложения справиться будет затруднительно (если вообще возможно).

Если брутят ssh, то могу посоветовать fail2ban. Оно читает логи на предмет неудавшихся попыток аутентификации и автоматически банит на определенный период времени средствами фаерволла. По дефолту 10 минут, но можно настроить и побольше.

Альтернативно, можно поменять номер порта, на котором слущает ssh. Делается это добавлением/заменой в /etc/ssh/sshd_config строчки

Port N

, где N - нужное число.

Если брутят ssh, то могу посоветовать fail2ban.

Порт я сменил и добавил такие правила:

iptables -A INPUT -p tcp --dport 3322 -m recent --name ssh --update --seconds 900 --hitcount 5 -j DROP
iptables -A INPUT -p tcp --dport 3322 -m recent --name ssh --set
iptables -A INPUT -p tcp --dport 3322 -m recent --name ssh ! --rcheck --seconds 15 --hitcount 2 -j DROP
iptables -A INPUT -p tcp --dport 3322 -j ACCEPT