Как исправить iptables, если я заблокировал все входящие и исходящие соединения?

от комментариев, мы установили это на Амазон aws экземпляр ec2, и что вы заперли себя из-удаленный доступ по SSH. Используя Amazon ec2, то вы будете иметь немного головная боль здесь. Нет реального серийного/консольный режим для доступа, ни тех, кто может просто "исправить" его, и, отключив все соединения, как и ты, ты окончательно заперся в себе.

Вы действительно не имеют много решений здесь, но уничтожить экземпляр ec2 и начать все сначала.

и как только вы начнете снова, у вас есть два варианта, как брандмауэр вашей системы:

использовать группу безопасности ec2 вместо брандмауэра. Это немного проще в настройке, и это уже есть без каких-либо дополнительных настроек - это часть инфраструктуры, ЕС2, где вы должны разрешить порты на самом деле попасть на экземпляр ec2. Вы же не собираетесь запереть себя так же легко (хотя вы можете получить заблокирована, это тривиально, чтобы исправить то, потому что вы просто разрешить порт 22 снова в набор правил из Amazon ec2 в панель настроек, при условии, что Вы не связывайтесь с iptables также). Использовать приличный iptables правил и не выйти из putty на свой ЕС2, пока вы не будете абсолютно уверены, что правила, которые вы приняли не полностью Торпедо доступ к системе.

теперь, я упомянул в #2 в "приличных правил". Ниже здесь мой проводник в ec2 iptables, при условии, что вы на самом деле Читать комментарии перед выполнением команды (например, не связывайтесь с выходным или вперед, если вам действительно нужно).

Вы действительно не имеют много решений здесь, но уничтожить экземпляр ec2 и начать все сначала.

[dиода d17]Вам не нужно, чтобы линии типа, которые имеют # в начале, это просто мои комментарии, объясняя, что каждая команда делает. Кроме того, заменить на [F9] с ваш фактический IP-адрес, где он появляется ниже.[!dиода d17]

фильтрация входящих:

# Permit localhost to communicate with itself. iptables -A INPUT -i lo -j ACCEPT # Permit already established connection traffic and related traffic iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Permit new SSH connections into the system from trusted IP address iptables -A INPUT -p tcp --dport 22 -s YOUR.IP.ADDRESS.HERE -m conntrack --ctstate NEW -j ACCEPT # Permit all other traffic from trusted IP Address iptables -A INPUT -s YOUR.IP.ADDRESS.HERE -j ACCEPT # Drop all other traffic iptables -A INPUT -j DROP

фильтрация входящих:

предупреждение: это позволит заблокировать доступ к серверам обновления, серверы синхронизации времени и т. д. так что только фильтр на исходящие, если вы абсолютно необходимо, в противном случае не делайте этого раздела вообще!д22] # Allow Localhost to itself iptables -A OUTPUT -i lo -j ACCEPT # Allow RELATED,ESTABLISHED state traffic (related to Inbound for example) iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Allow all other traffic to trusted IP address iptables -A OUTPUT -d YOUR.IP.ADDRESS.HERE -j ACCEPT # Drop all other unpermitted outbound traffic. iptables -A OUTPUT -j DROP

вперед фильтрации:

предупреждение: это позволит заблокировать доступ к серверам обновления, серверы синхронизации времени и т. д. так что только фильтр на исходящие, если вы абсолютно необходимо, в противном случае не делайте этого раздела вообще!д23] # Drop FORWARD target traffic, we don't need it iptables -A FORWARD -j DROP

Примечание: если вам действительно нужно ограничить такие вещи, как перенаправление трафика к Интернет через туннель или VPN-сервер в качестве прокси в инет, вы действительно не нужно возиться с правил, поэтому я бы посоветовал не делать этого, потому что ничего другого на самом деле происходит, чтобы использовать эту функцию или когда-либо земле в этот набор правил, Таблица

