• Codeby web-security - Курс "Тестирование Веб-Приложений на проникновение с нуля" от команды codeby. Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое. Подробнее ...

  • Мобильный клиент нашего форума для Android гаджетов доступен в Google Play Market по этой ссылке. Клиент можно скачать с нашего форума по этой ссылке. Последняя версия МК в нашем телеграм канале вот здесь

Настройка IPTables на разрыв соединения при отключении от VPN

07.02.2018
21
49
#1
Хочу затронуть такую большую проблему, которая очень легко решается.

Не однократно случалось что разрывается соединение с VPN а у тебя там темные делишки творятся. Не удобно очень, да и рисково.

Вчера после очередного разрыва я подумал что должны быть методы, которые уберегут нас от таких вещей. После узнал про IPTables ( кстати, настоятельно рекомендую начать изучение т.к очень полезная вещь).
Оказывается очень короткой командой можно сделать так что бы пакеты не пропускало при разрыве соединения с нашим VPN.

Задать правило :
Код:
iptables -I FORWARD -s 123.132.123.123 -j DROP  // 123.... это IP вашего VPN
Удалить правило :
Код:
iptables -D FORWARD -s 123.132.123.123 -j DROP
Просмотреть правила:
Код:
iptables -L
 
24.03.2017
80
190
#2
Не понимю, часто вижу такие темы. Но OpenVPN же при потере связи с сервером, просто глушит трафик, пока openvpn на клиенте не выключен.
 

Wool

Member
14.03.2018
13
6
#4

Wool

Member
14.03.2018
13
6
#6
Для просмотра контента необходимо: Войти или зарегистрироваться

Перенаправления к 123.123.123.123 дропаются, ты удаляешь это правило и тем самым разрешаешь перенаправлять. Тебе это не поможет.
Тебе еще и мысли научится правильно излагать. Дело не в удалении, добавлении, синтаксисе. Дело в логике правила.
 

TROOPY

Премиум
16.02.2017
103
87
#7
Хочу затронуть такую большую проблему, которая очень легко решается.

Не однократно случалось что разрывается соединение с VPN а у тебя там темные делишки творятся. Не удобно очень, да и рисково.

Вчера после очередного разрыва я подумал что должны быть методы, которые уберегут нас от таких вещей. После узнал про IPTables ( кстати, настоятельно рекомендую начать изучение т.к очень полезная вещь).
Оказывается очень короткой командой можно сделать так что бы пакеты не пропускало при разрыве соединения с нашим VPN.

Задать правило :
Код:
iptables -I FORWARD -s 123.132.123.123 -j DROP  // 123.... это IP вашего VPN
Удалить правило :
Код:
iptables -D FORWARD -s 123.132.123.123 -j DROP
Просмотреть правила:
Код:
iptables -L
А разве не в цепочку output надо добавлять правило? Может кто-то прояснить?
 

Vertigo

Lex mea est Vulgate Linux
Red Team
15.02.2017
788
2 073
#8
А разве не в цепочку output надо добавлять правило?
Попробую.
На самом деле,приведённый пример,следует рассматривать не как самостоятельное отдельное правило.
А часть цепочки правил.Ведь после параметра вставки (-I)и цепочки (Forward в нашем случае),
должен указываться номер строки , т.е. каким по счёту будет строка с правилом в цепочке.

Конечно,логичным кажется сделать какие-то изменения с запретами в цепочке OUTPUT.
Но ,важно помнить,что это как мы знаем, исходящие пакеты и они пройдут через цепочку FORWARD,затем POSTROUTING,
прежде чем,покинуть наш хост.Просто многие ошибочно считают,что OUTPUT-это всё,отправка исходящего трафика.

OUTPUT применяется в основном ,когда у нас маршрутизация и фильтрация более сложная,ставится задача,к примеру,
модифицирования пакетов,проброса портов,маскарадинга,набор правил для ещё какого-то узла в нашей сети.
И в таком случае,будут включены другие таблицы iptables (nat и возможно даже mangle)
Банальный запрет здесь исходящих пакетов просто не обеспечит соединение с узлом VPN изначально,
т.к.тот не то что, не дождётся ответа,к нему и запрос на соединение не пройдёт.

У нас стандартная ситуация,поэтому действует дефолтный приоритет применения таблицы
Это таблица filter,т.к.мы не указываем через параметр -t что-то иное.
Повторюсь,что нам в цепочках других таблиц именно OUTPUT ,не требуется в даном случае таблица mangle,
поскольку нам не требуются изменения в заголовках пакетов ,и кстати,сама фильтрация в такой цепочке признана риском с возможностью негативных последствий.
Также ,нам не требуется применение таблицы nat с цепочкой OUTPUT - мы не преобразовываем здесь сетевые адреса nat,
не требуется от нас трансляция этих же самых адресов в пакетах,которые идут от локальных процессов брандмауэра.

Использовать цепочку INPUT для фильтрации транзитных пакетов нельзя - они туда не попадут.
И вообще,через эту цепь движутся только пакеты,которые предназначены нашему хосту.
Поэтому,у нас остаётся цепочка FORWARD, где в конкретном нашем применре,очень удобно применять какие-то правила.
Ведь сюда идут пакеты ,которые далее попадут на другой хост.
Здесь же ,происходит фильтрация всего транзитного трафика и он движется в обоих направлениях.Это важно.

В итоге,конечно ,каждый желающий может создавать для себя набор правил для приведённой цепи.
Можно установить разрешение на соединение исходящего трафика только с конкретным адресом VPN.
Это неудобно , потому что придётся (в случае,если этот адрес не постоянен)переписывать правила для каждого соединения.
Также ,можно дополнить правила с учётом применения явных параметров через опцию -m --state ESTABLISHED
Т.е.принимать пакеты для нашего хоста,которые принадлежат только этому установленному соединению.
В случае разрыва,понятно,что никакие пакеты приниматься и отправляться не будут,если ещё и указать в правилах конкретные протоколы и порты.
В заключении,для закрепления материала,очень рекомендую заглянуть
Для просмотра контента необходимо: Войти или зарегистрироваться
 
Последнее редактирование:
Вверх Снизу