Показ дописів із міткою iptables. Показати всі дописи
Показ дописів із міткою iptables. Показати всі дописи

вівторок, 7 жовтня 2014 р.

Шлюз Ubuntu з iptables: історичний скрипт і розбір помилок

У цій старій нотатці я описував налаштування шлюзу Ubuntu через iptables після спроб використати UFW, Squid та інші інструменти. Для своїх проєктів зручним виявився повторно використовуваний скрипт. Це особистий досвід, а не універсальна перевага одного засобу для всіх мереж.

В інтернеті вистачало готових варіантів; цей скрипт я теж колись знайшов у мережі :).

Початкова конфігурація призначалася для віртуальних серверів на одному мережевому інтерфейсі. Назви eth0, eth0:1 та підмережа 10.0.2.0/24 належать до того прикладу.

Що потрібно уточнити перед читанням коду

Скрипт очищує правила firewall у кількох таблицях і змінює пересилання пакетів. Його запуск на робочому чи віддаленому сервері може прибрати наявний захист або перервати доступ. Нижче збережено історичний код, а не готову безпечну політику для сучасної системи.

У початковому тексті dnsmasq помилково названо програмою для маскарадингу. NAT у цьому прикладі виконує Netfilter/iptables; dnsmasq використовується для DNS/DHCP та не є необхідною умовою самого NAT. Початкова команда встановлення:

aptitude install dnsmasq

Для одночасної роботи bind9 і dnsmasq я тоді використовував у rc.local:

service bind9 stop
service dnsmasq restart
service bind9 start

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

Початковий скрипт

#!/bin/bash
# Тут в принципе может и не надо этого всего но не помеха
# вдруг какой модуль не подгружен или форвардинг не включен
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

# Объявление переменных
export IPT="iptables"

# Интерфейс который смотрит в интернет
export WAN=eth0

# Локальная сеть (в моем случае, все висит на одном интерфейсе. Чеще всего же тут заменяете на eth1)
export LAN=eth0:1
export LAN_IP_RANGE=10.0.2.0/24

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Закрываем изначально ВСЁ (т.е. изначально все что не разрешено - запрещено):
###$IPT -P INPUT DROP
###$IPT -P OUTPUT DROP
###$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback и внутренней сети
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A INPUT -i $LAN -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A OUTPUT -o $LAN -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Разрешить форвардинг для новых, а так же уже инициированных
# и их дочерних соединений
$IPT -A FORWARD -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU
$IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы
# и поэтому не могут иметь определенного статуса.
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A FORWARD -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный
# обмен данными становится не возможным.
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP



# Разрешаем доступ из внутренней сети наружу
$IPT -A FORWARD -i $LAN -o $WAN -j ACCEPT

# Запрещаем доступ снаружи во внутреннюю сеть
$IPT -A FORWARD -i $WAN -o $LAN -j REJECT

# Маскарадинг
$IPT -t nat -A POSTROUTING -o $WAN -s $LAN_IP_RANGE -j MASQUERADE


# Далее дано как пример открытие портов извне:
# **********************************************************************
# Открываем порт для ssh
$IPT -A INPUT -i $WAN -p tcp --dport 22,220 -j ACCEPT

# Открытие портов для торрентов (такие же указать в torrent-клиенте)
# $IPT -A INPUT -i $WAN -p tcp -m multiport --ports 49152:65535 -j ACCEPT

# Открытие 443 порта
$IPT -A INPUT -p tcp --dport 443 -j ACCEPT

# Открываем 80 порт для веб сайтов
$IPT -A INPUT -i $WAN -p tcp --dport 80 -j ACCEPT
$IPT -A INPUT -i $WAN -p udp --dport 80 -j ACCEPT

# Открытие портов для игровых серверов
# $IPT -A INPUT -i $WAN -p tcp --dport 27010:27030 -j ACCEPT
# $IPT -A INPUT -i $WAN -p udp --dport 27010:27030 -j ACCEPT

# Открытие порта для голосового сервера Team Speak
# $IPT -A INPUT -i $WAN -p tcp --dport 9987 -j ACCEPT
# $IPT -A INPUT -i $WAN -p udp --dport 9987 -j ACCEPT
# **********************************************************************
.
# Вывод информации о состоянии таблиц.
route -n
$IPT -L
$IPT -L -v -n
$IPT -L -v -n -t nat