обратите внимание, что я твердо верю в вперед фильтрации: возиться с политики по умолчанию на сервере, потому что он имеет некоторые... зол... если это не сделано правильно, и я обычно только фильтр входного трафика и [F10] для трафика, и разрешения исходящего трафика из-за синхронизации времени сервера, серверы обновлений в Ubuntu не всегда имея определенное количество IP-адресов, других связанных с этим процессов мне нужно (SSH в/из например, как часть 'связанных с движением) и т. д.

я также твердо верю в использовании REJECT вместо DROP, но это только, чтобы сделать его легче знать, что сервер отказал в подключении. С этой целью, я бы заменять [от f13] с -j REJECT --reject-with icmp-host-unreachable или похожие.

Из комментариев мы установили это на экземпляре Amazon AWS EC2 и что вы заблокировали себя из SSH удаленного доступа. Используя Amazon EC2, у вас будет небольшая головная боль. Нет никакого реального режима серийного / консольного доступа для доступа и никого, кто мог бы «исправить» его, и отключив все подключения, как вы, вы полностью заблокировали себя.

У вас действительно нет

И как только вы начнете, у вас есть два варианта использования брандмауэра вашей системы:

Использовать безопасность EC2 групповой брандмауэр. Это немного легче настроить, и он уже существует без какой-либо дополнительной настройки - это часть инфраструктуры EC2, где вы должны разрешить порты фактически добраться до экземпляра EC2. Вы также не собираетесь блокировать себя так же легко (хотя вы можете быть заблокированы, это тривиально, чтобы исправить это, потому что вы просто разрешаете порт 22 снова в правиле, установленном на панели настроек Amazon EC2, при условии, что вы не испортите с iptables). Используйте подходящий набор правил iptables и не выходите из PuTTY на EC2, пока не убедитесь, что правила, которые вы установили, не полностью торпедируют ваш доступ к системе.

Теперь я упоминаю в № 2 «приличный набор правил». Ниже приведен мой путеводитель по EC2 iptables при условии, что вы действительно прочитали комментарии перед выполнением команд (например, не путайте с OUTPUT или FORWARD, если вам действительно не нужно).

У вас на самом деле нет большого количества решений, кроме как уничтожить экземпляр EC2 и начать все сначала.

Вам не нужно набирать строки, которые имеют a # в начале, это только мои комментарии, объясняющие, что делает каждая команда. Кроме того, замените YOUR.IP.ADDRESS.HERE на ваш фактический IP-адрес, где он отображается ниже.

Входящая фильтрация:

# Permit localhost to communicate with itself. iptables -A INPUT -i lo -j ACCEPT # Permit already established connection traffic and related traffic iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Permit new SSH connections into the system from trusted IP address iptables -A INPUT -p tcp --dport 22 -s YOUR.IP.ADDRESS.HERE -m conntrack --ctstate NEW -j ACCEPT # Permit all other traffic from trusted IP Address iptables -A INPUT -s YOUR.IP.ADDRESS.HERE -j ACCEPT # Drop all other traffic iptables -A INPUT -j DROP

Входящая фильтрация:

Предупреждение. Это заблокирует доступ к серверам обновлений, серверам синхронизации времени и т. д., поэтому ТОЛЬКО фильтрует на Outbound, если вам это абсолютно необходимо, иначе вообще не делайте этого раздела # Allow Localhost to itself iptables -A OUTPUT -i lo -j ACCEPT # Allow RELATED,ESTABLISHED state traffic (related to Inbound for example) iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Allow all other traffic to trusted IP address iptables -A OUTPUT -d YOUR.IP.ADDRESS.HERE -j ACCEPT # Drop all other unpermitted outbound traffic. iptables -A OUTPUT -j DROP

Прямая фильтрация:

Предупреждение. Это заблокирует доступ к серверам обновлений, серверам синхронизации времени и т. д., поэтому ТОЛЬКО фильтруйте на исходящем, если вам это абсолютно необходимо, иначе не делайте этого раздела на всех

# Drop FORWARD target traffic, we don't need it iptables -A FORWARD -j DROP

ПРИМЕЧАНИЕ. Если вам действительно не нужно ограничивать такие вещи, как пересылка трафика в Интернет через туннель или VPN на ваш сервер в качестве «прокси» 'в сеть, вам действительно не нужно возиться с наборами правил FORWARD, поэтому я предлагаю не делать этого, потому что больше ничего не будет использовать эту функцию или когда-либо приземляться в этой таблице правил

Обратите внимание, что я твердо верю в Форвардная фильтрация: возиться с политиками по умолчанию на сервере, потому что у него есть некоторые ... зла ... если не все сделано правильно, и я обычно только фильтрую входящий трафик и трафик FORWARD и разрешаю исходящий трафик из-за серверов синхронизации времени, Ubuntu серверы обновлений, не всегда имеющие определенное количество IP-адресов, другие связанные процессы, которые мне нужны (SSH в / из, например, как часть «связанного» трафика) и т. д.

Я также твердо убежден в использовании REJECT вместо DROP, но это только для того, чтобы было легче узнать, что ваш сервер встал и отказался от соединений. С этой целью я бы заменил -j DROP на -j REJECT --reject-with icmp-host-unreachable или аналогичный.