Правило IPTables, щоб дозволити вхідні SSH-з'єднання


11

Метою цього сценарію є лише дозволити трафік через VPN, за винятком localhost <-> localhost та вхідного SSH трафіку. Але коли я запускаю сценарій через SSH, я відключаюсь і змушений перезапустити vm. Що не так з моїм сценарієм?

#!/bin/bash
iptables -F

#Allow over VPN
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

#Localhost
iptables -A INPUT -s 127.0.0.1/8 -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1/8 -j ACCEPT

#VPN
iptables -A INPUT -s 123.123.123.123 -j ACCEPT
iptables -A OUTPUT -d 123.123.123.123 -j ACCEPT

#SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

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

Відповіді:


10

Вихідний ланцюг несе відповідальність за вихід будь-якого пакету.

Ваш сценарій дозволяє лише вихідним пакетам тунельний інтерфейс, localhost та віддалений хост на 123.123.123.123.

Якщо ви підключаєтесь до сервера таким чином, що вимагає, щоб демон SSH надсилав пакети до пункту призначення, відмінного від одного з перерахованих вище, трафік не буде дозволений.

Щоб дозволити вихідні пакети з вашого демона SSH клієнту SSH, вам потрібно додати таке правило:

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Ви також можете додати до вищезазначеного правила IP-критерії призначення, якщо ви підключаєтесь лише з одного місця. Це правило повинно бути перед кінцевим правилом "ЗРОБИТИ що-небудь інше" для вихідного ланцюга.


+1 Це буде спрацьовувати і є більш конкретним, ніж використання встановленого, пов'язаного правила (що робить його більш-менш корисним залежно від контексту).
goldilocks

Обидва чудові відповіді, я багато чого навчився! Я перевірив відповідь @SkyDan, і вона працює добре!
Стівен

Nitpick: ланцюг виводу не відповідає за переслані пакети.
Бьорн Ліндквіст

13

Ваше #SSHправило передбачає, що ssh - це одна зі способів спілкування, якою вона не є. Дані надсилаються вперед і назад.

Нормальний спосіб вирішити це, оскільки ви не можете знати номер порту на стороні клієнта заздалегідь, це дозволити з'єднання, які вважаються "встановленими" або "пов'язаними" з встановленим з'єднанням. Для цього вам потрібно:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Перед вашими DROPправилами (бажано вгорі, оскільки правила обробляються в порядку, і ці два стосуватимуться більшості пакетів).

Тут є пояснення того, як TCP-з'єднання стає встановленим тут ; по суті, факт відповіді сервера на пакет, дозволений вашим #SSH INPUTправилом, робить це так.


1
Це не вийде. Видно встановлені пакети засобів в обох напрямках для даного TCP-з'єднання. Якщо ви додасте лише це правило, перший вихідний пакет все одно буде заблокований.
hellodanylo

2
@SkyDan Ось посилання на це . Зауважте на діаграмі, що коли сервер відправляє syn / ack назад до клієнта після отримання відкриваючого syn, з'єднання встановлюється, тобто iptables дозволить відповісти пакету через: "Після того, як він побачив один пакет (SYN), він враховує з'єднання як НОВЕ. Після того, як він побачить пакет повернення (SYN / ACK), він розглядає з'єднання як ВСТАНОВЛЕНО. " -> знову: iptables бачить зворотний пакет, який сервер хоче надіслати, встановлює з'єднання як встановлене, і дозволяє відповісти.
goldilocks

1
Гаразд, я бачу, чому це буде працювати. Це трохи незрозуміло, оскільки людина iptables говорить лише про те, щоб побачити пакети в обох напрямках, і жодне слово про пакети рукостискання TCP не є винятком. Дякую за довідку!
hellodanylo

2
@SkyDan Насправді логіка не стосується лише tcp - я помилявся, -p tcpколи я змінив значення в цьому сенсі, і подивився подальше пояснення UDP на цій сторінці (це те саме). Справа в тому, що сервер відповідає, не знаючи, чи дозволить iptables це чи ні, і коли iptables отримає цю відповідь від сервера в локальній системі , він тепер побачив трафік в обох напрямках (навіть якщо клієнт ще не має), вважає з'єднання встановлено і дозволяє відповідь. Тут "технічність" залежить від брандмауера, що знаходиться посеред двох сторін.
goldilocks

1
Ви там праві. Хтось, мабуть, повинен включити цю інформацію в людину iptables.
hellodanylo
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.