Файервол для Linux с простым интерфейсом
Файервол представляет из себя bash-скрипт, который интегрирует с помощью соответствующих пакетов следующие функции:
- Файервол внешний и внутренний (пакет iptables).
- Учёт трафика внешнего и внутреннего (пакет iptables).
- Прокси-сервер для локальных сетей (пакет Squid).
- Контент-фильтр для локальных сетей (пакет DansGuardian).
- DNS-сервер для локальных сетей (пакет BIND).
Скрипт является результатом многолетней работы и претендует на универсальность — он позволяет использовать Linux-машину в качестве Интернет-шлюза как для небольшого офиса, так и для большого предприятия (на данный момент он используется на пяти предприятиях и в одном удалённом офисе — везде стоит CentOS).
Скрипт требует для своей работы наличие как минимум двух сетевых интерфейсов — один из которых является внешним, а остальные считаются внутренними. Внешний интерфейс задаётся переменной EXTIF и определяется автоматически, если эта переменная не задана.
Ещё одно требование — все интерфейсы должны иметь статические адреса, т.е. интерфейсы могут получать их динамически, но адреса должны быть всегда одними и теми же. Это требование вытекает из того, что в правилах iptables используются IP-адреса интерфейсов. Правила генерируются и применяются на основе файла конфигурации fwtraf.conf по команде «fwtraf fwnormal» и сохраняются по команде «fwtraf fwsave«. Т.е. если IP-адреса интерфейсов изменились, нужно будет опять применить правила (и сохранить их, если нужно чтобы они действовали после перезагрузки).
Режимы работы source NAT и web-прокси можно комбинировать:
- source NAT: выкл. (SNAT=»»)
- source NAT: вкл. (SNAT=«YES»).
- web-прокси: выкл. (WEBPROXY=»»)
- web-прокси: Squid (WEBPROXY=«SQUID»).
- web-прокси: DansGuardian->Squid (WEBPROXY=«DGSQUID»).
Скрипт поддерживает несколько локальных сетей (переменная LANS) — они перечисляются через пробел:
LANS=«192.168.0.0/24 10.0.0.0/8»
Также поддерживаются удалённые локальные сети — например, локальные сети офисов, подключенные по технологиям VPN (переменная REMOTE_LANS):
REMOTE_LANS=«192.168.1.0/24 192.168.3.0/24 192.168.5.0/24»
Скрипт имеет простой конфигурационный файл:
В нём указаны статические IP-адреса и имена компьютеров пользователей, которым:
- разрешаются (команда a — сокращение от «allow»)
- запрещаются (команда d — сокращение от «deny»)
порты (колонка PORTS):
- один или несколько TCP-портов через запятую: web,ftp.
- все TCP-порты кроме, например, smtp: !smtp.
- все TCP и UDP-порты: all.
Если используется контент-фильтр (WEBPROXY=«DGSQUID») и пользователю разрешаются web-порты , то к нему применяется группа web-доступа (колонка WA — сокращение от «Web Access»).
Очень просто делается так называемый проброс портов внешнего интерфейса на внутренние IP-адреса локальных сетей (destination NAT). Это удобно, когда на шлюзе включен режим SNAT и локальные сети из Интернет недоступны. Например, разрешим админу с его компьютера доступ к Интернет (web и ftp-трафик) и ещё разрешим ему подключаться из Интернет по RDP на внешний IP-адрес шлюза, а шлюз будет перенаправлять rdp-трафик на его компьютер:
a 192.168.1.240 pc30 0 web,ftp,rdp-rdp # Админ
Ещё замечу, что пробрасываемые порты не обязаны совпадать — можно, например, слушать порт 2525 на внешнем IP, а пробрасывать его на 25-й порт почтового сервера, находящегося внутри локальной сети:
a 192.168.1.2 mail 0 2525-25 # Почтовый сервер
Скрипт также ежедневно создает html-отчеты о трафике и ежечасно их обновляет :
И ещё небольшой бонус — после установки файервола в ежедневных отчетах Logwatch будут появляться записи об IP-адресах, превышающих лимиты подключений CONN_LIMIT. Таким образом, вы всегда будете в курсе, кто проявляет к вашему серверу повышенный интерес:
— iptables firewall Begin ————————
Logged 24 packets on interface eth0
From 10.7.57.22 — 21 packets to tcp(110)
From 10.16.63.206 — 3 packets to tcp(110)
Logged 5367 packets on interface eth1
From 72.53.179.125 — 5297 packets to tcp(110)
From 193.255.130.19 — 2 packets to tcp(25)
From 217.175.23.3 — 68 packets to tcp(25)
1. Скачиваем скрипт файервола и помещаем его в /bin/ :
wget —no-check-certificate sites.google.com/site/smkuzmin/home/fwtraf/fwtraf -O fwtraf
mv fwtraf /bin/
chmod 755 /bin/fwtraf
2. Скачиваем файл конфигурации файервола и помещаем его в /etc/fwtraf/ :
wget —no-check-certificate sites.google.com/site/smkuzmin/home/fwtraf/fwtraf.conf -O fwtraf.conf
mkdir /etc/fwtraf
mv fwtraf.conf /etc/fwtraf/
3. Скачиваем файл для планировщика задач Cron и помещаем его в /etc/cron.d/ :
wget —no-check-certificate sites.google.com/site/smkuzmin/home/fwtraf/fwtraf.cron -O fwtraf.cron
mv fwtraf.cron /etc/cron.d/
4. Выключаем сервис iptables и добавляем инициализацию файервола при каждой загрузке:
chkconfig iptables off
chkconfig ip6tables off
echo>>/etc/rc.d/rc.local /bin/fwtraf fwinit
5. Читаем файл /etc/fwtraf/fwtraf.conf и редактируем его в соответствии со
своими потребностями.
6. После редактирования fwtraf.conf применяем правила файервола:
fwtraf fwnormal — нормальный (рабочий) режим.
7. Проверяем работу файервола, и если всё устраивает, сохраняем правила:
fwtraf fwsave — все правила сохраняются и действуют после перезагрузки.
Существует режим с минимальным набором правил:
fwtraf fwsimple — простой режим, персональные правила не действуют, всё разрешено.
Остальные команды можно узнать так:
fwtraf — справка по командам.
Для включения поддержки работы с BIND ( внимание: будут презаписываться DNS-зоны! ) нужно раскомментировать строку c » DNSROOTDIR=. » в /bin/fwtraf.
Программный интернет шлюз для уже не маленькой компании (Shorewall, OpenVPN, OSPF). Часть 1
Представляю пока две статьи, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:
- Простейшая настройка Shorewall
- Ужасно сложная настройка dnsmasq
- Не менее сложная настройка OpenVPN
- И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF
А во второй части будут рассмотрены:
- Более подробная настройка Shorewall
- Страшный и не понятный QoS
- Балансировка нагрузки и резервирование
В третьей части:
- QoS во всю ширь в Shorewall
- Более подробная настройка Shorewall
- Раскидывание трафика по каналам в соответствии с протоколами
- Костыли, без них, никуда
В четвертой части:
- Автоматические события
- Макросы
Все описанное ниже справедливо для CentOS 7.1 (и выше, 6 серия тоже подойдет, но с небольшими особенностями)
Исходим из того, что у нас:
- Локалка первого филиала: 172.16.0.0/23
- Подсеть OpenVPN первого филиала: 172.16.3.0/25
- Второй филиал соответственно: 172.16.8.0/23 и 172.16.11.0/25
Вообще мой ip план подразумевал резервацию /21 сети для каждого филиала из диапазона 172.16.0.0/12. Каждый диапазон /21 нарезается на подсети для различных нужд (подробнее в следующей статье).
Простейшая настройка Shorewall
Для тех кто не слышал раньше, Shorewall это надстройка над утилитой iptables для конфигурирования NetFilter в ядре Linux. Сама по себе iptables не слишком сложная, но когда конфигурация шлюза становится большой и от этого сложной, разобраться в таком объеме команд iptables становиться не просто.
На помощь в таких ситуациях приходят различные самопальные скрипты или, уже давно не самопальные, системы аналогичные Shorewall.
В Shorewall все вертится вокруг понятия «зона». В зону включаются хосты (путем задания интерфейсов или непосредственно сетей и/или отдельных адресов).
Ключевые слова значат следующие:
- ACCEPT — принимать (в том числе форвардить) пакеты
- REJECT — Отбросить пакет, а отправителю сообщить, что писем мы от него не ждем
- DROP — Отбросить пакет, и загадочно осмотревшись, никому ничего не сказать
В третий столбец можно прописать еще несколько параметров, один из которых info, задаст логирование данной политики (имеет смысл для DROP и REJECT, а то ACCEPT завалит вас логами).
Заданная политика примитивна и не годится для серьезных проектов, соответствует настройке большинства домашних роутеров, но для самого старта она нам подойдет.
Осталось чуть чуть, а именно настроить маскарадинг (чего в эпоху IPv6 делать будет не надо):
Очевидно, все что идет в сторону интерфейса $IF_RED1 из сети $NET_GRN нужно замаскировать. Третий столбец ADDRESS используется для SNAT.
Для отслеживания и соответствующего изменения правил файрвола, в ответ на включение\отключение интерфейса, нам поможет небольшой скрипт:
Дав команду «systemctl enable shorewall.service && systemctl restart shorewall.service», мы применим настройки нашего файрвола, и у нас ничего (ну почти), не заработает, нам не хватает самой малости: нет кэширующего DNS И DHCP серверов (не будем же мы сами все клиентские машины настраивать).
Простейшая настройка dnsmasq
Эта служба очень неплохо справляется со своей задачей, и сеть /23 для неё не является проблемой, а простота и гибкость настроек делает её очень подходящей для нашей ситуации.
Так как файл настроек большой, приведу и его тоже в урезанном виде:
Думаю пояснять тут ничего особо не надо, задали интерфейс, на котором обслуживать DNS и DHCP запросы, задали диапазон раздаваемых адресов, задали некоторые передаваемые в DHCP параметры и задали авторитарный режим работы.
Теперь после «systemctl enable dnsmasq.service && systemctl restart dnsmasq.service» у нас заработает доступ в интернет с внутренних клиентов (как только аренду DHCP получат).
Настройка OpenVPN
Думаю это часть не составит особого труда вообще никому, но приведем эти шаги:
- Из epel установим пакеты: openvpn easy-rsa
- Скопируем из /usr/share/easy-rsa папку в /etc/openvpn и переименуем её в easy-rsa
- Перейдем в /etc/openvpn/easy-rsa и при необходимости отредактируем файл vars
- Выполним: «. ./vars && ./clean-all && ./build-dh && openvpn —genkey —secret ./keys/ta.key &&./build-ca && ./build-key-server server #привет от гентушника (как установить Gentoo одной командой, да и такое возможно)!
Еще нам понабиться файл конфигурации сервера:
Я использую интерфейс типа tap, потому, что tun маршрутизируется ядром OpenVPN, и конфигурируется это все директивой iroute. И печаль такова, если за одним сервером, будет еще один, к которому нам нужен маршрут, этот маршрут нам надо в явном виде прописывать в ccd, той самой директивой iroute, что помимо обычных маршрутов создаст лишние трудности (о каких трудностях я говорю, написано в разделе OSPF).
Теперь сгенерим конфигурацию для клиента:
./build-ovpn.sh -r
Создадим файл ccd для клиента:
После надо скопировать файл из каталога /etc/openvpn/ovpn/ / .ovpn на клиентский компьютер (шлюз) и поместить его в /etc/openvpn/ с расширением «.conf»
Запускаем openvpn на клиенте и сервере:
А результат есть только на сервере! Клиент в непонятках. Во всем виноват shorewall, а точнее, наша политика, мы не разрешили соединения из интернета (red зона)!
Внесем разрешающее правило в файл:
Выполняем «shorewall restart» и видим, что клиент успешно подключился.
Попробуем попинговать ip клиента, выданный OpenVPN, все Ok. Теперь сеть за клиентом (172.16.8.0/23), и опять облом, ip в туннеле пингуется, а сеть нет, так как нет маршрутов, их нам и предоставит OSPF.
Настройка протокола динамической маршрутизации OSPF в quagga
Тут на хабре есть серия больших статей посвященных динамической маршрутизации, тому как оно работает, и т.д., тут же я дам некоторую практическую выжимку из них и саму настройку.
К использованию OSPF я пришел после того, как компания в которой я работаю, обзавелась почти десятком филиальчиков и представительств, и туннели между ними были построены не только звездой, но и были еще прямые между отдельными филиалами (чтобы наиболее активно взаимодействующие ходили по прямой, а не в центральный узел). Когда я малость припух от числа маршрутов и мест их настройки, соорудил велосипед (скрипт, который перестраивал статические конфиги маршрутов по прописанной карте), велосипед был красивый, колеса шестиугольные, педалей десять, и для езды ты его катишь, сам идя рядом… Ну его в болото, подумал я, и по быстрому выяснил про OSPF и начал внедрение.
Нам понадобится пакет quagga, после установки, скопируем файл начальной конфигурации и запустим службу:
Теперь нам понабиться настроить ip адрес на loopback интерфейсе, который помимо прочего (смысл вы найдете в других статьях), будет выполнять роль router-id.
В файл /etc/sysconfig/network-scripts/ifcfg-lo добавим строки:
И повторно подымим интерфейс: ifup lo
Теперь подключимся к службе ospfd и проведем её настройку:
Итоговый файл конфигурации:
Скопировав этот файл на другой шлюз (который связан с этим по OpenVPN) и внеся туда соответствующие правки, мы получим рабочую конфигурацию между двумя шлюзами (службу ospfd на втором шлюзе тоже надо запустить).
Теперь команда «ip route list» должна показать нам нечто подобное:
Маршруты с «proto zebra» как раз добавлены с помощью OSPF.
Я рекомендую всем, используйте динамическую маршрутизацию, даже если у вас всего два филиала. Когда их станет больше, вам не составит труда добавить еще один узел в сеть.
И конечно, предложенная конфигурация OSPF довольна примитивна, более сложные варианты с примерами ждите в следующей статье (или читайте статьи более компетентных товарищей, по сути, OSPF я изучил еще не достаточно глубоко).
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.