Назад | Перейти на главную страницу

Команда iptables -F закрывает мне доступ к SSH?

Я создаю некоторые правила брандмауэра для VPS с помощью iptables. Мой сценарий оболочки выглядит примерно так:

#!/bin/sh
# My system IP/set ip address of server
SERVER_IP="1.2.3.4"

# Flushing all existing rules
iptables -F
iptables -X

# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Allow SSH on 22
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

# Default policy DROP
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

Если я запустил iptables -F после запуска этого сценария я не могу подключиться к SSH (я могу вернуться, но я никогда не хочу, чтобы SSH отключился).

У меня три вопроса.

  1. Я заблокирован политиками фильтров по умолчанию, которые не удаляются при запуске iptables -F команда?
  2. Я не заблокируюсь, если я это сделаю iptables -FX?
  3. Нужны ли политики фильтрации по умолчанию, если я все равно добавляю политику отбрасывания по умолчанию в конце сценария оболочки?

Ура!

Конечно, вас заблокируют - вы устанавливаете политику запрета по умолчанию, а затем сбрасываете все правила, которые позволяют вам войти.

  1. Да.
  2. Нет потому что -X имеет такое же отношение к сетевой политике, как и -F (то есть ничего).
  3. Да, потому что правила могут быть удалены, очищены, перевернуты и искажены. Сетевые политики не могут.

Вы должны только обнаружить, что ssh временно заблокирован, потому что вы разрешили "ESTABLISHED" в правилах. Однако временная потеря пакетов нарушит работу ssh, и для восстановления tcp потребуется 10 секунд или более.

Лично я всегда помещаю общее правило «iptables -A INPUT -m state --state installed, related» вверху сразу после команды flush, чтобы блокировка была очень короткой!

вы ведь не используете conntrack для сброса состояний?

p.s. если вы управляете соединениями из относительно надежной локальной сети, то использование правила REJECT в конце может быть более полезным, поскольку новые попытки соединения, которые терпят неудачу, немедленно отклоняются, а не требуют тайм-аута.