Какое решение killswitch для iptables лучше?

Question

[hemir]

Привет.

Делаю VPN killswitch на linux ноутбуке и среди рекомендаций нашел два очень похожих набора правил для iptables. Хочу вас спросить, идентичны ли они? Или какой-то из них предпочтительнее для выбора?

Первое решение:

iptables --flush
iptables --delete-chain
iptables -t nat --flush
iptables -t nat --delete-chain
iptables -P OUTPUT DROP
iptables -A INPUT -j ACCEPT -i lo
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A OUTPUT -j ACCEPT -d 169.38.69.24/32 -o wlp6s0 -p udp -m udp --dport 1194
iptables -A INPUT -j ACCEPT -s 169.38.69.24/32 -i wlp6s0 -p udp -m udp --sport 1194
iptables -A INPUT -j ACCEPT -i tun0
iptables -A OUTPUT -j ACCEPT -o tun0

Второе решение:

iptables --flush
iptables --delete-chain
iptables -t nat --flush
iptables -t nat --delete-chain
iptables -P OUTPUT DROP
iptables -A INPUT -j ACCEPT -i lo
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A OUTPUT -j ACCEPT -d 169.38.69.24
iptables -A OUTPUT -j ACCEPT -o tun0

Я не очень "сетевой" парень. Для меня оба решения выглядит почти одинаково. Только не понимаю почему в первом случае мы отдельно разрешаем INPUT на tun0 и на VPN сервер, а во втором случае такого правила нет. В остальном второе решение смотрится лаконичнее.

Answer 1

[hint000]

Нет здесь правил для INPUT с действием DROP, а значит и нет смысла добавлять что-то в INPUT с действием ACCEPT, оно и так по-умолчанию будет. Можно написать и более лаконично:

iptables --flush
iptables --delete-chain
iptables -t nat --flush
iptables -t nat --delete-chain
iptables -P OUTPUT DROP
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A OUTPUT -j ACCEPT -p udp --dport 1194
iptables -A OUTPUT -j ACCEPT -o tun+

Отличие в том, что можно подключаться к любому OpenVPN-серверу, т.к. ограничение задано по номеру порта, но не по адресу сервера. Также запись tun+ позволит работать через любой туннель, если будет создано несколько туннелей (tun0, tun1, tun2,..) - ну мало ли как и что захочется добавить в будущем.

Comments

[hemir]

hint000 Большое спасибо за ответ!

А почему нам нужно оставлять INPUT ACCEPT?

Например, не будет ли безопаснее вообще все закрыть?

iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -P INPUT DROP

Я понимаю, что есть какая-то резонная причина для этого. Хочу узнать какая.

[hint000]

hemir,

А почему нам нужно оставлять INPUT ACCEPT?

Не нужно. Просто не было поставлено задачи закрыть, вот и не закрывали. Если такая задача есть, то да, безопаснее закрыть через
iptables -P INPUT DROP
Но тогда вот и потребуется явно открывать INPUT как в первом варианте. Просто в первом варианте не было -P INPUT DROP, и это было похоже, как будто на входе стоит охранник и проверяет у всех документы; у кого документы в порядке, тех пропускает; у кого не в порядке или вообще нет документов - всё равно пропускает. :)
Что касается FORWARD, это актуально, когда хост является маршрутизатором для других хостов, т.е. пропускает через себя чужой трафик (в том числе трафик виртуальных машин, если такие есть). Если это не так, то не важно, что там в FORWARD.

[hemir]

hint000, спасибо за подробный ответ, вы очень помогли.

Итого, самый безопасный и лаконичный вариант:

iptables --flush
iptables --delete-chain
iptables -t nat --flush
iptables -t nat --delete-chain

iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -P INPUT DROP

iptables -A INPUT -j ACCEPT -i lo
iptables -A OUTPUT -j ACCEPT -o lo

iptables -A OUTPUT -j ACCEPT -d 169.38.69.24 (Если нужен конкретный ip)
iptables -A OUTPUT -j ACCEPT -s 169.38.69.24

iptables -A OUTPUT -j ACCEPT -o tun0+

[hemir]

hint000,

А открытый INPUT ACCEPT плох в плане какого-то внешнего скана портов/брутфорса? Или это может привести к утечке ip адреса/dns?

Обещаю, это последний вопрос!

[hint000]

hemir, надо ещё
iptables -A OUTPUT -j ACCEPT -o tun0+
и вместо
iptables -A OUTPUT -j ACCEPT -s 169.38.69.24
должно быть
iptables -A INPUT -j ACCEPT -s 169.38.69.24

К утечке не приведёт, а скан\брутфорс вполне реален. Но если на хосте нет ни DNS-сервера, ни SSH-сервера, ни почтового, ни Samba, ни FTP, ни Web, ни чего-то ещё, способного отвечать на внешние запросы, то сканирование не может причинить вреда, даже когда INPUT полностью открыт. Будут только пинги проходить. Если какой-нибудь сервис поднят, то при такой защите он уже будет доступен только через туннель.