Помилки й обмеження прикладу

  • Рядки політик DROP закоментовані: коментар про початкову заборону всього не відповідає фактичним командам.
  • Раннє правило FORWARD дозволяє NEW, ESTABLISHED і RELATED без обмеження інтерфейсів. Пізніша заборона вхідного пересилання не забезпечує очікувану фільтрацію всього такого трафіку.
  • --dport 22,220 не є коректним способом задати перелік портів. Для списку використовується модуль multiport із параметром --dports.
  • Окремий рядок із крапкою та назви старих FTP-модулів потребують перевірки; код не слід копіювати без аналізу.
  • TCPMSS коригує MSS TCP-з'єднань; коментар про «вмикання фрагментації» неточний.

Приклад синтаксису списку портів, окремо від початкового скрипту:

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 22,220 -j ACCEPT

Вихідна нотатка пропонувала зберігати скрипт як fw.sh та викликати з rc.local:

/usr/fw/fw.sh

Спосіб запуску, backend iptables, назви інтерфейсів і правила слід узгоджувати з поточною системою. Опис iptables та multiport допомагає перевірити значення команд. Перед застосуванням потрібні збережені поточні правила та доступ для відновлення.

субота, 14 лютого 2009 р.

Firestarter і PPTP VPN: розбір старого обхідного рішення

У старій конфігурації VPN я зіткнувся з проблемою взаємодії Firestarter і з'єднання через ppp0. Guarddog мені не підійшов, тому я повернувся до Firestarter й знайшов обговорення за адресою http://forum.ubuntu.ru/index.php?topic=42746.0.

Інтерфейс ppp0 і перший обхід проблеми

Спочатку я вибрав ppp0 як інтерфейс, що дивиться в інтернет, і відредагував /etc/firestarter/user-pre. Наведений варіант із політиками ACCEPT міг істотно послабити фільтрацію — саме тому його не варто переносити як готове безпечне налаштування:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Це встановлює політику ACCEPT для відповідних вбудованих ланцюжків. Така політика дозволяє пакети, для яких не спрацювало інше завершальне правило; вона не видаляє наявні правила, але може істотно послабити фільтрацію. Відновлення VPN таким способом не підтверджує безпечного налаштування.

Окремі правила для PPTP і неперевірена ідея з FORWARD

На інших форумах я також зустрічав такі правила:

$IPT -A INPUT -p TCP --dport 1723 -j ACCEPT
$IPT -A INPUT -p 47 -j ACCEPT
$IPT -A OUTPUT -p TCP --dport 1723 -j ACCEPT
$IPT -A OUTPUT -p 47 -j ACCEPT

У моїй тодішній конфігурації з цим варіантом з’єднання через певний час усе одно переривалося. Я припускав, що слід додати ще два рядки, але їх не перевіряв:

$IPT -A FORWARD -p TCP --dport 1723 -j ACCEPT
$IPT -A FORWARD -p 47 -j ACCEPT

Тут $IPT — змінна зі старого оточення, значення якої в нотатці не задано. Число 47 позначає IP-протокол GRE, а не порт; TCP 1723 використовується для керувального з'єднання PPTP. Самі ці фрагменти не визначають повного набору правил для маршрутизації, станів з'єднань і конкретної топології.

Перезапуск Firestarter після редагування

Після зміни файла в тодішній системі я перезапускав Firestarter:

sudo /etc/init.d/firestarter restart

Що перевіряти під час діагностики

Для діагностики слід перевіряти фактичні правила, журнали та потрібні напрямки трафіку, з можливістю повернення попередньої конфігурації. Технічний опис дії правил і протоколу: Netfilter: iptables та RFC 2637: PPTP. Цей історичний розбір не є рекомендацією обирати PPTP для нового VPN.

Міжмережевий екран Linux: Netfilter, Firestarter і Guarddog

Графічні оболонки, на які я звернув увагу

У 2009 році для редагування правил iptables я розглядав графічні оболонки Firestarter і Guarddog. Firestarter здавався простішим, але в моїй конфігурації переривалися VPN-з’єднання; Guarddog був складнішим у налаштуванні. Це особисте спостереження, без версій і журналів збою.

Netfilter і керування правилами

Ядро Linux містить підсистему Netfilter, а правила налаштовують відповідними інструментами. Не всі конфігурації зводяться до редагування одного текстового файла й не кожна система автоматично має потрібні правила.

Де перевірити спосіб налаштування своєї системи

У сучасному контексті також є nftables і засоби керування на кшталт ufw. Конкретний інструмент і спосіб збереження правил залежать від дистрибутива та його версії. Для Ubuntu це пояснює документація щодо міжмережевих екранів.

K2 відкрила курс з ERP: 61 урок, практика й сертифікат

Перший день у новій ERP часто починається з пошуку потрібної кнопки. Наступний виклик складніший: зрозуміти, що зміниться після натискання. ...