[iptables] mac filtering, squid, nat
Необходимо раздать интернет на основании MAC-адресов. При этом HTTP-трафик заворачивать на squid, а остальной пропускать через NAT. Дело в том, что MAC-адресов достаточно много и не хотелось бы их дублировать. Возможно ли какое-то красивое решение?
На данный момент приходится дублировать адреса в таблице NAT цепочки PREROUTING и в таблице FILTER цепочки FORWARD.
генерируй правила циклом, на основе списка маков.
Что в таком случае лучше использовать для обработки списка маков? awk? Пример бы не помешал.
Легко. Выделяй пакеты по макам и маркируй их в mangle/PREROUTING, а в nat/PREROUTING и filter/FORWARD отлавливай их по маркировке.
iptables -t mangle -N check_mac
iptables -t mangle -A check_mac -m mac —mac-source 00:1c:fc:9a:94:fa -j MARK —set-mark 1
.
iptables -t mangle -I PREROUTING -p tcp -j check_mac
iptables -t nat -I PREROUTING -i eth1 -p tcp —dport 80 -m mark —mark 1 -j REDIRECT —to-ports 3128
iptables -I FORWARD -m mark —mark 1 -j ACCEPT
Также советую фильтр по маркировке добавить в filter/INPUT, чтобы всякие на проксю не шлялись.
Впрочем, лично мне более изящным кажется решение на базе stateful-маркировок.
Поробуйте использовать ipset macipmap для выделения трафика от разрешенных хостов, потому что если MAC-адресов достаточно много то куча правил затормозит ваш роутер. Вообще неплохо бы просто прибить ип к макам на коммутаторах заюзав DHCP snooping, а на шлюзе ориентироваться только на ip адреса.
В данном случаем может и не подойти, так как оно работает только в том случае, если айпишники гвоздями прибиты к макам. Проверять маки отдельно там нельзя. (Ключ matchunset к делу не относится, он разрешает проверку адресов на соответствие рабочему диапазону безотносительно мака.)
если MAC-адресов достаточно много то куча правил затормозит ваш роутер
netfilter очень неплохо вылизан по скорости, поэтому, чтобы создать ощутимые задержки, нужны тысячи или десятки тысяч правил (в зависимости от железа). Сомневаюсь, что в сети ТС’а найдется столько уникальных маков.
Всем спасибо. Воспользовался советом 
nnz и markevichus .
Фильтруемых маков несколько десятков, не более.
Источник
linux-notes.org
Я уже рассказал о том, как можно себя защитить от различных атак. Иногда, приходиться додумывать различные методы использования защиты, т.к СА (системный администраторы) зачастую закрывают все порты ( не все конечно. Открытые используются для работы). При этом, клиенты хотят использовать сервер из вне ( подключаться к нему и работать). А бывает так, что вообще нужно забанить определенную особь. При статическом IP на стороне клиента, трудно угадать какой ИП разрезать/запрещать — в такой ситуации хорошо подойдет MAC-фильтрацию через IPTables.
Iptables имеет модуль, который обеспечивает MAC-фильтрацию пакетов на определенные порты. Эта статья «Фильтрация MAC используя Iptables в Linux» покажет как можно использовать данный модуль на готовых примерах.
Разрешить полный доступ к конкретной MAC
Ниже команда которая позволит работать со всеми портами для определенного MAC-адреса (например 5D:E5:66:B4:44:3A).
Разрешить/Запретить SSH доступ к определенным MAC
С IPtables можно разрешать и запрещать подключения к серверу через mac-адрес.
Разрешить SSH доступ к определенным MAC.
Ниже команда разрешит доступ на сервер через SSH (порт 22) с MAC-адресом 5D:E5:66:B4:44:3A.
Запретить SSH доступ к определенным MAC.
Ниже команда запретит доступ на сервер через SSH (порт 22) с MAC-адресом 5D:E5:66:B4:44:3A.
Ограничить SSH для всех, кроме специфического MAC
Ниже команда позволит получить SSH доступ (порт 22) для системы, имеющие физический адрес 5D:E5:66:B4:44:3A.
На этом все, я завершаю свою статью «Фильтрация MAC используя Iptables в Linux».
Источник
Squid и Iptables фильтруем по mac адресам.
Был у меня на работе старенький сервачок на FreeBSD, на нем крутился DHCP и squid, и что бы никто без моего ведома не получал доступ к интернетам, был своеобразный фильтр, по маку выдавался определенный IP, который был разрешен в squid через SAMS. Слишком много телодвижений подумал я, и решил все упростить. 
FreeBSD решил снести и накатить туда debian. Процедуру установки описывать не буду, не об этом заметка.
1. В squid включаем прозрачность
В 3 версии необходимо слушать на 2х портах, один прозрачный, второй обычный
2. У меня на работе 5 этажей и для каждого этажа я создал по файлу с mac адресами
Содержимое файла 1_floor.mac
Можно включить в логах отображение mac-адреса, для этого в конфиг сквида нужно добавить:
3. Теперь про iptables.
Закручиваем весь http траффик на 8081 порт(прозрачный)
Все запросы из 84 подсети, кроме 84.1(это наш сервер) на 80 порт, будут перенаправлены на локальный порт 8081.
Допустим некоторых надо пустить напрямую, без редиректа, через NAT, для этого следующее правило:
Оно должно быть выше, редиректа на SQUID
Ну а теперь самое интересное, многие знают, что 443 порт очень сложно сделать прозрачным, точнее даже не сложно, а геморройно, связи с сертификатами. Так вот, наша задача состоит в том, что бы включить NAT на 443 порт для mac адресов перечисленных в файлах *.mac.
Принцип действия.
Мы создаем таблицу(mangle) mac_access и маркируем пакеты с определенных mac адресов, и в конечном итоге указываем, что разрешено этим маркированным пакетам.
Скрипт для добавления всех mac адресов из файлов X_floor.mac расположенных в /etc/squid3
Правило в iptables разрешающее NAT 443 порта
4. И немножко про DHCP.
В настройка DHCP можно указать файл автоматический конфигурации PROXY. Для этого надо добавить следующее:
/etc/dhcp/dhcpd.conf
Если нет никакого http сервера, устанавливаем lighttpd apt-get install lighttpd , особой конфигурации не требует.
Создаем файл /var/www/html/wpad.dat:
IE и Chrome понимают данную конструкцию.
Так же про wpad можно почитать здесь http://habrahabr.ru/company/mailru/blog/259521/
Вроде бы все, из вышесказанного можно делать любые конструкции по фильтрации и маскарадинга по mac адресу. Насчет производительности не уверен, но у меня в таблице свыше 100 mac адресов и сервер хоть и старенький, но чувствует себя комфортно.
Источник
Фильтрации пакетов для программных мостов
Данная заметка есть продолжение предыдущей где я рассматривал, как объединять интерфейсы в один образуя программный мост, а также той где упоминал что на основе собранной информации по MAC адресам всех систем в локальной сети буду разграничивать доступ. Существует еще один этап безопасности который можно использовать на благо своей сети – это
объединение коммутатора и брандмауера посредством утилиты ebtables которая также присутствует в репозитариях Ubuntu 12.04.5 Server
$ apt-cache search ebtables
ebtables — Ethernet bridge frame table administration
Брандмауер на канальном уровне ничем себя не выдает по сравнений с сетевым, он прозрачен/невидимый
Утилита ebtables имеет в своем арсенале следующие возможности:
— фильтрация на уровне протокола Ethernet;
— фильтрация MAC-адресов;
— простая фильтрация по заголовкам IP;
— фильтрация по заголовкам ARP;
— фильтрация VLAN 802.1Q;
— фильтрация входящего и исходящего интерфейсов (логических и физических устройств);
— трансляция MAC-адресов (NAT);
— ведение логов;
— счетчики кадров;
— возможность добавлять, удалять, вставлять правила, сбрасывать цепочки, обнулять счетчики;
— возможность создавать brouter;
— возможность автоматической загрузки таблицы с созданными правилами в ядро;
— поддержка определяемых пользователем цепочек;
— поддержка маркировки кадров и соответствия маркированным кадрам.
Для справки: ebtables чем-то напоминает iptables с той лишь разницей, что используется на втором уровне модели OSI (Канальный уровень), а iptables на третьем (Сетевой уровень)
- Канальный уровень – Физическая адресация – PPP, IEEE 802.2, L2TP, ARP
- Сетевой уровень – Определение маршрута и логическая адресация – IPv4,IPv6,IPsec
Для справки: трафик проверяется ebtables раньше, чем это сделает iptables – т.к. это разные уровни модели OSI. В ebtables управление идет на основе MAC-адреса, а в iptables — IP-адреса.
$ sudo apt-get install ebtables -y
$ sudo ebtables —list
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT → входящие правила
Bridge chain: FORWARD, entries: 0, policy: ACCEPT → правила идущие транзитом
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT → исходящие правила
К примеру запретим подключение к текущей системе если компьютер с которого я подключаюсь имеет следующий MAC-адрес
(мой компьютер с которого я подключаюсь к системе где изучаю работу bridge:
> sudo ifconfig vlan10 | grep ‘addr’
vlan10 Link encap:Ethernet HWaddr 00:E0:4C:8D:7F:E9
inet addr:10.7.8.227 Bcast:10.7.8.255 Mask:255.255.255.0)
$ sudo ebtables -A INPUT -s 00:E0:4C:8D:7F:E9 -j DROP
теперь пробую послать ECHO запрос к хосту 10.7.8.154 с 10.7.8.227 и получаю – блокировка:
PING 10.7.8.154 (10.7.8.154) 56(84) bytes of data.
— 10.7.8.154 ping statistics —
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
Работает, для удаления правила, отобразим сперва все правила какие есть а уже потом на основе вывода удалим созданную выше цепочку:
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
-s 00:E0:4C:8D:7F:E9 -j DROP → удаляем эту цепочку
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
$ sudo ebtables -D INPUT 1
если цепочек несколько то их можно перечислять: 1:2
изменения вступают в силу мгоновенно
Может понадобиться ограничить доступ к текущей системе только по MAC-адресу, и не важно что какой IP адрес у разрешенной, если MAC адрес не соответствует разрешенному:
пакеты идут с разрешенной системы
$ sudo ebtables -A INPUT -s 00:E0:4C:8D:7F:E9 -j ACCEPT
пакеты идут на разрешенную систему
$ sudo ebtables -A OUTPUT -d 00:E0:4C:8D:7F:E9 -j ACCEPT
блокируем доступ к системе для всех кроме указанной системы выше:
$ sudo ebtables -P INPUT DROP
теперь если с другой системе попробовать пропинговать систему srv-mon то это станет не возможным:
PING 10.7.8.154 (10.7.8.154) 56(84) bytes of data.
— 10.7.8.154 ping statistics —
3 packets transmitted, 0 received, 100% packet loss, time 2213ms
Чтобы заблокировать все broadcast и multicast:
$ sudo ebtables -I FORWARD -d Multicast -j DROP
Но вот как быть ведь в случае перезагрузки системы настроенные правила ebtables потеряются, поэтому нужно рассмотреть, как их подгружать в систему на стадии инициализиации сетевой подсистеме, вот собственно и чему будет посвящены нижеследующие шаги:
К примеру настройка правил такая:
$ sudo ebtables -P FORWARD DROP
$ sudo ebtables -I FORWARD -d Multicast -j DROP
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: DROP
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Сохраняем таблицы брандмауера канального уровня в файлы:
На заметку : таблицы имеют названия: filter, nat and broute
$ sudo ebtables -t filter —atomic-file /etc/ebtables.forward.conf –atomic-save
Полученный файл – это бинарник и посмотреть его через текстовый редактор не удасться (возможно если использовать шестнадцатеричный)
$ sudo file /etc/ebtables.forward.conf
После добавляем в файл /etc/rc.local до строки exit 0 следующую строку:
$ sudo nano /etc/rc.local
ebtables -t filter —atomic-file /etc/ebtables.forward.conf —atomic-commit
Не забываем сохранить внесенные изменения. Теперь когда система будет перезагружена, первым делом подгрузятся настройки правил ebtables а уже потом если используется правила iptables, проверяем:
заметил, что система загружается не прям-таки и сразу как до использования bridge – возможно это так и должно быть.
И после загрузки проверив текущие правила ebtables обнаружил, что да они подгрузились из сохраненного файла. Работает.
Чтобы подсчитать трафик через ebtables:
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: DROP
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Почему значение 0 – просто сейчас система не используется.
Рассмотрю еще такой пример, разрешаем доступ к системе если отрабатываются два условия: IP = MAC, в примере выше я показывал если исполняется только одно условием c MAC’ом:
$ sudo ebtables -A INPUT -p IPv4 —ip-src 10.7.8.227 -s ‘!’ 00:E0:4C:8D:7F:E9 -j DROP
[sudo] password for ekzorchik:
$ sudo ebtables -t filter —atomic-file /etc/ebtables.forward.conf –atomic-save
Видите, как все просто да и главное это уже более низкий уровень управления системой. Таким образом использование утилит ebtables & iptables на системе Ubuntu образует связку обеспечения защиты сети на 2 и 3 уровнях модели OSI. На этом я пока завершу свое освещение возможностей bridga и ebtables. До встречи, с уважением автор блога – ekzorchik.
Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:
Поблагодари автора и новые статьи
будут появляться чаще 🙂
Карта МКБ: 4432-7300-2472-8059
Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.
Источник
