[ новости /+++ | форум | теги | ]

СОВЕТЫ (Краткие заметки, Tips) (базовая разбивка)

Администратору

Сетевая подсистема, маршрутизация

Ethernet, ARP, привязка MAC адресов.

NAT, трансляция адресов

Policy routing

PPP, PPTP, PPPOE

Wifi, настройка беспроводного доступа

Ограничение трафика

Пакетные фильтры и фаерволы

Пакетные фильтры в Linux: iptables, ipchains

Пакетный фильтр в FreeBSD: ipfw, IP-Filter

Проблемы работы сети

Туннелинг, VPN, VLAN

Сетевые сервисы

DNS

FTP, Bittorrent

INN

Mail, почта

Безопасность и установка ограничений

Борьба со спамом, фильтрация почты

Отправка и пересылка сообщений на уровне пользователя

NFS

Samba

SNMP

Socks proxy

WWW, Apache httpd

Ограничение доступа и ресурсов, безопасность

Оптимизация и тюнинг Apache

Редирект, mod_rewrite

Прокси сервер Squid

ACL, ограничения трафика и пользователей

Система

FreeBSD специфика

Сис. информация, оптимизация и тюнинг FreeBSD

Увеличение безопасности FreeBSD

Установка и апгрейд FreeBSD и приложений.

Linux специфика

Оптимизация и тюнинг в Linux

Увеличение безопасности Linux

Установка и работа с пакетами программ в Linux

OpenBSD

Solaris специфика

Syslog, ведение логов

Диски и файлы

CD-ROM, CD-R, AudioCD:

RAID массивы

Ramdisk, tmpfs

Диагностика и Восстановление после сбоя

Квоты

Монтирование

Резервное копирование

Файловые системы

Загрузка, однопользовательский режим

Кластерные технологии

Поддержка аппаратного обеспечения

Просмотр состояния и мониторинг системы

Установка и синхронизация времени

Простое устройство для защиты данных в случае кражи ноутбука (доп. ссылка 1)   [комментарии]   Майкл Олтфилт (Michael Altfield) предложил простое и эффективное устройство для блокирования доступа к конфиденциальным данным в случае кражи ноутбука с активным пользовательским сеансом. Суть метода в контроле за подключением к ноутбуку определённого USB-устройства, прикреплённого к владельцу (аналогично в качестве признака можно использовать достижимость Bluetooth смартфона владельца или метку RFID). Во время работы в общественном месте или парке на ноутбуке активируется специальное правило UDEV, которое контролирует активность подключения к USB-устройству. В случае отсоединения USB-устройства (когда злоумышленник выхватил ноутбук) UDEV-правило выполняет скрипт для завершения сеанса, удаления каталога с конфиденциальными данными, шифрования данных или отмонтирования шифрованного раздела. Пример udev-правила для блокировки экрана при извлечении любого USB-устройства: sudo vi /etc/udev/rules.d/busKill.rules ACTION=="remove", SUBSYSTEM=="usb", RUN+="DISPLAY=:0 xscreensaver-command -lock" sudo udevadm control --reload Для привязки к определённому USB-устройству необходимо узнать его идентификатор (нужно подключить устройство, запустить udevadm monitor и извлечь устройство): udevadm monitor --environment --udev ACTION=remove ID_MODEL="Micromax_A74" SUBSYSTEM=usb Модифицируем правило /etc/udev/rules.d/busKill.rules ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_MODEL}=="Micromax_A74", RUN+="DISPLAY=:0 xscreensaver-command -lock" Как вариант предложено дополнительно использовать магнитный разъединитель USB-кабеля, подключённый до брелока с ключами шифрования данных. Далее брелок подсоединяется цепочкой к одежде или руке владельца. При выдёргивании ноутбука во время работы брелок с ключами шифрования остаётся у владельца, а UDEV-скрипт экстренно выключает устройство. ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_MODEL}=="Micromax_A74", RUN+="shutdown -h now" Активировать правило блокировки можно автоматически при подключении USB-устройства, добавив UDEV-правило с обработчиком ACTION=="bind" ACTION=="bind", SUBSYSTEM=="usb", ENV{ID_MODEL}=="Micromax_A74", RUN+="/root/killcord_on.sh" /root/killcord_on.sh cat << EOF | tee /etc/udev/rules.d/busKill.rules ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_MODEL}=="Micromax_A74", RUN+="shutdown -h now" EOF udevadm control --reload   Настройка SSH для использования наиболее защищённых алгоритмов шифрования (доп. ссылка 1)   [комментарии]   В свете появления сведений об организации АНБ атак, направленных на получение контроля над SSH-соединениями, подготовлено руководство с рекомендациями по усилению защищённости SSH. АНБ может получить контроль за SSH-соединением в случае использования уязвимых методов шифрования или в результате захвата приватных ключей. Ниже представлены советы по отключению потенциально проблемных алгоритмов и усилению защиты. Обмен ключами. Применяемые в SSH методы обмена ключей DH (Diffie-Hellman) и ECDH (Elliptic Curve Diffie-Hellman) можно считать безопасными. Из 8 поддерживаемых в SSH протоколов обмена ключами вызывают подозрения три, основанные на рекомендациях NIST: ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521. Не заслуживающими полного доверия также можно считать протоколы, использующие потенциально проблемный SHA1. Протоколы curve25519-sha256 и diffie-hellman-group-exchange-sha256 пока не вызывают сомнений в безопасности. Для использования только заслуживающих доверия протоколов обмена ключами в /etc/ssh/sshd_config для сервера следует указать: KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256 Аналогичные настройки для клиента, в /etc/ssh/ssh_config: Host * KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256 В /etc/ssh/moduli можно указать (или удалить строки с размером ключа, менее 2048): ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli Аутентификация. В SSH поддерживается четыре алгоритма аутентификации по открытым ключам: DSA, ECDSA, Ed25519 и RSA. ECDSA завязан на технологиях NIST и должен быть отключен. К сожалению, если просто удалить ключ ECDSA, он будет повторно сгенерирован, поэтому можно воспользоваться обходным путём с создать заведомо нерабочую символическую ссылку, которая помешает сгенерировать и использовать ключ: cd /etc/ssh rm ssh_host_ecdsa_key* rm ssh_host_key* ln -s ssh_host_ecdsa_key ssh_host_ecdsa_key ln -s ssh_host_key ssh_host_key Так как размер ключей DSA не может превышать 1024, его тоже следует отключить тем же способом: cd /etc/ssh rm ssh_host_dsa_key* ln -s ssh_host_dsa_key ssh_host_dsa_key Далее, следует позаботиться о RSA, сгенерировав ключ большего размера: cd /etc/ssh rm ssh_host_rsa_key* ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null Для создания клиентских ключей лучше использовать команды: ssh-keygen -t ed25519 ssh-keygen -t rsa -b 4096 Симметричные шифры. Из 15 поддерживаемых в SSH алгоритмов симметричного шифрования, используемых для организации защиты установленного канала связи, безопасными можно считать chacha20-poly1305, aes*-ctr и aes*-gcm. Шифры 3des-cbc и arcfour потенциально уязвимы в силу использования DES и RC4, cast128-cbc применяет слишком короткий размер блока (64 бит). В итоге, в /etc/ssh/sshd_config рекомендуется добавить: Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr В /etc/ssh/ssh_config: Host * Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr Код аутентичности сообщения (MAC). Для шифров в режиме CTR для гарантирования целостности передаваемых блоков доверия заслуживает только метод Encrypt-then-MAC ("*-etm", MAC добавляется к уже зашифрованному блоку). Методы MAC-then-encrypt и Encrypt-and-MAC потенциально подвержены атакам. Из 18 доступных в SSH алгоритмов MAC сразу следует отбросить основанные на хэшах MD5 и SHA1, не стойких к выявлению коллизий, а также алгоритмы использующие размеры ключей менее 128 бит и размеры тегов менее 256 бит. В итоге, наиболее безопасными MAC можно считать hmac-sha2-512-etm и hmac-sha2-256-etm. В /etc/ssh/sshd_config: MACs [email protected],[email protected] В /etc/ssh/ssh_config: # Для GitHub в качестве исключения добавляем mac-sha2-512, так как он не поддерживает Encrypt-then-MAC. Host github.com MACs [email protected],[email protected],hmac-sha2-512 Host * MACs [email protected],[email protected] Защита от утечки ключей. Наиболее простым способом получения контроля за SSH-соединением является захват ключей на стороне клиента или сервера. Рекомендации сводятся к соблюдению типовых правил поддержания безопасности системы: оперативная установка обновлений, установка программ только из надёжных источников, установка только действительно необходимых программ и сервисов, использование программ для которых доступны исходные тексты, включение дополнительных механизмов защиты (Grsecurity, сборка с флагом -fstack-protector). Для защиты ключей следует выбрать надёжный пароль доступа к клиентским файлам ключей. При формировании ключа для увеличения числа итераций хэширования можно использовать опцию "ssh-keygen -o -a число", что усложнит подбор пароля. Также можно сохранить ключи только на внешнем носителе, подключая его только во время соединения по SSH. Защита от анализа транзитного трафика. SSH-сервер можно настроить в виде скрытого сервиса Tor, что скроет IP, а также добавит дополнительный слой шифрования и аутентификации. Для приема соединений только через скрытый сервис Tor можно использовать следующие настройки: В /etc/ssh/sshd_config (для приема соединений из LAN следует вместо привязки к 127.0.0.1 использовать для ограничения доступа межетевой экран): ListenAddress 127.0.0.1:22 В /etc/tor/torrc добавим: HiddenServiceDir /var/lib/tor/hidden_service/ssh HiddenServicePort 22 127.0.0.1:22 Имя скрытого хоста для подключения можно найти в файле /var/lib/tor/hidden_service/ssh/hostname. Для настройки подключения клиента к скрытому сервису Tor в /etc/ssh/ssh_config можно добавить: Host *.onion ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050   Двухфакторная аутентификация SSH с использованием YubiKey (доп. ссылка 1)   Автор: Dvenum  [комментарии]   Все началось с того, что я приобрел YubiKey и захотел использовать его для двухфакторной аутентификации SSH. Я также хотел иметь возможность восстановить доступ к серверу на случай, если потеряю ключ. Информация о том, как это сделать, слишком разрознена, поэтому я написал собственное руководство. Вещи, которые необходимо знать: * HOTP -- это алгоритм генерации одноразового пароля на основе счетчика. Счетчик меняется каждый раз, когда генерируется новый пароль. * TOTP -- алгоритм генерации пароля в зависимости от таймера, регулярно генерируется новый пароль. (30 секунд в этом случае). В результате, вы входите через SSH, видите запрос пароля и вводите пароль, предоставленный OTP, системой одноразовых паролей (one-time password) от YubiKey. Для аварийного доступа я настроил возможность аутентификации с помощью Android-приложения Google Authenticator. Я настраивал все на Debian Wheezy сервере, но это должно работать и для других похожих систем. Вам необходимо установить libpam-oath на сервере (>=1.12.4-1 или вы не сможете использовать аварийный вход). На вашем компьютере необходимо установить yubikey-personalization-gui, oathtool и libmime-base32-perl. Когда вы установите необходимые программы и библиотеки, то прежде, чем приступать к настройке, убедитесь, что у вас открыт дополнительный терминал с правами root, чтобы можно было исправить возможные ошибки. Ключ ниже указан просто для примера, вам необходимо подставить свой. Настройка YubiKey. Для начала, используем yubikey-personalisation-gui, чтобы настроить YubiKey и сгенерировать ключ. Укажите OATH-HOTP режим, отключите token идентификацию и скопируйте ключ куда-нибудь, он понадобится для настройки сервера. Не забудьте сохранить настройки в YubiKey. Создайте файл /etc/users.oath на сервере с содержанием: HOTP robin - 8a54ac40689f0bb99f306fdf186b0ef6bd153429 где robin это имя пользователя, использующего ключ, а большая шестнадцатиричная строка это ключ без пробелов, который вы сгенерировали ранее. Установите возможность читать файл только для root: # chmod 600 /etc/users.oath Измените /etc/pam.d/sshd таким образом, чтобы строка @include common-auth была раскомментирована, а после нее добавьте следующее: auth required pam_unix.so nullok_secure # OATH OTP auth required pam_oath.so usersfile=/etc/users.oath window=20 window=20 указывает, как много раз может быть нажата кнопка на YubiKey перед входом. Иными словами, как далеко в последовательности OTP модуль будет искать совпадение. Измените sshd_config, чтобы он разрешал вызов-ответ (Challenge-Response) аутентификацию. sed -i.bak -E -e 's/(ChallengeResponseAuthentication) no/\\1 yes/' /etc/ssh/sshd_config Вы можете проверить последовательность следующим образом: $ oathtool -w10 8a54ac40689f0bb99f306fdf186b0ef6bd153429 333518 886962 ... Если вы нажмете кнопку на YubiKey несколько раз, вы дожны увидеть точно такую же последовательность. Перезапустите ssh демон и все должно работать. Вам нужно ввести пароль, вы нажимаете на кнопку YubiKey. Настройка Google Authenticator Это будет аварийным входом на случай, если вы потеряете ключ. Используем здесь повременной счетчик TOTP вместо счетчика на основе последовательности. Для начала сгенерируйте случайный десятибайтовый ключ (20 символов в шестнадцатиричном виде): $ head -c 1024 /dev/urandom | openssl sha1 | tail -c 21 2c2d309a7a92e117df5a Добавьте строку в /etc/users.oath: HOTP/T30 robin - 2c2d309a7a92e117df5a T30 означает, что используется повременной алгоритм с 30-и секундной ротацией. Перед тем, как добавить этот же ключ в android приложение, мы должны представить его в base32 виде: $ perl -e 'use MIME::Base32 qw( RFC ); print lc(MIME::Base32::encode(pack("H*","2c2d309a7a92e117df5a")))."\\n";' fqwtbgt2slqrpx22 Эта команда на perl из шестнадцатиричного ключа сначала получает двоичный, который потом преобразовывает в base32. Проверить, что все работает, можно так: $ oathtool --totp -w10 2c2d309a7a92e117df5a 125557 804612 ... Последовательность должна совпадать с той, которую отдает android приложение. Поскольку алгоритм генерации основывается на времени, то разница времени на устройствах должна не превышать пары секунд. Теперь вы можете войти на сервер через повременной ключ, сгенерированный приложением или с помощью пароля, сгенерированным нажатием на кнопку YubiKey. Примечания Когда вы залогиньтесь, файл users.oath будет изменен, в него будет записано новое значение счетчика и время. Убедитесь, что файл не открыт в текстовом редакторе. Если кто-нибудь нажмет кнопку YubiKey много раз (больше двадцати для этого примера), то ключ рассинхронизируется с сервером и вам придется сбросить его, сгенерировав новый и заменив старый в users.oath. Есть еще libpam-google-authenticator, который ведет себя похожим образом, но недоступен для Debian Wheezy. Если у вас много сервереров и вы хотите использовать один YubiKey для всех, то вам потребуется что-нибудь вроде центрального сервера аутентификации, чтобы избежать рассинхронизации ключей.   Поиск "проблемных" бинарников в системе   Автор: Карбофос  [комментарии]   Если в системе по каким-то причинам есть бинарные файлы, а нет внешних библиотек к ним, то этот скрипт поможет достаточно просто найти такие файлы: #!/bin/bash # скрипт для поиска проблемных файлов # список директорий для поиска directory=("/usr/bin/" "/usr/sbin/" "/bin/" "/usr/lib/" "/usr/lib64/") toreplace="=> not found" # Loop through our array. for x in ${directory[@]} do # Find all Files # for i in $(find $x -type f -executable) for i in $(find $x -type f) do # если ldd выдает ошибку "not found".. n=`ldd "$i" | grep found 2>/dev/null` if [ -n "$n" ]; then # echo $i " not found lib: " $n # с небольшой корректировкой, выкидываем "=> not found" echo "$i not found lib(s): $n" | sed "s/$toreplace//g" fi done done   Доступ к файлам виртуальных машин VMware ESX из Fedora Linux (доп. ссылка 1)   Автор: Andrey Markelov  [обсудить]   Richard W.M. Jones в своем блоге опубликовал интересный пост (http://rwmj.wordpress.com/2010/01/06/examine-vmware-esx-with-libguestfs/) о работе при помощи утилит libguestfs с образами VMware ESX4. Немного дополнив, напишу, в чем суть. Во-первых нам понадобятся пакеты fuse-sshfs и guestfish. Первый позволяет монтировать при помощи FUSE удаленную файловую систему по SSH FTP, а второй установит в систему интерактивную командную оболочку, из которой можно получать доступ к образам дисков виртуальных машин, в том числе и vmdk. Естественно, в системе должны присутствовать стандартные компоненты виртуализации Fedora, в частности, работающий демон libvirtd. Для начала проверяем, какие присутствуют на хосте ESX виртуальные машины: $ virsh -c esx://192.168.1.12?no_verify=1 list --all Enter username for 192.168.1.12 [root]: Enter root password for 192.168.1.12: ID Имя Статус ---------------------------------- 208 www выполнение 224 mail выполнение - 2RHEL5_DS отключить - 2W2003_DC отключить - RHEL5_IPA отключить - RHEL5_Satellite53 отключить - RHEL5_Server1 отключить - RHEL5_Station отключить - RHEL5_Station2 отключить - RHEL5_Zimbra отключить Далее смонтируем через FUSE соответствующую директорию файловой системы vmfs: $ mkdir esx $ sshfs [email protected]:/vmfs/volumes esx [email protected]'s password: $ cd esx/ $ ls 4ac343f6-500e2828-d805-0022640793d2 LocalStorage1 Естественно, мы ничего нового по сравнению с тем, что нам покажет vCenter client, не увидели. Далее переходим в директорию с нужной нам виртуальной машиной: $ cd LocalStorage1/RHEL5_IPA/ $ ls RHEL5_IPA-flat.vmdk RHEL5_IPA.vmdk RHEL5_IPA.vmx vmware.log RHEL5_IPA.nvram RHEL5_IPA.vmsd RHEL5_IPA.vmxf При помощи новой утилиты virt-list-filesystems (в версии libguestfs репозитория Fedora 12 пока ее нет, зато есть в Rawhide) смотрим какие разделы доступны внутри образа: $ virt-list-filesystems -al RHEL5_IPA-flat.vmdk /dev/sda1 ext3 /dev/vol0/home ext3 /dev/vol0/root ext3 /dev/sda3 swap И, наконец, запускаем интерактивную командную оболочку: $ guestfish --ro -a RHEL5_IPA-flat.vmdk -m /dev/vol0/root Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help with commands 'quit' to quit the shell > ll / total 192 drwxr-xr-x. 22 root root 4096 Oct 24 07:47 . dr-xr-xr-x 29 root root 0 Jan 8 12:59 .. drwxr-xr-x. 2 root root 4096 Oct 7 15:07 bin drwxr-xr-x. 2 root root 4096 Oct 7 13:45 boot drwxr-xr-x. 4 root root 4096 Oct 7 13:45 dev drwxr-xr-x. 93 root root 12288 Oct 24 07:47 etc drwxr-xr-x. 2 root root 4096 Oct 7 13:45 home .... Ну, а дальше man guestfish и help для списка команд оболочки. Для виртуальных машин с включенным SELinux крайне желательно использовать ключ --selinux, иначе при попытке записи файлов вы можете создать при монтировании образа r/w файлы без меток SELinux.   Быстрый способ учета трафика на сетевых интерфейсах (доп. ссылка 1)   Автор: Gleb Poljakov  [комментарии]   Дано: Почтовый сервер на базе Ubuntu 8.10 Четыре сетевых интерфейса Необходимо: Считать трафик на каждом интерфейсе, вести статистику. Решение: vnstat (http://humdi.net/vnstat/) - маленький консольный пакет, который считает трафик на указанных интерфейсах и не загружает систему. Показывает статистику по часам, дням неделям и тд. Не требует для своей работы привилегий суперпользователя, поддерживает Linux, *BSD и Darwin/MacOS X. Для доступа к статистике дополнительно доступен web-интерфейс. Устанавливаем vnstat: #apt-get install vnstat Инициализируем базу данных для каждого необходимого интерфейса: #vnstat -u -i eth0 #vnstat -u -i eth1 #vnstat -u -i eth2 Далее необходимо сказать vnstat запустить мониторинг интерфейса. Это можно сделать путем ifdown/ifup для каждого интерфейса, либо, если нет желания разрывать соединения выполнить для каждого: #IFACE=eth${i} #export IFACE #/bin/sh -x /etc/network/if-up.d/vnstat где ${i} порядковый номер интерфейса. Все, мониторинг готов, теперь по прошествии нескольких минут можно смотреть статистику #vnstat -q   Клонирование дисков во FreeBSD, используя снапшоты ФС   [комментарии]   Создаем снапшот test1 раздела /home mount -v -u -o snapshot /home/snapshot/test1 /home или другой метод: mksnap_ffs /home /home/snapshot/test1 Привязываем снапшот к устройству /dev/md1: mdconfig -a -t vnode -f /home/snapshot/test1 -u 1 При необходимости снапшот можно смонтировать и посмотреть его содержимое: mount -o ro /dev/md1 /mnt .... umount /mnt Копируем содержимое раздела на второй диск: dd if=/dev/md1 of=/dev/ad4s1f bs=16k Отключаем снапшот mdconfig -d -u 1 Выполняем fsck на новом разделе: fsck -f /dev/ad4s1f   Как избавиться от нечитаемых секторов на диске   [комментарии]   В логе smartd появились подобные свидетельства наличия нечитаемых секторов на диске: smartd[798]: Device: /dev/ad5, 15 Currently unreadable (pending) sectors smartd[798]: Device: /dev/ad5, 15 Offline uncorrectable sectors SMART тестирование подтвердило подозрения: Запускаем фоновый тест диска, не мешающий основной работе: smartctl -t long /dev/ad5 Ждем завершения периодически просматривая статус: smartctl -l selftest /dev/ad5 В итоге смотрим содержимое лога, в самом конце вывода: smartctl -a /dev/ad5 Имеем: # 1 Extended offline Completed: read failure 90% 2916 10373954 Выявляем полный список сбойных секторов, путем чтения всех данных с диска: dd if=/dev/ad5 of=/dev/null bs=512 conv=noerror,sync В один прекрасный момент появятся надписи вида: dd: /dev/ad5: Input/output error 10373954+0 records in 10373954+0 records out 5311464448 bytes transferred in 2427.397393 secs (2188131 bytes/sec) В системном логе увидим: kernel: ad5: TIMEOUT - READ_DMA retrying (1 retry left) LBA=10373954 kernel: ad5: TIMEOUT - READ_DMA retrying (0 retries left) LBA=10373954 .... kernel: ad5: FAILURE - READ_DMA timed out LBA=10374109 kernel: ad5: TIMEOUT - READ_DMA retrying (1 retry left) LBA=10374113 Проверяем, каждый участок еще раз: dd if=/dev/ad5 of=/dev/null bs=512 count=1 skip=10373954 conv=noerror,sync Смотрим какой файл в ФС подпадает под этот блок. Смотрим и примерно вычисляем номер раздела на который приходится сбойный сектор (LBA 10373954): fdisk -s /dev/ad5 /dev/ad5: 775221 cyl 16 hd 63 sec Part Start Size Type Flags 1: 63 398444067 0xa5 0x80 2: 398444130 382973535 0xa5 0x80 10373954 - 63 = 10373891 disklabel /dev/ad5s1 # /dev/ad5s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 2048 16384 28552 b: 4194304 2097152 swap c: 398444067 0 unused 0 0 # "raw" part d: 2097152 6291456 4.2BSD 2048 16384 28552 e: 10485760 8388608 4.2BSD 2048 16384 28552 f: 104857600 18874368 4.2BSD 2048 16384 28552 g: 104857600 123731968 4.2BSD 2048 16384 28552 h: 162127234 228589568 4.2BSD 2048 16384 28552 Видим, что 10373891 приходится на раздел /dev/ad5s1e Расчитываем смещение относительно начала раздела: 10373891 - 8388608 = 1985283 Находим иноду, которой принадлежит заданный блок: fsdb -r /dev/ad5s1e findblk 1985283 повторяем для каждого сбойного сектора (для Linux нужно использовать debugfs - http://smartmontools.sourceforge.net/BadBlockHowTo.txt) Пытаемся записать данные в сбойный сектор, чтобы инициировать процесс ремапинга на диске. sysctl kern.geom.debugflags=16 # иначе будет dd: /dev/ad5: Operation not permitted) dd if=/dev/zero of=/dev/ad5 bs=512 count=1 skip=10373954 conv=noerror,sync sysctl kern.geom.debugflags=0 Если после записи сектор начал читаться - все ok, если нет - резервная область на диске уже заполнена, пробуем запретить обращещние окружающих секторов в ФС: man badsect /dev/ad5s1e примонтирован как /usr, создаем директорию /usr/BAD и выполняем badsect /usr/BAD 1985283 fsck -y /dev/ad5s1e Полезные порты: /usr/ports/sysutils/recoverdm /usr/ports/sysutils/diskcheckd   Почему на нагруженных серверах лучше использовать SCSI диски, а не IDE.   [комментарии]   1. Качество исполнения, запас прочности и надежность накопителей со SCSI интерфейсом как правило выше, чем у IDE. 2. Два подключенных к одному каналу контроллера IDE накопителя, не могут одновременно передавать данные по шине. 3. SCSI показывают значительно лучшую производительность в загруженной многозадачной среде, при обилии разрозненных параллельных запросов за счет более оптимального использования шины передачи данных. (конек IDE - линейное чтение, сильная сторона SCSI - случайный доступ). Поясняю: Специфика IDE такова, что запросы могут передаваться по одной шине последовательно (одна труба передачи данных, однопоточный режим). Допустим, если 100 процессов обращаются к данным на диске, запросы в рамках одного канала контроллера будут обрабатываться один за другим, каждый следующий после полного выполнения предыдущего (связка: выдача команды - получение данных). При использовании SCSI, допускается перекрытие запросов (организуется очередь команд), ответы при этом будут получены распараллеленно (асинхронная передача), при этом устройство заведомо зная подробности по командам находящимся в очереди, производит оптимизацию самостоятельно - минимизируя движение головок.   expect для автоматизации операций требующих ручного ввода   [комментарии]   #!/usr/bin/expect -f # Забор файла по FTP spawn ftp ftp.test.ru expect "Name*:" { send "ftp\n"} expect "Password:" { send "ftp@\n"} expect "ftp>" {send "bin\n"} expect "ftp>" {send "prompt no\n"} expect "ftp>" {send "cd /pub/store\n"} expect "ftp>" {send "get arc.tar.gz\n"} expect "ftp>" {send "exit\n"} #!/usr/bin/expect -f # Выполнение операции используя telnet spawn telnet cisco.test.ru expect "login:" { send "adm\n"} expect "Password:" { send "пароль\n"} expect "#" {send "show users\n"} expect "#" {send "exit\n"}

Сетевая подсистема, маршрутизация

Ethernet, ARP, привязка MAC адресов.

NAT, трансляция адресов

Policy routing

PPP, PPTP, PPPOE

Wifi, настройка беспроводного доступа

Ограничение трафика

Пакетные фильтры и фаерволы

Пакетные фильтры в Linux: iptables, ipchains

Пакетный фильтр в FreeBSD: ipfw, IP-Filter

Проблемы работы сети

Туннелинг, VPN, VLAN

Часто используемые параметры sysctl, касающиеся настройки сети в Linux (доп. ссылка 1)   Автор: zersh  [комментарии]   От переводчика (@zersh). Это адаптированный перевод работы https://github.com/leandromoreira/linux-network-performance-parameters Для понимания некоторых моментов использовалась статья. Принимаются любые замечания и предложения. Спасибо zizmo и @servers(Artem) - за помощь и конструктивную критику) Лицензия: BSD-3 Введение Иногда люди пытаются найти некие универсальные значения параметров sysctl (https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt), применение которых во всех случаях позволит добиться и высокой пропускной способности, и низкой задержки при обработке сетевых запросов. К сожалению, это не возможно, хотя стоит отметить, что современные версии ядер по умолчанию уже неплохо настроены. Важно понимать, что изменение заданных по умолчанию настроек может ухудшить производительность (https://medium.com/@duhroach/the-bandwidth-delay-problem-c6a2a578b211). Это краткое руководство, в котором приведены часто используемые параметры sysctl, касающиеся настройки сети Linux, вдохновлённый иллюстрированным руководством по сетевому стеку Linux (https://blog.packagecloud.io/eng/2016/10/11/monitoring-tuning-linux-networking-stack-receiving-data-illustrated/) и многими постами Marek Majkowski (https://blog.cloudflare.com/how-to-achieve-low-latency/). Обзор сетевых очередей Linux Связь переменных sysctl с различными стадиями обработки сетевых потоков в Linux Входящие пакеты (Ingress) 1. Пакеты прибывают в NIC (сетевой адаптер) 2. NIC проверяет `MAC` (если не включён promiscuous-режим) и `FCS (Frame check sequence)` и принимает решение отбросить пакет или продолжить обработку. 3. NIC используя DMA (https://en.wikipedia.org/wiki/Direct_memory_access), помещает пакеты в RAM регионе, ранее подготовленном (mapped) драйвером. 4. NIC ставит ссылки в очередь на пакеты при получении ring buffer (https://en.wikipedia.org/wiki/Circular_buffer) очередь `rx` до истечения таймаута `rx-usecs` или `rx-frames` 5. NIC Генерируется аппаратное прерывание, чтобы система узнала о появлении пакета в памяти `hard IRQ` 6. CPU запустит `IRQ handler`, который запускает код драйвера 7. Драйвер вызовет `планировщик NAPI`, очистит `hard IRQ` 8. Драйвер будит подсистему NAPI с помощью `soft IRQ (NET_RX_SOFTIRQ)` 9. NAPI опрашивает данные, полученные из кольцевого буфера до тех пор пока не истечёт таймаут `netdev_budget_usecs`, или `netdev_budget` и `dev_weight` пакета 10. Linux также выделяет память для `sk_buff` 11. Linux заполняет метаданные: протокол, интерфейс, устанавливает MAC-адрес (setmacheader), удаляет ethernet 12. Linux передаёт skb (данные) в стэк ядра (`netif_receive_skb`) 13. Установит сетевые заголовки, клонирует `skb` ловушкам (вроде tcpdump) и передаст на вход 14. Пакеты обрабатываются в qdisc (Queueing discipline) размера `netdev_max_backlog`, алгоритм которого определяется `default_qdisc` 15. Вызывает `ip_rcv` и пакеты обрабатываются в IP 16. Вызывает netfilter (`PREROUTING`) 17. Проверяет маршрутизацию, кому предназначен пакет: переслать (forwarding) или локально (local) 18. Если локально, вызывает netfilter (`LOCAL_IN`) 19. Это вызовет протокол L4 (для примера `tcp_v4_rcv`) 20. Находит нужный сокет 21. Переходит на конечный автомат tcp (finite state machine). 22. Поставит пакет в входящий буфер, размер которого определяется правилами `tcp_rmem`. Если `tcp_moderate_rcvbuf` включён, ядро будет автоматически тюнить буфер приёма (receive) 23. Ядро сигнализирует приложению, что доступны данные (epoll или другая polling-система) 24. Приложение просыпается и читает данные Исходящие пакеты (Egress) 1. Приложение отправляет сообщение (`sendmsg` или другие) 2. TCP-стек выделяет память для skb_buff 3. Помещает skb в сокет буфера, размером `tcp_wmem` 4. Создаст TCP заголовки (источник и порт назначения, контрольная сумма) 5. Вызывает обработчик L3 (в данном случае `ipv4` в `tcp_write_xmit` и `tcp_transmit_skb`) 6. L3 (`ip_queue_xmit`) построит заголовок IP и вызовет netfilter (`LOCAL_OUT`) 7. Вызывает действие выходного маршрута (Calls output route action) 8. Вызывает netfilter (`POST_ROUTING`) 9. Фрагментирует пакет (`ip_output`) 10. Вызывает функции отправки L2 (`dev_queue_xmit`) 11. Подаёт на выход (QDisc) очередь длинной `txqueuelen` с алгоритмом `default_qdisc` 12. Код драйвера помещает пакеты в `ring buffer tx` 13. Драйвер генерирует `soft IRQ (NET_TX_SOFTIRQ)` после `tx-usecs` таймаута или `tx-frames` 14. Реактивирует аппаратное прерывание (IRQ) в NIC 15. Драйвер отражает (map) все пакеты (для отправки) в некоторую область DMA 16. NIC получит пакеты (через DMA) из RAM для передачи 17. После передачи NIC поднимет сигнал `hard IRQ` о его завершении 18. Драйвер обработает это прерывание IRQ (выключает) 19. И планирует (`soft IRQ`) NAPI poll system 20. NAPI будет обрабатывать сигналы приёма пакетов и освобождать ОЗУ Для отслеживания обработки событий, связанных с выполнением сетевой операции, можно использовать команду: perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null Что, Почему и Как - сеть и sysctl параметры Кольцевой буфер (Ring Buffer) - rx, tx Что: драйвер очереди приёма/отправки одной или нескольких очередей с фиксированным размером, обычно реализованный как FIFO, находится в ОЗУ Почему: буфер для плавного прима соединений без их отбрасывания. Возможно, вам понадобится увеличить эти очереди, когда вы увидите сбросы (drops) или переполнения, то есть, если поступает больше пакетов, чем ядро может обработать. Побочным эффектом от увеличения буфера может стать увеличение задержки. Как: Команда проверки: ethtool -g ethX Как изменить: ethtool -G ethX rx значение tx значение Как мониторить: ethtool -S ethX | grep -e "err" -e "drop" -e "over" -e "miss" -e "timeout" -e "reset" -e "restar" -e "collis" -e "over" | grep -v "\: 0" Слияние прерываний (Interrupt Coalescence - IC) - rx-usecs, tx-usecs, rx-frames, tx-frames (аппаратные IRQ) Что: количество микросекунд / кадров, ожидающих перед поднятием hard IRQ, с точки зрения сетевого адаптера это будет пакеты данных DMA до этого тайм-аута / количества кадров Почему: сокращение использования CPUs, аппаратных IRQ, может увеличить пропускную способность за счет задержки. Как: Команда проверки: ethtool -c ethX Как изменить: ethtool -C ethX rx-usecs value tx-usecs value Как мониторить: cat /proc/interrupts Объединение прерываний (soft IRQ) и управления сетевыми очередями QDisc входящих пакетов (ingress). Что: максимальное число микросекунд в одном NAPI (https://en.wikipedia.org/wiki/New_API) цикле опроса. Опрос завершится когда, либо `netdev_budget_usecs` истечёт по временя цикла опроса или количество обработанных пакетов достигнет `netdev_budget`. Почему: вместо того чтобы обрабатывать кучу softIRQ, драйвер сохраняет данные в пуле (polling data); следите за состояниями `dropped` (число пакетов, отброшенных из-за того, что `netdev_max_backlog` был превышен) и `squeezed` (число раз когда ksoftirq превысил `netdev_budget`). Как: Команда проверки: sysctl net.core.netdev_budget_usecs Как изменить: sysctl -w net.core.netdev_budget_usecs value Как мониторить: cat /proc/net/softnet_stat или скриптом. Что: `netdev_budget` максимальное количество пакетов, взятых со всех интерфейсов за один цикл опроса (NAPI poll). В одном цикле опроса интерфейсы, которые зарегистрированы для опроса, зондируются круговым способом. Кроме того, цикл опроса не может превышать `netdev_budget_usecs` микросекунд, даже если `netdev_budget` не был исчерпан. Как: Команда проверки: sysctl net.core.netdev_budget Как изменить: sysctl -w net.core.netdev_budget value Как мониторить: cat /proc/net/softnet_stat или скриптом. Что: `dev_weight` максимальное количество пакетов, которое ядро может обработать при прерывании NAPI, это переменная для каждого процессора. Для драйверов, которые поддерживают LRO или GRO_HW, аппаратно агрегированный пакет считается в этом пакете одним. Как: Команда проверки: sysctl net.core.dev_weight Как изменить: sysctl -w net.core.dev_weight value Как мониторить: cat /proc/net/softnet_stat или скриптом. Что: `netdev_max_backlog` максимальное количество пакетов, находящихся в очереди на стороне INPUT (входной qdisc_), когда интерфейс получает пакеты быстрее, чем ядро может их обработать. Как: Команда проверки: sysctl net.core.netdev_max_backlog Как изменить: sysctl -w net.core.netdev_max_backlog value Как мониторить: cat /proc/net/softnet_stat или скриптом. Исходящие QDisc - txqueuelen (длина очереди tx) и default_qdisc Что: `txqueuelen` максимальное количество пакетов, поставленных в очередь на стороне вывода. Почему: buffer/queue появление разрывов соединений, а также примением контроля трафика tc (traffic control). Как: Команда проверки: ifconfig ethX Как изменить: ifconfig ethX txqueuelen value Как мониторить: ip -s link Что: `default_qdisc` дисциплина очереди по умолчанию, используемая для сетевых устройств. Почему: Каждое приложение имеет разную нагрузку и требует контроля трафика, оно также используется для борьбы с излишней сетевой буферизацией bufferbloat. Как: Команда проверки: sysctl net.core.default_qdisc Как изменить: sysctl -w net.core.default_qdisc value Как мониторить: tc -s qdisc ls dev ethX Буферы/очереди чтения и записи (TCP Read and Write Buffers/Queues) Что: `tcp_rmem` - min (минимальный размер доступный при создании сокета), default (начальный размер), max (максимальный размер) - максимальный размер приёмного буфера TCP. Почему: буфер/очередь приложения для записи/отправки данных. Понять последствия может помочь статья https://blog.cloudflare.com/the-story-of-one-latency-spike/ Как: Команда проверки: sysctl net.ipv4.tcp_rmem Как изменить: sysctl -w net.ipv4.tcp_rmem="min default max" когда меняете значение по умолчанию, не забудьте перезагрузить приложения в пользовательском окружении (т.е. ваш веб-сервер, nginx, и т.п.) Как мониторить: cat /proc/net/sockstat Что: `tcp_wmem` - min (минимальный размер доступный при создании сокета), default (начальный размер), max (максимальный размер) - размер буфера отправки, используемого сокетами TCP. Как: Команда проверки: sysctl net.ipv4.tcp_wmem Как изменить: sysctl -w net.ipv4.tcp_wmem="min default max" когда меняете значение по умолчанию, не забудьте перезагрузить приложения в пользовательском окружении (т.е. ваш веб-сервер, nginx, и т.п.) Как мониторить: cat /proc/net/sockstat Что: `tcp_moderate_rcvbuf` - если установлено, TCP выполняет автонастройку приёмного буфера, пытаясь автоматически определить размер буфера. Как: Команда проверки: sysctl net.ipv4.tcp_moderate_rcvbuf Как изменить: sysctl -w net.ipv4.tcp_moderate_rcvbuf value Как мониторить: cat /proc/net/sockstat TCP FSM и алгоритм перегрузки (Honorable mentions - TCP FSM and congestion algorithm) `sysctl net.core.somaxconn` - обеспечивает верхний предел значения параметра backlog, передаваемого в функцию `listen()` (https://eklitzke.org/how-tcp-sockets-work), известный пользователям как `SOMAXCONN`. Если вы меняете это значение, вы также должны изменить в своём приложении совместимые значения (т.е. nginx backlog). `cat /proc/sys/net/ipv4/tcp_fin_timeout` - указывает количество секунд ожидания окончательного пакета FIN, прежде чем сокет будет принудительно закрыт. Это строго является нарушением спецификации TCP, но требуется для предотвращения атак типа "отказ в обслуживании". `cat /proc/sys/net/ipv4/tcp_available_congestion_control` - показывает доступные варианты управления перегрузкой, которые зарегистрированы. `cat /proc/sys/net/ipv4/tcp_congestion_control` - устанавливает алгоритм управления перегрузкой, используемое для новых соединений. `cat /proc/sys/net/ipv4/tcp_max_syn_backlog` - задаёт максимальное число запросов подключения в очереди, которые еще не получили подтверждения от подключающегося клиента; если это число будет превышено, ядро начнёт отбрасывать запросы. `cat /proc/sys/net/ipv4/tcp_syncookies` - включён/выключен [syn cookies](https://en.wikipedia.org/wiki/SYN_cookies), полезен для защиты от syn flood атак (https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/). `cat /proc/sys/net/ipv4/tcp_slow_start_after_idle` - включён/выключен медленный старт tcp. Как мониторить: общая сводка netstat -atn | awk '/tcp/ {print $6}' | sort | uniq -c счётчики по определённому состоянию: `established`, `syn-sent`, `syn-recv`, `fin-wait-1`, `fin-wait-2`, `time-wait`, `closed`, `close-wait`, `last-ack`, `listening`, `closing`: ss -neopt state time-wait | wc -l` tcp статистика netstat -st более читаемая tcp статистика nstat -a обобщённая статистика сокетов cat /proc/net/sockstat детальная статистика, описание полей смотрите: https://www.kernel.org/doc/Documentation/networking/proc_net_tcp.txt cat /proc/net/tcp `ListenOverflows` и `ListenDrops` - важные поля для наблюдения cat /proc/net/netstat читаемый вариант /proc/net/netstat (https://sa-chernomor.livejournal.com/9858.html) cat /proc/net/netstat | awk '(f==0) { i=1; while ( i<=NF) {n[i] = $i; i++ }; f=1; next} \ (f==1){ i=2; while ( i<=NF){ printf "%s = %d\n", n[i], $i; i++}; f=0} ' | grep -v "= 0 Источник: https://commons.wikimedia.or/wiki/File:Tcp_state_diagram_fixed_new.svg Сетевые утилиты для тестирования и мониторинга iperf3 (https://iperf.fr/) - пропускная способность сети vegeta (https://github.com/tsenart/vegeta) - нагрузочное тестирование HTTP netdata (https://github.com/firehol/netdata) - система распределённого мониторинга производительности и работоспособности в реальном времени Рекомендации https://www.kernel.org/doc/Documentation/sysctl/net.txt https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt https://www.kernel.org/doc/Documentation/networking/scaling.txt https://www.kernel.org/doc/Documentation/networking/proc_net_tcp.txt https://www.kernel.org/doc/Documentation/networking/multiqueue.txt http://man7.org/linux/man-pages/man7/tcp.7.html http://man7.org/linux/man-pages/man8/tc.8.html http://www.ece.virginia.edu/cheetah/documents/papers/TCPlinux.pdf https://netdevconf.org/1.2/papers/bbr-netdev-1.2.new.new.pdf https://blog.cloudflare.com/how-to-receive-a-million-packets/ https://blog.cloudflare.com/how-to-achieve-low-latency/ https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/ https://www.youtube.com/watch?v=6Fl1rsxk4JQ https://oxnz.github.io/2016/05/03/performance-tuning-networking/ https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/xl710-x710-performance-tuning-linux-guide.pdf https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf https://medium.com/@matteocroce/linux-and-freebsd-networking-cbadcdb15ddd https://blogs.technet.microsoft.com/networking/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them/ https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/multi-core-processor-based-linux-paper.pdf http://syuu.dokukino.com/2013/05/linux-kernel-features-for-high-speed.html https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/ https://software.intel.com/en-us/articles/setting-up-intel-ethernet-flow-director https://courses.engr.illinois.edu/cs423/sp2014/Lectures/LinuxDriver.pdf https://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ http://vger.kernel.org/~davem/skb.html https://www.missoulapubliclibrary.org/ftp/LinuxJournal/LJ13-07.pdf https://opensourceforu.com/2016/10/network-performance-monitoring/ https://www.yumpu.com/en/document/view/55400902/an-adventure-of-analysis-and-optimisation-of-the-linux-networking-stack https://lwn.net/Articles/616241/ https://medium.com/@duhroach/tools-to-profile-networking-performance-3141870d5233 https://www.lmax.com/blog/staff-blogs/2016/05/06/navigating-linux-kernel-network-stack-receive-path/ https://es.net/host-tuning/100g-tuning/ http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html https://people.cs.clemson.edu/~westall/853/tcpperf.pdf http://tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html https://es.net/assets/Papers-and-Publications/100G-Tuning-TechEx2016.tierney.pdf https://www.kernel.org/doc/ols/2009/ols2009-pages-169-184.pdf https://devcentral.f5.com/articles/the-send-buffer-in-depth-21845 http://packetbomb.com/understanding-throughput-and-tcp-windows/ https://www.speedguide.net/bdp.php https://www.switch.ch/network/tools/tcp_throughput/ https://www.ibm.com/support/knowledgecenter/en/SSQPD3_2.6.0/com.ibm.wllm.doc/usingethtoolrates.html https://blog.tsunanet.net/2011/03/out-of-socket-memory.html https://unix.stackexchange.com/questions/12985/how-to-check-rx-ring-max-backlog-and-max-syn-backlog-size https://serverfault.com/questions/498245/how-to-reduce-number-of-time-wait-processes https://unix.stackexchange.com/questions/419518/how-to-tell-how-much-memory-tcp-buffers-are-actually-using https://eklitzke.org/how-tcp-sockets-work https://www.linux.com/learn/intro-to-linux/2017/7/introduction-ss-command https://staaldraad.github.io/2017/12/20/netstat-without-netstat/ https://loicpefferkorn.net/2016/03/linux-network-metrics-why-you-should-use-nstat-instead-of-netstat/ http://assimilationsystems.com/2015/12/29/bufferbloat-network-best-practice/   Актуальность опции TCP_NODELAY для распределённых приложений (доп. ссылка 1)   [комментарии]   Один из инженеров Amazon Web Services (AWS) разобрал заблуждения, связанные с повышением эффективности передачи мелких сообщений при использовании алгоритма Нейгла, применяемого по умолчанию в TCP/IP стеке. Рекомендации сводятся к отключению по умолчанию алгоритма Нейгла через выставление опции TCP_NODELAY для сетевых сокетов при помощи вызова setsockopt. setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one)); Алгоритм Нейгла позволяет агрегировать мелкие сообщения для снижения трафика - приостанавливает отправку новых сегментов TCP до получения подтверждения о приёме ранее отправленных данных. Например, без применения агрегирования при отправке 1 байта, дополнительно отправляется 40 байтов с заголовками пакета. В современных условиях использование алгоритма Нейгла приводит к заметному возрастанию задержек, неприемлемых для интерактивных и распределённых приложений. Приводится три основных довода в пользу использования по умолчанию опции TCP_NODELAY, отключающей алгоритм Нейгла: 1. Несовместимость алгоритма Нейгла с оптимизацией "delayed ACK", при которой ACK-ответ направляется не сразу, а после получения ответных данных. Проблема в том, что в алгоритме Нейгла поступление ACK-пакета является сигналом для отправки агрегированных данных, а если ACK-пакет не поступил, отправка выполняется при наступлении таймаута. Таким образом, возникает замкнутый круг и ACK-пакет как сигнал не работает, так как другая сторона не получает данные из-за их накопления на стороне отправителя, а отправитель не отправляет их до таймаута, так как не получает ACK-пакет. 2. RFC для алгоритма Нейгла принят в 1984 году и он не рассчитан на параметры современных высокоскоростных сетей и серверов в датацентрах, что приводит к возникновению проблем с отзывчивостью. Задержка между отправкой запроса и получением ответа (RTT) в современных сетях составляет 0.5 мс + несколько миллисекунд при обмене данными между датацентрами в одном регионе + до сотни миллисекунд при отправке по всему миру. За эти миллисекунды современный сервер способен выполнить огромный объём работы. 3. Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения. Даже если размер полезных данных составляет 1 байт, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.   Диапазоны IP-адресов облачных сервисов Amazon, Google, OVH, DigitalOcean и Microsoft (доп. ссылка 1)   [комментарии]   Иногда на сервере возникает необходимость динамического определения подключения пользователя, транзитно использующего окружение в одном из арендуемых облачных сервисов. Проект cloud-ranges поддерживает актуальную БД диапазонов адресов различных облачных операторов, которую можно загрузить со страницы https://github.com/pry0cc/cloud-ranges/tree/master/companies Также могут оказаться полезными база IP в привязке к странам: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz и базы адресов выходных узлов Tor: https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=IP_текущего хоста https://www.dan.me.uk/torlist/ https://torstatus.rueckgr.at/ip_list_all.php/Tor_ip_list_ALL.csv https://raw.githubusercontent.com/Machou/tor-ip-list/master/Tor_ip_list_ALL.csv Преобразовать указанные списки для mod_geo или mod_geo2 можно простым скриптом, например, curl https://raw.githubusercontent.com/Machou/tor-ip-list/master/Tor_ip_list_ALL.csv https://torstatus.rueckgr.at/ip_list_all.php/Tor_ip_list_ALL.csv | sort| uniq | grep -v "^#" |grep -E '^[0-9]+\.[0-9]+\.[0-9]+' | sed 's/$/ TT/' > /etc/httpd/conf/tor_db.txt После включения mod_geo2 в Apache LoadModule geo2_module /usr/lib64/httpd/modules/mod_geo2.so <IfModule geo2_module> GEOTable /etc/httpd/conf/tor_db.txt GEOActive Off </IfModule> в скриптах можно узнавать факт подключения через облачных провайдеров или Tor анализируя переменную окружения "HTTP_IP_GEO" (в примере выше для адресов Tor будет выставляться значение "TT").   Домашний шлюз на Raspberry Pi   Автор: Павел Самсонов  [комментарии]   Нам понадобится: Raspberry Pi (у меня Raspberry Pi 1 модель B), вторая сетевая карта с интерфейсом USB (например, DLink DUB-E100) и SD карта с записанным образом Raspbian. Сразу скажу, что в Raspbian Wheezy ядро собрано без опций CONFIG_NETFILTER_XT_TARGET_TCPMSS=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=y и будут проблемы с некоторыми сайтами. Придется позже пересобрать ядро с этими опциями. Итак, установим пакеты: sudo apt-get install ntp # Нам нужно точное время sudo update-rc.d ntp enable sudo service ntp start sudo apt-get install dnsmasq # Роутер будет резолвером DNS для локальной сети sudo update-rc.d dnsmasq enable sudo apt-get dnsmasq start Настроим локальную сеть, для этого отредактируем файл /etc/network/interfaces: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.4.1 netmask 255.255.255.0 У нас eth0 - локальная сеть, eth1 (DLink) будет для Internet. Теперь установим пакеты для pppoe: sudo apt-get install pppoe pppoeconf Настроим интернет соединение pppoe с помощью мастера pppoeconf: sudo pppoeconf Теперь осталось настроить firewall. Во-первых включим маршрутизацию: отредактируем файл /etc/sysctl.conf и установим в нем net.ipv4.ip_forward=1 и выполним sudo sysctl net.ipv4.ip_forward=1 Возьмем за основу firewall файл /etc/firewall: # Generated by iptables-save v1.4.14 on Thu Sep 15 16:51:15 2016 *nat :PREROUTING ACCEPT [1:32] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [2:307] :POSTROUTING ACCEPT [1:240] -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT # Completed on Thu Sep 15 16:51:15 2016 # Generated by iptables-save v1.4.14 on Thu Sep 15 16:51:15 2016 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :TINYWALL-FORWARD - [0:0] :TINYWALL-INPUT - [0:0] :TINYWALL-OUTPUT - [0:0] -A INPUT -m state --state INVALID -j LOG --log-prefix "CHAIN=TINYWALL-INVALID-INPUT -A INPUT -m state --state INVALID -j DROP -A INPUT -m state --state NEW -j LOG --log-prefix "CHAIN=TINYWALL-NEW-INPUT " #Это необязательная строка -A INPUT -p icmp -j ACCEPT -A INPUT -s 192.168.4.0/24 -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT -A INPUT -s 127.0.0.1/32 -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT -A INPUT -s 192.168.4.0/24 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -j TINYWALL-INPUT -A INPUT -j LOG --log-prefix "CHAIN=TINYWALL-INPUT-REJECT " -A INPUT -j REJECT --reject-with icmp-admin-prohibited -A FORWARD -m state --state INVALID -j LOG --log-prefix "CHAIN=TINYWALL-INVALID-FORW " -A FORWARD -m state --state INVALID -j DROP -A FORWARD -m state --state NEW -j LOG --log-prefix "CHAIN=TINYWALL-NEW-FORW " -A FORWARD -p icmp -j ACCEPT -A FORWARD -m state --state NEW -j LOG --log-prefix "CHAIN=TINYWALL-NEW-FORW " #Это необязательная строка -A FORWARD -s 192.168.4.0/24 -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT -A FORWARD -s 192.168.4.0/24 -m state --state NEW -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j TINYWALL-FORWARD -A FORWARD -j LOG --log-prefix "CHAIN=TINYWALL-FORW-REJECT " -A FORWARD -j REJECT --reject-with icmp-admin-prohibited -A OUTPUT -m state --state INVALID -j DROP -A OUTPUT -m state --state NEW -j LOG --log-prefix "CHAIN=TINYWALL-NEW-OUTPUT " -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -m state --state NEW -j LOG --log-prefix "CHAIN=TINYWALL-NEW-OUTPUT " #Это необязательная строка -A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT -A OUTPUT -p udp -m udp --sport 53 -m state --state NEW -j ACCEPT -A OUTPUT -p udp -m udp --dport 123 -m state --state NEW -j ACCEPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j TINYWALL-OUTPUT -A OUTPUT -j LOG --log-prefix "CHAIN=TINYWALL-OUTPUT-REJECT " -A OUTPUT -j REJECT --reject-with icmp-admin-prohibited -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1492 COMMIT # Completed on Thu Sep 15 16:51:15 2016 # Generated by iptables-save v1.4.14 on Thu Sep 15 16:51:15 2016 *mangle :PREROUTING ACCEPT [2857:1106716] :INPUT ACCEPT [2787:1101011] :FORWARD ACCEPT [70:5705] :OUTPUT ACCEPT [2005:212971] :POSTROUTING ACCEPT [2163:232874] COMMIT # Completed on Thu Sep 15 16:51:15 2016 Запишем в /etc/rc.local строчку iptables-restore < /etc/firewall Шлюз готов, можно использовать 192.168.4.1 как шлюз и DNS сервер. Напоследок текст скрипта log-analyzer: #!/bin/bash while read string do echo "" export $string 2>/dev/null HSRC=`host $SRC 2>/dev/null | grep "domain name pointer" | awk '{ print $5 }'` HDST=`host $DST 2>/dev/null | grep "domain name pointer" | awk '{ print $5 }'` echo $PROTO | grep "^[[:digit:]]*$" > /dev/null && unset DPT PROTO=`grep "[[:space:]]$PROTO[[:space:]]" /etc/protocols | awk '{ print $1 }'` HPROTO=`grep -i "[[:space:]]$DPT/$PROTO" /etc/services | sed 's/\\t/\\ /g' | sed 's/\\ \\ /\\ /g'` HSPROTO=`grep -i "[[:space:]]$SPT/$PROTO" /etc/services | sed 's/\\t/\\ /g'| sed 's/\\ \\ /\\ /g'` HSRC=${HSRC:-$SRC} HDST=${HDST:-$DST} HPROTO=${HPROTO:-"$DPT/$PROTO"} HSPROTO=${HSPROTO:-"$SPT/$PROTO"} set $string echo "$CHAIN $HDST ($HPROTO) <=== $HSRC ($HSPROTO) /$1 $2 $3/" done Его можно запустить командой: sudo tail -n 50 -f /var/log/syslog | grep "TINYWALL" | /<path>/log-analyzer   Использование нескольких сетевых стеков в Linux   Автор: Roman Timofeev ( ^rage^ )  [комментарии]   В linux относительно давно появилась такая замечательная вещь, как неймспейсы (namespaces). Основное применение данной технологии - контейнерная виртуализация, но и на маршрутизаторе можно придумать много разных применений, так как среди неймспейсов есть "network namespaces". Network namespaces позволяют в рамках одной машины в каждом неймспейсе иметь: свой набор таблиц маршрутизации (а их 2^31-1 шт) свою arp-таблицу свои правила iptables свои устройства (а значит и qdisc + class'ы tc) NB: для выполнения нижеследующих примеров крайне желательно иметь свежий iproute2 и ядро. Создаются неймспейсы достаточно скучно и просто: ip netns add VROUTER ip netns add KUKYSEVRACI Создадим "виртуальны шнурок": ip link add name ve0a type veth peer name ve0b Добавим интерфейсы внутрь VROUTER: ip link set dev eth0 netns VROUTER ip link set dev ve0b netns VROUTER Выполнить команду в контексте определённого неймспейса можно так: ip netns exec VROUTER ip link show Настроим адреса: ip netns exec VROUTER ip a a 192.168.1.1/24 dev ve0b ip a a 192.168.1.2/24 dev ve0a ip netns exec VROUTER ip a a 10.140.48.16/24 dev eth0 Поднимем интерфейсы: ip link set dev ve0a up ip netns exec VROUTER ip link set dev eth0 up ip netns exec VROUTER ip link set dev ve0b up Шлюз по умолчанию: ip netns exec VROUTER ip r a default via 10.140.48.1 Посмотрим, что получилось: root@laptus:~# ip netns exec VROUTER ip r s default via 10.140.48.1 dev eth0 10.140.48.0/24 dev eth0 proto kernel scope link src 10.140.48.16 192.168.1.0/24 dev ve0b proto kernel scope link src 192.168.1.1 Добавим NAT: ip netns exec VROUTER iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 10.140.48.16 Сделаем пару трейсов: root@laptus:~# ip netns exec VROUTER traceroute -q 1 -I opennet.ru traceroute to opennet.ru (77.234.201.242), 30 hops max, 60 byte packets 1 10.140.48.1 (10.140.48.1) 0.148 ms 2 10.140.0.1 (10.140.0.1) 0.245 ms 3 border.yournet.ru (91.204.148.17) 0.436 ms 4 alisa.yournet.ru (91.204.151.2) 0.521 ms 5 sev-gw.yournet.ru (91.204.148.2) 8.975 ms 6 bl16-1-gw.spb.runnet.ru (194.190.255.25) 1.321 ms 7 bl16-1-gw.spb.runnet.ru (194.85.40.170) 1.785 ms 8 s14-1-gw.spb.runnet.ru (194.85.40.81) 1.456 ms 9 vuztc.spb.runnet.ru (194.190.255.170) 1.987 ms 10 opennet.ru (77.234.201.242) 2.395 ms root@laptus:~# traceroute -q 1 -I opennet.ru traceroute to opennet.ru (77.234.201.242), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.094 ms 2 10.140.48.1 (10.140.48.1) 0.751 ms 3 10.140.0.1 (10.140.0.1) 1.277 ms 4 border.yournet.ru (91.204.148.17) 2.061 ms 5 alisa.yournet.ru (91.204.151.2) 2.911 ms 6 sev-gw.yournet.ru (91.204.148.2) 6.770 ms 7 bl16-1-gw.spb.runnet.ru (194.190.255.25) 3.622 ms 8 bl16-1-gw.spb.runnet.ru (194.85.40.170) 5.262 ms 9 s14-1-gw.spb.runnet.ru (194.85.40.81) 4.135 ms 10 vuztc.spb.runnet.ru (194.190.255.170) 4.710 ms 11 opennet.ru (77.234.201.242) 7.220 ms   Multicast во FreeBSD без igmpproxy (доп. ссылка 1) (доп. ссылка 2)   Автор: nuclight  [комментарии]   Иван Рожук опубликовал скрипт mcastbr2.sh для проброса multicast через шлюз на базе FreeBSD штатными средствами netgraph, без использования неработающих у многих igmpproxy и mrouted. #!/bin/sh # Copyright (c) 2011 Rozhuk Ivan <[email protected]> # All rights reserved. # # Subject to the following obligations and disclaimer of warranty, use and # redistribution of this software, in source or object code forms, with or # without modifications are expressly permitted by Whistle Communications; # provided, however, that: # 1. Any and all reproductions of the source or object code must include the # copyright notice above and the following disclaimer of warranties; and # 2. No rights are granted, in any manner or form, to use Whistle # Communications, Inc. trademarks, including the mark "WHISTLE # COMMUNICATIONS" on advertising, endorsements, or otherwise except as # such appears in the above copyright notice or in the software. # # THIS SOFTWARE IS BEING PROVIDED BY WHISTLE COMMUNICATIONS "AS IS", AND # TO THE MAXIMUM EXTENT PERMITTED BY LAW, WHISTLE COMMUNICATIONS MAKES NO # REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, REGARDING THIS SOFTWARE, # INCLUDING WITHOUT LIMITATION, ANY AND ALL IMPLIED WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. # WHISTLE COMMUNICATIONS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY # REPRESENTATIONS REGARDING THE USE OF, OR THE RESULTS OF THE USE OF THIS # SOFTWARE IN TERMS OF ITS CORRECTNESS, ACCURACY, RELIABILITY OR OTHERWISE. # IN NO EVENT SHALL WHISTLE COMMUNICATIONS BE LIABLE FOR ANY DAMAGES # RESULTING FROM OR ARISING OUT OF ANY USE OF THIS SOFTWARE, INCLUDING # WITHOUT LIMITATION, ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, # PUNITIVE, OR CONSEQUENTIAL DAMAGES, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES, LOSS OF USE, DATA OR PROFITS, HOWEVER CAUSED AND UNDER ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF # THIS SOFTWARE, EVEN IF WHISTLE COMMUNICATIONS IS ADVISED OF THE POSSIBILITY # OF SUCH DAMAGE. # # Author: Rozhuk Ivan <[email protected]> # # $FreeBSD: src/sys/netgraph/ng_l2ccp.c,v 1.0.0.1 2010/09/19 08:13:06 kensmith Exp $ # This script create bridge between two network interfaces # downstream - network with clients # upstream - network with multicast # downstream <-IGMP-> upstream # downstream <-UDP<- upstream # only packets with multicast dst mac addr forwarded trouth bridge and (!) not pass to network stack IF_UPSTREAM="$2" IF_DOWNSTREAM="$3" BR_NAME="${IF_UPSTREAM}-${IF_DOWNSTREAM}-br" PATTERN_MCAST_IGMP="ether[0] & 1 = 1 and (ether[0:4] != 0xffffffff or ether[4:2] != 0xffff) and ip[9] = 2" PATTERN_MCAST_IGMP_UDP="ether[0] & 1 = 1 and (ether[0:4] != 0xffffffff or ether[4:2] != 0xffff) and (ip[9] = 17 or ip[9] = 2)" # allways NOT MATCH BPFPROG_PASSTOUTH="bpf_prog_len=1 bpf_prog=[ { code=6 jt=0 jf=0 k=0 } ]" usage_msg() { echo "usage: start|stop upstreamIF downstreamIF1" echo "This create bridge beetwen two IFs for IGMP, and UDP from upstreamIF to downstreamIF1" } if [ -z "${IF_UPSTREAM}" -o -z "${IF_DOWNSTREAM}" ]; then usage_msg return 1 fi if ! ifconfig "$IF_UPSTREAM" > /dev/null 2>&1 ; then usage_msg echo "Invalid upstream interface: ${IF_UPSTREAM}" return 1 fi if ! ifconfig "$IF_DOWNSTREAM" > /dev/null 2>&1 ; then usage_msg echo "Invalid downstream interface: ${IF_DOWNSTREAM}" return 1 fi case "$1" in start) # load modules kldload ng_ether > /dev/null 2>&1 kldload ng_bpf > /dev/null 2>&1 echo "start bridging beetwen ${IF_UPSTREAM} and ${IF_DOWNSTREAM}" BPFPROG_MCAST_IGMP=$( tcpdump -s 65535 -ddd ${PATTERN_MCAST_IGMP} | \ ( read len ; \ echo -n "bpf_prog_len=$len " ; \ echo -n "bpf_prog=[" ; \ while read code jt jf k ; do \ echo -n " { code=$code jt=$jt jf=$jf k=$k }" ; \ done ; \ echo " ]" ) ) BPFPROG_MCAST_IGMP_UDP=$( tcpdump -s 65535 -ddd ${PATTERN_MCAST_IGMP_UDP} | \ ( read len ; \ echo -n "bpf_prog_len=$len " ; \ echo -n "bpf_prog=[" ; \ while read code jt jf k ; do \ echo -n " { code=$code jt=$jt jf=$jf k=$k }" ; \ done ; \ echo " ]" ) ) # create and connect nodes ngctl mkpeer ${IF_UPSTREAM}: bpf lower ${IF_UPSTREAM}-lower ngctl name ${IF_UPSTREAM}:lower ${BR_NAME}-bpf ngctl connect ${IF_UPSTREAM}: ${BR_NAME}-bpf: upper ${IF_UPSTREAM}-upper ngctl connect ${IF_DOWNSTREAM}: ${BR_NAME}-bpf: lower ${IF_DOWNSTREAM}-lower ngctl connect ${IF_DOWNSTREAM}: ${BR_NAME}-bpf: upper ${IF_DOWNSTREAM}-upper # configure BPF node ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_UPSTREAM}-lower\" ifMatch=\"${IF_DOWNSTREAM}-lower\" ifNotMatch=\"${IF_UPSTREAM}-upper\" ${BPFPROG_MCAST_IGMP_UDP} } ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_UPSTREAM}-upper\" ifMatch=\"\" ifNotMatch=\"${IF_UPSTREAM}-lower\" ${BPFPROG_PASSTOUTH} } ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_DOWNSTREAM}-lower\" ifMatch=\"${IF_UPSTREAM}-lower\" ifNotMatch=\"${IF_DOWNSTREAM}-upper\" ${BPFPROG_MCAST_IGMP} } ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_DOWNSTREAM}-upper\" ifMatch=\"\" ifNotMatch=\"${IF_DOWNSTREAM}-lower\" ${BPFPROG_PASSTOUTH} } # configure net if ngctl msg ${IF_UPSTREAM}: setautosrc 1 ngctl msg ${IF_UPSTREAM}: setpromisc 1 #ngctl msg ${IF_DOWNSTREAM}: setautosrc 0 ngctl msg ${IF_DOWNSTREAM}: setpromisc 1 ;; stop) echo "stop" # remove hooks and nodes ngctl rmhook ${IF_UPSTREAM}: lower ngctl rmhook ${IF_UPSTREAM}: upper ngctl rmhook ${IF_DOWNSTREAM}: lower ngctl rmhook ${IF_DOWNSTREAM}: upper ngctl shutdown ${BR_NAME}-bpf: # unload modules #kldunload ng_ether > /dev/null 2>&1 #kldunload ng_bpf > /dev/null 2>&1 ;; *) usage_msg esac return 0 Суть скрипта: между интерфейсами (ng_ether) создается подобие бриджа с ng_bpf посередине, который пропускает через себя только мультикаст. Причем эти пакеты проходят полностью в обход сетевого стека. Дополнение. Создать мост между em0 и re0, где re0 подключён к сети с мультикастом: mcastbr2.sh start re0 em0 Удалить мост: mcastbr2.sh stop re0 em0 История igmpproxy и mrouted у меня работать отказались, после нескольких часов проб, чтения и новых проб я решил не заниматься ремонтом ядра и этих приложений, а просто выборочно сбриджевать два сетевых интерфейса: - IGMP на multicast адреса из локалки в сеть провайдера и обратно; - UDP на multicast адреса из сети провайдера в локалку. Броадкаст не нужен, и направляется в ядро как обычно. Несмотря на цифру 2, по сути эта третья версия графа, получившая в результате оптимизации первых двух. Первая содержала ng_ether, ng_tee, ng_one2many, ng_bpf. Вторая содержала ng_ether, ng_tee, ng_one2many, ng_bpf. Окончательная содержит: ng_ether, ng_left2right, ng_tee, ng_bpf. В первых двух версиях создавалась копия пакета, и один уходил через мост в другую сеть либо отбрасывался, а второй попадал в ядро. Поскольку ядро всё равно их дропало где то внутри и нетграф их очень много отбрасывал, ничего полезного не делая, то я решил их вообще туда не посылать и организовать так чтобы не создавать дубликатов и не уничтожать пакеты. Принцип работы BPF настроен таким образом чтобы пропускать все без исключения пакеты с upper хуков ng_ether нод на lower хуки (пакеты от системы в сеть). Приходящие из сети пакеты с lower хуков нод проверяются в BPF, и - если это мультикаст; - и не броадкаст; - и IGMP [или UDP в случае если пакет от адаптера подключённого к провайдеру] то такой пакет целиком пересылается на lower хук другого адаптера, минуя сетевой стёк операционной системы. Тонкости 1. Пришлось включить promisc режим на обоих интерфейсах, иначе мультикаст дропается самим сетевым адаптером, это нормальное поведение. 2. Пришлось включить autosrc на интерфейсе в сети провайдера, так как у провайдера на коммутаторе настроен Port Security на пропускание только одного MAC адреса - первого изученного на порту после поднятия линка. 3. Моему провайдеру нет дела до того какой src-ip в IP приходит от меня, если бы было, то я бы попробовал гнать трафик в сторону провайдера через ng_patch ноду, которая бы заменяла src-ip на нужны, и выставляла CSUM_IP и CSUM_UDP в заголовке пакета - есть шанс что драйвер сетевого адаптера сам рассчитает эти суммы либо что оборудование провайдера проигнорирует неверную контрольную сумму в IGMP пакетах от меня. Нода также подключается обоими хуками к BPF, выход настраивается на passtrouth (пересылку всех пакетов) на lower хук ng_ether на адаптере в сети провайдера, а вход ng_patch должен быть match выходом от lower на адаптере в локальной сети. Те совсем не большая модификация графа. 4. Работает на vlan интерфейсах. Для создания аналогичного по функционалу моста, в котором будет несколько сетевых интерфейсов в разных сетях с мультикастом и несколько сетевых адаптеров в сетях куда его нужно переправить потребуется на каждый сетевой адаптер вешать по ng_split + ng_one2many и по одной ng_one2many с каждой стороны моста для рассылки копий мультикаста на все интерфейсы. upper хуки ng_ether нод по прежнему будут напрямую подключатся к BPF. В случае нескольких сетей - источников мультикаста будет ещё проблема с возможным перекрытием адресных пространств, которую можно частично разрешить настроив в BPF фильтрацию по адресам.   Запись и повторное проигрывание трафика   [комментарии]   Для симулирования трафика, перехваченного сниффером и сохранённого в формате pcap, удобно использовать сочетание утилит tcpreplay (http://tcpreplay.synfin.net/) для непосредственной переотправки трафика и tcprewrite (http://tcpreplay.synfin.net/wiki/tcprewrite) для замены IP-адресов и других параметров пакетов. Повторная генерация потока может быть полезна для оценки поведения различных программ на различные атаки, при изучении причин сбоев в сетевом ПО или при проведении нагрузочного тестирования (можно менять интенсивность отправки пакетов). Обе утилиты входят в состав пакета tcpreplay: sudo apt-get install tcpreplay Перехват трафика можно произвести утилитой tcpdump: tcpdump -ni wlan0 -s0 -w dump.pcap port 501 Для замены адреса отправителя 210.1.54.1 на адрес локальной машины 192.168.1.1 используем утилиту tcprewrite: tcprewrite --skipbroadcast --pnat=210.1.54.1:192.168.1.1 --infile=dump.pcap --outfile=dump2.pcap Повторно генерируем пакеты, используя интерфейс eth0: tcpreplay --intf1=eth0 dump2.pcap Из других похожих проектов, можно отметить: fragroute - позволяет перехватывать, изменять и переотправлять трафик, адресованный определённому хосту. netdude - мощный редактор и просмотрщик содержимого pcap-дампов. wireplay - простая и удобная утилита для переотправки записанных в pcap-дампе TCP-сессий с внесением изменений. Например, для переотправки записанного в http.pcap HTTP-трафика: wireplay -K --role client --port 80 --target 127.0.0.1 -L -F http.pcap В ситуации, когда нужно просто сгенерировать поток на основе лога HTTP-сервера, можно использовать утилиту httperf: Копируем список запрашиваемых URL из лога: cat apache.log | awk '{print $7}' > requests.log Заменяем перевод сроки на нулевой символ, как того требует httperf tr "\n" "\0" < requests.log > httperf.log Симулируем отправку пакетов к IP 192.168.1.1 в 100 одновременных запросов, прекращаем отправку после 10 тыс. запросов. httperf --hog --server 192.168.1.1 --port 80 --wlog=n,httperf.log --rate=100   Передача статических маршрутов в DHCP (доп. ссылка 1)   [комментарии]   В основную секцию файла конфигурации DHCP сервера нужно прописать: option ms-classless-static-routes code 249 = array of unsigned integer 8; option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; в потом в секции subnet или host прописывать: option ms-classless-static-routes 16, 172,16, 10,16,40,100; option rfc3442-classless-static-routes 16, 172,16, 10,16,40,100; где 16 (маска) 172.16.0.0 (сеть) 10.16.40.100 (шлюз) Скрипт для генерации содержимого "option classless-route" в шестнадцатеричной нотации для более старых версий dhcpd: #!/usr/bin/perl use strict; # Usage: # make_classless_option({ "subnet/mask" => "router", "subnet/mask" => "router", ... }); # subnet the subnet address, 4 dot-separated numbers # mask the subnet mask length (e.g. /24 corresponds to 255.255.255.0, /8 corresponds to 255.0.0.0) # router the router address, 4 dot-separated numbers sub make_classless_option{ my $routes = shift; my ($s1, $s2, $s3, $s4, $len, @bytes, $net, $mask, $destination, $router); $len = 2; @bytes = (); foreach $destination(keys %{$routes}) { ($net, $mask) = split('/', $destination); $router = $routes->{$destination}; ($s1, $s2, $s3, $s4) = split(/\./, $net); push(@bytes, sprintf('%02x', $mask)); push(@bytes, sprintf('%02x', $s1)); push(@bytes, sprintf('%02x', $s2)) if($mask > 8); push(@bytes, sprintf('%02x', $s3)) if($mask > 16); push(@bytes, sprintf('%02x', $s4)) if($mask > 24); ($s1, $s2, $s3, $s4) = split(/\./, $router); push(@bytes, sprintf('%02x', $s1)); push(@bytes, sprintf('%02x', $s2)); push(@bytes, sprintf('%02x', $s3)); push(@bytes, sprintf('%02x', $s4)); } return join(':', @bytes); } # Пример использования print make_classless_option({ "10.230.0.0/16" => "10.230.178.145" });   Настройка IPv6 в Ubuntu Linux (доп. ссылка 1)   Автор: pridumal.org.ua  [комментарии]   Имеем Ubuntu 8.10 Intrepid Ibex Server Edition, выходящий в сеть по PPP и работающий с интранет IP через NAT. Задача: дать ему реальный, белый IPv6-адрес и сделать на его базе IPv6-маршрутизатор, который будет обеспечивать передачу IPv6-пакетов между миром и локальной сетью. Для начала получим себе адрес IPv6. В этом нам поможет сервис (т.н. "брокер") http://go6.net, на котором нам, в первую очередь, надо зарегистрироваться. Go6 даст нам не один адрес IPv6, а целую подсеть. Для того, чтобы выпустить пакеты IPv6 в мир go6 предоставит нам IPv4-туннель: пакеты шестой версии будут упакованы в пакеты четвертой версии, в таком виде через провайдерские сети дойдут до маршрутизаторов freenet6 (именно так называется сеть, к которой мы подключаемся), где их распакуют и выпустят уже в виде полноценной v6. После регистрации на указанный адрес придет письмо в котором нас интересуют поля Username, Password и Gateway6 Address. Теперь приступаем к настройке сервера. По умолчанию поддержка IPv6 в ubuntu-server уже включена. В случае чего ситуацию можно исправить командой: $ sudo modprobe ipv6 Нам понадобится установить всего лишь один единственный пакет: $ sudo apt-get install tspc После установки редактируем конфиг: $ sudo nano /etc/tsp/tspc.conf Вот вывод того, что включено у меня (результат команды sudo cat /etc/tsp/tspc.conf | grep -v "#") auth_method=any client_v4=auto userid=xxxxxx <== Тут ваш юзернейм из письма passwd=******** <== Пароль из письма template=setup server=broker.freenet6.net <== Адрес брокера retry_delay=30 tunnel_mode=v6anyv4 if_tunnel_v6v4=sit1 if_tunnel_v6udpv4=tun proxy_client=no keepalive=yes keepalive_interval=30 syslog_facility=DAEMON syslog_level=INFO host_type=router prefixlen=64 if_prefix=eth0 <== Адрес сетевой карты, которая смотрит в локалку Ок, кажется всё настроили - теперь можно проверять: $ sudo /etc/init.d/tspc restart $ ifconfig eth0 Если вы увидели там inet6 addr, начинающийся на что-то, отличное от fe... (например 2001:5с0...), значит всё получилось. Иначе - читаем и повторяем всё сначала. Еще один неплохой способ проверить - пропинговать какой-нибудь IPv6-enabled сайт. Например ipv6.google.com. Для этого, вместо "обычного" пинга, воспользуемся специальной версией для IPv6: $ ping6 ipv6.google.com PING ipv6.google.com(2001:4860:0:1001::68) 56 data bytes 64 bytes from 2001:4860:0:1001::68: icmp_seq=1 ttl=54 time=444 ms   Настройка IPv6 в Debian GNU/Linux (доп. ссылка 1)   [комментарии]   IPv6 соединение будем туннелировать через брокер туннелей (Tunnel Broker), так как не все ISP поддерживают прямое IPv6 соединение. Регистрируем свою систему в сервисе http://tunnelbroker.net/ (выбираем "Create Regular Tunnel") , http://go6.net/4105/freenet.asp или http://www.sixxs.net/ При регистрации вводим IPv4 адрес машины, на которой будет поднят туннель. После регистрации получаем: IPv4 адрес удаленного конца туннеля: 216.66.80.30 IPv6 адрес удаленного шлюза: 2001:0470:1f0a:cc0::1/64 Клиентский IPv6 адрес, который нужно использовать на своей машине: 2001:0470:1f0a:cc0::2/64 Поднимаем IPv6-in-IPv4 туннель: ifconfig sit0 up ifconfig sit0 inet6 tunnel ::216.66.80.30 ifconfig sit1 up ifconfig sit1 inet6 add 2001:0470:1f0a:cc0::2/64 route -A inet6 add ::/0 dev sit1 Проверяем через пинг удаленного конца туннеля и IPv6 хоста из списка http://www.ipv6.org/v6-www.html : ping6 -c4 2001:0470:1f0a:cc0::1 ping6 -c4 www.ipv6.uni-muenster.de Создаем файл /etc/network/if-up.d/ipv6 для настройки параметров при загрузке: #!/bin/sh PATH=/sbin:/bin ifconfig sit0 up ifconfig sit0 inet6 tunnel ::216.66.80.30 ifconfig sit1 up ifconfig sit1 inet6 add 2001:0470:1f0a:cc0::2/64 route -A inet6 add ::/0 dev sit1 Не забываем поставить права доступа: chmod 755 /etc/network/if-up.d/ipv6   Подключение FreeBSD к IPv6 - поднимаем туннель через IPv4-сети провайдера (доп. ссылка 1)   Автор: Litos  [комментарии]   Итак, пришло время поднять IPv4-IPv6 gateway, чтобы ходить в мир "другого интернета", коим он скоро будет. Самым простым способом получить IPv6 адрес оказалось получить подключение от http://go6.net Идем на этот сайт и регистрируемся http://go6.net/4105/register.asp Тут же они предлагают скачать софт и поставить, например для Windows вида "скачай и запусти" http://go6.net/4105/download.asp Но это не совсем наш метод, мы будем подключать сервер на FreeBSD 7.0 к этой сети. Ядро у нас собрано с поддержкой IPV6, т.е. с options INET6 (ядро GENERIC уже поддерживает этот протокол и если вы его не отключали, значит, он у вас есть) Итак, ставим клиента, то, что они предлагают скачивать - есть в портах Port: gateway6-5.0_2 Path: /usr/ports/net/gateway6 Info: Gateway6 Tunnel Setup Protocol Client - Free IPv6 tunnel B-deps: R-deps: WWW: http://www.go6.net/ Приступаем к установке: cd /usr/ports/net/gateway6 make install clean Буквально через несколько минут клиент будет установлен Отредактируйте его конфигурационный файл /usr/local/etc/gw6c.conf userid= passwd= Пропишите туда ваше имя и пароль которые указали при регистрации на сайте. На этом начальная настройка закончена, для дальнейшей настройки читайте документацию. Как я понял, выдается целая сеть и для авторизованных пользователей http://go6.net/4105/freenet.asp, тем самым можно все компьютеры дома подключить на реальные статические IPv6 адреса. server=broker.freenet6.net broker.freenet6.net - это имя сервера для подключения (написано в письме при регистрации) # Включить использование авторизации auth_method=any # Писать логи в syslogd log_syslog=3 Теперь осталось запустить его echo 'gateway6_enable="YES"' >> /etc/rc.conf /usr/local/etc/rc.d/gateway6 start И смотрим # tail -f /var/log/messages Oct 17 18:39:38 lola gw6c: Gateway6 Client v5.0-RELEASE build Oct 17 2008-14:56:32 Oct 17 18:39:38 lola gw6c: Establishing connection to tunnel broker broker.freenet6.net using reliable UDP. Oct 17 18:39:42 lola gw6c: Connection to broker.freenet6.net established. Oct 17 18:39:45 lola gw6c: Authentication success. Oct 17 18:39:45 lola gw6c: Got tunnel parameters from server. Setting up local tunnel. Oct 17 18:39:45 lola gw6c: Executing configuration script: /bin/sh "/usr/local/share/gateway6/freebsd.sh". Oct 17 18:39:46 lola gw6c: Script completed successfully. Oct 17 18:39:46 lola gw6c: Your IPv6 address is 2001:05c0:8fff:fffe:0000:0000:0000:c243. Oct 17 18:39:46 lola gw6c: The tunnel type is v6udpv4. # ifconfig tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 inet6 2001:5c0:8fff:fffe::c243 --> 2001:5c0:8fff:fffe::c242 prefixlen 128 Opened by PID 873 # traceroute6 www.jp.freebsd.org ... # ping6 www.jp.freebsd.org ... Все прекрасно работает не смотря на то, что выход осуществляется в мир через NAT на модеме. Итак, осталось только понять, "зачем это надо", но ясно одно - за этим будущее. А еще можно посмотреть на танцующую черепаху на http://www.kame.net/ :-) Также рекомендую прочитать документацию (главу в HandBook http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/network-ipv6.html) по поддержке протокола IPv6 в системе FreeBSD.   Пример настройки ng_neflow для нескольких интерфейсов.   Автор: stalex  [комментарии]   #cat ng5_netflow.sh #!/bin/sh kldload ng_netflow kldload ng_ether kldload ng_tee kldload ng_one2many /usr/sbin/ngctl -f- <<-SEQ mkpeer em2: tee lower right connect em2: em2:lower upper left name em2:lower em2_tee mkpeer em2:lower netflow right2left iface0 name em2:lower.right2left netflow msg netflow: setifindex { iface=0 index=1 } connect em2:lower netflow: left2right iface1 msg netflow: setifindex { iface=1 index=1 } mkpeer vlan254: tee lower right connect vlan254: vlan254:lower upper left name vlan254:lower vlan254_tee connect vlan254:lower netflow: right2left iface3 msg netflow: setifindex { iface=3 index=1 } connect vlan254:lower netflow: left2right iface4 msg netflow: setifindex { iface=4 index=1 } mkpeer vlan22: tee lower right connect vlan22: vlan22:lower upper left name vlan22:lower vlan22_tee connect vlan22:lower netflow: right2left iface5 msg netflow: setifindex { iface=5 index=1 } connect vlan22:lower netflow: left2right iface6 msg netflow: setifindex { iface=6 index=1 } mkpeer vlan21: tee lower right connect vlan21: vlan21:lower upper left name vlan21:lower vlan21_tee connect vlan21:lower netflow: right2left iface7 msg netflow: setifindex { iface=7 index=1 } connect vlan21:lower netflow: left2right iface8 msg netflow: setifindex { iface=8 index=1 } mkpeer netflow: ksocket export inet/dgram/udp msg netflow:export connect inet/127.0.0.1:20001 SEQ   Прозрачный редирект порта, используя xinetd и netcat (доп. ссылка 1)   [комментарии]   После переноса сервиса на новый сервер, на старом можно организовать сервис заглушку, осуществляющий редирект следующим образом: /etc/xinetd.d/smtp-tcp service smtp { disable = no socket_type = stream protocol = tcp user = nobody wait = no server = /bin/nc # server = /usr/bin/netcat server_args = -w 2 192.168.1.1 25 } где 192.168.1.1 адрес нового сервера, nc - утилита netcat, "-w 2" - таймаут в 2 сек.   Изменение имени сетевого интерфейса в Linux   Автор: NuclearCat  [комментарии]   /sbin/ifconfig ppp1 down /sbin/ip link set ppp1 name my_ppp /sbin/ifconfig my_ppp up   Статические маршруты через isc-dhcpd   Автор: Артем Бохан  [комментарии]   Согласно RFC 3442 через dhcp можно отдавать таблицу маршрутизации. Изначально эта опция не поддерживается isc-dhcpd, но опцию можно добавить. Пример: option classless-route code 121 = string; option classless-route 18:c0:a8:ea:c0:a8:00:05; пример получения кода, взято с http://rfc3442svc.sourceforge.net/isc-dhcpd-configuration.html #!/usr/bin/perl use strict; # Usage: # make_classless_option({ "subnet/mask" => "router", "subnet/mask" => "router", ... }); # subnet the subnet address, 4 dot-separated numbers # mask the subnet mask length (e.g. /24 corresponds to 255.255.255.0, /8 corresponds to 255.0.0.0) # router the router address, 4 dot-separated numbers sub make_classless_option { my $routes = shift; my ($s1, $s2, $s3, $s4, $len, @bytes, $net, $mask, $destination, $router); $len = 2; @bytes = (); foreach $destination(keys %{$routes}) { ($net, $mask) = split('/', $destination); $router = $routes->{$destination}; ($s1, $s2, $s3, $s4) = split(/\./, $net); push(@bytes, sprintf('%02x', $mask)); push(@bytes, sprintf('%02x', $s1)); push(@bytes, sprintf('%02x', $s2)) if($mask > 8); push(@bytes, sprintf('%02x', $s3)) if($mask > 16); push(@bytes, sprintf('%02x', $s4)) if($mask > 24); ($s1, $s2, $s3, $s4) = split(/\./, $router); push(@bytes, sprintf('%02x', $s1)); push(@bytes, sprintf('%02x', $s2)); push(@bytes, sprintf('%02x', $s3)); push(@bytes, sprintf('%02x', $s4)); } return join(':', @bytes); } # Sample usage print make_classless_option({ "172.16.0.0/12" => "10.0.0.1", "10.0.0.0/8" => "10.0.0.1", "0.0.0.0/0" => "192.168.0.1", "192.168.234.0/24" => "192.168.0.5" }); На данный момент данную опцию поддерживает малое количество клиентов, например windows XP, только по непонятным причинам использует код 249, т.е. в конфигурации сервера надо будет использовать option classless-route code 249 = string;   Настройка беспроводной 80211 карты под FreeBSD (доп. ссылка 1)   Автор: toxa  [комментарии]   kldload bridge sysctl net.link.ether.bridge.enable="1" sysctl net.link.ether.bridge.config="wi0,fxp0" sysctl net.inet.ip.forwarding="1" ifconfig wi0 ssid toxawlan channel 11 media DS/11Mbps mediaopt hostap up stationname "toxawlan"   Обобщение используемых моделей ввода/вывода (доп. ссылка 1)   [обсудить]   Стратегии организации ввода-вывода: Блокируемый I/O - после вызова read/write происходит блокировка до завершения операции, функция завершается только после принятия или передачи блока данных. Неблокируемый I/0 - функция завершается сразу, если данные не были приняты/отправлены возвращается код ошибки (т.е. нужно вызывать функции I/O в цикле пока не получим положительный результат). Мультиплексирование через select/poll - опрашиваем список состояния сокетов, перебирая состояния определяем сокеты готовые для приема/передачи. Главный минус - затраты на перебор, особенно при большом числе неактивных сокетов. select - число контролируемых сокетов ограничено лимитом FD_SETSIZE, в некоторых случаях лимит обходится пересборкой программы, в других - пересборкой ядра ОС. poll - нет лимита FD_SETSIZE, но менее эффективен из за большего размера передаваемой в ядро структуры. Генерация сигнала SIGIO при изменении состояния сокета (ошибка, есть данные для приема, или отправка завершена), который обрабатывает обработчик SIGIO. В классическом виде применение ограничено и трудоемко, подходит больше для UDP. Асинхронный I/O - описан в POSIX 1003.1b (aio_open, aio_write, aio_read...), функция aio_* завершается мгновенно, далее процесс сигнализируется о полном завершении операции ввода/вывода (в предыдущих пунктах процесс информировался о готовности прочитать или передать данные, т.е. данные еще нужно было принять или отправить через read/write, в aio_* процесс сигнализируется когда данные полностью получены и скопированы в локальный буфер). Передача данных об изменении состояния сокета через генерацию событий. (специфичные для определенных ОС решения, малопереносимы, но эффективны). kqueue - лучшее для FreeBSD, NetBSD. Данные о нескольких событиях могут быть переданы за раз, очень гибкое решение. /dev/epoll - лучшее для 2.6 Linux ядра, передача нескольких событий за раз, трудоемкость поддержки /dev/epoll если параллельно в программе поддерживаются другие механизмы нотификации. Realtime Signals (F_SETSIG) - лучшее для 2.4 Linux ядра. /dev/poll - имеет смысл в Solaris, в Linux реализация недостаточно хороша. Ссылки: libevent - очень хорошая библиотека враппер для работы с kqueue, select, poll, epoll и real-time signals. kqueue - a generic and scalable event notification facility man kqueue Слайды "The kqueue facility in FreeBSD" /dev/epoll - a highspeed Linux kernel patch Improving (network) I/O performance - описание /dev/epoll с примерами кода, неплохое сравнение с poll(), realtime signals и /dev/poll. signal-per-fd" Linux kernel patch Analysis of RealTime Signals for Highly Concurrent Network I/O Using the devpoll (/dev/poll) Interface Using the select() and poll() methods Главная ссылка к новости The C10K problem - отличное собрание информации по стратегиям ввода/вывода ru.unix.prog FAQ - Некоторые методы получения состояния (активности) сокета High-Performance Server Architecture Сравнение производительности poll, kqueue и /dev/poll Сравнение производительности poll() и realtime signals Краткое введение в kqueue/kevent (rus);   tcpdump для просмотра содержимого пакетов по определенным портам. (доп. ссылка 1)   [комментарии]   tcpdump -X -s 1500 -n -i fxp0 (tcp port 443) or (tcp port 994) Если нужно выбрать трафик в котором не фигурируют IP 1.2.3.190 и 192.168.20.254, а также внутренние пересылки между адресами 192.168.20 сети, можно использовать правило фильтрации: not host 1.2.3.190 and not host 192.168.20.254 and not (dst net 192.168.20.0/24 and src net 192.168.20.0/24)   Как в FreeBSD добавить/убрать алиас для сетевого интерфейса   [комментарии]   Добавить: ifconfig fxp0 inet 192.168.1.1 netmask 255.255.255.255 alias Убрать: ifconfig fxp0 inet 192.168.1.1 netmask 255.255.255.255 -alias   Табличка с сетевыми масками. (доп. ссылка 1)   [комментарии]   адресов в подсети, 255.255.255.x маска, /x маска, .0 - cisco acl маска. 0 .255 /32 .0 2 .254 /31 .1 4 .252 /30 .3 8 .248 /29 .7 16 .240 /28 .15 32 .224 /27 .31 64 .192 /26 .63 128 .128 /25 .127 256 .0 /24 .255

Ethernet, ARP, привязка MAC адресов.

Пробуждение компьютера по сети с помощью D-Link DIR 300 (320) NRU   Автор: jPump  [комментарии]   Задача: Осуществить возможность пробуждения (Wake on Lan) из интернета удаленного компьютера, находящегося дома за роутером марки D-Link (DIR-300, DIR-320). Решение: Использование команды ip, имеющейся в стандартных сборках BusyBox'a в роутерах D-Link. Предисловие: Дома стоит роутер D-Link DIR-320/NRU ревизии B1, а до этого был DIR-300/NRU ревизии B5, для которых (на данный момент) нет альтернативных готовых прошивок (в том числе и горячо всеми любимой DD-WRT). На роутере стоит BusyBox 1.12. Проблема состояла в том, что встроенное в веб-интерфейс средство переброса пакетов не позволяют переадресацию в широковещательный канал - broadcast (x.x.x.255), а хитровыделанный D-Link обновляет arp-таблицу каждые 15-30 секунд, так что непосредственно в выключенный длительное время компьютер Magic Packet тоже не перебросить. Тайваньские ребята решили отказаться от компиляции arp, sudo и прочих печенюшек в BusyBox, поскольку iptables тоже не позволяет POSTROUTING на широковещательный канал. Решение после недели напряженного поиска было найдено случайно на ныне почившем форуме сборки линукса для старых компьютеров под роутер. Пример: Для начала настройте BIOS вашей материнской платы (в разделе настроек питания есть пункт о пробуждении из выключенного состояния) и вашей сетевой карты (уже из операционной системы в свойствах карты). Для проверки выключите компьютер и посмотрите, если индикация сетевого разъема мигает, значит все в порядке. 1. Подключаемся telnet-ом к роутеру (логин и пароль те же, что и для веб-интерфейса): Dlink-Router login: admin Password: Welcome to _______ ___ __ ____ _ _ ___ | ___ \\ | | |__|| \\ | || | / / | | | || ___ | |__ __ | \\| || |/ / | |___| || |___| | || || |\\ || \\ |_______/ |______||__||_| \\____||_|\\___\\ = Ebuilding Networks for People = BusyBox v1.12.1 (2011-05-13 14:42:48 MSD) built-in shell (ash) Enter 'help' for a list of built-in commands. # 2. Если компьютер в данный момент присоединен к роутеру, то ищем его mac-адрес, набираем: # ip neigh show <Внешний_ip> dev eth2.5 lladdr 01:23:45:67:AB:CD DELAY ! Внешний адрес 192.168.0.50 dev br0 lladdr 11:22:33:44:55:66 REACHABLE ! Настольный компьютер 192.168.0.90 dev br0 lladdr 77:88:99:00:AA:BB REACHABLE ! Ноутбук 3. Поскольку в данный момент уже уже есть запись для нашего mac-адреса, то мы не добавляем, а просто изменяем текущую: # ip neigh change 192.168.0.50 lladdr 11:22:33:44:55:66 nud permanent dev br0 4. Смотрим результат, снова набираем: # ip neigh show <Внешний_ip> dev eth2.5 lladdr 01:23:45:67:AB:CD DELAY ! Внешний адрес 192.168.0.50 dev br0 lladdr 11:22:33:44:55:66 PERMANENT ! Настольный компьютер 192.168.0.90 dev br0 lladdr 77:88:99:00:AA:BB REACHABLE ! Ноутбук После этого уже заходим на веб-интерфейс нашего роутера и в разделе "межсетевой экран" в пункте "Виртуальные серверы" добавляем проброс 9 (или 7, в зависимости от вашей сетевой карты) порта роутера на порт ip вашего компьютера. Послесловие: Совет: настройте через веб-интрефейс роутера DHCP для mac'а вашего компьютера статический IP (по умолчанию DIR-300(320)/NRU выдает их в диапазоне от 192.168.0.2 - 192.168.0.100) Дополнительные ссылки: Немного о линуксовых командах в пределах BusyBox: http://noted.org.ua/1727 Чуть подробнее про команду ip: http://linux-ip.net/html/tools-ip-neighbor.html Для проверки работоспособности можно воспользоваться сайтом: http://wakeonlan.me/ Особая благодарность русскоязычному форуму D-Link'a, оказавшую неоценимую помощь и моральную поддержку: 1, 2, 3   Подстановка HTTP-трафика определенному компьютеру в локальной сети (доп. ссылка 1)   [комментарии]   Используя нехитрые манипуляции в Linux можно подшутить или удивить соседа по офису, например отобразив персональное поздравление при попытке открыть соседом какой-нибудь известного ресурса. Манипуляции проделываются без изменения конфигурации шлюза, путем поднятия web-сервера на своей машине и перенаправление на него запросов, через подмену ARP-адреса шлюза в кэше на машине соседа. Техника действует только в пределах локальной сети. Включаем на своей машине перенаправление IP-пакетов: echo 1 > /proc/sys/net/ipv4/ip_forward Перенаправляем запросы на 80-порт, заменив адрес назначения в пакете на 192.168.1.200 - локальный IP машины с подставным шлюзом. На локальной машине должен быть заблаговременно поднят http-сервер с нужной страницей. iptables -t nat -A PREROUTING -p tcp --dport 80 -j NETMAP --to 192.168.1.200 Добавляем адрес реального шлюза (192.168.1.1) на сетевой интерфейс: ip addr add 192.168.1.1/24 dev eth0 Анонсируем смену MAC-адреса шлюза: arping -c 3 -A -I eth0 192.168.1.1 После завершения розыгрыша убираем IP шлюза с локального интерфейса: ip addr delete 192.168.1.1/24 dev eth0 iptables -t nat -D PREROUTING -p tcp --dport 80 -j NETMAP --to 192.168.1.200 ifconfig eth0 down ifconfig eth0 up arp -d 192.168.1.1 Внимание, описанное действие не следует применять в рабочей сети предприятия, так как подстановка шлюза на время блокирует работу сети из-за конфликта с реальным шлюзом.   Настройка PPPoE соединения в Debian/Ubuntu Linux (доп. ссылка 1)   Автор: Сергей Афонькин  [комментарии]   В данной заметке пойдет речь о частном случае настройки PPPoE - когда необходимо установить соединение на определенный PPPoE концентратор (в том случае когда в сети имеется несколько концентраторов), без использования графических утилит. Для начала установим необходимые пакеты: sudo aptitude install pppoe ppp Далее выполним поиск имеющихся PPPoE концентраторов в сети: sudo pppoe-discovery Access-Concentrator: ac1 Got a cookie: 00 b0 f3 f8 77 fb 26 64 c8 5e 48 80 42 2e 5b a3 AC-Ethernet-Address: 88:43:e1:36:d9:00 Access-Concentrator: ac2 Got a cookie: c2 9c 3c db 26 06 89 f6 06 7e a0 06 ff 8a f8 17 9a 07 00 00 AC-Ethernet-Address: d8:d3:85:e3:85:75 ... В моем случае видим два концентратора с именами ac1 и ac2. Предположим, что необходимо постоянно подключаться к концентратору ac2. Как это сделать? Создаем файл /etc/ppp/peers/pppoe, следующего содержания: ipcp-accept-local ipcp-accept-remote lcp-echo-interval 30 lcp-echo-failure 5 noipdefault usepeerdns defaultroute replacedefaultroute noccp noaccomp noauth persist mtu 1492 hide-password connect /bin/true pty "pppoe -I eth0 -C ac2" # <-- Тут имя вашего концентратора user ПОЛЬЗОВАТЕЛЬ # <-- Тут ваш логин password ПАРОЛЬ # <-- Тут ваш пароль После создания файла можно пробовать устанавливать соединение, выполнив в командной строке: sudo pon pppoe Смотрим наличие интерфейса ppp0 в выводе команды ifconfig. Вывод команды приблизительно такой: sudo ifconfig ppp0 Link encap:Point-to-Point Protocol inet addr:172.22.51.19 P-t-P:94.70.254.21 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1472 Metric:1 RX packets:29890 errors:0 dropped:0 overruns:0 frame:0 TX packets:26304 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:17850149 (17.0 MiB) TX bytes:1835091 (1.7 MiB) ... Если интерфейса ppp0 в выводе команды ifconfig нет, смотрим логи: sudo plog или sudo grep ppp /var/log/syslog Для автоматического создания PPPoE подключения при загрузке компьютера можно прописать следующие строки в /etc/network/interfaces: auto ppp0 iface ppp0 inet ppp pre-up /sbin/ifconfig eth0 up provider pppoe Для отключения соединения PPPoE достаточно выполнить следующую команду: sudo poff pppoe Если PPPoE соединение используется для организации сервиса NAT в сети, то машины за этим NATом должны иметь MTU равный 1412. Иначе возможна ситуация когда, например, некоторые www ресурсы будут недоступны пользователям за NATом. Чтобы этого избежать можно "выравнивать" MTU при помощи iptables. Загрузку правила для iptables сделаем автоматически, при установке PPPoE соединения. А при отключении соединения будем удалять это правило из iptables. Для этого создадим два файла. Для загрузки правила создадим файл /etc/ppp/ip-up.d/pppoemtu следующего содержания: #! /bin/sh PATH=/sbin:/bin:/usr/bin set -e if [ -n "$PPP_IFACE" ]; then iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp \ --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu fi Для удаления правила создадим файл /etc/ppp/ip-down.d/pppoemtu следующего содержания: #! /bin/sh PATH=/sbin:/bin:/usr/bin set -e if [ -n "$PPP_IFACE" ]; then iptables -t mangle -L -n -v --line-numbers | \ grep "TCPMSS.*$PPP_IFACE.*clamp" | cut -f1 -d " " | sort -r | xargs -n1 -r iptables -t mangle -D FORWARD fi Чтобы правила работали надо сделать файлы исполняемыми: sudo chmod 755 /etc/ppp/ip-up.d/pppoemtu /etc/ppp/ip-down.d/pppoemtu Проверить наличие правила в iptables после установки соединения можно выполнив следующую команду: sudo iptables -L -n -v -t mangle Если нет необходимости использовать определенный PPPoE концентратор, то надо просто в файле /etc/ppp/peers/pppoe заменить строку pty "pppoe -I eth0 -C ac2" на pty "pppoe -I eth0".   Объединение сетeвых интерфейсов в Ubuntu Linux при помощи "bonding" (доп. ссылка 1)   Автор: Stepanoff  [комментарии]   В статье рассказано, как объединить два физических сетевых интерфейса в один для увеличения пропускной способности или для повышения отказоустойчивости сети. В Linux это делается при помощи модуля bonding и утилиты ifenslave. В большинстве новых версий дистрибутивов модуль ядра bonding уже есть и готов к использованию, в некоторых вам придется собрать его вручную. Я настраивал данное решение на Ubuntu 8.04 server amd64, поэтому примеры установки ПО взяты оттуда. Установим нужное ПО: aptitude install ifenslave ethtool Затем добавим модуль bonding в автозагрузку и пропишем опции для его запуска, для этого в конец файла /etc/modules добавим текст из примера ниже, примеров будет два: для создания одного интерфейса из двух физических и для создания двух интерфейсов из четырех физических. Подробнее о режимах работы bonding можно почитать здесь. Пример для одного виртуального интерфейса из двух физических: alias bond0 bonding options bonding mode=0 miimon=100 Пример для создания двух интерфейсов из четырех физических: alias bond0 bonding alias bond1 bonding options bonding mode=0 miimon=100 max_bonds=2 Затем загрузим модуль bonding ## Один виртуальный интерфейс modprobe bonding mode=0 miimon=100 ## Два виртуальных интерфейса modprobe bonding mode=0 miimon=100 max_bonds=2 Настроим параметры сетевых интерфейсов bonding`a, для этого отредактируем файл настроек интерфейсов /etc/network/interfaces. В примере шаблоны для настройки двух виртуальных интерфейсов. # The bond0 network interface auto bond0 allow-hotplug bond0 iface bond0 inet static address <ip-address> netmask <netmask> network <network-address> broadcast <broadcast-address> gateway <gateway-address> dns-nameservers <nameserver-one> <nameserver-two> dns-search <domain-name> up /sbin/ifenslave bond0 eth0 up /sbin/ifenslave bond0 eth1 # The bond1 network interface auto bond1 allow-hotplug bond1 iface bond1 inet static address <ip-address> netmask <netmask> network <network-address> broadcast <broadcast-address> gateway <gateway-address> dns-nameservers <nameserver-one> <nameserver-two> dns-search <domain-name> up /sbin/ifenslave bond1 eth2 up /sbin/ifenslave bond1 eth3 Более подробно по опциям файла /etc/network/interfaces можно прочитать выполнив команду man interfaces После того как прописаны настройки интерфейсов нужно перезапустить сеть командой /etc/init.d/networking restart и проверить, поднялись ли интерфейсы bond0, и если настраивали два, то bond1.   Превращение Cisco Catalyst 6500 в кабельный тестер (доп. ссылка 1)   Автор: Gleb Poljakov  [комментарии]   Некоторые карты для Cisco Catalyst имеют встроенный "кабельный тестер" - Time Domain Reflectometry (TDR). TDR может использоваться для определения обрывов в кабеле, неверно обжатых коннекторов, повреждений изоляции и др. TDR поддерживается следующими медными линейными картами: WS-X6748-GE-TX (48 port CEF720 10/100/1000 line card) WS-X6548-GE-TX/45AF (48 port CEF256 10/100/1000 line card) WS-X6148A-GE-TX/45AF (48 port Classic 10/100/1000 line card) WS-X6148-GE-TX/45AF (48 port Classic 10/100/1000 line card) WS-X6148A-RJ-45/45AF (48 port Classic 10/100 line card) Для тестирования кабеля необходимо выполнить две команды: 1. Первая - команда на тестирование порта: 6K-LV2-CL3# test cable-diagnostics tdr interface g1/3 TDR test started on interface Gi1/3 A TDR test can take a few seconds to run on an interface Use 'show cable-diagnostics tdr' to read the TDR results. 2. Вторая - вывод данных тестирования: 6K-LV2-CL3# show cable-diagnostics tdr interface g1/3 TDR test last run on: March 5 10:22:06 Interface Speed Pair Cable length Distance to fault Channel Pair status Gi1/3 1000 1-2 1 +/- 6 m N/A Pair B Terminated 3-4 1 +/- 6 m N/A Pair A Terminated 5-6 1 +/- 6 m N/A Pair C Terminated 7-8 1 +/- 2 m N/A Pair D Short в данном тесте пара 7-8 оказалась оборвана. Ссылки: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd805457cc.html   Конфигурирование bonding для сетевых интерфейсов на RHEL/CentOS 5 (доп. ссылка 1)   Автор: Roman Sozinov  [комментарии]   Конфигурация необходимых сетевых интерфейсов: * eth0 # cat > /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no [Ctrl+D] * eth1: # cat > /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no [Ctrl+D] * bond0: # cat > /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 BOOTPROTO=none ONBOOT=yes NETWORK=10.10.70.0 IPADDR=10.10.70.77 NETMASK=255.255.255.0 USERCTL=NO [Ctrl+D] Загружаем модуль и перегружаем сеть: # cat >> /etc/modprobe.conf alias bond0 bonding options bond0 mode=1 miimon=100 [Ctrl+D] # service network restart Просмотр статуса: # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Link Failure Count: 2 Permanent HW addr: 00:1b:11:50:7a:01 Slave Interface: eth1 MII Status: up Link Failure Count: 1 Permanent HW addr: 00:18:fe:8c:a1:96   Конфигурирование VLAN в RHEL/CentOS/Fedora и Debian/Ubuntu (доп. ссылка 1) (доп. ссылка 2)   Автор: Roman Shramko  [комментарии]   Ниже представлены примеры настройки VLAN через стандартные средства дистрибутивов Linux. RHEL, CentOS, Fedora Для начала необходимо описать базовый сетевой интерфейс, на котором мы будем поднимать VLAN. /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 # здесь нужно указать реальное имя интерфейса BOOTPROTO=static HWADDR=00:07:E9:A7:13:48 # здесь нужно указать реальный MAC ONBOOT=no TYPE=Ethernet IPADDR=0.0.0.0 NETMASK=255.255.255.0 Дла наших целей важны только два параметра: DEVICE и HWADDR. Остальное роли не играет. Можно даже заполнить "от балды". Далее, создаем подинтерфейсы для VLAN. Именование подинтерфейсов может быть двух видов: "vlanX" и "eth0.X". В первом случае, мы имеем описательное имя, которое не привязано к имени родительского интерфейса. Соответственно, перемещение VLAN на другой физический интерфейс не требует значительных изменений в конфигурацию системы (не нужно править правила пакетного фильтра и тд и тп). С другой стороны, при использовании имен вида "eth0.X" мы имеем более удобное (по моему мнению) имя интерфейса, по которому видно на каком родительском интерфейсе поднят VLAN, чем немного упрощается администрирование системы. Плюс, поскольку имя подинтерфейса базируется на имени физического, то мы имеем различные пространства имен для VLAN-ов. Я имею ввиду ситуацию, когда на разных интерфейсах приходят VLAN-ы с одинаковыми номерами. Использование "vlanX" в данном случае будет несколько затруднительно. Минусом будет то, что некоторые утилиты некорректно работают с именами интерфейсов с точкой в имени (например sysctl). Конфигурирование интерфейсов типа "vlanX" /etc/sysconfig/network-scripts/ifcfg-vlan10 VLAN=yes VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD DEVICE=vlan10 PHYSDEV=eth0 BOOTPROTO=static ONBOOT=yes TYPE=Ethernet IPADDR=10.10.10.2 NETMASK=255.255.255.252 Здесь: PHYSDEV - физический интерфейс, на котором работает VLAN. VLAN_NAME_TYPE - указываем тип наименование устройства. В данном случае номер VLAN будет браться с имени устройства. Возможные варианты: VLAN_PLUS_VID -vlan0010 VLAN_PLUS_VID_NO_PAD - vlan10 DEV_PLUS_VID - eth0.0010 DEV_PLUS_VID_NO_PAD - eth0.10 Конфигурирование интерфейсов типа "eth0.X" /etc/sysconfig/network-scripts/ifcfg-eth0.10 VLAN=yes DEVICE=eth0.10 BOOTPROTO=static ONBOOT=yes TYPE=Ethernet IPADDR=10.10.10.2 NETMASK=255.255.255.252 Все то же самое, но без PHYSDEV и VLAN_NAME_TYPE. Хочеться добавить, что смешать в одной системе "vlanX" и "eth0.X" штатными средствами вряд ли получится, т.к. тип именования (VLAN_NAME_TYPE) при инициализации интерфейсов задается по первому поднимаемому интерфейсу. Примеры для Debian, Ubuntu. Устанавливаем поддержку vlan: sudo apt-get install vlan В /etc/network/interfaces добавляем: # Какие интерфейсы поднимать автоматически auto vlan4 auto vlan5 auto vlan101 # VLAN 4 iface vlan4 inet static address 192.168.0.8 netmask 255.255.255.192 network 192.168.0.0 broadcast 192.168.0.63 mtu 1500 vlan_raw_device eth0 # VLAN 5 iface vlan5 inet static address 10.0.111.8 netmask 255.255.255.0 network 10.0.111.0 broadcast 10.0.111.255 mtu 1500 vlan_raw_device eth0 # VLAN 101 iface vlan101 inet static address 172.12.101.8 netmask 255.255.255.0 network 172.12.101.0 broadcast 172.12.101.255 gateway 172.12.101.1 mtu 1500 vlan_raw_device eth0   Восстановление потерянного Ethernet линка в Linux   [комментарии]   В офисе внезапно отключили электроэнергию. На одном из работающих в тот момент ноутбуков, после восстановления электричества, отказался подниматься сетевой линк. На свиче отображалось отсутствие физического линка. Замена патч-корда, переключение в другой порт, жесткая перезагрузка - не помогли. # mii-tool eth0 eth0: no link Пробуем инициировать autonegotiation: # mii-tool -r eth0 бесполезно. Решаемся испробовать опцию -R для переинициализации трансивера. # mii-tool -R eth0 и, о чудо !, линк поднялся.   MAC DNS лист   Автор: Vladimir Shingarev  [комментарии]   Иногда нужно узнать какому производителю принадлежит оконечное оборудование, наблюдая только его мак на интерфейсе. А открывать браузер для этого лениво. В таком случае удобно создать MAC-based dns лист. Пользоваться просто: ket:/home/sva# host -t txt 001243.macl.nov.ru 001243.macl.nov.ru descriptive text "Cisco" ket:/home/sva# host -t txt 0050ba.macl.nov.ru 0050ba.macl.nov.ru descriptive text "D-LINK"   Объединение сетевых интерфейсов при помощи протокола LACP во FreeBSD 7 (доп. ссылка 1)   Автор: s@sh@  [комментарии]   Собираем ядро с поддержкой LACP (Link aggregation control protocol): device lagg Объединяем интерфейсы em0 и em1: ifconfig em0 up ifconfig em1 up ifconfig lagg0 create ifconfig lagg0 up laggproto lacp laggport em0 laggport em1 ifconfig lagg0 10.10.10.18 netmask 255.255.255.0 route add -net 0.0.0.0 10.10.10.1 0.0.0.0 На Cisco и к каждому нужному интерфейсу прописываем: interface GigabitEthernet2/2 .... channel-protocol lacp channel-group 23 mode active interface GigabitEthernet2/16 .... channel-protocol lacp channel-group 23 mode active   Настройка Linux как Wifi шлюза для КПК (доп. ссылка 1)   Автор: Михаил Конник  [комментарии]   Linux шлюз: Нужно создать простую одноранговую ad-hoc сеть и дать статический IP-адрес сетевому беспроводному интерфейсу. После этого делаем NAT и всё работает. Для беспроводного интерфейса eth3 и сети с идентификатором virens команда выглядит так (от рута): # iwconfig eth3 mode Ad-Hoc channel 1 essid virens В /etc/network/interfaces пишем что-то вроде: auto eth3 iface eth3 inet static address 10.106.146.1 netmask 255.255.255.0 wireless-mode ad-hoc wireless-channel 1 wireless-rate auto wireless-essid virens Теперь делаем NAT: # echo 1 > /proc/sys/net/ipv4/ip_forward # iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE При этом eth1 это интерфейс, который подключён к Интернету. Соединение не шифруется. КПК: Необходимо задать essid - такой же, какой дали в iwconfig. Шифрование отсутствует, тип сети - одноранговая ad-hoc. Снимаем галку "Получать IP-адрес автоматически" и вводим адреса: IP-адрес: 10.106.146.2 Маска подсети: 255.255.255.0 Маршрутизатор: 10.106.146.1   Как "протянуть" 802.1q tagged порт через ip-сеть.   Автор: Roman Timofeev aka ^rage^  [комментарии]   Дано: Есть hostA, который воткнут в каталист, в trunk (т.е. тегированный) порт, инкапсуляция 802.1q. Есть hostB, который маршрут до hostA. маршрут живой, ip-пакеты между хостами безпроблемно бегают. Задача: надо с hostA "притащить" виланы на hostB. Решение: vtund + bridge. описание клиента в vtund.conf homepeer { passwd qwerty; type ether; device home; proto tcp; compress yes; stat yes; persist yes; up { ifconfig "%% up"; program "brctl addbr br0"; program "brctl addif br0 %%"; program "brctl addif br0 eth0"; ifconfig "br0 up"; }; down { ifconfig "%% down"; ifconfig "br0 down"; program "brctl delbr br0"; }; } описание пира из конфига сервера homepeer { passwd qwerty; # Password type ether; # Ethernet tunnel device work; # Device tap1 proto tcp; compress yes; up { ifconfig "%% up"; }; down { ifconfig "%% down"; }; } Теперь на той Linux машине, куда кидаем порт: vconfig set_name_type VLAN_PLUS_VID_NO_PAD vconfig add work 4 ifconfig vlan4 10.1.1.1 netmask 255.255.255.0 up vconfig add vlan4 8 ifconfig vlan8 192.168.1.1 netmask 255.255.255.0 up Замечание: Клиент - хост, с которого мы тащим порт. Он живёт в серой сети и имеет выход в internet через NAT. Сервер - машина с публичным ip.   Сброс счетчиков ifconfig в Linux   Автор: OlegOS (Очередин Олег)  [комментарии]   Если нужно сбросить счетчики пакетов/байт, отображаемые ifconfig, то есть из /proc/net/dev, нужно собрать драйвер сетевой карты в виде модуля (не в ядро). Для сброса опускаем интерфейс, выгружаем драйвер, загружаем снова и поднимаем интерфейс. Должно работать на всех картах. Пример. ifdown eth0 modprobe -r eepro100 modprobe eepro100 ifup eth0 Для того чтобы узнать имя драйвера обеспечивающего работу сетевого интерфейса: ethtool -i eth1   Привязка имени сетевого интерфейса к MAC адресу в Linux (доп. ссылка 1)   [комментарии]   При наличии нескольких одинаковых сетевых карт, чтобы гарантировать, что eth0, eth1,.. всегда будут закреплены за одними и теми же картами, можно огранизовать привязку имени к MAC адресу: В /etc/mactab добавляем: eth0 00:23:B7:89:39:E2 eth1 00:08:A3:20:F8:29 eth2 00:50:BA:29:B7:32 Для Debian GNU/Linux создаем скрипт /etc/network/if-pre-up.d/nameif #!/bin/sh PATH=/sbin nameif -c /etc/mactab Для других Linux дистрибутивов нужно на начальном этапе инициализаци выполнить: /sbin/nameif eth0 00:23:B7:89:39:E2 /sbin/nameif eth1 00:08:A3:20:F8:29 /sbin/nameif eth2 00:50:BA:29:B7:32   Как настроить сетевой мост во FreeBSD   [комментарии]   Предположим, имеется несколько сетевых интерфейсов fxp0,fxp1,fxp2,fxp3 вы хотите чтобы ваша машина выспупала в качестве сетевого моста: Первый способ на основе if_bridge(работает в 5-STABLE и 6-ке) # kldload if_bridge # ifconfig bridge0 create # ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 up # ifconfig fxp0 up # ifconfig fxp1 up # ifconfig fxp2 up # ifconfig fxp3 up Посмотреть # ifconfig bridge0 Подробнее в man if_bridge и man ifconfig Второй способ на основе bridge: # kldload bridge # sysctl net.link.ether.bridge.config=fxp0,fxp1,fxp2,fxp3 # sysctl net.link.ether.bridge.enable =1   Управление дуплексным режимом и скоростью линка в различных ОС. (доп. ссылка 1)   [комментарии]   Solaris Проверка: ndd /dev/hme link_mode 0 = half duplex, 1 = full duplex Установка full duplex: ndd -sec /dev/hme adv_100fdx_cap ndd -set /dev/hme adv_autoneg_cap 0 Установка half duplex: ndd -sec /dev/hme adv_100hdx_cap ndd -set /dev/hme adv_autoneg_cap 0 Linux Текущее состояние mii-tool eth0 ethtool eth0 Установка full duplex: mii-tool -F 100baseTx-FD eth0 ethtool -s eth0 speed 1000 duplex full autoneg off некоторые драйверы можно настроить через /etc/modules.conf options eepro100 options=48 options 3c59x options=0x204 full_duplex=0x200 FreeBSD Установка full duplex: ifconfig xl0 media 100baseTX mediaopt full-duplex Установка half duplex: ifconfig xl0 media 100baseTX mediaopt half-duplex IBM AIX Список адаптеров и проверка режима: lsdev -HCc adapter lsattr -d ent# Установка full duplex: chdev -l ent# -a media_speed=100_Full_Duplex -P Установка half duplex: chdev -l ent# -a media_speed=100_Half_Duplex -P HP-UX Список адаптеров и проверка режима: lanscan -n (HP-UX 10.x) lanscan -p (HP-UX 11.x) lanadmin -x NMid# (HP-UX 10.x) lanadmin -x PPA# (HP-UX 11.x) Установка full duplex: lanadmin -X 100FD NMid# (HP-UX 10.x) lanadmin -X 100FD PPA# (HP-UX 11.x) Установка half duplex: lanadmin -X 100HD NMid# (HP-UX 10.x) lanadmin -X 100HD PPA# (HP-UX 11.x)   Проброс трафика через Linux машину используя Proxy ARP (доп. ссылка 1) (доп. ссылка 2)   [комментарии]   Пусть: x.x.x.96/28 - выделенная подсеть, которую нужно распределить по машинам в локальной сети. x.x.x.97 - IP внешнего шлюза. Требуется поставить между шлюзом и сетью фаервол, с одним адресом на двух интерфейсах x.x.x.98, транслируя ARP трафик используя "Proxy ARP". (x.x.x.99 ... x.x.x.110) --- (eth1, x.x.x.98 | eth0, x.x.x.98) --- (x.x.x.97) Удаляем маршруты созданные по умолчанию. ip route del x.x.x.96/28 dev eth0 ip route del x.x.x.96/28 dev eth1 Пакеты для x.x.x.97 пускаем через eth0, а для x.x.x.96/28 через eth1 ip route add x.x.x.97 dev eth0 ip route add x.x.x.96/28 dev eth1 Включаем Proxy ARP echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp   Объединение сетевых интерфейсов под Linux (доп. ссылка 1)   [комментарии]   Превращение двух 100 мбит/c сетевых карт в одну виртуальную, с пропускной способностью 200 мбит/c. Документация: Documentation/networking/bonding.txt в дереве исходных текстов ядра и "modinfo bonding". Кратко: Подгружаем модуль ядра "bonding", в /etc/modules.conf указываем alias bond0 bonding При желании устанавливаем опции для доп. настройки модуля, например: options bond0 mode=2, где mode= 0 - balance-rr (Round-robin выбор интерфейса) 1 - active-backup (работает только один интерфейс, остальные в режиме горячей замены) 2 - balance-xor - для всех пересылок на MAC закрепляется один из интерфейсов 3 - broadcast - трафик идет через оба интерфейса одновременно 4 - 802.3ad - для коммутаторов с поддержкой IEEE 802.3ad Dynamic link aggregation 5 - balance-tlb, 6 - balance-alb /sbin/ifconfig bond0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up /sbin/ifenslave bond0 eth0 /sbin/ifenslave bond0 eth1 Или для дистрибутивов в которых используется пакет initscripts (http://rhlinux.redhat.com/initscripts/): /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 BOOTPROTO=static BROADCAST=192.168.63.255 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.0.0 ONBOOT=yes /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 BOOTPROTO=static ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no   Объединение сетевых интерфейсов под FreeBSD 5.x (доп. ссылка 1)   Автор: Мишка  [комментарии]   Превращение двух 100 мбит/c сетевых карт в одну виртуальную, с пропускной способностью 200 мбит/c . kldload /boot/kernel/ng_ether.ko kldload /boot/kernel/ng_one2many.ko ifconfig rl0 up ifconfig rl1 up ngctl mkpeer rl0: one2many upper one ngctl connect rl0: rl0:upper lower many0 ngctl connect rl1: rl0:upper lower many1 ngctl msg rl1: setpromisc 1 ngctl msg rl1: setautosrc 0 ngctl msg rl0:upper \ setconfig "{ xmitAlg=1 failAlg=1 enabledLinks=[ 1 1 ] }" ifconfig rl0 inet 192.168.0.78   Привязка IP к MAC адресу (доп. ссылка 1)   Автор: Krigs  [комментарии]   Я сделал так (идею тоже нашел на этом сайте): 1. Создал файл б/д привязки IP к MAC (например /etc/ethers.local) Пример строк из файла: 192.168.0.11 00:0c:6e:3f:cd:e5 #kasa2 192.168.0.12 00:0d:88:82:da:a2 #mobil и т. д. 2. Написал скрипт такого содержания: (например /etc/static.arp): #!/bin/sh # обнуляем всю таблицу arp arp -ad > null # к каждому компу в локальной сети привязываем несуществующий (нулевой) # MAC адрес I=1 while [ $I -le 254 ] do arp -s 192.168.0.${I} 0:0:0:0:0:0 I=`expr $I + 1` done # к реально существующему компу в сети из базы данных в файле # /etc/ethers.local привязываем # правильный MAC адрес arp -f /etc/ethers.local 3. Делаем этот файл исполняемым и прописываем в файл /etc/rc.local такую строчку: /etc/static.arp Еще желательно, чтобы привязки имен юзерских хостов к ip-адресам были прописаны в /etc/hosts (это ускорит их поиск). Теперь сервер не будет рассылать широковещательные запросы о локальных MAC адресах, т. к. все они статически жестко привязаны к ip-адресам. Этим убивается два зайца: не рассылаются широковещательные запросы, что экономит траффик и время на ответ сервера, и не позволяет пользователю менять свой ip-адрес, т. к. сервер все равно пакет будет отправлять на жестко привязанный MAC адрес.   Включение Device Polling в FreeBSD (доп. ссылка 1)   [комментарии]   man polling - периодических опрос состояния ядром, вместо генерации прерываний (полезно при очень большом числе пакетов проходящих через сетевую карту), возможен комбинированный вариант, когда polling включается при преодалении определенного порога нагрузки). В конфигурации ядра options DEVICE_POLLING options HZ=1000 Далее: sysctl kern.polling.enable=1 sysctl kern.polling.user_frac=50   Смена скорости (10/100) и duplex (full/half) на сетевых картах Realtek-8139   Автор: Alexey N. Kovyrin  [комментарии]   1) Duplex можно менять параметром full-duplex модуля 8139too: full-duplex=1 (Full-Duplex) full-duplex=0 (Half-Duplex) 2) Также существует параметр media, который является набором битовых полей: 5-й бит: 1=100Mbps / 0=10Mbps 4-й бит: 1=Full-Duplex / 0=Half-Duplex 9-й бит: Форсированная установка параметра duplex (1=Force / 0=Don't Force) 9-й бит используется только вместе с 4-м. 3) Примеры: modprobe 8139 full-duplex=1 (100Mbps Full-Duplex) modprobe 8139 full-duplex=0 (100Mbps Half-Duplex) modprobe 8139 media=16 (10Mbps Full-Duplex) modprobe 8139 media=48 (100Mbps Full-Duplex) modprobe 8139 media=32 (100Mbps Half-Duplex) modprobe 8139 media=32 (100Mbps Half-Duplex) modprobe 8139 media=0 (10Mbps Half-Duplex)   С чем может быть связаны потери пакетов и нестабильная работа ethernet карт ? (доп. ссылка 1)   [комментарии]   Приходилось сталкиваться с проблемами согласования режимов работы карт Intel EtherExpress 100 и Reltek RTL-8139 c коммутаторами и концентраторами различных производителей. Несогласование проявляется, например в работе карты в режиме half-duplex, а свича в full-duplex и т.д. (в linux: /sbin/mii-tool -F 100baseTx-FD eth0)   Как в Linux выставить принудительно 100Mb FullDuplex для Intel EtherExpress Pro100, а то auto-select с некоторыми свичами не работает. (доп. ссылка 1)   [обсудить]   /sbin/mii-tool -F 100baseTx-FD eth0 или ethtool -s eth0 speed 100 duplex full autoneg off Для модуля: В /etc/modules.conf: options eepro100 options=0x200 full_duplex=1 alias eth0 eepro100 insmod eepro100.o debug=1 options=0x200 Для ядра в boot приглашении: ether=0,0,0x200,eth0 PS. Для драйвера версии меньше 1.14 (mod_info -a eepro100) вместо 0x200 следует писать 0x30.   Почему выкачиваются данные с машины нормально, как только пытаюсь что-то закачать - соединение останавливается, даже через ssh больше 5 мин. не удается поработать. Другие машины работают нормально.   [комментарии]   Неоднократно замечена проблема работы сетевых карт на базе RealTek 8129/8139 (машины под FreeBSD, но с другими ОС тоже проявляется) с некоторыми концентраторами и коммутаторами. Проявляется в замирании сессий до истечения таймаута. Диагностика: ping -s N remote_ip, при больших N не проходят. Решение: Смените сетевую карту, например, на Intel EtherExpress Pro.   Как переключить сетевую карту в FreeBSD из full-duplex в half-duplex   [комментарии]   Текущий режим работы сетевой карты можно посмотреть выполнив: # ifconfig fxp0 Перевести сетевую карту в режим работы 10baseT/UTP half-duplex: # ifconfig fxp0 media 10baseT/UTP mediaopt half-duplex Автоматически выбрать режим: # ifconfig fxp0 media autoselect Подробнее: man 4 ed, man 4 rl, man 4 fxp   Объединение сетевых интерфейсов в Gentoo Linux (доп. ссылка 1)   Автор: Sheridan  [комментарии]   Довольно часто бывает, что пропускной способности не хватает. Если у вас нет гигабитной сетевой карты (или порта на свиче), не расстраивайтесь. Можно вставить в компьютер еще 1-2 сетевухи и объединить интерфейсы в один. Данная операция называется bonding. Так как под рукой у меня только Gentoo, то могу привести алгоритм объединения интерфейсов только для него. Итак. 1. emerge ifenslave 2. Редактируем /etc/conf.d/net: 2.1 Комментируем текущий конфиг 2.2 Пишем следующее: slaves_bond0="eth0 eth1" config_bond0=( "192.168.1.101 netmask 255.255.255.0 brd 192.168.1.255" ) routes_bond0=( "default gw 192.168.1.11" ) config_bond0 и routes_bond0 берем из закомментированного конфига (скорее всего это будет config_eth0 и routes_eth0). То есть настраиваем bond0 как обычный интерфейс 3. Делаем симлинк из /etc/init.d/net.lo в /etc/init.d/net.bond0 4. Проверяем: ~# /etc/init.d/net.eth0 stop ~# /etc/init.d/net.bond0 start 5. Если все нормально, то добавляем старт интерфейса при загрузке ~# rc-update -d net.eth0 ~# rc-update -a net.bond0 boot Все, скорость линка должна возрасти.   Дублирование сервера с использованием VRRP (доп. ссылка 1)   Автор: Ron McCarty  [комментарии]   Имеется два сервера - первичный и запасной. При помощи протокола VRRP (Virtual Router Redundancy Protocol) при крахе первичного сервера, автоматически поднимаем его MAC и IP на запасном. Устанавливаем vrrpd (http://sourceforge.net/projects/vrrpd/). На первичном сервере выполняем: vrrpd -i eth0 -p 25 -v 1 192.168.1.1 На запасном: vrrpd -i eth0 -p 24 -v 1 192.168.1.1 ,где -i eth0 - имя интерфейса на котором будет установлен IP 192.168.1.1 -v 1 - (virtual router) номер VRRP связки (в локальной сети может быть несколько резервирующих друг-друга систем) -p N - приоритет, машина с меньшим весом будет активирована, только при недоступности системы с большим весом. При тестировании можно использовать tcpdump -vv proto 112   Как привязать IP к MAC-адресу сетевой карты (доп. ссылка 1)   Автор: Dima I. Allaverdov  [комментарии]   arp -s ваш.ip.адрес mac.адрес.сетевой.карты pub Пример: /usr/sbin/arp -s 192.168.0.10 0:0:e7:ac:4c:63 pub Начиная с FreeBSD 4.10 в ifconfig доступна опция staticarp, заставляющий интерфейс только отвечать на ARP запросы для привязанных к нему адресам.

NAT, трансляция адресов

Определение IP-адреса пользователя в Telegram через голосовой вызов (доп. ссылка 1) (доп. ссылка 2)   [комментарии]   По умолчанию Telegram устанавливает прямой канал связи при осуществлении голосового вызова пользователя, присутствующего в адресной книге (в настройках можно выборочно отключить использование P2P и направлять трафик только через внешний сервер). При инициировании соединения для обхода NAT в Telegram применяется протокол STUN (Session Traversal Utilities for NAT), который передаёт информацию об адресах звонящего и принимающего звонок в поле XOR-MAPPED-ADDRESS. Соответственно, если в настройках "Security and Privacy" не отключён P2P, звонящий может узнать IP-адрес того, кому адресован звонок. Метод подойдёт и для любых других приложений, использующих STUN. Для определения IP-адреса следует во время осуществления вызова записать дамп трафика в формате pcap, например, при помощи утилиты tcpdump или tshark, после чего воспользоваться готовым скриптом https://github.com/n0a/telegram-get-remote-ip/ или при помощи штатных утилит проанализировать значение поля XOR-MAPPED-ADDRESS: tshark -w dump.pcap -a duration:5 cat dump.pcap | grep "STUN 106" | sed 's/^.*XOR-MAPPED-ADDRESS: //' | awk '{match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/); ip = substr($0,RSTART,RLENGTH); print ip}' | awk '!seen[$0]++'   Мультиплексирование ssl/ssh соединений через один 443 порт (доп. ссылка 1)   [комментарии]   В рамках проекта sslh (http://www.rutschle.net/tech/sslh.shtml) развивается мультиплексор ssl/ssh соединений, способный принимать соединения на одном порту и перебрасывать их в зависимости от типа протокола. Поддерживается широкий спектр протоколов, среди которых HTTP, HTTPS, SSH, OpenVPN, tinc и XMPP. Наиболее востребованным применением sslh является обход межсетевых экранов, допускающих только ограниченное число открытых портов. Например, запустив sslh за пределами межсетевого экрана на 443 порту, можно организовать работу SSH и любых других протоколов: соединение с внешней системы будет производиться на 443 порт, но пробрасываться на локальный 22 порт, при этом штатные HTTPS-запросы будут перебрасываться на localhost:443. Для обеспечения работы такой схемы sslh следует запустить с опциями: sslh --user sslh --listen 192.168.10.15:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:443 где, "--user sslh" определяет пользователя, под которым следует запустить sslh; "--listen 192.168.10.15:443" - IP и порт для приёма внешних соединений; "--ssh 127.0.0.1:22" - IP и порт для проброса SSH "--ssl 127.0.0.1:443" - IP и порт для проброса HTTPS   Проброс 802.1q/access порта в Linux через IP-сеть   Автор: Roman Timofeev  [комментарии]   В 2007 году я написал заметку с похожим названием. Тогда использовалась userspace-реализация с tap-интерфейсом и демоном vtund. Особой производительностью этот вариант не отличался. В свежих ядрах Linux появилась поддержка l2tpv3 ethernet pseudowire. Организуем l2-линк с udp-инкапсуляцией между двумя хостами laptus и gw: laptus# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \\ udp_dport 5000 encap udp local 192.168.1.39 remote 213.x.x.x laptus# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1 laptus# ip a a 192.168.30.2/24 dev l2tpeth0 gw# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \\ udp_dport 11932 encap udp local 213.x.x.x remote 188.134.x.x gw# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1 gw# ip a a 192.168.30.1/24 dev l2tpeth0 (так как машина laptus на NAT, то пришлось сначала сконфигурировать туннель на нём и запустить ping 192.168.30.1 и на внешнем интерфейсе gw "подсмотреть" ip:port, в который оттранслировались пакеты на выходе. Если у вас на обоих концах публичные ip - всё просто). Теперь попробуем сделать что-то полезное: laptus# ip link add link l2tpeth0 name vlan5 type vlan id 5 laptus# ip link add link l2tpeth0 name vlan6 type vlan id 6 laptus# ip a a dev vlan5 10.1.5.2/24 laptus# ip a a dev vlan6 10.1.6.2/24 gw# ip link add link l2tpeth0 name vlan5 type vlan id 5 gw# ip link add link l2tpeth0 name vlan6 type vlan id 6 gw# ip a a dev vlan5 10.1.5.1/24 gw# ip a a dev vlan6 10.1.6.1/24 laptus# ping 10.1.6.1 PING 10.1.6.1 (10.1.6.1) 56(84) bytes of data. 64 bytes from 10.1.6.1: icmp_req=1 ttl=64 time=5.77 ms 64 bytes from 10.1.6.1: icmp_req=2 ttl=64 time=13.4 ms 64 bytes from 10.1.6.1: icmp_req=3 ttl=64 time=17.6 ms ^C --- 10.1.6.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 5.776/12.295/17.671/4.922 ms при этом tcpdump -e -n -i l2tpeth0 на gw покажет: 16:44:30.055082 b2:19:70:63:90:85 > 76:a9:12:12:c7:30, ethertype IPv4 (0x0800), length 98: 192.168.30.2 > 192.168.30.1: ICMP echo request, id 26927, seq 1376, length 64 16:44:30.055116 76:a9:12:12:c7:30 > b2:19:70:63:90:85, ethertype IPv4 (0x0800), length 98: 192.168.30.1 > 192.168.30.2: ICMP echo reply, id 26927, seq 1376, length 64 16:44:30.990689 b2:19:70:63:90:85 > 76:a9:12:12:c7:30, ethertype 802.1Q (0x8100), length 102: vlan 6, p 0, ethertype IPv4, 10.1.6.2 > 10.1.6.1: ICMP echo request, id 27037, seq 2, length 64 16:44:30.990734 76:a9:12:12:c7:30 > b2:19:70:63:90:85, ethertype 802.1Q (0x8100), length 102: vlan 6, p 0, ethertype IPv4, 10.1.6.1 > 10.1.6.2: ICMP echo reply, id 27037, seq 2, length 64 l2tpeth можно объединить бриджом с физическим интерфейсом. выглядит это примерно так: root@atomus:~# ip a s l2tpeth0 7: l2tpeth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vl0 state UNKNOWN qlen 1000 link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff root@atomus:~# ip a s vl0 9: vl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff inet 10.1.1.10/24 brd 10.1.1.255 scope global vl0 root@atomus:~# ip a s vlan5 11: vlan5@vl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff inet 10.1.5.10/24 brd 10.1.5.255 scope global vlan5 root@atomus:~# ip a s vlan222 12: vlan222@vl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 1e:7f:ec:bd:cf:6a brd ff:ff:ff:ff:ff:ff inet 10.1.222.10/24 brd 10.1.222.255 scope global vlan222 root@atomus:~# brctl show bridge name bridge id STP enabled interfaces vl0 8000.1e7fecbdcf6a no l2tpeth0 root@gw:~# ip a s vlan222 68: vlan222@l2tpeth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1488 qdisc noqueue state UP link/ether c6:8c:43:30:88:03 brd ff:ff:ff:ff:ff:ff inet 10.1.222.1/24 brd 10.1.222.255 scope global vlan222 root@gw:~# ip a s l2tpeth0 64: l2tpeth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether c6:8c:43:30:88:03 brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/24 brd 10.1.1.255 scope global l2tpeth0 root@atomus:~# ping 10.1.5.1 PING 10.1.5.1 (10.1.5.1) 56(84) bytes of data. 64 bytes from 10.1.5.1: icmp_req=1 ttl=64 time=6.37 ms 64 bytes from 10.1.5.1: icmp_req=2 ttl=64 time=5.53 ms ...... root@atomus:~# ping 10.1.222.1 PING 10.1.222.1 (10.1.222.1) 56(84) bytes of data. 64 bytes from 10.1.222.1: icmp_req=1 ttl=64 time=10.0 ms 64 bytes from 10.1.222.1: icmp_req=2 ttl=64 time=4.24 ms ..... Как видим, к нам приходит тегированный трафик: root@gw:~# tcpdump -n -e -i l2tpeth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on l2tpeth0, link-type EN10MB (Ethernet), capture size 65535 bytes 19:21:33.962979 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 139, length 64 19:21:33.963047 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 139, length 64 19:21:33.986660 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 222, p 0, ethertype IPv4, 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 149, length 64 19:21:33.986698 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype 802.1Q (0x8100), length 102: vlan 222, p 0, ethertype IPv4, 10.1.222.1 > 10.1.222.10: ICMP echo reply, id 3764, seq 149, length 64 19:21:35.165848 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 140, length 64 19:21:35.165903 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4, 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 140, length 64 19:21:35.168489 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype 802.1Q (0x8100), length 102: vlan 222, p 0, ethertype IPv4, 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 150, length 64 ... а тут уже тегов нет: root@gw:~# tcpdump -n -e -i vlan5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan5, link-type EN10MB (Ethernet), capture size 65535 bytes 19:22:17.038686 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 182, length 64 19:22:17.038759 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 182, length 64 19:22:18.041890 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.5.10 > 10.1.5.1: ICMP echo request, id 3765, seq 183, length 64 19:22:18.041935 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.5.1 > 10.1.5.10: ICMP echo reply, id 3765, seq 183, length 64 root@gw:~# tcpdump -n -e -i vlan222 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan222, link-type EN10MB (Ethernet), capture size 65535 bytes 19:23:14.155061 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 249, length 64 19:23:14.155100 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.222.1 > 10.1.222.10: ICMP echo reply, id 3764, seq 249, length 64 19:23:15.150799 1e:7f:ec:bd:cf:6a > c6:8c:43:30:88:03, ethertype IPv4 (0x0800), length 98: 10.1.222.10 > 10.1.222.1: ICMP echo request, id 3764, seq 250, length 64 19:23:15.150833 c6:8c:43:30:88:03 > 1e:7f:ec:bd:cf:6a, ethertype IPv4 (0x0800), length 98: 10.1.222.1 > 10.1.222.10: ICMP echo reply, id 3764, seq 250, length 64 если требуется "протащить" несколько trunk-интерфейсов, то достаточно сказать: ip l2tp add session tunnel_id 1 session_id 2 peer_session_id 2 В рамках одно туннеля может быть 65535 сессий.   Выявление NAT-устройства в сети   Автор: Kirill  [комментарии]   Значения TTL в популярных ОС известны (http://www.binbert.com/blog/2009/12/default-time-to-live-ttl-values/), например, в Linux 2.6.x и FreeBSD - 64, в Windows - 128. Если в сети имеется маршрутизатор на базе *nix или если есть возможность завернуть трафик на определенный хост, или настроен PBR на прозрачный прокси - на этой машине нужно выполнить: # tcpdump -vv -n -i @interface@ 'ip[7:2] != 128 and ip[7:2] != 64' Соответственно, если пакеты приходят с вашего маршрутизатора после PBR, значение TTL нужно уменьшить на 1. Но эта информация неточная, так как TLL в ОС можно поменять. Также полезным дополнением внутри этой команды будет 'src net @ваша внутренняя сеть@' и 'src net not @сеть, которую нужно исключить@'.   Организация доступа к IPTV через NAT (доп. ссылка 1)   Автор: Антон Каукин  [комментарии]   Инструкция для желающих настроить Multicast Routing на Linux шлюзе, обеспечивающем работу клиентов через NAT. Для переброса IGMP-трафика между подсетями будем использовать демон igmpproxy (http://sourceforge.net/projects/igmpproxy) Ставим IGMP Proxy из пакетов используемого дистрибутива или устанавливаем из исходных текстов: # tar -zxf igmpproxy-src-0.1.tar.gz # cd igmpproxy/ # less README # cd src/ # make && make install Правим файл конфигурации /etc/igmpproxy.conf. В представленном примере, интерфейс eth0 смотрит в публичную сеть провайдера Mig Telecom, а eth1 в домашнюю сеть. # Enable Quickleave mode (Sends Leave instantly) # Эту строчку раскомментируют только в том случае, # если внути всего лишь один клиент IP TV #quickleave # Configuration for eth0 (Upstream Interface) # Здесь указаны параметры для публичного интерфейса, # на который придет поток от провайдера phyint eth0 upstream ratelimit 0 threshold 1 altnet 10.20.0.0/16 altnet 88.210.40.0/24 altnet 80.240.211.0/22 # Configuration for eth1 (Downstream Interface) # Типовая конфигурация для внутреннего интерфейса phyint eth1 downstream ratelimit 0 threshold 1 # Configuration for eth2 (Disabled Interface) # eth2 в системе есть, но не используется никем, отключаем phyint eth2 disabled Запускаем igmpproxy и переходим к небольшой конфигурации IPTables. Вот этот набор правил понадобился для корректной работы пакетного фильтра, разрешается весь входящий мультикст, разрешается его форвардинг и плюс ко всему добавляем в TTL 1, без этого добавления не работает если пакеты от провайдера приходят с минимально выставленным TTL. modprobe ipt_TTL iptables -t filter -A INPUT -d 224.0.0.0/240.0.0.0 -i eth0 -j ACCEPT iptables -t filter -A INPUT -s 224.0.0.0/240.0.0.0 -i eth0 -j ACCEPT iptables -t filter -A FORWARD -d 224.0.0.0/240.0.0.0 -j ACCEPT iptables -t filter -A FORWARD -s 224.0.0.0/240.0.0.0 -j ACCEPT iptables -t mangle -A PREROUTING -d 224.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1   Настройка пакетного фильтра PF для проброса SIP-телефонов через NAT (доп. ссылка 1) (доп. ссылка 2)   Автор: argo  [комментарии]   Во FreeBSD для включения PF указываем в /etc/rc.conf: pf_enable="YES" При необходимости выделения гарантированной полосы пропускания для голосового трафика задействуем ALTQ. Пересобираем ядро с поддержкой ALTQ, указав в конфигурации: options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build Далее для организации NAT для машин с SIP телефонами используем следующие настройки пакетного фильтра (/etc/pf.conf): # Вернет ошибку, порт заблокирован set block-policy return # тайм-аут UDP сессии должен быть равен или больше, чем время регистрации SIP # Таймер тайм-аута. Обычно достаточно 300 секунд. set timeout { udp.first 300, udp.single 150, udp.multiple 900 } # переменные int_if = "fxp0" ext_if = "fxp1" int_net = "192.168.1.0/24" ipphone1 = "192.168.1.18" ipphone2 = "192.168.1.19" # Включим очереди для внешнего интерфейса. Отделим голосовой трафик от данных altq on $ext_if hfsc bandwidth 512Kb queue { q_voice, q_other } queue q_voice bandwidth 3.84Kb priority 6 hfsc(realtime 96Kb) queue q_other bandwidth 416Kb hfsc { q_pri, q_std, q_low } queue q_pri bandwidth 200Kb priority 3 hfsc(red realtime 64Kb) queue q_std bandwidth 200Kb priority 2 hfsc(default red ) queue q_low bandwidth 3.84Kb priority 1 hfsc(red ) # Для каждого IP- телефона свое правило трансляции nat. # Параметр static-port нужен для сохранения временного порта UDP. # Это нужно чтобы удаленный SIP прокси знал к какой сессии привязан наш IP телефон. nat on $ext_if proto udp from $ipphone1 to any -> ($ext_if) static-port nat on $ext_if proto udp from $ipphone2 to any -> ($ext_if) static-port # Правило NAT для остальных устройств локальной сети nat on $ext_if from $int_net to any -> ($ext_if) pass in quick on lo0 all pass out quick on lo0 all # Разрешаем SIP трафик с телефонов на локальном интерфейсе pass in quick on $int_if proto udp from $ipphone1 to any tag VOIP keep state pass in quick on $int_if proto udp from $ipphone2 to any tag VOIP keep state pass in quick on $ext_if proto tcp from any to any port 22 keep state \ queue(q_std,q_pri) pass in quick on $ext_if proto tcp from any to any port 80 keep state \ queue q_low pass out quick on $ext_if tagged VOIP queue q_voice keep state pass out quick on $ext_if proto tcp from any to any port 22 keep state \ queue(q_std,q_pri) pass out quick on $ext_if proto tcp from any to any flags S/SA keep state \ queue(q_std,q_pri) pass out quick on $ext_if proto udp from any to any port 53 queue q_pri \ keep state # Разрешаем с внешнего интерфейса наружу tcp, udp, icmp pass out quick on $ext_if proto { tcp, udp, icmp } all keep state block in log all Конфигурация была протестирована на VoIP телефоне Cisco 7960, NAT прокси и outbound_proxy не используются, в телефоне настроен прокси-сервер SIP и порт контроля 5060/udp. Функция STUN в телефоне включена, хотя некоторые коммерческие SIP-прокси могут работать без него. Проверить очереди: pfctl -vsq -v Очистить таблицы состояний: pfctl -F state Проверка правил: pfctl -s rules -v   Трансляция адресов во FreeBSD средствами ng_nat (доп. ссылка 1)   Автор: Folio  [комментарии]   Для работы этого примера необходимо иметь подгруженный ng_ipfw.ko Убедиться в его наличии можно командой: /sbin/kldstat| grep ng_ipfw.ko Если ng_ipfw.ko не загружен, то загружаем его: /sbin/kldload /boot/kernel/ng_ipfw.ko После того как ng_ipfw.ko подгружен, в выводе команды: /usr/sbin/ngctl list появится строчка вида: Name: ipfw Type: ipfw ID: 00000023 Num hooks: 2 Без загруженного ng_ipfw.ko при попытке выполнить команды ngctl'а вы будете получать сообщение: ngctl: send msg: No such file or directory а при попытке добавить правило в ipfw получите: ipfw: getsockopt(IP_FW_ADD): Invalid argument Настройка ng_nat проста и сводится к скрипту: Для примера будем NAT'ить подсеть 172.16.5.96/27 через IP-адрес 192.168.20.8 на внешнем интерфейсе fxp0. #!/usr/bin/perl $ip='192.168.20.8'; $iface='fxp0'; $net='172.16.5.96/27'; $cmd=sprintf("/usr/sbin/ngctl -f - << -EOF mkpeer ipfw: nat 60 out name ipfw:60 nat connect ipfw: nat: 61 in msg nat: setaliasaddr %s ",$ip); system($cmd); ###добавляем необходимые правила в firewall $cmd=sprintf("/sbin/ipfw add 1000 netgraph 61 all from any to %s via %s in",$ip,$iface); system($cmd); $cmd=sprintf("/sbin/ipfw add 1010 netgraph 60 all from %s to any via %s out",$net,$iface); system($cmd); где: $ip - IP адрес, через который будет работать нат (который смотрит в интернет) $iface - ваш внешний интерфейс $net - IP подсеть, которую мы собираемся NAT'ить netgraph - правило в firewall, аналогично divert, только перенаправляет трафик не в socket, а в ноду netgraph, 60, 61 - адреса исходящего и входящего хуков. Если делать руками в консоли, то команды выглядят следующим образом: ###создаем ноду nat и подключаем к ipfw /usr/sbin/ngctl mkpeer ipfw: nat 60 out ###даем ноде имя "natA" /usr/sbin/ngctl name ipfw:60 natA ###соединяем входящие и исходящие хуки для "natA" /usr/sbin/ngctl connect ipfw: natA: 61 in ###посылаем управляющее сообщение в виде IP адреса, через который будет работать нат. /usr/sbin/ngctl msg natA: setaliasaddr 192.168.20.8 Если все работает, то мы можем посмотреть вывод следующей команды: ngctl show natA: Также можно посмотреть все целиком: ngctl list Для выключения настроенного NAT нужно выполнить команду: ngctl shutdown natA: Заметка: Если вы хотите запустить NAT на нескольких внешних IP-адресах, но не забывайте изменять имена нод (в примере natA) и номера хуков (в примере 60,61) т.к. они должны быть уникальны для каждого из процессов. Не путайте in и out в создаваемой ноде и правилах ipfw. Чтиво: man 8 ipfw Все о Netgraph (http://citrin.ru/netgraph/) man 4 netgraph man 4 ng_ipfw   Port mapping и открытие портов наружу во FreeBSD 7.1 (ipfw + kernel nat)   Автор: reZon  [комментарии]   Для начала надо пересобрать ядро со следующими опциями options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPDIVERT options IPFIREWALL_FORWARD options DUMMYNET options IPFIREWALL_NAT #ipfw kernel nat support options LIBALIAS Далее пересобираем ядро: cd /usr/src/ make buildkernel KERNCONF=Yourkernel && make installkernel KERNCONF=Yourkernel shutdown -r now Далее кусок файла конфигурации с примером. 192.168.1.132 - ip адрес сетевой карты смотрящей наружу останое внутренние адреса #!/bin/sh # здесь просто удаляю старые правила ipfw -f flush ipfw nat 122 delete # разрещаю все через loopback ipfw add allow all from any to any via lo0 # делаю нат на ip смотрящем наружу, same_ports - для попытки сохранить номера портов при нате ipfw nat 123 config ip 192.168.1.132 log same_ports \ # пробрасываю все что приходит на порт 9999 на тот же порт внутренней машины # как вариант можно указать -redirect_port tcp 192.168.4.86:9999 192.168.1.132:9999 redirect_port tcp 192.168.4.86:9999 9999 # этот кусок нужен что бы у машины был не полный нат а только порт который я разрешил, # потому что вообще в интернет буду пускать через проксю. ipfw add 100 nat 123 tcp from 192.168.4.86 9999 to any ipfw add 100 nat 123 tcp from any to 192.168.4.86 9999 # здесь я разрешаю клиенту с ip 192.168.4.86 коннектится к любым серверам по 25 порту, # но только по нему. ipfw add 100 nat 123 tcp from 192.168.4.86 to any 25 # это что бы был нат, иначе ничего не будет работать, правило для выпуска клиентов наружу ipfw add 100 nat 123 ip from any to 192.168.1.132 Основанно на http://www.opennet.me/tips/info/1618.shtml   Интернет-шлюз с использованием PF   Автор: vitalic  [комментарии]   O пакетном фильтре (PF) написано довольно много статей. Вот и я хочу предложить свою реализацию Интернет-шлюза с использованием PF. Раздача Интернета для локальной сети происходит через NAT и основана на Packet Tagging. Плюсом этого метода является то что упрощается настройка правил для FTP (ftp-proxy не используется), как для клиентов за шлюзом, так и для возможной публикации "внутреннего" ftp-сервера в мир. Для простоты приведу пример с 1 внешним и 1 внутренним интерфейсом. На шлюзе также запущен DNS-сервер. Пользователям локальной сети разрешен доступ на все порты без исключений по протоколам TCP, UDP, из ICMP разрешен только ping. В качестве ОС выступает FreeBSD7.0 Для начала определим интерфейсы с помощью макросов ext_if="rl0" int_if="sk1" dns="ААА.ААА.ААА.ААА" lan="192.168.1.0/24" table <no_if> {BBB.BBB.BBB.BBB, 192.168.1.1, 127.0.0.1} persist set skip on lo set loginterface rl0 set ruleset-optimization basic set block-policy return scrub in all no-df random-id ##### INET FOR LAN nat on $ext_if tag LAN_INET_NAT_TCP_UDP tagged LAN_INET_TCP_UDP -> $ext_if:0 nat on $ext_if tag LAN_INET_NAT_ICMP tagged LAN_INET_ICMP -> $ext_if:0 ###### block in block out antispoof quick for { lo $int_if } ############## EXT_IF_OUT pass out quick on $ext_if inet tagged LAN_INET_NAT_TCP_UDP pass out quick on $ext_if inet tagged LAN_INET_NAT_ICMP pass out quick on $ext_if inet proto {tcp udp} from $ext_if to $dns port = dns pass out quick on $ext_if inet proto icmp from $ext_if to any icmp-type echoreq ############## EXT_IF_IN pass in quick on $ext_if inet proto tcp from any to $ext_if port = ssh synproxy state (max 10) pass in quick on $ext_if inet proto icmp from any to $ext_if icmp-type echoreq ############## INT_IF_IN pass in quick on $int_if inet proto {tcp udp} from $lan to !<no_if> tag LAN_INET_TCP_UDP pass in quick on $int_if inet from $lan to $int_if pass in quick on $int_if inet proto icmp from $lan to !<no_if> icmp-type echoreq tag LAN_INET_ICMP pass in quick on $int_if inet proto icmp from $lan to $int_if icmp-type echoreq Пояснения. Пришедшие на внутр. интерфейс пакеты "метятся". Метятся только те пакеты, у которых dst addr любой, кроме всех внутренних и внешних интерфейсов. Это необходимо, если есть несколько подсетей и вы не хотите, что бы кто-либо из одной сети мог подключится к висящему сервису на другом интерфейсе. Впринципе здесь можно вместо !<no_if> указать any. Весь исходящий трафик с сервера в "мир" (кроме ДНС) и локальную сеть блокируется. ААА.ААА.ААА.ААА - IP DNS-сервера провайдера.   ipfw nat во FreeBSD 7   Автор: Pikador  [комментарии]   В конфигурацию ядра добавляем: options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPDIVERT options IPFIREWALL_FORWARD options DUMMYNET options IPFIREWALL_NAT #ipfw kernel nat support options LIBALIAS в /etc/make.conf: CFLAGS+= -DIPFIREWALL_NAT Далее пересобираем систему: cd /usr/src/ ; make builworld && make kernel KERNCONF=YourKern && make installworld reboot В конфигурационном файле ipfw: NatIP="111.111.111.111" ipfw nat 123 config ip ${NatIP} log ipfw add 10 nat 123 ip from 192.168.0.0/16 to any ipfw add 20 nat 123 ip from any to ${NatIP} Наслаждаемся достоинствами kernel nat   Настройка работы ipnat под большой нагрузкой (доп. ссылка 1)   Автор: Антон Южанинов  [комментарии]   Для работы ipnat под большой нагрузкой (много трансляций) нужно перед сборкой ядра изменить в файле /usr/src/sys/contrib/ipfilter/netinet/ip_nat.h #undefine LARGE_NAT на #define LARGE_NAT   Балансировка двух каналов средствами ipfw под FreeBSD   Автор: Ivan Voytas  [комментарии]   natd -p 8668 -a ip1 natd -p 8669 -a ip2 ipfw add divert 8668 ip from any to ip1 recv if1 ipfw add divert 8669 ip from any to ip2 recv if2 ipfw add check-state ipfw add prob 0.5 divert 8668 ip from 192.168.0.0/16 to any xmit if1 keep-state ipfw add divert 8669 ip from 192.168.0.0/16 to any xmit if1 keep-state ipfw add fwd gw1 ip from ip1 to any out xmit if1 (если default на if1) ipfw add fwd gw2 ip from ip2 to any out xmit if1   В двух словах про включение NAT и Firewall в ОС FreeBSD (доп. ссылка 1)   Автор: hub.ru  [комментарии]   Что бы поднять NAT и Firewall на FreeBSD надо: Скомпилировать ядро: Следующие строки нужно включить в /usr/src/sys/i386/conf/GENERIC файл конфигурации: options IPFIREWALL options IPDIVERT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options DUMMYNET options TCP_DROP_SYNFIN Переходим в директорию /usr/src/ make buildkernel KERNCONF=GENERIC make installkernel KERNCONF=GENERIC Следующие строки можно к примеру включить в rc.conf файл конфигурации: hostname="free" ifconfig_rl0="10.0.0.1" gateway_enable="YES" firewall_enable="YES" firewall_type="open" natd_enable="YES" natd_interface="rl0" natd_flags="-redirect_port tcp 10.0.0.10:80 80" tcp_extensions="NO" tcp_drop_synfin="YES" icmp_drop_redirect="YES" sendmail_enable="NONE" Для удаленного управления нужно добавить следующую строку: sshd_enable="YES" (возможно понадобится скопировать /etc/ssh/ssh_host_dsa_key.pub в /root/.ssh/authorized_keys Следующие строки можно включить в rc.firewall файл конфигурации (секция "open"): [Oo][Pp][Ee][Nn]) oif="rl0" iif="tx0" oip="132.5.7.172" iip="10.0.0.1" lan="10.0.0.0/24" setup_loopback # allow all for LAN ${fwcmd} add 500 pass all from ${lan} to ${iip} via ${iif} ${fwcmd} add 550 pass all from ${iip} to ${lan} via ${iif} # download - 60K upload - 6K for all lan ip's ${fwcmd} add 600 pipe 1 ip from any to any in via ${oif} ${fwcmd} add 650 pipe 2 ip from any to any out via ${oif} # for selected ip's only # ${fwcmd} add 601 pipe 1 all from any to 10.0.0.10 # ${fwcmd} add 651 pipe 2 all from 10.0.0.10 to any ${fwcmd} pipe 1 config bw 512Kbit/s ${fwcmd} pipe 2 config bw 48Kbit/s # dns setup ${fwcmd} add 770 pass tcp from any to ${oip} 53 setup ${fwcmd} add 780 pass udp from any domain to any ${fwcmd} add 790 pass udp from any to any domain # main setup ${fwcmd} add 800 pass tcp from any http,https,20-21,989-990 to any ${fwcmd} add 810 pass tcp from any to any http,https,20-21,989-990 ${fwcmd} add 830 pass tcp from any pop3,pop3s,smtp,imap,imaps,aol to any ${fwcmd} add 840 pass tcp from any to any pop3,pop3s,smtp,imap,imaps,aol ${fwcmd} add 65000 deny ip from any to any ;; Где oip, oif - внешний интерфейс; iip, iif - внутренний; lan - внутренняя сеть. Такая конфигурация ipfw весьма параноидальна, и здесь приведена только в качестве примера. На практике обычно нужен более открытый фаервол.   pf и трансляция адресов на двух интерфейсах   Автор: DelGod  [комментарии]   Решение оптимизировано для шлюза на флешке (не используется perl и другие "тяжелые" решения) ------------------------- /usr/local/etc/rc.d/openvpn.sh ------------------------- #!/bin/sh . /etc/rc.subr name=openvpn rcvar=`set_rcvar` prefix="/usr/local" openvpn_precmd() { for i in $openvpn_if ; do # FreeBSD <= 5.4 does not know kldstat's -m option # FreeBSD >= 6.0 does not add debug.* sysctl information # in the default build - we check both to keep things simple if ! sysctl debug.if_${i}_debug >/dev/null 2>&1 \ && ! kldstat -m if_${i} >/dev/null 2>&1 ; then if ! kldload if_${i} ; then warn "Could not load $i module." return 1 fi fi done return 0 } start_postcmd() { `/bin/cat /var/db/ukr_nets| /usr/bin/awk '{ if ($1) {system("route add "$1" 193.201.61.65 >/dev/null")} }'` /bin/sleep 10 && pfctl -F all -f /etc/pf.conf_openvpn } stop_postcmd() { `/bin/cat /var/db/ukr_nets| /usr/bin/awk '{ if ($1) {system("route delete "$1" 193.201.61.65 >/dev/null")} }'` pfctl -F all -f /etc/pf.conf rm -f "$pidfile" || warn "Could not remove $pidfile." } extra_commands="reload" pidfile="/var/run/${name}.pid" command="/usr/local/sbin/${name}" start_precmd="openvpn_precmd" start_postcmd="start_postcmd" stop_postcmd="stop_postcmd" load_rc_config ${name} : ${openvpn_enable="NO"} : ${openvpn_flags=""} : ${openvpn_if=""} : ${openvpn_configfile="${prefix}/etc/openvpn/openvpn.conf"} : ${openvpn_dir="${prefix}/etc/openvpn"} required_files="${openvpn_configfile}" command_args="--cd ${openvpn_dir} --daemon --config ${openvpn_configfile} --writepid ${pidfile}" run_rc_command "$1" ------------------------- /etc/pf.conf ------------------------- ext_if_t="rl0" int_if="rl1" table <users> persist { 192.168.1.0/24 } nat on $ext_if_t inet from <users> to any -> $ext_if_t pass on $ext_if_t all pass on $int_if all ------------------------- /etc/pf.conf_openvpn ------------------------- ext_if_o="tap0" ext_if_t="rl0" int_if="rl1" table <users> persist { 192.168.1.0/24 } table <ukr> persist file "/var/db/ukr_nets" nat on $ext_if_t inet from <users> to <ukr> -> $ext_if_t nat on $ext_if_o inet from <users> to !<ukr> -> $ext_if_o pass on $ext_if_o all pass on $ext_if_t all pass on $int_if all ------------------------- cron: ------------------------- 0 0 * * * /usr/bin/fetch -q -o "/var/db/ukr_nets" 'http://www.colocall.net/ua/?list'   Проброс портов с двух различных gateway на внутренний сервер через IPNAT   Автор: Жека  [комментарии]   Иногда необходимо пробросить порты с двух различных gateway GW1 и GW2 на один внутренний сервер, у которого в качестве default GW указан GW1. Прямой проброс и NAT невозможен, т.к. пакеты пришедшие из GW2 попытаются вернуться по маршруту через GW1. Есть следующий выход, это двойной NAT на GW2, при котором запрос приходит не снаружи, а с внутреннего IP. ed0 - внешний интерфейс lnc0 - интерфейс смотрящий внутрь. в ipnat.rules нужно прописать следующее: map ed0 10.6.10.0/24 -> 0.0.0.0/32 мапим локалку наружу map lnc0 0.0.0.0/0 -> 0.0.0.0/32 ремап внешних ip в локальные rdr ed0 0.0.0.0/0 port 80 -> 10.6.10.2 port 80 tcp форвард на внутренний сервер   Пример настройки NAT для двух сетей в FreeBSD 5.3 (доп. ссылка 1)   Автор: Vov  [комментарии]   Стоит задача - выпустить свою сеть в инет через два разных интерфейса rl1 и rl2. Так как адреса в локали серые, то надо поднимать NAT. С учетом того, что динамической маршрутизации не предвидится, будем поднимать NAT на 2 интерфейса. Для этого нужно: Скомпилировать ядро с параметрами: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=20 options IPFIREWALL_FORWARD options IPDIVERT options DUMMYNET options TCP_DROP_SYNFIN это необходимый минимум. На все случаи жизни ))))) Далее, в rc.local пишем такие строки: natd -p 8668 -n rl1 natd -p 8669 -n rl2 #natd -p 8671 -n rl3 #natd -p 8672 -n rl4 #natd -p 8673 -n rl5 Последние три строки - если кому надо поднимать NAT на большее количество интерфейсов. Следующее - правила ipfw: ipfw -f add divert 8668 all from #твоясеть# to any out via rl1 ipfw -f add divert 8668 all from any to #адрес_rl1# in via rl1 ipfw -f add divert 8669 all from #твоясеть# to any out via rl2 ipfw -f add divert 8669 all from any to #адрес_rl2# in via rl2 Теперь все, что будет выходить через внешние интерфейсы, будет правильно NATиться через них же. Остается проверить маршрутизацию. Если маска на rl2 /24. В этом случае все просто. Стандартный шлюз (default gateway) прописан через rl1, а все, что идет на сеть 999.888.0.0/24 будет автоматически бежать через rl2. Если же на rl2 выделена подсетка из нескольких адресов, то тогда надо писать жесткий марщрут на всю сеть 999.888.0.0/24 через rl2 на тот шлюз, который тебе дал провайдер N2. Его тоже можно прописать в rc.local отдельной строкой типа: route add 999.888.0.0/24 999.888.0.25 У Sergey2005 заработала комбинация: ${fwcmd} add 40 divert 8668 all from #моя сеть# to not #подсеть провайдера "S"# out via rl1 ${fwcmd} add 45 divert 8668 all from not #подсеть провайдера "S"# to any in via rl1 ${fwcmd} add 50 divert 8669 all from #моя сеть# to #подсеть провайдера "S"# out via rl2 ${fwcmd} add 55 divert 8669 all from #подсеть провайдера "S"# to any in via rl2 natd -p 8668 -m -u -n rl1 natd -p 8669 -m -u -n rl2   Особенности использование ftp из-за фаервола ipfw/natd   Автор: globus  [комментарии]   Необходимо выпустить пользователей на ftp сайты из локальной сети, но при этом не устанавливая дополнительного ПО, используя только возможности FreeBSD 4.10. Этими возможностями, как ни странно, оказались ipfw и natd вот собственно как все это прописывается. Исходные данные, FreeBSD 4.10 + настроенный nat правила для ipfw ipfw -q add 100 divert natd from 192.168.20.0/24 to any 20, 21 out via $oif ipfw -q add 200 divert natd from any 20, 21 to $iip in via $oif ipfw -q add 300 allow tcp from any to any established ipfw -q add 400 allow tcp from any to any setup где $oif и $iip соответственно внешний интерфейс и внешний IP теперь запускаем natd /sbin/natd -m -s -u -punch_fw 500:200 -n xl1 заострю внимание на параметре "-punch_fw" -этот параметр создает в фаерволе "ходы", добавляя динамические правила. В моем случае эти правила начнутся с номера 500 и будет их добавлено максимум 200 (понятно чем больше сеть, те больше нужно правил). Особое спасибо A Clockwork Orange.   Как в FreeBSD перебросить соединение через NAT во внутреннюю сеть  (доп. ссылка 1)   Автор: spanka  [комментарии]   Вот реализация для ipfw: if1IP="ип_смотрящий_в_инет", if1="интерфейс_смотрящий_в_инет" ifLIP="ип_на_который хотим делать редирект" ipfw add divert natd tcp from any to ${if1IP} 80 via ${if1} ipfw add divert natd ip from any to ${ifLIP} to any via ${if1} ipfw add allow tcp from any to ${if1IP} 80 via any natd -n ${if1} -redirect_port tcp ${ifLIP}:80 80 Решение от miaso <[email protected]>: tproxy -s 80 -r nobody -l /var/log/transparent_proxy.log [int_ip] 80   Как в Linux перебросить соединение через NAT во внутреннюю сеть (доп. ссылка 1)   Автор: Dimez  [комментарии]   Первый путь - пробрасывание только порта: 1) iptables -t nat -A PREROUTING -p tcp -d EXT_R_IP --dport 10000 -j DNAT --to-destination LOCAL_IP:80 2) iptables -A FORWARD -i eth0 -d LOCAL_IP -p tcp --dport 22 -j ACCEPT Второй вариант - выброс всей машины наружу (если есть свободные адреса): 1) ifconfig eth0:0 NEW_IP netmask NETMASK broadcast BROADCAST 2) route add NEW_IP gw GW netmask 0.0.0.0 metric 1 dev eth0:0 3) iptables -t nat -A PREROUTING -p tcp -d NEW_IP -j DNAT --to-destination LOCAL_IP 4) iptables -A FORWARD -i eth0 -d LOCAL_IP -j ACCEPT Обозначения: EXT_R_IP - внешний IP роутера, LOCAL_IP - внутренний IP машины, которую хочешь выбросить NEW_IP - новый IP на который хочешь посадить машину, которая имеет локальный LOCAL_IP NETMASK, BROADCAST, GW - внешние netmask, broadcast и gateway   Пример настройки NAT с привязкой к IP под Linux   [комментарии]   Пример настройки NAT с привязкой к IP под Linux iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -o eth0 -j SNAT --to-source 212.23.98.45 или (без привязки к IP) ipchains -A forward -j MASQ -s 192.168.0.0/16 -d 0.0.0.0/0 или (через iproute2) ip rule add from 10.0.1.0/24 nat 254.147.38.14 Другой способ трансляции адресов: iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -j MASQUERADE   Как организовать редирект порта на внутреннюю машину через ipnat в FreeBSD.   [комментарии]   man 5 ipnat в /etc/ipnat.conf: rdr fxp0 205.15.63.3/32 port 80 -> 192.168.1.1 port 80 tcp # Базансировка нагрузки между 2 IP: rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp round-robin   Как настроить NAT (транслятор адресов) для нормальной работы с FTP и ICQ в Linux   [комментарии]   iptables: modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp modprobe ip_nat_irc ipchains: modprobe ip_masq_ftp modprobe ip_masq_raudio modprobe ip_masq_irc modprobe ip_masq_icq   Как обеспечить работу active FTP режима в FreeBSD NAT   [обсудить]   В ipnat воспользуйтесь модулем ftp proxy: map fxp0 0/0 -> 0/32 proxy port ftp ftp/tcp map rl0 172.16.33.0/24 -> 212.46.231.50/32 proxy port ftp ftp/tcp не забудьте поместить правило трансляции ftp перед общим правилом трансляции, порядок следования правил важен.   Как запустить трансляцию адресов (NAT) под FreeBSD   [комментарии]   В /etc/rc.conf: ipnat_enable="YES" В /etc/ipnat.rules: Трансляция адресов (NAT): map ppp0 172.16.1.0/24 -> 194.46.124.53/32 где, ppp0 - внешний интерфейс, 172.16.1.0/24 - внутренние IP, 194.46.124.53 - реальный IP внешнего интерфейса. Переброс порта во внутреннюю сеть: rdr ed0 294.16.9.6/32 port 8080 -> 192.168.0.7 port 8080 tcp где, ed0 - внешний интерфейс, 294.16.9.6 - реальный IP внешнего интерфейса, на который нужно обращаться из вне. 192.168.0.7 - внутренний IP на который делается переброс. 8080 - номер перебрасываемого порта. Перечитать: ipnat -CF -f /etc/ipnat.rules

Policy routing

Использование нескольких сетевых стеков в Linux   Автор: Roman Timofeev ( ^rage^ )  [комментарии]   В linux относительно давно появилась такая замечательная вещь, как неймспейсы (namespaces). Основное применение данной технологии - контейнерная виртуализация, но и на маршрутизаторе можно придумать много разных применений, так как среди неймспейсов есть "network namespaces". Network namespaces позволяют в рамках одной машины в каждом неймспейсе иметь: свой набор таблиц маршрутизации (а их 2^31-1 шт) свою arp-таблицу свои правила iptables свои устройства (а значит и qdisc + class'ы tc) NB: для выполнения нижеследующих примеров крайне желательно иметь свежий iproute2 и ядро. Создаются неймспейсы достаточно скучно и просто: ip netns add VROUTER ip netns add KUKYSEVRACI Создадим "виртуальны шнурок": ip link add name ve0a type veth peer name ve0b Добавим интерфейсы внутрь VROUTER: ip link set dev eth0 netns VROUTER ip link set dev ve0b netns VROUTER Выполнить команду в контексте определённого неймспейса можно так: ip netns exec VROUTER ip link show Настроим адреса: ip netns exec VROUTER ip a a 192.168.1.1/24 dev ve0b ip a a 192.168.1.2/24 dev ve0a ip netns exec VROUTER ip a a 10.140.48.16/24 dev eth0 Поднимем интерфейсы: ip link set dev ve0a up ip netns exec VROUTER ip link set dev eth0 up ip netns exec VROUTER ip link set dev ve0b up Шлюз по умолчанию: ip netns exec VROUTER ip r a default via 10.140.48.1 Посмотрим, что получилось: root@laptus:~# ip netns exec VROUTER ip r s default via 10.140.48.1 dev eth0 10.140.48.0/24 dev eth0 proto kernel scope link src 10.140.48.16 192.168.1.0/24 dev ve0b proto kernel scope link src 192.168.1.1 Добавим NAT: ip netns exec VROUTER iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 10.140.48.16 Сделаем пару трейсов: root@laptus:~# ip netns exec VROUTER traceroute -q 1 -I opennet.ru traceroute to opennet.ru (77.234.201.242), 30 hops max, 60 byte packets 1 10.140.48.1 (10.140.48.1) 0.148 ms 2 10.140.0.1 (10.140.0.1) 0.245 ms 3 border.yournet.ru (91.204.148.17) 0.436 ms 4 alisa.yournet.ru (91.204.151.2) 0.521 ms 5 sev-gw.yournet.ru (91.204.148.2) 8.975 ms 6 bl16-1-gw.spb.runnet.ru (194.190.255.25) 1.321 ms 7 bl16-1-gw.spb.runnet.ru (194.85.40.170) 1.785 ms 8 s14-1-gw.spb.runnet.ru (194.85.40.81) 1.456 ms 9 vuztc.spb.runnet.ru (194.190.255.170) 1.987 ms 10 opennet.ru (77.234.201.242) 2.395 ms root@laptus:~# traceroute -q 1 -I opennet.ru traceroute to opennet.ru (77.234.201.242), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.094 ms 2 10.140.48.1 (10.140.48.1) 0.751 ms 3 10.140.0.1 (10.140.0.1) 1.277 ms 4 border.yournet.ru (91.204.148.17) 2.061 ms 5 alisa.yournet.ru (91.204.151.2) 2.911 ms 6 sev-gw.yournet.ru (91.204.148.2) 6.770 ms 7 bl16-1-gw.spb.runnet.ru (194.190.255.25) 3.622 ms 8 bl16-1-gw.spb.runnet.ru (194.85.40.170) 5.262 ms 9 s14-1-gw.spb.runnet.ru (194.85.40.81) 4.135 ms 10 vuztc.spb.runnet.ru (194.190.255.170) 4.710 ms 11 opennet.ru (77.234.201.242) 7.220 ms   Перенаправление всего трафика через один шлюз в Fedora/Red Hat Linux   Автор: shadow_alone  [комментарии]   При необходимости направить весь трафик с машины через шлюз, даже запросы к локальной сети, используем следующую конфигурацию сети (пример для Red Hat-совместимых дистрибутивов) /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.0.255 IPADDR=192.168.0.100 NETMASK=255.255.255.255 SCOPE="peer 192.168.0.1" ONBOOT=yes /etc/sysconfig/network-scripts/route-eth0 ADDRESS0=0.0.0.0 NETMASK0=0.0.0.0 GATEWAY0=192.168.0.1 Теперь весь трафик от текущей машины будет ходить через шлюз 192.168.0.1, так как маска у нас /32.   Тонкости настройки Linux при подключении к двум и более провайдерам   Автор: Pavel V. Rochnyack  [комментарии]   Подключение к интернет через нескольких провайдеров давно уже не редкость. Раньше рассматриваемая тема называлась "линукс и два провайдера", но в суровой реальности провайдеров может быть и больше. Также хочется вместо термина "провайдер" использовать "канал", поскольку некоторые люди путаются - "провайдер у меня один", а вот шлюзов (и адресов в различных подсетях) он предоставляет несколько (ну, так бывает нужно по разным мотивам). Написано на эту тему также уже довольно много. Но есть что дополнить, поэтому приступим. Вводная часть. Итак, первое что требуется сделать для указания правил маршрутизации - это указать, к чему эти правила будут приводить. А приводить они должны к тому, что пакеты пойдут по разным шлюзам, такчто, вполне логично описать эти самые шлюзы. Делается это с использованием набора пользовательских таблиц маршрутизации. Для удобства использования, им можно присваивать admin-friendly имена, что делается прописыванием строк в файл /etc/iproute2/rt_tables. Строки имеют вид примерно такой: 100 northtelecom 101 southtelecom Таблицы можно не именовать, а использовать во всех подкомандах команды ip безликие цифры, в этом случае ничего в файл rt_tables прописывать не потребуется. Также, часть документации таблицы именует именами вида "Т1", "Т2" что тоже, на мой взгляд, слабо удобно при просмотре правил. Отлично, таблицы поименованы. Далее требуется указать шлюзы, на которые требуется отправлять трафик. Обычно для этого прописывается пара команд в системный файл-скрипт, который отвечает за "подъем" маршрутизатора. На PC-маршрутизаторе вполне можно для этих целей использовать непосредственно /etc/rc.local. Итак, команды указания маршрутов в интернет выглядят так: ip route add default via northtelecom_gw table northtelecom ip route add default via southtelecom_gw table southtelecom Отлично! Мы создали две таблицы маршрутизации, внесли в них значения двух шлюзов для маршрутизации трафика. Теперь эти таблицы надо начать применять. Обдуманное применение таблиц маршрутизации заключается в использовании команды "ip rule" и выглядит это примерно так: ip rule add from northtelecom_ip lookup northtelecom ip rule add from southtelecom_ip lookup southtelecom На самом деле, это еще не совсем обдуманное применение, поскольку не указаны приоритеты правил (забегая вперед, уточним что они указываются использованием "ip rule add .... pref <priority>"). Посмотрим на получившийся результат: debian:~# ip ru 0: from all lookup local 32764: from southtelecom_ip lookup southtelecom 32765: from northtelecom_ip lookup northtelecom 32766: from all lookup main 32767: from all lookup default Что означает полученный вывод ? Он означает, что пакет при выборе пути к месту назначения будет сначала проверен правилом 0, который отправит поиск маршрута в таблицу "local". Просмотр таблицы "local" проводится на предмет "не является ли получателем" локальная машина, широковещательный или сетевой адреса интерфейсов маршрутизатора. Соответствующими маршрутами заполняют эту таблицу команды конфигурации сетевых интерфейсов. Далее, пакет будет проверен нашими двумя правилами 32764 и 32765, на предмет адреса отправителя, и, в случае совпадения, будет отправлен в соответствующую таблицу маршрутизации. Если адрес отправителя не совпадет с southtelecom_ip или northtelecom_ip, поиск маршрута пойдет с использованием таблицы "main", а таблица "default" (пока еще?) дистрибутивно чиста. Как вы могли заметить, если маршрут не будет найден в таблице, на которую поиск будет завернут правилом, то поиски-проверки будут продолжены со следующего правила. Таблица "main" - это основная таблица, используемая по-умолчанию всеми командами-программами, связанными с маршрутизацией. При поднятии интерфейсов в неё прописываются маршруты к подсетям интерфейсов, стартовые скрипты также заносят в эту таблицу значение шлюза по-умолчанию. Использование команды "route add" администратором также может дополнить таблицу машрутами. В общем случае, таблица "main" всегда содержит подходящий для пакета маршрут (например шлюз по-умолчанию). Закончим вводную часть и приступим к "первому сложному моменту". Некоторые источники рекомендуют использовать еще и примерно такие команды при описании таблиц провайдеров: ip route add northtelecom_net dev northtelecom_if src northtelecom_ip table northtelecom ip route add southtelecom_net dev southtelecom_if src southtelecom_ip table southtelecom Во-первых, хочется заметить что можно упростить команду, опустив уточнение "src northtelecom_ip", поскольку таблица будет выбираться путем сравнения IP-адреса отправителя пакета с некоторым значением, т.е. адрес уже будет задан. А во-вторых, объясню более подробно, зачем нужны соответствующие маршруты. Без дополнительной команды таблица northtelecom содержит следующие маршруты (да, пока, только один маршрут): debian:~# ip ro sh table northtelecom default via northtelecom_gw dev northtelecom_if В этом случае, пакетик, который отправляется с адреса northtelecom_ip к одному из хостов в сети провайдера northtelecom будет послан не непосредственно к этому хосту, а отправлен на машрутизатор провайдера. Конечно же, лучше отправлять пакет непосредственно к хосту, для чего требуется соответствующее уточнение таблиц маршрутизации командами ip route add northtelecom_net dev northtelecom_if table northtelecom ip route add southtelecom_net dev southtelecom_if table southtelecom Вроде бы всё здорово, пакеты в непосредственно присоединенные сети провайдеров идут напрямую к хостам. Но неужели у нас отсутствует локальная сеть ? Чаще всего она у нас есть. Но что же произойдет, если из локальной сети будет произведено обращение к одному из адресов northtelecom_ip или southtelecom_ip ? Посмотрим еще раз на вывод команды "ip rule" debian:~# ip ru 0: from all lookup local 32764: from southtelecom_ip lookup southtelecom 32765: from northtelecom_ip lookup northtelecom 32766: from all lookup main 32767: from all lookup default В соответствии с правилами, маршрут отправки пакетов, исходящих с адресов northtelecom_ip или southtelecom_ip, будет производиться в таблицах northtelecom и southtelecom, что в конечном счете приведет к отправке пакета в сторону шлюза провайдера. Поскольку это слегка не то, что нам нужно, придется дополнить таблицы еще парочкой маршрутов. ip route add local_net dev local_if table northtelecom ip route add local_net dev local_if table southtelecom А если у нас есть еще и внутренние маршрутизаторы, и подсетки, скрытые за ними, то всё аналогично, требуется добавление каждой подсетки в каждую таблицу провайдеров. ip route add local_net2 via local_router2 table northtelecom ip route add local_net3 via local_router2 table northtelecom ip route add local_net2 via local_router2 table southtelecom ip route add local_net3 via local_router2 table southtelecom Много правил, много команд, легко запутаться, потерять, забыть что-то прописать ... Неужели нельзя проще ? Как показывает практика, можно, но не всегда. Легкий трюк, который в большинстве случаев помогает, выглядит так: ip rule add lookup main pref 1000 ip ro add default via (northtelecom|southtelecom)_gw table default ip ro delete default table main Что он означает? Посмотрим на таблицу правил командой "ip rule" (да, я уже перенабрал набор правил с указанием приоритетов) debian:~# ip ru 0: from all lookup local 1000: from all lookup main 3000: from southtelecom_ip lookup southtelecom 3010: from northtelecom_ip lookup northtelecom 32766: from all lookup main 32767: from all lookup default Теперь для исходящих пакетов до поиска маршрутов в таблицах провайдеров будет осуществлен поиск маршрута в таблице "main", а она, как было написано выше, содержит максимум информации о маршрутах, в том числе и маршруты в локальные сети, как присоединенные напрямую, так и через внутренние маршрутизаторы. Чтобы поиск маршрута в таблице "main" не закончился отправкой пакета в "шлюз по умолчанию", мы перенесем его указание в таблицу "default". Всё, теперь локальные и присоединенные сети вносить в таблицы "southtelecom" и "northtelecom" необходимости нет. Достаточно эти таблицы сформировать командами ip route add default via northtelecom_gw table northtelecom ip route add default via southtelecom_gw table southtelecom и получить работоспособность. Но этот легкий трюк имеет некоторый побочный эффект, который иногда ограничивает его прямое применение. Допустим, что от хоста из сети southtelecom_net идет обращение к northtelecom_ip. Поскольку теперь маршрут приоритетно ищется в таблице main, то ответные пакеты с адреса northtelecom_ip будут отправлены через интерфейс southtelecom_if непосредственно к обратившемуся хосту. C одной стороны, это можеть быть здорово, пакеты пойдут кратчайшим путем, мы можем ожидать более высокой скорости передачи ответа и массы других полезных вещей, но с другой стороны это может оказаться не тем, чего от нас ожидал наш провайдер southtelecom, который ограничил нас на нашем порту коммутатора парой MAC+IP... В общем, вышеописаный трюк - это трюк для слегка ленивых. Оптимальным методом решения задачи является создание третьей пользовательской таблицы "localnets" и указание в ней части маршрутов (маршрутов к локальным сетям) из таблицы main. В этой конфигурации, ответ при обращении из сети southtelecom_net к адресу northtelecom_ip пойдет точно также, как если бы второй канал в сеть southtelecom_net на маршрутизаторе отсутствовал, т.е. через сеть провайдера northtelecom, а не напрямую к хосту. Приведу набор команд, формирующих решение, а анализ того, как будет определяться маршрут для пакетов оставлю пытливым умам читателей. ip route add local_net dev local_if table localnets ip route add local_net2 via local_router2 table localnets ip route add local_net3 via local_router2 table localnets ip route add southtelecom_net dev southtelecom_if table southtelecom ip route add default via southtelecom_gw table southtelecom ip route add northtelecom_net dev northtelecom_if table northtelecom ip route add default via northtelecom_gw table northtelecom ip rule add lookup table localnets pref 1000 ip rule add from southtelecom_ip lookup southtelecom pref 3000 ip rule add from northtelecom_ip lookup northtelecom pref 3010 debian:~# ip ru 0: from all lookup local 1000: from all lookup localnets 3000: from southtelecom_ip lookup southtelecom 3010: from northtelecom_ip lookup northtelecom 32766: from all lookup main 32767: from all lookup default В качестве завершения, хочется отметить то, для чего между правилом 1000 и правилами 30хх оставлен свободный диапазон. Используя этот диапазон, очень удобно разделять, по какому из каналов пойдет трафик хостов локальной сети (без специальных правил он пойдет с использованием шлюза по умолчанию, заданного в таблице "main" или "default") или специально маркированный трафик. Например, это делается так: ip ru add from 192.168.0.100 lookup southtelecom pref 2000 ip ru add from 192.168.0.128/25 lookup northtelecom pref 2010 Названия провайдеров "southtelecom" и "northtelecom" являются вымышленными, совпадения, если таковые имеются, случайны.   Два провайдера и default gw в Linux   Автор: Dmitriy Altuhov  [комментарии]   Имеется сервер ASPLinux 10, с установленным postfix и 3-я сетевыми интерфейсами. Задача: корректная работа почты через один из интерфейсов, при этом в качестве default gw указан другой. Реализация: 1) в /etc/iproute2/rt_tables добавляем: 201 T1 202 T2 2) создаём скрипт и даём права на запуск, предварительно исправив нужные параметры IP - адреса сетевых интерфейсов P - адреса шлюзов #!/bin/sh IP1=192.168.4.1 IP2=217.1.1.2 P1=192.168.4.2 P2=217.1.1.1 ip route add default via $P1 table T1 ip route add default via $P2 table T2 ip route add default via $P1 ip rule add from $IP1 table T1 ip rule add from $IP2 table T2 В результате получим, что если пакет пришёл на P2, то он не пойдёт через default gw P1, а уйдёт через тот же интерфейс с IP1   Балансировка двух каналов средствами ipfw под FreeBSD   Автор: Ivan Voytas  [комментарии]   natd -p 8668 -a ip1 natd -p 8669 -a ip2 ipfw add divert 8668 ip from any to ip1 recv if1 ipfw add divert 8669 ip from any to ip2 recv if2 ipfw add check-state ipfw add prob 0.5 divert 8668 ip from 192.168.0.0/16 to any xmit if1 keep-state ipfw add divert 8669 ip from 192.168.0.0/16 to any xmit if1 keep-state ipfw add fwd gw1 ip from ip1 to any out xmit if1 (если default на if1) ipfw add fwd gw2 ip from ip2 to any out xmit if1   Проброс трафика через Linux машину используя Proxy ARP (доп. ссылка 1) (доп. ссылка 2)   [комментарии]   Пусть: x.x.x.96/28 - выделенная подсеть, которую нужно распределить по машинам в локальной сети. x.x.x.97 - IP внешнего шлюза. Требуется поставить между шлюзом и сетью фаервол, с одним адресом на двух интерфейсах x.x.x.98, транслируя ARP трафик используя "Proxy ARP". (x.x.x.99 ... x.x.x.110) --- (eth1, x.x.x.98 | eth0, x.x.x.98) --- (x.x.x.97) Удаляем маршруты созданные по умолчанию. ip route del x.x.x.96/28 dev eth0 ip route del x.x.x.96/28 dev eth1 Пакеты для x.x.x.97 пускаем через eth0, а для x.x.x.96/28 через eth1 ip route add x.x.x.97 dev eth0 ip route add x.x.x.96/28 dev eth1 Включаем Proxy ARP echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp   Почему в FreeBSD 5.3 не работает форвадинг пакетов (ipfw fwd) (доп. ссылка 1)   Автор: Bushi  [комментарии]   Это ошибка в FreeBSD 5.3, патч здесь: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71910   Пример настройки NAT для двух сетей в FreeBSD 5.3 (доп. ссылка 1)   Автор: Vov  [комментарии]   Стоит задача - выпустить свою сеть в инет через два разных интерфейса rl1 и rl2. Так как адреса в локали серые, то надо поднимать NAT. С учетом того, что динамической маршрутизации не предвидится, будем поднимать NAT на 2 интерфейса. Для этого нужно: Скомпилировать ядро с параметрами: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=20 options IPFIREWALL_FORWARD options IPDIVERT options DUMMYNET options TCP_DROP_SYNFIN это необходимый минимум. На все случаи жизни ))))) Далее, в rc.local пишем такие строки: natd -p 8668 -n rl1 natd -p 8669 -n rl2 #natd -p 8671 -n rl3 #natd -p 8672 -n rl4 #natd -p 8673 -n rl5 Последние три строки - если кому надо поднимать NAT на большее количество интерфейсов. Следующее - правила ipfw: ipfw -f add divert 8668 all from #твоясеть# to any out via rl1 ipfw -f add divert 8668 all from any to #адрес_rl1# in via rl1 ipfw -f add divert 8669 all from #твоясеть# to any out via rl2 ipfw -f add divert 8669 all from any to #адрес_rl2# in via rl2 Теперь все, что будет выходить через внешние интерфейсы, будет правильно NATиться через них же. Остается проверить маршрутизацию. Если маска на rl2 /24. В этом случае все просто. Стандартный шлюз (default gateway) прописан через rl1, а все, что идет на сеть 999.888.0.0/24 будет автоматически бежать через rl2. Если же на rl2 выделена подсетка из нескольких адресов, то тогда надо писать жесткий марщрут на всю сеть 999.888.0.0/24 через rl2 на тот шлюз, который тебе дал провайдер N2. Его тоже можно прописать в rc.local отдельной строкой типа: route add 999.888.0.0/24 999.888.0.25 У Sergey2005 заработала комбинация: ${fwcmd} add 40 divert 8668 all from #моя сеть# to not #подсеть провайдера "S"# out via rl1 ${fwcmd} add 45 divert 8668 all from not #подсеть провайдера "S"# to any in via rl1 ${fwcmd} add 50 divert 8669 all from #моя сеть# to #подсеть провайдера "S"# out via rl2 ${fwcmd} add 55 divert 8669 all from #подсеть провайдера "S"# to any in via rl2 natd -p 8668 -m -u -n rl1 natd -p 8669 -m -u -n rl2   Пример разделения трафика для использования двух каналов в FreeBSD (доп. ссылка 1)   Автор: ILJA  [комментарии]   rl0 -> Первый ифайс во вне, rl1 -> Второй ифайс во вне rc.conf: defaultrouter="${rl1_gateway_ip}" rc.local: /sbin/natd -n rl0 -p 8660 /sbin/natd -n rl1 -p 8661 rc.firewall: ${fwcmd} add 1100 divert 8660 tcp from ${local_ip} to not ${rl0_ip} 22,25,53,80,110,6667 ${fwcmd} add 1110 fwd ${rl0_gateway_ip} tcp from ${rl0_ip} to not ${local_ip} ${fwcmd} add 1120 divert 8660 all from not ${rl0_ip},${local_ip} to ${rl0_ip} ${fwcmd} add 1150 pass all from any to ${rl0_ip} ${fwcmd} add 1150 pass all from ${rl0_ip} to any ${fwcmd} add 1999 divert 8661 all from ${local_ip} to not ${rl1_ip} ${fwcmd} add 2000 divert 8661 all from not ${rl1_ip},${local_ip} ${fwcmd} add 2010 pass all from any to ${local_ip} ${fwcmd} add 2010 pass all from ${local_ip} to any ${fwcmd} add 2100 pass all from any to ${rl1_ip} ${fwcmd} add 2100 pass all from ${rl1_ip} to any Правила тестировались на FreeBSD 4.7, 4.8, 4.9, 4.10, c ipfw2. Если у вас с ipfw(1) не работает, попробуйте убрать "not ${ip}" и вместо него вставить "any". "not" нужен для того чтобы локальные адреса не дивертировались, т.к. нам это не нужно. Порядковые номера могут быть на ваше усмотрение, рекомендую в начале разрешить трафик lo0, защититься от спуфа, запретить некоторые типы ICMP, разрешить внутренний трафик и т.д., и т.п.   Пример policy routing в Linux (маршрутизация в зависимости от IP источника)   [обсудить]   ip rule add from 10.1.10.0/24 to 0/0 table 102 pref 100 ip route add table 102 via 10.1.10.1 ip rule add from 10.1.11.0/24 to 0/0 table 103 pref 100 ip route add table 103 via 10.1.11.45   Как организовать Policy Routing на FreeBSD   [комментарии]   ipfw add 100 fwd 10.0.0.2 ip from 10.0.2.0/24 to any Если нужно использовать 2 шлюза, то можно воспользоваться: ipfw add fwd $ext_gw_ip ip from $ext_net to any out xmit $ext_int   Маршрутизация IP сервисов в DMZ через два провайдера   Автор: Pavel V. Rochnyack  [комментарии]   На форуме часто задается вопрос, по поводу маршрутизации сети, подключенной к двум провайдерам. В частном случае проблема расширяется тем, что нужно осуществлять проброс соединений к сервисам, расположенным в локальной сети. Это делается с помощью DNAT, и при этом снова возникает проблема - по каналу какого провайдера отправлять ответ. Проблема усугубляется тем, что обратное преобразование адресов выполняется уже после принятия решения о маршрутизации, т.е. примерно в районе цепочки POSTROUTING, но скрытно от пользователя. Решить эту нерешаемую проблему поможет модуль CONNMARK. Принцип работы маршрутизатора для решения описанной задачи будет выглядеть примерно так: Входящие соединения маркируются определенным флажком, после чего делается их проброс в нужное назначение. Каждый обратный пакет соединения _до принятия решения о маршрутизации_ маркируется флажком соответствующего ему соединения (флажок восстанавливается). На основании флажков принимается решение о маршрутизации пакета в соответствующую сеть. В нижеописанном примере обеспечение доступности сервиса по двум каналам/провайдерам делалось для локального сервиса маршрутизатора. В связи с этим маркировка исходящих пакетов делается в цепочке OUTPUT таблицы mangle. Для проброса порта к серверу в локальной сети (в DMZ) проверку и восстановление маркера надо делать в цепочке PREROUTING. Таким образом, "обратный DNAT" будет происходить когда пакет уже будет идти по нужному маршруту. Все не маркированные пакеты будут идти по маршруту по умолчанию. В моем случае это первый провайдер first и айпи интерфейса first_ip. Входящие пакеты/соединения с порта второго провайдера (destination <second_ip>) будут помечены маркером и к ним будет применен DNAT. Все исходящие (обратные) пакеты будут промаркированы значением маркера соединения в цепочке OUTPUT таблицы mangle. Более корректным вариантом, не зависящим от значения шлюза по умолчанию, является обязательная маркировка пакетов для соединений от любого провадера и создание соответствующих правил маршрутизации. [root@test z]# iptables -t nat -nvL PREROUTING Chain PREROUTING (policy ACCEPT 144M packets, 9659M bytes) pkts bytes target prot opt in out source destination 1 52 CONNMARK tcp -- * * 0.0.0.0/0 <second_ip> tcp dpt:<port> CONNMARK set 0x1 1 52 DNAT tcp -- * * 0.0.0.0/0 <second_ip> tcp dpt:<port> to:<first_ip>:<port> [root@test z]# iptables -t mangle -nvL OUTPUT Chain OUTPUT (policy ACCEPT 6745M packets, 7048G bytes) pkts bytes target prot opt in out source destination 65915 8600K CONNMARK tcp -- * * <first_ip> 0.0.0.0/0 tcp spt:<port> CONNMARK restore [root@test z]# ip ru sh 0: from all lookup local 1000: from all lookup main 3300: from all fwmark 0x1 lookup <second> 5000: from <first_ip> lookup <first> 5500: from <second_ip> lookup <second> 10000: from all lookup default 32766: from all lookup main 32767: from all lookup default

PPP, PPTP, PPPOE

Как поднять выделенное соединение по PPP.   [комментарии]   Скрипт /etc/ppp.sh: #!/bin/sh while : ; do pppd cuaa0 115200 noipdefault noauth defaultroute nodetach done   Настройка устойчивого подключения к провайдеру Beeline (Corbina) в CentOS6/RHEL6 (доп. ссылка 1)   Автор: Ilya  [комментарии]   Настройка устойчивого подключения к провайдеру Internet Beeline (Corbina) в CentOS6 и RHEL6 по протоколу l2tp, с помощью openl2tp. Продолжение опуса - http://www.opennet.me/tips/info/2539.shtml Многие идеи и скрипты были взяты из Debian(6). Для краткости изложения, привожу, только имена скриптов и конфигурационных файлов задействованных в процессе соединения и описание происходящих событий. Совет: если нет необходимости, или выбор дистрибутива не имеет значения, в Debian настройка выполняется проще и без установки дополнительных пакетов. Все необходимые пакеты (x86_64), скрипты, исходники можно найти по адресу http://www.ilyx.ru/openl2tp Дано: 1. Локальное подключения: ethernet 100Mb(eth0). 2. Login и Password для подключения к серверу tp.internet.beeline.ru. Необходимо: 1. Получить настройки по DHCP (локальный IP, маршруты, DNS сервера) через eth0. 2. Подключиться к Internet: с помощью openl2tp через сервер tp.internet.beeline.ru. Начнем с принципиальных трудностей и их устранения. Ядро (на данный момент 2.6.32-279.5.2.el6) собрано без заплатки для модуля "pppol2tp" - https://lkml.org/lkml/2011/5/5/416 - "Fix UDP socket reference count bugs in the pppol2tp driver", что не даст нам получить устойчивое соединение. В Debian(6) все нормально. Чтобы не пересобирать этот модуль для каждого нового ядра, я, воспользовавшись наработками http://elrepo.org, собрал пакет с пропатченным модулем. Устанавливаем "kmod-pppol2tp". "pppd" нас "радует" отсутствием необходимых плагинов openl2tp.so и pppol2tp.so из-за ошибок при сборке. Установим пакет - "openl2tp-ppp" - который является побочным продуктом при сборке openl2tp для RHEL6 после внесения необходимых изменений см. openl2tp-1.8-1.el6.src.rpm. Опять же, в Debian(6) все нормально. После этого устанавливаем сам openl2tp. Далее устанавливаем все необходимое из архива в /etc/* вносим необходимые изменения в файлы - /etc/sysconfig/network-scripts/ifcfg-* ; Если надо. /etc/openl2tpd.conf ; Меняем user_name= и dest_ipaddr= /etc/ppp/chap-secrets ; Меняем client, secret chkconfig openl2tpd on semodule -i pppol2tp.pp ; Если включен SELINUX. shutdown -r now Пояснение: Каталог /etc/dhcp - содержит конфигурационный файл dhclient.conf и скрипты для обработки параметров полученных по DHCP и не обрабатываемых по умолчанию утилитой dhclient. Результатом работы dhclient после поднятия eth0 должно быть: присвоение IP адреса (10.*.*.*) интерфейсу eth0, заполнение довольно внушительной, таблицы маршрутов к локальным сервисам Beeline, доступным без подключения к Internet, заполнение /etc/resolv.conf и установка временного маршрута по умолчанию. Также в файле /etc/dhcp-default-router сохраняется, IP адрес, полученного маршрута по умолчанию, для последующей настройке маршрутов при запуске и завершение openl2tpd(pppd). В файле /etc/openl2tpd.conf рекомендую в поле dest_ipaddr= указать IP адрес tp.internet.beeline.ru, а не tp.internet.beeline.ru, т.к. в случае если при разыменование произойдет сбой, openl2tpd завершится, без дальнейших попыток переустановить соединение. Можно выбрать понравившийся IP адрес, несколько раз запустив "ping -c 1 tp.internet.beeline.ru". Каталог /etc/ppp - содержит простейшие скрипты и необходимые настройки, спецефичные для RHEL6, для настройки таблицы маршрутов при поднятие "pppX" интерфейса используя файл /etc/dhcp-default-router. Если используем как маршрутизатор, добавляем где-нибудь в iptables: iptables -t mangle -A FORWARD -o pppX -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1421:65496 -j TCPMSS --clamp-mss-to-pmtu P.S. В некоторых скриптах используется, при настройке маршрутов, параметр metric 10, это только для отладочных целей, чтобы определенные маршруты выделить из общей массы, никакой иной роли, этот параметр, в данном случае не имеет. P.S.2. У меня конечная таблица маршрутов выглядит так: http://ilyx.ru/openl2tp/openl2tpCEntOS.txt   pptpd и решение проблемы маршрута по умолчанию   Автор: Брызгалов Константин  [комментарии]   Суть вопроса: Имеем настроенный на linux pptp сервер для подключения внешних клиентов к ресурсам внутренней сети. При установлении соединения с pptp сервером на машине windows клиента поднимается маршрут по умолчанию с более высоким приоритетом, чем маршрут через основное подключение. Вследствие чего перестает работать связь с Интернет, со всеми вытекающими последствиями. Если же в свойствах pptp соединения отключить галочку с пункта "Использовать основной шлюз в удаленной сети", то пропадает связь до ресурсов в удаленной сети. Возможности передать маршруты в рамках соединения клиент-сервер через pptpd нет. Решение: Используем мапирование адресных пространств сетей. Будем транслировать то пространство, которое является локальным для интерфеса windows клиента после установки соединения. Например, имеем адресное пространство удаленной(по отношению к клиенту) сети 192.168.0.0/24, а адрес интерфейса pptpd: # grep localip /etc/pptpd.conf localip 10.50.11.1 Настраиваем трансляцию адресного пространства: # iptables -t nat -A PREROUTING -d 10.50.11.0/24 -j NETMAP --to 192.168.0.0/24 -m comment --comment "For_PPTPD_clients" После чего с клиентской машины есть связь и с интернет, и с ресурсами удаленной сети через адреса 10.50.11.x. Неудобство с применением IP можно обойти через настройку dns с использованием отдельной зоны для клиентов pptpd сервера. Необходимо отметить, что есть еще другой путь решения проблемы - через настройку отдельного dhcp на стороне сервера и использования option ms-classless-static-routes code, option rfc3442-classless-static-routes code. Встретил здесь. Может быть он более правильный, но мне приведенное решение показалось более красивым и простым. PS: Не забудьте разрешить соединения через цепочку FORWARD, если используется политика "Запрещено все, что не разрешено".   Как в mpd5 присвоить определенный номер для ng интерфейса (доп. ссылка 1)   Автор: PavelR  [комментарии]   Несколько интерфейсов в Multi-link PPP Daemon, например два, можно сделать следующим образом: create bundle static NAME create link static NAME1 TYPE set link action bundle NAME create link static NAME2 TYPE set link action bundle NAME В результате получится два интерфейса, у одного будет жестко ng0, у второго ng1, они появятся в системе сразу после запуска mpd, просто будут в DOWN, пока mpd не подымет линки.   Проверка GSM/UMTS оператора в chat-скрипте (доп. ссылка 1)   Автор: Kirill Zabarniuk  [комментарии]   В ситуации работы через нескольких операторов для проверки активного GSM/UMTS-оператора, к которому в данный момент подключился модем, в chatscript можно использовать следующую конструкцию: '' ATZ OK-AT-OK "AT+COPS=?" UTEL3G '' OK-AT-OK AT+CGDCONT=1,"IP","unlim.utel.ua" OK-AT-OK "ATDT*99***1#" CONNECT '' '' \d\c Список экзотичных GPRS/3G/UMTS/HSDPA AT-команд можно посмотреть здесь.   Решение проблемы с MPPE, при использовании связки linux, ppp, poptop и IAS (доп. ссылка 1)   Автор: mdv  [комментарии]   Проблема: pppd[27229]: MPPE required, but keys are not available. Possible plugin problem? Решение: В свойствах "remote access policy", щелкаем "edit profile", на вкладе "encryption" убираем галку No Encryption, Apply, ok. И не верьте никому, что это влияет только на MS RRAS. Причина: Без этой настройки IAS начинает отдавать вот такие радиус-атрибуты: MS-MPPE-Encryption-Policy MS-MPPE-Encryption-Types а с ним, включенным по-умолчанию, не отдает.   Сохранение статистики pppd в MySQL   Автор: Андрей "squirL" Товстик  [комментарии]   Вот такой код я использую, чтобы вести учет статистики для PPP соединений в MySQL. Этот код помещается в скрипт /etc/ppp/ip-down. Используются переменные окружения, устанавливаемые pppd. #!/bin/sh # echo "INSERT INTO pppdstats VALUES ( `date +%Y%m%d`, `date +\'%T\' -d\"-${CONNECT_TIME} sec\" ` , '$PEERNAME', '$IPREMOTE', '$CONNECT_TIME', '$BYTES_SENT', '$BYTES_RCVD', '$DEVICE', `date +\'%T\'`);" | mysql -uuser -ppassword database Формат таблицы: CREATE TABLE pppdstats ( c_date date, c_start_time time, user varchar(128), ip_addr varchar(15), online_time int(11), send_bytes int(11), recv_bytes int(11), device varchar(15), c_end_time time ); PS: Естественно, что изменив перенаправление можно записывать статистику в обычный текстовый файл.   Настройка клиентского PPTP соединения по msCHAPv2 в Linux (доп. ссылка 1)   Автор: onorua  [комментарии]   /etc/ppp/chap-secrets # Secrets for authentication using CHAP # client server secret IP addresses vkXXXX * password /etc/ppp/options.pptp lock +chap require-mschap-v2 nobsdcomp nodeflate noaccomp nopcomp defaultroute noipdefault mtu 1000 mru 1000 ipcp-accept-local ipcp-accept-remote noauth /etc/ppp/peers/topnet user vkXXXX defaultroute noauth mru 1000 mtu 1000 Запускаем: sudo pptp 172.16.0.206 call topnet Завершаем сервис: sudo killall pptp   Автоподъем pptp linux-клиента на Fedora Core Linux   Автор: Abor Mot  [комментарии]   После безуспешного шаманства вокруг pppd с использованием persist, holdof и maxfail решил написать следующий скрипт. Запускается из rc.local #!/usr/bin/perl use strict; use Net::Ping; my $hping=Net::Ping->new("icmp"); my $s=0; sub logger($) { my @ldata=localtime;$ldata[5]+=1900;$ldata[4]+=1; my $j = 0; for ($j = 0;$j < 5; $j++) { if ($ldata[$j] <10) { $ldata[$j] = "0" . $ldata[$j]; } } my $data1="$ldata[3]/$ldata[4]/$ldata[5] $ldata[2]:$ldata[1]:$ldata[0]"; open (MAN_LOG, ">>/var/log/ppp_watcher"); print MAN_LOG "pw: $data1\t$_[0]\n"; close(MAN_LOG) } logger("daemon started."); `echo "kill -15 $$" > /root/ppp_watch.die`; `chmod 0700 /root/ppp_watch.die`; sub ppp_watch { my @presence=split(' ', `ifconfig | grep ppp0`); $presence[0].=''; if ($presence[0] ne 'ppp0') { logger("trying to start daemon."); `route add -net <LOCAL NETWORK> netmask 255.255.255.0 gw <LOCAL GW> 2>/dev/null`; `sleep 2`; `pppd noauth nobsdcomp nodeflate name sspm pty "pptp <GW> --nolaunchpppd" 2>/dev/null`; `sleep 3`; `route add -net <IP> netmask 255.255.255.0 gw <GW> 2>/dev/null`; `sleep 2`; `route del -net 0.0.0.0 netmask 0.0.0.0 gw <LOCAL IP> 2>/dev/null`; `sleep 3`; `route add -net 0.0.0.0 netmask 0.0.0.0 dev ppp0`; $SIG{'ALRM'}='ppp_watch'; logger("delaying for 20 sec..."); alarm(20); } else { my @traff=split(' ', `pppstats | tail -1`); logger("watching, total traffic $traff[0]"); $SIG{'ALRM'}='ppp_watch'; alarm(5); } } ppp_watch; sub ppp_die { $s=1; } $SIG{'TERM'}='ppp_die'; while ($s ne 1) { } logger("daemon stopped."); exit 0; Кроме всего прочего ведет лог состояния и трафика.   Настройка ADSL для Стрима под FreeBSD 4.9/5.3 (доп. ссылка 1)   Автор: Dmitry Pupkov  [комментарии]   запускать bash# ppp -ddial test Или если мы хотим поднимать соединение при старте, в rc.conf: ppp_enable="YES" ppp_mode="ddial" ppp_profile="test" и никаких tun0! xl0 - ethernet карта куда воткнут модем (у меня Zyxel Omni ADSL LAN EE) Вот как у меня, /etc/ppp/ppp.conf: default: test: set device PPPoE:xl0 set MTU 1492 set MRU 1492 set dial set crtscts off set speed sync accept lqr disable deflate disable pred1 disable vjcomp disable acfcomp disable protocomp set log Phase LCP IPCP CCP Warning Error Alert set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 add default HISADDR set login set authname ppp0012345@mtu set authkey your_password set server /var/run/ppp/ppp.pid "" 0117   Настройка PPTP-клиента на FreeBSD (альтернативный вариант)   Автор: Skylord  [комментарии]   Точнее, частично альтернативный. Используем все тот же pptpclient из портов, прописываем роутинг к адресу vpn-сервера (если он в другом сегменте), а потом добавляем в ppp.conf нечто подобное: vpn: set device "!pptp <vpn_server_address> --nolaunchpppd" set dial set login set server /var/run/ppp/loop "" 0177 set timeout 3600 set reconnect 120 0 enable dns set authname <vpn_login> set authkey <vpn_password> nat enable yes enable lqr disable ipv6cp disable mppe set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR Это мой конфиг и, естественно, не все из этого (типа, таймаутов и реконнектов) нужно всем. Как видно, в данном случае не pptp вызывает ppp, а наоборот. Главный бонус как раз в том, что можно без геморроя обеспечить on demand'овое соединение (потому и реконнекты с таймаутами у меня стоят) и автоматическое его поднятие, если vpn_server сдох, а потом ожил. Ну и мелкие приятности - типа включения из rc.conf без необходимости написания дополнительных скриптов....   Как в pppd зафиксировать номер PPP интерфейса   [комментарии]   Необходимо использовать опцию "unit N", где N - номер ppp интерфейса. Например, для привязки к ppp0: /usr/sbin/pppd /dev/ttyS0 115200 noauth crtscts 192.168.1.245:192.168.1.246 local \ nodetach netmask 255.255.255.252 unit 0   Настройка PPTP-клиента под FreeBSD (доп. ссылка 1)   Автор: l0ner  [комментарии]   Необходимо установить из портов пакет pptpclient /etc/ppp/ppp.conf vpn: set authname <LOGIN> set authkey <PASSWORD> set timeout 0 set ifaddr 0 0 add default HISADDR Подключение к VBN серверу: /sbin/route add -host <IP_address_of_VPN_server> <gateway> /usr/local/sbin/pptp <IP_address_of_VPN_server> vpn &

Wifi, настройка беспроводного доступа

Решение проблемы с картами Intel после устранения уязвимости в WPA2 в wpa_supplicant (доп. ссылка 1)   Автор: sfstudio  [комментарии]   После обновления wpa_supplicant с правками, касающимися уязвимости WPA2 CRACK, многие владельцы беспроводных карт Intel (3160, 3168, 7260, 7265, 8000C, 8265) могли обратить внимание на странное поведение адаптера. Проявляется оно как потеря связи на некоторое время с интервалом в половину времени истечения срока жизни GTK. При этом в логах нет абсолютно никакого криминала. Нет также и попыток переподключения, просто останавливается хождение данных, пока роутер или точка доступа не отстрелят такого клиента по idle timeout. Проблема оказалась в том, что intel частично реализует логику SME (даже в случае использования nl80211 подсистемы ядра) на уровне микрокода. И после внесения правок на стороне supplicant&#8217;а, обновление группового ключа происходит не всегда корректно. Исправление микрокода Intel представил в обновлении от 3.11.2017, однако большинство дистрибутивов так и не обновили микрокод, хотя обновили supplicant. Отсюда и появилась проблема. Для решения, достаточно загрузить новый микрокод: git clone https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git После чего содержимое скопировать поверх /lib/firmware и перезагрузиться. Проконтроллировать успех решения проблемы можно заглянув до и после обновления в вывод dmesg и обратив внимание на строку iwlwifi 0000:01:00.0: loaded firmware version XX.YYYYYY.Z op_mode iwlmvm. Кроме всего прочего, неаккуратно бэкпортированные исправления уязвимости wpa_supplicant в Mageia 6 ломают миграцию. Клиент перестаёт выполнять автоматические фоновые сканирования и даже не пытается мигрировать. Решение - сборка последней версии wpa_supplicant из git, куда уже включены все необходимые правки, а также сообщения о проблеме разработчикам своих дистрибутивов.   Настройка локальной Wi-Fi точки доступа в Linux (доп. ссылка 1)   [комментарии]   Настройка точки беспроводного доступа на ноутбуке или рабочей станции с Linux. eth0 - сетевой интерфейс, через который осуществляется выход в интернет. wlan0 - интерфейс беспроводной карты (IP 10.0.0.1). Поднимает сетевой интерфейс: ip link set dev wlan0 up ip addr add 10.0.0.1/24 dev wlan0 Настраиваем dnsmasq для отдачи клиентам IP по DHCP и обработки DNS-запросов. Используем подсеть 10.0.0.0/24 tmp-dnsmasq.conf: interface=wlan0 bind-interfaces # Шлюз по умолчанию dhcp-option=3,10.0.0.1 # Список DNS-серверов dhcp-option=6,10.0.0.1 # Диапазон отдаваемых клиентам IP dhcp-range=10.0.0.2,10.0.0.10,12h no-hosts no-resolv log-queries log-facility=/var/log/dnsmasq.log # Рабочий DNS-сервер server=8.8.8.8 server=8.8.4.4 Запускаем dnsmasq: dnsmasq --conf-file=tmp-dnsmasq.conf Настраиваем трансляцию адресов через iptables для обеспечения выхода в интернет: echo '1' > /proc/sys/net/ipv4/ip_forward iptables -A FORWARD -i eth0 -o wlan0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Настраиваем hostapd для работы точки беспроводного доступа: tmp-hotspot.conf ctrl_interface=/var/run/hostapd interface=wlan0 # ESSID, идентификатор беспроводной сети. ssid=TEST driver=nl80211 # hostap, bsd channel=11 # если 0 до автоматический выбор канала hw_mode=g # g - 2.4GHz, a - 5GHz ieee80211d=1 # применение ограничений по частотам для выбранной страны country_code=RU # разрешаем все MAC-адреса, кроме занесённых в чёрный список macaddr_acl=0 # если 1, то разрешение входа только по белому списку (accept_mac_file) deny_mac_file=/etc/hostapd.deny wmm_enabled=0 # 1 - включение QoS auth_algs=1 # 1=wpa, 2=wep, 3=wpa+wep wpa=2 # только WPA2 # Настройки для входа с авторизацией, без них разрешается вход без пароля wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP wpa_passphrase=пароль_для_полключения Запускаем hostapd: hostapd tmp-hotspot.conf   Создания WiFi-ретрансляторов с поддержкой построения Mesh-сети (доп. ссылка 1)   [комментарии]   Для микроконтроллеров ESP 8285 и 8266 со встроенным беспроводным адаптером, которые продаются в китайских интернет-магазинах по цене около 100 руб, подготовлена прошивка с реализацией ретранслятора, позволяющего увеличить зону покрытия существующей беспроводной сети. Ретранслятор реализован в виде точки доступа, прозрачно передающей весь трафик на вышестоящую точку доступа, используя трансляцию адресов (NAT) для организации проброса (не требуется изменение настроек и маршрутизации). Несколько ретрансляторов могут связываться между собой, по цепочке пробрасывая канал связи и образуя Mesh-сеть. Для настройки параметров подключения предоставляется консольный и web-интерфейс (задаётся пароль подключения к внешней беспроводной сети, пароль для подключения к ретранслятору и выбор режима работы). Поддерживаются функции межсетевого экрана, позволяющего ограничить доступ к IP-адресам, подсетям и сетевым портам через простой ACL, а также ограничить пропускную способность подключения клиента. Для IoT-устройств предусмотрена поддержка протокола MQTT. Имеется поддержка режима мониторинга, позволяющего анализировать проходящий через ретранслятор трафик в приложениях, поддерживающих формат pcap (например, wireshark). Для прошивки достаточно подключить плату через последовательный порт или переходник USB2Serial, загрузить готовые сборки прошивки (0x00000.bin и 0x10000.bin) и записать их при помощи специально подготовленной утилиты: esptool.py --port /dev/ttyUSB0 write_flash -fs 4MB -ff 80m -fm dio 0x00000 firmware/0x00000.bin 0x10000 firmware/0x10000.bin Через консоль можно сразу настроить параметры работы ретранслятора: set ssid идентификатор-основной-сети set password пароль-подключения-к-основной-сети set ap_ssid идентификатор-сети-ретранслятора set ap_password пароль-подключения-к-сети-ретранслятора set ap_open 0 set ap_on 1 save   Как увеличить охват квартиры точкой доступа при помощи алюминиевой фольги (доп. ссылка 1)   [комментарии]   В случае если беспроводная точка доступа размещена у одной из боковых стен в квартире и в дальних комнатах наблюдается плохой уровень сигнала, решить проблему можно разместив за антеннами точки доступа импровизированный отражатель из обычной пищевой алюминиевой фольги. Отражатель следует ориентировать по направлению комнат с плохим уровнем сигнала. Эффект превосходит все ожидания и в местах, где раньше сеть была недоступна становится можно полноценно работать. Зона покрытия без отражающего экрана: Зона покрытия с отражающим экраном:   Проверка безопасности беспроводной сети WPA/WPA2 при помощи Aircrack-ng и Hashcat (доп. ссылка 1)   [комментарии]   Беспроводные сети на базе WPA/WPA2 не подвержены прямым методам атаки, но злоумышленник может получить доступ к системам, на которых установлен недостаточно надёжный пароль. Нижеприведённая инструкция позволяет проверить свои системы на предмет стойкости к атаке по типовому словарю паролей. Предлагается два метода восстановления пароля по перехваченному в трафике хэшу - при помощи Aircrack-ng и Hashcat. Устанавливаем Aircrack-ng: sudo apt-get install aircrack-ng Определяем, поддерживает ли беспроводная карта режим мониторинга (http://aircrack-ng.org/doku.php?id=compatible_cards - выбор поддерживаемых плат), на выходе будет список сетевых интерфейсов для которых имеется подобная поддержка: airmon-ng Переводим беспроводную плату в режим мониторинга: airmon-ng start wlan0 Отслеживаем все проходящие в эфире кадры на предмет идентификаторов беспроводной сети (BSSID) и используемых номеров каналов. airodump-ng mon0 BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 9C:5E:8A:C9:AB:C0 -81 19 0 0 6 54e WPA2 CCMP PSK mywifi ... Определив, что наша сеть имеет BSSID 9C:5E:8A:C9:AB:C0 и 6 канал, отслеживаем и сохраняем в файл capture/-01.cap трафик пакетов, связанных с согласованием нового соединения (ждём пока появится надпись "WPA handshake" и прерываем перехват по ctrl-c): airodump-ng -c 6 --bssid 9C:5E:8A:C9:AB:C0 -w capture/ mon0 Для того, чтобы не ждать долго инициируем обрыв соединения у подключенных клиентов (64:BC:0C:49:87:F7 - идентификатор клиента): airodump-ng -c 6 --bssid 9C:5E:8A:C9:AB:C0 mon0 BSSID STATION PWR Rate Lost Frames Probe 9C:5E:8A:C9:AB:C0 64:BC:0C:49:87:F7 -37 1e- 1e 4 6479 ASUS aireplay-ng -0 10 -a 9C:5E:8A:C9:AB:C0 -c 64:BC:0C:49:87:F7 mon0 Загружаем словарь с примерами паролей (размер 134MB, около 14 млн типовых паролей): curl -L -o rockyou.txt https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt Запускаем aircrack-ng в режиме подбора хэша пароля по словарю (подбор выполняется только на CPU, без привлечения GPU): aircrack-ng -a2 -b 9C:5E:8A:C9:AB:C0 -w rockyou.txt capture/-01.cap Или используем для этого naive-hashcat (более эффективен при наличии доступа к GPU), предварительно преобразовав cap-дамп в формат hccapx при помощи утилиты cap2hccapx: cap2hccapx.bin capture/-01.cap capture/-01.hccapx HASH_FILE=hackme.hccapx POT_FILE=hackme.pot HASH_TYPE=2500 ./naive-hashcat.sh Дополнение: Опубликован новый метод атаки, который не требует ожидания подключения к сети нового пользователя и сохранения всей активности, связанной с установкой им соединения. Для получения данных, достаточных для начала подбора пароля, новый метод требует перехвата лишь одного кадра, который можно получить в любое время, отправив запрос аутентификации к точке доступа. Для проведения атаки требуются свежие версии: * hcxdumptool * hcxtools * hashcat Запускаем hcxdumptool, отправляем запрос к точке доступа для получения PMKID и сохраняем результат в файл в формате pcapng: ./hcxdumptool -o test.pcapng -i wlp39s0f3u4u5 --enable_status start capturing (stop with ctrl+c) INTERFACE:...............: wlp39s0f3u4u5 FILTERLIST...............: 0 entries MAC CLIENT...............: 89acf0e761f4 (client) MAC ACCESS POINT.........: 4604ba734d4e (start NIC) EAPOL TIMEOUT............: 20000 DEAUTHENTICATIONINTERVALL: 10 beacons GIVE UP DEAUTHENTICATIONS: 20 tries REPLAYCOUNTER............: 62083 .... [13:29:57 - 011] 89acf0e761f4 -> 4604ba734d4e [ASSOCIATIONREQUEST, SEQUENCE 4] [13:29:57 - 011] 4604ba734d4e -> 89acf0e761f4 [ASSOCIATIONRESPONSE, SEQUENCE 1206] [13:29:57 - 011] 4604ba734d4e -> 89acf0e761f4 [FOUND PMKID] В случае если точка доступа поддерживает отправку PMKID будет выведено сообщение "FOUND PMKID". Из-за помех перехват может не получиться с первого раза, поэтому рекомендуется запускать hcxdumptool в течение приблизительно 10 минут. Запускаем утилиту hcxpcaptool для преобразования перехваченного дампа из формата pcapng в формат для разбора в hashcat. ./hcxpcaptool -z test.16800 test.pcapng start reading from test.pcapng summary: -------- file name....................: test.pcapng file type....................: pcapng 1.0 file hardware information....: x86_64 file os information..........: Linux 4.17.11-arch1 file application information.: hcxdumptool 4.2.0 network type.................: DLT_IEEE802_11_RADIO (127) endianess....................: little endian read errors..................: flawless packets inside...............: 66 skipped packets..............: 0 packets with FCS.............: 0 beacons (with ESSID inside)..: 17 probe requests...............: 1 probe responses..............: 11 association requests.........: 5 association responses........: 5 authentications (OPEN SYSTEM): 13 authentications (BROADCOM)...: 1 EAPOL packets................: 14 EAPOL PMKIDs.................: 1 1 PMKID(s) written to test.16800 Содержимое записанного файла включает строки вида "2582a81d0e61c61*4604ba734d4e*89acf0e761f4*ed487162465af3a", которые содержат шестнадцатеричные значения PMKID, MAC AP,MAC Station и ESSID. Дополнительно при запуске hcxpcaptool можно использовать опции "-E", "-I" и '-U" для анализа наличия паролей, идентификаторов и имён пользователей в беспроводном трафике: ./hcxpcaptool -E essidlist -I identitylist -U usernamelist -z test.16800 test.pcapng Запускаем hashcat для подбора пароля (применяется режим 16800): ./hashcat -m 16800 test.16800 -a 3 -w 3 '?l?l?l?l?l?lt!' hashcat (v4.2.0) starting... OpenCL Platform #1: NVIDIA Corporation ====================================== * Device #1: GeForce GTX 1080, 2028/8112 MB allocatable, 20MCU * Device #2: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU * Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU * Device #4: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU Hashes: 1 digests; 1 unique digests, 1 unique salts Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates Applicable optimizers: * Zero-Byte * Single-Hash * Single-Salt * Brute-Force * Slow-Hash-SIMD-LOOP Minimum password length supported by kernel: 8 Maximum password length supported by kernel: 63 Watchdog: Temperature abort trigger set to 90c 2582573161c61*4604d4e*89acf0e761f4*ed4824639f3a:hashcat! Session..........: hashcat Status...........: Cracked Hash.Type........: WPA-PMKID-PBKDF2 Hash.Target......: 2582a8281d0e61c61*4604ba734d4e*89acf...a39f3a Time.Started.....: Sun Aug 12 12:51:38 2018 (41 secs) Time.Estimated...: Sun Aug 12 12:52:19 2018 (0 secs) Guess.Mask.......: ?l?l?l?l?l?lt! [8] Guess.Queue......: 1/1 (100.00%) Speed.Dev.#1.....: 408.9 kH/s (103.86ms) @ Accel:64 Loops:128 Thr:1024 Vec:1 Speed.Dev.#2.....: 408.6 kH/s (104.90ms) @ Accel:64 Loops:128 Thr:1024 Vec:1 Speed.Dev.#3.....: 412.9 kH/s (102.50ms) @ Accel:64 Loops:128 Thr:1024 Vec:1 Speed.Dev.#4.....: 410.9 kH/s (104.66ms) @ Accel:64 Loops:128 Thr:1024 Vec:1 Speed.Dev.#*.....: 1641.3 kH/s Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.........: 66846720/308915776 (21.64%) Rejected.........: 0/66846720 (0.00%) Restore.Point....: 0/11881376 (0.00%) Candidates.#1....: hariert! -> hhzkzet! Candidates.#2....: hdtivst! -> hzxkbnt! Candidates.#3....: gnxpwet! -> gwqivst! Candidates.#4....: gxhcddt! -> grjmrut! HWMon.Dev.#1.....: Temp: 81c Fan: 54% Util: 75% Core:1771MHz Mem:4513MHz Bus:1 HWMon.Dev.#2.....: Temp: 81c Fan: 54% Util:100% Core:1607MHz Mem:4513MHz Bus:1 HWMon.Dev.#3.....: Temp: 81c Fan: 54% Util: 94% Core:1683MHz Mem:4513MHz Bus:1 HWMon.Dev.#4.....: Temp: 81c Fan: 54% Util: 93% Core:1620MHz Mem:4513MHz Bus:1   Решение проблем с работой поставляемых в ноутбуках Samsung WiFi-адаптеров Broadcom BCM4313 в Ubuntu   [комментарии]   Многие модели ноутбуков Samsung укомплектованы WiFi-адаптерами на базе чипа Broadcom BCM4313. При этом в процессе работы, при использовании штатных открытых драйверов, идущих в базовой поставке Ubuntu, от версии к версии наблюдаются разнообразные проблемы. Например, подсоединиться к Wifi-сетям удаётся с десятой попытки или сеть периодически зависает - линк поднят, но данные через сетевой интерфейс не передаются до пересоединения с беспроводной сетью. Решение проблемы простое, поставить проприетаный вариант прошивки: sudo apt-get remove --purge bcmwl-kernel-source sudo apt-get install linux-firmware-nonfree sudo apt-get install firmware-b43-installer после чего нужно перезагрузить систему для загрузки новой прошивки.   Отключение STP в точках доступа ASUS WL520gc (доп. ссылка 1)   Автор: vvm7ua  [комментарии]   Не так давно столкнулся с ситуацией, когда есть в сети несколько точек доступа ASUS WL520gc, который "гоняют" по сети лишний трафик в виде STP. Решение было найдено следующее: необходимо зайти на страницу роутера по адресу http://ip/Main_AdmStatus_Content.asp ввести в после System Command: значение nvram set lan_stp=0 нажать кнопку Refresh затем ввести nvram commit и снова нажать кнопку Refresh после этого необходимо будет ввести reboot и опять нажать Refresh Роутер уйдет на перезагрузку и STP таким образом более не будет тревожить другие сетевые устройства в сети.   Настройка беспроводного соединения в Debian GNU/Linux   Автор: screenn  [комментарии]   Действия по настройке Wi-Fi проводились в стабильном дистрибутиве Debian GNU/Linux 6.0.4 Ранее длительное время я работал с модулем NDISwrapper, который удавалось запускать с поддержкой WEP шифрования. После того как WEP шифрование было принято считать небезопасным, под рукой оказалось решение под названием wpasupplicant позволяющее работать с WPA и WPA2 методами шифрования в беспроводных сетях, которое было взято на вооружение в совокупности с драйверами b43 - в них на этот момент уже поддерживались Broadcom устройства. Все прекрасно работало пока не было принято решение вернуться к стабильному дистрибутиву после многолетних экспериментов работы в среде sid, что повлекло за собой переустановку и необходимость перенастройки системы и написания данной инструкции. Для начала необходимо убедиться в присутствии беспроводного адаптера - команда lspci lspci В моем случае обнаружились ethernet и wifi сетевые карты: 02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02) 04:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01) Немного погуглив удалось найти информацию на английском языке http://wiki.debian.org/bcm43xx - там есть список с описанием модулей, в каких ядрах и версиях системы они работают а где нет. А также инструкция по установке. Оказалось на сегодняшний день есть несколько разновидностей драйверов для Linux: b43, b43legacy, brcm80211, rndis_wlan, wl, наряду с которыми все так же остается возможность запускать WINDOWS-драйвер сетевых карт при помощи NDISwrapper модуля. Далее просто приведу шаги выполненные по вышеприведенной инструкции: 1. Необходимо добавить contrib non-free части в строку с источником установки, отредактировав файл /etc/apt/sources.list #строка с источником установки пакетов системы deb http://ftp.us.debian.org/debian squeeze main contrib non-free 2. После добавления новых источников установки необходимо обновить список доступных пакетов и установить утилиту wireless-tools aptitude update && aptitude install wireless-tools 3. Далее следует установка самих драйверов, в зависимости от типа вашей сетевой карты необходимо выбрать правильный драйвер, в моем случае это устройство BCM4312 802.11b/g LP-PHY - как показала команда lspci, поэтому я выполняю команду устанавливающую firmware-b43-lpphy-installer. Для владельцев других сетевых карт соответственно: 802.11b/g BCM4306 revision 3, BCM4311, BCM4318 - устанавливаем firmware-b43-installer; 802.11b BCM4301, 802.11b/g BCM4306 revision 2 chipset - устанавливаем firmware-b43legacy-installer; aptitude install firmware-b43-lpphy-installer aptitude install firmware-b43-lpphy-installer 4. Проверим что модуль загрузился: # lsmod | grep b43 b43 132415 0 rng_core 2178 1 b43 mac80211 122874 1 b43 cfg80211 86965 2 b43,mac80211 ssb 33578 1 b43 led_class 1757 3 b43,acer_wmi,sdhci mmc_core 38277 3 b43,sdhci,ssb pcmcia 16194 2 b43,ssb pcmcia_core 20414 5 b43,yenta_socket,rsrc_nonstatic,ssb,pcmcia Модуль b43 - загружен успешно, если у вас он окажется не загружен, можно попробовать загрузить его командой modprobe b43, в случае если он загружен но не отрабатывает корректно - можно попробовать сначала его выгрузить командой modprobe -r b43 после чего загрузить заново. 5. Драйверы установлены и загружены теперь можно проверить наличие wifi карты в списке сетевых устройств утилитой iwconfig: # iwconfig lo no wireless extensions. eth0 no wireless extensions. irda0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:off/any Mode:Managed Frequency:2.457 GHz Access Point: Not Associated Tx-Power=27 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off pan0 no wireless extensions. Видно что в списке сетевых адаптеров присутствует wlan0 - устройство распознанное как IEEE 802.11bg, это и есть ни что иное как наш wifi адаптер. 6. Далее необходимо сконфигурировать сетевые настройки в системе для нашего wifi адаптера. Для этого редактируем файл настройки сетевых подключений /etc/network/interfaces добавляя опции новой wifi сетевой карты: #my Wi-fi connection auto wlan0 iface wlan0 inet dhcp 7. Стартуем новый сетевой интерфейс - ifup wlan0 # ifup wlan0 Internet Systems Consortium DHCP Client 4.1.1-P1 Listening on LPF/wlan0/00:00:00:00:00:00 Sending on LPF/wlan0/00:00:00:00:00:00 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 2 No DHCPOFFERS received. No working leases in persistent database - sleeping. После выполнения данной команды система попытается получить адрес по dhcp, в результате чего мы увидим что адрес ей получить не удалось так как не указана точка доступа, но при этом wlan0 интерфейс появится в списке поднятых интерфейсов отображаемых при просмотре ifconfig Затем уже можно будет выполнять сканирование пространства на наличие точек доступа. Попытки просканировать пространство с неподнятым интерфейсом выдадут сообщение:"wlan0 Interface doesn't support scanning : Network is down" 8. Проверить поднялся ли wlan0 интерфейс можно командой ifconfig #ifconfig wlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:408 errors:0 dropped:0 overruns:0 frame:0 TX packets:62 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:26662 (26.0 KiB) TX bytes:6305 (6.1 KiB) 9. Если интерфейс поднялся мы можем просканировать пространство на наличие WIFI точек доступа командой - iwlist scanning # iwlist scanning lo Interface doesn't support scanning. eth0 Interface doesn't support scanning. irda0 Interface doesn't support scanning. pan0 Interface doesn't support scanning. wlan0 Scan completed : Cell 01 - Address: 00:00:00:00:00:00 Channel:13 Frequency:2.457 GHz (Channel 13) Quality=70/70 Signal level=-3 dBm Encryption key:on ESSID:"myhome" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=0000003f190b259c Extra: Last beacon: 104ms ago IE: Unknown: 00036E6574 IE: Unknown: 010C82848B8C12969824B048606C IE: Unknown: 03010A IE: Unknown: 0706555320010B1E IE: Unknown: 2A0100 IE: Unknown: 2F0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: Unknown: DD090010180200F0000000 Результаты сканирования показали наличие точки доступа под названием - ESSID:"myhome", работающей на канале - Channel:13, в режиме - Mode:Master, с включенным шифрованием - Encryption key:on, тип шифрования - IE: IEEE 802.11i/WPA2 Version 1. 10. Устанавливаем поддержку WPA/WPA2 шифрования поскольку наша точка доступа использует WPA2 apt-get install wpasupplicant 11. Конфигурируем wpasupplicant, Редактируем файл /etc/network/wpa-psk-tkip.conf # WPA-PSK/TKIP ctrl_interface=/var/run/wpa_supplicant network={ ssid="myhome" proto=WPA2 RSN key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk="пароль к точке доступа" } В моем случае конфиг выглядит именно таким образом, возможно у вас он будет отличаться если например будет отличаться метод шифрования, более подробно с опциями конфиг файла для wpasuplicant можно ознакомиться при помощи команды - man wpa_supplicant, гугла и админской интуиции. 12. Донастраиваем сетевое соединение, дописываем в конфиге /etc/network/interfaces новые строки: # The primary network interface #allow-hotplug eth0 #auto eth0 #iface eth0 inet dhcp #my Wi-fi connection auto wlan0 iface wlan0 inet dhcp wireless-channel 10 wireless-mode Master #WPA-TKIP wpa-conf /etc/network/wpa-psk-tkip.conf Как видно, я специально закомментировал знаком # eth0 интерфейс через который был подключен интернет, так как после рестарта сетевых соединений хочу чтобы интернет соединялся только через wlan0 интерфейс. Затем можно отключить eth0 интерфес командой "ifconfig eth0 down". 13. Перезагружаем сетевые соединения командой /etc/init.d/networking restart # /etc/init.d/networking restart Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces ... (warning). Reconfiguring network interfaces...Ignoring unknown interface eth0=eth0. Internet Systems Consortium DHCP Client 4.1.1-P1 Listening on LPF/wlan0/00:00:00:00:00:00 Sending on LPF/wlan0/00:00:00:00:00:00 Sending on Socket/fallback DHCPRELEASE on wlan0 to 192.168.13.1 port 67 Error for wireless request "Set Mode" (8B06) : SET failed on device wlan0 ; Invalid argument. Internet Systems Consortium DHCP Client 4.1.1-P1 Listening on LPF/wlan0/00:00:00:00:00:00 Sending on LPF/wlan0/00:00:00:00:00:00 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 192.168.13.1 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.13.1 bound to 192.168.13.13 -- renewal in 37509 seconds. done. 14. Проверим что все работает Посмотрим список поднятых интерфейсов: #ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:76 errors:0 dropped:0 overruns:0 frame:0 TX packets:76 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5802 (5.6 KiB) TX bytes:5802 (5.6 KiB) wlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.13.13 Bcast:192.168.13.255 Mask:255.255.255.0 inet6 addr: fe80::21f:e1ff:fe25:4fd4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1036 (1.0 KiB) TX bytes:1640 (1.6 KiB) Видим поднятые внутренний системный интерфейс Loopback, и наш wifi wlan0 интерфейс, теперь проверим работает ли интернет # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=54 time=69.8 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=54 time=69.6 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=54 time=69.5 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=54 time=69.5 ms 64 bytes from 8.8.8.8: icmp_req=5 ttl=54 time=69.6 ms Google пингуется отлично! Посмотрим таблицу маршрутизации системы: # ip r 192.168.13.0/24 dev wlan0 proto kernel scope link src 192.168.13.13 default via 192.168.13.1 dev wlan0 Понимаем что все работает. На этом я завершаю заметку о том как настраивать Wi-Fi в Linux. Надеюсь что данная информация будет Вам полезна, а поднять шифрованное wifi соединение при помощи родных драйверов Linux теперь не для кого не составит большого труда. Присылайте Ваши вопросы, дополнения, исправления к данному руководству на мой e-mail: [email protected], дополняйте комментариями к статье-совету ниже на сайте. Автор: Александр Головин. Полезные ссылки по теме: http://wiki.debian.org/Broadcom http://wiki.debian.org/bcm43xx http://wireless.kernel.org/en/users/Drivers/b43#Known_issues   Виртуальная точка доступа с раздачей от ADSL на базе маршрутизатора D-Link 2500u (доп. ссылка 1)   Автор: sukanax  [комментарии]   В этом примере в качестве маршрутизатора используется D-Link 2500u (перепрошитый 2300u). Необходимо чтобы dlink 2500u работал в режиме маршрутизатора. В качестве wifi-устройства использовался USB-адаптер tp-link wn721n. 1. Устанавливаем hostapd, dhcpd клиент, bridge-utils из консоли. После выполняем "sudo su" 2. Создаем файл /etc/hostapd/hostapd.conf interface=wlan0 bridge=br0 logger_stdout=-1 logger_stdout_level=2 ssid="Имя нашей точки доступа" hw_mode=g channel=6 auth_algs=3 max_num_sta=5 wpa=2 wpa_passphrase="пароль" wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP CCMP rsn_pairwise=CCMP 3. включаем ip форвардинг echo 1 > /proc/sys/net/ipv4/ip_forward 4. Создаем скрипт в любом месте нашего Linux. #!/bin/bash auto eth1 iface eth1 inet dhcp killall dhcpcd ifconfig eth0 down ifconfig wlan0 down brctl addbr br0 #Создает мост brctl addif br0 eth0 #Добавляет интерфейс eth0 к br0 мосту brctl setfd br0 0 #This sets the forwarding delay to 0 seconds hostapd -dd /etc/hostapd/hostapd.conf & iwconfig wlan0 brctl addif br0 wlan0 ifconfig eth0 up ifconfig br0 up dhcpcd br0 & exit 5. Запускаем этот скрипт и подключаем мобильное устройство по wifi к интернету. Возможно придется выключить network-manager перед запуском. Скрипт создает сетевой мост eth0 и wlan0. eth1 у меня остался для работы интернета на главном компьютере.   Настройка подключения к Comstar через USB WiMAX модем 2501 в Linux   Автор: desenix  [комментарии]   Предисловие Когда-то давно купил себе данный модем (на чипсете Beceem BCS200) с тарифом без абонентской платы, в качестве резервного канала, с тех пор пользовался от случая к случаю, тем более тариф тому способствовал. А тут недавно мой проводной провайдер отвалился на целый день и решил проверить, а не появилось ли решения под Linux? Одно дело компьютер с WiMax, а другое дело домашний роутер обеспечивающий несколько компьютеров интернетом. Что интересно в сети уже с 2010 года лежат готовые решения но для других провайдеров, а для Комстар-а нет, либо не нашёл. Да и сам провайдер не заботиться о Linux пользователях. Попадались решения и для других модемов, но как-то не возникло желания покупать ещё один, когда этот достался по акции. Введение На одно из решений наткнулся здесь. Там кто-то в комментариях очень похожий конфиг для другого провайдера выложил. Информацию по настройке параметров для Комстар частично взял отсюда. Если кто-то знает где лежат параметры сети для Yota, сообщите, размещу ссылку. Там же можно по ссылке скачать необходимый сертификат (ca1.cer), либо вытащить его из Comstar Connection Manager (далее CCM), но об этом ниже. Подготовка Нам понадобится: 1. Компьютер с Linux, у меня был c Fedora 15 (x86), пробовал модули собирать и на x86_64. 2. Как советует автор одного из решений, нужно установить пакеты linux-source linux-headers openssl unzip dos2unix patch gcc. Возможно у вас они будут называться немного иначе (у меня первые два такие kernel-debug kernel-headers), и это возможно не полный список.\ 3. Самое главное Sprint 4G Depelopment Pack, по данной ссылке всегда последняя версия, где взять предыдущие не знаю. Кстати, этот пакет, позволяет экспериментировать и под Windows, а затем можно немного отредактировав, перенести настройки в Linux, что я и сделал, так как не было уверенности в правильной работе драйверов под Linux. Модуль ядра, судя по коду, должен поддерживать VID=0x198F PID=0x0300, 0x0210, 0x0220, 0x15E, 0x015F, 0x0160. Под Lunix для своего модема VID и PID можно посмотреть командой lsusb, предварительно вставив его в USB. Скачиваем Sprint 4G Depelopment Pack, распаковываем его в любой каталог. В корне каталога Sprint4GDeveloperPack-1.6.1.2.2 (у вас может оказаться уже другая версия), находим там файл install.sh и немного его поправим. Если не хотите потом вводить путь к исходникам ядра, это можно сделать до запуска инсталлятора, отредактировав соответствующую строчку в файле install.sh KERNEL_SOURCES=${5:-/usr/src/linux}; На случай если в директории /usr/src/kernels/ будет несколько версий исходников ядра, уточнить текущую версия ядра можно командой uname -r или например так, в данном случае, версия ядра, будет подставляться автоматически: KERNEL_SOURCES=${5:-/usr/src/kernels/`uname -r`}; Ещё изменил параметр POWER_SAVE на Off, это на ваш вкус, работало в обоих случаях. POWER_SAVE_On_Off=${12:-On} Установка Запускаем install.sh На вопрос о лицензии нажимаем "y", далее если вы отредактировали install.sh жмём Enter до вопроса о корректности настроек, там надо нажать "y", после чего начнётся копирование файлов и сборка пакета. Ждём результата либо ошибок. У меня если и возникали ошибки, только из-за нехватки того или иного пакета. После ошибки опять запускаем, после стандартной процедуры вопросов появиться ещё один, тут выбираем "A" затем Enter. После сборки, нужно проверить загрузку и работу модуля, вставьте модем в USB разъём, затем выполните: modprobe drxvi314 Теперь посмотрим появился ли у нас ещё один интерфейс ifconfig -a Если не помните какие у вас были интерфейсы, выгрузите модуль и сравните вывод rmmod drxvi314 ifconfig -a Запомните имя интерфейса, он понадобиться в файле конфигурации. Конфигурация Если модуль ядра загружается и работает, его можно вставить в "автозагрузку" в конец файла /etc/rc.d/rc.local, если такого нет, создайте. Понадобиться сертификат из CCM, если не хотите выковыривать, можно скачать но с другим именем здесь. Благодаря этой ссылке и были подобраны правильные параметры для конфига. В CCM надо найти файл ca1.cer и конвертировать его командой openssl x509 -inform DER -in ca1.cer -outform PEM -out ca1.pem положите его куда хотите, например чтоб директория зря не пропадала в /etc/Sprint4G/ca1.pem Туда же положим и конфиг /etc/Sprint4G/wimaxd.conf # Частотный план, не уверен что стоит писать сюда лишнее, # иначе модем в автоматическом режиме может долбиться к другому провайдеру. BandwidthMHz 10 CenterFrequencyMHz 2540 2550 2560 AuthEnabled Yes EAPMethod 0 UserIdentity 'ваш_логин@wimax.comstar-uts.ru' UserPassword 'ваш_пароль' ValidateServerCert Yes CACertPath '/etc/Sprint4G/' CACertFileName '/etc/Sprint4G/ca1.pem' TTLSAnonymousIdentity '[email protected]' TLSDevicePrivateKeyPassword '' PrivateKeyPasswordFormat 'Ascii' AuthenticationTimeoutSec 10 InvertMSKByteOrder No AlwaysIncludeTLSLength No EAPFragmentMaxLength 1398 EAPPollingLoopIntervalMs 50 TLSDevicePrivateKeyPassword '' InnerNAIChange No NetworkSearchTimeoutSec 60 LPSearchInShutDownEnabled No NetworkEntryTimeoutSec 10 NEToHighestCINRBaseStation No BeceemEngineFileName '/usr/lib/libengine_beceem.so' AuthEthernetToRADIUS No # Автоподключение AutoReConnectEnabled Yes AutoReDisconnectEnabled No SkipNetSearch No AutoReConnectIntervalSec 1 AutoReDisconnectIntervalSec 20 LinkStatusRequestPeriodSec 2 # Скрипт выполняется после установки соединения IPRefreshCommand '/etc/Sprint4G/wimaxup.sh' # Можно заменить на такой вариант, естественно указав ваш интерфейс #IPRefreshCommand 'dhclient eth0' # Разрешает выполнять скрипт NetEntryIPRefreshEnabled Yes # Вроде должен убивать dhclient, у меня не работало TerminateDHCPClient No FirmwareFileName '/lib/firmware/macxvi350.bin' ConfigFileName '/lib/firmware/macxvi.cfg' # Управление логами #CSCMDebugLogLevel 4 CSCMDebugLogLevel 1 #AuthLogLevel 5 AuthLogLevel 1 AuthLogFileName '/tmp/CM_Auth.log' AuthLogFileMaxSizeMB 1 EngineLoggingEnabled Yes EngineLogFileMaxSizeMB 2 EngineLogFileName '/tmp/CM_Engine.log' Немного автоматизации не помешает, не забудьте заменить eth0 на свой интерфейс, который определили при тестировании модуля. /etc/Sprint4G/wimaxup.sh #!/bin/bash varif=eth0 res=`ifconfig $varif | grep -c "UP"` if [ ! "$res" == "0" ]; then ifdown $varif fi ifup $varif Проверка и использование Проверку лучше проводить в режиме полной отладки, для выявления ошибок CSCMDebugLogLevel 4 AuthLogLevel 5 Необходимо запустить демон в отладочном режиме и его клиент в разных консолях Демон (Сервер) wimaxd -D -c /etc/Sprint4G/wimaxd.conf консоль клиента, через неё будем управлять демоном (Сервером). wimaxc -i Набор возможных команд консоли можно узнать запросом help. В текущем конфиге, если есть сигнал, сразу начнётся попытка подключения, этого нам не надо, отредактируем секцию "Автоподключение". Так как автоподключение отключено, подключаться надо в ручном режиме: Сначала ищем базовые станции > search Если найдены несколько, подключаемся с наилучшим сигналом, или к единственной, например > connect 0 Для просмотра статуса соединения, нужно выполнять команды status, linkstats. Так команда status при установленном соединении содержит строчку "LINKUP ACHIEVED". IP адрес можно менять перезапрашивая, не разрывая соединение, и установка самого соединения не значит автоматического получения адреса, настройки маршрутов и др., этим должен заниматься dhclient. Для корректного выхода и выгрузки сервера надо сначала выключить модуль > shutdown Затем остановить и выгрузить сервер (демон) > server stop Если выгрузите сервер и не остановите работу модуля командой shutdown, соединение не будет разорвано и продолжит работать само по себе потребляя трафик. Для нормальной работы, отключим отладку в логах CSCMDebugLogLevel 1 AuthLogLevel 1 и запустим сервер в качестве демона wimaxd -c /etc/Sprint4G/wimaxd.conf Нормальных средств управления нет, хотя пишут что в сети гуляют какие-то скрипты. Но есть исходники клиента и сервера, при желании можно разобраться. Так сервер открывает порт 5200, если туда подключиться telnet-ом, можно увидеть текстовое приглашение, правда текстовые команды он от вас принимать не будет. Безопасность В отладочных логах сохраняются логин и пароль, поэтому не забывайте их удалять, а после экспериментов отключите отладочные логи. Не забывайте также что логин и пароль хранятся в открытом виде в файле конфигурации. Нюансы, Недостатки, Ошибки После обновления ядра, понадобиться пересобирать модуль. Модуль ядра иногда работает не стабильно, например на Fedora 14 приходиться его выгружать, вставлять устройство загружать или в ином порядке плясать с бубном, пару раз система зависала, хотя может проблема с железом. На версии Fedora 15, работает без замечаний. Если индикатор на модеме гаснет во время поиска сети, либо во время подключения, скорее всего ему не хватает питания, для исправления ситуации пришлось использовать USB-HUB с отдельным источником. Сам модем плохо ловит сеть в помещении, хотя раньше работал, видимо работа сети стала хуже, работает только у окна. Сервер (демон) иногда при завершении работы выдаёт ошибку и/или зависает, приходиться его "убивать". Иногда если не выгружен dhclient который запускал сервер (демон) для его интерфейса, то сервер (Beceem Connection Manager Server) может повторно не запуститься, ругаясь на занятый сокет, приходиться dhclient "убивать" вручную. После остановки сервера, остаётся "активным" интерфейс, его приходиться вручную деактивировать ifconfig eth0 down, хотя можно этого и не делать, если не мешает. Нет возможности или не нашёл, запуска скрипта при отключении, для деактивации интерфейса.   Настройка Intel Wireless WiFi Link 4965AGN во FreeBSD 8.0   Автор: Селин Павел  [комментарии]   Имеется ноутбук Toshiba Satellite A200 с беспроводной картой на чипсете Intel 4965AGN. Установлена ОС FreeBSD 8-STABLE и имеется огромное желание завести WiFi. Определяем наличие карты: pciconf -lv видим none@pci...... и подпись "Intel Wireless WiFi Link 4965AGN......." Определяем драйвер для используемого Wifi путем поиска в системных руководствах: man -k 4965AGN iwn(4) Читаем руководство по найденному драйверу: man iwn Видим что данный софт, как раз таки обслуживает устройство 4965AGN, и для его включения необходимо либо включить в loader.conf строку if_iwn_load="YES", либо пересобрать ядро с device iwn device iwnfw Поддержка необходимых для работы wifi-карты устройств wlan, pci и firmware уже включена в ядро GENERIC. Пересобираем ядро или правим /boot/loader.conf, перезагружаем систему и видим появление нового устройства iwn0. Находим в man rc.conf в разделе ifconfig строчку: "One or more wlan(4) device must be created for each wireless device as of FreeBSD 8.0" т.е. использовать iwn0 на прямую в ifconfig нельзя, а нужно создать отдельные wifi-интерфейсы (ifconfig wlan0 create wlandev iwn0). В /etc/rc.conf добавим: vaps_iwn0="wlan0" # если нужно использовать VAP (virtual access point) wlans_iwn0="wlan0" и после перезагрузки видим полноценно функционирующий интерфейс wlan0: ifconfig wlan0 up scan Для настройки соединения правим /etc/wpa_supplicant.conf (man wpa_supplicant.conf) network={ ssid="идентификатор сети" psk="ключ доступа" } и запускаем /etc/rc.d/wpa_supplicant start wlan0 dhclient wlan0 Если все работает, добавляем в /etc/rc.conf: ifconfig_wlan0="WPA DHCP"   Изменение порядка настройки беспроводного соединения во FreeBSD 8   Автор: mvalery  [комментарии]   В описании (http://www.freebsd.org/releases/8.0R/relnotes-detailed.html) релиза FreeBSD 8.0 сообщается об изменениях в организации поддержки беспроводных сетей. Дословно написано следующее: "Подсистема поддержки беспроводных сетей (net80211) в настоящий момент использует псевдо-интерфейс именуемый wlanN вместо использования напрямую имени драйвера - такого как em0." Это серьезное изменение, которое привело к тому, что у всех перешедших на FreeBSD 8.0, беспроводное соединение потеряло работоспособность. На эту проблему еще год назад указывалось в статье. Беспроводное соединение восстанавливается путем внесения минимальных изменений в конфигурационный файл /etc/rc.conf: Старый вариант (FreeBSD 7.2 и более ранние версии): ifconfig_ral0="DHCP ssid office1" Новый вариант (FreeBSD 8.0): wlans_ral0="wlan0" ifconfig_wlan0="DHCP ssid office1" То есть, если раньше все параметры моей WiFi карты Edimax EW-7128g были "привязаны" непосредственно к драйверу устройства ral0, то сейчас на базе драйвера устройства ral0 создается псевдо-интерфейс wlan0. В дальнейшем конфигурируется псевдо-интерфейс wlan0.   Решение проблем с WiFi в Ubuntu 9.10 (доп. ссылка 1)   Автор: Князь  [комментарии]   После обновления Ubuntu на ноутбуке (Dell Vostro A860) до версии 9.10 перестал работать Wifi при абсолютной тишине в логах. Модуль ath5k грузится без ошибки и правильно распознает чип от Atheros. А Network Manager скупо пишет "Устройство не готово". После продолжительного гугления выяснилось, что все дело в некорректной работе функциональной кнопки (Fn + F11), отвечающей за включение/отключение Wifi и Bluetooth: $ tail /sys/class/rfkill/*/{state,name,type,persistent} ==> /sys/class/rfkill/rfkill1/state <== 0 ==> /sys/class/rfkill/rfkill2/state <== 0 ==> /sys/class/rfkill/rfkill3/state <== 0 ==> /sys/class/rfkill/rfkill1/name <== phy0 ==> /sys/class/rfkill/rfkill2/name <== dell-wifi ==> /sys/class/rfkill/rfkill3/name <== dell-bluetooth ==> /sys/class/rfkill/rfkill1/type <== wlan ==> /sys/class/rfkill/rfkill2/type <== wlan ==> /sys/class/rfkill/rfkill3/type <== bluetooth ==> /sys/class/rfkill/rfkill1/persistent <== 0 ==> /sys/class/rfkill/rfkill2/persistent <== 0 ==> /sys/class/rfkill/rfkill3/persistent <== 0 Как видим, rfkill1 и rfkill2 имеют тип wlan. Состояние (state) у обоих равно 0, означающему SOFT LOCK. Кроме состояния 0 могут быть 1 и 2, UNLOCK и HARD LOCK соответственно. Вся проблема состоит в том, что при нажатии на упомянутую ранее функциональную кнопку состояние переключается только между значениями SOFT LOCK и HARD LOCK, минуя UNLOCK. Из-за этого блокируется переход интерфейса Wifi в активный режим, наглядно демонстрируемый командой $ sudo ifconfig wlan0 up SIOCSIFFLAGS: Unknown error 132 Решение состоит в принудительном переводе в состояние UNLOCK. Для этого пишем простой скрипт #!/bin/sh for i in /sys/class/rfkill/rfkill*/type; do type="`cat $i`" if [ "$type" = "wlan" ]; then n="`echo $i | sed -r 's%/type$%%'`"; echo 1 > ${n}/state; fi; done; Сохраняем скрипт в файл "/usr/local/sbin/unlock-wlan" и делаем его исполняемым $ sudo chmod +x /usr/local/sbin/unlock-wlan После ручного запуска скрипта надо перезапускать Network Manager - иначе он ничего не заметит. Теперь настраиваем Upstart для исполнения нашего скрипта при загрузке системы, перед стартом Network Manager. Для этого создаем файл "/etc/init/unlock-wlan.conf" # unlock-wlan - unlock wireless device # description "unlock wireless device" # Скрипт запускается перед настройкой сетевых интерфейсов start on starting networking task exec /usr/local/sbin/unlock-wlan   Настройка WiMAX соединения в Linux, с картой Intel PRO WiFi/WiMax 5150(5350)   Автор: pavlinux  [комментарии]   По причине не любви к торчащим изо всех щелей USB-свисткам, была выбрана PCI карта Intel 5150, или аналогичная ей, - 5350, полностью схожи, кроме количества подключаемых антен, в 5350 из 3 штуки, заявленая скорость в 450Мб/сек., и пр. вкусности. 1. Настройка ядра. Начиная с версии 2.6.26, драйвер поддерживающий сию карту находится в основной ветке ядра. а. Поддержка стека WiMax: Networking support --> <M> WiMAX Wireless Broadband support б. Для подержки карты на PCI шине, необходимо включить следующие: Device Drivers <M> MMC/SD/SDIO card support ---> Внтури раздела MMC ничего включать ненадо, кроме поддержки отладочной информации, если конечно Вам нужно. с. Выбор драйвера - PCI (он же SDIO) и/или USB: Device Drivers --> [*] Network device support ---> WiMAX Wireless Broadband devices ---> <M> Intel Wireless WiMAX Connection 2400 over USB (including 5x50) <M> Intel Wireless WiMAX Connection 2400 over SDIO (8) WiMAX i2400m debug level Для более раних версий ядер, но не ранее 2.6.23 драйвера находятся на сайте http://linuxwimax.org/Download Процесс компиляции и установки описан во включённых README. # make && make modules_install && make install && update-initramfs -u; 2. Установка Firmware. Необходимо скопировать последнюю версию firmware с вышеуказаного сайта. Поместить в каталог с остальными firmware, в основных дистрибутивах это каталог /lib/firmware/ Далее нужно переименовать скаченный файл в соответстующий типу вашего устройства: i2400-fw-usb-1.4.sbcf - для USB устройства или i2400-fw-sdio-1.4.sbcf - для PCIe карты. Проверить какую именно firmware требует установленый драйве, можно командой: # modinfo i2400m-usb || modinfo i2400m-sdio 3. Установка Порльзовательских приложений. 3.1 Intel WiMAX Tools. # cd /usr/src # git clone git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax-tools.git # cd wimax-tools/ # sh bootstrap # ./configure --build i386 \ --with-i2400m=/usr/src/linux \ --sysconfdir=/etc \ --localstatedir=/var; # make install; 3.2 Intel WiMAX Network Service. # wget "http://linuxwimax.org/Download?action=AttachFile&do=get&target=WiMAX-Network-Service-1.4.0.tar.bz2" # tar -xf WiMAX-Network-Service-1.4.0.tar.bz2 # cd WiMAX-Network-Service-1.4.0 # sh bootstrap # ./configure --build i386 \ --with-i2400m=/usr/src/linux \ --sysconfdir=/etc; # make install 3.3 WiMAX Binary Supplicant. # wget "http://linuxwimax.org/Download?action=AttachFile&do=get&target=Intel-WiMAX-Binary-Supplicant-1.4.0.tar.bz2" # tar -xf Intel-WiMAX-Binary-Supplicant-1.4.0 # cd Intel-WiMAX-Binary-Supplicant-1.4.0 # ./install_supplicant.sh install 4. Запуск WiMax демона. # rm /var/run/wimaxd.pid # /etc/init.d/wimax start 5. Соединение. # wimaxcu status # wimaxcu ron # wimaxcu scan # wimaxcu connect network 4 # dhclient wmx0 # wimaxcu status link # wimaxcu status connect 6. Подробное описание man wimaxcu. 7. Дополнительная информация. * http://linuxwimax.org/FAQ * http://ru.wikipedia.org/wiki/WiMAX * http://www.intel.com/network/connectivity/products/wireless/wimax/wifi/index.htm * http://www.yotatester.ru/obzor-podklyuchenie-i-test-skorosti-intel-wifiwimax-51505350-modemov/ * http://lists.linuxwimax.org/pipermail/wimax/   Установка PAN-соединения через bluetooth во FreeBSD 7.2   Автор: shurik  [комментарии]   Рассказ об организации выхода ноутбутка в сеть через комуникатор Toshiba Portege G810 с Windows Mobile 6.1 на борту, не позволяющий использовать его в качестве gprs-модема, но позволяющий организовать соединение с ПК через bluetooth PAN. В состав FreeBSD 7.2 был включен демон btpand с реализацией поддержки профилей Bluetooth Network Access Point (NAP), Group Ad-hoc Network (GN) и Personal Area Network User (PANU). Связывание комуникатора с ноутбуком через bluetooth я описывать не буду - это хорошо изложено в хендбуке (http://www.freebsd.org/doc/ru/books/handbook/network-bluetooth.html). Для использования btpand нам необходимо знать BD_ADDR не только коммуникатора, но и локального ПК. Узнать его можно так: # hccontrol Read_BD_ADDR BD_ADDR: 00:1a:6b:df:1b:c9 Для удобства добавим BD_ADDR комуниактора и ПК в /etc/bluetooth/hosts: 00:1a:6b:df:1b:c9 hp6710s 00:1b:24:a8:9c:76 g810 Далее все как описано в man 8 btpand: # ifconfig tap0 create # btpand -a g810 -d hp6710s -s NAP -i tap0 btpand[1986]: Searching for NAP service at 00:1b:24:a8:9c:76 btpand[1986]: Found PSM 15 for service NAP btpand[1986]: Opening connection to service 0x1116 at 00:1b:24:a8:9c:76 btpand[1986]: channel_open: (fd#4) btpand[1986]: Using interface tap0 with addr 00:00:6b:df:1b:c9 btpand[1986]: channel_open: (fd#5) # dhclient tap0 DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 5 DHCPOFFER from 192.168.0.1 DHCPREQUEST on tap0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.238 -- renewal in 129600 seconds. Все можем работать:)   Настройка спутникового интернета через Skystar3 в Ubuntu Linux (доп. ссылка 1)   Автор: Князь  [комментарии]   Описывается настройка спутникового интернета провайдера "Радуга Интернет" через OpenVPN. После установки спутниковой карты в свободный слот PCI и загрузки ОС создаем файл "/etc/modprobe.d/dvb_core.modprobe" options dvb_core dvb_shutdown_timeout=915360000 Этим мы препятствуем "засыпанию" карты. В новых ядрах, в отличие от старых, установка параметра "dvb_shutdown_timeout" в 0 не помогает и потому надо выставлять заведомо большое значение таймаута (в секундах). Перезагружаем компьютер. Устанавливаем требуемые утилиты $ sudo aptitude install dvb-utils Создаем файл /etc/channels.conf Raduga:11671:v:0:18200:0:0:0 Здесь: Raduga - название канала. Может быть любым. 11671 - частота v - поляризация. Может быть H - горизонтальная и V - вертикальная 0 - FEC: 0 - Авто, 3 - 3/4,... 18200 - Величина потока (Symbol rate) 0 - Видео PID 0 - Аудио PID 0 - Program id Пробуем залочиться на сигнал $ szap -c /etc/channels.conf -x -n 1 reading channels from file '/etc/channels.conf' zapping to 1 'Raduga': sat 0, frequency = 11671 MHz V, symbolrate 18200000, vpid = 0, apid = 0 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 07 | signal 9797 | snr 3270 | ber 0000ff00 | unc 00000000 | status 1f | signal 9696 | snr d344 | ber 00001800 | unc 00000000 | FE_HAS_LOCK Ключевые значения: "status 1f" и "FE_HAS_LOCK". Остальные поля указывают уровень сигнала, количество ошибок и т.п. Когда устойчивый сигнал будет получен, szap завершит свою работу. Теперь отключим rp_filter, фильтрующий пакеты которые не могут уйти через тот же интерфейс что и пришли. В нашем случае пакет приходит через один интерфейс, а уходит через другой $ sudo sh -c 'echo 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter' Создаем сетевой интерфейс спутниковой карты $ sudo dvbnet -p 1234 где "1234" - ваш PID. После выполнения команды должен появиться сетевой интерфейс "dvb0_0" (неактивный). Настраиваем интерфейс $ sudo ifconfig dvb0_0 hw ether YOUR-MAC-ADDRESS YOUR-IP-ADDRESS netmask 255.255.255.0 up где YOUR-MAC-ADDRESS и YOUR-IP-ADDRESS соответственно MAC-адрес и IP-адрес вашей подписки. Смотрим на наличие входящего трафика на интерфейсе dvb0_0 $ sudo dvbtraffic -PID--FREQ-----BANDWIDTH-BANDWIDTH- 0000 10 p/s 1 kb/s 15 kbit 0010 0 p/s 0 kb/s 1 kbit 0011 0 p/s 0 kb/s 1 kbit 0014 0 p/s 0 kb/s 1 kbit 0032 60 p/s 11 kb/s 90 kbit 003c 10 p/s 1 kb/s 15 kbit 003d 31 p/s 5 kb/s 47 kbit 0064 13 p/s 2 kb/s 20 kbit Если программа ничего не выводит, то проблемы могут быть в неправильных параметрах или "заснула" спутниковая карта. Правим конфигурационный файл /etc/network/interfaces и добавляем auto dvb0_0 iface dvb0_0 inet manual pre-up sh -c '/usr/bin/dvbnet -a 0 -p 1234 > /dev/null' up ifconfig $IFACE hw ether YOUR-MAC-ADDRESS YOUR-IP-ADDRESS netmask 255.255.255.0 up up sh -c 'echo 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter' up sh -c '/usr/bin/szap -c /etc/channels.conf -n 1 -x' down ifconfig $IFACE down down /usr/bin/dvbnet -d 0 Теперь приступим к установке и настройке openvpn Установим openvpn $ sudo aptitude install openvpn Скачаем из личного кабинета архив с ключами для openvpn. Из архива распакуем файлы ca.crt, client.ovpn, i0xxxxxx.csr, i0xxxxxx.crt, i0xxxxxx.key. Скопируем все эти файлы в директорию /etc/openvpn Сменим права доступа к файлу i0xxxxxx.key $ sudo chmod 0400 /etc/openvpn/i0xxxxxx.key Переименуем файл client.ovpn в raduga.conf и отредактируем его. В итоге должно получиться примерно такое содержание client dev tap # dev-node Raduga proto udp remote 80.81.208.66 55032 resolv-retry infinite nobind persist-key persist-tun ca /etc/openvpn/ca.crt cert /etc/openvpn/i0xxxxxx.crt key /etc/openvpn/i0xxxxxx.key ns-cert-type server verb 3 comp-lzo comp-noadapt auth-user-pass /etc/openvpn/password.txt route-up /etc/openvpn/tap0-route.sh Создаем файл /etc/openvpn/password.txt с именем и паролем подписки user password и делаем его доступным на чтение только владельцу $ sudo chmod 0400 /etc/openvpn/password.txt Создаем скрипт /etc/openvpn/tap0-route.sh, выполняемый после поднятия роутов. netstat -rn | \ sed '1,2d' | \ awk '{ \ if ($1 == "0.0.0.0" && $2 == "10.251.32.1" && $3 == "0.0.0.0" && $8 != "tap0") { \ EX=sprintf("/sbin/route del -net 0.0.0.0/0 gw %s dev %s && /sbin/route add -net 0.0.0.0/0 gw %s dev tap0\n", \ $2, $8, $2); system(EX); } }' В моем случае openvpn дефолтовый маршрут постоянно вешал на интерфейс dvb0_0 и пришлось прибегнуть к принудительной привязке скриптом роута к tap0. Делаем скрипт исполняемым $ sudo chmod +x /etc/openvpn/tap0-route.sh Редактируем файл /etc/default/openvpn и добавляем строку AUTOSTART="raduga" Пробуем соединиться к провайдеру из консоли $ sudo openvpn /etc/openvpn/raduga.conf Если успешно соединились с сервером, закрываем соединение нажатием "ctrl+c". Перезапускаем даемон $ sudo /etc/init.d/openvpn restart   Настройка беспроводного соединения в Linux с использованием LEAP, WPA или WPA2 (доп. ссылка 1) (доп. ссылка 2)   [комментарии]   Примеры настройки LEAP, WPA или WPA2 в Linux при помощи wpa_supplicant (http://hostap.epitest.fi/wpa_supplicant/) В Debian пакет wpasupplicant, также имеются пакеты с GUI интерфейсом - kwlan и wpagui. WPA --- Создаем файл конфигурации, например /etc/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 eapol_version=1 # ap_scan=2 was the one for me you may try 0 or 1 indstead of 2 ap_scan=2 fast_reauth=1 network={ ssid="SSID сети" proto=WPA key_mgmt=WPA-PSK pairwise=TKIP group=TKIP psk="пароль доступа" } WPA2-Personal ------------- Файл конфигурации: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 ap_scan=1 network={ ssid="SSID сети" proto=RSN key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk="пароль доступа" } LEAP ---- Файл конфигурации: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 eapol_version=1 ap_scan=1 fast_reauth=1 network={ scan_ssid=1 mode=0 ssid="SSID сети" proto=WPA key_mgmt=WPA-EAP pairwise=TKIP group=TKIP eap=LEAP priority=2 auth_alg=LEAP eapol_flags=0 identity="идентификатор пользователя" password="Пароль достутпа" } "SSID сети", "идентификатор пользователя" и "пароль достутпа" заменяем на полученные от администратора сети данными. Далее поднимаем wifi интерфейс (Intel Pro Wireless 3945ABG/BG): ifconfig wlan0 down iwconfig wlan0 essid "имя сети" ifconfig wlan0 up Запускаем wpa_supplicant: wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf -Dwext -dd Для драйвера ipw2200, интерфейс будет eth1: wpa_supplicant -d -c /etc/wpa_supplicant.conf -ieth1 -Dwext -dd Для madwifi - ath0: wpa_supplicant -d -c /etc/wpa_supplicant.conf -iath0 -Dmadwifi -dd Посмотреть состояние соедиения можно через wpa_cli или GUI интерфейс wpa_gui. Для получения IP адреса по DHCP нужно запустить DHCP-клиент: dhcpcd wlan0 Для настройки соединение двух машин в Ad-Hoc режиме можно использовать примерно такую комбинацию: modprobe ipw3945 iwconfig eth1 mode Ad-Hoc iwconfig eth1 essid "testnet" iwconfig eth1 key restricted iwconfig eth1 channel 1 ifconfig eth1 192.168.1.1 up iwconfig eth1 key s:12345 где, testnet имя сети, а 12345 пароль.   Настройка работы беспроводной карты на базе Broadcom BCM43xx в Ubuntu (доп. ссылка 1)   Автор: E@zyVG  [комментарии]   После установки Ubuntu 8.04 по умолчанию не работают беспроводные карты на базе чипов Broadcom BCM43xx из-за отсутствия firmware. Начиная с Linux ядра 2.6.24 работу данных карт в Linux обеспечивает драйвер b43, в более ранних версиях использовался драйвер bcm43xx. Для включения работы карты нужно установить пакет b43-fwcutter и получить firmware: sudo apt-get install b43-fwcutter и активировать на ноутбуке адаптер. Также можно воспользоваться меню Menu / System / Administration / Hardware Drivers. Драйвером b43 поддерживаются чипы: * bcm4303 (802.11b) * bcm4306 * bcm4309 (только 2.4GHz) * bcm4311 rev 1 / bcm4312 * bcm4311 rev 2 / bcm4312 (с 2.6.24 ядром работает через доп. патчи) * bcm4318 В настоящее время нет поддержки: * 802.11a для серий 4309 и 4312; * BCM 4328/4329 * не реализованы возможности представленные в проекте стандарта 802.11n; Сайт разработчиков драйвера: http://wireless.kernel.org/en/users/Drivers/b43   Обеспечение работы беспроводной карты в Ubuntu 7.10 через ndiswrappe (доп. ссылка 1)   Автор: silverghost  [комментарии]   1. Устанавливаем ndiswrapper: sudo apt-get install ndiswrapper-common ndiswrapper-utils-1.9 2. Распаковываем куда нибудь Windows драйверы и пишем из под пользователя root такие команды: ndiswrapper -i bcmwl5.inf modprobe ndiswrapper echo "blacklist bcm43xx" >> /etc/modprobe.d/blacklist echo "ndiswrapper" >> /etc/modules 3. Перегружаемся и проверяем. Все должно работать.   Настройка Linux как Wifi шлюза для КПК (доп. ссылка 1)   Автор: Михаил Конник  [комментарии]   Linux шлюз: Нужно создать простую одноранговую ad-hoc сеть и дать статический IP-адрес сетевому беспроводному интерфейсу. После этого делаем NAT и всё работает. Для беспроводного интерфейса eth3 и сети с идентификатором virens команда выглядит так (от рута): # iwconfig eth3 mode Ad-Hoc channel 1 essid virens В /etc/network/interfaces пишем что-то вроде: auto eth3 iface eth3 inet static address 10.106.146.1 netmask 255.255.255.0 wireless-mode ad-hoc wireless-channel 1 wireless-rate auto wireless-essid virens Теперь делаем NAT: # echo 1 > /proc/sys/net/ipv4/ip_forward # iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE При этом eth1 это интерфейс, который подключён к Интернету. Соединение не шифруется. КПК: Необходимо задать essid - такой же, какой дали в iwconfig. Шифрование отсутствует, тип сети - одноранговая ad-hoc. Снимаем галку "Получать IP-адрес автоматически" и вводим адреса: IP-адрес: 10.106.146.2 Маска подсети: 255.255.255.0 Маршрутизатор: 10.106.146.1   Подключение к беспроводной сети под Linux (доп. ссылка 1)   [комментарии]   0. Убеждаемся, что наш беспроводной адаптер в списке поддерживаемых в Linux (http://www.linux-wlan.org/docs/wlan_adapters.html.gz) на сайте http://www.linux-wlan.org/ 1. Подгружаем модуль ядра: insmod prism2_usb 2. Активируем wlan0 wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable 3. Устанавливаем SSID для используемой сети wlanctl-ng wlan0 lnxreq_autojoin ssid=stayoutofmynet authtype=opensystem 4. Выставляем атрибуты WEP wlanctl-ng wlan0 lnxreq_hostwep encrypt=true decrypt=true wlanctl-ng wlan0 dot11req_mibset mibattribute=dot11PrivacyInvoked=true 5. Используем WEP ключ wlanctl-ng wlan0 dot11req_mibset mibattribute=dot11WEPDefaultKeyID=3 wlanctl-ng wlan0 dot11req_mibset mibattribute=dot11WEPDefaultKey3=12:34:56:78:9A 6. Конфигурируем IP ifconfig wlan0 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255 route add default gw 192.168.1.11   Настройка беспроводной 80211 карты под FreeBSD (доп. ссылка 1)   Автор: toxa  [комментарии]   kldload bridge sysctl net.link.ether.bridge.enable="1" sysctl net.link.ether.bridge.config="wi0,fxp0" sysctl net.inet.ip.forwarding="1" ifconfig wi0 ssid toxawlan channel 11 media DS/11Mbps mediaopt hostap up stationname "toxawlan"   Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android (доп. ссылка 1) (доп. ссылка 2)   Автор: sfstudio  [комментарии]   С wpa_supplicant из GIT теперь можно настроить в Linux прозрачную миграцию, позволяющую переключиться на другую точку доступа без разрыва соединений приложений, в том числе продолжается вещание мультикастовоего IPTV, а выполнение iperf в большинстве случаев не умирает, а лишь деградирует по скорости в момент миграции. При этом даже корректно отрабатывает вариант с несколькими AP в разных поддиапазонах 5ГГц. Для настройки роуминга потребуется (на примере Mageia Linux 5): 1) wpa_supplicant из git. Можно взять подготовленный автором src.rpm wget http://wive-ng.sf.net/downloads/wpa_supplicant-2.6-1.mga5.src.rpm и собрать командой rpmbuild --rebuild wpa_supplicant-2.6-1.mga5.src.rpm 2) переключить его на использование nl80211 вместо wext, драйвер вашего wifi-модуля должен полностью поддерживать nl80211 (при использовании wext всегда будут долгие периоды реконнекта с потерей соединений пользовательских приложений) так как требуется, чтобы SME был на уровне wpa_supplicant. Большинство дистрибутивов по умолчанию использует WEXT, т.е. до сих пор далеко не все драйверы wifi, даже входящие в состав ядра, умеют nl80211 (iwlwifi точно умеют, ath*k тоже должны, в rt28xxx по факту даже сканирование не работает). Проверить, что используется на данный момент, можно, посмотрев, с какими опциями запущен supplicant ps ax | grep wpa_supplicant должен выдать что-то типа 25201 ? Ss 0:01 /usr/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D nl80211 -f /var/log/wpa_supplicant.log Для этого редактируем /etc/sysconfig/network-scripts/ifcfg-имя_интерфейса Важно установить: WIRELESS_WPA_DRIVER=nl80211 WIRELESS_WPA_REASSOCIATE=no MII_NOT_SUPPORTED=yes USERCTL=yes В /etc/wpa_supplicant.conf везде отключаем рандомизацию MAC. Включаем фоновое сканирование: bgscan="simple:30:-60:200" Т.е. при уровне ниже -60 будем начинать время от времени "щупать эфир" на предмет наличия кандидатов для миграции и по возможности мигрировать. Вместо фонового сканирования можно было бы использовать данные из RRM, но этой логики в wpa_supplicant пока нет. Также следует обратить внимание на используемый DHCP-клиент. Важно, чтобы он не сбрасывал адрес на интерфейсе (иначе сбросится состояние соединений приложений) по сигналу от ifplugd. Я использую штатный " "Internet Systems Consortium DHCP Client 4.3.3-P1". Ну и естественно, точки доступа и опорная сеть должны нормально отрабатывать ситуацию с перемещением клиентов. В прошивке Wive-NG для этого сделано абсолютно всё, что возможно. Больше ничего не требуется. Проверено на адаптерах Intel I3160/I7260. Выпинывать их принудительно не надо - оно само инициирует переход без всяких проблем. Под Windows эти карты ведут себя аналогично, т.е. без проблем мигрируют с сохранением пользовательских соединений, достаточно лишь в настройках драйвера увеличить агрессивность роуминга. Настройка миграции Android-устройств с беспроводными чипами от Atheros/Qualcomm. Достаточно давно atheros/qualcomm добавили в свои драйверы вполне внятную логику handover (миграции внутри плоской L2 сети, с точки зрения клиента, с множественными AP, на которых установлен один SSID). Собственно, тот самый роуминг, да ещё и бесшовный (ну если используемые AP не совсем плохи и умеют моментально передавать в опорную сеть критичные данные, например, ARP-ы для обновления ARP-таблиц на устройствах в сети + ещё ряд условий на тему кривости). Теперь о проблеме. Handover есть, сеть с нормальными AP есть, но чтобы клиент мигрировал, по-прежнему требуется пинок, иначе висит до последнего... Что делать и кто виноват? Для продолжения нужно само устройство, обязательно рутованное, обязательно использующее радио на чипе qualcomm (например yota phone 2). Перемонтируем разделы в RW, идём в /system/etc/wifi, видим там файл WCNSS_qcom_cfg.ini - собственно, это основной конфигурационный файл, читаемый драйвером wifi. Драйверы QCA сами реализуют слои SME/MLME, не экспортируя эти функции на плечи wpa_supplicant. И вся логика управления подключениями и миграцией возложена на них. Wpa_supplicant в Android собран с NO_ROAMING, а значит можно ожидать, что это сделано так же у всех абсолютно чипмэйкеров для Android (файлы конфигурации, естественно, разные, или же, как у Broadcom, интересующие нас параметры к исправлению задаются при компиляции, и изменить их на лету невозможно). Первая настройка, которая нас будет интересовать в файле конфигурации, это: # default value of this parameter is zero to enable dynamic threshold allocation # to set static roming threshold uncomment below parameter and set vaule gNeighborLookupThreshold=78 Эта настройка напрямую отвечает за то, когда клиент начнёт пытаться искать кандидата (форсирует сканирование, или запросит список ближайших AP по RRM и проведёт короткую процедуру скана для подтверждения). И значение у нас выставлено -78дБ... И вроде бы всё хорошо, но... Мы как обычно забыли, что то, что слышит клиент и то, что слышит AP, может отличаться по уровню на десятки дБ. Обычно в android-клиентах передатчик в 20МГц полосе может выдать 16дБм, в 40МГц в лучшем случае 14дБм. Тогда как со стороны AP обычно имеем как минимум 20дБм дури даже в 40МГц полосе (обычно определяется законодательными ограничениями конкретной страны, для РФ 20дБм в 2.4ГГц и 23дБм в 5ГГц независимо от ширины, хоть в 80МГц эти 23дБм, хоть в 20МГц). Из опыта, при таком раскладе в среднем перекос по уровням в прямой видимости уже в 10 метрах будет составлять около 10-15 Дб, а если есть преграды, то запросто перевалит и за 30 Дб. Но возьмём 10дБ для простоты. Т.е. когда клиент видит AP с уровнем в -78дБ, AP видит клиента уже с уровнем около -88дБ. Стоит говорить, что нормальной работы при таком раскладе уже не будет (особенно в 2.4ГГц в зашумленном эфире офиса)? TCP, требующий подтверждения доставки, просто встанет колом, голос начнёт квакать и т.д. Что бы этого избежать (плюс приземлить побольше клиентов, ведь для этого надо заставить всех работать на самой ближней AP, желательно с максимальными рэйтами и без повторов передачи), админ в сети наверняка на AP настроил handoff с уровнем эдак в -75дБ. Т.е. при -75дБ RSSI handoff со стороны AP застрелит такого клиента (при этом на клиенте уровень от AP будет аж -65дБ, т.е. далеко до заветных -78дБ, когда он решит подумать мигрировать). Т.е. будет link beat, сброс стэйтов и обрыв соединений на пользовательской стороне. Ещё пример - когда AP видит клиента с уровнем в -75дБ, клиент видит AP с уровнем -65дБ!! Или, когда на клиенте видим -78дБ, то со стороны AP клиент будет слышен лишь с уровнем -88дБ. Т.е. что бы обеспечить нормальный сервис, мы должны отстреливать клиента сильно раньше, чем он сам подумает мигрировать (имеется в виду, с вышеозначенными умолчаниями в драйвере). Или же нам придётся снижать мощность на AP что бы "уравнять" шансы, что в условиях грязного эфира может привести к катастрофическому падению SNR и как следствие бульканью, хрипам и прочему. А вот чтобы этого не происходило, достаточно выше обозначенную переменную поправить, выставив значение в диапазоне -65 ~ -70дБ. Побочный эффект - чуть упадёт скорость у клиента, так как чаще будет выполняться фоновые сканирования, плюс незначительно вырастет энергопотребление. Зато у него "будет повод" начать смотреть, кто есть вокруг, и попытаться мигрировать, не дожидаясь, пока его выпнет точка доступа. Следующий блок: # CCX Support and fast transition CcxEnabled=0 FastTransitionEnabled=1 CcxEnabled - это поддержка rrm ccx location-measurement, т.е. определения местоположения. Зачастую бесполезна и лишь будет расходовать аккумулятор. FastTransitionEnabled - поддержка 802.11R, однако в старых драйверах не полная, но хотя бы умеет учитывать MDIE при миграции (работает всегда, если переменная в значении 1). Заметим, что FT, а именно ускорение фазы аутентификации просто при взводе значения переменной в 1 работать не начнёт, так как требуется ещё пропатчить Supplicant и обвязку андроидную (как это делает, например, Samsung в своих топовых моделях). Однако, учёт MDIE - уже польза. Включаем. Не забываем также отключить 802.11d, иначе встретим много чудес в 5ГГц с DFS каналами. Пусть использование или не использование оных лежит на совести админа сети. # 802.11d support g11dSupportEnabled=0 Далее блок: # Legacy (non-CCX, non-802.11r) Fast Roaming Support # To enable, set FastRoamEnabled=1 # To disable, set FastRoamEnabled=0 FastRoamEnabled=1 Включает возможность миграции в любых сетях. Иначе, логика handover будет активироваться, только если клиент видит, что AP вещает поддержку 802.11R в IECAP. И/или используется WPA*-Enterprise. В новых драйверах, поставляемых в SDK для Android 6.0.1, добавлена ещё одна прекрасная опция: # Handoff Enable(1) Disable(0) gEnableHandoff=0 Эта опция (если выставить в 1) позволяет обрабатывать handoff с пинком со стороны AP как сигнал к миграции, т.е. банально не генерируется LinkBeat при kickout со стороны AP, а сразу выполняется попытка перескочить на следующую подходящую выбранную сканом AP, и только если не получилось сгенерировать Link Beat системе (т.е. о том, что его выпнули (kickout), знает только драйвер, и сразу пытается мигрировать, если не получается, то тогда уже сообщает системе, что всё, связи с этой сетью больше нет, надо выбрать другой SSID из тех, которые знает Android). Пользовательские соединения при этом останутся целыми (ну разве что iperf пострадает, но мессенджеры и голос останутся работать, правда в случае голоса будет квак). Это слегка нарушает "стандарт" 802.11, но в случае миграции очень полезная штука. После её включения, устройство прозрачно (с точки зрения запущенных приложений) сможет мигрировать даже в сетях, где весь роуминг построен исключительно на отстрелах клиента по уровню. А вот ещё одна крайне полезная настройка: #Check if the AP to which we are roaming is better than current AP in terms of RSSI. #Checking is disabled if set to Zero.Otherwise it will use this value as to how better #the RSSI of the new/roamable AP should be for roaming RoamRssiDiff=5 Дельта уровней между AP для выбора кандидата при миграции. Больше значение - меньше вероятность прилететь назад на ту же AP, но более отложенный старт миграции. Установленных по умолчанию 5дБ маловато. Нужно иметь дельту около 8-10дБ. Для начала выставим 8. RoamRssiDiff=8 Ещё интересная штука: #Beacon Early Termination (1 = enable the BET feature, 0 = disable) enableBeaconEarlyTermination=1 beaconEarlyTerminationWakeInterval=11 Эта опция откидывает все маяки, если в этих фрэймах не взведён бит TIM, а клиент спит. Т.е. во сне клиент не может вести пассивный сбор данных о соседних AP. Хорошо для аккумулятора - вероятно, плохо для миграции (надо глубже копать драйвер). gActiveMaxChannelTime=60 gActiveMinChannelTime=30 gActiveMaxChannelTimeConc=60 gActiveMinChannelTimeConc=30 Настройки времени прослушивания эфира при активном сканировании поканально, в мс. Больше значения - больше времени уйдёт на сканирование всего диапазона. Меньше время - быстрее просканируем, но можем половину не услышать. RRM включается так: # 802.11K support gRrmEnable=1 gRrmOperChanMax=8 gRrmNonOperChanMax=8 gRrmRandIntvl=100 Правда, я на доступных мне железках (в смысле, на тех, в которых было выключено и включил, на SGS A5 2017 запросы есть, но там и так всё с миграцией более-менее) так и не дождался ни одного запроса с использованием RRM от Yota Phone. Видимо, отключена поддержка при сборке драйвера. Это основное, что касается миграции. Да и ещё: # 1: Enable standby, 2: Enable Deep sleep, 3: Enable Mcast/Bcast Filter gEnableSuspend=3 По умолчанию обычно 0. В таком режиме клиент при переходе в режим сна (часто просто при выключении экрана) полностью тушит RF часть, временно просыпаясь только для того, чтобы AP его по таймауту не выпнула. При этом, реализация такова, что и роумингу зачастую становится плохо. Следует установить его в 3, т.е. фильтровать броадкасты и мультикасты во сне, и только. В файле конфигурации ещё много интересных параметов. Например, куча настроек для энергосбережения, если поотключать которые, миграция становиться более весёлой и точной, но батарея... Ну и на закуску: #Channel Bonding gChannelBondingMode24GHz=1 gChannelBondingMode5GHz=1 gShortGI20Mhz=1 gShortGI40Mhz=1 Поддержка широких каналов (>20МГц) + поддержка SGI. Зачастую для 2.4ГГц поддержка 40МГц отключена, т.е. gChannelBondingMode24GHz установлен в 0. Что, во-первых, не позволяет работать на максимальных рэйтах (150Мбит/с для 1T1R в 2.4ГГц при 40МГц, будет только 72). Увы, проблема в том, что видимо для первого соединения значение перекрывается откуда-то ещё, и даже выставив gChannelBondingMode24GHz=1, сразу мы 150Мбит/с не видит. Но после первой же миграции драйвер плюёт на всех и взлетает в 40МГц полосе. Также установка gChannelBondingMode24GHz решает проблему совместимости с некоторыми 2.4ГГц AP на Xiaomi и One+ (как обычно, намутили с анонсами в зависимости от региона, в итоге AP и клиент не могут договориться, в какой полосе разговаривать). Не забываем после правки сохранить, перемонтировать назад системный раздел в RO и перезагрузиться.

Ограничение трафика

Как заблокировать вход пользователей, работающих через сеть Tor   [комментарии]   Список точек выхода сети Tor, с которых инициируются исходящие соединения, можно загрузить на официальном сайте проекта Tor: https://check.torproject.org/cgi-bin/TorBulkExitList.py или используя неофициальные архивы: http://torstatus.info/ip_list_all.php/Tor_ip_list_ALL.csv https://www.dan.me.uk/torlist/ По указанным адресам выдаются списки IP-адресов, которые можно использовать для блокирования межсетевым экраном/HTTP-сервером или привязки метки через модуль geo_ip. Пример блокирования через ipfw: ipfw table 1 flush curl https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 | grep -v "^#" | while read cnt ip; do /sbin/ipfw table 1 add $ip 1 done ipfw add deny all from "table(1)" to any via em1 Для выставления флага через модуль ngx_http_geo_module в nginx: curl https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 | grep -v "^#" | sed 's/$/ tor;/' > /usr/local/etc/nginx/tor.conf в nginx.conf: geo $country { include /usr/local/etc/nginx/tor.conf } далее для блокировки можно добавить проверку: if ($country = 'tor') { ... }   Построение системы фильтрации контента по реестру Роскомнадзора на базе CISCO и FreeBSD (доп. ссылка 1)   Автор: Пережилин Юрий  [комментарии]   В статье подробно рассмотрен один из вариантов фильтрации трафика по реестру Роскомнадзора с помощью SQUID на базе FreeBSD, состыкованного с бекбоне CISCO по протоколу WCCP2. После долгих размышлений на тему фильтрации, производительности (если пустить в фильтр весь http-трафик, то фильтрация должна осуществляться на скоростях более гигабита в секунду), была выбрана следующая схема: Трафик HTTP и HTTPS, выходящий из облака нашей сети (в примере VLAN90) через наш бордер CISCO, мы будем сравнивать с ACL, содержащим IP-адреса, извлеченные из списка Роскомнадзора. В случае совпадения, мы отправляем трафик по протоколу WCCP (Web Cache Communication Protocol) на сервер(а) SQUID. Данная схема позволит нам избежать анализа всего трафика и анализировать только тот, который идет на заявленные IP, что не может не сказаться положительно на общей производительности системы. Из минусов данной связки следует, что допустим если внесенный в реестр ресурс с IP=3.3.3.3, доменом=bad.xxx и URL=http://www.bad.xxx/1.jpg переезжает на другой IP, то фильтр работать не будет. Но с другой стороны актуализация списков блокировки, это не наша проблема. Данный подход позволит нам с одной стороны не тратится на дорогостоящие системы анализа проходящего трафика, с другой стороны исключить "пионерский" подход блокировки всего ресурса по IP, а блокировать только указанный в реестре Роскомнадзора контент. Связку по WCCP лучше поднимать на приватных адресах, что бы не писать лишние ACL в SQUID . И так, приступим к реализации. Для начала нам надо вытащить электронную подпись с рутокена, полученного в роскомнадзоре. Для этого воспользуемся утилитой P12FromGostCSP, и экспортируем подпись в формате PKSC#12. Если экспорт удался, то можем перейти далее к построению системы. Если экспорт не удался (у меня в одном случае из четырех было именно так), то автоматическая загрузка реестра Роскомнадзора будет не доступна, и Вам придется файл качать и выкладывать реестр руками. Берем любой сервер на базе FreeBSD (я предпочитаю данную ОС, но ничего не мешает Вам сделать по образу и подобию на любой *NIX машине), на котором мы будем заниматься загрузкой базы Роскомнадзора, ее обработкой и у меня этот же сервер как правило обеспечивает анализ и фильтрацию контента. Так как системный OpenSSL в FreeBSD не поддерживает шифрование ГОСТ, ставим свежую версию из портов. Это не затрагивает работоспособность всей системы, и портовый OpenSSL прекрасно существует параллельно системному: # which openssl /usr/bin/openssl # openssl version OpenSSL 0.9.8y 5 Feb 2013 # /usr/local/bin/openssl version OpenSSL 1.0.1e 11 Feb 2013 # Находим файл /usr/local/openssl/openssl.cnf и пишем в конец файла: [openssl_def] engines = engine_section [engine_section] gost = gost_section [gost_section] default_algorithms = ALL engine_id = gost #dynamic_path = /usr/local/lib/engines/libgost.so CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet В начало этого файла пишем : openssl_conf = openssl_def Копируем на сервер наш сертификат в формате PKSC#12 и конвертируем его в формат PEM: /usr/local/bin/openssl pkcs12 -in p12.pfx -out cert.pem -nodes -clcerts Подготавливаем структуру директорий для работы наших скриптов и копируем туда сконвертированный сертификат: mkdir /var/db/zapret-info/ mkdir /var/db/zapret-info/cfg mkdir /var/db/zapret-info/arch cp cert.pem /var/db/zapret-info/cfg/ mkdir /tftpboot Создаем файл запрос в соответствии с требованиями Роскомнадзора (где данные между тэгами изменены на данные вашей фирмы): echo '<operatorName>ООО "РОГА И КОПЫТА"</<operatorName>' > /var/db/zapret-info/cfg/request.xml echo '<inn>00XXXXXXXXXX</inn>' >> /var/db/zapret-info/cfg/request.xml echo '<ogrn>XXXXXXXXXXXXX</ogrn>' >> /var/db/zapret-info/cfg/request.xml echo '<email>[email protected]</email>' >> /var/db/zapret-info/cfg/request.xml В зависимости от раскладок системной консоли полученный файл /var/db/zapret-info/cfg/request.xml необходимо сконвертировать в кодировку WINDOWS-1251. Скачиваем нижеприложенные скрипты. Скрипт download.pl был найден мной на просторах Интернета и упрощен, в оригинале он был чуток более замороченный. Задача данного скрипта - создать, подписать и отправить запрос в Роскомнадзор и загрузить реестр после отправки. #!/usr/bin/perl -w use strict; use SOAP::Lite; use MIME::Base64; use Sys::Syslog qw(:DEFAULT setlogsock); use POSIX qw(strftime); # XXX dirty!!! binmode STDOUT, ':utf8'; binmode STDERR, ':utf8'; my $BASE = "/var/db/zapret-info"; my %n; ($n{sec},$n{min},$n{hour},$n{mday},$n{mon},$n{year},$n{wday},$n{yday}, $n{isdst}) = localtime(time()); $n{year}+=1900; $n{mon}++; $n{mon}=~s/^(\\d)$/0$1/; $n{mday}=~s/^(\\d)$/0$1/; $n{hour}=~s/^(\\d)$/0$1/; $n{min}=~s/^(\\d)$/0$1/; $n{sec}=~s/^(\\d)$/0$1/; my $dt="$n{year}-$n{mon}-$n{mday}T$n{hour}:$n{min}:$n{sec}.000+04:00"; my $dd="$n{year}$n{mon}$n{mday}$n{hour}"; my $service = SOAP::Lite->service("http://www.zapret-info.gov.ru/services/OperatorRequest?wsdl"); my $reqfn = "$BASE/request-$dd.xml"; my $binfn = "$BASE/request-$dd.bin"; my $xmlreqfn = "$BASE/cfg/request.xml"; my $certfn = "$BASE/cfg/cert.pem"; my $request="" ; open (XML, "<$xmlreqfn"); while (<XML>) { $request .= $_; } close (XML); die "Resuest template not found in $xmlreqfn." if (length($request)==0); open (XMLREQ, ">$reqfn") or die "Can't create new request"; print XMLREQ "<?xml version=\\"1.0\\" encoding=\\"windows-1251\\"?>\\n"; print XMLREQ "<request>\\n\\t<requestTime>$dt</requestTime>\\n"; print XMLREQ $request; print XMLREQ "</request>"; close XMLREQ; system ("/usr/local/bin/openssl smime -sign -in $reqfn -out $binfn". " -signer $certfn -outform DER -nodetach"); open XMLREQ, "<$reqfn" or die "Can't open $reqfn"; my $xmlreq = do { local $/ = undef; <XMLREQ>; }; close XMLREQ; open XMLREQSIG, "<$binfn" or die "Can't open $binfn"; my $xmlreqsig = do { local $/ = undef; <XMLREQSIG>; }; close XMLREQSIG; my @sendresult = $service->sendRequest( $xmlreq, $xmlreqsig ); if ($sendresult[0] eq 'false') { mylog("error request $sendresult[1]"); } elsif ($sendresult[0] eq 'true') { open (CODESTRING, ">$BASE/codestring"); print CODESTRING $sendresult[2]; close CODESTRING; mylog("sent request $binfn: $sendresult[1]"); }; if (-e "$BASE/codestring") { open CODESTRING, "$BASE/codestring"; my $codestring = <CODESTRING>; close CODESTRING; my $cnt = 0; while(1) { my @getresult = $service->getResult($codestring); if ($getresult[0] eq 'false') { mylog ("$getresult[1]"); sleep 60; } elsif ($getresult[0] eq 'true') { my $outarch = decode_base64($getresult[1]); open (OUT, ">$BASE/out.zip"); print OUT $outarch; close OUT; unlink "$BASE/codestring"; if (-e "$BASE/out.zip") { system("/bin/mv $reqfn $BASE/arch/"); system("/bin/mv $binfn $BASE/arch/"); system("/bin/cp $BASE/out.zip $BASE/arch/out-$dt.zip"); system("/usr/bin/unzip -o $BASE/out.zip -d $BASE/dump"); unlink "$BASE/out.zip"; mylog ("Done. Everything seems to be ok."); exit 0; }; mylog("Shouldn't reach. DEBUG ME!!!"); exit 255; } else { mylog ("getresult is unknown"); exit 255; }; $cnt++; if ($cnt>30) { mylog ("too much tries, bailing out"); exit 255; } }; # notreached } else { mylog ("codestring file not found"); }; sub mylog { my $logstring = $_[0]; my($now_string); $now_string = strftime "%d-%m-%Y %H:%M:%S", localtime; print(STDERR $now_string." ".$logstring."\\n"); }; В задачи скрипта xml-paser.pl входит обработка полученного реестра и подготовка двух файлов - block.acl и denied.conf. Файл block.acl содержит правила для нашей cisco и как правило загружается по tftp. Файл denied.conf содержит URL для редиректора SQUID. Скрипт анализирует, префикс http или https указан в URL и в соотвествии с данным префиксом генерирует ACL для CISCO. Для ресурсов с множественныйми IP и/или URL, скрипт генерирует два ACL - как по порту www, так и по порту 443 (так как реестр сам по себе сырой, и такие записи не предусматривают однозначной трактовки какой протокол на каком IP использовать). #!/usr/bin/perl use XML::Simple; use Data::Dumper ; use Encode ; use URI::Escape; use Text::Iconv; $db_path='/var/db/zapret-info/' ; $tftp_root='/tftpboot' ; $query_ip='XXX.XXX.XXX.XXX' ; $simple=XML::Simple->new( KeepRoot=>1, RootName=>'reg:register' ); $xml=$simple->XMLin($db_path.'dump/dump.xml'); my %list = %{$xml->{'reg:register'}->{'content'}}; open(FURL, ">${db_path}denied.conf"); open(FACL, ">${tftp_root}/block.acl"); open(FTMP, ">/tmp/block.ip"); print(FACL "no ip access-list extended WCCP_REDIRECT\\n"); print(FACL "ip access-list extended WCCP_REDIRECT\\n"); print(FACL "deny tcp host ${query_ip} any\\n"); sub _url { eval { $url=shift; $url=~s/ //g; $url=uri_escape_utf8($url, "^A-Za-z0-9\\-\\._~:/\\?\\=\\&\\%"); print(FURL $url."\\n"); } } while ( my($key, $value) = each %list) { my $domain=$value->{'domain'} ; my $ip=$value->{'ip'} ; my $url=$value->{'url'} ; if(ref($ip) eq 'ARRAY'){ my @ip_list=@{$ip}; foreach $ip (@ip_list) { print(FTMP "$ip eq $port\\n"); print(FTMP "$ip eq 443\\n"); } } else { my $proto=substr($url, 0, 5) ; if ("\\L$proto" eq 'https') { $port = '443'; } else { $port = 'www'; } print(FTMP "$ip eq $port\\n"); } if(ref($url) eq 'ARRAY'){ my @url_list=@{$url}; foreach $url (@url_list) { _url($url); } } else { _url($url); } } close(FTMP); open(FTMP ,"sort -u /tmp/block.ip|"); while (<FTMP>) { $ip=$_; $ip=~s/ //g; print(FACL "permit tcp any host $ip \\n"); } close(FTMP); print(FACL "deny ip any any\\n"); print(FACL "!\\n"); print(FACL "end\\n"); close(FACL); close(FURL); open(SER ,"${db_path}/serial"); read(SER,$serial,6); close(SER); if (length($serial)==0) { $serial=0; } $serial+=1; open(SER ,">${db_path}/serial"); printf(SER "%06d",$serial); close(SER); exit 0; В начале данного файла надо установить значение переменных, в соответсвии с Вашими настройками. Переменная $tftp_root должна быть установлена в соответствии с настройками Вашего tftp-сервера, переменная $query_ip должна содержать IP-адрес интерфейса сервера, через который посылается в Интернет фильтрованный трафик, для исключения образования кольцевой обработки запросов. Для работы скриптов нам требуется установить следующие порты : cd /usr/ports/net/p5-SOAP-Lite; make install cd /usr/ports/converters/p5-MIME-Base64; make install cd /usr/ports/sysutils/p5-Sys-Syslog; make install cd /usr/ports/textproc/p5-XML-Simple; make install cd /usr/ports/devel/p5-Data-Dumper; make install cd /usr/ports/converters/p5-Encode; make install cd /usr/ports/net/p5-URI; make install cd /usr/ports/converters/p5-Text-Iconv; make install На данном этапе мы реализовали получение и разбор реестра Роскомнадзора в требуемый для нас вид. Переходим к настройке нашего железа. Конфигурируем CISCO для работы с сервером SQUID по WCCP. Группа 0 используется для отсылки http-трафика, группа 70 - для отсылки https-трафика. ip wccp 0 redirect-list WCCP_REDIRECT group-list 10 accelerated ip wccp 70 redirect-list WCCP_REDIRECT group-list 10 accelerated access-list 10 remark +++ WCCP_SQUID_PROXY +++ access-list 10 permit 1.1.2.2 Создаем пользователя, который будет грузить access-листы и настраиваем rsh. username blocker privilege 15 password password no ip rcmd domain-lookup ip rcmd rsh-enable ip rcmd remote-host blocker 1.1.2.2 root enable Ставим из портов SQUID. При выборе опций обязательно контролируем, что WCCP и WCCP2 протоколы включены. Создаем конфиг (в примере для версии 3.2) /usr/local/etc/squid/squid.conf http_port 1.1.2.2:9090 http_port 1.1.2.2:3128 transparent https_port 1.1.2.2:3129 transparent ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/usr/local/etc/squid/squid.pem always_direct allow all ssl_bump allow all sslproxy_cert_error allow all sslproxy_flags DONT_VERIFY_PEER sslcrtd_program /usr/local/libexec/squid/ssl_crtd -s /var/squid/ssl_db -M 4MB icp_port 0 hierarchy_stoplist cgi-bin ? acl QUERY urlpath_regex cgi-bin \\? cache deny QUERY acl apache rep_header Server ^Apache cache_mem 1 MB cache_swap_low 90 cache_swap_high 95 maximum_object_size 1 KB maximum_object_size_in_memory 50 KB cache_replacement_policy heap LFUDA cache_dir ufs /var/squid/cache 1 1 1 no-store logfile_rotate 7 dns_nameservers 8.8.8.8 8.8.4.4 hosts_file /etc/hosts refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320 quick_abort_min 0 KB quick_abort_max 0 KB half_closed_clients off acl purge method PURGE acl CONNECT method CONNECT acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 # https acl Safe_ports port 1025-65535 # unregistered ports http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access allow all http_reply_access allow all icp_access allow all cache_mgr [email protected] cache_effective_group proxy memory_pools off log_icp_queries off cachemgr_passwd q1w2e3r4 all client_db off buffered_logs on wccp2_router 1.1.2.1 wccp2_forwarding_method 2 wccp2_return_method 2 wccp2_assignment_method 2 wccp2_service dynamic 0 wccp2_service_info 0 protocol=tcp flags=dst_ip_hash,dst_port_hash priority=240 ports=80 wccp2_service dynamic 70 wccp2_service_info 70 protocol=tcp flags=dst_ip_hash,dst_port_hash priority=240 ports=443 wccp2_address 1.1.2.2 redirect_program /usr/local/etc/squid/redirector.pl url_rewrite_children 20 startup=10 idle=1 concurrency=0 Обратите внимание на строки wccp2_router и wccp2_address. Соответственно тут должны быть адреса на интерфейсе со стороны CISCO и SQUID. Трафик на сервер SQUID посылается путем замены MAC-адреса, без организации дополнительного GRE-тунеля. Скрипт редиректора копируется в /usr/local/etc/squid/: #!/usr/bin/perl use IO::Handle; use POSIX qw(strftime); use POSIX qw(setsid); my $db_path = "/var/db/zapret-info/"; my $block_url = "http://my.domain/block/"; my $log_file = "/var/log/squid/redirector.log"; $0 = 'redirect' ; $| = 1 ; my @banners ; my @X ; my $serial =0; sub _log { my $log_str = shift; my $now_str = strftime "%d-%m-%Y %H:%M:%S", localtime; printf(FLOG "[%s] %s\\n", $now_str, $log_str); } sub _rule_refresh { open(SER ,"${db_path}/serial"); read(SER,$num,6); close(SER); if (length($num)==0) { $num=0; } if ($num > $serial) { _log("Reading file ${db_path}/denied.conf serial ${num}"); open (IN_FILE, "${db_path}/denied.conf") || die $!; my @tmp_data = <IN_FILE>; chomp @tmp_data; @banners=(); push @banners, map { qr /\\Q$_\\E/ } grep { ! /^\\s*$/ } @tmp_data; close(IN_FILE); $serial=$num; } } $SIG{INT} = \\&_rule_refresh; open(FLOG, ">>${log_file}"); $| = 1 ; FLOG->autoflush(1); _log("Redirector started."); while (<>) { chomp ; @X = split ; ($url, $who, $ident, $method) = @X ; _rule_refresh ; $url = $block_url if grep ($url=~/$_/i, @banners) ; print "$url $who $ident $method\\n" ; } _log("Redirector exited."); close(FLOG); exit 0; В начале данного файла мы должны установить значение переменных $db_path, $block_url, $log_file в соответствии с Вашими настройками. $db_path содержит путь до директории с файлом denied.conf и serial, $block_url должен содержать адрес страницы на которую мы перекидываем клиента при блокировании ресурса. Что бы анализировать HTTPS-трафик, нам нужно сгенерировать самоподписанный сертификат: cd /usr/local/etc/squid/ openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squid.pem -out squid.pem Запускаем SQUID. Если все настроено верно, то на CISCO по команде sh ip wccp, мы увидим что-то похожее на такое: #sh ip wccp Global WCCP information: Router information: Router Identifier: 1.1.1.1 Protocol Version: 2.0 Service Identifier: 0 Number of Service Group Clients: 1 Number of Service Group Routers: 1 ... Redirect access-list: WCCP_REDIRECT ... Service Identifier: 70 Number of Service Group Clients: 1 Number of Service Group Routers: 1 ... Redirect access-list: WCCP_REDIRECT ... Если соединение WCCP2 установилось, мы может попробовать запустить трафик на SQUID. Для этого в ipfw мы должны поставить правила переадресации трафика : ipfw add 100 fwd 1.1.2.2,3128 tcp from not me to any dst-port 80 via ${wccp_intf} in ipfw add 100 fwd 1.1.2.2,3129 tcp from not me to any dst-port 443 via ${wccp_intf} in (где ${wccp_intf} - интерфейс для обмена wccp-трафиком) На CISCO запускаем трафик на SQUID : conf t int vlan90 ip wccp 0 redirect in ip wccp 70 redirect in Для загрузки acl в CISCO поднимаем tftp-сервер, раскомментировав соответствующую строку в /etc/inetd.conf и перезапустив inetd . Проверяем загрузку правил по rsh, выполнив из консоли сервера : ( sleep 2 ; echo '' ; sleep 15 ) | rsh -l blocker 1.1.2.1 copy tftp://1.1.2.2/block.acl running-config ; Проверяем в CISCO что правила загрузились. Если все отлично, создаем скрипт, который мы включаем в на выполнение в крон : #!/bin/sh . /var/db/zapret-info/cfg/loader.conf /scripts/download.pl if [ $? -eq 0 ]; then /scripts/xml-parser.pl else exit 254 ; fi if [ $? -eq 0 ]; then ( sleep 2 ; echo '' ; sleep 15 ) | rsh -l blocker ${cisco_address} copy tftp://${tftp_address}/block.acl running-config ; else exit 253 ; fi exit 0; Создадим файл конфигурации скрипта в /var/db/zapret-info/cfg/loader.conf echo 'cisco_address="1.1.2.1"' > /var/db/zapret-info/cfg/loader.conf echo 'tftp_address="1.1.2.2"' >> /var/db/zapret-into/cfg/loader.conf Если Вы все сделали без ошибок и поняли идею, Вы получили работающий полностью в автоматическом режиме сервер фильтрации трафика, синхронизированный с реестром Роскомнадзора, фильтрующий ВСЕ (!) ресурсы внесенные в реестр, в том числе URI написанные на русском языке и URI на защищенных SSL-ресурсах (для пользователя соединение отдаётся с использованием самоподписанного сертификата).   Маршрутизатор на базе FreeBSD с приоритизация трафика средствами PF и ALTQ   Автор: artemrts  [комментарии]   Проблема приоритизации трафика, на мой взгляд, весьма актуальна. Интернет-канала много не бывает и на всех пользователей и сервисов локальной зачастую не хватает. Поэтому для нормальной работы Интернета требуется грамотное распределения полосы с учетом потребностей каждого из участников. Единственный раз, когда мне не понадобился QoS - это гарантированный провайдером канал в 20 Мбит/с в мир и 100Мбит/с - национальный. Но такое удовольствие не из дешевых, поэтому зачастую народ довольствуется ADSL-каналом с заявленной скоростью к клиенту до 5-10 Мбит/с. Хочу заметить, что данная статья не предназначенная для новичков в сетевом администрировании в целом и в PF в частности. Читателю необходимо иметь минимальные навыки работы с сетями (понимать устройство пакета, знать что такое ТСР-флаги и т.д.), а также с пакетным фильтром PF. Не лишним будет прочесть официальный FAQ и man'ы. В основном цель этой статьи поделиться опытом, выслушать замечания и, возможно, улучшить свой вариант. И так, постановка задачи: организовать доступ к сети Интернет. Грамотно распределить как входящий так и исходящий трафик с разделением канала для клиентов локальной сети и сервисов, запущенных на самом роутере (например, FTP-сервер, SIP-сервер и т.д.). В качестве роутера выступает сервер с ОС FreeBSD 9 c пакетным фильром PF. Протокол FTP будет использоваться только в пассивном режиме, что немного упростит конфигурацию. Для решения поставленной задачи необходимо пересобрать ядро и включить в него поддержку PF и ALTQ. Для задач, не требующих ALTQ, пересобирать ядро не обязательно. Можно просто подгрузить PF как модуль. Добавляем в файл конфигурации следующие строки и пересобираем ядро. Описывать каждую опцию не буду. В man 4 altq все есть. options HZ=1000 device pf device pflog options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ #options ALTQ_NOPCC #for SMP CPU Лично я для боевого сервера пересобираю не только ядро системы, но и мир. Как это сделать, хорошо описано в Хендбуке и /usr/src/Makefile. Для автоматического запуска PF при старте системы добавляем в /etc/rc.conf строки: pf_enable="YES" pflog_enable="YES" Далее, собственно, сам конфигурационный файл пакетного фильтра. Возьмем самую простую реализацию роутера: один внутренний сетевой интерфейс и один внешний. Интернет канал подключен через ADSL-модем, работающий в режиме моста, т.е. подключение pppoe организовано средствами штатного ppp-клиента. Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c. На роутере запущен HTTP-прокси для прозрачного перенаправления WWW-трафика пользователей сети. Это сделано с целью блокировать метод CONNECT и принудительно направить другие виды трафика (например, торрент) в другие очереди с другим приоритетом. Я использую легковесный, но "шустрый" 3proxy (3proxy.ru). Кому важен кэш - используйте Squid или Apache Traffic Server. Также перенаправляются все ДНС-запросы на сервер ДНС-провайдера. Это сделано с целью блокировки фишинговых и других зловредных сайтов, сайтов для взрослых, аплоадеры, соц. сети и т.д. и т.п. Некоторые компании так же предоставляет блокировку рекламных баннеров. Весь исходящий трафик я разбил на следующие очереди: - ДНС-запросы - очередь u_dns - ТСР АСК-пакеты - очередь u_ack - трафик с высоким приоритетом - очередь u_hipri - трафик с нормальным приоритетом - очередь u_pri - трафик с низким приоритетом - очередь u_lowpri - весь остальной трафик - очередь u_other - стандартная очередь - очередь u_std, одна очередь должна быть с опцией default, в которую попадает трафик, который не попадает ни под какое другое правило. В нашем случае это показатель правильности назначения очередей в правилах фильтрации. В эту очередь ничего не должно попадать. Аналогичное деление трафика, идущего к клиенту локальной сети, только вместо u_* используется d_* обозначение. Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP. Данные, являющиеся ДНС-запросам и ТСР АСК-пакетами, для всех пользователей имеют свой высокий неизменный приоритет. Например, весь трафик от/к компьютера, относящегося к группе с низким приоритетом, будет обрабатываться с низким приоритетом, кроме ДНС и ТСР АСК. Определяем макросы, что бы меньше текста в основной части конфигурационного файла. mst="modulate state" str="source-track rule" ext_if="tun0" int_if="rl0" Таблица, в которую включены компьютеры трафик к/от которых весь будет считаться с высоким приоритетом. table <pc_hipri> persist {10.11.1.2} Аналогично для ПК с нормальным приоритетом. table <pc_pri> persist {10.13.1.2 10.13.1.10 10.13.1.13 10.13.1.14 10.13.1.15} Таблица с адресами, доступ к которым блокируется. table <ban> persist file "/etc/pf.ban" Таблица, с адресами клиентов, которым можно доверять. table <trust> persist {123.10.456.0/24 193.196.125.0/24} IP-адрес системного администратора. table <me> persist {210.211.13.84} IP-адреса SIP-провайдеров table <sip_peers> persist {212.15.65.122 75.16.127.118} Конфигурируем опции пакетного фильтра, изменяющие его поведение. В нашем случае: - не производится проверка на интерфейсе обратной петли; - выставляем оптимизацию правил в basic; - устанавливаем привязку состояний соединения (т.н. стейтов) к каждому интерфейсу; - устанавливаем максимальное кол-во состояний. Если сетевых интерфейсов большое кол-во или большое кол-во клиентов в сети, возможно, потребуется скорректировать это значение в большую сторону. set skip on lo0 set ruleset-optimization basic set state-policy if-bound set limit states 20000 Нормализация трафика (т.н. скрабинг). Срабинг позволяет значительно повысить безопасность файервола. В нашем случае выполняется нормализация трафика на внешнем интерфейсе, генерируется случайная последовательность в поле идентификации IP-пакета, устанавливается величина TTL=128, производится "дефрагментация" IP-пакетов, а также нормализация TCP соединений. scrub on $ext_if all random-id no-df min-ttl 128 fragment reassemble reassemble tcp ALTQ. Приоритизировать будем на всех физических сетевых интерфейсах. На внешнем - исходящий трафик, на внутреннем - входящий. Выбор дисциплины - очень важный момент. Возможные варианты: priq, cbq, hfsc. Я использую hfsc, т.к. важной чертой этого планировщика есть именно гарантирование полосы для конкретного пользователя/сервиса. Работа планировщика для нашего конкретного случая построена следующим образом: если в описании очереди указан дополнительный параметр realtime, то ей будет отдана указанная (realtime) полоса независимо ни от чего. Величина трафика свыше realtime будет рассчитываться исходя из величины bandwidth. Причем bandwidth - не абсолютный параметр, скорее относительный. Исходя из величин bandwidth каждой очереди рассчитывается величина трафика свыше realtime для каждой очереди пока не будет достигнут параметр upperlimit, который жестко ограничивает полосу. Приоритеты в планировщике hfsc не используются. Помимо всех прочих параметров, hfsc имеет параметр qlimit - кол-во слотов, доступных очереди для сохранения исходящих пакетов, когда вся доступная полоса исчерпана. И только когда все слоты будут заняты, пакеты будут отбрасываться, что заставит клиента снижать скорость. Мы не будем использовать RED или ECN, вместо этого увеличим значение qlimit. Назначаем очередь на внешнем интерфейсе. Величина bandwidth должна быть 96% от предоставляемой вышестоящим роутером. Здесь же перечисляем все дочерние очереди. altq on $ext_if hfsc bandwidth 800Kb queue {u_std,u_ack,u_dns,u_hipri,u_pri,u_lowpri,u_other} Очередь по-умолчанию. Будет потреблять 25 кбит/с независимо ни от чего. Величина bandwidth 1Kb означает, что если канал будет полностью занят любой другой очередью или всеми, то очередь u_std практически ничего не получит свыше 25 кбит/с. queue u_std bandwidth 1Kb qlimit 50 hfsc (default realtime 25Kb) Очередь u_ack - это ТСР АСК-пакеты, которые будут отправляться удаленному хосту с которого происходит загрузка по протоколу ТСР. Важно, что бы эти пакеты проходили без задержек. Для максимальной скорости от провайдеоа 4 Мбит/с требуется гарантированный канал в обратную сторону в размере 125 кбит/с. queue u_ack bandwidth 1Kb qlimit 200 hfsc (realtime 125Kb) ДНС-запросы. Гарантированной полосы в 25 кбит/с вполне достаточно. Больше не нужно, поэтому bandwidth 1Kb queue u_dns bandwidth 1Kb qlimit 50 hfsc (realtime 25Kb) Очередь с высоким приоритетом queue u_hipri bandwidth 300Kb qlimit 250 hfsc (realtime 200Kb) Очередь с обычным приоритетом queue u_pri bandwidth 300Kb qlimit 400 hfsc (realtime 150Kb) Очередь с низким приоритетом queue u_lowpri bandwidth 100Kb qlimit 100 hfsc (realtime 75Kb) Очередь для всего остального трафика ТСР и UDP. queue u_other bandwidth 97Kb qlimit 50 hfsc (realtime 25Kb) Назначаем очереди на внутреннем интерфейсе - приоритизируем входящий трафик. Провайдер отдает 5 Мбит/с, поэтому устанавливаем очередь inetq в размере 96%. Так же на внутреннем интерфейсе запущен ряд служб, например, локальный FTP, поэтому важно "не смешать" локальный трафик с Интернет-трафиком. Так как сетевая карточка 100Mbit, то выставляем значение bandwidth в 100Mb. Назначаем две очереди: одна - локальный трафик, вторая Интернет-трафик с дочерними очередями. altq on $int_if hfsc bandwidth 100Mb queue {etherq, inetq} Очередь для локального трафика. В эту очередь будут попадать все пакеты, идущие от внутреннего сетевого интерфейса к пользователям локальной сети. Параметр upperlimit определяет максимальное значения для данной очереди. Заметьте, в эту очередь не будут попадать ответы, например, от WWW-сервера из сети Интернет. Эта очередь исключительно для локального трафика. queue etherq bandwidth 95Mb hfsc (upperlimit 95Mb) Очередь для Интернет-трафика. В эту очередь будут попадать пакеты, идущие с сети Интернет. Имеет дочерние очереди по аналогии с внешним интерфейсом. queue inetq bandwidth 4800Kb hfsc (upperlimit 4800Kb) {d_std,d_ack,d_dns,d_hipri,d_pri,d_lowpri,d_other} queue d_std bandwidth 1Kb qlimit 50 hfsc (default realtime 25Kb) queue d_ack bandwidth 1Kb qlimit 50 hfsc (realtime 50Kb) queue d_dns bandwidth 1Kb qlimit 50 hfsc (realtime 25Kb) queue d_hipri bandwidth 1297Kb qlimit 500 hfsc (realtime 1000Kb) queue d_pri bandwidth 2000Kb qlimit 500 hfsc (realtime 2000Kb) queue d_lowpri bandwidth 1000Kb qlimit 500 hfsc (realtime 500Kb) queue d_other bandwidth 500Kb qlimit 500 hfsc (realtime 240Kb) Правила трансляции локальных адресов (NAT). Транслируются адреса, где источник - IP-адрес из любой подсети внутреннего интерфейса, а адрес назначения - любой, кроме IP-адресов из всех подсетей, подключенных к роутеру. Это могут быть как физические так и VPN-интерфейсы (tun, gif). ($ext_if) - в круглых скобках, т.к. IP-адрес внешнего интерфейса назначается динамически. ($int_if:network) и (self) в круглых скобках что бы в выводе pfctl -sn не было подстановки реальных адресов и сетей. Это удобно, когда у вас на внутреннем интерфейсе несколько алиасов и, соответственно, подсетей (как в моем случае). nat on $ext_if inet from ($int_if:network) to !(self) -> ($ext_if) port 1024:65535 Пользователей из группы pc_hipri и pc_pri пускаем в обход прокси. Я пускаю их напрямую, т.к. эти пользователи не нуждаются в контроле, а также специфическое ПО не работает в режиме прозрачного проксирования. no rdr on $int_if inet proto tcp from {<pc_hipri> <pc_pri>} to !(self) port 80 Правило редиректа, перенаправляющие все ДНС-запросы локальных пользователей на внешний ДНС-сервер. Это может быть Google или, лучше, ДНС-сервер компании, предоставляющей фильтрацию трафика посредством ДНС. rdr on $int_if inet proto {tcp udp} from ($int_if:network) to !(self) port 53 -> 193.58.251.251 port 53 Редирект на прокси-сервер. rdr on $int_if inet proto tcp from ($int_if:network) to !(self) port 80 -> 127.0.0.1 port 31280 Редирект на удаленный рабочий стол виндовой машины в локальной сети из сети Интернет. rdr on $ext_if inet proto tcp from any to ($ext_if) port 3389 -> 10.11.1.2 port 3389 Правила фильтрации трафика. Правила будем группировать в такой последовательности: действие, интерфейс, направление, протокол, адрес источника, порт источника, адрес назначения, порт назначения. Антиспуфинг. antispoof quick for {$int_if lo0} inet Блокируем не маршрутизируемые адреса. block in quick inet from no-route to any Блокируем броадкасты. block in quick on $ext_if inet from any to 255.255.255.255 Блокируем IP-адреса, содержащиеся в таблице ban. Опция return возвращает TCP RST, что закрывает сразу соединение без таймаута. Полезно, когда блокируются адреса рекламных сетей, что позволяет браузеру нормально загружать странички без ожидания загрузки блокируемого контента. block return out quick on $ext_if inet from any to <ban> Эти 2 правила определяют тип файервола: запрещено все, кроме явно разрешенного. block in all block out all Собственно разрешающие правила. Расположены в определенной последовательности, что важно с точки зрения производительности, а также ожидаемого эффекта. Внутренний интерфейс. Разрешаем ТСР-пакеты к интерфейсу обратной петли, на котором "слушает" прокси- сервер для организации прозрачного проксирования. Назначаем очереди. Мы не можем приоритизировать входящий трафик, только исходящий. В d_pri будут попадать пакеты, которые являются ответом от сервера к клиенту, таким образом мы регулируем скорость скачивания. pass in log quick on $int_if inet proto tcp from ($int_if:network) to 127.0.0.1 port 31280 queue (d_pri, d_ack) Далее 3 правила, которые разрешают ТСР соединения на определенные порты на не локальные IP-адреса. Назначаются соответствующие очереди. Тегирование необходимо что бы потом на внешнем интерфейсе мы могли "отделить" его от остального трафика и направить в нужную очередь. Заметьте, опция quick не используется, поэтому эти правила нужно расположить в правильной последовательности: от менее ограничивающего к более, потому как без опции quick последнее совпавшее правило выигрывает, а не первое совпавшее. Опция quick не используется т.к. при совпадении пакет будет назначен в очередь и пропущен и не дойдет до тех правил, которые описывают разрешения и приоритеты, основанные не на протоколах, а на адресах источника/назначения (в нашем случае это компьютеры из группы pc_hipri и pc_pri). Т.к. протокол ТСР, то так же добавляем очередь для ТСР АСК-пакетов. В качестве адреса назначения в правилах фигурирует !(self:network). Это значит, что только пакеты, не предназначенные ни к одному IP-адресу сетевых интерфейсов или IP-адресу из подсетей, подключенных к роутеру, будут разрешаться и, соответственно, тегироваться. Это, например, не даст подключиться к внешнему IP из локальной сети. pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ $mst queue (d_other d_ack) tag INET_OTHER pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port {20 21 25 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port 443 $mst queue (d_pri d_ack) tag INET_PRI Далее 2 правила, которые будут срабатывать как для всех пользователей так и для тех, кто принадлежит к т.н. VIP-группе (pc_hipri и pc_pri). Поэтому тут используем опцию quick. pass in log quick on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port {22 3389} $mst queue (d_hipri d_ack) tag INET_HIPRI pass in log quick on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port 53 $mst queue (d_dns d_ack) tag INET_DNS Следующие 2 правила, по-аналогии с TCP, описывают разрешения и очереди для протокола UDP. Так же их тегируем. Второе правило с опцией quick, т.к. оно должно срабатывать для всех категорий пользователей. pass in log on $int_if inet proto udp from ($int_if:network) to !(self:network) queue d_other tag INET_OTHER pass in log quick on $int_if inet proto udp from ($int_if:network) to !(self:network) \\ port {53 123} queue d_dns tag INET_DNS Правило, разрешающее ICMP. pass in log on $int_if inet proto icmp from ($int_if:network) to !(self:network) queue d_lowpri tag INET_LOWPRI Следующие правила, разрешающие трафик от клиентов, с высоким и нормальным приоритетом. Весь трафик будет считаться очень высоким (hipri) или высоким (pri) приоритетом (кроме ДНС и ТСР АСК). Здесь мы не указываем протокол, но указываем modulate state, который применяется только для ТСР. Это не будет ошибкой, PF достаточно "умный" и он подставит modulate state для протокола ТСР, и keep state - для всех остальных протоколов. pass in log quick on $int_if inet from <pc_hipri> to !(self:network) $mst queue (d_hipri, d_ack) tag INET_HIPRI pass in log quick on $int_if inet from <pc_pri> to !(self:network) $mst queue (d_pri, d_ack) tag INET_PRI Разрешаем локальный Ethernet к внутреннему интерфейсу роутера. pass in quick on $int_if inet from ($int_if:network) to ($int_if) queue etherq Теперь опишем разрешающие правила с внутреннего интерфейса роутера в локальную сеть. Если у вас нет редиректа с Интернета в локальную сеть или нет никаких серверов/клиентов, запущенных на самом роутере и требующих доступ в локальную сеть, то эти правила можно не добавлять. Первое правило разрешает трафик с Интернета к указанному IP в локальной сети и назначает очень высокий приоритет входящего трафика. Это третье правило (первое - rdr, второе - разрешающее на внешнем интерфейсе) для редиректа (проброса) порта в локальную сеть. pass out quick on $int_if inet proto tcp from !(self) to 10.11.1.2 port 3389 queue (d_hipri d_ack) Правило, разрешающее трафик от внутреннего сетевого интерфейса роутера в локальную сеть. Не важно какой протокол. Весь направляется в очередь etherq. pass out quick on $int_if inet from ($int_if) to ($int_if:network) queue etherq Внешний интерфейс. Разрешающие правила для входящего трафика. Важно, для каждого входящего правило указывать максимальное кол-во стейтов, которые может создать правило. Это предотвратит исчерпывания всего лимита стейтов одним правилом в случае DoS атаки. Последующие 6 правил разрешают входящие ТСР-подключения к определенным портам роутера, а также назначаются соответствующие очереди. Эти очереди будут приоритизировать не входящий трафик, а исходящий. Так же стоит обратить внимание на первые два правила, которые разрешают доступ к FTP серверу на роутере. Передача команд по 21-му порту будет направляться в очередь с большим приоритетом (u_pri), а данные - с меньшим (u_lowpri). pass in quick on $ext_if inet proto tcp from <trust> to ($ext_if) port 21 $mst (max 100) queue (u_pri u_ack) pass in quick on $ext_if inet proto tcp from <trust> to ($ext_if) port >=49152 $mst (max 100) queue (u_lowpri u_ack) pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 22 $mst (max 10) queue (u_hipri u_ack) pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 80 $mst (max 100) queue (u_pri u_ack) pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 5900 $mst (max 10) queue (u_hipri u_ack) Правило, разрешающее входящее подключение с сети Интернет (конкретно с адреса администратора), но не к интерфейсам роутера (внешнему в том числе), а к компьютеру в локальной сети к порту RDP. pass in quick on $ext_if inet proto tcp from <me> to !(self) port 3389 $mst (max 10) queue (u_hipri u_ack) Следующее правило разрешает подключение с любого адреса сети Интернет к VNC-репитеру. В целях безопасности включен трекинг источника (source-track). pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 5500 $mst \\ (max 10,$str, max-src-nodes 2, max-src-states 3, max-src-conn-rate 3/60) \\ queue (u_hipri u_ack) Следующие 2 правила разрешают подключения к определенным портам по протоколу UDP. pass in quick on $ext_if inet proto udp from any to ($ext_if) port 1194 (max 20) queue u_pri pass in quick on $ext_if inet proto udp from <sip_peers> to ($ext_if) port 5060 (max 20) queue u_hipri Разрешаем пинг к внешнему интерфейсу. pass in quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type echoreq (max 100) queue u_other Внешний интерфейс. Разрешающие правила для исходящего трафика. Следующие 5 правил разрешают исходящий трафик с внешнего интерфейса, который был помечен на внутреннем интерфейсе. Это исключительно данные, которые передаются в сеть Интернет от клиентов в локальной сети. pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_dns u_ack) tagged INET_DNS pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_hipri u_ack) tagged INET_HIPRI pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_pri u_ack) tagged INET_PRI pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_lowpri u_ack) tagged INET_LOWPRI pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_other u_ack) tagged INET_OTHER И последние правила, разрешающие исходящие соединения с внешнего интерфейса. Это будет трафик непосредственно самого роутера. В целом приоритет этого трафика выше чем от клиентов в локальной сети. pass out quick on $ext_if inet proto tcp from ($ext_if) to any port 53 $mst queue (u_dns u_ack) pass out quick on $ext_if inet proto tcp from ($ext_if) to any $mst queue (u_pri u_ack) pass out quick on $ext_if inet proto udp from ($ext_if) to any port {53 123} queue u_dns pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers> port 5060 queue u_hipri pass out quick on $ext_if inet proto udp from ($ext_if) to any queue u_pri pass out quick on $ext_if inet proto icmp from ($ext_if) to any $mst queue u_lowpri Есть один важный момент, на котором остановлюсь подробнее. Второе правило будет разрешать ТСР-соединения с роутера и в том числе на 80 порт. Под это правило так же подпадают пакеты, отправленные с прокси-сервера, трафик, который фактически является HTTP-трафиком клиентов из локальной сети. Т.к. в нашем случае приоритеты этих видов трафика равны (очередь u_pri), то все хорошо. Но если планируется назначить очереди разные (например, HTTP от локальных клиентов - очередь u_lowpri, а с внешнего интерфейса роутера - u_pri), тогда следует указать в правиле для прокси-сервера опцию user uid и поместить его над правилом для внешнего интерфейса роутера. Например, прокси запущен с правами пользователя nobody: pass out quick on $ext_if inet proto tcp from ($ext_if) to any user nobody $mst queue (u_lowpri u_ack) pass out quick on $ext_if inet proto tcp from ($ext_if) to any $mst queue (u_pri u_ack) Соответственно, правило, разрешающее доступ к прокси из локалной сети тоже немного измениться: необходимо поменять очередь с d_pri на d_lowpri. pass in log quick on $int_if inet proto tcp from ($int_if:network) to 127.0.0.1 port 31280 queue (d_lowpri, d_ack) Стоить отметить о наличии бага, который проявляется при использованием опции user. Об этом описано в секции BUGS на странице руководства pf.conf. Лично у меня этот баг не проявлялся. Все же старайтесь опцию user не использовать. Отладка. Отличительной способностью PF есть его протоколирование, статистика и мониторинг состояния в реальном времени что значительно облегчает конфигурирование файервола, особенно для сложных сетевых топологий. Просмотр загруженных очередей: pfctl -sq Что бы в реальном времени наблюдать загрузку очередей выполните команду: pfctl -vvsq Так же рекомендую установить из портов программу pftop, которая по аналогии с утилитой top выводит различную статистику PF в реальном времени.   Балансировка трафика в Linux (доп. ссылка 1)   Автор: mirage  [комментарии]   Данная схема отслеживает новые соединения и равномерно распределяет их по каналам. Допустим есть 4 канала в интернет: Linux Router ISP |ppp0 10.0.0.1|-----|10.0.0.2| |ppp1 10.0.0.3|-----|10.0.0.3| |ppp2 10.0.0.5|-----|10.0.0.4| |ppp3 10.0.0.7|-----|10.0.0.5| Добавляем в файл /etc/iproute2/rt_tables таблицы: 108 sat2 109 sat3 110 sat4 Настраиваем маршруты (раскидываем трафик по таблицам в зависимости от nfmark): ip rule add prio 50 fwmark 1 table sat2 ip rule add prio 51 fwmark 2 table sat3 ip rule add prio 52 fwmark 3 table sat4 ip route add default via 10.0.0.2 dev ppp0 ip rule add prio 210 from 10.0.0.3 table sat2 ip route add default via 10.0.0.4 dev ppp1 table sat2 ip rule add prio 211 from 10.0.0.5 table sat3 ip route add default via 10.0.0.6 dev ppp3 table sat3 ip rule add prio 212 from 10.0.0.7 table sat4 ip route add default via 10.0.0.8 dev ppp4 table sat4 Деление по таблицам осуществляется iptables: iptables -t mangle -N NEW_OUT_CONN # Выбираем новые сессии iptables -t mangle -A PREROUTING -s 10.0.0.0/16 -m state --state NEW,RELATED -j NEW_OUT_CONN # Восстанавливает значение nfmark из CONNMARK iptables -t mangle -A PREROUTING -s 10.0.0.0/16 -j CONNMARK --restore-mark iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 0 # Каждый четвертый пакет iptables -t mangle -A NEW_OUT_CONN -m statistic --mode nth --every 4 -j RETURN iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 1 # Каждый третий пакет iptables -t mangle -A NEW_OUT_CONN -m statistic --mode nth --every 3 -j RETURN iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 2 # Каждый второй пакет iptables -t mangle -A NEW_OUT_CONN -m statistic --mode nth --every 2 -j RETURN iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 3 Модуль CONNMARK отслеживает метки для всех пакетов сессии, это значит, что если пометить пакет в сессии, то все пакеты принадлежащие ей будут иметь эту же метку. --restore-mark копирует метку в метку пакета 'nfmark'. По которой пакет попадает в соответствующую таблицу, и подвергается маршрутизации. -m statistic --mode nth --every N соответствует каждому N-нному пакету.   Распределение трафика между двумя каналами во FreeBSD (доп. ссылка 1)   Автор: pehlle  [комментарии]   Во FreeBSD 7 появилась возможность задания множественных таблиц маршрутизаций. В ядре отвечает за это опция: options ROUTETABLES=[количество таблиц] Распределения трафика будет осуществляться средствами пакетного фильтра ipfw. Задаем маршруты по умолчанию: setfib 0 route add default 1.0.1.1 # таблица по умолчанию setfib 1 route add default 1.1.1.1 # новая таблица Файл конфигурации для запуска ipfw: cmd="/sbin/ipfw" $cmd add 10 check-state $cmd add 20 prob 0.5 setfib 0 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state $cmd add 30 setfib 1 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state $cmd add 40 allow all from any to any Таким образом мы задаем распределение трафика 50/50. Если каналы не равноценные то нужно выставить процентную весомость этих каналов. Трансляция адресов (NAT). Под эту задачу я выбрал ipnat, реализацию NAT от фаервола ipf. пример /etc/ipnat.rules: map vlan0 192.168.0.0/16 -> 1.0.1.1/32 map tun0 192.168.0.0/16 -> 1.1.1.1/32 Также можно выбрать демон natd или новый, работающий на уровне ядра, NAT, который появился во FreeBSD 7.   Скрипт для распределения пропускной способности средствами iproute2 в Linux (доп. ссылка 1)   Автор: Adam Palmer  [комментарии]   Скрипт опробован в Debian Etch с установленными пакетами tc, iproute2 и bc. Задача скрипта равномерное распределения пропускной способности канала среди пользователей и повышения приоритета dns, ssh, smtp. SOME_IMPORTANT_IP, SOME_OTHER_IMPORTANT_IP, IMPORTANT_IP - нужно заменить на IP важного сервера во внутренней сети. #!/bin/bash EXT_IFACE="eth0" INT_IFACE="eth1" TC="tc" UNITS="kbit" LINE="10000" # максимальная фактическая скорость внешнего (ext) линка LIMIT="5000" # максимально скорость, которую мы можем допустить # Переменные определеяющие скорость для индивидуальных классов трафика # для ограничения внутреннего трафика, проходящего через интерфейс eth0; CLS1_RATE="200" # гарантировано 200kbit CLS2_RATE="300" # гарантировано 300kbit CLS3_RATE="4500" # на всех 4500kbit (низкий приоритет) # Переменные определеяющие скорость для индивидуальных классов трафика # для ограничения трафика, проходящего через внешний интерфейс eth1; INT_CLS1_RATE="1000" #Priority INT_CLS2_RATE="4000" #Bulk # Чистим содержимое qdiscs ${TC} qdisc del dev ${INT_IFACE} root ${TC} qdisc del dev ${EXT_IFACE} root # Создаем корневые qdiscs, используя HTB, привязываем к интерфейсу и ставим метку "1:0" ${TC} qdisc add dev ${INT_IFACE} root handle 1:0 htb ${TC} qdisc add dev ${EXT_IFACE} root handle 1:0 htb # Создаем корневые классы и выставляем максимально-допустимый лимит скорости # eth1 ${TC} class add dev ${INT_IFACE} parent 1:0 classid 1:1 htb rate ${LIMIT}${UNITS} ceil ${LIMIT}${UNITS} # eth0 ${TC} class add dev ${EXT_IFACE} parent 1:0 classid 1:1 htb rate ${LIMIT}${UNITS} ceil ${LIMIT}${UNITS} # Создаем дочерние классы, маркируем их меткой "1:2", "1:3", в зависимости от лимита, для eth1 ${TC} class add dev ${INT_IFACE} parent 1:1 classid 1:2 htb rate ${INT_CLS1_RATE}${UNITS} ceil ${LIMIT}${UNITS} ${TC} class add dev ${INT_IFACE} parent 1:1 classid 1:3 htb rate ${INT_CLS2_RATE}${UNITS} ceil ${INT_CLS2_RATE}${UNITS} # Привязываем лимит для eth1 (для ограничения исходящего трафика) # Ставим для класса "1:2" гарантированную скорость 200kbit # с возможностью подъема при свободности канала до 5000kbit ${TC} class add dev ${EXT_IFACE} parent 1:1 classid 1:2 htb rate ${CLS1_RATE}${UNITS} ceil ${LIMIT}${UNITS} # Ставим для класса "1:3" гарантированную скорость 300kbit # с возможностью подъема при свободности канала до 4800kbit (5000kbit - 200kbit зарезервированный для 1:2) ${TC} class add dev ${EXT_IFACE} parent 1:1 classid 1:3 htb rate \ ${CLS2_RATE}${UNITS} ceil `echo ${LIMIT}-${CLS1_RATE}|bc`${UNITS} # Ставим для менее приоритетного класса "1:4" оставшуюся скорость 4500kbit (5000kbit - 200kbit - 300kbit) ${TC} class add dev ${EXT_IFACE} parent 1:1 classid 1:4 htb rate ${CLS3_RATE}${UNITS} \ ceil `echo ${LIMIT}-${CLS1_RATE}-${CLS2_RATE}|bc`${UNITS} # Добавляем pfifo. ${TC} qdisc add dev ${INT_IFACE} parent 1:2 handle 12: pfifo limit 10 ${TC} qdisc add dev ${INT_IFACE} parent 1:3 handle 13: pfifo limit 10 ${TC} qdisc add dev ${EXT_IFACE} parent 1:2 handle 12: pfifo limit 10 ${TC} qdisc add dev ${EXT_IFACE} parent 1:3 handle 13: pfifo limit 10 ${TC} qdisc add dev ${EXT_IFACE} parent 1:4 handle 14: pfifo limit 10 ### С классами закончили, создаем правила для адресов в сети # INT_IFACE, настраиваем скорость. # под dst подразумевается трафик уходящий во внутренний интерфейс eth0, т.е. к локальному IP # и определяем скорость загрузки с этих адресов. # адрес SOME_IMPORTANT_IP привязываем к классу 1:2 ${TC} filter add dev ${INT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip dst SOME_IMPORTANT_IP/32 flowid 1:2 ${TC} filter add dev ${INT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip dst SOME_OTHER_IMPORTANT_IP/32 flowid 1:2 # Все остальные адреса привязываем к классу 1:3 и считаем неприоритетными ${TC} filter add dev ${INT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip dst 0.0.0.0/0 flowid 1:3 # EXT_IFACE # Устанавливаем повышенный приоритет для DNS запросов ${TC} filter add dev ${EXT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip src IMPORTANT_IP/32 match ip sport 53 0xffff flowid 1:2 # SSH тоже считаем приоритетным ${TC} filter add dev ${EXT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip src IMPORTANT_IP/32 match ip sport 22 0xffff flowid 1:2 # SMTP отдаем остатки полосы, но приоритет по сравнению с остальным трафиком поднимаем ${TC} filter add dev ${EXT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip src IMPORTANT_IP/32 match ip sport 25 0xffff flowid 1:3 # Все остальное - в последнюю очередь, самый низкий приоритет ${TC} filter add dev ${EXT_IFACE} parent 1:0 protocol ip prio 1 u32 match ip src 0.0.0.0/0 flowid 1:4   IFB (аналог IMQ ) - основные команды для управления трафиком   Автор: Andrejs Spunitis  [комментарии]   Считается что IFB идеологически более правильная реализация псевдо-устройства, чем IMQ. IFB по умолчанию доступна в дистре Fedora Core 6. IMQ требует патчить ядро, по умолчанию не доступна. Насколько я понял идеологически IFB - это скорее для iproute2 IMQ - iptables Документация по IFB в исходниках iproute doc/actions/ или по адресу: http://linux-net.osdl.org/index.php?title=IFB Отличные картинки с местоположением IMQ: http://www.abclinuxu.cz/clanky/site/traffic-shaping-2-imq-a-uvod-do-shapingu # СБРОС ПРАВИЛ ----------------------------- tc qdisc del dev eth0 root tc qdisc del dev eth0 ingress tc qdisc del dev ifb0 root tc qdisc del dev ifb0 ingress modprobe ifb ip link set dev ifb0 up service iptables restart # ------------------------------------------ # IFB включение ---------------------------- modprobe ifb ip link set dev ifb0 up # ------------------------------------------ ## ПОЛЕЗНЫЕ КОМАНДЫ------------------------- tc -s filter show parent ffff: dev eth0 tc -s qdisc ifconfig ifb0 tc -s filter show dev ifb0 parent 1: tc -s qdisc show dev ifb0 ###################################################### # ПРИМЕР ограничения входящего трафика # маркировка IPTABLES недоступна ###################################################### ### IFB -------------------------------------------------------------- tc qdisc add dev ifb0 root handle 1: prio tc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 80kbit buffer 1600 limit 3000 tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 160kbit buffer 1600 limit 3000 ## выделили закачку исходников ядра ## wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz tc filter add dev ifb0 parent 1: protocol ip prio 1 u32 match ip src 204.152.191.37/32 flowid 1:1 ## выделили закачку исходников fedora core 6 ## wget ftp://ftp.muug.mb.ca/pub/fedora/linux/core/6/i386/iso/FC-6-i386-DVD.iso tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip src 130.179.31.46/32 flowid 1:2 ### eth0 -------------------------------------------------------------- # перенаправлять входящие пакеты с eth0 в ifb0 tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: protocol ip \ u32 match u32 0 0 action mirred egress redirect dev ifb0 ## TESTING ------------------------------------------------------------- оцените скорость и т.д. wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz ###################################################### # ПРИМЕР ограничения исходящего трафика # маркировка IPTABLES доступна но # filter работает на уровне iproute2 match ip dst ###################################################### Выполните СБРОС ПРАВИЛ и включите IFB (если выкл.) ### IFB -------------------------------------------------------------- tc qdisc add dev ifb0 root handle 1: prio tc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 80kbit buffer 1600 limit 3000 tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 160kbit buffer 1600 limit 3000 # закачка большого файла с хх.хх.хх.хх tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip dst хх.хх.хх.хх/32 flowid 1:2 ### eth0 -------------------------------------------------------------- # перенаправлять выходящие пакеты с eth0 в ifb0 tc qdisc add dev eth0 root handle 2: prio tc filter add dev eth0 parent 2: protocol ip \ u32 match u32 0 0 action mirred egress redirect dev ifb0 ## TESTING ------------------------------------------------------------- закачивайте большой файла на хх.хх.хх.хх оцените скорость и т.д. tc -s filter show parent ffff: dev eth0 tc -s qdisc ifconfig ifb0 tc -s filter show dev ifb0 parent 1: tc -s qdisc show dev ifb0 ###################################################### # ПРИМЕР ограничения исходящего трафика # маркировка IPTABLES доступна # filter работает на уровне маркировке пакетов в IPTABLES ###################################################### Выполните СБРОС ПРАВИЛ и включите IFB (если выкл.) ### IFB -------------------------------------------------------------- tc qdisc add dev ifb0 root handle 1: prio tc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 80kbit buffer 1600 limit 3000 tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 160kbit buffer 1600 limit 3000 tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:1 tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:2 ### eth0 -------------------------------------------------------------- # перенаправлять выходящие пакеты с eth0 в ifb0 tc qdisc add dev eth0 root handle 2: prio tc filter add dev eth0 parent 2: protocol ip \ u32 match u32 0 0 action mirred egress redirect dev ifb0 tc qdisc add dev eth0 root handle 2: prio tc filter add dev eth0 parent 2: protocol ip \ u32 match u32 0 0 action mirred egress redirect dev ifb0 # поставить в IPTABLES метку iptables -t mangle -A OUTPUT -p tcp -d 85.254.228.6/32 -j MARK --set-mark 10 ## TESTING ------------------------------------------------------------- закачивайте большой файла на хх.хх.хх.хх оцените скорость и т.д.   Расчет размера очереди для pipe с заданной пропускной способностью (доп. ссылка 1)   [комментарии]   > Работает шейпер на dummynet, наблюдается некотороая потеря > траффика. Hавскидку проблема в дефолтных значениях размера очереди (50 пакетов) > для pipe'ов от 32 до 512 Кбит\с. Скорее всего, поток не влезает в очередь и > часть пакетов отбрасывается. Как правильно рассчитать размер очереди для > каждого pipe в отдельности? Eugene Grosbein: Pipe и должен отбрасывать пакеты, иначе какой же это шейпер? Ты не можешь увеличивать длину очереди бесконечно, потому что задержки вырастут настолько, что соединение начнет рвать сам юзер :-) Hа таких низких скоростях размер очереди надо бы, наоборот, уменьшать, чтобы не допустить гигантских задержек типа нескольких тысяч милисекунд. А если хочешь и рыбку съесть, и потерь иметь минимум, то читай-ка ты про RED/GRED на unixfaq.ru и делай не просто pipe, а queue/pipe с gred. Рекомендую делать w_q=0.002, max_p=0.1, min=q/10, max=3*min, где q - длина очереди, q=20 для скоростей меньше 100Kbit/s, q=30 для скоростей от 100 до 300Kbit/s и q=50 для скоростей 512Kbit/s и выше. ---------- Sergey A Yakovets: Пол-дня игрался с параметром queue. В итоге подобрал на первый взгляд кое-что подходящее. Алгоритм\мысли были следующие: Дано: асинхронный спутниковый Инет. Входящий канал - 1024 Кбит\с. Опытным путем установлено, что проблемы с потерей траффика (до 10% от общего объема) возникают при многопотоковых http\ftp закачках, т.к. спутниковый провайдер в этом случае может отдать поток на все 1024 Кбит\с. При серфинге все нормально. Исходя из этого, мною были сделаны некоторые расчеты: При максимальной пропускной способности входящего спутникового канала в 1024 Кбит\с и размере пакета в 1500 байт, пропускная способность канала равна ~ 87 пакетов\сек. В это же время, для канала в 128 Кбит\с пропускная способность равна ~ 11 пакетов\сек. Гипотетическая разница, при условии что на юзера будет идти поток в 1024 Кбит\с, а отдаваться только 128 Кбит\с, может составить 76 пакетов\сек. Итого, опытным путем установлено: - (было) при дефолтной очереди в 50 пакетов на pipe 128 Кбит\с потери 10% - при размере очереди = разница*2 = 150 пакетов потери 2% - (стало) при размере очереди = разница*3 = 230 пакетов потери 0% Серфинг не страдает, задержек нет. Закачка идет на скорости шейпера, потерь нет. Пробовал другой вариант. Hа pipe 128 Кбит\с было выставлено gred 0.002/3/6/0.1 В итоге - огромные потери, т.к. канал практически все время работал на скорости пакетов намного больше чем max_th*2. Изменение параметров до gred 0.002/50/150/0.1 не влияло на результат, т.к. дефолтный размер очереди в 50 пакетов часто переполнялся и gred не имел никакого действия. --------- Что такое алгоритмы RED и gentle RED у ipfw? http://unixfaq.ru/index.pl?req=qs&id=310 Ответ на этот вопрос скомпилирован из статей в конференции RU.UNIX.BSD от следующих авторов: Valentin Ermolaev, Alexander V. Naumochkin, Jen Linkova. Сокращение RED означает "Random Early Detection". Метод используется для выравнивания всплесков трафика. Основным критерием метода является так называемая перегрузка. В качестве показателя перегрузки avg используется вычисляемое среднее значение длины очереди пакетов, принадлежащей к определенной сессии TCP. Использование усредненного, а не мгновенного значения очереди позволяет отделить кратковременные перегрузки, которые могут быть нормально обработаны устройством и сетью, от длительных перегрузок, которые могут утопить сеть. Алгоритмически это выглядит так: В момент прихода пакета ; ; if (очередь не пуста) ; ; ; ; avg = (1 - w_q)*avg + w_q*q ; ; else ; ; ; ; m = f(time - q_time) ; ; ; ; avg = (1 - w_q)^m * avg; где avg -средний размер очереди q_time - "start of queue idle time" q - размер очереди w_q - вес очереди (фиксированный параметр) f() - линейная функий от времени В /usr/src/sys/netinet/ip_dummynet.c по этому поводу написано следующее: * RED algorithm * * RED calculates the average queue size (avg) using a low-pass filter * with an exponential weighted (w_q) moving average: * avg <- (1-w_q) * avg + w_q * q_size * where q_size is the queue length (measured in bytes or * packets). * * If q_size == 0, we compute the idle time for the link, and set * avg = (1 - w_q)^(idle/s) * where s is the time needed for transmitting a medium-sized packet. - что полностью согласуется с приведенными выше формулами. Далее в алгоритме вводятся два порога уровня перегрузки: min_th и max_th. Когда уровень перегрузки ниже первого порога min_th, то пакеты не отбрасываются. Если уровень перегрузки находится между двумя порогами, пакеты отбрасываются с линейно возврастающей вероятностью из диапазона от 0 до конфигурируемой величины max_p, которая достигается при достижении второго порога max_th. Выше порога max_th отбрасываются все пакеты. Такой метод вычисления позволяет сглаживать всплески трафика - для сравнения в первой из статей (см. ниже) на одном графике приводятся и изменение размера очереди q, и усредненного размера очереди (avg) от времени. В той же статье есть выкладки на тему значений w_q. При gentle RED ситуация выглядит чуть сложнее: Если перегрузки лежит в интервале от min_th до max_th, то пакеты отбрасываются с линейно возрастающей от 0 до max_p вероятностью. Когда перегрузка превышает max_th, но не превышет 2*max_th, пакеты отбрасываются не все (как в случае RED), а с линейно возрастающей от max_p до 1 вероятностью. Все пакеты отбрасываются только после превышения перегрузки канала значения 2*max_th. Вот как это сделано в ip_dummynet.c: если длина очереди > max_th, то в случае gred вероятность отбрасывания пакета вычисляется как ; ; p_b = c_3 * avg - c_4 где c_3 = (1 - max_p) / max_th ; ; c_4 = 1 - 2 * max_p В случае просто RED пакет отбрасывается. При загрузке очереди, большей min_th, но меньшей max_th, функция вероятности одинакова и выглядит след. образом: ; ; p_b = c_1 *avg - c_2 где c_1 = max_p / (max_th - min_th), ; ; c_2 = max_p * min_th / (max_th - min_th) Полезные ссылки: 1. http://www.icir.org/floyd/papers/red/red.html 2. http://www.icir.org/floyd/red.html 3. http://www.cisco.com/warp/public/732/Tech/red/   Ограничение входящей и исходящей скорости (shaping) для клиентов на ppp интерфейсах.   Автор: Tangar aka Андрей Орлов  [комментарии]   Ограничение входящей и исходящей скорости (shaping) для клиентов на ppp интерфейсах. #!/bin/bash DEVICE=ppp9 UP=512 DOWN=512 /sbin/tc qdisc del dev $DEVICE root /sbin/tc qdisc add dev $DEVICE root tbf rate ${DOWN}Kbit latency 50ms burst $[$DOWN*1024] /sbin/tc qdisc del dev $DEVICE handle ffff: ingress /sbin/tc qdisc add dev $DEVICE handle ffff: ingress /sbin/tc filter add dev $DEVICE parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 \ police rate ${UP}Kbit burst $[$DOWN*1024] drop flowid :1   Ограничение трафика через iptables (доп. ссылка 1)   Автор: Николай Малых  [комментарии]   ipt_limit - общее ограничение по срабатываний правила -m limit --limit {avg}/[second|minute|hour|day] --limit-burst {burst} iplimit - ограничение соединений для одного IP. Ограничение коннектов к 80 порту от одного IP: iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-above 4 -j REJECT Тоже, но для запросов с одной /24 подсети: iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-mask 8 --iplimit-above 4 -j REJECT hashlimit - для каждого IP в хэше хранятся параметры соединений; -m hashlimit --hashlimit {avg} --hashlimit-burst {burst} --hashlimit-mode {режим: dstip, dstport, srcip, srcport} \ --hashlimit-name {name} --hashlimit-htable-max {num} --hashlimit-htable-expire {num} --hashlimit-htable-gcinterval {num} iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m hashlimit --hashlimit 1/hour \ --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name SSH --hashlimit-htable-expire 360000 -j ACCEPT tbf (http://www.nmalykh.org/work/tbf.tar.gz) - продолжение развития limit и hashlimit c поддержкой возможности инверсии правил в целом. iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m tbf ! -- tbf 1/s --tbf-burst --tbf-mode srcip --tbf-name SMTP -j DROP   Как ограничить пропускную полосу для пакетов помеченных меткой через MARK.   Автор: Denis Fedorishenko (NuclearCat)  [комментарии]   Сделать MARK, и загнать все такие трансферы в какой-либо класс шейпера. Т.е. если например помеченные пакеты - все их отнести к классу 1:51 где скорость ограничена от 32К до 64К: tc filter add dev eth1 parent 1:0 protocol ip prio 100 handle 51 fw classid 1:51 tc class add dev eth1 parent 1:2 classid 1:51 htb rate 32Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:51 handle 51 sfq perturb 10   Ограничения трафика с помощью iproute2 (доп. ссылка 1)   Автор: Z0termaNN  [комментарии]   tc qdisc add dev eth1 root handle 1: htb default 2 r2q 1 tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit mtu 1500 tc class add dev eth1 parent 1:1 classid 1:77 htb rate 32kbit ceil 48kbit mtu 1500 prio 0 tc class add dev eth1 parent 1:1 classid 1:2 htb rate 128kbit ceil 128kbit mtu 1500 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dport 25 flowid 1:77   Пример ограничения полосы пропускания трафика в FreeBSD   [комментарии]   Собираем ядро с опциями: options DUMMYNET options IPFIREWALL Ограничиваем трафик для сеток 1.1.1.0/24 и 3.3.3.0/24 на 14000 кбит/с: ipfw add pipe 50 tcp from any to 1.1.1.0/24 via fxp0 ipfw add pipe 50 tcp from any to 3.3.3.0/24 via fxp0 ipfw pipe 50 config bw 14Kbit/s Для внесения задержки на N ms, используйте delay N после config. Для установки веса данного пайпа по отношению к другим пайпам используйте weight вес. Для WF2Q ограничения трафика используйте ipfw queue (queue N config [pipe pipe_nr] [weight weight] [queue {slots | size}) PS (комментарий от [email protected]): Если возникает необходимость организовать "канал" для каждого пользователя из данной сети то пишем: ipfw pipe 10 config mask dst-ip 0x000000ff bw 1024bit/s queue ipfw add pipe 10 tcp from any to 1.1.1.0/24 via fxp0 Теперь каждый хост из сети 1.1.1.0/24 имеет свой канал 1024bit/s   Как запретить открывать более 30 соединений с одного IP   [комментарии]   Запретим более 30 коннектов для 80 порта сервера 1.2.3.4. ipfw add allow tcp from any to 1.2.3.4 80 limit src-addr 30 ipfw add allow tcp from any to 1.2.3.4 80 via fxp0 setup limit src-addr 10 Вместо src-addr можно использовать src-port, dst-addr, dst-port Конструкция работает в последних версиях FreeBSD 4.x ветки.   Ограничение трафика через iptables (доп. ссылка 1)   Автор: Z0termaNN  [комментарии]   iptables --new-chain car iptables --insert OUTPUT 1 -p tcp --destination-port 25 -o eth1 --jump car iptables --append car -m limit --limit 20/sec --jump RETURN iptables --append car --jump DROP

Пакетные фильтры и фаерволы

Пакетные фильтры в Linux: iptables, ipchains

Пакетный фильтр в FreeBSD: ipfw, IP-Filter

Как заблокировать вход пользователей, работающих через сеть Tor   [комментарии]   Список точек выхода сети Tor, с которых инициируются исходящие соединения, можно загрузить на официальном сайте проекта Tor: https://check.torproject.org/cgi-bin/TorBulkExitList.py или используя неофициальные архивы: http://torstatus.info/ip_list_all.php/Tor_ip_list_ALL.csv https://www.dan.me.uk/torlist/ По указанным адресам выдаются списки IP-адресов, которые можно использовать для блокирования межсетевым экраном/HTTP-сервером или привязки метки через модуль geo_ip. Пример блокирования через ipfw: ipfw table 1 flush curl https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 | grep -v "^#" | while read cnt ip; do /sbin/ipfw table 1 add $ip 1 done ipfw add deny all from "table(1)" to any via em1 Для выставления флага через модуль ngx_http_geo_module в nginx: curl https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 | grep -v "^#" | sed 's/$/ tor;/' > /usr/local/etc/nginx/tor.conf в nginx.conf: geo $country { include /usr/local/etc/nginx/tor.conf } далее для блокировки можно добавить проверку: if ($country = 'tor') { ... }   Решение проблемы с uTP-протоколом uTorrent (доп. ссылка 1)   Автор: Zzz  [комментарии]   По многочисленным наблюдениям системных администраторов различных компаний предоставляющих доступ к сети интернет, с начала февраля 2010 года наблюдается ежедневный лавинообразный рост количества пакетов в сети, их фрагментация, а также существенный рост исходящего трафика. Данная проблема связана с новой версией торрент-клиента uTorrent вышедшего 3 февраля 2010 года с поддержкой протокола uTP, работающего поверх UDP. Призванный снизить нагрузку на провайдеров протокол uTP в результате привел к обратному эффекту. Для относительно безболезненной для клиента фильтрации uTP на шлюзе под управлением Linux рекомендуется использовать следующее правило: /sbin/iptables -I FORWARD -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp \ --from 40 --to 44 -m statictic --mode random --probability 0.90 -j DROP Мониторинг работы правила: iptables -L FORWARD -nv | grep statist Для FreeBSD правило будет выглядеть следующим образом: ngctl mkpeer ipfw: bpf 2 main ngctl name ipfw:2 utp_filter ngctl msg utp_filter: setprogram { thisHook=\"main\" ifMatch=\"\" ifNotMatch=\"main\" bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] } ipfw add 2 netgraph 2 udp from any to any iplen 0-128 Мониторинг: ngctl msg utp_filter: getstats \"main\"   Ускорение анализатора сетевого трафика Snort при помощи библиотеки Hyperscan (доп. ссылка 1)   Автор: Владимир Кунщиков  [комментарии]   Осенью прошлого года компания Intel открыла исходные тексты библиотеки поиска совпадений для регулярных выражений Hyperscan, обеспечивающей ускорение DPI-приложений за счёт использования SIMD compiler intrinsics. Использование новых наборов инструкций позволяет добиться значительного прироста производительности в самом узком месте анализаторов трафика: в поиске совпадений по образцу. Snort - самое известное DPI-приложение с открытым кодом - получил поддержку Hyperscan только в начале этого лета. Представленный патч предназначен для версии Snort 2.9.8.2 но без проблем накладывается на 2.9.8.3 и может быть портирован и на предыдущие релизы. Сборка Для сборки Hyperscan сборочное окружение должно содержать Boost и компилятор ragel. В библиотеке используется система сборки cmake. Сложности, если можно их назвать сложностями, вызывает только Boost: данной версии всё ещё нет в большинстве дистрибутивов на момент июня 2016, поэтому скорее всего придётся собираться локально. Собрать буст несложно и весь процесс не очень длителен. Что касается ragel и cmake, то они уже имеются в пакетных репозитариях Gentoo, Ubuntu, CentOS в достаточно свежих версиях. Boost Ragel Hyperscan Snort Boost Нужен Boost выше 1.57. В наиболее ожидаемом случае, если версия буста в используемом дистрибутиве ниже, то надо будет установить более свежую копию. Для этого надо скачать актуальную версию и установить её локально. tar xf ~/tmp/boost_1_61_0.tar.bz2 cd boost_1_61_0 ./bootstrap.sh -prefix=$HOME/opt/boost/ ./b2 --ignore-site-config install --ignore-site-config требуется для устранения потенциальных конфликтов с системной версией Boost: игнорирование текущих настроек при сборке локальной версии буста в домашней директории пользователя. Ragel Далее нужен ragel, этот компилятор доступен в стандартных репозитариях всех распространённых дистрибутивов. Поэтому инсталляция проста: emerge ragel или же apt-get install ragel, yum install ragel итп итд HyperScan Сборка библиотеки стандартна для проектов использующих cmake: tar xf ~/tmp/hyperscan-4.2.0.tar.gz cd hyperscan-4.2.0/ mkdir build cd build cmake .. -DBOOST_ROOT=$HOME/opt/boost/ -DCMAKE_INSTALL_PREFIX=$HOME/opt/hp make install Предполагается, что будет использован локальный буст, установленный в $HOME/opt/boost. Все переменные сборки можно проверить и перезадать при помощи "ccmake ." или же через аргументы cmake. В случае использования системного буста указывать -DBOOST_ROOT не следует. Snort Подходит кодовая база Snort любой из 2.9.8.* версий: 2.9.8.0, 2.9.8.2. В статье используется последний стабильный релиз: 2.9.8.3. Добавление поддержки HyperScan производится патчем версии v1: https://01.org/sites/default/files/downloads/hyperscan/snort-2982-hyperscan-v1.tar_0.gz распаковываем исходники Snort: tar xf ~/tmp/snort-2.9.8.3.tar.gz cd snort-2.9.8.3/ накладываем патч: tar xf ~/tmp/snort-2982-hyperscan-v1.tar_0.gz gunzip -c snort-2982-hyperscan-v1/snort-2982-hyperscan-v1.patch.gz| patch -p2 На всех трёх доступных мне машинах с CentOS, Gentoo, Ubuntu этого было недостаточно для сборки: при линковке snort возникали ошибки вида /opt/hp/lib/libhs.a(mpvcompile.cpp.o): In function 'operator--': /usr/include/c++/4.8/bits/stl_tree.h:204: undefined reference to 'std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' /opt/hp/lib/libhs.a(mpvcompile.cpp.o): In function '__gnu_cxx::new_allocator<ue2::raw_puff>::deallocate(ue2::raw_puff*, unsigned long)': /usr/include/c++/4.8/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' требуется добавление -lstdc++ к списку библиотек в configure.in. Поэтому открываем любимым редактором файл configure.in, ищем в нём строчку, где задаётся "-lhs" и заменяем на "-lhs -lstdc++": - LIBS="${LIBS} -lhs" + LIBS="${LIBS} -lhs -lstdc++" Собираем Snort: autoreconf -fi ./configure --enable-intel-hyperscan --with-intel-hyperscan-includes=$HOME/opt/hp/include/hs --with-intel-hyperscan-libraries=$HOME/opt/hp/lib --prefix=$HOME/usr/opt298hp make install Настройка Собранный таким образом снорт уже будет немного быстрее оригинального, так как для поиска контента будут использоваться SIMD инструкции. Но прирост будет малозаметен. Для реального ускорения детектирования необходимо задать движок hyperscan в опции config detection конфигурационного файла snort.conf: config detection: search-method hyperscan Если использовать актуальный большой набор правил, например открытый набор от [[https://rules.emergingthreats.net/open/snort-2.9.0/ Emerging Threats]], то начальная загрузка снорта значительно замедлится. Чтобы избежать этого без особых потерь в ускорении можно использовать опцию split-any-any, таким образом результирующая строка config detection будет выглядеть так: config detection: search-method hyperscan split-any-any При этом будет наблюдаться выигрыш как в производительности сравнительно со снортом без hyperscan), так и по использованию памяти, точные данные зависят от набора правил. На наборах ET это около 10 процентов (~520 мб и 470 мб в top соответственно). Без опции split-any-any снорт будет анализировать трафик с максимальной скоростью, но будет гораздо дольше стартовать и будет гораздо более заметен в потреблении памяти системы. Таким образом, для сравнения получаются 4 системы с одним набором правил от ET: чистый Snort 2.9.8.3 без модификаций Snort, собранный с Hyperscan, без изменений конфигураци, то есть использующий библиотеку только для простого поиска контента Snort с Hyperscan и включённым движком детектирования hyperscan Snort с включенным движком hyperscan и опцией split-any-any Результаты Скорость проще всего оценивается по времени обработки pcap-файлов. Результирующее ускорение зависит от новизны CPU. Так, на одноядерном Celeron M560 от старого ноутбука, выигрыш будет в районе считанных процентов: с гиперсканом дамп будет обрабатываться за 300 секунд, без гиперскана за 310. Получше результаты на более современном Intel(R) Core(TM) i7-2600: Время обработки 100+ mb pcap файла без hyperscan: Run time for packet processing was 39.578298 seconds Время обработки того же 100+ mb pcap файла c hyperscan: Run time for packet processing was 35.190397 seconds Время обработки 100+ mb pcap файла с движком hyperscan + split-any-any: Run time for packet processing was 24.616165 seconds Время обработки 100+ mb pcap файла с движком hyperscan: Run time for packet processing was 22.323232 seconds Было бы интересно сравнить на Xeon. Видно, что при использовании данной библиотеки и хорошего железа можно ускорить обработку пакетов, пролетающих через Snort IDS, практически двукратно.

Пакетные фильтры в Linux: iptables, ipchains

Пример правил nftables с реализацией port knoсking для открытия доступа к SSH   Автор: umask  [комментарии]   Общий набор правил для nftables с реализацией техники "port knoсking", позволяющей организовать временное открытие сетевого порта к SSH только после предварительной попытки соединения к определённой последовательности портов (порты задаются в параметрах "define ssh_port_knock_[1234]"). #!/usr/bin/env -S bash -c 'nft -cof "${0}" && nft -f "${0}"' flush ruleset table inet filter { define sshd_port = 2299; set ssh_bad_ipv4_set { type ipv4_addr; flags dynamic; timeout 15m; } set ssh_bad_ipv6_set { type ipv6_addr; flags dynamic; timeout 15m; } set ssh_clients_ipv4_set { type ipv4_addr; flags dynamic; timeout 3s; } set ssh_clients_ipv6_set { type ipv6_addr; flags dynamic; timeout 3s; } set ssh_clients_candidates_ipv4_set { type ipv4_addr . inet_service; flags dynamic; timeout 1s; } set ssh_clients_candidates_ipv6_set { type ipv6_addr . inet_service; flags dynamic; timeout 1s; } ### printf %d\\n 0x$(openssl rand -hex 2) define ssh_port_knock_1 = changeme1; define ssh_port_knock_2 = changeme2; define ssh_port_knock_3 = changeme3; define ssh_port_knock_4 = changeme4; ### opened ports set serving_tcp_ports_set { type inet_service; flags constant; # elements = { # http, # https, # }; } set trusted_ipv4_set { type ipv4_addr; flags constant, interval; elements = { 169.254.169.254, 10.0.0.0/8, 192.168.0.0/16, }; } set trusted_ipv6_set { type ipv6_addr; flags constant, interval; elements = { fd00:ec2::254, }; } define dns_resolvers = { 0.0.0.0/0, } define allowed_icmp_types_input = { echo-reply, echo-request, destination-unreachable, } define allowed_icmp_types_output = { echo-reply, echo-request, destination-unreachable, } ### rfc4890; assist mobility candidate codes: 144, 145, 146, 147 define allowed_icmpv6_types_input = { echo-reply, echo-request, destination-unreachable, packet-too-big, time-exceeded, parameter-problem, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld-listener-query, mld-listener-report, mld-listener-done, mld2-listener-report, } ### rfc4890; assist mobility candidate codes: 144, 145, 146, 147 define allowed_icmpv6_types_output = { echo-reply, echo-request, destination-unreachable, packet-too-big, time-exceeded, parameter-problem, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld-listener-query, mld-listener-report, mld-listener-done, mld2-listener-report, } chain INPUT { type filter hook input priority filter + 20; policy drop; iif lo accept comment "accept input connections via loopback"; iif != lo ip saddr 127.0.0.0/8 counter drop comment "drop loopback connections not coming from loopback"; iif != lo ip daddr 127.0.0.0/8 counter drop comment "drop loopback connections not coming from loopback"; iif != lo ip6 saddr ::1/128 counter drop comment "drop loopback connections not coming from loopback"; iif != lo ip6 daddr ::1/128 counter drop comment "drop loopback connections not coming from loopback"; ### as little rules as possible for trusted hosts ip saddr @trusted_ipv4_set accept comment "accept trusted hosts"; ip6 saddr @trusted_ipv6_set accept comment "accept trusted hosts"; ### before ct meta l4proto icmp icmp type $allowed_icmp_types_input limit rate 10/second burst 20 packets counter accept comment "accept icmp with limits"; meta l4proto icmpv6 icmpv6 type $allowed_icmpv6_types_input limit rate 10/second burst 20 packets counter accept comment "accept icmpv6 with limits"; meta l4proto { icmp, icmpv6 } counter drop comment "drop icmp over limit"; ct state vmap { established : accept, related : accept, invalid : drop }; tcp dport @serving_tcp_ports_set ct state new counter accept comment "accept connections to serving tcp ports"; ### port knocking #tcp dport $ssh_port_knock_1 add @ssh_clients_candidates_ipv4_set { ip saddr . $ssh_port_knock_2 }; #tcp dport $ssh_port_knock_1 add @ssh_clients_candidates_ipv6_set { ip6 saddr . $ssh_port_knock_2 }; #tcp dport $ssh_port_knock_2 ip saddr . tcp dport @ssh_clients_candidates_ipv4_set add @ssh_clients_candidates_ipv4_set { ip saddr . $ssh_port_knock_3 }; #tcp dport $ssh_port_knock_2 ip6 saddr . tcp dport @ssh_clients_candidates_ipv6_set add @ssh_clients_candidates_ipv6_set { ip6 saddr . $ssh_port_knock_3 }; #tcp dport $ssh_port_knock_3 ip saddr . tcp dport @ssh_clients_candidates_ipv4_set add @ssh_clients_candidates_ipv4_set { ip saddr . $ssh_port_knock_4 }; #tcp dport $ssh_port_knock_3 ip6 saddr . tcp dport @ssh_clients_candidates_ipv6_set add @ssh_clients_candidates_ipv6_set { ip6 saddr . $ssh_port_knock_4 }; #tcp dport $ssh_port_knock_4 ip saddr . tcp dport @ssh_clients_candidates_ipv4_set add @ssh_clients_ipv4_set { ip saddr } counter log prefix "ssh port knocked : "; #tcp dport $ssh_port_knock_4 ip6 saddr . tcp dport @ssh_clients_candidates_ipv6_set add @ssh_clients_ipv6_set { ip6 saddr } counter log prefix "ssh port knocked : "; #tcp dport $sshd_port ip saddr @ssh_clients_ipv4_set counter accept; #tcp dport $sshd_port ip6 saddr @ssh_clients_ipv6_set counter accept; ### rate limits tcp dport $sshd_port ct state new, untracked meter ssh_conns_ratemeter4 { ip saddr timeout 5m limit rate over 1/minute burst 7 packets } counter update @ssh_bad_ipv4_set { ip saddr } comment "update ssh bruteforce set with saddr of attacker; hint: nft list meter inet filter ssh_conns_ratemeter4"; tcp dport $sshd_port ct state new, untracked meter ssh_conns_ratemeter6 { ip6 saddr timeout 5m limit rate over 1/minute burst 7 packets } counter update @ssh_bad_ipv6_set { ip6 saddr } comment "update ssh bruteforce set with saddr of attacker; hint: nft list meter inet filter ssh_conns_ratemeter6"; tcp dport $sshd_port ip saddr @ssh_bad_ipv4_set counter drop comment "drop ssh bruteforce; hint: nft list set inet filter ssh_bad_ipv4_set"; tcp dport $sshd_port ip6 saddr @ssh_bad_ipv6_set counter drop comment "drop ssh bruteforce; hint: nft list set inet filter ssh_bad_ipv6_set"; tcp dport $sshd_port counter accept comment "accept ssh connections"; ### new rules place here: counter comment "count dropped packets"; #log prefix "nft drop IN : " comment "log dropped packets"; } chain OUTPUT { type filter hook output priority filter + 20; policy drop; oif lo accept comment "accept input connections via loopback"; oif != lo ip saddr 127.0.0.0/8 counter drop comment "drop loopback connections not coming from loopback"; oif != lo ip daddr 127.0.0.0/8 counter drop comment "drop loopback connections not coming from loopback"; oif != lo ip6 saddr ::1/128 counter drop comment "drop loopback connections not coming from loopback"; oif != lo ip6 daddr ::1/128 counter drop comment "drop loopback connections not coming from loopback"; ### as little rules as possible for trusted hosts ip daddr @trusted_ipv4_set accept comment "accept trusted hosts"; ip6 daddr @trusted_ipv6_set accept comment "accept trusted hosts"; ### before ct meta l4proto icmp icmp type $allowed_icmp_types_output limit rate 10/second burst 20 packets counter accept comment "accept icmp with limits"; meta l4proto icmpv6 icmpv6 type $allowed_icmpv6_types_output limit rate 10/second burst 20 packets counter accept comment "accept icmpv6 with limits"; meta l4proto { icmp, icmpv6 } counter drop comment "drop icmp over limit"; ct state vmap { established : accept, related : accept, invalid : drop }; meta skuid { root, uadm, chrony } meta skgid { root, uadm, chrony } counter accept comment "accept connections from specified users"; meta skuid postfix meta skgid postfix tcp dport { smtp, smtps, submission } counter accept comment "accept connections from postfix user"; meta l4proto { tcp, udp } th dport 53 ip daddr $dns_resolvers counter accept comment "accept dns; for paranoia specify comma separated list of resolvers in $dns_resolvers"; ### new rules place here: counter comment "count dropped packets"; log prefix "nft drop OUT : " comment "log dropped packets"; } chain FORWARD { type filter hook forward priority filter + 20; policy drop; log prefix "nft drop FWD : " comment "log dropped packets"; } }   Прозрачный межсетевой экран с маршрутизатором (доп. ссылка 1)   Автор: Владимир Олейник  [комментарии]   Предисловие В этом году поменяли провайдера. Выдал он нам небольшую сетку, сказал маршрутизатор по умолчанию, находящийся в этой же сети. В общем, ситуация вполне стандартная. Сразу же столкнулись с неудобствами такого подключения, которых не было при подключении к старому провайдеру по pppoe, ведь теперь маршрутизатор не под нашим управлением: Все хосты с "белыми" адресами должны обзавестись собственными межсетевыми экранами. Маршрутизация превращается либо в динамическую (что то ещё удовольствие), либо в прописывании её на всех "белых" хостах. Быстрые и неправильные решения Данные проблемы можно попытаться решить наскоком, и что может ложно успокоить, "всё будет работать". Поменяв маршрут по умолчанию на белых хостах на собственный маршрутизатор создастся видимость, что всё починилось: маршрутизация до филиалов и серых сетей появилась, а межсетевой экран даже сможет срабатывать на выход. Но кому более всего нужен межсетевой экран на выход? Вот то-то же. Да и с маршрутизацией не всё на самом деле в порядке. На каждый посланный вами из белой сети в Интернет пакет, вы будете получать ICMP redirect, говорящий, что маршрутизатор вами установлен не тот: PING branch.mydomain.ru (branch-IP): 56 data bytes From GW-IP Redirect (change route) 84 bytes from branch-IP: icmp_seq=0 ttl=63 time=N ms Windows машины, у которых по умолчанию применяется политика реагирования на этот код, будут бесконечно добавлять в таблицу маршрутизации записи на каждый хост в Интернете через маршрутизатор провайдера. Хорошо, а давайте добавим все статические маршруты, а между провайдерским и своим коммутатором поставим прозрачный файервол. Ну что ж, это решение будет работать пока вам не надоест возиться с маршрутизацией и не возникнет мысль, что может сделаем управляющий интерфейс прозрачного файервола в белой сети и он и будет центральным маршрутизатором. Увы, как только вы это сделаете, всё вернётся к проблеме, описанной ранее. Правильное решение Из предыдущей главы стало понятно, что нам нужно: прозрачный файервол; управляющий интерфейс этого файервола сделать внешним для возможности включения туннелей для филиалов и домашних пользователей через Интернет; озаботиться хорошей фильтрацией от атак и для него, подконфигурив файрвол; выключить redirect; сконфигурить все VPN-ы либо на этом хосте, либо прописать маршрут на хосте с прозрачным файерволом - центральным маршрутизатором до сервера VPN. Как ни странно, но в сети можно найти решение как это сделать, но это решение предлагается как совершенно странный нетипичный пример сети с запутанными условиями "из реальной жизни", совсем не похожей на рассматриваемый пример типичного подключения. Как это делается в других ОС, отличных от Linux оставим на самостоятельный поиск читателю, а для Linux эта строчка выглядит вот так и немного странно: ebtables -t broute -A BROUTING -i eth-in -p ipv4 -j redirect --redirect-target DROP Где eth-in - входящий интерфейс со стороны вашей остальной сети. Тот, кто уже имел дела с конфигурацией файервола на Linux, взглянув на эту строчку скажет, что мы запретили совсем необходимый переброс пакета со входящего интерфейса на выход. Да, именно так. Дело в том, что ebtables имеет много точек разветвления, запрещая одно ветвление, мы заставляем пермещать пакет в другое, если политика по умолчанию или следующие правила это не запрещают. В данном случае пакет покинет L2-уровень, за который ответсвеннен ebtables и мост, а пойдёт на L3-уровень в маршрутизацию и iptables. Посмотрите на примеры использования ebtables, вы там в большинстве случаев найдёте именно правила с DROP. Такова уж судьба у L2-уровня, другие действия нужны к ну уж очень занятны и нетипичным конфигурациям, типа кластеров и др.   Борьба с подстановкой фиктивных пакетов провайдером при помощи iptables   [комментарии]   Многие провайдеры и корпоративные системы инспектирования трафика применяют подстановку пакетов, перенаправляющих браузер пользователя на страницу с информацией о блокировке, при этом не обрывая изначально установленное соединение к заблокированному ресурсу. Например, запустив tcpdump -nA -s1500 host заблокированный_IP и попытавшись отрыть заблокированный ресурс в браузере, можно увидеть такой пакет: 13:50:24.563093 IP 1.2.3.4.80 > 192.168.1.10.58072: Flags [.], seq 1777859077:1777859201, ack 3185912442, win 229, length 124 E.......2..a..x$...f.P..i.....*zP....V..HTTP/1.1 302 Found Connection: close Location: http://warning.bigprovider.ru/?id=61&st=0&dt=1.2.3.4&rs=http://badsite.com/ следом за которым приходит реальный ответ и другие пакеты с подпадающего под блокировку сайта, которые продолжают приходить и не отбрасываются провайдером. Данный метод блокировки обусловлен тем, что оборудование для обеспечения блокировки хоть и имеет доступ к транзитному трафику, но оно работает обособленно от сетевой инфраструктуры и не может изменять трафик или напрямую блокировать прохождение пакетов. Соответственно, суть применяемого провайдерами метода состоит в том, что блокирующее оборудование зная параметры сетевого соединения реализует блокировку через отправку подставного упреждающего ответа. Так как такой фиктивный ответ приходит раньше реального ответа от удалённого сервера и снабжён корректным номером последовательности TCP, он воспринимается клиентским ПО в первую очередь, а пришедший хвост реального ответа игнорируется. Обойти подобную блокировку достаточно легко при помощи добавления на локальной Linux-системе правила, отбрасывающего фиктивный ответ: iptables -I INPUT -p tcp --sport 80 -m string --string "Location: http://warning.bigprovider.ru" --algo bm -j DROP В случае HTTPS (подобным образом также часто блокируют Tor) блокировка обычно устраивается через подстановку в трафик RST-пакетов для принудительного обрыва соединения. Обходится данное ограничение следующим правилом: iptables -I INPUT -p tcp --sport 443 --tcp-flags RST RST -j DROP Итог: Даже самые крупные провайдеры лукавят и вместо полноценной блокировки применяют сомнительные методы подстановки трафика, не блокируя фактически запрещённый трафик. Таким образом, описанная выше техника не может рассматриваться как метод обхода блокировки, так как блокировки нет как таковой - пакеты с запрещённых ресурсов не блокируются и продолжают приходить на клиентскую систему, а приходящие от провайдера вкрапления лишь создают видимость блокировки и организуют проброс на стороне клиента. Клиент имеет полное право отбрасывать любые пакеты на своей системе и это не может рассматриваться как лазейка для обхода блокировки, которая не выполнена должным образом провайдером. Дополнение: Для выявления описанного выше вида блокировок можно использовать утилиту curl, в которой можно увидеть "хвост" реального ответа: $ curl -i --ignore-content-length http://badsite.org/ HTTP/1.1 302 Found Connection: close Location: http://warning.bitprovider.ru/?id=6&st=0&dt=1.2.3.4&rs=http://badsite.org/ 8 Location: http://badsite.org/forum/index.php Connection: keep-alive ... Если запросить конечную страницу, то можно получить её содержимое без манипуляций с iptables: $ curl -i --ignore-content-length --trace-asci dump.txt http://badsite.org/forum/index.php HTTP/1.1 302 Found Connection: close Location: http://warning.bigprovider.ru/?id=6&st=0&dt=1.2.3.4&rs=http://badsite.org/forum/index.php ection: keep-alive 1fc0 ...содержимое HTML-документа. $ less dump.txt ... <= Recv header, 20 bytes (0x14) 0000: HTTP/1.1 302 Found <= Recv header, 19 bytes (0x13) 0000: Connection: close <= Recv header, 101 bytes (0x65) 0000: Location: http://warning.bigprovider.ru/?id=6&st=0&dt=1.2.3.4&rs=h 0040: ttp://badsite.org/forum/index.php <= Recv header, 2 bytes (0x2) 0000: <= Recv data, 1238 bytes (0x4d6) 0000: ection: keep-alive ...   Борьба с SYN-флудом при помощи iptables и SYNPROXY (доп. ссылка 1) (доп. ссылка 2)   [комментарии]   Начиная с ядра Linux 3.12 и инструментария IPTables 1.4.21 в iptables доступна поддержка новой цели - SYNPROXY, позволяющей в десятки раз увеличить интенсивность обработки SYN-пакетов при противостоянии таким атакам, как SYN Flood, SYN-ACK Flood и ACK Flood. Например, если в обычной конфигурации ядра сервер на базе CPU Xeon X5550 способен обработать приблизительно 200 тысяч SYN- или ACK-пакетов в секунду, то при включении SYNPROXY производительность возрастает до нескольких миллионов, чего достаточно для отражения небольших атак без привлечения специализированного оборудования. Включаем в /etc/sysctl.conf syncookies и timestamps, так как они необходимы для работы SYNPROXY: sysctl -w net/ipv4/tcp_syncookies=1 sysctl -w net/ipv4/tcp_timestamps=1 Исключаем ACK-пакеты из обработки системой отслеживания соединений (отслеживаем только уже установленные соединения, ACK-пакеты снабжаются меткой INVALID), что помогает снизить нагрузку при ACK-флуде: sysctl -w net/netfilter/nf_conntrack_tcp_loose=0 Увеличивает размер хэша для отслеживания соединений: echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize sysctl -w net/netfilter/nf_conntrack_max=2000000 Исключаем SYN-пакеты из обработки в системе отслеживания соединений (таблица raw обрабатывает соединений без их отслеживания, а опция "--notrack" позволяет обойти цель CT ("conntrack")): iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack Выделяем SYN- и ACK-пакеты без отслеживания (UNTRACKED и INVALID), как в прошлом правиле и направляем их в цель SYNPROXY, в которой будет выполнена проверка syncookies и если всё нормально установлено TCP-соединение: iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 Отбрасываем все остальные пакеты, не прошедшие проверку в прошлом правиле: iptables -A INPUT -m conntrack --ctstate INVALID -j DROP Если необходимо обеспечить защиту для отдельного IP, правила можно изменить следующим образом (если атака ведётся только на 80 сетевой порт, можно добавить "--dport 80"): iptables -t raw -I PREROUTING -p tcp -m tcp -d 192.168.1.10 --syn -j CT --notrack iptables -I INPUT -p tcp -m tcp -d 192.168.1.10 -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 iptables -A INPUT -m conntrack --ctstate INVALID -j DROP Для просмотра статистики: iptables -t raw -vnL cat/proc/net/stat/synproxy Если нужно на низком уровне заблокировать некоторые HTTP-запросы, явно связанные с проведением атаки, можно использовать следующее правило (маску можно выделить из логов или через "tcpdump -nnA dst host 192.168.1.10 and port http"): iptables -A INPUT -p tcp --dport 80 -m string --string "маска_блокировки" --algo bm -j DROP   Отключение Firewalld и возвращение к iptables в RHEL/CentOS 7   Автор: Базиль  [комментарии]   Использование применяемой по умолчанию в RHEL/CentOS 7 надстройки Firewalld не всегда очевидно, поэтому бывает удобнее вернуться к классическим скриптам работы с пакетным фильтром. Установим классические сервисы для работы с iptables: yum install -y iptables-services Настраиваем правила фильтрации в файлах /etc/sysconfig/iptables и /etc/sysconfig/iptables-config, например, можно сохранить текущие правила firewalld: iptables-save > /etc/sysconfig/iptables Завершаем работу firewalld и запускаем сервисы iptables: systemctl stop firewalld && systemctl start iptables Проверяем, что используются новые правила: iptables -S iptables -L Для восстановления резервной копии типовых правил с другой машины можно воспользоваться командой iptables-restore: cat iptables.backup| iptables-restore -t service iptables save (или /usr/libexec/iptables/iptables.init save) для возвращения настроек из /etc/sysconfig/iptables: systemctl reload iptables Если всё нормально убираем активацию Firewalld при загрузке и запрещаем ручной запуск: systemctl disable firewalld systemctl mask firewalld Активируем включение сервисов iptables при загрузке: systemctl enable iptables   Блокирование попыток эксплуатации heartbeat-уязвимости в OpenSSL средствами iptables (доп. ссылка 1)   [комментарии]   Пример блокирования критической уязвимости CVE-2014-0160 в OpenSSL 1.0.1, позволяющей получить содержимое памяти удалённых серверных и клиентских приложений. Отражаем в логе все heartbeat-запросы при помощи iptables и модуля u32: iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" Блокируем heartbeat-запросы: iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP Отслеживаем возможные атаки при помощи Wireshark: tshark -i interface port 443 -R 'frame[68:1] == 18' tshark -i interface port 443 -R 'ssl.record.content_type == 24'   Использование xtables-модуля xt_bpf для фильтрации через BPF в Linux   Автор: Roman Timofeev  [комментарии]   В ядре Linux 3.9 добавили xt_bpf - аналог нетграф-ноды ng_bpf из FreeBSD. Без использования правил iptables на платформе x86_64 BPF-правило демонстрирует производительность 40K (40 GBps) netperf TCP_STREAM, после вставки 100 BPF-правил производительность составляет 28K. Используемое BPF-правило: iptables -A OUTPUT -m bpf --bytecode '6,40 0 0 14, 21 0 3 2048,48 0 0 25,21 0 1 20,6 0 0 96,6 0 0 0,' -j При использовании 100 эквивалентных правил через u32 производительность составляет 21K: iptables -A OUTPUT -m u32 --u32 '6&0xFF=0x20' -j DROP Т.е. для достаточно приличного числа ситуаций можно получить как упрощение правил, так и их ускорение (тем более, что на некоторых платформах доступен net.core.bpf_jit_enable и инструкции bpf преобразуются в нативный код). Для желающих использовать в более старых ядрах, доступен патч для ядра и патч для iptables. В оригинале, для формирования байткода BPF автор модуля использует компилятор (который просто вызывает libpcap), хотя всё что нужно можно получить от tcpdump, указав ему подходящий интерфейс с DLT_RAW (для чего прекрасно подходит создаваемый после загрузки модуля ipip.ko интерфейс tunl0). Пример использования: modprobe ipip tcpdump -i tunl0 -ddd 'udp' > udp.bpf tcpdump -i tunl0 -ddd 'icmp' > icmp.bpf iptables -A INPUT -m bpf --bytecode-file udp.bpf -j LOG --log-prefix "udp: " iptables -A INPUT -m bpf --bytecode-file icmp.bpf -j LOG --log-prefix "icmp: " В dmesg мы увидим: [17453.963938] udp: IN=eth0 OUT= MAC=00:15:17:14:c8:c3:00:30:4f:64:71:92:08:00 SRC=192.168.100.1 DST=192.168.100.2 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=63634 PROTO=UDP SPT=53 DPT=8516 LEN=217 [17460.203403] icmp: IN=eth0 OUT= MAC=00:15:17:14:c8:c3:00:30:4f:64:71:92:08:00 SRC=192.168.100.1 DST=192.168.100.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=18090 SEQ=1   Использование нескольких сетевых стеков в Linux   Автор: Roman Timofeev ( ^rage^ )  [комментарии]   В linux относительно давно появилась такая замечательная вещь, как неймспейсы (namespaces). Основное применение данной технологии - контейнерная виртуализация, но и на маршрутизаторе можно придумать много разных применений, так как среди неймспейсов есть "network namespaces". Network namespaces позволяют в рамках одной машины в каждом неймспейсе иметь: свой набор таблиц маршрутизации (а их 2^31-1 шт) свою arp-таблицу свои правила iptables свои устройства (а значит и qdisc + class'ы tc) NB: для выполнения нижеследующих примеров крайне желательно иметь свежий iproute2 и ядро. Создаются неймспейсы достаточно скучно и просто: ip netns add VROUTER ip netns add KUKYSEVRACI Создадим "виртуальны шнурок": ip link add name ve0a type veth peer name ve0b Добавим интерфейсы внутрь VROUTER: ip link set dev eth0 netns VROUTER ip link set dev ve0b netns VROUTER Выполнить команду в контексте определённого неймспейса можно так: ip netns exec VROUTER ip link show Настроим адреса: ip netns exec VROUTER ip a a 192.168.1.1/24 dev ve0b ip a a 192.168.1.2/24 dev ve0a ip netns exec VROUTER ip a a 10.140.48.16/24 dev eth0 Поднимем интерфейсы: ip link set dev ve0a up ip netns exec VROUTER ip link set dev eth0 up ip netns exec VROUTER ip link set dev ve0b up Шлюз по умолчанию: ip netns exec VROUTER ip r a default via 10.140.48.1 Посмотрим, что получилось: root@laptus:~# ip netns exec VROUTER ip r s default via 10.140.48.1 dev eth0 10.140.48.0/24 dev eth0 proto kernel scope link src 10.140.48.16 192.168.1.0/24 dev ve0b proto kernel scope link src 192.168.1.1 Добавим NAT: ip netns exec VROUTER iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 10.140.48.16 Сделаем пару трейсов: root@laptus:~# ip netns exec VROUTER traceroute -q 1 -I opennet.ru traceroute to opennet.ru (77.234.201.242), 30 hops max, 60 byte packets 1 10.140.48.1 (10.140.48.1) 0.148 ms 2 10.140.0.1 (10.140.0.1) 0.245 ms 3 border.yournet.ru (91.204.148.17) 0.436 ms 4 alisa.yournet.ru (91.204.151.2) 0.521 ms 5 sev-gw.yournet.ru (91.204.148.2) 8.975 ms 6 bl16-1-gw.spb.runnet.ru (194.190.255.25) 1.321 ms 7 bl16-1-gw.spb.runnet.ru (194.85.40.170) 1.785 ms 8 s14-1-gw.spb.runnet.ru (194.85.40.81) 1.456 ms 9 vuztc.spb.runnet.ru (194.190.255.170) 1.987 ms 10 opennet.ru (77.234.201.242) 2.395 ms root@laptus:~# traceroute -q 1 -I opennet.ru traceroute to opennet.ru (77.234.201.242), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.094 ms 2 10.140.48.1 (10.140.48.1) 0.751 ms 3 10.140.0.1 (10.140.0.1) 1.277 ms 4 border.yournet.ru (91.204.148.17) 2.061 ms 5 alisa.yournet.ru (91.204.151.2) 2.911 ms 6 sev-gw.yournet.ru (91.204.148.2) 6.770 ms 7 bl16-1-gw.spb.runnet.ru (194.190.255.25) 3.622 ms 8 bl16-1-gw.spb.runnet.ru (194.85.40.170) 5.262 ms 9 s14-1-gw.spb.runnet.ru (194.85.40.81) 4.135 ms 10 vuztc.spb.runnet.ru (194.190.255.170) 4.710 ms 11 opennet.ru (77.234.201.242) 7.220 ms   Интерактивный firewall в Linux   Автор: tux2002  [комментарии]   Linux обладает отличными средствами фильтрации сетевого трафика, но обычно в нём строят статический firewall. В данной статье я опишу идею и реализацию интерактивного firewall, который в случае подозрительной активности выводит пользователю окно с предложением блокирования трафика или игнорирования предупреждения. Рассмотрим следующую заготовку firewall, которую в дальнейшем можно обучать интерактивно: cat slackwall.initstate # Generated by iptables-save v1.4.10 on Sat Dec 3 21:42:46 2011 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :FIREWALL-INPUT - [0:0] :FIREWALL-FORWARD - [0:0] :FIREWALL-OUTPUT - [0:0] -A INPUT -m state --state INVALID -j REJECT --reject-with icmp-port-unreachable -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -j FIREWALL-INPUTFIREWALL-INPUT -A INPUT -j LOG --log-prefix "FIREWALL-INPUT " -A INPUT -j REJECT --reject-with icmp-port-unreachable -A FORWARD -m state --state INVALID -j REJECT --reject-with icmp-port-unreachable -A FORWARD -p icmp -j ACCEPT -A FORWARD -p udp -m udp --dport 53 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j FIREWALL-FORWARD -A FORWARD -j LOG --log-prefix "FIREWALL-FORWARD " -A FORWARD -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -m state --state INVALID -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j FIREWALL-OUTPUT -A OUTPUT -j LOG --log-prefix "FIREWALL-OUTPUT " -A OUTPUT -j REJECT --reject-with icmp-port-unreachable COMMIT # Completed on Sat Dec 3 21:42:46 2011 В трёх основных цепочках мы сначала запрещаем обрывки соединений, потом разрешаем уже установленные соединения, DNS и ICMP трафик. Далее пакеты перенаправляются в одну из трёх обучаемых цепочек: FIREWALL-INPUT FIREWALL-OUTPUT FIREWALL-FORWARD откуда пакеты, для которых не нашлось правила возвращаются в одну из основных цепочек и ЛОГИРУЮТСЯ а затем отклоняются ПО УМОЛЧАНИЮ. В цепочке FIREWALL-OUTPUT для персонального firewall лучше держать только одно разрешающее правило для всего трафика, иначе обучение становится трудоёмким. Таким образом пакет в обучаемой цепочке шлибо обрабатывается с соответствующим решением, либо попадает в LOG firewall`а и отклоняется. То есть строки о "необученных пакетах" можно регулярно считывать, парсить, предлагать решение пользователю и вносить новые правила в обучаемые цепочки. Например если есть некий shell сценарий обработки SYSLOG, можно выполнить от рута: tail -n 1 -f /var/log/syslog | ./slackwall В данном примере обработчик - скрипт slackwall. Вот его текст: #!/bin/sh while read string do echo $string | grep FIREWALL > /dev/null || continue for token in $string do echo $token | grep "=" > /dev/null && export $token echo $token | grep "FIREWALL" > /dev/null && export CHAIN=$token done [ -z "$IN" ] && unset SRC [ -z "$OUT" ] && unset DST HSRC=`host $SRC 2>/dev/null | grep "domain name pointer" | awk '{ print $5 }'` HDST=`host $DST 2>/dev/null | grep "domain name pointer" | awk '{ print $5 }'` echo $PROTO | grep "^[[:digit:]]*$" > /dev/null && unset DPT PROTO=`cat /etc/protocols | grep "[[:space:]]$PROTO[[:space:]]" | awk '{ print $1 }'` HPROTO=`cat /etc/services | grep -i "[[:space:]]$DPT/$PROTO"` HSRC=${HSRC:-$SRC} HDST=${HDST:-$DST} HPROTO=${HPROTO:-"$DPT/$PROTO"} unset IHSRC IHDST ISRC IDST IDPT IPROTO [ -z "$HSRC" ] || IHSRC="-s $HSRC" [ -z "$HDST" ] || IHDST="-d $HDST" [ -z "$SRC" ] || ISRC="-s $SRC" [ -z "$DST" ] || IDST="-d $DST" [ -z "$DPT" ] || IDPT="--dport $DPT" IPROTO="-p $PROTO" cat slackwall.userules | grep "iptables -A $CHAIN $IPROTO $IHSRC $IHDST $IDPT -j" \\ && echo Alredy && continue cat slackwall.userules | grep "iptables -A $CHAIN $IPROTO $ISRC $IHDST $IDPT -j" \\ && echo Alredy && continue cat slackwall.userules | grep "iptables -A $CHAIN $IPROTO $IDPT -j" \\ && echo Alredy && continue unset COMMAND ACTION=6 LANG=C xmessage -buttons BlockFQDN:1,BlockIP:2,AcceptFQDN:3,AcceptIP:4,BlockPortOnAllIP:5,Skip:6 \\ -default Skip -timeout 15 "$HSRC => $HDST ($HPROTO)" ACTION=$? [ $ACTION == 0 ] && continue [ $ACTION == 1 ] && COMMAND="iptables -A $CHAIN $IPROTO $IHSRC $IHDST $IDPT -j REJECT" [ $ACTION == 2 ] && COMMAND="iptables -A $CHAIN $IPROTO $ISRC $IDST $IDPT -j REJECT" [ $ACTION == 3 ] && COMMAND="iptables -A $CHAIN $IPROTO $IHSRC $IHDST $IDPT -j ACCEPT" [ $ACTION == 4 ] && COMMAND="iptables -A $CHAIN $IPROTO $ISRC $IDST $IDPT -j ACCEPT" [ $ACTION == 5 ] && COMMAND="iptables -A $CHAIN $IPROTO $IDPT -j REJECT" [ $ACTION == 6 ] && continue $COMMAND [ "$?" == 0 ] && echo "$COMMAND" >> slackwall.userules done Он парсит строки SYSLOG и рисует на экране пользователя вопрос с помощью xmessage и затем добавляет правило в ядро и дублирует его в сценарий slackwall.userules, предназначенный для начальной инициализации firewall. Вот его начальное состояние: #!/bin/bash modprobe nf_conntrack modprobe nf_conntrack_amanda modprobe nf_conntrack_ftp modprobe nf_conntrack_h323 modprobe nf_conntrack_irc modprobe nf_conntrack_netbios_ns modprobe nf_conntrack_netlink modprobe nf_conntrack_pptp modprobe nf_conntrack_proto_dccp modprobe nf_conntrack_proto_gre modprobe nf_conntrack_proto_sctp modprobe nf_conntrack_proto_udplite modprobe nf_conntrack_sane modprobe nf_conntrack_sip modprobe nf_conntrack_tftp modprobe xt_conntrack iptables -F FIREWALL-INPUT iptables -F FIREWALL-FORWARD iptables -F FIREWALL-OUTPUT iptables -A FIREWALL-OUTPUT -j ACCEPT Для начального запуска firewall нужно выполнить: 1. Разрешаем руту рисовать на X сервере (выполняется от пользователя, остальное всё от рута) $xhost +localhost 2. Загружаем неизменяемую часть firewall #cat slackwall.initstate | iptables-restore 3. Загружаем пользовательские правила, в дальнейшем их можно отредактировать и перезапустить эту комманду #./slackwall.userules 4. Запускаем скрипт обучения: #tail -n 1 -f /var/log/syslog | ./slackwall У меня это работает в таком виде на Slackware 13.37, Linux psc 2.6.37.6-tinyslack Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux. Ссылка на готовый пакет: https://sourceforge.net/projects/slackwall/   Создание модуля для iptables, изменяющего ID пакета (доп. ссылка 1)   Автор: xlise  [комментарии]   Данная статья основывается на материале "Разработка Match-модуля для iptables своими руками" (http://www.linuxjournal.com/article/7184), но код работает на ядрах 2.6.20+. Мне потребовалось изменить ID IP пакетов, в интернете подходящей инструкции как это сделать на ядре 2.6.24 я не нашел, из-за этого решил написать, как удалось решить задачу. Для реализации задуманного нам понадобится написать модуль ядра, который будет выполнять проверку и модуль расширения для iptables, который будет работать с модулем ядра - создавать новые цепочки, использующие наш модуль, выводить информацию о критерии при выводе списка правил на экран, а также проверять корректность передаваемых модулю параметров. Сначала создадим общий заголовочный файл ipt_ID.h: #ifndef _IPT_ID_H #define _IPT_ID_H enum { IPT_ID_RAND = 0, IPT_ID_INC }; #define IPT_ID_MAXMODE IPT_ID_INC struct ipt_ID_info { u_int8_t mode; u_int16_t id; }; #endif Теперь скопируем его в исходники netfilter в директорию linux/netfilter_ipv4/ Далее рассмотрим модуль ядра ipt_ID.с. #include <linux/module.h> #include <linux/skbuff.h> #include <linux/ip.h> #include <net/checksum.h> #include <linux/random.h> #include <linux/netfilter/x_tables.h> #include <linux/netfilter_ipv4/ipt_ID.h> MODULE_AUTHOR("Xlise <[email protected]>"); MODULE_DESCRIPTION("Xtables: IPv4 ID field modification target"); MODULE_LICENSE("GPL"); static int count=0; static struct iphdr l_iph[5]; static unsigned int id_tg(struct sk_buff *skb, const struct net_device *in, const struct net_device *out, unsigned int hooknum, const struct xt_target *target, const void *targinfo) { struct iphdr *iph; const struct ipt_ID_info *info = targinfo; u_int16_t new_id; int i=0; if (!skb_make_writable(skb, skb->len)) return NF_DROP; iph = ip_hdr(skb); switch (info->mode) { case IPT_ID_RAND: get_random_bytes(&info->id, sizeof(info->id)); new_id = info->id; break; case IPT_ID_INC: while (i<5) { if (l_iph[i].daddr == iph->daddr) { new_id = l_iph[i].id + htons(1); l_iph[i].id = new_id; } else {new_id = iph->id; l_iph[count] = *iph; count++; if (count > 4) count = 0; } i++; } default: new_id = iph->id; break; } if (new_id != iph->id) { csum_replace2(&iph->check, iph->id, new_id); iph->id = new_id; } return XT_CONTINUE; } static bool id_tg_check(const char *tablename, const void *e, const struct xt_target *target, void *targinfo, unsigned int hook_mask) { const struct ipt_ID_info *info = targinfo; if (info->mode > IPT_ID_MAXMODE) { printk(KERN_WARNING "ipt_ID: invalid or unknown Mode %u\n", info->mode); return false; } if (info->mode != IPT_ID_SET && info->id == 0) return false; return true; } static struct xt_target id_tg_reg __read_mostly = { .name = "ID", .family = AF_INET, .target = id_tg, .targetsize = sizeof(struct ipt_ID_info), .table = "mangle", .checkentry = id_tg_check, .me = THIS_MODULE, }; static int __init id_tg_init(void) { return xt_register_target(&id_tg_reg); } static void __exit id_tg_exit(void) { xt_unregister_target(&id_tg_reg); } module_init(id_tg_init); module_exit(id_tg_exit); Напишем Makefile для нашего модуля: obj-m := ipt_ID.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) $(MAKE) -C $(KDIR) M=$(PWD) modules добавим модуль в ядро insmod ipt_ID.ko Для создания модуля для iptables нам потребуются исходники для iptables-1.4.4 Создадим файл libipt_ID.c #include <stdio.h> #include <string.h> #include <stdlib.h> #include <getopt.h> #include <xtables.h> #include <linux/netfilter_ipv4/ipt_ID.h> #define IPT_ID_USED 1 static void ID_help(void) { printf( "ID target options\n" " --id-rand value Set ID to \n" " --id-inc value Increment ID by \n"); } static int ID_parse(int c, char **argv, int invert, unsigned int *flags, const void *entry, struct xt_entry_target **target) { struct ipt_ID_info *info = (struct ipt_ID_info *) (*target)->data; u_int16_t value; if (*flags & IPT_ID_USED) { xtables_error(PARAMETER_PROBLEM, "Can't specify ID option twice"); } if (!optarg) xtables_error(PARAMETER_PROBLEM, "ID: You must specify a value"); if (xtables_check_inverse(optarg, &invert, NULL, 0)) xtables_error(PARAMETER_PROBLEM, "ID: unexpected `!'"); if (!xtables_strtoui(optarg, NULL, &value, 0, UINT16_MAX)) xtables_error(PARAMETER_PROBLEM, "ID: Expected value between 0 and 255"); switch (c) { case '1': info->mode = IPT_ID_RAND; break; case '2': if (value == 0) { xtables_error(PARAMETER_PROBLEM, "ID: increasing by 0?"); } info->mode = IPT_ID_INC; break; default: return 0; } info->id = value; *flags |= IPT_ID_USED; return 1; } static void ID_check(unsigned int flags) { if (!(flags & IPT_ID_USED)) xtables_error(PARAMETER_PROBLEM, "TTL: You must specify an action"); } static void ID_save(const void *ip, const struct xt_entry_target *target) { const struct ipt_ID_info *info = (struct ipt_ID_info *) target->data; switch (info->mode) { case IPT_ID_SET: printf("--id-set "); break; case IPT_ID_DEC: printf("--id-dec "); break; case IPT_ID_INC: printf("--id-inc "); break; } printf("%u ", info->id); } static void ID_print(const void *ip, const struct xt_entry_target *target, int numeric) { const struct ipt_ID_info *info = (struct ipt_ID_info *) target->data; printf("ID "); switch (info->mode) { case IPT_ID_SET: printf("set to "); break; case IPT_ID_DEC: printf("decrement by "); break; case IPT_ID_INC: printf("increment by "); break; } printf("%u ", info->id); } static const struct option ID_opts[] = { { "id-set", 1, NULL, '1' }, { "id-inc", 1, NULL, '2' }, { .name = NULL } }; static struct xtables_target id_tg_reg = { .name = "ID", .version = XTABLES_VERSION, .family = NFPROTO_IPV4, .size = XT_ALIGN(sizeof(struct ipt_ID_info)), .userspacesize = XT_ALIGN(sizeof(struct ipt_ID_info)), .help = ID_help, .parse = ID_parse, .final_check = ID_check, .print = ID_print, .save = ID_save, .extra_opts = ID_opts, }; void _init(void) { xtables_register_target(&id_tg_reg); } Далее скопируем файл ipt_ID.h в iptables-1.4.4/include/linux/netfilter_ipv4/ и файл libipt_ID.c в iptables-1.4.4/extensions/ теперь скомпилируем iptables и скопируем файл iptables-1.4.4/extensions/libipt_ID.so в /lib/xtables/ Теперь можно создавать цепочки в iptables пример: iptables -t mangle -A POSTROUTING -j ID --id-rand 1 Будет выдавть всем пакетам случайные ID (единица в конце ничего не обозначает просто я не доделал модуль) iptables -t mangle -A POSTROUTING -j ID --id-inc 1 Будет пакетам направленным на один IP присваивать ID постоянно увеличивая на единицу, может хранить в памяти пять таких цепочек (количество цепочек можно увеличить) P.S. Если кого интересует данная тема, то я доделаю статью и допишу модуль, просто пока всё работает и так не хочется ничего переделывать, но если нужно сделаю.   Совместное использование SELinux и iptables (доп. ссылка 1)   [комментарии]   Используя утилиту Secmark можно организовать назначение в правилах iptables SELinux-меток для сетевых пакетов, примерно также как осуществляется назначение меток для локальных системных ресурсов. Подобное может использоваться для предотвращения доступа сторонних процессов, не находящихся под контролем SELinux, к определенному классу пакетов. Например, можно указать что запросы на 80 порт (метка http_packet_t) может отправлять только определенный web-браузер (или процесс, имеющий SELinux-метку http_t) и никто иной. По умолчанию все сетевые пакеты снабжаются меткой unlabeled_t, а для всех подконтрольных процессов активируется правило, без ограничений разрешающее отправку и прием пакетов: allow MYDOMAIN unlabed_t:packet { send recv }; При назначении меток для трафика при помощи Secmark разрешительная политика по отношению к unlabed_t может привести к тому, что в случае отключения пакетного фильтра или в момент его перезапуска, правила блокирования будут временно проигнорированы. Попытаемся отключить автоматическую установку метки unlabeled_t, которая назначается в Fedora Linux через SELinux-модуль unlabelednet. Если отключить данный набор SELinux-политик, то все подконтрольные SELinux приложения потеряют возможность отправлять и принимать пакеты с меткой unlabeled_t. Чтобы вернуть таким программам возможность работы в сети для них необходимо подготовить соответствующие SELinux-правила и пометить пакеты. Для усиления защиты ноутбука было решено подготовить простые SELinux-политики, запрещающие обращаться к внешним сетевым ресурсам всем системным сервисам, ограниченным при помощи SELinux. Всем программ, запущенные в рамках сессии пользователя, разрешено обращаться как ко внутренним, так и к внешним сетевым ресурсам. Подготовлено три политики доступа к сети: internal_packet_t: Iptables помечает меткой internal_packet_t все пакеты, отправленные в локальную сеть или приходящие на текущую машину из локальной сети; dns_external_packet_t: Iptables помечает меткой dns_external_packet_t все внешние обращения к DNS-серверам (udp/tcp порт 53); external_packet_t: Iptables помечает меткой external_packet_t все остальные пакеты, не подпадающие под первые два правила; Для упрощения генерации iptables-правил для назначения SELinux-меток был создан скрипт secmarkgen: #!/bin/sh -e init() { # This just tells iptables to apply the same label to incoming packets as it did on outgoing echo $IPTABLES -F -t security echo $IPTABLES -t security -A INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --restore # Apply a label even if its on another port but is related echo $IPTABLES -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --restore echo return } start() { # Create a chain for each class of packets we have. echo "$IPTABLES -t security -X $NAME 2> /dev/null" echo "$IPTABLES -t security -N $NAME" } fini() { # Label all other packets going internally to $TYPE:$MCS echo $IPTABLES -t security -A $NAME -j SECMARK --selctx system_u:object_r:$TYPE:$MCS echo $IPTABLES -t security -A $NAME -j CONNSECMARK --save echo $IPTABLES -t security -A $NAME -j ACCEPT echo } setup_network() { if [ ! -z "$PORTS" ]; then if [ ! -z "$NETWORK" ]; then # Send packets going to an $NET httpd to the $NAME chain echo $IPTABLES -A OUTPUT -t security -p $PROTOCOL -d $NETWORK --dport $PORTS -j $NAME echo $IPTABLES -A INPUT -t security -p $PROTOCOL -d $NETWORK --sport $PORTS -j $NAME else # Send packets going to $PORTS httpd to the $NAME chain echo $IPTABLES -A OUTPUT -t security -p $PROTOCOL --dport $PORTS -j $NAME echo $IPTABLES -A INPUT -t security -p $PROTOCOL --sport $PORTS -j $NAME fi elif [ ! -z "$NETWORK" ]; then # Send packets going to $PORT httpd to the $NAME chain echo $IPTABLES -A OUTPUT -t security -d $NETWORK -j $NAME echo $IPTABLES -A INPUT -t security -s $NETWORK -j $NAME else echo $IPTABLES -A OUTPUT -t security -j $NAME echo $IPTABLES -A INPUT -t security -j $NAME fi } usage() { $""" Usage: $0 -i Usage: $0 -T iptablescmd -P protocol -p port[:...] -N network[,...] -t selinux_type -m MCS NAME Usage: $0 -f NAME """ } echo echo "#---------------" echo "# $0 $*" echo "#---------------" echo IPTABLES=iptables NAME= PORTS= MCS=s0 NETWORK= TYPE=client_packet_t PROTOCOL=tcp FINISH=0 START=0 INIT=0 while getopts "sfin:p:m:t:T:P:" i; do case "$i" in i) INIT=1 ;; s) START=1 ;; f) FINISH=1 ;; P) PROTOCOL=$OPTARG ;; T) IPTABLES=$OPTARG ;; n) export NETWORK=$OPTARG ;; t) export TYPE=$OPTARG ;; p) export PORTS=$OPTARG ;; m) export MCS=$OPTARG ;; *) usage exit 1 esac done # Init does not require a NAME if [ $INIT == 1 ]; then init exit $? fi # Move out processed options from arguments shift $(( OPTIND - 1 )) NAME=$1 if [ -z "$NAME" -o -z "$MCS" -o -z "$NAME" ]; then usage exit 1 fi if [ $START == 1 ]; then start exit $? fi if [ $FINISH == 1 ]; then fini exit $? fi setup_network Скрипт можно запускать со следующими параметрами: Инициализируем secmark-метки: ./secmarkgen -i Определяем имя сети (имя Iptables-цепочки): ./secmarkgen -s INTERNAL Привязываем к созданной цепочке набор правил. Синтаксис команды: ./secmarkgen -T iptablescmd -P protocol -p port[:...] -N network[,...] -t selinux_type -m MCS NAME Например: ./secmarkgen -n 255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 INTERNAL Для завершения формирования secmark-правил и их привязки к определенной SELinux-метке используется команда: ./secmarkgen -f NAME Например, ./secmarkgen -f -t internal_packet_t INTERNAL в итоге будет сгенерирован примерно такой скрипт: #-------------------- # ./secmarkgen -i #-------------------- iptables -F -t security iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --restore iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --restore #-------------------- # ./secmarkgen -s INTERNAL #-------------------- iptables -t security -X INTERNAL 2> /dev/null iptables -t security -N INTERNAL #-------------------- # ./secmarkgen -n 255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 INTERNAL #-------------------- iptables -A OUTPUT -t security -d 255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 -j INTERNAL iptables -A INPUT -t security -s 255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 -j INTERNAL #-------------------- # ./secmarkgen -f -t internal_packet_t INTERNAL #-------------------- iptables -t security -A INTERNAL -j SECMARK --selctx system_u:object_r:internal_packet_t:s0 iptables -t security -A INTERNAL -j CONNSECMARK --save iptables -t security -A INTERNAL -j ACCEPT Для генерации iptables-правил для локальных приложений используется примерно такой скрипт (secmark_test.sh): ./secmarkgen -i ./secmarkgen -s INTERNAL ./secmarkgen -n 255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 INTERNAL ./secmarkgen -f -t internal_packet_t INTERNAL ./secmarkgen -s DNS ./secmarkgen -P udp -p 53 DNS ./secmarkgen -P tcp -p 53 DNS ./secmarkgen -f -t dns_external_packet_t DNS ./secmarkgen -s EXTERNAL ./secmarkgen EXTERNAL ./secmarkgen -f -t external_packet_t EXTERNAL ./secmarkgen -T ip6tables -i ./secmarkgen -T ip6tables -s INTERNAL ./secmarkgen -T ip6tables -n FEC0::/10,::1/128,FF::/8,FE80::/10FC00::/7 INTERNAL ./secmarkgen -T ip6tables -f -t internal_packet_t INTERNAL ./secmarkgen -T ip6tables -s EXTERNAL ./secmarkgen -T ip6tables EXTERNAL ./secmarkgen -T ip6tables -f -t external_packet_t EXTERNAL Генерируем соответствующие iptables-правила: ./secmark_test.sh > /tmp/rules Устанавливать данные iptables-правила пока рано, вначале нужно определить соответствующие указанным меткам (*_packet_t) SELinux-политики, без которых использование данных меток в iptables приведет к выводу ошибки. Формируем файл с SELinux-политиками (secmark.te): policy_module(secmark, 1.0) gen_require(' attribute domain; attribute sysadm_usertype; # Domains that a staff user could transition to attribute staff_usertype; attribute telepathy_domain; type ping_t; type vpnc_t; type ssh_t; type nsplugin_t; type mozilla_plugin_t; # System domains that want to talk to the external network type ntpd_t; type sssd_t; ') # Type Definitions attribute external_packet; type internal_packet_t; corenet_packet(internal_packet_t) type dns_external_packet_t, external_packet; corenet_packet(dns_external_packet_t) type external_packet_t, external_packet; corenet_packet(external_packet_t) # Allow Rules allow domain internal_packet_t:packet { recv send }; allow sysadm_usertype external_packet:packet { recv send }; allow staff_usertype external_packet:packet { recv send }; allow vpnc_t external_packet:packet { recv send }; allow ssh_t external_packet:packet { recv send }; allow mozilla_plugin_t external_packet:packet { recv send }; allow nsplugin_t external_packet:packet { recv send }; allow telepathy_domain external_packet:packet { recv send }; allow ping_t external_packet:packet { recv send }; allow ntpd_t external_packet:packet { recv send }; dontaudit sssd_t dns_external_packet_t:packet { recv send }; Рассмотрим правила более подробно. Строка policy_module(secmark, 1.0) определяет имя модуля с политиками. Далее следует список требований gen_require(' attribute domain; ... type sssd_t; ') При написании SELinux-политики необходимо сослаться на все типы и атрибуты, чтобы их можно было использовать в правилах. Подобные ссылки указываются в блоке gen_requires. Одновременно можно определить новые типы. Если один из определенных в gen_requires атрибутов или типов будет не определен в других частях правил, SELinux не активирует созданную политику. Например, атрибут staff_usertype предоставляется всем обслуживающим пользовательским процессам, sysadm_usertype присваивается всем процессам, используемым при администрировании, домен telepathy_domain охватывает все приложения, связанные с фреймворком telepathy. Далее, в файле следуют правила определения типов и групп. Создаем атрибут external_packet для группировки всех правил, связанных с внешним трафиком. Также создаем интерфейс corenet_packet для ассоциации набора правил с пакетами. attribute external_packet; type internal_packet_t; corenet_packet(internal_packet_t) type dns_external_packet_t, external_packet; corenet_packet(dns_external_packet_t) type external_packet_t, external_packet; corenet_packet(external_packet_t) Далее указано правило, разрешающее всем процессам отправку и прием внутренних пакетов из локальной сети: allow domain internal_packet_t:packet { recv send }; Следующее правило позволяет запускаемым администраторами программам отправлять и принимать пакеты из внешних сетей (вместо указания xternal_packet_t в правиле фигурирует атрибут external_packet, который позволяет провести действие сразу над группой - external_packet_t и dns_external_packet_t): allow sysadm_usertype external_packet:packet { recv send }; allow staff_usertype external_packet:packet { recv send }; allow vpnc_t external_packet:packet { recv send }; allow ssh_t external_packet:packet { recv send }; allow mozilla_plugin_t external_packet:packet { recv send }; allow nsplugin_t external_packet:packet { recv send }; allow telepathy_domain external_packet:packet { recv send }; allow ping_t external_packet:packet { recv send }; Для сервиса ntpd заведен отдельный тип ntp_external_packet_t: allow ntpd_t external_packet:packet { recv send }; Для программы sssd запрещаем общение с системами за пределами приватной сети: dontaudit sssd_t dns_external_packet_t:packet { recv send }; Теперь приступим к компиляции, установке и применению созданной SELinux-политики: Компилируем: make -f /usr/share/selinux/devel/Makefile Устанавливаем: semodule -i secmark.pp Активируем iptables-правила: sh /tmp/rules Сохраняем внесенные изменения: service iptables save service ip6tables save С этого момента каждому сетевому пакету присваивается одна из трех созданных SELinux-меток. Для отладки следует проследить за появлением avc-сообщений и при необходимости добавить исключения с использованием правил allow/dontaudit или расследовать причину появления непрошеного трафика.   Простой интерактивный firewall в Linux   Автор: tux2002  [комментарии]   Недавно на форуме спрашивали есть ли интерактивный firewall в Linux и многие отвечали, что нет. Ниже простая заготовка скрипта, следящего за событиями в логе, в случае подозрительной активности выводящего пользователю окно с предложением блокирования трафика или игнорирования предупреждения. 1. Первоначальные настройки iptables: #iptables-save # Generated by iptables-save v1.4.7 on Fri Mar 11 15:15:29 2011 *filter :INPUT DROP [137:16764] :FORWARD DROP [0:0] :OUTPUT DROP [10:708] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -j LOG --log-prefix "firewall-INPUT " -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j LOG --log-prefix "firewall-FORWARD " -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j LOG --log-prefix "firewall-OUTPUT " COMMIT # Completed on Fri Mar 11 15:15:29 2011 # Generated by iptables-save v1.4.7 on Fri Mar 11 15:15:29 2011 *nat :PREROUTING ACCEPT [48:6290] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [6:396] COMMIT # Completed on Fri Mar 11 15:15:29 2011 Правила по умолчанию в цепочках можно изменить на ваш вкус. Основной сценарий будем запускать от рядового пользователя, поэтому ему требуется право на чтение /var/log/syslog (или куда у Вас попадает журнал netfilter). Также пользователю требуется право заполнять правила netfilter командой iptables. У меня это сделано через /etc/sudoers 2. Основной сценарий обработки журнала netfilter: interactive-firewall.sh while read line do echo $line | grep firewall > /dev/null 2>&1 [ $? != 0 ] && continue for item in $line do case $item in firewall-*) CHAIN=$item;; PROTO=*) PROTO=$item;; SRC=*) SRC=$item;; SPT=*) SPT=$item;; DST=*) DST=$item;; DPT=*) DPT=$item;; esac done CHAIN=${CHAIN#firewall-} PROTO=${PROTO#PROTO=} PROTO=${PROTO,,} SRC=${SRC#SRC=} SPT=${SPT#SPT=} DST=${DST#DST=} DPT=${DPT#DPT=} ACTION=`LANG=C xmessage -buttons ACCEPT,DROP,SKIP -default SKIP -timeout 15 -print "$SRC => $DST:$DPT"` ACTION=${ACTION:-"SKIP"} case $ACTION in SKIP) continue;; ACCEPT) sudo iptables -I $CHAIN 2 -s $SRC -d $DST -p $PROTO --dport $DPT -j ACCEPT;; DROP) sudo iptables -I $CHAIN 2 -s $SRC -d $DST -p $PROTO --dport $DPT -j DROP;; esac sleep 1 3. Запускаем firewall tail -f /var/log/syslog | ./interactive-firewall.sh 4. Что можно улучшить. В этом варианте правила имеют вид SRC => DST:PORT -j ACTION. Исходный порт соединения понятно пропускается. Хорошо бы предоставлять выбор пользователю из нескольких вариантов, но xmessage для этого маловато. Может у кого есть предложения чем рисовать вопрос пользователю и обрабатывать его выбор? По желанию сценарий можно доработать и отображать в xmessage не голые цифры, а расшифровать их в имена компьютеров командой host, а протоколы по /etc/services. Кроме модификации сценария потребуется так же разрешить первоначально DNS трафик resolver'а в первоначальной конфигурации netfilter. 5. Эта заметка ни на что не претендует, просто идея и простой набросок.   Установка ipfw и dummynet в Linux и Windows (доп. ссылка 1)   [комментарии]   Не многие знают о том, что классический пакетный фильтр FreeBSD ipfw и система ограничения пропускной способности dummynet были успешно портированы в Linux и Windows. В Ubuntu для сборки могут потребоваться пакеты: $ sudo apt-get install build-essential linux-source linux-headers-$(uname -r) Собираем ipfw и dummynet в Linux: $ wget http://info.iet.unipi.it/~luigi/dummynet/20100319-ipfw3.tgz $ tar xzf 20100319-ipfw3.tgz -C ~/src $ cd ~/src/ipfw3 $ make Загружаем модуль Linux-ядра: $ sudo insmod ./dummynet2/ipfw_mod.ko $ lsmod| grep ipfw ipfw_mod 86695 0 Проверяем работу утилиты: $ sudo ipfw/ipfw show 65535 54 6340 allow ip from any to any $ sudo ipfw/ipfw 10 add deny ip from 192.168.100.100 to any 00010 deny ip from 192.168.100.100 to any $ sudo ipfw/ipfw show 00010 1 84 deny ip from 192.168.100.100 to any 65535 121 22335 allow ip from any to any Для Windows достаточно загрузить со страницы http://info.iet.unipi.it/~luigi/dummynet/ готовые исполняемые файлы. Для установки драйвера в панели конфигурации сетевой карты ( Control Panel -> Network -> карта) перейти в Properties->Install->Service->Add, выбрать 'Driver Disk' и указать на файл 'netipfw.inf', после чего выбрать 'ipfw+dummynet'.   Round Robin балансирование IP адресов исходящих соединений средствами iptables (доп. ссылка 1)   Автор: Stanislav S. Osipov  [комментарии]   Данное решение отличается изящностью, так как реализует все средствами iptables. Синтаксис: на машине, которая должна балансировать исходящие соединения, выполнить скрипт balancer.sh: sh ./balancer.sh Выключить балансер: sh ./balancer.sh off Замечание: При работе создается временный файл ~/balancer-rules.sav, используемый для уборки за собой при выключении балансера. balancer.sh #!/bin/bash # Written by Stanislav S. Osipov, [email protected] # Created 2010.08.08 # Script makes SNAT round robin balancing for connections between all real IPA of this host # # OpenVZ guest warning: you must allow the next options: # IPTABLES="ip_tables iptable_filter iptable_mangle iptable_nat ip_conntrack ipt_conntrack ipt_state" myips=`/sbin/ifconfig | /bin/grep "inet a" | /usr/bin/awk "{print \\$2}" | /usr/bin/cut -d: -f2 | /bin/grep -v "^127\.\|^10\.\|^192\.168\.\|^172\.\([12][0-9]\|3[01]\)\."` myipscount=`/sbin/ifconfig | /bin/grep "inet a" | /usr/bin/awk "{print \\$2}" | /usr/bin/cut -d: -f2 | /bin/grep -v "^127\.\|^10\.\|^192\.168\.\|^172\.\([12][0-9]\|3[01]\)\." | /usr/bin/wc -l` if [ $myipscount -lt 2 ] && [ "$1" != "off" ] then /bin/echo "you have not enough IPAs for balancing" /bin/echo "I have $myipscount IPAs:" /bin/echo $myips exit 0 fi #for connections, initiated from this host chain="OUTPUT" #for connections, initiated by other hosts, which go through this host #chain="FORWARD" /bin/echo "Cleaning old balancer iptables rules..." if [ -e ~/balancer-rules.sav ] then /bin/cat ~/balancer-rules.sav | /bin/bash /bin/echo > ~/balancer-rules.sav else /bin/echo "No previously dumped rules was found." fi /bin/echo "Cleaning was done." if [ "$1" == "off" ] then if [ -e ~/balancer-rules.sav ] then rm ~/balancer-rules.sav fi exit 0 fi /bin/echo "I have $myipscount IPAs: $myips Generating and writing mangle table mark logic rules..." i=1 while [ $i -le $myipscount ] do RULE1="/sbin/iptables -t mangle -A $chain -j CONNMARK --set-mark $i" RULE2="/sbin/iptables -t mangle -A $chain -m statistic --mode nth --every $((myipscount-i+1)) -j RETURN" /bin/echo $RULE1 $RULE1 /bin/echo $RULE2 $RULE2 /bin/echo $RULE1 | /bin/sed -e "s# -A # -D #" >> ~/balancer-rules.sav /bin/echo $RULE2 | /bin/sed -e "s# -A # -D #" >> ~/balancer-rules.sav ((i++)) done /bin/echo "...mangle table mark rules was done." /bin/echo "Writing SNAT mark based rules:" i=1 for ip in $myips do RULE="/sbin/iptables -t nat -A POSTROUTING -m connmark --mark $i -j SNAT --to $ip" /bin/echo $RULE $RULE /bin/echo $RULE | /bin/sed -e "s# -A # -D #" >> ~/balancer-rules.sav ((i++)) done /bin/echo "...nat table SNAT rules was done. Round robin balancer is turned on. Thank you for using this script written by Stanislav S. Osipov!" Как проверить Создать файл в DocumentRoot на какой-нить машине с апачом такого вида: `ip.php`: <? echo $_SERVER['REMOTE_ADDR']."\n"; ?> И запустить такой тест с машины, которая работает с правилами балансера (для успешного теста на машине должна стоять библиотека libwww-perl): i=1; count=20; url="http://my.www.ru/ip.php"; while [ $i -lt $count ]; do GET "$url"; ((i++)); done Как выглядит в работе root@h1:~# i=1; count=10; url="http://my.www.ru/ip.php"; while [ $i -lt $count ]; do GET "$url"; ((i++)); done 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 root@h1:~# ./balancer.sh Cleaning old balancer iptables rules... No previously dumped rules was found. Cleaning was done. I have 3 IPAs: 95.239.178.214 95.239.178.220 95.239.178.221 Generating and writing mangle table mark logic rules... /sbin/iptables -t mangle -A OUTPUT -j CONNMARK --set-mark 1 /sbin/iptables -t mangle -A OUTPUT -m statistic --mode nth --every 3 -j RETURN /sbin/iptables -t mangle -A OUTPUT -j CONNMARK --set-mark 2 /sbin/iptables -t mangle -A OUTPUT -m statistic --mode nth --every 2 -j RETURN /sbin/iptables -t mangle -A OUTPUT -j CONNMARK --set-mark 3 /sbin/iptables -t mangle -A OUTPUT -m statistic --mode nth --every 1 -j RETURN ...mangle table mark rules was done. Writing SNAT mark based rules: /sbin/iptables -t nat -A POSTROUTING -m connmark --mark 1 -j SNAT --to 95.239.178.214 /sbin/iptables -t nat -A POSTROUTING -m connmark --mark 2 -j SNAT --to 95.239.178.220 /sbin/iptables -t nat -A POSTROUTING -m connmark --mark 3 -j SNAT --to 95.239.178.221 ...nat table SNAT rules was done. Round robin balancer is turned on. Thank you for using this script written by Stanislav S. Osipov! root@h1:~# i=1; count=10; url="http://my.www.ru/ip.php"; while [ $i -lt $count ]; do GET "$url"; ((i++)); done 95.239.178.214 95.239.178.221 95.239.178.220 95.239.178.214 95.239.178.221 95.239.178.220 95.239.178.214 95.239.178.221 95.239.178.220 root@h1:~# ./balancer.sh off Cleaning old balancer iptables rules... Cleaning was done. root@h1:~# i=1; count=10; url="http://my.www.ru/ip.php"; while [ $i -lt $count ]; do GET "$url"; ((i++)); done 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214 95.239.178.214   Защита от bruteforce средствами iptables (доп. ссылка 1)   Автор: Владимир  [комментарии]   В заметке приведены различные варианты защиты от bruteforce-атак, на примере блокирования последовательного подбора паролей через ssh. Общий шаблон правил iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -p all -i lo -j ACCEPT iptables -A OUTPUT -p all -o lo -j ACCEPT Здесь будут наши правила (вариант) iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Вариант 1, используя модуль recent: Добавляем ip в таблицу iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name BLOCK -set С одного ip разрешаем 2 (--hitcount 3-1) запроса на соединение (NEW) в минуту (60 секунд), третье блокируется и все последующие в течение минуты iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name BLOCK --update --seconds 60 --rttl --hitcount 3 -j DROP Разрешаем входящие соединения на 22 порт iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT Вариант 2, используя модуль hashlimit: С одного ip разрешаем 2 запроса на соединение (NEW) в минуту (2/m) все остальные пакеты (NEW) c этого ip блокируется iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m hashlimit \ --hashlimit-name BLOCK --hashlimit-mode srcip --hashlimit-above 2/m --hashlimit-burst 2 -j DROP Разрешаем входящие соединения на 22 порт iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT Вариант 3, используя модули connlimit, limit: С одного ip разрешаем не больше одно соединения (! --connlimit-above 1) на 22 порт, пропускаем 2 пакета в минуту с запросом на соединение (NEW), все остальные пакеты (NEW) c этого ip блокируется iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m connlimit ! \ --connlimit-above 1 -m limit --limit 2/m --limit-burst 2 -j ACCEPT Вариант 4, параноидальный: Два раза в течение минуты разрешено подключаться к 22 порту, при превышении порога ip блокируется на 10 минут. блокируем ip с запросом на соединение (NEW) попавшие в динамически обновляемую таблицу на 600 секунд iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name BLOCK --rcheck --seconds 600 -j DROP С одного ip разрешаем 2 запроса на соединение (NEW) в минуту (2/m), если превышен порог,то добавляем ip в таблицу BLOCK для блокировки на 600 секунд (10 минут) iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m hashlimit \ --hashlimit-name BLOCK --hashlimit-mode srcip --hashlimit-above 2/m --hashlimit-burst 2 -m recent --name BLOCK --set -j DROP Разрешаем входящие соединения на 22 порт iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT   Защита от спамерских и bruteforce-атак с помощью iptables   Автор: Забудкин Лев Мирославович  [комментарии]   Сохраняем в файл скрипт: #!/bin/sh # Защита от спамовских атак и от BRUTE-атак с помощью IPTABLES # REJECT_BRUTERS v.1.0 Lev Zabudkin. [email protected]. http://zabudkin.ru # 23.03.2010 # # Описание: # Данный скрипт позволяет Вам, используя iptables заблокировать # дальнейшие попытки соединения от надоедливых хостов, # которые пытались приконнектиться в течении определенного Вами времени # и определенное Вами количество раз. # # Итак поехали: # # Мы создаём ниже переменную IPTABLES, дабы не указывать постоянно где он лежит # Где у Вас лежит iptables? (подсказка: # whereis iptables) IPTABLES="/sbin/iptables" # На каком сетевом интерфейсе контролировать коннекты CHECK_INT="ppp0" # Сколько именно коннектов Вы разрешаете с одного хоста? # В данном случае указано 2, чего вполне достаточно для SMTP. MAXIMUM_CONNECTIONS_PER_PERIOD=2 # А в течение скольки секунд они разрешены? PERIOD_SECONDS=60 # Пояснение: Если в течении Выше указанных секунд хост (в данном примере любой(!)) # попытается приконнектиться к Вам, то соединение будет отброшено (см. -j DROP) # причем НАВСЕГДА, т.е ДО ТЕХ ПОР, пока Вы не обнулите цепочку BRUTE_CHECK # ключём -F BRUTE_CHECK команды iptables # Создаём цепочку BRUTE_CHECK $IPTABLES -N BRUTE_CHECK # Обнуляем правила цепочки BRUTE_CHECK $IPTABLES -F BRUTE_CHECK # В данном случае мы удаляем ранее сделанное "перенаправление" (см. чуть ниже) # чтобы этот скрипт можно было вызывать многократно $IPTABLES -D INPUT -j BRUTE_CHECK # В данном случае мы "перенаправляем" для обработки входящие пакеты # в нашу созданную цепочку $IPTABLES -A INPUT -j BRUTE_CHECK # А тут уже пошли наши правила, которые гласят: # все входящие пакеты на сетевой интерфейс (мы его указали выше), # которые являются для нас новыми (см. state) и которые соответствуют нашим # параметрам (см. выше), мы отбрасываем. $IPTABLES -A BRUTE_CHECK -i $CHECK_INT -p tcp -m state --state NEW -m recent --set --name BRUTE # См. Ниже Пояснение, если понадобится, то раскоментируете нижеприведенную строку # (просто уберите символ решетки - #) #$IPTABLES -A BRUTE_CHECK -i $CHECK_INT -p tcp -m state --state NEW -m recent --update --seconds $PERIOD_SECONDS \ # --hitcount $MAXIMUM_CONNECTIONS_PER_PERIOD --rttl --name BRUTE -j LOG --log-level 4 --log-prefix '** BRUTE **' $IPTABLES -A BRUTE_CHECK -i $CHECK_INT -p tcp -m state --state NEW -m recent --update --seconds $PERIOD_SECONDS \ --hitcount $MAXIMUM_CONNECTIONS_PER_PERIOD --rttl --name BRUTE -j DROP Пояснение: Для того, чтобы видеть, каких же успехов Вы добились, применив выше написанное, проделайте следующее: откройте файл /etc/syslog.conf и добавьте в конец строку: kern.warning /var/log/iptables.log затем перезапустите syslog: /etc/init.d/syslog restart (если у Вас Ubuntu, то наверное это sysklogd) События (про попытки) будут записываться в файл /var/log/iptables.log, его и смотрите. Да, и будет не лишним добавить данный скрипт в CRON (/etc/crontab), скажем каждые 5 минут: */5 * * * * root Путь/ВашСкрипт   Защищаем http-proxy от пробрасывания http-туннеля средствами iptables (доп. ссылка 1)   Автор: Владимир   [комментарии]   При пробрасывании http-туннеля через http-прокси, http-заголовок пакета имеет аномально маленький размер, порядка 80-90 байт, так как передается лишь минимальный набор данных. Заголовок передаваемых браузером запросов обычно не бывает меньше 350 байт. Основываясь на данной особенности можно отфильтровать проброшенных поверх http-прокси туннели. # политика по умолчанию iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # создаём новую цепочку LENGTH iptables -N LENGTH # проверяем длину пакета, если меньше 350 байт то блокируем iptables -A LENGTH -p tcp --dport 3128 -m length --length :350 -j DROP # если пакет больше 350 байт то пропускаем iptables -A LENGTH -p tcp --dport 3128 -j ACCEPT # разрешаем подключение на порт 3128 iptables -A INPUT -p tcp --syn --dport 3128 -j ACCEPT # в установленом соединении проверяем пакеты на запрос GET --hex- string "|47 45 54 20|" # если есть такой пакет то направляем его в цепочку LENGTH для проверки длины пакета iptables -A INPUT -p tcp --dport 3128 -m state --state ESTABLISHED -m string --algo kmp \ --hex-string "|47 45 54 20|" --from 52 --to 56 -j LENGTH iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Представленный пример опробован на httptunnel   Настройка ufw в Ubuntu (доп. ссылка 1)   Автор: Eugene Shelepov  [комментарии]   Начиная с версии Ubuntu 8.04 в ее состав по умолчанию включена новая упрощенная оболочка для работы с файрволом - ufw (Uncomplicated firewall - "незамысловатый" брэндмауер). Как известно Linux по умолчанию имеет очень мощный встроенный сетевой фильтр - netfilter. Стандартной утилитой для управления настройками netfilter является утилита iptables. Ufw создан для того чтобы сделать более простым настройку netfilter-а. По сути ufw - это скрипт, который получает команды в одном формате и преобразует их в формат iptables. Так как ufw является упрощенной утилитой настройки файрвола, он так же является и более ограниченным в своих возможностях по сравнению с iptables. Практика показывает что большинству пользователей вполне достаточно функционала который предоставляет ufw. В то же время, в случае необходимости всегда можно дописать нужное правило с помощью iptables. Функционал ufw Основными функциями файрвола ufw является: 1. Работа в одном из двух режимов: разрешено все кроме того что описано правилами, запрещено все, кроме описанного правилами. 2. Создание правил для фильтрации пакетов с действиями allow, deny, reject 3. Создание правил с учетом адреса и порта получателя и отправителя, используемого протокола 4. Логирование пакетов подпадающих под правило 5. Блокировка частых неправильных попыток авторизации по ssh 6. Настраиваемые профили для приложений Запуск ufw Ufw может быть включен или выключен системным администратором сервера, для этого используется команд: # ufw enable Межсетевой экран активен и будет запущен при запуске системы # ufw disable Файрвол остановлен и деактивирован при загрузке Просматривать состояние можно с помощью команды: # ufw status [numbered] Status: active Параметр numbered может быть использован для отображения правил файрвола с соответствующей нумерацией. Изменение политики по умолчания: # ufw default allow [in|out] # ufw default deny [in|out] # ufw default reject [in|out] Где allow подразумевает что все пакеты будут пропущены, кроме тех, для которых есть запрещающее правило: deny - все пакеты будут заблокированы, кроме тех, для которых есть разрешающие правила; reject - все пакеты будут заблокированы с соответствующим уведомлением подключающуюся сторону. Параметры in|out указывают для какого направления мы хотим применять политику, для входящих или исходящих пакетов соответственно. Управление правилами осуществляется с помощью команд allow, deny, reject, delete, insert. allow - добавить разрешающее правило deny - добавить запрещающее правило (файрвол не предпринимает действий при попадании в это правило) reject - добавить запрещающее правило (файрвол даст знать подключающемуся что этот порт закрыт) limit - добавляет ограничивающее правило для указанного порта. В случае если с одного и того же адреса в течении 30 секунд будет произведено 6 и более неуспешных попыток авторизации в службу удаленного доступа ssh, ufw заблокирует удаленный адрес. delete - удалить добавленное ранее правило insert - вставить правило в определенную позицию в цепочке Построение правил файрвола Конструкция построения правил ufw allow|deny|reject|limit [in|out on INTERFACE] [log|log-all] [proto protocol] \ [from ADDRESS [port PORT]] [to ADDRESS [port PORT]] Подробнее о параметрах: allow|deny|reject|limit - указываем что будет делать это правило (см. описание выше). [in|out on INTERFACE] - указываем будет это правило относится к входящему трафику (in) или исходящему (out) и хотим ли мы ограничить данное правило отдельным сетевым интерфейсом (к примеру eth0). [log|log-all] - при желании можно логировать события которые подпадают под правило. По умолчанию лог пишется в /var/log/syslog. При использовании опции log - в файл будут записаны лишь пакеты участвующие при установке соединения с сервером. Используя опцию log-all в лог файл будут записаны все пакеты подпадающие под правило. [proto protocol] - в правиле можно указать для какого протокола оно действует: tcp или udp. [from ADDRESS [port PORT]] - адрес и порт источника пакета [to ADDRESS [port PORT]] - адрес и порт получателя пакета Профили приложений Ufw позволяет создавать профили приложений. в которых можно указать все порты которые используются и удобно добавлять их в правила. Так к примеру можно создать профиль для веб-сервера Apache, указав что слушает он 80 и 443 порты по протоколу tcp. Профили приложений являются текстовыми файлами и могут быть отредактированы любым текстовым редактором. все файлы хранятся в директории /etc/ufw/applications.d: root@server:/etc/ufw/applications.d# pwd /etc/ufw/applications.d root@server:/etc/ufw/applications.d# ls -l -rw-r--r-- 1 root root 406 2009-11-13 00:52 apache2.2-common -rw-r--r-- 1 root root 145 2009-10-22 22:50 openssh-server -rw-r--r-- 1 root root 241 2009-09-22 16:52 postfix Рассмотрим пример профиля приложения apache2.2-common: [Apache] title=Web Server description=Apache v2 is the next generation of the omnipresent Apache web server. ports=80/tcp [Apache Secure] title=Web Server (HTTPS) description=Apache v2 is the next generation of the omnipresent Apache web server. ports=443/tcp [Apache Full] title=Web Server (HTTP,HTTPS) description=Apache v2 is the next generation of the omnipresent Apache web server. ports=80,443/tcp В одном файле может находится несколько профилей. В данном примере 3: Apache, Apache Secure, Apache Full. Структура записей проста: сначала имя профиля в квадратных скобка ([Apache Full]), далее развернутое наименования приложения, далее описание приложения и список портов с указанием протокола которые задействованы в профиле (80,443/tcp). Вывести список профилей можно с помощью команды: # ufw app list Доступные приложения: Apache Apache Full Apache Secure OpenSSH Postfix Postfix Submission Детальную информацию по профилю можно просмотреть с помощью команды: # ufw app info OpenSSH |Профиль: OpenSSH |Название: Secure shell server, an rshd replacement |Описание: OpenSSH is a free implementation of the Secure Shell protocol. |Порт: 22/tcp После добавления или изменения профиля приложения (в файле) необходимо дать знать файрволу о новом профиле: # ufw app update OpenSSH Для того чтобы новый профиль сразу вступил в силу, необходимо добавить опцию --add-new: # ufw app update --add-new OpenSSH По умолчанию добавленные с помощью --add-new профили не будут обрабатываться файрволом. Рекомендуется вначале задать политику для новых профилей приложений: ufw app default allow|deny После чего все новые профили приложений будут добавляться в цепочку файрвола с указанной политикой. Использовать профили приложений можно также при создании обычных правил, например: # ufw allow OpenSSH Настройка профиля безопасности 1. Ограничение входящих подключений к FTP и Веб серверу Пример настройки файрвола для ситуации, когда необходимо заблокировать доступ к FTP и Веб серверу с адреса 192.168.100.100. В примере 192.168.1.11 - сервер на котором настраивается файрвол: # ufw deny proto tcp from 192.168.100.100 to 192.168.1.11 port 21,80 Правило добавлено # ufw status |Статус: активно |До Действие От ---- -------------------- 192.168.1.11 21,80/tcp DENY 192.168.100.100 Теперь при попытках подключения с хоста 192.168.100.100 к 21 или 80 порту хоста 192.168.1.11 клиент будет висеть пока не отвалится по таймауту. Удалим это правило и добавить аналогичное но с действием reject: # ufw delete deny proto tcp from 192.168.100.100 to 192.168.1.11 port 21,80 # ufw reject proto tcp from 192.168.100.100 to 192.168.1.11 port 21,80 Теперь при попытке подключения к 21 порту сервера удаленный клиент получит ответ Connection refused: $ telnet 192.168.1.11 21 Trying 192.168.1.11... telnet: Unable to connect to remote host: Connection refused Просканируем порты сервера: # nmap -sT 192.168.1.100 Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-28 22:56 EET Interesting ports on 192.168.1.100: Not shown: 992 closed ports PORT STATE SERVICE 21/tcp filtered ftp 22/tcp open ssh 80/tcp filtered http 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2323/tcp open unknown 3128/tcp open squid-http 5900/tcp open vnc MAC Address: 00:18:F3:67:85:9E (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 17.52 seconds 2. Ограничение исходящих подключений к указанному серверу Цель - запретить исходящие подключения с сервера к адресу 195.214.195.105: # ufw deny proto tcp to 195.214.195.105 3. Ограничение попыток авторизации по ssh # ufw limit 22 Произведем несколько попыток подключения к 22 порту сервера с введением заведомо неправильного пароля: $ ssh 192.168.1.100 [email protected]'s password: Permission denied, please try again. ... $ ssh 192.168.1.100 ssh: connect to host 192.168.1.100 port 22: Connection refused Как видим после нескольких неудачных попыток файрвол блокирует IP адрес с которого исходят попытки подключения и в логах появится соответсвтующяя запись: Dec 28 22:59:13 fortress kernel: [273659.578463] [UFW LIMIT BLOCK] IN=eth0 OUT= MAC=00:18:f3:67:85:9e:00:26:5e:46:40:86:08:00 SRC=192.168.1.156 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3150 DF PROTO=TCP SPT=33783 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 4. Логирование пакетов # ufw allow log 22 С помощью этого правила файрвол будет логировать пакеты установки соединиения по указанному 22 порту. В логах появятся следующие записи: Dec 28 23:04:18 fortress kernel: [273964.364715] [UFW ALLOW] IN=eth0 OUT= MAC=00:18:f3:67:85:9e:00:26:5e:46:40:86:08:00 SRC=192.168.1.156 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6564 DF PROTO=TCP SPT=58069 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0   Защита от трассировки маршрутов с помощью iptables (доп. ссылка 1)   Автор: Владимир  [комментарии]   Для того, чтобы затруднить исследование сети (локальной, DMZ и т.д.) можно заблокировать все пакеты с низким значением TTL. Пример блокирования пакетов с TTL меньше 5: iptables -A INPUT -p all -m ttl --ttl-lt 5 -j DROP или iptables -A FORWARD -p all -m ttl --ttl-lt 5 -j DROP   Активное противодействие сканированию портов (доп. ссылка 1)   Автор: Владимир  [комментарии]   Имеется сервер на нем ssh и web. Ниже приведён простой пример правил для блокирования на определенное время IP, обратившегося по неактивному номеру порта. iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -p all -i lo -j ACCEPT iptables -A OUTPUT -p all -o lo -j ACCEPT # любой пакет идущий на не 22,80 порт блокируется с ip адресом отправившим его на 120 секунд, # на 120 секунд блокируется все пакеты с этого ip, тем самым предотвращается сканирование портов iptables -A INPUT -m recent --rcheck --seconds 120 --name FUCKOFF -j DROP iptables -A INPUT -p tcp -m multiport ! --dports 22,80 -m recent --set --name FUCKOFF -j DROP iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Теперь nmap -sV ip не выдаст ничего и если какой нибудь демон повесить на нестандартный порт, его будет не так просто обнаружить.   Защищаем SSH при помощи технологии "Port Knocking" (доп. ссылка 1) (доп. ссылка 2)   Автор: Дмитрий  [комментарии]   Реализация идеи динамического открытия доступа к 22 порту, при предварительном обращении telnet-ом на определенный сетевой порт (в примере 333 - открыть доступ и 334 - закрыть). Идея реализована средствами iptables, без привлечения дополнительных утилит и анализаторов логов. # Создаю цепочку с именем SSH iptables -N SSH # Правило по умолчанию в INPUT - DROP iptables -P INPUT DROP # Всё что пришло на 22 порт - в цепочку SSH iptables -A INPUT -p tcp --dport 22 -j SSH # Всё что пришло на 333 порт - в цепочку SSH iptables -A INPUT -p tcp --dport 333 -j SSH # Всё что пришло на 334 порт - в цепочку SSH iptables -A INPUT -p tcp --dport 334 -j SSH Разделения на цепочки сделано для своего удобства, от этого можно и отказаться. Теперь заполняем цепочку SSH. # Проверяем на наличие имени "SSH" у IP адреса устанавливающего соединение на 22 порт. # И если оно присутствует - то ACCEPT iptables -A SSH -p tcp -m state --state NEW -m tcp --dport 22 -m recent --rcheck --name SSH --rsource -j ACCEPT # Устанавливает имя SSH любому IP адресу с которого пришло новое TCP соединение на указанный порт. (порт 333) iptables -A SSH -p tcp -m state --state NEW -m tcp --dport 333 -m recent --set --name SSH --rsource -j DROP # Удаляет имя "SSH" с IP адреса установившего соединение на этот порт. (порт 334) iptables -A SSH -p tcp -m state --state NEW -m tcp --dport 334 -m recent --remove --name SSH --rsource -j DROP Насладимся итоговым результатом: Делаем: telnet ip_address_or_domain_name 333 После чего спокойно подключаемся по SSH. Когда прекращаем работу закрываем за собой 22 порт: telnet ip_address_or_domain_name 334   Методы сокрытия сервисов средствами iptables на примере sshd (доп. ссылка 1) (доп. ссылка 2)   Автор: Владимир  [комментарии]   Все действия в нижеизложенной статье выполнялись в debian 5, стандартными средствами. Методы предназначены для сокрытия сервисов. Ниже представлен простой шаблон правил: iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -p all -i lo -j ACCEPT iptables -A OUTPUT -p all -o lo -j ACCEPT ... ЗДЕСЬ НАШЕ ПРАВИЛО iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT 1. Использование нестандартного диапазона tcp портов при установлении исходящего соединения. Идея заключается в установлении нестандартных номеров портов (для исходящих соединений) на КЛИЕНТСКОЙ СТОРОНЕ и фильтрации фаерволом на сервере при установлении соединения по этим портам, тем самый делая наш sshd не видимым для всех и доступным для нас :) Реализуем идею на практике: По умолчанию диапазон портов в linux равен от 32768 до 61000 (значения в различных дистрибутивах могут отличатся) посмотреть установленные значения можно командой cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 изменяем на, к примеру 30000 32500 (на клиентской ОС linux) echo "30000 32500">/proc/sys/net/ipv4/ip_local_port_range правило будет выглядеть так: iptables -A INPUT -p tcp --syn --sport 30000:32500 --dport 22 -j ACCEPT Правило означает: входящие подключение по протоколу tcp с флагами:FIN,SYN,RST,ACK/SYN с диапазона портов 30000:32500 на порт 22 разрешить 2. Фильтрация на основе ttl (время жизни пакета) Здесь можно пойти несколькими путями: 1) Суть заключается в привязывании к числу маршрутизаторов, через которые проходит пакет (ttl уменьшается на 1 при прохождении маршрутизатора), а так как количество маршрутизаторов в разных сетях разное, то получаем значение ttl равное числу по умолчанию минус число пройденных маршрутизаторов. В данном варианте на клиентской ОС ничего менять не будем. Выполним трассировку до нашего сервера, затем от значения ttl по умолчанию отнимем количество хостов до нашего сервера (default ttl - traceroute) получим значение ttl по которому будем принимать пакеты на стороне сервера. В linux значение ttl по умолчанию равно 64, посмотреть можно командой cat /proc/sys/net/ipv4/ip_default_ttl 64 Пример: выполняем трассировку tcptraceroute ya.ru ... 9 ya.ru (93.158.134.8) [open] 556.844 ms 474.811 ms * Всего в пути встретилось 9 узлов, значит к серверу придёт пакет с ttl=55 (64-9=55) правило будет выглядеть так: iptables -A INPUT -p tcp --syn --dport 22 -m ttl --ttl-eq 55 -j ACCEPT Правило означает: входящие подключение по протоколу tcp с флагами:FIN,SYN,RST,ACK/SYN на порт 22 с временем жизни 55 разрешить. Иногда бывает маршрут по которому проходящий пакет незначительно изменяется (к примеру, провайдер пускает трафик по разным канал в целях балансировки), следовательно и количество маршрутизаторов, по которым идёт пакет, тоже меняется, тогда на всякий случай добавим к правилу ttl +2 и ttl -2 Правило будет выглядеть так: iptables -A INPUT -p tcp --syn --dport 22 -m ttl --ttl-gt 52 -m ttl --ttl-lt 58 -j ACCEPT Правило означает: входящие подключение по протоколу tcp с флагами:FIN,SYN,RST,ACK/SYN на порт 22 с временем жизни больше 52 и меньше 58 (match TTL > 52 TTL match TTL < 58) разрешить 2) Второй вариант является продолжением первого, основное отличие в установлении на клиентской стороне нестандартного значения ttl, по которому на сервере будем фильтровать пакеты. Например ttl=80: echo "80" > /proc/sys/net/ipv4/ip_default_ttl При количестве маршрутизаторов 12, составим правило с запасом которое будет выглядеть так: iptables -A INPUT -p tcp --syn --dport 22 -m ttl --ttl-gt 65 -m ttl --ttl-lt 70 -j ACCEPT Правило означает: входящие подключение по протоколу tcp с флагами:FIN,SYN,RST,ACK/SYN на порт 22 с временем жизни больше 65 и меньше 70 (match TTL > 65 TTL match TTL < 70) разрешить 3. Фильтрация на основе mss (максимальный размер сегмента) Размер mss рассчитывается по формуле: mtu минус 40 байт mtu по умолчанию обычно равно 1500 байтам, итого значение mss по умолчанию равно 1460 байт Посмотреть mtu можно командой ifconfig При фильтрации по mss на сервере, на клиентской стороне потребуется лишь изменить mtu сетевого интерфейса (желательно немного уменьшить). Реализуем идею на практике: На клиентской стороне ставим mtu=1440 ifconfig eth0 mtu 1440 На сервере правило будет выглядеть так: iptables -A INPUT -p tcp --syn --dport 22 -m tcpmss --mss 1400 -j ACCEPT Правило означает: входящие подключение по протоколу tcp с флагами:FIN,SYN,RST,ACK/SYN на порт 22 с размером mss=1400 разрешить 4. Защита от установки пользователям сервера исходящих соединений во внешний мир. Например заблокируем возможность соединения пользователю с правами которого работает web сервер iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp -m owner --uid-owner 33 -m state --state NEW -j DROP В первой цепочки разрешаем входящие соединения на 80 порт по протоколу tcp, во второй запрещаем устанавливать новые исходящие соединения пользователю (uid 33) с правами которого работает web сервер.   Использование L7-filter в Linux (доп. ссылка 1)   Автор: Сергей Яремчук  [комментарии]   Проект l7-filter (http://l7-filter.sf.net) дает возможность Netfilter идентифицировать пакет на прикладном уровне данных, основываясь на его содержимом, и классифицировать пакеты по их назначению, без привязки к номеру порта. В настоящее время поддерживаются протоколы HTTP и FTP; P2P сети (Kazaa, BitTorrent, eDonkey2000, FastTrack); IM-системы (AIM/Jabber/IRC/MSN); VoIP/Skype; VPN; игры (Battlefield, CS, Doom3, WoW); файлы (exe, mp3) и даже сетевые черви - Code Red и Nimda. Проект предлагает две версии L7-filter: * Kernel version - развивается уже давно и хорошо протестирована, немного сложна в установке, не очень дружит с SMP-процессорами и позволяет использовать только самые простые регулярные выражения; * Userspace version - находится в ранней стадии развития, и, возможно, в будущем будет поддерживаться только эта версия, обладает большими возможностями по фильтрации, так как поддерживает весь спектр команд GNU grep. Несмотря на то, что userspace стабилен в работе, этот вариант не рекомендуют использовать на критических системах и для блокировки трафика. В дальнейшем рассмотрим установку kernel варианта l7-filter, который затем дополним IPP2P. Данный способ потребует пересборки ядра. Для успешного проведения сборки в твоей системе должны быть установлены пакеты build-essential, iptables, iptables-dev и linux-source. Берем настройки текущего ядра, которые будем использовать как базовые, и копируем текущую конфигурацию в /usr/src/linux: sudo cp /boot/config-`uname -r` /usr/src/linux/.config Получаем архив с патчами для ядра с сайта L7-filter, распаковываем его и переходим в каталог с сырцами ядра: tar xzvf netfilter-layer7-v2.21.tar.gz $ cd /usr/src/linux В архиве несколько патчей для разных версий ядер и iptables, нужно выбрать вариант для своего ядра: $ sudo patch -p1 < ../netfilter-layer7-v2.21/for_older_kernels/kernel-2.6.22-2.6.24-layer7-2.18.patch Теперь аналогично патчим iptables, выбрав также свою версию: $ cd ../iptables $ iptables -v iptables v1.3.8 $ sudo patch -p1 < ../netfilter-layer7-v2.21/iptables-1.3-for-kernel-2.6.20forward-layer7-2.21.patch $ sudo chmod +x extensions/.layer7-test Собираем iptables: $ make KERNEL_DIR=/usr/src/linux $ sudo make install Конфигурируем и компилируем ядро: $ sudo make menuconfig Переходим в "Networking - Networking option - Network packet filtering framework(Netfilter) - Core Netfilter Configuration", где активируем "Connection tracking flow accounting" и "Layer 7 match support". Cтавим фильтры протоколов, фактически они просто копируются в каталог /etc/l7-protocols: $ tar xzvf l7-protocols-2009-05-28.tar.gz $ cd l7-protocols-2009-05-28/ $ sudo make install После перезагрузки можно проверить работу фильтра. Команда "iptables -m layer7 --help" выдаст список параметров. Например, чтобы заблокировать BitTorrent, AIM и Skype, пишем: iptables -A FORWARD -m layer7 --l7proto bittorrent -j DROP iptables -A FORWARD -m layer7 --l7proto aim -j DROP iptables -A FORWARD -m layer7 --l7proto skypetoskype -j DROP iptables -A FORWARD -m layer7 --l7proto skypeout -j DROP То есть ищем в списке название протокола и производим нужное действие.   Корректировка вывода arptables-save в Debian Lenny   Автор: аноним  [комментарии]   Суть проблемы: в Debian Lenny arptables-save генерирует данные, синтаксически и семантически некорректные с точки зрения arptables-restore. Например, если в чистую таблицу filter добавить правило # arptables -A INPUT -s 10.128.0.100 -j DROP а затем вызвать arptables-save, получим # arptables-save *filter :INPUT ACCEPT :OUTPUT ACCEPT :FORWARD ACCEPT -A INPUT -j DROP -i any -o any -s 10.128.0.100 Попытавшись скормить это arptables-restore, увидим arptables v0.0.3.3: Can't use -o with INPUT Try 'arptables -h' or 'arptables --help' for more information. ERROR(line 5): Но даже удаление -o any не сильно исправит дело. Потому что останется -i any. С точки зрения arptables-restore, да и arptables, any ни разу не ключевое слово, а просто имя интерфейса. Почему arptables-save считает иначе - непонятно. Подводя итог: вывод arptables-save нужно фильтровать примерно таким образом: # arptables-save | sed -e 's/\(-[io]\) any *//g' *filter :INPUT ACCEPT :OUTPUT ACCEPT :FORWARD ACCEPT -A INPUT -j DROP -s 10.128.0.100   Ограничение возможностей ssh туннеля при помощи iptables   Автор: Avatar  [комментарии]   Использование туннелей на основе ssh сейчас широко распространено. И многие используют его как универсальное решение для организации туннелей внутрь локальной сети для доступа к различным сервисам. И в связи с этим очень часто возникает вопрос "А как ограничить возможности такого туннеля". Например: есть компания, которая обслуживает ваш web сервер. Для выполнения этой работы требуется доступ к серверу web-server.dmz по портам 80 и 443. Решение: на сервере ssh, через который создаётся туннель, выполняем: 1) добавляем пользователя aaa 2) устанавливаем ему шелл /bin/false (или другой, только так чтобы он не мог залогиниться) 3) Добавляем правила iptables: iptables -A OUTPUT -d web-server.dmz -p tcp -m tcp --dport 80 -m owner --uid-owner aaa -j ACCEPT iptables -A OUTPUT -d web-server.dmz -p tcp -m tcp --dport 443 -m owner --uid-owner aaa -j ACCEPT iptables -A OUTPUT -m owner --uid-owner aaa -j REJECT   Скрипт для блокировки в iptables целых стран (доп. ссылка 1)   Автор: Vivek Gite  [комментарии]   Скрипт для организации блокировки диапазонов IP адресов в привязке к названию страны. Например, можно использовать для блокирования всех непрофильных сайту стран в моменты DDoS атаки или запретить приход почты для стран с которыми явно не ведется переписка. Список привязки IP к странам загружается с сайта http://www.ipdeny.com/ipblocks/data/countries #!/bin/bash ### Block all traffic from AFGHANISTAN (af) and CHINA (CN). Use ISO code ### ISO="af cn" ### Set PATH ### IPT=/sbin/iptables WGET=/usr/bin/wget EGREP=/bin/egrep ### No editing below ### SPAMLIST="countrydrop" ZONEROOT="/root/iptables" DLROOT="http://www.ipdeny.com/ipblocks/data/countries" cleanOldRules(){ $IPT -F $IPT -X $IPT -t nat -F $IPT -t nat -X $IPT -t mangle -F $IPT -t mangle -X $IPT -P INPUT ACCEPT $IPT -P OUTPUT ACCEPT $IPT -P FORWARD ACCEPT } # create a dir [ ! -d $ZONEROOT ] && /bin/mkdir -p $ZONEROOT # clean old rules cleanOldRules # create a new iptables list $IPT -N $SPAMLIST for c in $ISO do # local zone file tDB=$ZONEROOT/$c.zone # get fresh zone file $WGET -O $tDB $DLROOT/$c.zone # country specific log message SPAMDROPMSG="$c Country Drop" # get BADIPS=$(egrep -v "^#|^$" $tDB) for ipblock in $BADIPS do $IPT -A $SPAMLIST -s $ipblock -j LOG --log-prefix "$SPAMDROPMSG" $IPT -A $SPAMLIST -s $ipblock -j DROP done done # Drop everything $IPT -I INPUT -j $SPAMLIST $IPT -I OUTPUT -j $SPAMLIST $IPT -I FORWARD -j $SPAMLIST # call your other iptable script # /path/to/other/iptables.sh exit 0 Вместо последовательного добавления правил, для увеличения производительности, рекомендуется использовать систему ipset (http://ipset.netfilter.org/) или nfqueue (http://nfqueue.sf.net/) Использовать можно примерно так: #!/bin/sh iptables -F INPUT ipset -N spam ipmap cat block_country_net_list.txt | while read net; do ipset -A spam --network $net done iptables -A INPUT -m set --set spam src -j REJECT Другой эффективный вариант - использовать iptables модуль geoip (http://people.netfilter.org/peejix/geoip/), который не входит в базовую поставку iptables и требует установки patch-o-matic и загрузки дополнительной базы привязки к странам, например с http://www.maxmind.com/ Например, блокировка ICMP запросов из Франции, Италии и Испании будет выглядеть так: iptables -A OUTPUT -p icmp -m geoip --dst-cc FR,IT,ES -j REJECT   Поддержка TARPIT для RHEL 5/CentOS 5   Автор: Андрей  [комментарии]   Для RHEL 5 / CentOS 5 исходники модуля TARPIT можно загрузить здесь: http://enterprise.bih.harvard.edu/pub/tarpit-updates/old-patch-o-matic TARPIT позволяет организовать коннект в пустоту (соединение не закрывается, но ничего не происходит). Я скачал 2.6.19 версию, собирается без проблем при наличии пакета kernel-devel и простого makefile: obj-m += ipt_TARPIT.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: make -C $(KDIR) M=$(PWD) modules clean: make -C $(KDIR) M=$(PWD) clean Чтобы при обновлении ядра модуль автоматом подхватывался, нужно зарегистрировать модуль через /sbin/weak-modules Пример использования: iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT   Удаление iptables правил по их номерам   [комментарии]   Для отображения порядковых номеров iptables правил в списке необходимо использовать опцию --line-numbers. Например, просмотрим содержимое таблицы трансляции и правила, влияющие на пересылку пакетов между интерфейсами: iptables -L POSTROUTING -t nat -n -v --line-numbers iptables -L FORWARD -n -v --line-numbers Удалим несколько записей по номеру: iptables -D FORWARD 55 iptables -t nat -D POSTROUTING 15 Цепочку следует явно указывать, так как номера уникальны только в рамках каждой цепочки. Удалять следует внимательно и по одному элементу, так как после удаления следующие номера сдвигаются! Т.е., если вы хотели удалить в списке строки 15 и 25, удалять нужно, начиная с большего номера, иначе 25 запись после удаления 15 сменит номер на 24.   Обход блокировки BitTorrent трафика, через отправку фиктивных RST пакетов (доп. ссылка 1)   Автор: tuxtraining.com  [комментарии]   Некоторые сетевые операторы, например Comcast, используют ПО Sandvine для нарушения работы BitTorrent. Принцип действия Sandvine в отправке клиенту поддельных RST пакетов, приводящих к прерыванию соединения. Простейший способ борьбы с подобной практикой блокирования - запретить прием пакетов с RST флагом: iptables -A INPUT -p tcp --dport 6883 --tcp-flags RST RST -j DROP где, 6883 - номер BitTorrent порта. Пример скрипта, оставляющего возможность входящих соединений только для BitTorrent: #!/bin/sh # Номер порта BitTorrent BT_PORT=6883 # Сброс настроек iptables iptables -F # Разрешаем трафик на loopback интерфейсе iptables -A INPUT -i lo -j ACCEPT # Молча отбрасываем RST пакеты iptables -A INPUT -p tcp --dport $BT_PORT --tcp-flags RST RST -j DROP # Пропускаем уже установленные входящие соединения iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Разрешаем прием соединений для BitTorrent iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport $BT_PORT -j ACCEPT iptables -A INPUT -m state --state NEW -m udp -p udp --dport $BT_PORT -j ACCEPT # Все остальные входящие соединения блокируем iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited   Как заблокировать через iptables пакеты отправленные из определенной ОС (доп. ссылка 1)   Автор: Evgeniy Polyakov  [комментарии]   Модуль ost был написан для использования в iptables правилах результатов пассивного определения типа операционной системы, из которой был отправлен TCP SYN пакет. Загружаем исходные тексты модуля со страницы http://www.ioremap.net/archive/osf/ или ставим из patch-o-matic: В Makefile через переменную IPTABLES указываем путь к заголовочным файлам iptables (xtables.h и /lib/iptables или /lib/xtables в Debian). Собираем модуль xt_osf.ko: make Собираем библиотеку libipt_osf.so, после чего копируем ее в /lib/iptables или /lib64/iptables: make lib Собираем утилиты для загрузки сигнатур ОС и ведения лога (load, osfd, ucon_osf): make bin Загружаем список сигнатур: wget http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.os Загружаем модуль ядра: insmod ./xt_osf.ko Загружаем сигнатуры: ./load ./pf.os /proc/sys/net/ipv4/osf Пример правила для занесения всех пересылок с участием Linux лог: iptables -I INPUT -j ACCEPT -p tcp -m osf --genre Linux --log 0 --ttl 2 Для блокирования внешних пакетов от Windows машин: iptables -j DROP -i INPUT -p tcp -m osg --genre Windows --ttl 2 При отправке с Windows в логе появится: ipt_osf: Windows [2000:SP3:Windows XP Pro SP1, 2000 SP3]: 11.22.33.55:4024 -> 11.22.33.44:139 Опции: --log - если в качестве аргумента передан 0, то помещать в лог все совпадения и неизвестные срабатывания, если 1, помещать только первое совпадение, 2 - только совпадения; --ttl - если 0, проверять только для пакетов внутри локальной сети, 1 - для внешней сети, 2 - не учитывать TTL.   Как увеличить размер таблицы контроля сессий ip_conntrack в Linux   [комментарии]   Если ядро ругается "kernel: ip_conntrack: table full, dropping packet.", причину флуда (скорее всего вирус или сканирование портов) можно найти по списку /proc/net/ip_conntrack Если просто общая загрузка большая, увеличить размер таблицы можно через /proc/sys/net/ipv4/ip_conntrack_max Также можно увеличить размерность хэша через параметр hashsize модуля ip_conntrack: /etc/modules.conf: options ip_conntrack hashsize=N Более тонкий тюнинг можно произвести через переменные определенные в /proc/sys/net/ipv4/netfilter   Как вести лог блокировок в iptables и ipfw   [комментарии]   Linux: - Перед правилом блокировки нужно вставить "log" правило: iptables -A FORWARD -p tcp -m tcp -s 192.168.0.0/16 --dport 25 \ -j LOG --log-level debug --log-prefix "outgoing mail" iptables -A FORWARD -p tcp -m tcp -s 192.168.0.0/16 --dport 25 -j DROP - Проверить запущены ли в системе klogd и syslogd. - Настроить /etc/syslog.conf на прием kern.debug логов: kern.=debug -/var/log/kernel/info FreeBSD: Добавить ключ log в ipfw, например: ipfw add 1000 deny log tcp from any to 192.168.10.10 22 via fxp0 ipfw add 1000 deny log logamount 0 tcp from any to 192.168.10.10 80 via fxp0 Для ведения логов ядро должно быть собрано с IPFIREWALL_VERBOSE или нужно выставить "sysctl -w net.inet.ip.fw.verbose=1". Далее проверить чтобы в /etc/syslog.conf было упоминание LOG_SECURITY: security.* /var/log/security Через параметр logamount передается число записей которые будет записано в лог, после превышения записи перестанут появляться в логе, до тех пор пока не будет вызвана команда "ipfw resetlog". Максимальное число сообщений можно также установить через sysctl net.inet.ip.fw.verbose_limit. Для отмены лимитирования на число записей, нужно установить атрибут в 0.   Статистика сетевых соединений через syslog и iptables   Автор: umask  [комментарии]   Часто недовольные пользователи приходят и просят дать им распечатку логов доступа в интернет. Отчасти это позволяет сделать squid, но только при прозрачном проксировании, да и то логи только по http-протоколу. На помощь приходит iptables и syslog. Настраиваем в syslog.conf добавление сообщений от ядра уровня debug (или уровня, который вам удобнее) в отдельный файл. Лучше всего хранить эти логи на отдельном разделе (их размер огромен! но проблему решает gzip - сжимает логи более чем в 10 раз). В моём syslog.conf была добавлена строка: kern.=debug -/var/log/access/access Желательно, что бы в уровень debug сообщений от ядра не поступало никакой другой информации, кроме информации от iptables. У меня так и получилось по умолчанию с уровнем debug. В rc.firewall было добавлено в самое начало: #LOG ALL (!!!). Beware!!! #FORWARD iptables -A FORWARD -m state --state NEW -j LOG --log-level debug \ --log-prefix 'FRWLL_FWD_NEW ' # --log-tcp-options --log-ip-options #iptables -A FORWARD -m state --state ESTABLISHED -j LOG --log-level debug \ # --log-prefix 'FRWLL_FWD_ESTBLSHD ' # --log-tcp-options --log-ip-options #iptables -A FORWARD -m state --state RELATED -j LOG --log-level debug \ # --log-prefix 'FRWLL_FWD_RLTD ' # --log-tcp-options --log-ip-options #iptables -A FORWARD -m state --state INVALID -j LOG --log-level debug \ # --log-prefix 'FRWLL_FWD_INVLD ' # --log-tcp-options --log-ip-options #INPUT iptables -A INPUT -m state --state NEW -j LOG --log-level debug \ --log-prefix 'FRWLL_INPT_NEW ' # --log-tcp-options --log-ip-options #iptables -A INPUT -m state --state ESTABLISHED -j LOG --log-level debug \ # --log-prefix 'FRWLL_INPT_ESTBLSHD ' # --log-tcp-options --log-ip-options #iptables -A INPUT -m state --state RELATED -j LOG --log-level debug \ # --log-prefix 'FRWLL_INPT_RLTD ' # --log-tcp-options --log-ip-options iptables -A INPUT -m state --state INVALID -j LOG --log-level debug \ --log-prefix 'FRWLL_INPT_INVLD ' # --log-tcp-options --log-ip-options Если раскомментировать все строки, то получиться лог с полной статистикой доступа - он будет очень большим. Поэтому в данном примере имеем лог только по установкам соединений и ошибочным соединениям в цепочках INPUT и FORWARD. Итак. В logrotate я добавил (/etc/logrotate.d/access): /var/log/access/access { sharedscripts compress rotate 45 daily postrotate /bin/killall -HUP syslogd endscript } Сжимаем логи каждый день. Храним статистику за последние 45 суток. Компрессия логов в моём случае дала значительный прирост производительности, поскольку шлюз достаточно мощный и скорость парсинга логов упиралась только в чтение с HDD. В итоге был написан простой скрипт на perl, выдающий статистику в более-менее удобоваримой форме. Вот и сам скрипт: ------------------------- #!/usr/bin/perl use CGI qw(:standard); use PerlIO::gzip; use Switch; ##Redefine before start: my $LOG_DIR="/var/log/access/"; my $LOG_FILENAME="access"; ##end my $IP, $FLAG; ## Params delimeter in request: "-" ($IP, $FLAG) = split(/-/, $ARGV[0]); ## if undefine IP or file log FLAG-number or FLAG is empty - parser exit: if(!defined($IP)||!defined($FLAG)||$FLAG==""){ print header; print start_html; print "Valid parameters required!"; print end_html; exit(1); } print header; print start_html("Stat for: $IP"); print "<h2>Stat for: $IP</h2><br/>", "\n<pre>"; switch($FLAG) { case "0" { open($FD, "<$LOG_DIR$LOG_FILENAME") or die "Cannot open current (0) log-file!<br> File does not exist or access not permitted!<br>"; while(<$FD>) { chomp; s/gw kernel://g; if(grep(/$IP/, $_)) { print $_, "<br>\n"; } } close($FD); } else { open($GZIP, "<:gzip(lazy)", "$LOG_DIR$LOG_FILENAME.$FLAG.gz") or die "Cannot open old (", $FLAG, ") log-file!<br> File does not exist or access not permitted!<br>"; while(<$GZIP>) { chomp; s/gw kernel://g; if(grep(/$IP/, $_)) { print $_, "<br>\n"; } } close($GZIP); } } print "</pre>\n"; print "<br><br>Access stat parser by \"umask at yandex dot ru\"<br>"; print end_html; ------------------------- Для работы скрипта необходимо установить модуль PerlIO-gzip. Найти ссылку на модуль можно на cpan.org. Доступ к статистике можно получить через браузер (скрипт рассчитан для работы как CGI): hostname.ru/cgi-bin/parse.pl?192.168.1.1-0 Аргумент понимаеться так: 192.168.1.1 - искомая подстрока. 0 - норме лог файла. В данном случае текущий (в который пока ещё записываются сообщения syslog). 1 - вчерашний, 2 - позавчерашний, 3 - 3 дня назад. ..... и т.д. Для меня данное решение оказалось удобным.   Скрипт для автоматизации настройки iptables фильтра для локальной сети (доп. ссылка 1)   Автор: Константин Брызгалов  [комментарии]   На разных машинах в моей локальной сети накопилась куча программ, которым нужен был выход в интернет напрямую. У каждой свой набор портов. Захотелось на входе иметь минимальную конфигурацию, описывающую ресурсы, а на выходе набор разрешающих правил для iptables. В основном были клиент-банки - поэтому и такая терминология в программе. А так вместо банка можно указывать любой ресурс в формате определенном в man iptables. Ограничения, недостатки: 1. использование количества портов для одного ресурса менее 16 2. нельзя указать диапазон портов через двоеточие как в iptables Оба легко устаняются: первое - есть пример в самом скрипте, второе через использование другого разделителя для записей на входе, проверку наличия ":" - использование другого формата вызова iptables. Мне это не нужно и код не хотел раздувать. #!/bin/bash #bkv 2005.10 #Дано: # Два списка: # Первый список из записей вида - банк:порты(через запятую) # Второй список из записей вида - клиент:банки(через запятую) #Найти: # Набор разрешающих правил iptables для forward #Примечания: # политика FORWARD по умолчанию - "запрещено все, что не разрешенно" # iptables поддерживает одновременное указание не более 15 портов #Решение: # Создадим отдельную цепочку, например, - CLIENTBANK # Сгенерируем необходимые правила и поместим их в цепочку CLIENTBANK # Обращения по всем портам из первого списка направим на обработку в CLIENTBANK # Перед выполнением все правила связаные с цепочкой CLIENTBANK удалим, чтобы не плодить # правила от многократного запуска itls="/sbin/iptables" #Подаем список на обработку awk #признак первого списка - первое поле BankPorts #признак второго списка - первое поле ClientBanks echo -e "\ BankPorts:smtp.mail.ru:25\n\ BankPorts:10.24.70.0/26:22,23\n\ BankPorts:pop.mail.ru:110\n\ BankPorts:bank4.ru:9999,888\n\ BankPorts:bank5.ru:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15\n\ BankPorts:bank6.ru:21,22,23,24,25,26,27,28,29,210,211,212,213,214,215\n\ ClientBanks:192.168.9.0/16:smtp.mail.ru,pop.mail.ru,10.24.70.0/26\n\ ClientBanks:192.168.9.8:bank4.ru,bank5.ru,bank6.ru\n\ ClientBanks:192.168.9.6:bank6.ru,bank4.ru\n\ "|\ awk -v itls=$itls -F: '{ if($0~/^BankPorts/) BankPorts[$2]=$3 #создаем ассоциативный массив - индекс:банк, значение:порты через запятую if($0~/^ClientBanks/) ClientBanks[$2]=$3 #аналогично клиент -> банки }END{ #Cгенерируем _необходимые_ правила для цепочки CLIENTBANK for (client in ClientBanks){ split(ClientBanks[client],bank_arr,",") #поместили в массив bank_arr адреса банков для клиента for(i in bank_arr){ all_ports=all_ports","BankPorts[bank_arr[i]] #создаем список всех портов для дальнейшего использования count_ports=split(BankPorts[bank_arr[i]],tmp_arr,",") if(count_ports > 15) print "echo Слишком много портов для "bank_arr[i]".Допиши программу.Выход&&exit 1" else printf("%s -A CLIENTBANK -s %s -d %s -p tcp -m multiport --dports %s -j ACCEPT\n",itls,client,bank_arr[i],BankPorts[bank_arr[i]]) } } #Создадим правила перенаправляющие из FORWARD на обработку в CLIENTBANK, помня про ограничение в 15 портов sub(",","",all_ports) #отрезаем первую запятую у списка всех использующихся портов split(all_ports,all_ports_arr,",")#поместили в массив all_ports_arr все порты какие есть j=1;i=1 while(all_ports_arr[i]){ while(i<=(j*15)){ if (all_ports_arr[i]) tmp_all_ports=tmp_all_ports","all_ports_arr[i] i++ } sub(",","",tmp_all_ports) #отрезаем первую запятую printf("%s -I FORWARD -p tcp -m multiport --ports %s -j CLIENTBANK\n",itls,tmp_all_ports) tmp_all_ports="" j++ } print itls" -A CLIENTBANK -p tcp -m state --state ESTABLISHED -j ACCEPT" print itls" -N CLIENTBANK" print itls" -X CLIENTBANK" print itls" -F CLIENTBANK" #Удаляем из FORWARD все цепочки содержащие цель CLIENTBANK del_rules_nums="'`$itls --line-numbers -L FORWARD -n|grep CLIENTBANK|cut -f1 -d" "|tr "\n" ","`'" split(del_rules_nums,del_rules_arr,",") cnt_rules=1 while(del_rules_arr[cnt_rules]){ printf("%s -D FORWARD %s\n",itls,del_rules_arr[cnt_rules]) cnt_rules++ } }'|tac > gen.itls.sh chmod 700 gen.itls.sh echo "Команды сгенерированы в файл ./gen.itls.sh .Выход." exit ./gen.itls.sh rm ./gen.itls.sh   Лимитирование числа запросов в единицу времени через iptables (доп. ссылка 1)   Автор: Steve  [комментарии]   Разрешаем производить только 4 коннекта к 22 порту в течении 60 секунд: iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \ --update --seconds 60 --hitcount 4 -j DROP   Ограничение трафика через iptables (доп. ссылка 1)   Автор: Николай Малых  [комментарии]   ipt_limit - общее ограничение по срабатываний правила -m limit --limit {avg}/[second|minute|hour|day] --limit-burst {burst} iplimit - ограничение соединений для одного IP. Ограничение коннектов к 80 порту от одного IP: iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-above 4 -j REJECT Тоже, но для запросов с одной /24 подсети: iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-mask 8 --iplimit-above 4 -j REJECT hashlimit - для каждого IP в хэше хранятся параметры соединений; -m hashlimit --hashlimit {avg} --hashlimit-burst {burst} --hashlimit-mode {режим: dstip, dstport, srcip, srcport} \ --hashlimit-name {name} --hashlimit-htable-max {num} --hashlimit-htable-expire {num} --hashlimit-htable-gcinterval {num} iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m hashlimit --hashlimit 1/hour \ --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name SSH --hashlimit-htable-expire 360000 -j ACCEPT tbf (http://www.nmalykh.org/work/tbf.tar.gz) - продолжение развития limit и hashlimit c поддержкой возможности инверсии правил в целом. iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m tbf ! -- tbf 1/s --tbf-burst --tbf-mode srcip --tbf-name SMTP -j DROP   Примеры возможностей iptables открывающихся после установки POM (patch-o-matic) (доп. ссылка 1)   [комментарии]   Фильтрация по строковой маске: iptables -A FORWARD -i eth0 -p tcp --sport 80 \ -m string --string '|7F|ELF' -j DROP iptables -A FORWARD -i eth0 -p tcp \ ! -s 192.168.0.5 --sport 80 -m string \ --string '|7F|ELF' -j DROP Сжатая компоновка номеров портов в одной строке: iptables -A INPUT -p tcp -m mport \ --dports 80,110,21,6000:6003 -j ACCEPT Учет времени при блокировке: iptables -A INPUT -p tcp -d 80 -m time \ --timestart 04:00 --timestop 06:30 --days Fri \ --syn -j REJECT Коннект в пустоту (соединение не закрывается, но ничего не происходит): iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT Срабатывание правила с заданной вероятностью (в процентах): iptables -t nat -A PREROUTING -i eth0 -p tcp \ --dport 80 --syn -m random --average 33 \ -j DNAT --to-destination 192.168.0.100:80 iptables -t nat -A PREROUTING -i eth0 -p tcp \ --dport 80 --syn -m random --average 50 \ -j DNAT --to-destination 192.168.0.101:80 iptables -t nat -A PREROUTING -i eth0 -p tcp \ --dport 80 --syn -j DNAT \ --to-destination 192.168.0.102:80 См. также статью http://linuxgazette.net/108/odonovan.html   Как удалить iptables правило по номеру   [комментарии]   iptables -L INPUT --line-numbers iptables -D INPUT номер iptables -t nat -L POSTROUTING --line-numbers iptables -t nat -D POSTROUTING номер   Как ограничить пропускную полосу для пакетов помеченных меткой через MARK.   Автор: Denis Fedorishenko (NuclearCat)  [комментарии]   Сделать MARK, и загнать все такие трансферы в какой-либо класс шейпера. Т.е. если например помеченные пакеты - все их отнести к классу 1:51 где скорость ограничена от 32К до 64К: tc filter add dev eth1 parent 1:0 protocol ip prio 100 handle 51 fw classid 1:51 tc class add dev eth1 parent 1:2 classid 1:51 htb rate 32Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:51 handle 51 sfq perturb 10   Как запретить пользователям качать большие файлы   Автор: Denis Fedorishenko (NuclearCat)  [обсудить]   - Собираем поддержку connbytes в patch-o-matic. - Добавляем правило в firewall, например: iptables -A FORWARD --connbytes 100000 -j REJECT - теперь все TCP сессии более 100 Кбайт будут "обрезаны", необходимо добавить исключения для протоколов типа ssh, обычные "долгоживущие" чаты и т.п.   Борьба с Kazaa и прочим вредным трафиком путем вырезания пакетов по маске   Автор: Denis Fedorishenko (NuclearCat)  [комментарии]   - собираем поддержку "string" в patch-o-matic. - смотрим на протокол Kazaa, в заголовках содержится: HTTP/1.0 503 Service Unavailable.Retry-After: 3..X-Kazaa-Username: BlazeTre - добавляем в firewall строчку - iptables -A FORWARD -m string --string "X-Kazaa-" -j REJECT   Как в Linux перебросить соединение через NAT во внутреннюю сеть (доп. ссылка 1)   Автор: Dimez  [комментарии]   Первый путь - пробрасывание только порта: 1) iptables -t nat -A PREROUTING -p tcp -d EXT_R_IP --dport 10000 -j DNAT --to-destination LOCAL_IP:80 2) iptables -A FORWARD -i eth0 -d LOCAL_IP -p tcp --dport 22 -j ACCEPT Второй вариант - выброс всей машины наружу (если есть свободные адреса): 1) ifconfig eth0:0 NEW_IP netmask NETMASK broadcast BROADCAST 2) route add NEW_IP gw GW netmask 0.0.0.0 metric 1 dev eth0:0 3) iptables -t nat -A PREROUTING -p tcp -d NEW_IP -j DNAT --to-destination LOCAL_IP 4) iptables -A FORWARD -i eth0 -d LOCAL_IP -j ACCEPT Обозначения: EXT_R_IP - внешний IP роутера, LOCAL_IP - внутренний IP машины, которую хочешь выбросить NEW_IP - новый IP на который хочешь посадить машину, которая имеет локальный LOCAL_IP NETMASK, BROADCAST, GW - внешние netmask, broadcast и gateway   Пример настройки NAT с привязкой к IP под Linux   [комментарии]   Пример настройки NAT с привязкой к IP под Linux iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -o eth0 -j SNAT --to-source 212.23.98.45 или (без привязки к IP) ipchains -A forward -j MASQ -s 192.168.0.0/16 -d 0.0.0.0/0 или (через iproute2) ip rule add from 10.0.1.0/24 nat 254.147.38.14 Другой способ трансляции адресов: iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -j MASQUERADE   Как ограничить через iptables максимальное число одновременных соединений с одного IP.   [комментарии]   # Максимум 10 одновременных соединений к 80 порту с одного IP iptables -A INPUT-p tcp --dport 80 -m iplimit --iplimit-above 10 -j REJECT # Блокируем на стадии SYN iptables -I INPUT -p tcp --syn --dport 80 -j DROP -m iplimit --iplimit-above 10 # 20 соединений на сеть класса С iptables -p tcp --dport 80 -m iplimit --iplimit-above 20 --iplimit-mask 24 -j REJECT   Как посмотреть статистику по PREROUTING цепочкам в iptables.   [комментарии]   > Делаю: > iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128 > По iptables -L ничего не показывается. Используйте: iptables -t nat -L   Как настроить пакетный фильтр для фильтрации по содержимому пакетов   [комментарии]   Следующие правила блокируют прохождение пакетов, данные в которых содержат подстроку virus.exe и ведут лог пакетов с строкой secret внутри: iptables -A INPUT -m string --string "secret" -j LOG --log-level info --log-prefix "SECRET" iptables -I INPUT -j DROP -p tcp -s 0.0.0.0/0 -m string --string "virus.exe" # Block Code Red iptables -I INPUT -j DROP -p tcp -m string --string "cmd.exe" # Block Nimda iptables -I INPUT -j DROP -p tcp -m string --string "root.exe" iptables -I INPUT -j DROP -p tcp -m string --string "default.ida"   Как настроить NAT (транслятор адресов) для нормальной работы с FTP и ICQ в Linux   [комментарии]   iptables: modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp modprobe ip_nat_irc ipchains: modprobe ip_masq_ftp modprobe ip_masq_raudio modprobe ip_masq_irc modprobe ip_masq_icq   Список интересных iptables модулей-расширений. (доп. ссылка 1)   [обсудить]   Фильтрация по MAC (mac): --mac-source [!] XX:XX:XX:XX:XX:XX (! - "не" маска.) Запись номеров портов (multiport): --source-port [port[,port]] --destination-port [port[,port]] --port [port[,port]] (source или destination) Установка и проверка маркера пакет (mark): --set-mark mark --mark value Выборка пакетов посланных/полученных пользователем (owner): --uid-owner userid --gid-owner groupid --pid-owner processid Установка/проверка типа сервиса (TOS/tos): --set-tos tos --tos tos Определение log-level для syslog (LOG): --log-level level Установка реального IP для работы NAT (SNAT, цепочка POSTROUTING): --to-source <ipaddr>[-<ipaddr>][:port-port] Изменение/проверка TTL - time to live (TTL/ttl): --ttl-set ttl --ttl-dec N - уменьшение на N --ttl-inc N - увеличение на N --ttl ttl - проверка   Можно ли отфильтровывать пакеты (вести лог) в зависимости от UID пользователя ?   [обсудить]   Для FreeBSD: ipfw add count tcp from any to not 192.168.1.0/24 uid 231 uid user (или gid group) - под правило попадают все TCP или UDP пакеты посланный или принятые пользователем user (группой group). В Linux в ядрах 2.4.x в iptables можно использовать модуль owner.   Ограничение трафика через iptables (доп. ссылка 1)   Автор: Z0termaNN  [комментарии]   iptables --new-chain car iptables --insert OUTPUT 1 -p tcp --destination-port 25 -o eth1 --jump car iptables --append car -m limit --limit 20/sec --jump RETURN iptables --append car --jump DROP

Пакетный фильтр в FreeBSD: ipfw, IP-Filter

Маршрутизатор на базе FreeBSD с приоритизация трафика средствами PF и ALTQ   Автор: artemrts  [комментарии]   Проблема приоритизации трафика, на мой взгляд, весьма актуальна. Интернет-канала много не бывает и на всех пользователей и сервисов локальной зачастую не хватает. Поэтому для нормальной работы Интернета требуется грамотное распределения полосы с учетом потребностей каждого из участников. Единственный раз, когда мне не понадобился QoS - это гарантированный провайдером канал в 20 Мбит/с в мир и 100Мбит/с - национальный. Но такое удовольствие не из дешевых, поэтому зачастую народ довольствуется ADSL-каналом с заявленной скоростью к клиенту до 5-10 Мбит/с. Хочу заметить, что данная статья не предназначенная для новичков в сетевом администрировании в целом и в PF в частности. Читателю необходимо иметь минимальные навыки работы с сетями (понимать устройство пакета, знать что такое ТСР-флаги и т.д.), а также с пакетным фильтром PF. Не лишним будет прочесть официальный FAQ и man'ы. В основном цель этой статьи поделиться опытом, выслушать замечания и, возможно, улучшить свой вариант. И так, постановка задачи: организовать доступ к сети Интернет. Грамотно распределить как входящий так и исходящий трафик с разделением канала для клиентов локальной сети и сервисов, запущенных на самом роутере (например, FTP-сервер, SIP-сервер и т.д.). В качестве роутера выступает сервер с ОС FreeBSD 9 c пакетным фильром PF. Протокол FTP будет использоваться только в пассивном режиме, что немного упростит конфигурацию. Для решения поставленной задачи необходимо пересобрать ядро и включить в него поддержку PF и ALTQ. Для задач, не требующих ALTQ, пересобирать ядро не обязательно. Можно просто подгрузить PF как модуль. Добавляем в файл конфигурации следующие строки и пересобираем ядро. Описывать каждую опцию не буду. В man 4 altq все есть. options HZ=1000 device pf device pflog options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ #options ALTQ_NOPCC #for SMP CPU Лично я для боевого сервера пересобираю не только ядро системы, но и мир. Как это сделать, хорошо описано в Хендбуке и /usr/src/Makefile. Для автоматического запуска PF при старте системы добавляем в /etc/rc.conf строки: pf_enable="YES" pflog_enable="YES" Далее, собственно, сам конфигурационный файл пакетного фильтра. Возьмем самую простую реализацию роутера: один внутренний сетевой интерфейс и один внешний. Интернет канал подключен через ADSL-модем, работающий в режиме моста, т.е. подключение pppoe организовано средствами штатного ppp-клиента. Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c. На роутере запущен HTTP-прокси для прозрачного перенаправления WWW-трафика пользователей сети. Это сделано с целью блокировать метод CONNECT и принудительно направить другие виды трафика (например, торрент) в другие очереди с другим приоритетом. Я использую легковесный, но "шустрый" 3proxy (3proxy.ru). Кому важен кэш - используйте Squid или Apache Traffic Server. Также перенаправляются все ДНС-запросы на сервер ДНС-провайдера. Это сделано с целью блокировки фишинговых и других зловредных сайтов, сайтов для взрослых, аплоадеры, соц. сети и т.д. и т.п. Некоторые компании так же предоставляет блокировку рекламных баннеров. Весь исходящий трафик я разбил на следующие очереди: - ДНС-запросы - очередь u_dns - ТСР АСК-пакеты - очередь u_ack - трафик с высоким приоритетом - очередь u_hipri - трафик с нормальным приоритетом - очередь u_pri - трафик с низким приоритетом - очередь u_lowpri - весь остальной трафик - очередь u_other - стандартная очередь - очередь u_std, одна очередь должна быть с опцией default, в которую попадает трафик, который не попадает ни под какое другое правило. В нашем случае это показатель правильности назначения очередей в правилах фильтрации. В эту очередь ничего не должно попадать. Аналогичное деление трафика, идущего к клиенту локальной сети, только вместо u_* используется d_* обозначение. Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP. Данные, являющиеся ДНС-запросам и ТСР АСК-пакетами, для всех пользователей имеют свой высокий неизменный приоритет. Например, весь трафик от/к компьютера, относящегося к группе с низким приоритетом, будет обрабатываться с низким приоритетом, кроме ДНС и ТСР АСК. Определяем макросы, что бы меньше текста в основной части конфигурационного файла. mst="modulate state" str="source-track rule" ext_if="tun0" int_if="rl0" Таблица, в которую включены компьютеры трафик к/от которых весь будет считаться с высоким приоритетом. table <pc_hipri> persist {10.11.1.2} Аналогично для ПК с нормальным приоритетом. table <pc_pri> persist {10.13.1.2 10.13.1.10 10.13.1.13 10.13.1.14 10.13.1.15} Таблица с адресами, доступ к которым блокируется. table <ban> persist file "/etc/pf.ban" Таблица, с адресами клиентов, которым можно доверять. table <trust> persist {123.10.456.0/24 193.196.125.0/24} IP-адрес системного администратора. table <me> persist {210.211.13.84} IP-адреса SIP-провайдеров table <sip_peers> persist {212.15.65.122 75.16.127.118} Конфигурируем опции пакетного фильтра, изменяющие его поведение. В нашем случае: - не производится проверка на интерфейсе обратной петли; - выставляем оптимизацию правил в basic; - устанавливаем привязку состояний соединения (т.н. стейтов) к каждому интерфейсу; - устанавливаем максимальное кол-во состояний. Если сетевых интерфейсов большое кол-во или большое кол-во клиентов в сети, возможно, потребуется скорректировать это значение в большую сторону. set skip on lo0 set ruleset-optimization basic set state-policy if-bound set limit states 20000 Нормализация трафика (т.н. скрабинг). Срабинг позволяет значительно повысить безопасность файервола. В нашем случае выполняется нормализация трафика на внешнем интерфейсе, генерируется случайная последовательность в поле идентификации IP-пакета, устанавливается величина TTL=128, производится "дефрагментация" IP-пакетов, а также нормализация TCP соединений. scrub on $ext_if all random-id no-df min-ttl 128 fragment reassemble reassemble tcp ALTQ. Приоритизировать будем на всех физических сетевых интерфейсах. На внешнем - исходящий трафик, на внутреннем - входящий. Выбор дисциплины - очень важный момент. Возможные варианты: priq, cbq, hfsc. Я использую hfsc, т.к. важной чертой этого планировщика есть именно гарантирование полосы для конкретного пользователя/сервиса. Работа планировщика для нашего конкретного случая построена следующим образом: если в описании очереди указан дополнительный параметр realtime, то ей будет отдана указанная (realtime) полоса независимо ни от чего. Величина трафика свыше realtime будет рассчитываться исходя из величины bandwidth. Причем bandwidth - не абсолютный параметр, скорее относительный. Исходя из величин bandwidth каждой очереди рассчитывается величина трафика свыше realtime для каждой очереди пока не будет достигнут параметр upperlimit, который жестко ограничивает полосу. Приоритеты в планировщике hfsc не используются. Помимо всех прочих параметров, hfsc имеет параметр qlimit - кол-во слотов, доступных очереди для сохранения исходящих пакетов, когда вся доступная полоса исчерпана. И только когда все слоты будут заняты, пакеты будут отбрасываться, что заставит клиента снижать скорость. Мы не будем использовать RED или ECN, вместо этого увеличим значение qlimit. Назначаем очередь на внешнем интерфейсе. Величина bandwidth должна быть 96% от предоставляемой вышестоящим роутером. Здесь же перечисляем все дочерние очереди. altq on $ext_if hfsc bandwidth 800Kb queue {u_std,u_ack,u_dns,u_hipri,u_pri,u_lowpri,u_other} Очередь по-умолчанию. Будет потреблять 25 кбит/с независимо ни от чего. Величина bandwidth 1Kb означает, что если канал будет полностью занят любой другой очередью или всеми, то очередь u_std практически ничего не получит свыше 25 кбит/с. queue u_std bandwidth 1Kb qlimit 50 hfsc (default realtime 25Kb) Очередь u_ack - это ТСР АСК-пакеты, которые будут отправляться удаленному хосту с которого происходит загрузка по протоколу ТСР. Важно, что бы эти пакеты проходили без задержек. Для максимальной скорости от провайдеоа 4 Мбит/с требуется гарантированный канал в обратную сторону в размере 125 кбит/с. queue u_ack bandwidth 1Kb qlimit 200 hfsc (realtime 125Kb) ДНС-запросы. Гарантированной полосы в 25 кбит/с вполне достаточно. Больше не нужно, поэтому bandwidth 1Kb queue u_dns bandwidth 1Kb qlimit 50 hfsc (realtime 25Kb) Очередь с высоким приоритетом queue u_hipri bandwidth 300Kb qlimit 250 hfsc (realtime 200Kb) Очередь с обычным приоритетом queue u_pri bandwidth 300Kb qlimit 400 hfsc (realtime 150Kb) Очередь с низким приоритетом queue u_lowpri bandwidth 100Kb qlimit 100 hfsc (realtime 75Kb) Очередь для всего остального трафика ТСР и UDP. queue u_other bandwidth 97Kb qlimit 50 hfsc (realtime 25Kb) Назначаем очереди на внутреннем интерфейсе - приоритизируем входящий трафик. Провайдер отдает 5 Мбит/с, поэтому устанавливаем очередь inetq в размере 96%. Так же на внутреннем интерфейсе запущен ряд служб, например, локальный FTP, поэтому важно "не смешать" локальный трафик с Интернет-трафиком. Так как сетевая карточка 100Mbit, то выставляем значение bandwidth в 100Mb. Назначаем две очереди: одна - локальный трафик, вторая Интернет-трафик с дочерними очередями. altq on $int_if hfsc bandwidth 100Mb queue {etherq, inetq} Очередь для локального трафика. В эту очередь будут попадать все пакеты, идущие от внутреннего сетевого интерфейса к пользователям локальной сети. Параметр upperlimit определяет максимальное значения для данной очереди. Заметьте, в эту очередь не будут попадать ответы, например, от WWW-сервера из сети Интернет. Эта очередь исключительно для локального трафика. queue etherq bandwidth 95Mb hfsc (upperlimit 95Mb) Очередь для Интернет-трафика. В эту очередь будут попадать пакеты, идущие с сети Интернет. Имеет дочерние очереди по аналогии с внешним интерфейсом. queue inetq bandwidth 4800Kb hfsc (upperlimit 4800Kb) {d_std,d_ack,d_dns,d_hipri,d_pri,d_lowpri,d_other} queue d_std bandwidth 1Kb qlimit 50 hfsc (default realtime 25Kb) queue d_ack bandwidth 1Kb qlimit 50 hfsc (realtime 50Kb) queue d_dns bandwidth 1Kb qlimit 50 hfsc (realtime 25Kb) queue d_hipri bandwidth 1297Kb qlimit 500 hfsc (realtime 1000Kb) queue d_pri bandwidth 2000Kb qlimit 500 hfsc (realtime 2000Kb) queue d_lowpri bandwidth 1000Kb qlimit 500 hfsc (realtime 500Kb) queue d_other bandwidth 500Kb qlimit 500 hfsc (realtime 240Kb) Правила трансляции локальных адресов (NAT). Транслируются адреса, где источник - IP-адрес из любой подсети внутреннего интерфейса, а адрес назначения - любой, кроме IP-адресов из всех подсетей, подключенных к роутеру. Это могут быть как физические так и VPN-интерфейсы (tun, gif). ($ext_if) - в круглых скобках, т.к. IP-адрес внешнего интерфейса назначается динамически. ($int_if:network) и (self) в круглых скобках что бы в выводе pfctl -sn не было подстановки реальных адресов и сетей. Это удобно, когда у вас на внутреннем интерфейсе несколько алиасов и, соответственно, подсетей (как в моем случае). nat on $ext_if inet from ($int_if:network) to !(self) -> ($ext_if) port 1024:65535 Пользователей из группы pc_hipri и pc_pri пускаем в обход прокси. Я пускаю их напрямую, т.к. эти пользователи не нуждаются в контроле, а также специфическое ПО не работает в режиме прозрачного проксирования. no rdr on $int_if inet proto tcp from {<pc_hipri> <pc_pri>} to !(self) port 80 Правило редиректа, перенаправляющие все ДНС-запросы локальных пользователей на внешний ДНС-сервер. Это может быть Google или, лучше, ДНС-сервер компании, предоставляющей фильтрацию трафика посредством ДНС. rdr on $int_if inet proto {tcp udp} from ($int_if:network) to !(self) port 53 -> 193.58.251.251 port 53 Редирект на прокси-сервер. rdr on $int_if inet proto tcp from ($int_if:network) to !(self) port 80 -> 127.0.0.1 port 31280 Редирект на удаленный рабочий стол виндовой машины в локальной сети из сети Интернет. rdr on $ext_if inet proto tcp from any to ($ext_if) port 3389 -> 10.11.1.2 port 3389 Правила фильтрации трафика. Правила будем группировать в такой последовательности: действие, интерфейс, направление, протокол, адрес источника, порт источника, адрес назначения, порт назначения. Антиспуфинг. antispoof quick for {$int_if lo0} inet Блокируем не маршрутизируемые адреса. block in quick inet from no-route to any Блокируем броадкасты. block in quick on $ext_if inet from any to 255.255.255.255 Блокируем IP-адреса, содержащиеся в таблице ban. Опция return возвращает TCP RST, что закрывает сразу соединение без таймаута. Полезно, когда блокируются адреса рекламных сетей, что позволяет браузеру нормально загружать странички без ожидания загрузки блокируемого контента. block return out quick on $ext_if inet from any to <ban> Эти 2 правила определяют тип файервола: запрещено все, кроме явно разрешенного. block in all block out all Собственно разрешающие правила. Расположены в определенной последовательности, что важно с точки зрения производительности, а также ожидаемого эффекта. Внутренний интерфейс. Разрешаем ТСР-пакеты к интерфейсу обратной петли, на котором "слушает" прокси- сервер для организации прозрачного проксирования. Назначаем очереди. Мы не можем приоритизировать входящий трафик, только исходящий. В d_pri будут попадать пакеты, которые являются ответом от сервера к клиенту, таким образом мы регулируем скорость скачивания. pass in log quick on $int_if inet proto tcp from ($int_if:network) to 127.0.0.1 port 31280 queue (d_pri, d_ack) Далее 3 правила, которые разрешают ТСР соединения на определенные порты на не локальные IP-адреса. Назначаются соответствующие очереди. Тегирование необходимо что бы потом на внешнем интерфейсе мы могли "отделить" его от остального трафика и направить в нужную очередь. Заметьте, опция quick не используется, поэтому эти правила нужно расположить в правильной последовательности: от менее ограничивающего к более, потому как без опции quick последнее совпавшее правило выигрывает, а не первое совпавшее. Опция quick не используется т.к. при совпадении пакет будет назначен в очередь и пропущен и не дойдет до тех правил, которые описывают разрешения и приоритеты, основанные не на протоколах, а на адресах источника/назначения (в нашем случае это компьютеры из группы pc_hipri и pc_pri). Т.к. протокол ТСР, то так же добавляем очередь для ТСР АСК-пакетов. В качестве адреса назначения в правилах фигурирует !(self:network). Это значит, что только пакеты, не предназначенные ни к одному IP-адресу сетевых интерфейсов или IP-адресу из подсетей, подключенных к роутеру, будут разрешаться и, соответственно, тегироваться. Это, например, не даст подключиться к внешнему IP из локальной сети. pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ $mst queue (d_other d_ack) tag INET_OTHER pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port {20 21 25 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port 443 $mst queue (d_pri d_ack) tag INET_PRI Далее 2 правила, которые будут срабатывать как для всех пользователей так и для тех, кто принадлежит к т.н. VIP-группе (pc_hipri и pc_pri). Поэтому тут используем опцию quick. pass in log quick on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port {22 3389} $mst queue (d_hipri d_ack) tag INET_HIPRI pass in log quick on $int_if inet proto tcp from ($int_if:network) to !(self:network) \\ port 53 $mst queue (d_dns d_ack) tag INET_DNS Следующие 2 правила, по-аналогии с TCP, описывают разрешения и очереди для протокола UDP. Так же их тегируем. Второе правило с опцией quick, т.к. оно должно срабатывать для всех категорий пользователей. pass in log on $int_if inet proto udp from ($int_if:network) to !(self:network) queue d_other tag INET_OTHER pass in log quick on $int_if inet proto udp from ($int_if:network) to !(self:network) \\ port {53 123} queue d_dns tag INET_DNS Правило, разрешающее ICMP. pass in log on $int_if inet proto icmp from ($int_if:network) to !(self:network) queue d_lowpri tag INET_LOWPRI Следующие правила, разрешающие трафик от клиентов, с высоким и нормальным приоритетом. Весь трафик будет считаться очень высоким (hipri) или высоким (pri) приоритетом (кроме ДНС и ТСР АСК). Здесь мы не указываем протокол, но указываем modulate state, который применяется только для ТСР. Это не будет ошибкой, PF достаточно "умный" и он подставит modulate state для протокола ТСР, и keep state - для всех остальных протоколов. pass in log quick on $int_if inet from <pc_hipri> to !(self:network) $mst queue (d_hipri, d_ack) tag INET_HIPRI pass in log quick on $int_if inet from <pc_pri> to !(self:network) $mst queue (d_pri, d_ack) tag INET_PRI Разрешаем локальный Ethernet к внутреннему интерфейсу роутера. pass in quick on $int_if inet from ($int_if:network) to ($int_if) queue etherq Теперь опишем разрешающие правила с внутреннего интерфейса роутера в локальную сеть. Если у вас нет редиректа с Интернета в локальную сеть или нет никаких серверов/клиентов, запущенных на самом роутере и требующих доступ в локальную сеть, то эти правила можно не добавлять. Первое правило разрешает трафик с Интернета к указанному IP в локальной сети и назначает очень высокий приоритет входящего трафика. Это третье правило (первое - rdr, второе - разрешающее на внешнем интерфейсе) для редиректа (проброса) порта в локальную сеть. pass out quick on $int_if inet proto tcp from !(self) to 10.11.1.2 port 3389 queue (d_hipri d_ack) Правило, разрешающее трафик от внутреннего сетевого интерфейса роутера в локальную сеть. Не важно какой протокол. Весь направляется в очередь etherq. pass out quick on $int_if inet from ($int_if) to ($int_if:network) queue etherq Внешний интерфейс. Разрешающие правила для входящего трафика. Важно, для каждого входящего правило указывать максимальное кол-во стейтов, которые может создать правило. Это предотвратит исчерпывания всего лимита стейтов одним правилом в случае DoS атаки. Последующие 6 правил разрешают входящие ТСР-подключения к определенным портам роутера, а также назначаются соответствующие очереди. Эти очереди будут приоритизировать не входящий трафик, а исходящий. Так же стоит обратить внимание на первые два правила, которые разрешают доступ к FTP серверу на роутере. Передача команд по 21-му порту будет направляться в очередь с большим приоритетом (u_pri), а данные - с меньшим (u_lowpri). pass in quick on $ext_if inet proto tcp from <trust> to ($ext_if) port 21 $mst (max 100) queue (u_pri u_ack) pass in quick on $ext_if inet proto tcp from <trust> to ($ext_if) port >=49152 $mst (max 100) queue (u_lowpri u_ack) pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 22 $mst (max 10) queue (u_hipri u_ack) pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 80 $mst (max 100) queue (u_pri u_ack) pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 5900 $mst (max 10) queue (u_hipri u_ack) Правило, разрешающее входящее подключение с сети Интернет (конкретно с адреса администратора), но не к интерфейсам роутера (внешнему в том числе), а к компьютеру в локальной сети к порту RDP. pass in quick on $ext_if inet proto tcp from <me> to !(self) port 3389 $mst (max 10) queue (u_hipri u_ack) Следующее правило разрешает подключение с любого адреса сети Интернет к VNC-репитеру. В целях безопасности включен трекинг источника (source-track). pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 5500 $mst \\ (max 10,$str, max-src-nodes 2, max-src-states 3, max-src-conn-rate 3/60) \\ queue (u_hipri u_ack) Следующие 2 правила разрешают подключения к определенным портам по протоколу UDP. pass in quick on $ext_if inet proto udp from any to ($ext_if) port 1194 (max 20) queue u_pri pass in quick on $ext_if inet proto udp from <sip_peers> to ($ext_if) port 5060 (max 20) queue u_hipri Разрешаем пинг к внешнему интерфейсу. pass in quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type echoreq (max 100) queue u_other Внешний интерфейс. Разрешающие правила для исходящего трафика. Следующие 5 правил разрешают исходящий трафик с внешнего интерфейса, который был помечен на внутреннем интерфейсе. Это исключительно данные, которые передаются в сеть Интернет от клиентов в локальной сети. pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_dns u_ack) tagged INET_DNS pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_hipri u_ack) tagged INET_HIPRI pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_pri u_ack) tagged INET_PRI pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_lowpri u_ack) tagged INET_LOWPRI pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_other u_ack) tagged INET_OTHER И последние правила, разрешающие исходящие соединения с внешнего интерфейса. Это будет трафик непосредственно самого роутера. В целом приоритет этого трафика выше чем от клиентов в локальной сети. pass out quick on $ext_if inet proto tcp from ($ext_if) to any port 53 $mst queue (u_dns u_ack) pass out quick on $ext_if inet proto tcp from ($ext_if) to any $mst queue (u_pri u_ack) pass out quick on $ext_if inet proto udp from ($ext_if) to any port {53 123} queue u_dns pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers> port 5060 queue u_hipri pass out quick on $ext_if inet proto udp from ($ext_if) to any queue u_pri pass out quick on $ext_if inet proto icmp from ($ext_if) to any $mst queue u_lowpri Есть один важный момент, на котором остановлюсь подробнее. Второе правило будет разрешать ТСР-соединения с роутера и в том числе на 80 порт. Под это правило так же подпадают пакеты, отправленные с прокси-сервера, трафик, который фактически является HTTP-трафиком клиентов из локальной сети. Т.к. в нашем случае приоритеты этих видов трафика равны (очередь u_pri), то все хорошо. Но если планируется назначить очереди разные (например, HTTP от локальных клиентов - очередь u_lowpri, а с внешнего интерфейса роутера - u_pri), тогда следует указать в правиле для прокси-сервера опцию user uid и поместить его над правилом для внешнего интерфейса роутера. Например, прокси запущен с правами пользователя nobody: pass out quick on $ext_if inet proto tcp from ($ext_if) to any user nobody $mst queue (u_lowpri u_ack) pass out quick on $ext_if inet proto tcp from ($ext_if) to any $mst queue (u_pri u_ack) Соответственно, правило, разрешающее доступ к прокси из локалной сети тоже немного измениться: необходимо поменять очередь с d_pri на d_lowpri. pass in log quick on $int_if inet proto tcp from ($int_if:network) to 127.0.0.1 port 31280 queue (d_lowpri, d_ack) Стоить отметить о наличии бага, который проявляется при использованием опции user. Об этом описано в секции BUGS на странице руководства pf.conf. Лично у меня этот баг не проявлялся. Все же старайтесь опцию user не использовать. Отладка. Отличительной способностью PF есть его протоколирование, статистика и мониторинг состояния в реальном времени что значительно облегчает конфигурирование файервола, особенно для сложных сетевых топологий. Просмотр загруженных очередей: pfctl -sq Что бы в реальном времени наблюдать загрузку очередей выполните команду: pfctl -vvsq Так же рекомендую установить из портов программу pftop, которая по аналогии с утилитой top выводит различную статистику PF в реальном времени.   Блокирование Skype по IP-адресам во FreeBSD   Автор: Тикунов Максим  [комментарии]   Раздумывая на досуге о наболевшем вопросе как заблокировать Skype, пришла идея, может она здесь уже описывалась, но всё таки решил поделиться личным опытом, может кому и пригодится. Первый раз заблокировать Skype удалось путём перекрытия всех не нужных портов и кое каких правил в прокси squid, которые не давали соединятся по ip-адресам методом CONNECT. Но это не самый лучший вариант, так как блокируется и всё остальное, icq, маил агенты и т.п. Новая идея основана на отслеживании и блокировке IP, на которые пытается соединиться Skype. И так, как я это делал (шлюз работает под управлением FreeBSD 8.1): 1. Нужен какой ни будь компьютер с Windows и установленным скайпом, желательно последней версии. 2. Отключаем на ПК все программы, которые могли бы обратиться в интернет, windows update и всё остальное (что бы эти адреса не попали в дальнейшем в список блокируемых). 3. Нужно включить скайп и залогиниться, что бы он взял с сервера базу ip-адресов, на которые можно соединяться. После этого выключаем его. 4. На шлюзе настраиваем фаервол, что бы он блокировал весь сетевой трафик ПК с протоколированием: ipfw add 50 deny log logamount 10000000 all from ip_машины to any пояснение: все обращение с нашей машины будут сыпаться с запретом в лог, у меня /var/log/all.log. 5. Включаем сбор логов и отсеиваем в отдельный файл: tail --f /var/log/all.log | grep ipfw: 50 > /usr/skype.ip 6. Включаем Skype на нашем компьютере и пытаемся залогиниться. получаем в файле skype.ip примерно следующее: Jul 9 14:34:10 server kernel: ipfw: 50 Deny UDP 192.168.3.41:40335 217.114.226.118:37950 in via rl0 Jul 9 14:34:11 server kernel: ipfw: 50 Deny UDP 192.168.3.41:40335 87.228.19.207:15134 in via rl0 Jul 9 14:34:12 server kernel: ipfw: 50 Deny UDP 192.168.3.41:40335 95.52.139.143:52195 in via rl0 Jul 9 14:34:12 server kernel: ipfw: 50 Deny UDP 192.168.3.41:40335 95.236.12.233:15842 in via rl0 Это малая часть моего примера из файла. Там больше записей. 7. После того, как скайп сказал, что не может соединиться, выключаем его, выключаем сбор логов и удаляем наше блокирующее правило под номером 50. 8. Теперь нам нужно из всей этой каши отобрать IP, на которые обращался скайп и заблокировать в фаерволе. Я написал не большой скрипт, создаём файлик и пишем туда следующее: # Очищаем таблицу 1, если таковая существует. ipfw table 1 flush # Запускаем считывание ip адресов(сортируем и отбираем только уникальные записи, # потому что могут быть повторяющиеся), куда стучался скайп. awk '{print ($11)}' /usr/skype.ip | sed 's#:.*##' | sort | uniq | while read ip; # Добавляем поочерёдно извлечённые адреса в таблицу 1. do ipfw table 1 add $ip done 9. Запускаем наш скрипт, если всё сделано верно, то таблица под номером 1 должна была заполниться адресами. Это можно проверить командой ipfw table 1 list 10. Всё, у нас есть таблица ip-адресов, куда соединялся скайп, теперь остаётся только написать правило: ipfw add 50 deny all from ip_машины to table\(1\) 11. Включаем скайп на нашей машине и проверяем, что скайп не может залогиниться. Вот в принципе и всё. Проделав это, удалось заблокировать скайп, без вреда для других программ. Да и ещё, нужно настроить сквид, что бы тот блокировал попытку соединения вида CONNECT по ip-адресам. Если ваши пользователи знают адрес прокси сервера и порт, то они могу указать это в скайпе и тот спокойно будет работать через прокси. Как это сделать есть масса статей в интернете. И ещё нужно не забывать, что скайп может соединиться с сервером через другой компьютер, на котором запущен скайп и есть доступ в интернет. Они называются супернодами. Но у меня это не вышло, я запустил скайп на своём компьютере, залогинился и закрыл доступ другому, тот второй не смог соединиться. Есть много способов вычислить адреса на которые стучится скайп. Мой пример - это один из вариантов и он проверен. Как часто обновляется база ip адресов я не знаю, но если эту операцию проделывать несколько раз в неделю, мне кажется можно поддерживать базу ip адресов в актуальном состоянии.   Проброс IPTV-трафика в локальную сеть при помощи OpenBSD и пакетного фильтра PF (доп. ссылка 1)   [комментарии]   Возникла необходимость обеспечения возможности просмотра IPTV сразу на нескольких устройствах в домашней сети. Реализации данной схемы мешало то, что полученный от провайдера модем имел два раздельных порта для данных и для IPTV. Простейшим решением было бы закорачивание IPTV-порта в домашний коммутатор, но такая схема нарушает принципы построения безопасных систем и сулит появление паразитного трафика. В связи с этим было решено организовать перенаправление IPTV-трафика через локальный шлюз, на котором используется пакетный фильтр PF и IGMP-прокси. 1. Включаем поддержку переброса между сетевыми интерфейсами мультикаст трафика, для OpenBSD: echo "multicast_router=YES" >> /etc/rc.conf.local перезагружаем систему. Активируем перенаправление мультисаст трафика: sysctl net.inet.ip.mforwarding=1 в /etc/sysctl.conf сохраняем настройку "net.inet.ip.mforwarding=1". 2. Устанавливаем пакет net/igmpproxy с реализацией igmp-прокси: pkg_add igmpproxy Отображаем свои сетевые настройки в файле конфигурации /etc/igmpproxy.conf: quickleave altnet 0.0.0.0/0 # принимаем igmp-трафик из всех подсетей phyint vr2 upstream ratelimit 0 threshold 1 phyint vr0 downstream ratelimit 0 threshold 1 phyint pppoe0 disabled Добавляем запуск igmpproxy в /etc/rc.local, чтобы прокси запустился после перезагрузки. 3. Настраиваем параметры внешнего сетевого интерфейса, через который приходит IPTV-поток. Для работы igmpproxy на интерфейсе должен быть IP-адрес, для получения которого обычно можно использовать DHCP или назначить вручную (бывают случаи привязки IP к MAC-адресу телеприставки, что потребует подмены MAC-адреса на сетевом интерфейсе шлюза). 4. Настраиваем правила для прохождения IGMP-трафика и multicast-потока в пакетном фильтре PF (в нашем случае - это UDP трафик на 5002 порт). Основной проблемой, возникающей в процессе настройки, является то, что в IGMP пакетах используется опция протокола IP "Router Alert", которая по умолчанию вычищается из пакетов при использовании PF (для отключения чистки расширенных опций необходимо использовать параметр allow-opts). В pf.conf добавляем примерно следующее: LAN = "vr0" IPTV = "vr2" block on $IPTV pass in on $IPTV inet proto udp from any to any port 5002 pass on {$LAN, $IPTV} proto igmp allow-opts   Трансляция PPTP (GRE) на шлюзе с PF (доп. ссылка 1)   Автор: Князь  [комментарии]   Как известно, межсетевой экран PF, портированный в FreeBSD из OpenBSD, не может корректно транслировать (NAT) GRE-протокол и, к примеру, из локальной сети невозможно создать несколько одновременных соединений к внешнему серверу VPN PPTP. Одним из способов решения проблемы является трансляция PPTP-соединений родным IPFW с "ядерным" NAT. При этом вовсе необязательно компилировать ядро. Все описанные действия проверены в FreeBSD версии 7.2. Но должно работать и в других версиях, где есть поддержка "ядерного" NAT для IPFW. В /etc/rc.conf добавляем #Включаем IPFW firewall_enable="YES" # Подгружаем модуль ядра ipfw_nat firewall_nat_enable="YES" # Указываем путь к скрипту загрузки правил firewall_script="/etc/ipfw.script" Создаем файл /etc/ipfw.script #!/bin/sh /sbin/ipfw -q /dev/stdin <<RULES flush #em0 - внешний интерфейс шлюза nat 10 config if em0 #Правила для трансляции PPTP-соединения add 10 nat 10 gre from any to any add 11 nat 10 tcp from any to any dst-port pptp add 12 nat 10 tcp from any pptp to any # Разрешаем весь трафик add allow all from any to any RULES Делаем скрипт исполняемым # chmod +x /etc/ipfw.script Добавляем в правила PF # Запрещаем PF транслировать PPTP-соединения no nat on $external_if proto gre all no nat on $external_if proto tcp from any to any port = pptp no nat on $external_if proto tcp from any port = pptp to any ... skip ... # Пропускаем PPTP-соединения pass quick on $external_if inet proto tcp from any to any port 1723 pass quick on $external_if inet proto tcp from any port 1723 to any pass quick on $external_if inet proto gre from any to any После всех сделанных изменений перезагружаемся.   Распределение трафика между двумя каналами во FreeBSD (доп. ссылка 1)   Автор: pehlle  [комментарии]   Во FreeBSD 7 появилась возможность задания множественных таблиц маршрутизаций. В ядре отвечает за это опция: options ROUTETABLES=[количество таблиц] Распределения трафика будет осуществляться средствами пакетного фильтра ipfw. Задаем маршруты по умолчанию: setfib 0 route add default 1.0.1.1 # таблица по умолчанию setfib 1 route add default 1.1.1.1 # новая таблица Файл конфигурации для запуска ipfw: cmd="/sbin/ipfw" $cmd add 10 check-state $cmd add 20 prob 0.5 setfib 0 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state $cmd add 30 setfib 1 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state $cmd add 40 allow all from any to any Таким образом мы задаем распределение трафика 50/50. Если каналы не равноценные то нужно выставить процентную весомость этих каналов. Трансляция адресов (NAT). Под эту задачу я выбрал ipnat, реализацию NAT от фаервола ipf. пример /etc/ipnat.rules: map vlan0 192.168.0.0/16 -> 1.0.1.1/32 map tun0 192.168.0.0/16 -> 1.1.1.1/32 Также можно выбрать демон natd или новый, работающий на уровне ядра, NAT, который появился во FreeBSD 7.   Борьба с перебором паролей на FTP сервере при помощи пакетного фильтра PF (доп. ссылка 1)   [комментарии]   Для предотвращения bruteforce-атак по подбору паролей во FreeBSD или OpenBSD можно использовать возможность пакетного фильтра PF по лимитированию числа соединений за единицу времени в сочетании с блокировкой по таблицам. Добавляем в /etc/pf.conf # Подключаем ранее составленный список заблокированных за излишнее число коннектов IP table <ftp-attacks> persist file "/etc/pf.ftp.block.list" # Блокируем все входящие соединения с IP, которые присутствуют в черном списке block in quick on $ext_if from <ftp-attacks> # Выявляем IP с которых было более 5 обращений за 40 секунд # и добавляем этот IP в ранее созданную таблицу блокировки pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 21 keep state (max-src-conn-rate 5/40, overload <ftp-attacks> flush global) Перечитываем конфигурацию PF: /etc/rc.d/pf reload или /sbin/pfctl -f /etc/pf.conf Далее, чтобы сохранить созданную таблицу блокировки между перезагрузками, необходимо добавить в /etc/rc.shutdown код для сброса в файл состояния таблицы перед завершением работы: /sbin/pfctl -t ftp-attacks -T show > /etc/pf.ftp.block.list Для удаления определенного IP (например, 192.168.1.1) из таблицы: /sbin/pfctl -t ftp-attacks -T delete 192.168.1.1 Для добавления IP или подсети вручную: /sbin/pfctl -t ftp-attacks -T add 192.168.1.1 /sbin/pfctl -t ftp-attacks -T add 192.168.1.0/24 Для полной очистки таблицы /sbin/pfctl -t ftp-attacks -T flush Для загрузки таблицы из файла: /sbin/pfctl -t ftp-attacks -T replace -f /etc/pf.ftp.block.list Для поиска IP в таблице /sbin/pfctl -t ftp-attacks -T test 192.168.1.1 Для вывода более подробной статистики по каждому из IP в таблице: /sbin/pfctl -t ftp-attacks -T show -v Для очистки счетчиков срабатываний: /sbin/pfctl -t ftp-attacks -T zero   Проброс сети во FreeBSD Jail через NAT и PF (доп. ссылка 1)   [комментарии]   Сервер работает под управлением FreeBSD 7 и имеет два сетевых интерфейса: один для интранет сети, другой для связи с внешними миром. Задача: обеспечить доступность изолированного Jail для обоих сетей, несмотря на ограничение jail по поддержке только одного интерфейса и одного IP. Решение: через NAT организовать отправку всех запросов к адресам интранет сети 10.0.0.0/8. В /etc/pf.conf на сервере прописываем: an_if="em0" # интерфейс интранет подсети lan_if_subnet="10.0.0.0/8" lan_if_ip="10.28.11.10" # IP на интранет интерфейсе em0 jail_vps_server_ip="202.54.2.3" # Реальный IP, выделенный для Jail nat on $lan_if inet proto { tcp, udp, icmp } from $jail_vps_server_ip to $lan_if_subnet -> $lan_if_ip Перезапускаем PF через /etc/rc.d/pf reload   Трансляция адресов во FreeBSD средствами ng_nat (доп. ссылка 1)   Автор: Folio  [комментарии]   Для работы этого примера необходимо иметь подгруженный ng_ipfw.ko Убедиться в его наличии можно командой: /sbin/kldstat| grep ng_ipfw.ko Если ng_ipfw.ko не загружен, то загружаем его: /sbin/kldload /boot/kernel/ng_ipfw.ko После того как ng_ipfw.ko подгружен, в выводе команды: /usr/sbin/ngctl list появится строчка вида: Name: ipfw Type: ipfw ID: 00000023 Num hooks: 2 Без загруженного ng_ipfw.ko при попытке выполнить команды ngctl'а вы будете получать сообщение: ngctl: send msg: No such file or directory а при попытке добавить правило в ipfw получите: ipfw: getsockopt(IP_FW_ADD): Invalid argument Настройка ng_nat проста и сводится к скрипту: Для примера будем NAT'ить подсеть 172.16.5.96/27 через IP-адрес 192.168.20.8 на внешнем интерфейсе fxp0. #!/usr/bin/perl $ip='192.168.20.8'; $iface='fxp0'; $net='172.16.5.96/27'; $cmd=sprintf("/usr/sbin/ngctl -f - << -EOF mkpeer ipfw: nat 60 out name ipfw:60 nat connect ipfw: nat: 61 in msg nat: setaliasaddr %s ",$ip); system($cmd); ###добавляем необходимые правила в firewall $cmd=sprintf("/sbin/ipfw add 1000 netgraph 61 all from any to %s via %s in",$ip,$iface); system($cmd); $cmd=sprintf("/sbin/ipfw add 1010 netgraph 60 all from %s to any via %s out",$net,$iface); system($cmd); где: $ip - IP адрес, через который будет работать нат (который смотрит в интернет) $iface - ваш внешний интерфейс $net - IP подсеть, которую мы собираемся NAT'ить netgraph - правило в firewall, аналогично divert, только перенаправляет трафик не в socket, а в ноду netgraph, 60, 61 - адреса исходящего и входящего хуков. Если делать руками в консоли, то команды выглядят следующим образом: ###создаем ноду nat и подключаем к ipfw /usr/sbin/ngctl mkpeer ipfw: nat 60 out ###даем ноде имя "natA" /usr/sbin/ngctl name ipfw:60 natA ###соединяем входящие и исходящие хуки для "natA" /usr/sbin/ngctl connect ipfw: natA: 61 in ###посылаем управляющее сообщение в виде IP адреса, через который будет работать нат. /usr/sbin/ngctl msg natA: setaliasaddr 192.168.20.8 Если все работает, то мы можем посмотреть вывод следующей команды: ngctl show natA: Также можно посмотреть все целиком: ngctl list Для выключения настроенного NAT нужно выполнить команду: ngctl shutdown natA: Заметка: Если вы хотите запустить NAT на нескольких внешних IP-адресах, но не забывайте изменять имена нод (в примере natA) и номера хуков (в примере 60,61) т.к. они должны быть уникальны для каждого из процессов. Не путайте in и out в создаваемой ноде и правилах ipfw. Чтиво: man 8 ipfw Все о Netgraph (http://citrin.ru/netgraph/) man 4 netgraph man 4 ng_ipfw   Интернет-шлюз с использованием PF   Автор: vitalic  [комментарии]   O пакетном фильтре (PF) написано довольно много статей. Вот и я хочу предложить свою реализацию Интернет-шлюза с использованием PF. Раздача Интернета для локальной сети происходит через NAT и основана на Packet Tagging. Плюсом этого метода является то что упрощается настройка правил для FTP (ftp-proxy не используется), как для клиентов за шлюзом, так и для возможной публикации "внутреннего" ftp-сервера в мир. Для простоты приведу пример с 1 внешним и 1 внутренним интерфейсом. На шлюзе также запущен DNS-сервер. Пользователям локальной сети разрешен доступ на все порты без исключений по протоколам TCP, UDP, из ICMP разрешен только ping. В качестве ОС выступает FreeBSD7.0 Для начала определим интерфейсы с помощью макросов ext_if="rl0" int_if="sk1" dns="ААА.ААА.ААА.ААА" lan="192.168.1.0/24" table <no_if> {BBB.BBB.BBB.BBB, 192.168.1.1, 127.0.0.1} persist set skip on lo set loginterface rl0 set ruleset-optimization basic set block-policy return scrub in all no-df random-id ##### INET FOR LAN nat on $ext_if tag LAN_INET_NAT_TCP_UDP tagged LAN_INET_TCP_UDP -> $ext_if:0 nat on $ext_if tag LAN_INET_NAT_ICMP tagged LAN_INET_ICMP -> $ext_if:0 ###### block in block out antispoof quick for { lo $int_if } ############## EXT_IF_OUT pass out quick on $ext_if inet tagged LAN_INET_NAT_TCP_UDP pass out quick on $ext_if inet tagged LAN_INET_NAT_ICMP pass out quick on $ext_if inet proto {tcp udp} from $ext_if to $dns port = dns pass out quick on $ext_if inet proto icmp from $ext_if to any icmp-type echoreq ############## EXT_IF_IN pass in quick on $ext_if inet proto tcp from any to $ext_if port = ssh synproxy state (max 10) pass in quick on $ext_if inet proto icmp from any to $ext_if icmp-type echoreq ############## INT_IF_IN pass in quick on $int_if inet proto {tcp udp} from $lan to !<no_if> tag LAN_INET_TCP_UDP pass in quick on $int_if inet from $lan to $int_if pass in quick on $int_if inet proto icmp from $lan to !<no_if> icmp-type echoreq tag LAN_INET_ICMP pass in quick on $int_if inet proto icmp from $lan to $int_if icmp-type echoreq Пояснения. Пришедшие на внутр. интерфейс пакеты "метятся". Метятся только те пакеты, у которых dst addr любой, кроме всех внутренних и внешних интерфейсов. Это необходимо, если есть несколько подсетей и вы не хотите, что бы кто-либо из одной сети мог подключится к висящему сервису на другом интерфейсе. Впринципе здесь можно вместо !<no_if> указать any. Весь исходящий трафик с сервера в "мир" (кроме ДНС) и локальную сеть блокируется. ААА.ААА.ААА.ААА - IP DNS-сервера провайдера.   Экспорт Netflow средствами netgraph во FreeBSD   Автор: VS  [комментарии]   При сборке ядра указываем: options IPFIREWALL options NETGRAPH options NETGRAPH_SOCKET options NETGRAPH_IPFW options NETGRAPH_NETFLOW options NETGRAPH_KSOCKET либо подгружаем модули: kldload ipfw.ko kldload netgraph kldload ng_socket kldload ng_ipfw kldload ng_netflow kldload ng_ksocket для их автозагрузки в /boot/loader.conf добавляем: ipfw_load="YES" ng_netflow_load="YES" ng_socket_load="YES" ng_ksocket_load="YES" ng_ipfw_load="YES" в ipfw правила ipfw add 02210 netgraph 100 ip from any to any via vlan108 ipfw add 02220 netgraph 100 ip from any to any via vlan208 Скрипт, для поднятия netflow: #!/bin/sh . /etc/rc.subr name="ngnetflow" rcvar=`set_rcvar` load_rc_config $name : ${ngnetflow_enable="NO"} : ${ngnetflow_src="127.0.0.1:9999"} : ${ngnetflow_dst="127.0.0.1:9996"} start_cmd="ngnetflow_start" stop_cmd="ngnetflow_stop" ngnetflow_start() { /usr/sbin/ngctl -f- <<-SEQ mkpeer ipfw: netflow 100 iface0 name ipfw:100 netflow connect ipfw: netflow: 108 out0 msg netflow: setdlt { iface=0 dlt=12 } msg netflow: settimeouts { inactive=30 active=600 } mkpeer netflow: ksocket export inet/dgram/udp name netflow:export flowexp msg flowexp: bind inet/${ngnetflow_src} msg flowexp: connect inet/${ngnetflow_dst} SEQ } ngnetflow_stop() { /usr/sbin/ngctl -f- <<-SEQ shutdown netflow: SEQ } run_rc_command "$1"   Как сделать отказоустойчивый брандмауэр с распределением нагрузки на FreeBSD (доп. ссылка 1)   Автор: Сгибнев Михаил  [комментарии]   Задача: Сконфигурировать два или более отказоустойчивых брандмауэра на базе IPF с функцией балансировки нагрузки (далее - "FWLB") для кластера, предоставляющего сервис в сети Интернет. Если один из брандмауэров приходит в негодность, то его функции будет выполнять второй. В этом случае мы получим высокодоступную систему с черезвычайно малым временем простоя и, как мы надеемся, сэкономит немало средств на специализированных устройствах. Наша задача - получить нижепреведенную конфигурацию: ~~~ ( net ) ~~~ | | | ---------- | switch | ---------- / \ / VIP \ --------- -------- | fwlb1 | | fwlb2 | --------- -------- \ VIP / \ / --------- | switch | --------- / \ / \ --------- --------- | server1 | | server2 | --------- --------- Где первый VIP (Virtual IP) это публичный IP адресс вашего сайта, а второй - приватный IP согласно RFC 1918, который будет использоваться серверами в качестве шлюза по умолчанию. Требования: - Два сервера с FreeBSD-STABLE. У каждого из них - по 2 сетевые карты - Два коммутатора/хаба - Два или более серверов для кластера, на котором запущен предоставляемый сервис - /usr/ports/net/pen - /usr/ports/net/freevrrpd - /usr/ports/sysutils/daemontools или /usr/ports/sysutils/runit - Ядро, скомпилированное с опциями IPFILTER и IPFILTER_LOG Pen является простым, но гибким балансировщиком. FreeVRRPd будет обеспечивать отказоустойчивость. Daemontools(или runit, с более дружественной лицензией и похожим функционалом) не является необходимым, но весьма полезен для контроля и управления процессами, поэтому тоже рекомендован к использованию. Выполнение: Часть 1: Брандмауэр Создайте набор правил IPF(или IPFW, или PF), разрешающий трафик на стороне сервиса, который нуждается в балансировке. По желанию, разрешите доступ к кластеру серверов через NAT, если есть необходимость в исходящих соединениях. Конфигурирование IPF/IPNAT не рассматривается в данной статье, но на эту тему написано достаточно много. Два пункта, которые очень важно иметь в виду, заключаются в том, что вам необходимо удостовериться, что разрешен multicast между брандмауэрами (необходимо для работы VRRP) и запрещен для всех других хостов (иначе возникнет угроза безопасности). Для получения ополнительной информации по IPF, обратитесь к: http://www.nwo.net/ipf/ipf-howto.html http://coombs.anu.edu.au/~avalon/ip-filter.html Скомпилировав ядро с опциями, указанными выше, вносим следующие изменения в /etc/rc.conf: ipfilter_enable="YES" ipfilter_rules="/etc/ipf.conf" ipnat_rules="/etc/ipnat.conf" ipnat_flags="-CF" ipmon_enable="YES" И переносим набор правил в указанные места. Часть 2: Балансировщик 1) Создаем необходимых пользователей и каталоги. mkdir -p /etc/supervise/pen/log mkdir -p /var/chroot/pen mkdir -p /var/log/pen pw useradd pen -s /bin/false -d /var/chroot/pen pw useradd penlog -s /bin/false -d /var/chroot/pen chown penlog:pen /var/log/pen 2) Создаем файлы, необходимые для запуска pen. cd /etc/supervise/pen cat << _EOF_ > run #!/bin/sh exec 2>&1 exec pen -d -u pen -j /var/chroot/pen -C localhost:8888 -f -r 80 hostname1 hostname2 _EOF_ chmod 755 run cd log cat << _EOF_ > run #!/bin/sh exec /usr/local/bin/setuidgid penlog /usr/local/bin/multilog s999999 n20 /var/log/pen _EOF_ chmod 755 run Так мы сконфигурируем pen для запуска в pen в /var/chroot/pen и портом управления 8888. Он будет балансировать входящий 80 порт на порт 80 hostname1 на hostname2. Тип балансировки - round-robin - если необходимы постоянные сессии, удалите флаг "-r". В этом примере pen запущен в режиме отладки, что упростит настройку. При промышленном использовании можно удалить флаг "-d". 3) Запуск балансировщика нагрузки. cd /service ln -s /etc/supervise/pen echo "csh -cf '/usr/local/bin/svscanboot &'" >> /etc/rc.local csh -cf '/usr/local/bin/svscanboot &' sleep 5 && svstat pen Теперь вы с помощью браузера можете удостовериться, что балансировка работает. Так же изучите /var/log/pen/current на обоих брандмауэрах. Часть 3: Отказоустойчивость 1) Сперва сконфигурируйте syslog для сбора сообщений VRRP. touch /var/log/freevrrpd.log cat << _EOF_ >> /etc/syslog.conf !freevrrpd *.* /var/log/freevrrpd.log _EOF_ 2) Конфигурирование FreeVRRPd До этого пункта, обе машины были равноправны. Теперь вам необходимо выбрать, какой FWLB будет primary. На этой машине скопируйте /usr/local/etc/freevrrpd.conf.sample в /usr/local/etc/freevrrpd.conf. Отредактируйте файл, как показано ниже: # public-facing VRID [VRID] serverid = 1 interface = fxp0 priority = 255 addr = 198.123.111.1/32 password = vrid1 vridsdep = 2 # backend VRID [VRID] serverid = 2 interface = fxp1 priority = 255 addr = 10.0.0.1/32 password = vrid2 vridsdep = 1 В результате мы получим 2 VRID - один для внешней сети, второй для внутренней, который будет использоваться кластером серверов. В этом примере оба VRIDs сконфигурированы, чтобы считать этот хост главным при выборах VRRP. Заметьте - оба VRID зависят друг от друга, что определено полем "vridsdep". Это означает, что, если один из интерфейсов в FWLB падает, другой автоматически перейдет в резервный режим, переводя оба интерфейса на резервный FWLB. Это позволит избежать попыток отправить данные через брандмауэр с упавшим внешним интерфейсом. Теперь вы должны скопировать этот файл на slave FWLB, и изменить оба поля priority на значение 100. Измените пароль на что-то более безопасное, чем на примере, но особо не расчитывайте на пароли VRRP в плане безопасности. Если другой брандмауэр, находящийся вне связки сможет общаться с вашими по VRRP, то у вас будут проблемы. 3) Запуск FreeVRRPd Теперь вы можете запустить freevrrpd на обоих брандмуэрах: cp /usr/local/etc/rc.d/freevrrpd.sh{.sample,} /usr/local/etc/rc.d/freevrrpd.sh start Часть 4: Проверка отказоустойчивости Теперь нам необходимо проверить получившуюся систему на отказоустойчивость. Сперва только надо запустить на обоих FWLB SSH, чтобы была возможность проверять правильность переключения интерфейсов. Попробуйте следующие сценарии: - С одной из машин кластера залогиньтесь по SSH на 10.0.0.1(внутренний интерфейс). Убедитесь, что это именно master FWLB. - Сделайте попытку соединения на 198.123.111.1(внешний интерфейс), порт 80 и посмотрите /var/log/pen/current, чтобы проверить факт соединения. - Отключить внешний интерфейс FWLB1. - Проверьте логи на FWLB2. Сделайте попытку соединения на 198.123.111.1, порт 80, чтобы проверить факт соединения. - Зайдите по SSH на 10.0.0.1. Вы должны увидеть FWLB2 в баннере SSH. - Подключите внешний интерфейс к FWLB1. Проверьте, что оба интерфейса FWLB1 вернулись в состояние master. Теперь повторите тест, отключая внутренний интерфейс. Если есть такое желание, то можно просто нажать Reset на FWLB1. Примечания: Удаление серверов из пула: Pen не может перманентно удалить сервера из пула, но мы можем указать ему игнорировать сервер, пока, например, идет его обновление или что-то подобное. Для этого выполните команду: penctl localhost:8888 server $servername blacklist 99999 Это поместит сервер в черный список на 99999 секунд. Для возвращения сервера в пул выполните команду: penctl localhost:8888 server $servername blacklist 1 Так мы выставим таймаут черного списка в 1 секунду, после чего сервер вернется в пул. Перманентное удаление или добавление серверов в пул: В случае, если есть необходимость добавить или удалить из пула несколько серверов, нужно отредактировать файл /service/pen/run. Просто добавьте имена хостов в конец команды запуска pen и выполните: svc -t /service/pen Эта команда пошлет сигнал TERM и перезапустит pen. Хотя эта операция и не должна сказаться на доступности сервиса, лучше такие вещи делать в специально определенное время. Ссылки: http://www.faqs.org/rfcs/rfc2338.html http://www.bsdshell.net/hut_fvrrpd.html http://siag.nu/pen/ http://cr.yp.to/daemontools.html http://smarden.org/runit © 2004 David Thiel --- lx [@ at @] redundancy.redundancy.org   Использование таблиц для блокирования большого числа IP в pf или ipfw (доп. ссылка 1)   [комментарии]   Список IP адресов или подсетей находится в файле /etc/block1.txt Например: 10.10.1.1 10.10.1.2 192.168.0.0/16 IPFW ---- Блок чтения IP в таблицу, проверка в которой будет осуществляться не через последовательный перебор правил, а через выборки из хэша: ipfw table 1 flush cat /etc/block1.txt | while read ip; do # echo ipfw table 1 add $ip 1 ipfw table 1 add $ip 1 done Привязка таблицы к правилу блокировки: ipfw add 100 deny ip from "table(1)" to any via em1 Просмотр содержимого таблицы: ipfw table 1 list PF -- /etc/pf.conf table <blockedips> persist file "/etc/block1.txt" ext_if="em1" block drop in log (all) quick on $ext_if from <blockedips> to any Проверка корректности правил PF: pfctl -nf /etc/pf.conf Чтение правил PF: pfctl -f /etc/pf.conf Добавление и удаление адресов из таблицы на лету: pfctl -t blockedips -T add 192.168.1.1 pfctl -t blockedips -T delete 192.168.1.1 Просмотр содержимого таблицы и более подробной статистики по каждому адресу: pfctl -t blockedips -T show pfctl -t blockedips -T show -v Просмотр лога срабатываний блокировок, умолчанию сохраняемого в /var/log/pflog: tcpdump -n -e -ttt -r /var/log/pflog tcpdump -n -e -ttt -r /var/log/pflog port 80 tcpdump -n -e -ttt -r /var/log/pflog and host 192.168.1.1 Срабатывание блокировок в режиме реального времени: tcpdump -n -e -ttt -i pflog0 tcpdump -n -e -ttt -i pflog0 port 80 tcpdump -n -e -ttt -i pflog0 host 192.168.1.1   ipfw nat во FreeBSD 7   Автор: Pikador  [комментарии]   В конфигурацию ядра добавляем: options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPDIVERT options IPFIREWALL_FORWARD options DUMMYNET options IPFIREWALL_NAT #ipfw kernel nat support options LIBALIAS в /etc/make.conf: CFLAGS+= -DIPFIREWALL_NAT Далее пересобираем систему: cd /usr/src/ ; make builworld && make kernel KERNCONF=YourKern && make installworld reboot В конфигурационном файле ipfw: NatIP="111.111.111.111" ipfw nat 123 config ip ${NatIP} log ipfw add 10 nat 123 ip from 192.168.0.0/16 to any ipfw add 20 nat 123 ip from any to ${NatIP} Наслаждаемся достоинствами kernel nat   Автоматическая синхронизация таблиц ipfw   Автор: freeseacher  [комментарии]   Вот таким скриптом можно периодически синхронизировать на всех сереверах таблицы ipfw #!/bin/sh #CHANGE ME prefix="/etc/tables" host="10.0.0.2" user="table" #standart variables rsync="/usr/local/bin/rsync" agg="/usr/local/bin/aggregate -t -q" ipfw="/usr/local/bin/sudo /sbin/ipfw" ${rsync} -q --rsh=ssh --rsync-path=${rsync} -d ${user}@${host}:${prefix}'/*' ${prefix} TOPROCESS=`find ${prefix}/ -type f ! -name '*.agg' -name 'table*'` for i in $TOPROCESS; do cat $i|awk '{if (! match($1,"/")) print $1"/32"; else print $1}' |$agg >$i.agg t_num=`/usr/bin/basename $i |awk -F "table" '{print $2}'` # Таблица реально существующих клиентов for SUBNET in `\ ${ipfw} table ${t_num} list | /usr/bin/cut -f 1 -d " " | /usr/bin/diff $i.agg - | \ /usr/bin/grep -v [a-z] | /usr/bin/grep ">" | /usr/bin/cut -f 2 -d " " ` ; do ${ipfw} -q table ${t_num} delete $SUBNET & /usr/bin/logger -p local4.info "ip $SUBNET blocked as no customer" & done && \ for SUBNET in `\ ${ipfw} table ${t_num} list | /usr/bin/cut -f 1 -d " " | /usr/bin/diff $i.agg - | \ /usr/bin/grep -v [a-z] | /usr/bin/grep "<" | /usr/bin/cut -f 2 -d " " ` ; do ${ipfw} -q table ${t_num} add $SUBNET & /usr/bin/logger -p local4.info "ip $SUBNET added as customer ip" & done done на выделенном серевере (например биллинге) в /etc/tables складывать файлики table100 table2 после прописывания везде одинаковых пользователей и разброса ключей, получаем эллегантное решение по синхронизации таблиц PS: рабочая часть взята из http://www.opennet.me/openforum/vsluhforumID3/32321.html#3   Пример использования таблиц блокировки в ipfw   [комментарии]   Блокировка производится командой: ipfw add deny ip from "table(1)" to any via em0 /etc/load_table.sh: #!/bin/sh ipfw table 1 flush cat /etc/block.txt | while read cnt ip; do ipfw table 1 add $ip done формат /etc/block.txt: "cnt ip" получем, например, из tcpdump лога атаки: tcpdump -n -i em0 udp and port 80 > ./tcpdump.log cat ./tcpdump.log |cut -d' ' -f3|cut -d'.' -f1,2,3,4|sort|uniq -c |sort -r -n > /etc/block.txt   Пример структурирования правил ipfw (доп. ссылка 1)   Автор: Vadim Guchenko  [комментарии]   Пример структурирования правил фильтра пакетов ipfw во FreeBSD с целью упрощения их восприятия и уменьшения вероятности допущения ошибок. Исторически так сложилось, что правила файрвола в rc.firewall написаны в плохом и труднопонимаемом стиле: входящие и исходящие пакеты проходят один и тот же набор правил. Многие используют этот скрипт как образец для написания собственного набора правил и наступают на одни и те же грабли. Как минимум, с натом. На самом деле ipfw очень удобен, если писать список правил как некую программу - с разбиением на мелкие подпрограммы (блоки) и добавлением комментариев. При этом надо руководствоваться рядом соглашений: 1. Весь трафик первым делом делится на входящий и исходящий. Каждый вид трафика обрабатывается в отдельном блоке. В качестве еще одного блока можно выделить трафик через интерфейс lo0. Слова in и out после первоначального разделения трафика не используются. 2. Входящий трафик делится на а) трафик, адресованный данному серверу; б) броадкасты; в) мультикасты; г) трафик, идущий транзитом. Каждый из видов трафика обрабатывается в отдельном блоке. Слово me после разделения трафика не используется. 3. Ветвление на блоки происходит по ip-адресам. Имена интерфейсов используются по возможности как можно реже и только тогда, когда без них не обойтись. В частности, при написании правил антиспуфинга. При использовании имен интерфейсов крайне не рекомендуется использовать слово via. В зависимости от блока (входящий или исходящий трафик) рекомендуется использовать слова xmit или recv. Это повышает читабельность. 4. Все строки с правилами нумеруются (там где это допустимо). Нумерация строго возрастающая. Рекомендуемый шаг между соседними номерами 100. 5. Блок занимает строго фиксированный диапазон номеров строк ipfw. Номер строки, с которой начинается блок, указывается в комментарии в начале этого блока. Переход на блок происходит только на его начало. Переход в середину блока недопустим. 6. Блок всегда заканчивается строкой allow ip from any to any или deny ip from any to any. Исключение составляет ситуация, когда один блок должен выполняться следом за другим. Даже если блок пустой (например, броадкасты или мультикасты не используются), все равно лучше поместить в него это единственное правило, чем удалять блок целиком. Возможно в будущем туда что-нибудь допишется. Пример я как-то уже приводил несколько лет назад. Приведу еще раз для трех разных серверов. Макросы, начинающиеся с %, заменятся на блоки ip-адресов. На всех серверах дефолтное 65535 правило: allow ip from any to any. Правила на центральном роутере/шлюзе в инет: #!/bin/sh -e fwcmd="echo" # Интерфейсы, подключенные к Интернету xmit_iface_inet="{ xmit fxp1 or xmit fxp2 }" recv_iface_inet="{ recv fxp1 or recv fxp2 }" # Ограничение количества ping-пакетов, уходящих на аплинка $fwcmd pipe 10 config bw 5Kbit/s ###################################################################### ## Разделение трафика в зависимости от направления (нумерация с 100) ###################################################################### # Трафик через интерфейс lo0 $fwcmd add 100 allow ip from any to any via lo0 # Исходящий трафик $fwcmd add 200 skipto 30000 ip from any to any out ###################################################################### ## Входящий трафик (нумерация с 500) ###################################################################### # Съем трафика для статистики $fwcmd add 500 divert 18000 ip from any to any $recv_iface_inet # NAT-трансляция входящих пакетов $fwcmd add 700 divert 8668 ip from any to %ip.nat $recv_iface_inet ##----------------------------------------------------------------------------- ## Антиспуфинг (нумерация с 1000) ##----------------------------------------------------------------------------- # Интерфейсы Интернета $fwcmd add 1000 deny log ip from %global.internal to any $recv_iface_inet ##----------------------------------------------------------------------------- ## Разделение трафика в зависимости от получателя пакета (нумерация с 5000) ##----------------------------------------------------------------------------- # Трафик, адресованный серверу $fwcmd add 5000 skipto 10000 ip from any to me # Броадкасты $fwcmd add 5100 skipto 20000 ip from any to 255.255.255.255 # Мультикасты $fwcmd add 5200 skipto 25000 ip from any to 224.0.0.0/4 ##----------------------------------------------------------------------------- ## Трафик, идущий транзитом (нумерация с 6000) ##----------------------------------------------------------------------------- # Запрещаем трафик на закрытые адреса магистрали $fwcmd add 6000 deny log ip from any to %global.backbone.private # Разрешаем остальной трафик $fwcmd add 6300 allow ip from any to any ##----------------------------------------------------------------------------- ## Трафик, адресованный серверу (нумерация с 10000) ##----------------------------------------------------------------------------- # Разрешаем установленные TCP-соединения $fwcmd add 10000 allow tcp from any to any established # Разрешаем фрагменты IP-пакетов $fwcmd add 10100 allow ip from any to any frag # Разрешаем пакеты, удовлетворяющие динамическим правилам $fwcmd add 10200 check-state # Разрешаем OSPF-пакеты $fwcmd add 10300 allow ospf from %global.backbone to any # Разрешаем GRE-пакеты $fwcmd add 10400 allow gre from any to any ##----------------------------------------------------------------------------- ## Службы сервера (нумерация с 12000) ##----------------------------------------------------------------------------- # SSH $fwcmd add 12000 deny tcp from %deny.ssh to %ip.ssh 22 $fwcmd add 12100 allow tcp from %allow.ssh to %ip.ssh 22 # BGP $fwcmd add 12200 deny tcp from %deny.bgp to %ip.bgp 179 $fwcmd add 12300 allow tcp from %allow.bgp to %ip.bgp 179 # SNMP $fwcmd add 12400 allow udp from %allow.snmp to %ip.snmp 161,1161 ##----------------------------------------------------------------------------- ## Завершающие правила для трафика, адресованного серверу (нумерация с 18000) ##----------------------------------------------------------------------------- # Разрешаем ICMP-пакеты $fwcmd add 18000 allow icmp from any to any # Разрешаем работу traceroute $fwcmd add 18100 unreach port udp from any to any 33434-33584 # Запрещаем соединения на 113 порт (ident) $fwcmd add 18200 reset tcp from any to any 113 # Запрещаем соединения на 1080 порт (socks check) $fwcmd add 18300 reset tcp from any to any 1080 # Запрещаем остальной трафик $fwcmd add 18400 deny log ip from any to any ##----------------------------------------------------------------------------- ## Броадкасты (нумерация с 20000) ##----------------------------------------------------------------------------- # Разрешаем SNMP trap'ы от ИБП $fwcmd add 20000 allow udp from %global.backbone to any 162 # Разрешаем NTP-пакеты $fwcmd add 20100 allow udp from %global.backbone to %global.backbone.broadcast 123 # Запрещаем остальной трафик $fwcmd add 20200 deny log ip from any to any ##----------------------------------------------------------------------------- ## Мультикасты (нумерация с 25000) ##----------------------------------------------------------------------------- # Разрешаем OSPF-пакеты $fwcmd add 25000 allow ospf from %global.backbone to 224.0.0.0/24{5,6} # Разрешаем общие IGMP и DVMRP-пакеты $fwcmd add 25100 allow igmp from %global.backbone to 224.0.0.0/24{1,2,4} $fwcmd add 25200 allow igmp from %ip.link.iskranet-gw to 224.0.0.0/24{1,2} # Разрешаем трафик TVoIP $fwcmd add 25300 allow ip from %ip.ext.tvoip to 224.2.153.173 # Запрещаем остальной трафик $fwcmd add 25400 deny log ip from any to any ###################################################################### ## Исходящий трафик (нумерация с 30000) ###################################################################### # Запрещаем отправку пакетов, предназначенных для внутрисетевых адресов, # на шлюз по умолчанию $fwcmd add 30000 deny ip from any to %global.internal $xmit_iface_inet # Запрещаем отправку в Интернет пакетов Netbios $fwcmd add 30100 deny tcp from any to any 135,139,445 $xmit_iface_inet # Запрещаем отправку пакетов в Интернет для клиентов, которые отключены # от Интернета $fwcmd add 30200 skipto 30350 ip from %allow.internet to any $xmit_iface_inet $fwcmd add 30300 deny ip from any to any $xmit_iface_inet # Шейпинг ping-пакетов $fwcmd add 30350 skipto 30400 icmp from %group.ping-shaping to any icmptypes 8 $xmit_iface_inet $fwcmd add 30351 pipe 10 icmp from any to any icmptypes 8 $xmit_iface_inet # Съем трафика для статистики $fwcmd add 30400 divert 18001 ip from any to any $xmit_iface_inet # NAT-трансляция исходящих пакетов $fwcmd add 30800 divert 8668 ip from 192.168.0.0/16 to any $xmit_iface_inet #$fwcmd add 30900 allow ip from %ip.nat to any $xmit_iface_inet # Направляем пакеты в нужные интерфейсы аплинков в зависимости от их src-адреса $fwcmd add 31000 fwd %ip.link.krastelecom-gw ip from %ip.link.krastelecom to any $xmit_iface_inet $fwcmd add 31100 fwd %ip.link.iskranet-gw ip from %ip.link.iskranet to any $xmit_iface_inet # Динамическое правило для доступа с данного сервера к внешним службам по UDP $fwcmd add 31200 allow udp from me to any keep-state ##----------------------------------------------------------------------------- ## Аккаунтинг трафика (нумерация с 40000) ##----------------------------------------------------------------------------- # Трафик Интернета $fwcmd add 40000 skipto 40200 ip from %global.internal to %group.accounting $fwcmd add 40100 divert 17000 ip from any to %group.accounting ###################################################################### Правила на сервере доступа: #!/bin/sh -e fwcmd="echo" # Интерфейс, подключенный к клиентскому сегменту iface_clients=fxp0 # Интерфейсы VPN iface_vpns=ng* ###################################################################### ## Разделение трафика в зависимости от направления (нумерация с 100) ###################################################################### # Трафик через интерфейс lo0 $fwcmd add 100 allow ip from any to any via lo0 # Исходящий трафик $fwcmd add 200 skipto 30000 ip from any to any out ###################################################################### ## Входящий трафик (нумерация с 500) ###################################################################### # Открываем доступ к DHCP-серверу с незарегистрированных адресов, запрещаем # с них любой другой трафик $fwcmd add 500 allow udp from %clients.unreg to %srv.dhcp 67 $fwcmd add 600 allow udp from %clients.unreg to 255.255.255.255 67 $fwcmd add 700 deny ip from %clients.unreg to any ##----------------------------------------------------------------------------- ## Антиспуфинг (нумерация с 1000) ##----------------------------------------------------------------------------- # Интерфейс клиентов $fwcmd add 1000 skipto 5000 ip from 0.0.0.0 to any recv $iface_clients $fwcmd add 1100 skipto 5000 ip from %clients to any recv $iface_clients $fwcmd add 1200 deny log ip from any to any recv $iface_clients # Интерфейсы VPN $fwcmd add 1300 skipto 5000 ip from %clients to any recv $iface_vpns $fwcmd add 1400 skipto 5000 ip from any to any verrevpath recv $iface_vpns $fwcmd add 1500 deny log ip from any to any recv $iface_vpns ##----------------------------------------------------------------------------- ## Разделение трафика в зависимости от получателя пакета (нумерация с 5000) ##----------------------------------------------------------------------------- # Трафик, адресованный серверу $fwcmd add 5000 skipto 10000 ip from any to me # Броадкасты $fwcmd add 5100 skipto 20000 ip from any to 255.255.255.255 $fwcmd add 5200 skipto 20000 ip from any to %global.backbone.broadcast $fwcmd add 5300 skipto 20000 ip from any to %clients.broadcast # Мультикасты $fwcmd add 5400 skipto 25000 ip from any to 224.0.0.0/4 ##----------------------------------------------------------------------------- ## Трафик, идущий транзитом (нумерация с 6000) ##----------------------------------------------------------------------------- # Запрещаем трафик на закрытые адреса магистрали $fwcmd add 6000 deny log ip from any to %global.backbone.private # Разрешаем любой трафик, идущий c VPN-адресов клиентов, которым открыт доступ # к услугам сети, и обратно $fwcmd add 6100 allow ip from %access.allow to any $fwcmd add 6200 allow ip from any to %access.allow # Разрешаем трафик, идущий от клиентов на DNS-резолвер и обратно $fwcmd add 6300 allow ip from any to %global.srv.resolver $fwcmd add 6400 allow ip from %global.srv.resolver to any # Разрешаем трафик, идущий от клиентов на веб-сервер сети и обратно $fwcmd add 6500 allow ip from any to %global.srv.http $fwcmd add 6600 allow ip from %global.srv.http to any # Разрешаем эхо-запросы, идущие на локальные адреса клиентов, и эхо-ответы # c этих адресов $fwcmd add 6700 allow icmp from any to %clients icmptypes 8 $fwcmd add 6800 allow icmp from %clients to any icmptypes 0 # Запрещаем остальной трафик $fwcmd add 6900 deny log ip from any to any ##----------------------------------------------------------------------------- ## Трафик, адресованный серверу (нумерация с 10000) ##----------------------------------------------------------------------------- # Разрешаем установленные TCP-соединения $fwcmd add 10000 allow tcp from any to any established # Разрешаем фрагменты IP-пакетов $fwcmd add 10100 allow ip from any to any frag # Разрешаем пакеты, удовлетворяющие динамическим правилам $fwcmd add 10200 check-state # Разрешаем OSPF-пакеты $fwcmd add 10300 allow ospf from %global.backbone to any # Разрешаем GRE-пакеты $fwcmd add 10400 allow gre from any to any ##----------------------------------------------------------------------------- ## Службы сервера (нумерация с 12000) ##----------------------------------------------------------------------------- # SSH $fwcmd add 12000 allow tcp from %srv.ssh.allow to %srv.ssh 22 # DHCP $fwcmd add 12100 allow udp from %srv.dhcp.allow to %srv.dhcp 67 # PPTP $fwcmd add 12200 allow tcp from %srv.pptp.allow to %srv.pptp 1723 # SNMP $fwcmd add 12300 allow udp from %srv.snmp.allow to %srv.snmp 161,1161 ##----------------------------------------------------------------------------- ## Завершающие правила для трафика, адресованного серверу (нумерация с 18000) ##----------------------------------------------------------------------------- # Разрешаем ICMP-пакеты $fwcmd add 18000 allow icmp from any to any # Разрешаем работу traceroute $fwcmd add 18100 unreach port udp from any to any 33434-33584 # Запрещаем соединения на 80 порт (samba) $fwcmd add 18200 reset tcp from any to any 80 # Запрещаем соединения на 113 порт (ident) $fwcmd add 18300 reset tcp from any to any 113 # Запрещаем соединения на 1080 порт (socks check) $fwcmd add 18400 reset tcp from any to any 1080 # Запрещаем остальной трафик $fwcmd add 18500 deny log ip from any to any ##----------------------------------------------------------------------------- ## Броадкасты (нумерация с 20000) ##----------------------------------------------------------------------------- # Разрешаем SNMP trap'ы от ИБП $fwcmd add 20000 allow udp from %global.backbone to any 162 # Разрешаем NTP-пакеты $fwcmd add 20100 allow udp from %global.backbone to %global.backbone.broadcast 123 # Разрешаем поиск DHCP-сервера $fwcmd add 20200 allow udp from %srv.dhcp.allow to any 67 # Запрещаем остальной трафик $fwcmd add 20300 deny log ip from any to any ##----------------------------------------------------------------------------- ## Мультикасты (нумерация с 25000) ##----------------------------------------------------------------------------- # Разрешаем OSPF-пакеты $fwcmd add 25000 allow ospf from %global.backbone to 224.0.0.0/24{5,6} # Разрешаем общие IGMP и DVMRP-пакеты $fwcmd add 25100 allow igmp from %global.backbone to 224.0.0.0/24{1,2,4} $fwcmd add 25200 allow igmp from %clients to 224.0.0.0/24{1,2} # Разрешаем подписку на группы TVoIP $fwcmd add 25300 allow igmp from %clients to %global.srv.tvoip.groups # Разрешаем трафик TVoIP $fwcmd add 25400 allow ip from %global.srv.tvoip to %global.srv.tvoip.groups # Запрещаем остальной трафик $fwcmd add 25500 deny log ip from any to any ###################################################################### ## Исходящий трафик (нумерация с 30000) ###################################################################### # Динамическое правило для доступа с данного сервера к внешним службам по UDP $fwcmd add 30000 allow udp from me to any keep-state ###################################################################### Правила на сервере служб: #!/bin/sh -e fwcmd="echo" ###################################################################### ## Разделение трафика в зависимости от направления (нумерация с 100) ###################################################################### # Трафик через интерфейс lo0 $fwcmd add 100 allow ip from any to any via lo0 # Исходящий трафик $fwcmd add 200 skipto 30000 ip from any to any out ###################################################################### ## Входящий трафик (нумерация с 1000) ###################################################################### ##----------------------------------------------------------------------------- ## Разделение трафика в зависимости от получателя пакета (нумерация с 5000) ##----------------------------------------------------------------------------- # Трафик, адресованный серверу $fwcmd add 5000 skipto 10000 ip from any to me # Броадкасты $fwcmd add 5100 skipto 20000 ip from any to 255.255.255.255 $fwcmd add 5150 skipto 20000 ip from any to %group.backbone_broadcast # Мультикасты $fwcmd add 5200 skipto 25000 ip from any to 224.0.0.0/4 ##----------------------------------------------------------------------------- ## Трафик, идущий транзитом (нумерация с 6000) ##----------------------------------------------------------------------------- # Запрещаем весь трафик $fwcmd add 6000 deny log ip from any to any ##----------------------------------------------------------------------------- ## Трафик, адресованный серверу (нумерация с 10000) ##----------------------------------------------------------------------------- # Преобразовываем запросы к DNS-резолверу $fwcmd add 10000 divert 8669 ip from %allow.resolver_internet to %ip.resolver # Разрешаем установленные TCP-соединения $fwcmd add 10100 allow tcp from any to any established # Разрешаем фрагменты IP-пакетов $fwcmd add 10200 allow ip from any to any frag # Разрешаем пакеты, удовлетворяющие динамическим правилам $fwcmd add 10300 check-state # Разрешаем OSPF-пакеты $fwcmd add 10400 allow ospf from %group.backbone to any ##----------------------------------------------------------------------------- ## Службы сервера (нумерация с 12000) ##----------------------------------------------------------------------------- # SSH $fwcmd add 12000 deny tcp from %deny.ssh to %ip.ssh 22 $fwcmd add 12100 allow tcp from %allow.ssh to %ip.ssh 22 # DNS-резолвер $fwcmd add 12200 deny { tcp or udp } from %deny.resolver to %ip.resolver 53 $fwcmd add 12300 allow { tcp or udp } from %allow.resolver to %ip.resolver 53 # DNS-сервер $fwcmd add 12400 deny { tcp or udp } from %deny.dns to %ip.dns 53 $fwcmd add 12500 allow { tcp or udp } from %allow.dns to %ip.dns 53 # DNS-кэш $fwcmd add 12600 deny { tcp or udp } from %deny.dnscache to %ip.dnscache 53 $fwcmd add 12700 allow { tcp or udp } from %allow.dnscache to %ip.dnscache 53 # NTP-сервер $fwcmd add 12800 deny udp from %deny.ntp to %ip.ntp 123 $fwcmd add 12900 allow udp from %allow.ntp to %ip.ntp 123 # IRC $fwcmd add 13000 deny tcp from %deny.irc to %ip.irc 6667-6669 $fwcmd add 13100 allow tcp from %allow.irc to %ip.irc 6667-6669 $fwcmd add 13200 deny icmp from any to %ip.irc icmptypes 8 # HTTP $fwcmd add 13700 deny tcp from %deny.http to %ip.http 80,443 $fwcmd add 13800 allow tcp from %allow.http to %ip.http 80,443 # SMTP $fwcmd add 13900 deny tcp from %deny.smtp to %ip.smtp 25 $fwcmd add 14000 allow tcp from %allow.smtp to %ip.smtp 25 $fwcmd add 14100 deny tcp from %group.internal to %ip.smtp 25 $fwcmd add 14200 allow tcp from any to %ip.smtp 25 # POP $fwcmd add 14300 deny tcp from %deny.pop to %ip.pop 110 $fwcmd add 14400 allow tcp from %allow.pop to %ip.pop 110 # SNMP $fwcmd add 14500 allow udp from %allow.snmp to %ip.snmp 161,1161 ##----------------------------------------------------------------------------- ## Завершающие правила для трафика, адресованного серверу (нумерация с 18000) ##----------------------------------------------------------------------------- # Разрешаем ICMP-пакеты $fwcmd add 18000 allow icmp from any to any # Разрешаем работу traceroute $fwcmd add 18100 unreach port udp from any to any 33434-33584 # Запрещаем соединения на 113 порт (ident) $fwcmd add 18200 reset tcp from any to any 113 # Запрещаем соединения на 1080 порт (socks check) $fwcmd add 18300 reset tcp from any to any 1080 # Запрещаем остальной трафик $fwcmd add 18400 deny log ip from any to any ##----------------------------------------------------------------------------- ## Броадкасты (нумерация с 20000) ##----------------------------------------------------------------------------- # Разрешаем SNMP trap'ы от ИБП $fwcmd add 20000 allow udp from %group.backbone to any 162 # Запрещаем остальной трафик $fwcmd add 20100 deny log ip from any to any ##----------------------------------------------------------------------------- ## Мультикасты (нумерация с 25000) ##----------------------------------------------------------------------------- # Разрешаем OSPF-пакеты $fwcmd add 25000 allow ospf from %group.backbone to 224.0.0.0/24{5,6} # Запрещаем остальной трафик $fwcmd add 25100 deny log ip from any to any ###################################################################### ## Исходящий трафик (нумерация с 30000) ###################################################################### # Преобразовываем ответы DNS-резолвера $fwcmd add 30000 divert 8669 ip from %ip.dnscache to %allow.resolver_internet # Динамическое правило для доступа с данного сервера к внешним службам по UDP $fwcmd add 30100 allow udp from me to any keep-state ##----------------------------------------------------------------------------- ## Аккаунтинг трафика (нумерация с 40000) ##----------------------------------------------------------------------------- # Трафик почтового сервера (POP) $fwcmd add 40000 divert 17000 tcp from %ip.pop to %group.accounting   Порядок прохождения пакетов в пакетных фильтрах FreeBSD (доп. ссылка 1)   Автор: butcher  [комментарии]   Порядок прохождения пакетов при одновременном использовании ipfilter, pf и ipfw: При загрузке фильтров модулями, порядок будет определяться порядком загрузки модулей. Причина здесь в том, что пакетные фильтры регистрируют себя в pfil(9). При включении всех фильтров в ядро порядок будет определять SYSINIT. Чтобы определить порядок, нужно открыть файл sys/kernel.h. В нём определён порядок инициализации определённых подсистем. Теперь, простейшее: # grep DECLARE_MODULE netinet/ip_fw_pfil.c DECLARE_MODULE(ipfw, ipfwmod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); # grep DECLARE_MODULE contrib/pf/net/pf_ioctl.c DECLARE_MODULE(pf, pf_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_FIRST); # grep DECLARE_MODULE contrib/ipfilter/netinet/mlfk_ipl.c DECLARE_MODULE(ipfilter, ipfiltermod, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY); От сюда следует: первым будет ipfilter, затем pf, затем ipfw.   Автоблокирование атак по подбору паролей (brute force) в SSH под FreeBSD (доп. ссылка 1)   Автор: Roman Y. Bogdanov  [комментарии]   Устанавливаем sshguard из портов: cd /usr/ports/security/sshguard make install clean WITH_PF=yes Настраиваем перенаправление логов в sshguard echo "auth.info;authpriv.info |exec /usr/local/sbin/sshguard" >> /etc/syslog.conf Правила блокировки по таблице, /etc/pf.conf internet="vlan50" table persist block in quick on $internet from label "ssh bruteforce" Перечитываем измененные файлы конфигурации PF и syslogd: pfctl -f /etc/pf.conf /etc/rc.d/syslogd restart Тестируем попробовав подобрать пароли: shguard[1048576]: Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan. sshd[1048577]: Invalid user administrador from 21.138.24.51 sshd[1048579]: Invalid user publica from 21.138.24.51 sshd[1048580]: Invalid user rbecerril from 21.138.24.51 sshd[1048581]: Invalid user rvences from 21.138.24.51 sshguard[1048582]: Blocking 21.138.24.51: 4 failures over 15 seconds. shguard[1048583]: Releasing 21.138.24.51 after 490 seconds.   Расчет размера очереди для pipe с заданной пропускной способностью (доп. ссылка 1)   [комментарии]   > Работает шейпер на dummynet, наблюдается некотороая потеря > траффика. Hавскидку проблема в дефолтных значениях размера очереди (50 пакетов) > для pipe'ов от 32 до 512 Кбит\с. Скорее всего, поток не влезает в очередь и > часть пакетов отбрасывается. Как правильно рассчитать размер очереди для > каждого pipe в отдельности? Eugene Grosbein: Pipe и должен отбрасывать пакеты, иначе какой же это шейпер? Ты не можешь увеличивать длину очереди бесконечно, потому что задержки вырастут настолько, что соединение начнет рвать сам юзер :-) Hа таких низких скоростях размер очереди надо бы, наоборот, уменьшать, чтобы не допустить гигантских задержек типа нескольких тысяч милисекунд. А если хочешь и рыбку съесть, и потерь иметь минимум, то читай-ка ты про RED/GRED на unixfaq.ru и делай не просто pipe, а queue/pipe с gred. Рекомендую делать w_q=0.002, max_p=0.1, min=q/10, max=3*min, где q - длина очереди, q=20 для скоростей меньше 100Kbit/s, q=30 для скоростей от 100 до 300Kbit/s и q=50 для скоростей 512Kbit/s и выше. ---------- Sergey A Yakovets: Пол-дня игрался с параметром queue. В итоге подобрал на первый взгляд кое-что подходящее. Алгоритм\мысли были следующие: Дано: асинхронный спутниковый Инет. Входящий канал - 1024 Кбит\с. Опытным путем установлено, что проблемы с потерей траффика (до 10% от общего объема) возникают при многопотоковых http\ftp закачках, т.к. спутниковый провайдер в этом случае может отдать поток на все 1024 Кбит\с. При серфинге все нормально. Исходя из этого, мною были сделаны некоторые расчеты: При максимальной пропускной способности входящего спутникового канала в 1024 Кбит\с и размере пакета в 1500 байт, пропускная способность канала равна ~ 87 пакетов\сек. В это же время, для канала в 128 Кбит\с пропускная способность равна ~ 11 пакетов\сек. Гипотетическая разница, при условии что на юзера будет идти поток в 1024 Кбит\с, а отдаваться только 128 Кбит\с, может составить 76 пакетов\сек. Итого, опытным путем установлено: - (было) при дефолтной очереди в 50 пакетов на pipe 128 Кбит\с потери 10% - при размере очереди = разница*2 = 150 пакетов потери 2% - (стало) при размере очереди = разница*3 = 230 пакетов потери 0% Серфинг не страдает, задержек нет. Закачка идет на скорости шейпера, потерь нет. Пробовал другой вариант. Hа pipe 128 Кбит\с было выставлено gred 0.002/3/6/0.1 В итоге - огромные потери, т.к. канал практически все время работал на скорости пакетов намного больше чем max_th*2. Изменение параметров до gred 0.002/50/150/0.1 не влияло на результат, т.к. дефолтный размер очереди в 50 пакетов часто переполнялся и gred не имел никакого действия. --------- Что такое алгоритмы RED и gentle RED у ipfw? http://unixfaq.ru/index.pl?req=qs&id=310 Ответ на этот вопрос скомпилирован из статей в конференции RU.UNIX.BSD от следующих авторов: Valentin Ermolaev, Alexander V. Naumochkin, Jen Linkova. Сокращение RED означает "Random Early Detection". Метод используется для выравнивания всплесков трафика. Основным критерием метода является так называемая перегрузка. В качестве показателя перегрузки avg используется вычисляемое среднее значение длины очереди пакетов, принадлежащей к определенной сессии TCP. Использование усредненного, а не мгновенного значения очереди позволяет отделить кратковременные перегрузки, которые могут быть нормально обработаны устройством и сетью, от длительных перегрузок, которые могут утопить сеть. Алгоритмически это выглядит так: В момент прихода пакета ; ; if (очередь не пуста) ; ; ; ; avg = (1 - w_q)*avg + w_q*q ; ; else ; ; ; ; m = f(time - q_time) ; ; ; ; avg = (1 - w_q)^m * avg; где avg -средний размер очереди q_time - "start of queue idle time" q - размер очереди w_q - вес очереди (фиксированный параметр) f() - линейная функий от времени В /usr/src/sys/netinet/ip_dummynet.c по этому поводу написано следующее: * RED algorithm * * RED calculates the average queue size (avg) using a low-pass filter * with an exponential weighted (w_q) moving average: * avg <- (1-w_q) * avg + w_q * q_size * where q_size is the queue length (measured in bytes or * packets). * * If q_size == 0, we compute the idle time for the link, and set * avg = (1 - w_q)^(idle/s) * where s is the time needed for transmitting a medium-sized packet. - что полностью согласуется с приведенными выше формулами. Далее в алгоритме вводятся два порога уровня перегрузки: min_th и max_th. Когда уровень перегрузки ниже первого порога min_th, то пакеты не отбрасываются. Если уровень перегрузки находится между двумя порогами, пакеты отбрасываются с линейно возврастающей вероятностью из диапазона от 0 до конфигурируемой величины max_p, которая достигается при достижении второго порога max_th. Выше порога max_th отбрасываются все пакеты. Такой метод вычисления позволяет сглаживать всплески трафика - для сравнения в первой из статей (см. ниже) на одном графике приводятся и изменение размера очереди q, и усредненного размера очереди (avg) от времени. В той же статье есть выкладки на тему значений w_q. При gentle RED ситуация выглядит чуть сложнее: Если перегрузки лежит в интервале от min_th до max_th, то пакеты отбрасываются с линейно возрастающей от 0 до max_p вероятностью. Когда перегрузка превышает max_th, но не превышет 2*max_th, пакеты отбрасываются не все (как в случае RED), а с линейно возрастающей от max_p до 1 вероятностью. Все пакеты отбрасываются только после превышения перегрузки канала значения 2*max_th. Вот как это сделано в ip_dummynet.c: если длина очереди > max_th, то в случае gred вероятность отбрасывания пакета вычисляется как ; ; p_b = c_3 * avg - c_4 где c_3 = (1 - max_p) / max_th ; ; c_4 = 1 - 2 * max_p В случае просто RED пакет отбрасывается. При загрузке очереди, большей min_th, но меньшей max_th, функция вероятности одинакова и выглядит след. образом: ; ; p_b = c_1 *avg - c_2 где c_1 = max_p / (max_th - min_th), ; ; c_2 = max_p * min_th / (max_th - min_th) Полезные ссылки: 1. http://www.icir.org/floyd/papers/red/red.html 2. http://www.icir.org/floyd/red.html 3. http://www.cisco.com/warp/public/732/Tech/red/   Как увеличить размер таблицы состояний активных соединений в pf (доп. ссылка 1)   [обсудить]   Проверяем число соединений в таблице и сравнимаем с текущим лимитом: # pfctl -s state | wc -l 10000 # pfctl -s memory | grep states states hard limit 10000 Таблица переполнена, поднимает лимит до 20000: set limit states 20000 Перечитываем конфигурацию pf: pfctl -O -f /etc/pf.conf   Прозрачный переброс SMTP трафика к spamd, используя pf (доп. ссылка 1)   Автор: undeadly.org  [комментарии]   Ниже описано как в разрыв между внешним миром и локальной сетью поставить машину на базе OpenBSD, на которой будет в прозрачном режиме отсеиваться спам через spamd. fxp2 - внешний интерфейс fxp0 - интерфейс локальной сети Поднимаем бридж: ifconfig fxp0 up ifconfig fxp2 inet 172.16.5.111 netmask 255.255.255.0 up route add default 172.16.5.1 ifconfig bridge0 create brconfig bridge0 add fxp0 add fxp2 up Проверяем включен ли форвадинг пакетов между интерфейсами и загружаем правила пакетного фильтра pf: sysctl net.inet.ip.forwarding=1 pfctl -ef /etc/pf.conf где /etc/pf.conf: ext_if="fxp2" table <spamd> persist table <spamd-white> persist rdr on $ext_if inet proto tcp from <spamd> to port smtp \ -> 127.0.0.1 port spamd rdr on $ext_if inet proto tcp from !<spamd-white> to port smtp \ -> 127.0.0.1 port spamd # "log" so you can watch the connections getting trapped pass in log on $ext_if route-to lo0 inet proto tcp to 127.0.0.1 port spamd   Как избавится от роста висящих FIN_WAIT_2 соединений под FreeBSD   [комментарии]   Если используется ipfw2 и keep-state правила, то от непрерывного роста соединений со статусом FIN_WAIT_2 помогает: sysctl -w net.inet.ip.fw.dyn_keepalive=0   Как вести лог блокировок в iptables и ipfw   [комментарии]   Linux: - Перед правилом блокировки нужно вставить "log" правило: iptables -A FORWARD -p tcp -m tcp -s 192.168.0.0/16 --dport 25 \ -j LOG --log-level debug --log-prefix "outgoing mail" iptables -A FORWARD -p tcp -m tcp -s 192.168.0.0/16 --dport 25 -j DROP - Проверить запущены ли в системе klogd и syslogd. - Настроить /etc/syslog.conf на прием kern.debug логов: kern.=debug -/var/log/kernel/info FreeBSD: Добавить ключ log в ipfw, например: ipfw add 1000 deny log tcp from any to 192.168.10.10 22 via fxp0 ipfw add 1000 deny log logamount 0 tcp from any to 192.168.10.10 80 via fxp0 Для ведения логов ядро должно быть собрано с IPFIREWALL_VERBOSE или нужно выставить "sysctl -w net.inet.ip.fw.verbose=1". Далее проверить чтобы в /etc/syslog.conf было упоминание LOG_SECURITY: security.* /var/log/security Через параметр logamount передается число записей которые будет записано в лог, после превышения записи перестанут появляться в логе, до тех пор пока не будет вызвана команда "ipfw resetlog". Максимальное число сообщений можно также установить через sysctl net.inet.ip.fw.verbose_limit. Для отмены лимитирования на число записей, нужно установить атрибут в 0.   Безопасное редактирование правил ipfw FreeBSD   Автор: 135all  [обсудить]   Для безопасного редактирование правил ipfw рекомендую обратить внимание на скрипт change_rules.sh, находящийся в /usr/share/examples/ipfw. В случае неправильных действий он вернёт старый набор правил, а также сообщит администратору об изменениях в файрволе по почте.   В двух словах про включение NAT и Firewall в ОС FreeBSD (доп. ссылка 1)   Автор: hub.ru  [комментарии]   Что бы поднять NAT и Firewall на FreeBSD надо: Скомпилировать ядро: Следующие строки нужно включить в /usr/src/sys/i386/conf/GENERIC файл конфигурации: options IPFIREWALL options IPDIVERT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options DUMMYNET options TCP_DROP_SYNFIN Переходим в директорию /usr/src/ make buildkernel KERNCONF=GENERIC make installkernel KERNCONF=GENERIC Следующие строки можно к примеру включить в rc.conf файл конфигурации: hostname="free" ifconfig_rl0="10.0.0.1" gateway_enable="YES" firewall_enable="YES" firewall_type="open" natd_enable="YES" natd_interface="rl0" natd_flags="-redirect_port tcp 10.0.0.10:80 80" tcp_extensions="NO" tcp_drop_synfin="YES" icmp_drop_redirect="YES" sendmail_enable="NONE" Для удаленного управления нужно добавить следующую строку: sshd_enable="YES" (возможно понадобится скопировать /etc/ssh/ssh_host_dsa_key.pub в /root/.ssh/authorized_keys Следующие строки можно включить в rc.firewall файл конфигурации (секция "open"): [Oo][Pp][Ee][Nn]) oif="rl0" iif="tx0" oip="132.5.7.172" iip="10.0.0.1" lan="10.0.0.0/24" setup_loopback # allow all for LAN ${fwcmd} add 500 pass all from ${lan} to ${iip} via ${iif} ${fwcmd} add 550 pass all from ${iip} to ${lan} via ${iif} # download - 60K upload - 6K for all lan ip's ${fwcmd} add 600 pipe 1 ip from any to any in via ${oif} ${fwcmd} add 650 pipe 2 ip from any to any out via ${oif} # for selected ip's only # ${fwcmd} add 601 pipe 1 all from any to 10.0.0.10 # ${fwcmd} add 651 pipe 2 all from 10.0.0.10 to any ${fwcmd} pipe 1 config bw 512Kbit/s ${fwcmd} pipe 2 config bw 48Kbit/s # dns setup ${fwcmd} add 770 pass tcp from any to ${oip} 53 setup ${fwcmd} add 780 pass udp from any domain to any ${fwcmd} add 790 pass udp from any to any domain # main setup ${fwcmd} add 800 pass tcp from any http,https,20-21,989-990 to any ${fwcmd} add 810 pass tcp from any to any http,https,20-21,989-990 ${fwcmd} add 830 pass tcp from any pop3,pop3s,smtp,imap,imaps,aol to any ${fwcmd} add 840 pass tcp from any to any pop3,pop3s,smtp,imap,imaps,aol ${fwcmd} add 65000 deny ip from any to any ;; Где oip, oif - внешний интерфейс; iip, iif - внутренний; lan - внутренняя сеть. Такая конфигурация ipfw весьма параноидальна, и здесь приведена только в качестве примера. На практике обычно нужен более открытый фаервол.   pf и трансляция адресов на двух интерфейсах   Автор: DelGod  [комментарии]   Решение оптимизировано для шлюза на флешке (не используется perl и другие "тяжелые" решения) ------------------------- /usr/local/etc/rc.d/openvpn.sh ------------------------- #!/bin/sh . /etc/rc.subr name=openvpn rcvar=`set_rcvar` prefix="/usr/local" openvpn_precmd() { for i in $openvpn_if ; do # FreeBSD <= 5.4 does not know kldstat's -m option # FreeBSD >= 6.0 does not add debug.* sysctl information # in the default build - we check both to keep things simple if ! sysctl debug.if_${i}_debug >/dev/null 2>&1 \ && ! kldstat -m if_${i} >/dev/null 2>&1 ; then if ! kldload if_${i} ; then warn "Could not load $i module." return 1 fi fi done return 0 } start_postcmd() { `/bin/cat /var/db/ukr_nets| /usr/bin/awk '{ if ($1) {system("route add "$1" 193.201.61.65 >/dev/null")} }'` /bin/sleep 10 && pfctl -F all -f /etc/pf.conf_openvpn } stop_postcmd() { `/bin/cat /var/db/ukr_nets| /usr/bin/awk '{ if ($1) {system("route delete "$1" 193.201.61.65 >/dev/null")} }'` pfctl -F all -f /etc/pf.conf rm -f "$pidfile" || warn "Could not remove $pidfile." } extra_commands="reload" pidfile="/var/run/${name}.pid" command="/usr/local/sbin/${name}" start_precmd="openvpn_precmd" start_postcmd="start_postcmd" stop_postcmd="stop_postcmd" load_rc_config ${name} : ${openvpn_enable="NO"} : ${openvpn_flags=""} : ${openvpn_if=""} : ${openvpn_configfile="${prefix}/etc/openvpn/openvpn.conf"} : ${openvpn_dir="${prefix}/etc/openvpn"} required_files="${openvpn_configfile}" command_args="--cd ${openvpn_dir} --daemon --config ${openvpn_configfile} --writepid ${pidfile}" run_rc_command "$1" ------------------------- /etc/pf.conf ------------------------- ext_if_t="rl0" int_if="rl1" table <users> persist { 192.168.1.0/24 } nat on $ext_if_t inet from <users> to any -> $ext_if_t pass on $ext_if_t all pass on $int_if all ------------------------- /etc/pf.conf_openvpn ------------------------- ext_if_o="tap0" ext_if_t="rl0" int_if="rl1" table <users> persist { 192.168.1.0/24 } table <ukr> persist file "/var/db/ukr_nets" nat on $ext_if_t inet from <users> to <ukr> -> $ext_if_t nat on $ext_if_o inet from <users> to !<ukr> -> $ext_if_o pass on $ext_if_o all pass on $ext_if_t all pass on $int_if all ------------------------- cron: ------------------------- 0 0 * * * /usr/bin/fetch -q -o "/var/db/ukr_nets" 'http://www.colocall.net/ua/?list'   FreeBSD 5.3 ipfw правило по умолчанию   Автор: else  [комментарии]   В прежних версиях FreeBSD изменить правило по умолчанию 65535 deny ip from any to any на allow ip from any to any можно было включением в ядро опции IPFIREWALL_DEFAULT_TO_ACCEPT. В версии 5.3 это не работает. Даже собрав ядро с этой опцией, получаем правило по умолчанию deny ip from any to any. Если сборка производится удаленно - сюрприз может оказаться довольно неприятным.   Проброс портов с двух различных gateway на внутренний сервер через IPNAT   Автор: Жека  [комментарии]   Иногда необходимо пробросить порты с двух различных gateway GW1 и GW2 на один внутренний сервер, у которого в качестве default GW указан GW1. Прямой проброс и NAT невозможен, т.к. пакеты пришедшие из GW2 попытаются вернуться по маршруту через GW1. Есть следующий выход, это двойной NAT на GW2, при котором запрос приходит не снаружи, а с внутреннего IP. ed0 - внешний интерфейс lnc0 - интерфейс смотрящий внутрь. в ipnat.rules нужно прописать следующее: map ed0 10.6.10.0/24 -> 0.0.0.0/32 мапим локалку наружу map lnc0 0.0.0.0/0 -> 0.0.0.0/32 ремап внешних ip в локальные rdr ed0 0.0.0.0/0 port 80 -> 10.6.10.2 port 80 tcp форвард на внутренний сервер   Как с помощью ipfw отрезать баннеры в ICQ   Автор: orm_vartis  [комментарии]   Мысль простая: Аська сообщениями по 5190 и другим портам обменивается, а баннеры только с определенных IP с 80го порта качает по HTTP ... Когда я на это наткнулся, написал скрипт такого содержания: #!/bin/sh # add this rule to your firewall and : # ipfw deny tcp from 192.168.0.0/16 to table(1) out via rl0 setup dst-port 80 NETS=" 64.12.164 64.12.174 152.163.208 205.188.165 205.188.248 205.188.250 " IPS=" 25 57 121 153 185 245 " fwcmd=" ipfw " tablenum=" 1 " #Flushing table ${fwcmd} table ${tablenum} flush #Add tables ips for D1 in ${NETS} do for D2 in ${IPS} do ${fwcmd} table ${tablenum} add ${D1}.${D2} done done И в firewall воткнул правило вида ipfw deny tcp from any to table\(1\) out via rl0 setup dst-port 80 Где rl0 - внешний интерфейс. Правильнее, конечно настроить squid и резать банеры на нем - но так проще и быстрее. К тому же заметно меньше грузит машину.   Как разделить канал между пользователями используя ipfw. (доп. ссылка 1)   Автор: mgear  [обсудить]   /sbin/ipfw pipe 1 config bw 7000Kbit/s /sbin/ipfw queue 1 config pipe 1 weight 75 mask dst-ip 0x00000000 /sbin/ipfw queue 2 config pipe 1 weight 50 mask dst-ip 0x00000000 /sbin/ipfw queue 3 config pipe 1 weight 50 mask dst-ip 0x00000000 /sbin/ipfw queue 4 config pipe 1 weight 50 mask dst-ip 0x00000000 /sbin/ipfw add queue 1 ip from any to 192.168.0.0/24 /sbin/ipfw add queue 2 ip from any to 192.168.1.0/24 /sbin/ipfw add queue 3 ip from any to 192.168.2.0/24 /sbin/ipfw add queue 4 ip from any to 192.168.3.0/24 Итого имеем: одну толстую трубу на 7К и 4 очереди в нее. У первой приоритет 75% канала. У остальных - по 50%   Установка IPFW2 на FreeBSD   Автор: Tigran Parsadanian  [комментарии]   Собираем библиотеки и сам IPFW: cd /usr/src/lib/libalias make -DIPFW2 && make install cd /usr/src/sbin/ipfw make -DIPFW2 && make install Пересобираем ядро с "options IPFW2" и опциями по вкусу: options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options DUMMYNET options IPFW2 Делаем reboot и проверяем например командой "ipfw show"   Как в FreeBSD перебросить соединение через NAT во внутреннюю сеть  (доп. ссылка 1)   Автор: spanka  [комментарии]   Вот реализация для ipfw: if1IP="ип_смотрящий_в_инет", if1="интерфейс_смотрящий_в_инет" ifLIP="ип_на_который хотим делать редирект" ipfw add divert natd tcp from any to ${if1IP} 80 via ${if1} ipfw add divert natd ip from any to ${ifLIP} to any via ${if1} ipfw add allow tcp from any to ${if1IP} 80 via any natd -n ${if1} -redirect_port tcp ${ifLIP}:80 80 Решение от miaso <[email protected]>: tproxy -s 80 -r nobody -l /var/log/transparent_proxy.log [int_ip] 80   Как разрешить или запретить выполнение следующих ipfw правил после встречи dummynet pipe   [комментарии]   Завершить выполнение цепочки ipfw правил после попадания в pipe: sysctl -w net.inet.ip.fw.one_pass=1 Продолжить выполнение следующих ipfw правил после попадания в pipe: sysctl -w net.inet.ip.fw.one_pass=0   Как правильно зафильтровать ICMP через FreeBSD ipfw (доп. ссылка 1)   Автор: Nikola_SPb  [комментарии]   Расшифровка кодов ICMP сообщений: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router adver-tisement (9), router solicitation(10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). ${fwcmd} add 00300 allow icmp from any to внешний_IP in via внешний_интерфейс icmptype 0,3,4,11,12 ${fwcmd} add 00301 allow icmp from внешний_IP to any out via внешний_интерфейс icmptype 3,8,12 ${fwcmd} add 00304 allow icmp from внешний_IP to any out via внешний_интерфейс frag ${fwcmd} add 00305 deny log icmp from any to any in via внешний_интерфейс   Как организовать редирект порта на внутреннюю машину через ipnat в FreeBSD.   [комментарии]   man 5 ipnat в /etc/ipnat.conf: rdr fxp0 205.15.63.3/32 port 80 -> 192.168.1.1 port 80 tcp # Базансировка нагрузки между 2 IP: rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp round-robin   Как у ipfilter обнулить статистику без перезагрузки ?   [обсудить]   ipf -z -f my_ipfilter_rules_file   Как в ipfw если выполнилось условие, пропустить следующие N правил.   [обсудить]   ipfw add 50 skipto 100 tcp from any to 1.2.3.4 ipfw add 60 ..... ipfw add 100 .....   Пример ограничения полосы пропускания трафика в FreeBSD   [комментарии]   Собираем ядро с опциями: options DUMMYNET options IPFIREWALL Ограничиваем трафик для сеток 1.1.1.0/24 и 3.3.3.0/24 на 14000 кбит/с: ipfw add pipe 50 tcp from any to 1.1.1.0/24 via fxp0 ipfw add pipe 50 tcp from any to 3.3.3.0/24 via fxp0 ipfw pipe 50 config bw 14Kbit/s Для внесения задержки на N ms, используйте delay N после config. Для установки веса данного пайпа по отношению к другим пайпам используйте weight вес. Для WF2Q ограничения трафика используйте ipfw queue (queue N config [pipe pipe_nr] [weight weight] [queue {slots | size}) PS (комментарий от [email protected]): Если возникает необходимость организовать "канал" для каждого пользователя из данной сети то пишем: ipfw pipe 10 config mask dst-ip 0x000000ff bw 1024bit/s queue ipfw add pipe 10 tcp from any to 1.1.1.0/24 via fxp0 Теперь каждый хост из сети 1.1.1.0/24 имеет свой канал 1024bit/s   Можно ли отфильтровывать пакеты (вести лог) в зависимости от UID пользователя ?   [обсудить]   Для FreeBSD: ipfw add count tcp from any to not 192.168.1.0/24 uid 231 uid user (или gid group) - под правило попадают все TCP или UDP пакеты посланный или принятые пользователем user (группой group). В Linux в ядрах 2.4.x в iptables можно использовать модуль owner.   Как запретить открывать более 30 соединений с одного IP   [комментарии]   Запретим более 30 коннектов для 80 порта сервера 1.2.3.4. ipfw add allow tcp from any to 1.2.3.4 80 limit src-addr 30 ipfw add allow tcp from any to 1.2.3.4 80 via fxp0 setup limit src-addr 10 Вместо src-addr можно использовать src-port, dst-addr, dst-port Конструкция работает в последних версиях FreeBSD 4.x ветки.   Как обеспечить работу active FTP режима в FreeBSD NAT   [обсудить]   В ipnat воспользуйтесь модулем ftp proxy: map fxp0 0/0 -> 0/32 proxy port ftp ftp/tcp map rl0 172.16.33.0/24 -> 212.46.231.50/32 proxy port ftp ftp/tcp не забудьте поместить правило трансляции ftp перед общим правилом трансляции, порядок следования правил важен.   Как запустить трансляцию адресов (NAT) под FreeBSD   [комментарии]   В /etc/rc.conf: ipnat_enable="YES" В /etc/ipnat.rules: Трансляция адресов (NAT): map ppp0 172.16.1.0/24 -> 194.46.124.53/32 где, ppp0 - внешний интерфейс, 172.16.1.0/24 - внутренние IP, 194.46.124.53 - реальный IP внешнего интерфейса. Переброс порта во внутреннюю сеть: rdr ed0 294.16.9.6/32 port 8080 -> 192.168.0.7 port 8080 tcp где, ed0 - внешний интерфейс, 294.16.9.6 - реальный IP внешнего интерфейса, на который нужно обращаться из вне. 192.168.0.7 - внутренний IP на который делается переброс. 8080 - номер перебрасываемого порта. Перечитать: ipnat -CF -f /etc/ipnat.rules   Как организовать Policy Routing на FreeBSD   [комментарии]   ipfw add 100 fwd 10.0.0.2 ip from 10.0.2.0/24 to any Если нужно использовать 2 шлюза, то можно воспользоваться: ipfw add fwd $ext_gw_ip ip from $ext_net to any out xmit $ext_int   Автоматическая нумерация правил ipfw в FreeBSD (доп. ссылка 1)   Автор: Дмитрий Новиков  [комментарии]   Для автоматической нумерации правил ipfw мы применяем следующий несложный прием: C=300 # начальное значение STEP=100 # Шаг увеличения ipfw add $C $(C=$(($C+$STEP))) allow ip from 10.128.0.0/16 to 10.128.0.0/16 ipfw add $C $(C=$(($C+$STEP))) allow ip from 195.131.31.0/24 to 195.131.31.0/24